Control: close -1 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.
