Hi Sebastian, On Tue, Jan 09, 2024 at 10:49:23AM +0100, Sebastian Ramacher wrote: > > > > > > 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. Have you had enough time to check this out? Are we ok to proceed with handling libobs0 along with the other libraries, which would address the ABI skew despite it technically not being libobs0 whose ABI is changing? > > > > > > 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? The skip handling is in the block starting at https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads#L852 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
