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-Meae606200efd965cc932318f Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
