Bug#980084: nmu: binNMUs for statically linked binaries built with glibc (<< 2.31)
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: binnmu
Dear release team,
Now that (build-)essential is frozen, the glibc package will only see
minor changes up to the bullseye release. I therefore think it's the
good moment to binNMUs packages with binaries statically linked against
older versions of glibc. This will reduce the number of glibc versions
shipped in bullseye and gives time ahead of the release to find possible
issues that could be introduced by this rebuilds (the autopkgtests can't
detect issues due to the statically linkage).
Here is a first list of binNMUs for packages built using glibc (<< 2.31):
nmu aide_0.16.1-1 . ANY . -m "Rebuild against latest glibc" # currently 2.28-8
nmu cdebootstrap_0.7.7 . ANY . -m "Rebuild against latest glibc" # currently 2.28-10
nmu prelink_0.0.20131005-1.1 . ANY . -m "Rebuild against latest glibc" # currently 2.30-4
nmu sash_3.8-5 . ANY . -m "Rebuild against latest glibc" # currently 2.28-8
nmu tripwire_2.4.3.7-3 . ANY . -m "Rebuild against latest glibc" # currently 2.30-4
nmu zsh_5.8-5 . ANY . -m "Rebuild against latest glibc" # currently 2.30-8
nmu zutils_1.9-1 . ANY . -m "Rebuild against latest glibc" # currently 2.30-8
The are a few other packages not built with the latest glibc, but they
are at least built with glibc (>= 2.31-3). I think we can binNMU them
later in the release process, as there might be a new glibc upload or
they might also get uploaded in the meantime.
Regards,
Aurelien
Reply to: