I believe I pushed the SQLite 3.50.3 sources to https://github.com/python/cpython-source-deps/releases/tag/sqlite-3.50.3.0 properly.

I've added builds of this version to https://github.com/beeware/cpython-android-source-deps.

!buildbot android

🤖 New build scheduled with the buildbot fleet by @mhsmith for commit c69125d 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137135%2Fmerge

The command will test the builders whose names match following regular expression: android

The builders matched are:

• aarch64 Android PR
• AMD64 Android PR

I believe I pushed the SQLite 3.50.3 sources to https://github.com/python/cpython-source-deps/releases/tag/sqlite-3.50.3.0 properly.

Somehow the sqlite branch head and the sqlite-3.50.3.0 tag refer to different commits that differ only in CommitDate. Other than that, either commit does the update correctly.

Oh, except that both branch from the sqlite-3.45.3.0 tag, not from sqlite-3.49.1.0 :(

except that both branch from the sqlite-3.45.3.0 tag, not from sqlite-3.49.1.0 :(

I don't think this matters? at least not any more so than it not mattering the past few updates? All the sqlite- tags since that 3.45.3.0 one are in a similar state. I think this is due to people using a fork to push to initially? the commits "don't appear in this repository" which I think is GH for they're identified as being in a fork's repo? (GH repos are a unified hash namespace across all forks) A little confusing to me how github manages such a weird state of a tag in a repo who's commit claims not to be.

in my own fork i probably re-pushed my branch after fixing the commit signing after getting that setup in order to follow the instructions that wanted a signed tag. (my tag was signed regardless)