+1 maintenance report
michael.hudson at canonical.com
Fri Mar 4 01:07:12 UTC 2022
I was on +1 this week and managed to help a few things along, at least (it
was a bit of a disrupted week).
The python transition. Oh boy, the python transition.
When I first looked at this, I was lead to sssd and samba, both of which
reported regressions in adsys. This turned out to be samba's fault
(incompatible command line options in 4.15) and I filed
https://github.com/ubuntu/adsys/pull/289 as a sort of simplest
possible solution. I uploaded this to the archive but then the build failed
on ppc64el and dep8 tests failed on armhf. Steve removed the package from
the archive to let the transitions go through.
The new version of avogadrolibs failed in strange ways. Steve removed this
for now (fortunately there was already a version that worked with Python
But no! Then britney found more things to be unhappy about. One of these
was an "implicit dependency" chain pointing at astropy / poliastro, which
was dealt with with a hint. A few more things got in the way, including a
component mismatch, and the next thing was a build failure of capnproto on
ppc64el. This turned out to be some undefined behaviour that upstream had
already fixed, so I backported that and uploaded it.
The final obstacle turned out to be wireshark ftbfs on s390x. Eventually it
turned out that previous versions had ignored test failures on s390x and
this was only removed by a typo. So doko put that back and finally finally
It has to be said, the way britney only revealed one blocking implicit
dependency chain at a time wasted a whole lot of time here. I wonder if
there is anything we can do about that?
In between all this I started looking at the nbs report for libssl1.1.
The no change rebuild of scrypt had failed to build on ppc64el so on a
total hunch I tried rebuilding it without -O3 in a PPA and that succeeded
so I uploaded it and it migrated.
ntpsec was also on the nbs report too. We'd synced a version from Debian a
few days ago that built with openssl3 but the debian/control file still had
libssl1.1 as an explicit dependency so I removed that and uploaded it. It
migrated. This got fixed in Debian very quickly as well so I synced it
when it became possible.
I looked very briefly at xml-security-c-utils and xmltooling and got
I merged swi-prolog to fix the build with openssl3 but lots of dep8 tests
sblim-sfcb ftbfs when rebuilt for ssl3 but the failure was not ssl related;
rather it was missing dependencies in the automake stuff and some
assumptions that -fcommon was the default. I fixed these and uploaded the
package and it migrated.
mumble ftbfs with openssl3 which is fixed upstream but the patch does not
apply cleanly. There is a new upstream version which will be easier to
backport the fix too it seems but that would require a FFe...
yapet fails to build with openssl3 so i reported this upstream:
After finding another package (libpython2.7-stdlib) that had an explicit
dependency on libssl1.1 I got Seth Arnold to search his collection of every
unpacked source package from the archive and found a small number of other
packages with similar dependencies:
- nim, where the openssl support works by dlopening a bunch of libcrypto
sonames. Unclear to me if it will work with openssl3.
- rhash also dlopens some libcrypto sonames but this one was simple enough
that I could tell it would still work with openssl3 so I added
libcrypto.so.3 to the list and uploaded it.
- qt6-base also dlopens a bunch of libcrypto sonames but appears to have
support for openssl3 so it's just a matter of fiddling the deps around,
mitya57 has some changes
that I / someone should get around to testing / proposing properly
- nvidia-cuda-toolkit -- this was actually in Build-Depends not Depends
and is clearly a special package (the source package is 14 gigs
uncompressed!) so I asked Graham who appears to have uploaded it in the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ubuntu-devel