Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
I closed this issue because: - I dropped all bad .h files from install - I added ABI flags to build - cyrus-dev has no reverse dependencies If I'm wrong, please reopen this issue Cheers, Yadd
Bug#1061341: Fwd: Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
On 2/7/24 06:31, ellie timoney wrote:
Hi Xavier,
On Mon, 29 Jan 2024, at 9:59 AM, ellie timoney wrote:
On Thu, 25 Jan 2024, at 3:53 PM, Yadd wrote:
yes there are other errors because some .h require unavailable .h like
config.h
Ooh interesting, I'll have a look
I'm still working on this, but the more I work on it, the more of it turns out
to need fixing...
I think for now, it makes sense for you to proceed with the packaging changes
assuming that 32 bit Cyrus will _not_ be ABI compatible when recompiled with 64
bit time_t. From the original email, I think that means you'll need to set up
strict version dependencies between the cyrus-common, cyrus-admin and
cyrus-clients packages, so that people can't partially upgrade and wind up with
conflicts.
Cheers,
ellie
Hi,
dependencies are already strict (= ${binary:Version}).
To be able to render cyrus-dev headers compatible with ABI test, I'll
have to remove the following (missing config.h,...):
/usr/include/cyrus/bufarray.h
/usr/include/cyrus/charset.h
/usr/include/cyrus/command.h
/usr/include/cyrus/crc32.h
/usr/include/cyrus/cyr_qsort_r.h
/usr/include/cyrus/glob.h
/usr/include/cyrus/imapurl.h
/usr/include/cyrus/mappedfile.h
/usr/include/cyrus/procinfo.h
/usr/include/cyrus/rfc822tok.h
/usr/include/cyrus/sieve/sieve_err.h
/usr/include/cyrus/sieve/sieve_interface.h
/usr/include/cyrus/sqldb.h
/usr/include/cyrus/tok.h
/usr/include/cyrus/vparse.h
/usr/include/cyrus/wildmat.h
Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
On 1/28/24 20:21, Steve Langasek wrote:
On Tue, Jan 23, 2024 at 08:32:18AM +0400, Yadd wrote:
Control: tags -1 + moreinfo
On 1/23/24 00:43, Steve Langasek wrote:
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.
However, cyrus-commons's shlibs file declares a dependency on a library
package name that contains no ABI information:
according to
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt
, this issue looks like a false-positive: test failed because of C error,
not bad report
Am I right here ?
We do not *know* that it's a false positive; we only know that we were
unable to analyze the header files under a-c-c to prove that the ABI is not
affected.
Patches to the check-armhf-time_t script at
https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads
to quirk this package and allow its headers to be analyzed, or changes to
the source package to not ship uncompilable headers ("apt-file search
lib/strarray.h" returns no results), would both be welcome.
Thanks,
Hi,
is it possible to build a salsa-ci job to test this on i386 ?
Best regards,
Yadd
Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
On Tue, Jan 23, 2024 at 08:32:18AM +0400, Yadd wrote:
> Control: tags -1 + moreinfo
> On 1/23/24 00:43, Steve Langasek wrote:
> > 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.
> > However, cyrus-commons's shlibs file declares a dependency on a library
> > package name that contains no ABI information:
> according to
> https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt
> , this issue looks like a false-positive: test failed because of C error,
> not bad report
> Am I right here ?
We do not *know* that it's a false positive; we only know that we were
unable to analyze the header files under a-c-c to prove that the ABI is not
affected.
Patches to the check-armhf-time_t script at
https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads
to quirk this package and allow its headers to be analyzed, or changes to
the source package to not ship uncompilable headers ("apt-file search
lib/strarray.h" returns no results), would both be welcome.
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
signature.asc
Description: PGP signature
Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
Control: tags -1 + moreinfo On 1/23/24 00:43, Steve Langasek wrote: 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. However, cyrus-commons's shlibs file declares a dependency on a library package name that contains no ABI information: Hi, according to https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt , this issue looks like a false-positive: test failed because of C error, not bad report Am I right here ? Best regards, Xavier
Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs
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.
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
signature.asc
Description: PGP signature
