Source: libcompschange
Version: 0.1.19-2.1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-arm@lists.debian.org
Usertags: time-t
Dear maintainer,
As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), 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 (and therefore to be on the safe
side we assume is affected).
To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.
Since turning on 64-bit time_t is being handled centrally through a
to the default dpkg-buildflags (https://bugs.debian.org/1037136), itis
important that libraries affected by this ABI change all be uploadedclose
together in time. Therefore I have prepared a 0-day NMU for libcompsAlthough
which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW.
Please find the patch for this NMU attached.
If you have any concerns about this patch, please reach out ASAP.
this package will be uploaded to experimental immediately, there willbe a
period of several days before we begin uploads to unstable; so ifinformation
becomes available that your package should not be included in thetransition,
there is time for us to amend the planned uploads.
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.
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.
On Wed, 28 Feb 2024 at 20:15, Steve Langasek <vorlon@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.
On Wed, Feb 28, 2024 at 09:38:06PM +0000, Luca Boccassi wrote:
On Wed, 28 Feb 2024 at 20:15, Steve Langasek <vorlon@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.
I'm not going to argue with you about this. Expect an NMU incoming.
On Wed, Feb 28, 2024 at 09:38:06PM +0000, Luca Boccassi wrote:
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.
We have done the work now to get an out-of-band result from abi-compliance-checker confirming that this library's ABI is not affected.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 06:34:17 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,028 |