On Wed, Sep 28, 2022, at 4:09 AM, Dominique MARTINET wrote:
>
> Arnd did a superb recap in 2020, let me just link to it first in case anyone
> needs a reminder:
> https://lists.debian.org/debian-arm/2020/02/msg00024.html
(It was Steve who did the recap of the work that I had done)
> tl;dr: glibc 2.34 added a -D_TIME_BITS=64 toggle, but afaiu we need to
> rebuild (virtually) everything to use it as that breaks the ABI for
> anything using time_t
>
>
> As far as I'm aware, there haven't been any new public discussion since
> that 2020 thread -- has there been any new attempt I missed?
I am not aware of anyone trying to do another bootstrap after me.
>From what I can tell, the main thing that has changed is that there
is even less developer time that we can spend on armhf. With every
year that passes, more workloads are moving from 32-bit userspace
native 64 bit, so the number of people that is willing to help
out is going down, though that does not necessarily make it less
important to those that do care about 32 bit.
Another thing that has changed is that /other/ 32-bit distros are
getting dropped, notably Fedora 37 dropped 32-bit Armv7 support,
and Arch Linux dropped support for any platform without NEON
support. OpenWRT on the other hand just had their first release
that is using 64-bit time_t on all musl-based targets, though
not yet on i386+glibc.
> My naive opinion is that having a flag day and dealing with fallouts
> might ultimately be the fastest way forward, but as there won't be any
> safety check to detect incompatibility I don't think anyone will be
> looking forward to the weird errors that will ensure for e.g. locally
> compiled programs and whatsnot.
>
> So that might be the first thing to think about again?
> (... and I wish I had any idea there, but nothing practical to
> suggest...)
I would agree that the idea of doing a soft migration that
correctly tracks library dependencies and allows a safe dist-upgrade
across the rebuild is pretty much dead because of the burden this
would put on package maintainers, so it will have to be fresh
time64 bootstrap.
Last time, the discussion got stuck because that means introducing
a new target name for dpkg, which then requires a new target triplet
to allow a multiarch installation. This in turn requires additional
work for porting packages that need to know about the new target
triplet. I don't think we can solve this problem now, but should
postpone the inevitable debate about this until someone has done
the work of rebootstrapping a working armhf environment with the
current names.
I don't expect that I'll have time to do this myself, but I'm
happy to help someone else figure out how to get to that point.
Arnd
