Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
On Tue, Jan 30, 2024 at 04:27:49PM -0500, Robert Edmonds wrote: > I guess you have to do it that way since there isn't really anything > universal and machine readable that says: this is the public API header > file to include to use this library. Exactly. Though there are good practices (I hesitate to say "best") that would make headers no-ops if included directly when they shouldn't be, etc. > > This shows there are headers that can't be compiled because they're > > Windows-specific. So it seems counterproductive to ship these at all in > > Debian? > > If this header were removed from the package, or if a quirk were added to > > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads > > to exclude the incorrect headers from the analysis, we could confirm that > > avro-c is unaffected and avoid unnecessary NMUs / transitions to unstable. > If there is a way to quirk the avro-c package for this analysis so you > only include /usr/include/avro.h rather than every header file shipped > in the -dev package I think it would let your analysis succeed, without > missing anything, and, I would guess that that analysis would show no > ABI changes and thus no ABI transition is necessary. > I'm also open to just dropping those ms*.h files from the -dev package > which should just work without any other changes without breaking > anything else, but I haven't tested it. It looks like my colleague has already re-tested (with a local change, not yet published to either of https://salsa.debian.org/vorlon/armhf-time_t/ or https://salsa.debian.org/adrien-n/armhf-time_t/) and confirmed that avro-c's ABI is unaffected. (It's important to confirm with a full compile test because there are a number of types besides bare time_t that could be affected and overlooked with a bare grep or so.) We will make sure that this gets fully integrated into the published test results and that avro-c does not get NMUed to unstable for this. In the meantime I suggest leaving this bug report open for tracking. 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#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > Hi Robert, > > On Tue, Jan 30, 2024 at 02:05:11PM -0500, Robert Edmonds wrote: > > Steve Langasek wrote: > > > 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 > > > avro-c 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). > > > Hi, Steve: > > > I'm not aware of anything in avro-c that embeds time_t, or really any > > platform-provided structs, into the API/ABI. Can you point me to the > > actual changes in the avro-c ABI due to this change? > > > Thanks! > > avro-c falls into the second of these categories, "or could not be analyzed > and therefore we assume is affected". > > Output of the attempt to analyze the package with abi-compliance-checker: > https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/libavro-dev/base/log.txt Ah, I see, so basically every header in the -dev package is getting included: // add includes #include "/usr/include/avro/allocation.h" #include "/usr/include/avro/basics.h" #include "/usr/include/avro/consumer.h" #include "/usr/include/avro/data.h" #include "/usr/include/avro/errors.h" #include "/usr/include/avro/generic.h" #include "/usr/include/avro/io.h" #include "/usr/include/avro/legacy.h" #include "/usr/include/avro/msinttypes.h" #include "/usr/include/avro/msstdint.h" #include "/usr/include/avro/platform.h" #include "/usr/include/avro/refcount.h" #include "/usr/include/avro/resolver.h" #include "/usr/include/avro/schema.h" #include "/usr/include/avro/value.h" #include "/usr/include/avro.h" I guess you have to do it that way since there isn't really anything universal and machine readable that says: this is the public API header file to include to use this library. For avro-c in particular the documentation of the library is here: https://avro.apache.org/docs/1.11.1/api/c/ And they only mention including to users of the library. So those headers that work around problems on Microsoft platforms don't end up getting included on other systems since the #include's of those headers are conditionalized. > This shows there are headers that can't be compiled because they're > Windows-specific. So it seems counterproductive to ship these at all in > Debian? > > If this header were removed from the package, or if a quirk were added to > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads > to exclude the incorrect headers from the analysis, we could confirm that > avro-c is unaffected and avoid unnecessary NMUs / transitions to unstable. If there is a way to quirk the avro-c package for this analysis so you only include /usr/include/avro.h rather than every header file shipped in the -dev package I think it would let your analysis succeed, without missing anything, and, I would guess that that analysis would show no ABI changes and thus no ABI transition is necessary. I'm also open to just dropping those ms*.h files from the -dev package which should just work without any other changes without breaking anything else, but I haven't tested it. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Hi Robert, On Tue, Jan 30, 2024 at 02:05:11PM -0500, Robert Edmonds wrote: > Steve Langasek wrote: > > 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 > > avro-c 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). > Hi, Steve: > I'm not aware of anything in avro-c that embeds time_t, or really any > platform-provided structs, into the API/ABI. Can you point me to the > actual changes in the avro-c ABI due to this change? > Thanks! avro-c falls into the second of these categories, "or could not be analyzed and therefore we assume is affected". Output of the attempt to analyze the package with abi-compliance-checker: https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/libavro-dev/base/log.txt This shows there are headers that can't be compiled because they're Windows-specific. So it seems counterproductive to ship these at all in Debian? If this header were removed from the package, or if a quirk were added to https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads to exclude the incorrect headers from the analysis, we could confirm that avro-c is unaffected and avoid unnecessary NMUs / transitions to unstable. 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#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > 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 > avro-c 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). Hi, Steve: I'm not aware of anything in avro-c that embeds time_t, or really any platform-provided structs, into the API/ABI. Can you point me to the actual changes in the avro-c ABI due to this change? Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Source: avro-c
Version: 1.11.1-1
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
avro-c 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 avro-c
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)
diff -Nru avro-c-1.11.1/debian/changelog avro-c-1.11.1/debian/changelog
--- avro-c-1.11.1/debian/changelog 2022-12-21 22:39:31.0 +
+++ avro-c-1.11.1/debian/changelog 2024-01-30 04:28:32.0 +
@@ -1,3 +1,10 @@
+avro-c (1.11.1-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek Tue, 30 Jan 2024 04:28:32 +
+
avro-c (1.11.1-1) unstable; urgency=medium
* New upstream version 1.11.1
diff -Nru avro-c-1.11.1/debian/control avro-c-1.11.1/debian/control
--- avro-c-1.11.1/debian/control2022-12-21 22:39:31.0 +
+++ avro-c-1.11.1/debian/control2024-01-30 04:28:32.0 +
@@ -36,7 +36,10 @@
.
This package contains the development files.
-Package: libavro23
+Package: libavro23t64
+Provides: ${t64:Provides}
+Replaces: libavro23
+Breaks: libavro23 (<< ${source:Version})
Section: libs
Architecture: any
Multi-Arch: same
diff -Nru avro-c-1.11.1/debian/libavro23.install
avro-c-1.11.1/debian/libavro23.install
--- avro-c-1.11.1/debian/libavro23.install 2022-12-21 22:39:31.0
+
+++ avro-c-1.11.1/debian/libavro23.install 1970-01-01 00:00:00.0
+
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru avro-c-1.11.1/debian/libavro23.shlibs
avro-c-1.11.1/debian/libavro23.shlibs
--- avro-c-1.11.1/debian/libavro23.shlibs 2022-12-21 22:39:31.0
+
+++ avro-c-1.11.1/debian/libavro23.shlibs 1970-01-01 00:00:00.0
+
@@ -1 +0,0 @@
-libavro 23 libavro23
diff -Nru avro-c-1.11.1/debian/libavro23t64.install
avro-c-1.11.1/debian/libavro23t64.install
--- avro-c-1.11.1/debian/libavro23t64.install 1970-01-01 00:00:00.0
+
+++ avro-c-1.11.1/debian/libavro23t64.install 2022-12-21 22:39:31.0
+
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru avro-c-1.11.1/debian/libavro23t64.lintian-overrides
avro-c-1.11.1/debian/libavro23t64.lintian-overrides
--- avro-c-1.11.1/debian/libavro23t64.lintian-overrides 1970-01-01
00:00:00.0 +
+++ avro-c-1.11.1/debian/libavro23t64.lintian-overrides 2024-01-30
04:28:32.0 +
@@ -0,0 +1 @@
+libavro23t64: package-name-doesnt-match-sonames libavro23
diff -Nru avro-c-1.11.1/debian/libavro23t64.shlibs
avro-c-1.11.1/debian/libavro23t64.shlibs
--- avro-c-1.11.1/debian/libavro23t64.shlibs1970-01-01 00:00:00.0
+
+++ avro-c-1.11.1/debian/libavro23t64.shlibs2024-01-30 04:28:32.0
+
@@ -0,0 +1 @@
+libavro 23 libavro23t64
