[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline



Hi!

[ It seems the original post didn't get through to debian-devel (yet?),
  I found it on debian-release though
  https://lists.debian.org/debian-release/2024/01/msg00033.html,
  you might want to repost it here though, so that it can be commented
  on properly? :) ]

On Fri, 2024-01-05 at 00:23:00 -0800, Steve Langasek wrote:
> On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote:
> > == Results ==
> > 
> > The overall findings of this analysis are 1,745 "dev" packages which either
> > are confirmed to have ABI changes or could not be checked; mapping to 2,154
> > runtime libraries (list attached) from 1,195 source packages (list attached)
> > and 5,477 reverse-dependencies requiring no-change rebuilds (list attached).
> > This is within the previously calculated range of "5300 to 5600", but there
> > are a number of newly-identified packages that fail to compile and have a
> > large number of reverse-dependencies.  I will continue to work to identify
> > false-positives here in the hopes of bringing this count down before pulling
> > the trigger on an actual transition.

> Guillem Jover <guillem@debian.org>
>    libaio
>    libmd
>    liburing

I checked these, and it looks like libmd and liburing are
false-positives?

 * libmd uses AC_SYS_LARGEFILE, and on 32-bit arches it is already built
   with LFS, the problem is that the header exposes off_t which means
   the code linking against it needs to match its build flags,
   otherwise they would already be broken now. You might want to look
   into this as a potential pattern for other false-positives probably.
   (I should probably update upstream the .pc file to include the
   -D_FILE_OFFSET_BITS=64 flags if enabled, but I don't think the
   analysis used .pc files anyway.)

 * liburing is marked as LFS-sensitive, but that comes from inline
   functions using off_t which end up casting that into an u32 type,
   so I don't think this should affect the ABI. It is also forcibly
   built with -D_FILE_OFFSET_BITS=64 in the upstream build system
   (and with future=+lfs for good measure in the packaging, which
   I'll switch to abi=+lfs).

Thanks,
Guillem


Reply to: