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
