On Wed, 28 Feb 2024 at 22:40, Steve Langasek <vor...@debian.org> wrote: > > 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.
Sorry, that's not how it works. If you report a bug, you need to provide enough information to prove that there really is a bug. If you don't have the capacity or time, that's fine, but it means nothing gets changed. > I'm not going to argue with you about this. Expect an NMU incoming. Expect it to be immediately followed by a revert.
