Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On Wed, Feb 28, 2024 at 12:50:16AM +0100, Thomas Goirand wrote: > Hi Steve, > The time_t transition was only for 32 bits arch support, right? It needs > nothing in 64 bits arch. > If that's the case, then you can remove Ceph from your list. The > Experimental package of Ceph, already lost support for 32 bits, and I asked > all reverse dependency maintainers to remove Ceph support on 32 bits arch > (this includes various packages like Samba, Qemu, etc.). > When I'll have time to work on Ceph again, then I'll upload Ceph 18.2.x from > Experimental, and that will mean no 32 bits support for Ceph in Debian > anymore. > Can you please confirm that I'm right above, so that on my next upload of > Ceph 18.2.x to unstable, I can close this bug? Yes, if you are dropping 32-bit support then you can close the bug then. In the short term, this is still on the list of packages to NMU for transition. Even if it will be dropped on armhf before release, we don't want to risk problems with ABI skew of the existing reverse-dependencies clogging up buildability or migratability so it's safest to just make sure we rebuild with the new name. But once 32-bit is dropped you should feel free to ignore the rename (except perhaps that you should then add Provides/Breaks/Replaces back the other direction for t64). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On 2/27/24 08:07, Bernd Zeimetz wrote: Hi Steve, I would not bother too much, actually I'm winding why ceph was not yet removed from the 32bit architectures. It's just not supported by upstream and although it builds, I would not trust it to work correctly. Bernd Hi Bernd, Well, Ceph 18.2.x was able to build in unstable. It's not anymore, because of the Cython 3.0 transition that made src/pybind/rados/rados.pxd not buildable. Otherwise, I would have upload it... If you know how to fix, please help. All reverse 32 bits use of Ceph must have been removed already from Debian at this point. I believe I did everything else that was needed for 18.2.x to be in good enough shape for Unstable, but I'm a bit stuck on that Cython 3 pb. :/ I've pushed my latest work (ie: upgrading to 18.2.1+ds) to Git... Cheers, Thomas Goirand (zigo)
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On 1/31/24 10:00, Steve Langasek wrote: Source: ceph Version: 16.2.11+ds-5 Severity: serious Tags: patch pending Justification: library ABI skew on upgrade User: debian-...@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 ceph 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 ceph 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. Hi Steve, The time_t transition was only for 32 bits arch support, right? It needs nothing in 64 bits arch. If that's the case, then you can remove Ceph from your list. The Experimental package of Ceph, already lost support for 32 bits, and I asked all reverse dependency maintainers to remove Ceph support on 32 bits arch (this includes various packages like Samba, Qemu, etc.). When I'll have time to work on Ceph again, then I'll upload Ceph 18.2.x from Experimental, and that will mean no 32 bits support for Ceph in Debian anymore. Can you please confirm that I'm right above, so that on my next upload of Ceph 18.2.x to unstable, I can close this bug? Cheers, Thomas Goirand (zigo)
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
Hi Steve, I would not bother too much, actually I'm winding why ceph was not yet removed from the 32bit architectures. It's just not supported by upstream and although it builds, I would not trust it to work correctly. Bernd 31.01.2024 10:03:28 Steve Langasek : > Source: ceph > Version: 16.2.11+ds-5 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@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 > ceph 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 ceph > 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'), (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)
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On Wed, Jan 31, 2024 at 09:00:26AM +, Steve Langasek wrote: > 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 ceph > which will initially be uploaded to experimental if possible, For the record, this was not possible, because it appears ceph fails to build from source with the current boost. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
