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