Have CI run on bookworm & trigger on GitHub's merge queue

[legoktm]

• Have CI run on bookworm
• Trigger CI on GitHub's merge queue
• Rebuild compiled wheels on bookworm, see Have CI run on bookworm & trigger on GitHub's merge queue #497 (comment) for explanation

Test plan

• visual review
• CI passes
• diffoscope of new wheels only shows diff to DW_ fields (and then checksums/CRC fields, etc.)

[legoktm]

Looking at why it's failing...

[legoktm]

Here's the diff for sqlalchemy:

├── sqlalchemy/cprocessors.cpython-311-x86_64-linux-gnu.so
│┄ File has been modified after NT_GNU_BUILD_ID has been applied.
│ ├── readelf --wide --notes {}
│ │ @@ -1,4 +1,4 @@
│ │  
│ │  Displaying notes found in: .note.gnu.build-id
│ │    Owner                Data size 	Description
│ │ -  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 502b719865e65a36a8fd1b4a80764ad08e5bd27e
│ │ +  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: d1f5c3b7ccb8d2e8044036737caa80b19830e1d6
│ ├── readelf --wide --debug-dump=info {}
│ │ @@ -367,28 +367,28 @@
│ │      <2ba>   DW_AT_decl_line   : (data1) 19
│ │      <2bb>   DW_AT_decl_column : (data1) 28
│ │      <2bc>   DW_AT_type        : (ref4) <0x2c0>, _longobject
│ │   <1><2c0>: Abbrev Number: 28 (DW_TAG_structure_type)
│ │      <2c1>   DW_AT_name        : (strp) (offset: 0xd2): _longobject
│ │      <2c5>   DW_AT_byte_size   : (data1) 32
│ │      <2c6>   DW_AT_decl_file   : (data1) 13
│ │ -    <2c7>   DW_AT_decl_line   : (data1) 79
│ │ +    <2c7>   DW_AT_decl_line   : (data1) 82
│ │      <2c8>   DW_AT_decl_column : (data1) 8
│ │      <2c9>   DW_AT_sibling     : (ref4) <0x2e8>
│ │   <2><2cd>: Abbrev Number: 2 (DW_TAG_member)
│ │      <2ce>   DW_AT_name        : (strp) (offset: 0x360): ob_base
│ │      <2d2>   DW_AT_decl_file   : (data1) 13
│ │ -    <2d3>   DW_AT_decl_line   : (data1) 80
│ │ +    <2d3>   DW_AT_decl_line   : (data1) 83
│ │      <2d4>   DW_AT_decl_column : (data1) 5
│ │      <2d5>   DW_AT_type        : (ref4) <0x65b>, PyVarObject
│ │      <2d9>   DW_AT_data_member_location: (data1) 0
│ │   <2><2da>: Abbrev Number: 2 (DW_TAG_member)
│ │      <2db>   DW_AT_name        : (strp) (offset: 0x6e9): ob_digit
│ │      <2df>   DW_AT_decl_file   : (data1) 13
│ │ -    <2e0>   DW_AT_decl_line   : (data1) 81
│ │ +    <2e0>   DW_AT_decl_line   : (data1) 84
│ │      <2e1>   DW_AT_decl_column : (data1) 11
│ │      <2e2>   DW_AT_type        : (ref4) <0xe17>, digit, uint32_t, __uint32_t, unsigned int
│ │      <2e6>   DW_AT_data_member_location: (data1) 24
│ │   <2><2e7>: Abbrev Number: 0
│ │   <1><2e8>: Abbrev Number: 5 (DW_TAG_typedef)
│ │      <2e9>   DW_AT_name        : (strp) (offset: 0x5f2): PyTypeObject
│ │      <2ed>   DW_AT_decl_file   : (data1) 9

pyyaml has roughly the same diff:

