HiAdding RT and Python team to this bug because I feel this is actually a bug else where (namely `py3clean` / `dh-python`). With that said, I do not think we can fix this properly for `trixie` and instead should rely on the work around of having `libexpat1` Pre-Depends on `libc` as Lucas suggest below (it would be a trivial patch).
As short context, Lucas found a case where the upgrade can break with:
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
This is triggered by calling `py3clean` from a `prerm` script at an inopportune moment where `libc` has not yet been upgraded but `libexpat1` has.
My recommendation is to:
1) Patch `libexpat1` to use `Pre-Depends: ${shlibs:Depends}`. It only
has a single dependency on amd64 (libc), so it should be safe and be
a work around
2) File an RC bug against `python3-minimal,dh-python` that is
immediately tagged `trixie-ignore` for the Python team to find a
better long term solution.
--> Do we agree with this proposal for moving forward for Trixie?
The reason why I think the bug is somewhere in Python stack is that we
call `py3clean` from the `prerm` of all our Python packages per Python
Policy. Now, the `prerm` comes with a guard to only call `py3clean` if
the command is present.
However, the scripts still assume that `py3clean` is functional at the time `prerm` is invoked. As Lucas demonstrate, this assumption is not fulfilled. In fact, any dependency of `python3-minimal` (provider of `py3clean`) can be in state `Half-Installed` and completely busted at the time `prerm` is invoked. The only guarantee we have are `Essential: yes` packages and things they (Pre-)Depend on as they are required to always be functional once unpacked at least once.
Consequently, the `prerm` scripts with `py3clean` are generally all RC buggy in the current state as I understand the situation, since they assume `py3clean` is functional if present and we have never been able to guarantee that it was functional.
If the fix requires a new maintscript template via `dh-python`, then it would rely a rebuild of every python package to fully be rolled out. This does not seem realistic nor desired at this point of the freeze (especially, since most of them cannot be binNMUed). That is why I recommend a quick fix to `libexpat1` and maybe `zlib1g` (also an indirect dependency of `python3-minimal that does not use `Pre-Depends`).
Obviously, if we can somehow fix this in `python3-minimal` or `python3.13-minimal` then my recommendation becomes moot. But it is beyond what I can figure out how to do (it would require `python3` to be able to run `py3clean` with a broken `libexpat1` or with `python3.13-minimal loosing its dependency on `libexpat1`. Neither of which sounds trivial).
Since I suspect the implementation of the proper long term fix might be a bit beyond the horizon for the freeze, I am recommending we file a new `trixie-ignore` RC bug for that (or at least a `trixie-can-defer` if `trixie-ignore` is not desired for some other reason).
This concludes my rationale for my recommendation above. Please let me know if we should proceed based on said recommendation. Best regards, NielsPS: The following is the original bug from Lucas quoted in full for the benefit of the newly added CC recipients.
On Tue, 8 Jul 2025 11:39:37 +0200 Lucas Nussbaum <lu...@debian.org> wrote:
Package: libexpat1 Version: 2.7.1-1 Severity: serious Control: affects -1 python3-cryptography Hi, While testing upgrades from bookworm to trixie, I ran into the following issue, that affects upgrades for the following packages: arctica-greeter-remote-logon barbican-tempest-plugin changeme cinder-tempest-plugin cloudkitty-tempest-plugin designate-tempest-plugin firejail-profiles firejail firetools glance-tempest-plugin horizon-tempest-plugin ironic-tempest-plugin jeepyb keystone-tempest-plugin lightdm-remote-session-x2go magnum-tempest-plugin manila-tempest-plugin mistral-tempest-plugin placement-common pyhoca-cli python3-placement python3-tempest python3-tempestconf python3-x2go refstack-client remmina-plugin-x2go ros-perception ros-viz senlin-tempest-plugin telemetry-tempest-plugin tempest vorta watcher-tempest-plugin zaqar-tempest-plugin In a bookworm chroot, I do: apt-get update && apt-get -y install pyhoca-cli && sed -i s/bookworm/trixie/ /etc/apt/sources.list && apt-get update && apt-get -y upgrade (that is, install pyhoca-cli, then apt-get upgrade to trixie) The situation in the chroot is then the following: # dpkg -l |grep -e libc6 -e libexpat1 -e python3-cryptography ii libc6:amd64 2.36-9+deb12u10 amd64 GNU C Library: Shared libraries ii libexpat1:amd64 2.5.0-1+deb12u1 amd64 XML parsing C library - runtime library ii python3-cryptography 38.0.4-3+deb12u1 amd64 Python library exposing cryptographic recipes and primitives (Python 3) now, if I apt-get dist-upgrade, one possible ordering results in: Preconfiguring packages ... (Reading database ... 14370 files and directories currently installed.) Preparing to unpack .../00-openssl_3.5.0-2_amd64.deb ... Unpacking openssl (3.5.0-2) over (3.0.16-1~deb12u1) ... Selecting previously unselected package libpython3.13-minimal:amd64. Preparing to unpack .../01-libpython3.13-minimal_3.13.3-2_amd64.deb ... Unpacking libpython3.13-minimal:amd64 (3.13.3-2) ... Preparing to unpack .../02-libexpat1_2.7.1-1_amd64.deb ... Unpacking libexpat1:amd64 (2.7.1-1) over (2.5.0-1+deb12u1) ... Preparing to unpack .../03-python3-cryptography_43.0.0-3_amd64.deb ... + set -e + command -v py3clean + py3clean -p python3-cryptography:amd64 /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1) dpkg: warning: old python3-cryptography package pre-removal script subprocess returned error exit status 1 dpkg: trying script from the new package instead ... /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1) dpkg: error processing archive /tmp/apt-dpkg-install-4LX8Uy/03-python3-cryptography_43.0.0-3_amd64.deb (--unpack): new python3-cryptography package pre-removal script subprocess returned error exit status 1 + set -e + command -v py3compile + py3compile -p python3-cryptography:amd64 /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libexpat.so.1) dpkg: error while cleaning up: installed python3-cryptography package post-installation script subprocess returned error exit status 1 I believe that this happens if the following ordering is picked by apt: - unpack libexpat1/trixie - unpack python3-cryptography/trixie - unpack libc6/trixie if another package causes libc6 to be unpacked earlier, of course the issue doesn't happen. I had trouble reproducing the issue in a larger environment because of this. Also, this doesn't happen if apt is upgraded before 'apt-get upgrade', because upgrading apt would pull a newer libc6. But I see that the releae notes no longer recommend upgrading apt prior to running 'apt-get upgrade' I'm obviously fine with the severity being downgraded to non-RC. Also I'm not sure of my analysis above, so please take it with a grain of salt. Lucas
OpenPGP_signature.asc
Description: OpenPGP digital signature
