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
