On Wed, Feb 28, 2024 at 09:38:06PM +0000, Luca Boccassi wrote: > On Wed, 28 Feb 2024 at 20:15, Steve Langasek <vor...@debian.org> wrote: > > On Wed, Feb 07, 2024 at 08:05:52PM +0000, Holger Levsen wrote: > > > On Wed, Feb 07, 2024 at 04:25:17PM +0000, Luca Boccassi wrote: > > > > Control: tags -1 -pending > > > > Control: close -1 > > > [...] > > > > There are no mentions of 'time_t' in the public headers of this > > > > library. The logs shows that it's a false positive, as the automated > > > > tool simply wasn't able to build it: > > > [...] > > > > Closing as not applicable. > > > > This is not sufficient reason to consider the bug a false-positive. time_t > > is *not* the only type eaffected by this, and the entire reason that we use > > abi-compliance-checker for identifying packages that need uploaded is to > > ensure we have deep inspection of the exposed types via a compiler rather > > than a grep that we know will have false-negatives.
> Well, the title of this bug is "NMU diff for 64-bit time_t > transition", and the bug description said: > "we have identified libcomps as a source package shipping runtime > libraries whose ABI either is affected by the change in size of > time_t, or could not be analyzed via abi-compliance-checker" > So the fact that there's no trace of time_t to be found and the script > was broken and couldn't find anything either sounds to me more than > enough to say it is a false positive. > If there are more things that can affect this, then the bug > description ought to at least mention what they are and why, but right > now it doesn't. > > So, I'm reopening this bug report. This package has already been skipped > > over in the short term for NMUing to unstable, so you can take some > > additional time to do your own analysis - but barring that, I will plan to > > do the NMU in 2 days. > If you can fix the script and show it is actually needed then sure, > please feel free to reopen and show that it's actually needed. But > otherwise no, having to carry a silly package name forever "just in > case" is very much not ok, sorry. Seven months ago, the fact that we did not have capacity to fix every library package that ships broken headers was communicated to debian-devel and that if maintainers wanted to be sure they didn't get an unnecessary transition, they were welcome to contribute patches to the analysis scripts or fix their packages to make the headers analyzable. The log showing the headers are broken is at https://adrien.dcln.fr/misc/armhf-time_t/2024-02-26T12%3A07%3A00/logs/libcomps-dev/base/abi-compliance-checker.log I'm not going to argue with you about this. Expect an NMU incoming. -- 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
