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

Re: 64-bit time_t transition in progress



On Sat, Feb 03, 2024 at 10:16:48AM +0100, julien.puydt@gmail.com wrote:
> Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit :
> > The packages previously not reported are:

> >    flint
> >    flint-arb

> About flint: if you need anything done, don't hesitate to ask me.

> About flint-arb: its code has been merged into flint, so it's abandoned
> upstream. The package is in FTBFS... only the sagemath package prevents
> its removal. Don't get blocked by this mess, you already have enough on
> your plate.

Thanks.  These were added because flint 2.9.0-5 which was the current
version in December successfully analyzed and showed no ABI breakage, but
flint 3.01-2 which is now current can't be analyzed due to compilation
errors.

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libflint-dev/base/log.txt

So *maybe* a quirk could be added for a-c-c to let the headers be analyzed
and show that no change is needed.  Or maybe the analysis would show that
the new version has introduced new entry points that do depend on time_t
size.  I can't tell from here.

I'm not bothered either way, but by default we're going to wind up picking
this up in the mass NMUs and libflint18 will change to libflint18t64, which
will have no effect either way on users upgrading from stable releases since
this is a new soname since bookworm.

-- 
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

Attachment: signature.asc
Description: PGP signature


Reply to: