This is a multi-part MIME message sent by reportbug.


Source: liblopsub
Version: 1.0.4-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
liblopsub 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 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 liblopsub
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.



-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru liblopsub-1.0.4/debian/changelog liblopsub-1.0.4/debian/changelog
--- liblopsub-1.0.4/debian/changelog 2023-07-02 12:12:13.000000000 +0000
+++ liblopsub-1.0.4/debian/changelog 2024-02-01 09:30:36.000000000 +0000
@@ -1,3 +1,10 @@
+liblopsub (1.0.4-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek <vorlon@debian.org> Thu, 01 Feb 2024 09:30:36 +0000
+
liblopsub (1.0.4-1) unstable; urgency=low

* Make the build reproducible (Chris Lamb, Vagrant Cascadian). Closes:
diff -Nru liblopsub-1.0.4/debian/control liblopsub-1.0.4/debian/control
--- liblopsub-1.0.4/debian/control 2023-07-02 12:12:13.000000000 +0000
+++ liblopsub-1.0.4/debian/control 2024-02-01 09:30:35.000000000 +0000
@@ -8,7 +8,10 @@
Vcs-Browser: http://git.tuebingen.mpg.de/lopsub.git
Vcs-Git: git://git.tuebingen.mpg.de/lopsub.git

-Package: liblopsub1
+Package: liblopsub1t64
+Provides: ${t64:Provides}
+Replaces: liblopsub1
+Breaks: liblopsub1 (<< ${source:Version})
Architecture: any
Depends: ${shlib

On Thu, Feb 01, 09:42, Steve Langasek wrote:

Source: liblopsub
Version: 1.0.4-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 liblopsub 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 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 liblopsub
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.

Thanks for the patch. I've applied it to a temporary git branch for
now, see below. Since the previous upload (1.0.4-1 in 2023-06) two
unrelated bugs have been found and fixed, so it would be good to get
these in as well. Do you want me to adjust the debian/changelog to
mention these fixes before merging the temporary branch?

If you have any concerns about this patch, please reach out ASAP.

No concerns but some questions:

* The tfortune package depends on liblopsub and currently has

Depends: ${shlibs:Depends}, liblopsub1, ${misc:Depends}

in its own debian/control file. When would be the best time to replace liblopsub1 by liblopsub1t64?

* Why did you call the new version 1.0.4-1.1? Why not 1.0.5-1 instead?

* Do I need to do anything else to get this going besides merging
the branch and pushing it to the public repo?

Thanks
Andre
---
commit 806c7a89423cf70c1593325de24be0b160ffde96
Author: Steve Langasek <vorlon@debian.org>
Date: Thu Feb 1 12:47:49 2024 +0100

64-bit time_t transition.

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
liblopsub 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 change to the default dpkg-buildflags
(https://bugs.debian.org/1037

On Thu, Feb 01, 21:13, Steve Langasek wrote:

* The tfortune package depends on liblopsub and currently has

Depends: ${shlibs:Depends}, liblopsub1, ${misc:Depends}

in its own debian/control file. When would be the best time to replace liblopsub1 by liblopsub1t64?

You should just drop this hard-coded dependency on liblopsub1. This is
what shlibs are for.

Done. Thanks for the suggestion.

* Do I need to do anything else to get this going besides merging
the branch and pushing it to the public repo?

No. Please do not upload this change to unstable; these changes will be batch-uploaded to unstable at the appropriate time, *after* dpkg has been uploaded to unstable changing the default build flags.

Once the NMU has been uploaded to unstable, you are free to make further uploads to unstable incorporating this change.

The master branch of the public repo now contains your patch.

Best
Andre
--
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAmW8xAMACgkQWto1QDEAkw+fPwCfaWQS4QcvjpPvbvl2kNSxY5VJ MSAAn3TbVOSm6ZXdrBItgYl+nzaMTPGK
=oGVr
-----END PGP SIGNATURE-----

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

This is a multi-part message in MIME format...

Your message dated Fri, 01 Mar 2024 06:04:18 +0000
with message-id <E1rfw0I-00EmOJ-UN@fasolo.debian.org>
and subject line Bug#1062407: fixed in liblopsub 1.0.4-1.1
has caused the Debian Bug report #1062407,
regarding liblopsub: NMU diff for 64-bit time_t transition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
1062407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062407
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

Received: (at submit) by bugs.debian.org; 1 Feb 2024 09:42:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
(2021-04-09) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-111.1 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FOURLA,FROMDEVELOPER,
HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_NONE,SPF_NONE,
T_SCC_BODY_TEXT_LINE,USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST,
XMAILER_REPORTBUG autolearn=ham autolearn_force=no
version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 35; hammy, 150; neutral, 276; spammy,
0. spammytokens: hammytokens:0.000-+--sk:taint_o, 0.000-+--sk:TAINT_O,
0.000-+--trixie, 0.000-+--langasek, 0.000-+--Langasek
Return-path: <vorlon@homer.dodds.net>
Received: from becquer.dodds.net ([207.224.24.209]:56069)
by buxtehude.