On Tue, Jan 30, 2024 at 03:18:23PM +0000, Lukas Märdian wrote:

Source: gap
Version: 4.12.1-2
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-arm@lists.debian.org
Usertags: time-t

Dear maintainer,

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 change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for gap
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. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads.

Hello Lukas, you uploaded 4.12.2-1.1 to experimental.

The upstream version (4.12.2) in experimental should never be uploaded to unstable,
because it breaks the build interface. There will be a new upstream version (4.13.0)
with a new soname (libgap.so.9) that will replace it and that I will eventually upload to unstable.

Secondly, your patch do not actually make libgap8t64 to actually use 64-bit time_t,
and it seem very dangerous to have a library named libgap8t64 that do not actually
use 64-bit time_t.

There is a single package that depend on libgap8 (python3-sage) and it is seriously
out of date, so we should probably wait for the new upstream version instead of introducing libgap8t64.

So if one really need to introduce libgap8t64, we need a patch for the version of GAP in unstable that actually use 64-bit time_t.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 01.02.24 um 16:13 schrieb Bill Allombert:

On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:

Hi Bill,

thanks for the heads-up!
The same debdiff should apply to the version in unstable (4.12.1).
We'll make sure to NMU the version from unstable.

How do you plan to make sure libgap8t64 actually use 64-bit time_t ?
This issue will also need to be solved with libgap9.

It will pick up the new 64-bit time_t ABI automatically, by recompilation with corresponding buildflags.
Those are currently staged in src:dpkg in experimental and will eventually move to unstable.

See: https://bugs.debian.org/1037136

-- Lukas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:

thanks for the heads-up!
The same debdiff should apply to the version in unstable (4.12.1).
We'll make sure to NMU the version from unstable.

Waiting for libgap.so.9 would also be an option, if timing works out.

Fortunately libgap.so.9 was prereleased today.
Would that mess anything if I upload it to experimental ? I expect not.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)