├── yaml/_yaml.cpython-311-x86_64-linux-gnu.so
│┄ File has been modified after NT_GNU_BUILD_ID has been applied.
│ ├── readelf --wide --notes {}
│ │ @@ -1,4 +1,4 @@
│ │  
│ │  Displaying notes found in: .note.gnu.build-id
│ │    Owner                Data size 	Description
│ │ -  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: ab81112a0ca3eac68d4286d376667ab7a846ea35
│ │ +  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 7cc5ec793c4b37d58d766d37736e9b5732e6e493
│ ├── readelf --wide --debug-dump=info {}
│ │ @@ -718,28 +718,28 @@
│ │      <554>   DW_AT_decl_line   : (data1) 19
│ │      <555>   DW_AT_decl_column : (data1) 28
│ │      <556>   DW_AT_type        : (ref4) <0x55a>, _longobject
│ │   <1><55a>: Abbrev Number: 62 (DW_TAG_structure_type)
│ │      <55b>   DW_AT_name        : (strp) (offset: 0x5062): _longobject
│ │      <55f>   DW_AT_byte_size   : (data1) 32
│ │      <560>   DW_AT_decl_file   : (data1) 21
│ │ -    <561>   DW_AT_decl_line   : (data1) 79
│ │ +    <561>   DW_AT_decl_line   : (data1) 82
│ │      <562>   DW_AT_decl_column : (data1) 8
│ │      <563>   DW_AT_sibling     : (ref4) <0x582>
│ │   <2><567>: Abbrev Number: 16 (DW_TAG_member)
│ │      <568>   DW_AT_name        : (strp) (offset: 0x1639): ob_base
│ │      <56c>   DW_AT_decl_file   : (data1) 21
│ │ -    <56d>   DW_AT_decl_line   : (data1) 80
│ │ +    <56d>   DW_AT_decl_line   : (data1) 83
│ │      <56e>   DW_AT_decl_column : (data1) 5
│ │      <56f>   DW_AT_type        : (ref4) <0xd64>, PyVarObject
│ │      <573>   DW_AT_data_member_location: (data1) 0
│ │   <2><574>: Abbrev Number: 16 (DW_TAG_member)
│ │      <575>   DW_AT_name        : (strp) (offset: 0x6cf2): ob_digit
│ │      <579>   DW_AT_decl_file   : (data1) 21
│ │ -    <57a>   DW_AT_decl_line   : (data1) 81
│ │ +    <57a>   DW_AT_decl_line   : (data1) 84
│ │      <57b>   DW_AT_decl_column : (data1) 11
│ │      <57c>   DW_AT_type        : (ref4) <0x171e>, digit, uint32_t, __uint32_t, unsigned int
│ │      <580>   DW_AT_data_member_location: (data1) 24
│ │   <2><581>: Abbrev Number: 0
│ │   <1><582>: Abbrev Number: 30 (DW_TAG_typedef)
│ │      <583>   DW_AT_name        : (strp) (offset: 0x19b0): PyTypeObject
│ │      <587>   DW_AT_decl_file   : (data1) 17

This is the DWARF debugging information, so I suspect some Python (or other thing we compile against) moved some source around, causing it to change line numbers since it was last built. I'll push the rebuilt wheels.

[eloquence]

Hm, if the wheels have changed, should we not have to update the sha256sums? I get this for the new SQLA wheel:

6883fcbac625a58b913ad7c546008f83071eafae6767bb570b2f47872bc211d2  SQLAlchemy-1.3.3-cp311-cp311-linux_x86_64.whl

[legoktm]

I knew I missed a step :/ Updating that... (also concerned that CI did not fail, maybe I accidentally removed that check in some monorepo refactoring??)

[legoktm]

Pushed updates to the shasums files and freedomofpress/securedrop-client#1974 for the build-requirements.txt changes.

[eloquence]

LGTM. Diffoscope results match yours: SQLAlchemy, PyYAML. Signatures verify. Hashes match local sha256sum check. Diff looks good. CI is happy.

[eloquence]

also concerned that CI did not fail, maybe I accidentally removed that check in some monorepo refactoring??

My read is that this would have failed previously because we we had build jobs in the same repo, and now we're just seeing the failure in the components. If that's correct, then I think we may want to implement some new basic sanity checks here to ensure no wheels are added/updated without corresponding checksums.

[legoktm]

If that's correct, then I think we may want to implement some new basic sanity checks here to ensure no wheels are added/updated without corresponding checksums.

Makes sense. I have a patch locally that I can't push right now, once the GH outage is over I'll upload it.