Hi,

Thanks a lot ! I'll try your patch on a Debian's 32bit machine

Best regards,
Xavier

On 1/24/24 03:44, ellie timoney wrote:
Hi Xavier,

On Tue, 23 Jan 2024, at 3:19 PM, Yadd wrote:
Hi Ellie,

here is a new issue on Cyrus-Imapd, could you help me here ?

Best regards,
Xavier

-------- Forwarded Message --------
Subject: Bug#1061341: cyrus-common: identified for time_t transition but
no ABI in shlibs
Resent-Date: Mon, 22 Jan 2024 20:45:02 +0000
Resent-From: Steve Langasek <vor...@debian.org>
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Debian Cyrus Team <team+cy...@tracker.debian.org>
Date: Mon, 22 Jan 2024 12:43:17 -0800
From: Steve Langasek <vor...@debian.org>
Reply-To: Steve Langasek <vor...@debian.org>, 1061...@bugs.debian.org
To: sub...@bugs.debian.org

Package: cyrus-common
Version: 3.8.1-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
cyrus-common as an affected package, on the basis that the headers could not
be compiled and analyzed out of the box using abi-compliance-checker[2], so
we have to assume it's affected.

It would be good to get Cyrus into a state where the abi-compliance-checker can 
actually check it, because I don't know enough about this issue to check it 
manually, and I don't have access to any 32bit systems to even run our tests on 
them.

I've made a draft PR with some patches that should fix the header problem that 
was reported by the abi-compliance-checker.  Are you able to arrange for it to 
be re-run with these patches in place?  
https://github.com/cyrusimap/cyrus-imapd/pull/4798.

I expect there will probably be more errors once the first one is fixed, but 
we've gotta start somewhere.  Please send me the log with any further errors, 
and we'll see what needs fixing next.


However, cyrus-commons's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libcyrus 0 cyrus-common (>= 3.8.1)
libcyrus_imap 0 cyrus-common (>= 3.8.1)
libcyrus_min 0 cyrus-common (>= 3.8.1)
libcyrus_sieve 0 cyrus-common (>= 3.8.1)
$

It is therefore not obvious that we should rename the package to
'cyrus-common-t64' as part of this transition.

Looking at the archive, there are packages that depend on these libraries,
cyrus-admin and cyrus-clients.  Despite being built from the same source
package, they do not have a strict versioned dependency on cyrus-common but
instead use the shlibs.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading cyrus-common without also
upgrading cyrus-{admin,clients}) will result in ABI skew and may result in
broken behavior.

Thanks,
--
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

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2]
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt

Cheers,

ellie

------------------------------------------
Cyrus: Devel
Permalink: 
https://cyrus.topicbox.com/groups/devel/T7b15dfc105949d4e-M8a2ac6ce22f5b40156323c17
Delivery options: https://cyrus.topicbox.com/groups/devel/subscription

Reply via email to