This is a multi-part MIME message sent by reportbug.


Source: avro-c
Version: 1.11.1-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-arm@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.000000000 +0000
+++ avro-c-1.11.1/debian/changelog 2024-01-30 04:28:32.000000000 +0000
@@ -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 <vorlon@debian.org> Tue, 30 Jan 2024 04:28:32 +0000
+
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/control 2022-12-21 22:39:31.000000000 +0000
+++ avro-c-1.11.1/debian/control 2024-01-30 04:28:32.000000000 +0000
@@ -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

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
edmonds@debian.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <avro.h> 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
edmonds@debian.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/ slangasek@ubuntu.com vorlon@debian.org

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmW5be4ACgkQVo0w8yGy Ez3ImQ//YVAPKQvRRAo7fX9DuZavuWbyc3bEtvgo5hZRz044uRumckl6em/lhrEf BQ68nXo/x9hB2Lm9oXiJ/KaIHMFld+GM5KkcaU1KDFRvhJol3RXyJsQ4SR6kf/SX zj9dt22HlZLlG83zv6kQuYejN7ChwYCYcQYzxwFCGJaAivkdN+HFK38sMQKARcGO NiNq2db/bQfpztni8c4D5uDvMjobdekH9AOej07kjJ5g+u4YfbJ3FeA7euX8ImXB 0m3RLTDw/cxkN5JUF7tUvHpJaSYHc5LBPlgtPntHNPoCO/OyyrCETJDqpH8sueEo B6GTmJfvHcrANzJEmHwlebpW6FIWB2rEGhTbw23af2uQ720cs3LviSI+p0gIYuvS re0WJH9IjS3ytGzNsVraxEHccfsXespctDn+R2KropmU+h/FIC4zmeVaqnSauimY rIsJKNUICfRr4Y3CMsmd+WGIPsqob4FmhLpKt35zUZnJsH7ZTFxutvHXpQNf4u/l xgkoDcbcjcSllnYPNUwNsCYLX7u08coHay+Qs+xFJTn+Ioj9IXK/snr1Vg+WqR/Q QiYxWuFLa23L1yDNKcEb

This is a multi-part message in MIME format...

Your message dated Mon, 5 Feb 2024 20:52:00 -0800
with message-id <ZcG68JsHmVgwGRl6@homer.dodds.net>
and subject line Re: Bug#1061928: avro-c: NMU diff for 64-bit time_t transition has caused the Debian Bug report #1061928,
regarding avro-c: NMU diff for 64-bit time_t transition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
1061928: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061928
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

Received: (at submit) by bugs.debian.org; 30 Jan 2024 04:28:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
(2021-04-09) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-111.1 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH,
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FOURLA,FROMDEVELOPER,
HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_NONE,SPF_NONE,
T_SCC_BODY_TEXT_LINE,USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST,
XMAILER_REPORTBUG autolearn=ham autolearn_force=no
version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 24; hammy, 150; neutral, 223; spammy,
0. spammytokens: hammytokens:0.000-+--sk:taint_o, 0.000-+--sk:TAINT_O,
0.000-+--trixie, 0.000-+--langasek, 0.000-+--Langasek
Return-path: <vorlon@homer.dodds.net>
Received: from becquer.dodds.net ([2001:470:e980::2]:51937)
by buxtehu