Hi Steve On 2024-01-05 20:26:56 -0800, Steve Langasek wrote: > 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.
Sorry for being unclear. My comment was related to the perl transition. Perl 5.38 will start (ACKed yesterday, it was blocked on our side) before this one and we try to complete it before starting time_t. > > 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. Sounds good to me (provided FPT master are happy to fast track those uploads). > > > > > 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? I need some more time to check the current situation. > > > > > 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. I was looking at the repo but it is unclear to me how packages that can be skipped are handled there. What would a PR look like to exclude specific packages? > > > > 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 :) vlc-plugin-pipewire is fixed, the fix for vlc-plugin-bittorrent is pending. If the upload of vlc-plugin-bittorrent does not happen before starting the time_t transition, I'll NMU it. (I will also fix both patckages in stable since we routinely update to new vlc stable releases that could also change the plugin ABI.) Cheers -- Sebastian Ramacher
