Hi all, 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 3.10). 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 everything migrated. 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 confused. I merged swi-prolog to fix the build with openssl3 but lots of dep8 tests now fail. 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: https://github.com/RafaelOstertag/yapet/issues/23 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 https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/531c31ae58aefc7c 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 past. Cheers, mwh
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
