On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote: > 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. Sorry, what were you expecting exactly? I've had no communication from the Release Team until now about expectations, including on the debian-devel thread back in July. > 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. Rene and Paul raise this concern as well. However, there is another option. For any packages involved in this transition which currently have new versions staged in experimental which are not yet ready to go to unstable, we can simply exclude them from the upload to experimental, and do the NEW processing for this subset of packages directly in unstable as part of the second step. This should be an ABI change but not an API change; the rate of new build failures should be very small (small enough that I have not proposed any rebuild testing as part of this transition). As previously discussed, there may be some impact from -Werror=implicit-function-declaration but those can be quickly dealt with. Barring any existing testing migration blockages, I expect this whole assembly to be able to migrate to testing rather quickly. The main point is that we don't want to have a large window between landing dpkg in unstable, and uploading the libraries in unstable, due to NEW processing; because that will result in misbuilt and crashy combinations of packages on armhf until resolved. And if the time_t transition goes into unstable, has not yet migrated to testing, and some of the library transitions in question are ready to go to unstable, I don't mind; I'm happy to work with the maintainers of those libraries to get the transitions done, and also they can just ignore the previous NMUs because they're getting a new SONAME anyway. Does this seem practicable to you (and the release team generally)? > > > > 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. Ok, but it appears there are a large number of reverse-dependencies on libobs0 from other source packages, and there is no OTHER encoding of information about plugin ABI aside from this (no Provides: field on obs-studio). So what do you suggest here with respect to ABI skew between obs-studio and its plugins on armhf? > > 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. It wastes less of my time to *not* special-case it, then ;-) > > > > 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. I wasn't directly involved in the discussion, but I understand Julian Klode was able to sort out a fast-pass review plan for binNEW with the ftp team that should make the per-package costs, and the processing time, trivial. I am of course open to any maintainers improving this analysis to exclude libraries from the transition; even if everything goes smoothly for the transition itself, every package we prune from the list will save buildd time if nothing else. But I also don't want maintainers to feel they need to spend a lot of time on this, as that does not align with my idea of "more efficient". > > > > 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. Thanks, I've manually excluded it from the list. This reduces the count of reverse-dependencies needing rebuilt from 5477+174 to 5452+177. > > > > 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. This further reduces the count of reverse-dependencies needing rebuilt from 5452+177 to 5450+178. A net gain of 1 package as a result of you handling this manually instead for the plugin abi, and it's not even phonon-backend-vlc fwiw. *And* it doesn't appear that the plugins from separate source packages even depend on vlc-plugin-abi-3-0-0f, only on libvlccore9? Let me know if you'd like me to put this back and handle the transition for you :) -- 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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature