##### cyrus-common - LP: #1971469 #####
cyrus-common had test failures around usage of EVP_PKEY_base_id. The usage of
this function seems to have changed somewhat, and cyrus-common was not using it
in a method consistent with the v3 OpenSSL manpage for EVP_PKEY_base_id. That
manpage suggests instead using EVP_PKEY_is_a for checking key types in this
scenario, which seems to work well.
Status: Forwarded upstream, merged to Debian (Thanks Yadd) and autosynced.
Jammy Status: the affected code was introduced as part of 3.5, and the version
of cyrus-common in Jammy is 3.4.3. I see no reason to believe that a SRU would
be needed.
##### osmo-mgw - LP: #1971620 #####
osmo-mgw turned out to have different behavior if you had systemd installed in
the build environment, and by default schroot does not. If systemd is present,
it causes an unexpected file to appear in the list of files to install, then
dh_missing complains.
Status: Fix proposed to Debian and also listed at above LP.
##### gyoto vs lorene - LP: #1971735 #####
gyoto had a LTO version conflict with a .a file found in liblorene-dev.
The symptom of that is:
lto1: fatal error: bytecode stream in file '/path/to/foo.a' generated with LTO
version 11.2 instead of the expected 11.3
By rebuilding liblorene-dev, I could use that for a working gyoto build.
However, this suggests a category problem with .a files. See below.
Status: Uploaded (Thanks Graham)
##### LTO vs .a files #####
Existing .a files in packages built with LTO could trigger the above problem.
I wrote some tooling to go looking for such things.
https://github.com/dbungert/lto-rebuild-detect
Getting the LTO version was harder than expected - lto-dump doesn't expose it
yet, so doing so requires a patched lto-dump or manual parsing of the info.
(no thanks!)
That said, it was still possible to detect this problem.
for each deb containing a .a file
for each .a file
run lto-dump from the correct version of gcc
look for a errors 'generated with LTO version X instead of ...'
It's not enough to just check the lto-dump return code, since it can fail for
other reasons - for example, lto-dump will fail on object files in .a files
in golang-golang-x-tools-dev, but the error is probably not LTO:
lto-dump-11: error: /tmp/tmp38g9q35d/archive-2/_go_.o: file not recognized
Based on this script, for AMD64 only looking at -dev packages, I found a few
candidates of packages I expect need a rebuild:
libbenchmark-dev
libbluetooth-dev
libdpdk-dev
libhts-dev
liblorene-dev
libngtcp2-crypto-gnutls-dev
libunwind-dev
libunwind-setjmp0-dev
libwmf-dev
libwvstreams-dev
slurm-wlm-basic-plugins-dev
(What's the best way to request sponsorship of a small batch of rebuilds?)
##### retest items #####
I didn't spend too much time trying to do retests - the queues have been awful
this week - but did request a few:
* cif-api
* yaz
##### other things #####
* armci-mpi - I was able to verify the test failures but didn't get too far
with it. ppc64el and s390x failures look different. s390x looks like an
endianness problem maybe.
* android-platform-system-core - problem with debug flags? Looks like this:
https://sourceware.org/bugzilla/show_bug.cgi?id=24756
-Dan
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
