On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote: > Hi Steve
> > - perl will also get a sourceful upload, to manually handle 'perlapi' > > Provides. > Can we combine this one with the upcoming perl transition? See #1055955. Pros and cons of combining: - it will save another rebuild of perl modules - new perl upstream versions usually break at least some reverse-dependencies in the archive, so this may slow down the time_t transition to testing for other packages by entangling it with sourceful perl changes. The release team has already suggested not entangling the two. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955#10 > Here are some more comments on individual packages. > > 22 libobs-dev > That's a change to the plugin ABI only. Can you explain how you've reached that conclusion? This is a package that failed to be analyzed in the latest run; an earlier run against Ubuntu lunar showed no change in ABI at all. Looks like the failure to analyze should be easily fixable (maybe libobs-dev shouldn't be shipping this header?) https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libobs-dev/base/log.txt > > 14 gnuradio > gnuradio bump its SONAME every other month. And usually takes time, at least from what I've seen on the Ubuntu side, to settle all reverse-dependencies out into a consistent state where they can migrate to testing > > 9 libopenmpt-dev > Seems to be a false positive. <snip> Your responses here are to the contents of the `sorted-revdep-count` list. This is the list of header packages that *we were unable to analyze with abi-compliance-checker*, and so in the interest of avoiding ABI mismatches and broken systems for users when upgrading on 32-bit archs, would get a package rename to be safe. This is the plan I had outlined at: https://lists.debian.org/debian-devel/2023/07/msg00232.html I am happy for any help in the form of patches to https://salsa.debian.org/adrien-n/armhf-time_t that fix the failures of these header packages to be analyzed, or explanations for how a given header package's API changes cannot affect the ABI of the runtime libraries from the source package so that we can manually exclude those libraries from the transition. I am not sure I would *recommend* that maintainers spend a lot of time on proving one or another individual library does not have an ABI breakage, especially in the long tail of libraries with few reverse-dependencies whose involvement in the transition is unlikely to substantially slow down Debian development. > > 5 gcc-10-plugin-dev > Can be skipped, not part of testing. Should be RMed from the archive > instead. Thanks, I had already manually excluded gcc-13-plugin-dev from the transition, but there are gcc-*-plugin-dev in the archive for 4 other versions of gcc. I've updated things here to exclude all of them now. I will not, in general, exclude a library from the transition only because it's currently not in testing; this could be a transient situation, and users' shouldn't wind up with broken partial upgrades of this library later if it returns to testing. > > 4 llvm-15-dev > llvm-toolchain-15 is scheduled for removal. Reverse dependencies should > get an RC bug instead. > > libavutil58 > av_timegm is not used by any package in the archive. I'd skip ffmpeg and > it's libraries. How did you determine that it's unused by any reverse-dependencies? I'd be happy to exclude it, but want to be sure we're not exposing users to bugs in the process. > > libpoppler-cpp0v5 > > libpoppler-glib8 > > libpoppler-qt5-1 > > libpoppler-qt6-3 > > libpoppler126 > Can be combined with the upcoming poppler transiton (see #1060019) Again, combining the time_t transition with transitions introducing sourceful changes (and possible API incompatibilities) to existing libraries risks slowing the transition down to Debian's detriment. > > libvlc5 > > libvlccore9 > Change to vlc plugin ABI. This does not require a change of the binary > package name. There are other reverse-dependencies of libvlccore9 in the archive that are not VLC plugins (phonon4qt5-backend-vlc etc). Are these packages simply mis-linked against that library? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
