On 2024-01-05 11:06:09 -0800, Steve Langasek wrote: > 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
That was two months ago and we were expecting some progress. There was however none so far. As perl 5.38 is already staged in exeperimental, there are only two options: time64_t waits until perl 5.38 is done or we entangle them. The same is true for all the other transitions (poppler, g2clib, ...) that are currently staged in experimental. So unless we want to tell everyone to stop preparing transitions in experimental (which is contrary to what we, the RT, tell maintainers to do all the time), get everything from experimental removed, etc, I expect that we have to entangle time64_t and all transitions that are staged in experimental. > > 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. libobs-dev and the shared library are an oddity of obs-studio. There only purpose is to build plugins. > > 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 I wouldn't waste my time with gnuradio. The maintainers does not coordinate transitions. After January 10th assuming that AUTORM kicks in, it won't be relevant any more. > > > 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. Based on the number of false positives in the libraries that I maintain, the time it takes to prepare, upload, accept from binNEW, etc. with involvement from different teams, I wonder if would not be more efficient to give maintainers some time to check their packages. > > > 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. I added a hint so that gcc-10 cannot migrate back 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. Manually checked via codesearch.debian.net. The only occurrences are in ffmpeg itself and embedded copies of ffmpeg. > > > 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. Same as with perl. > > > 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? No, they are not. The part that changes is exclusiv to plugins. I will deal with this change by updating the vlc-plugin-abi-$x Provides. Cheers -- Sebastian Ramacher
