Re: [Y2038] debian/armhf time64 build?
On Sun, Oct 02, 2022 at 04:23:35PM +0200, Arnd Bergmann wrote:
> On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> > On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
> >> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
> >>...
> >> > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
> >> > use musl-1.2, not glibc, and they have a much smaller set of packages.
> >>
> >> OK. We still have plenty of bugs to find then :-)
> >
> > Such bugs have already been found, reported and fixed in Debian for
> > 10 years thanks to the x32 port (e.g. #700012).
> >
> > More than 13k packages are currently Installed on x32 after having been
> > natively built and (if they have) passing their build time tests.
>
> There is a minimal user base on x32, so I'm sure a lot of bugs
> have gone unnoticed. Having 64-bit time_t on BSD and Windows
> probably did more to find bugs, but there are still lots of
> issues where neither of this would help. For instance:
>...
I am not denying that there will be bugs to be sorted out,
but with x32 (and likely soon arc) in ports many of the issues
have already been sorted out and there are also build logs that
could be searched for time_t gcc warnings in successful builds.
> - Things that are written in a language other than C/C++
> but don't link to C libraries should keep working,
Being written in C and linking to C libraries is not sufficient, we have
several other C libraries.
E.g. dietlibc:
https://sources.debian.org/src/dietlibc/0.34~cvs20160606-14/include/sys/types.h/#L106-L110
> but
> will not be y2038 safe unless they also migrate to the
> time64 interfaces by copying what glibc did.
>...
Yes, code breaking on 19 January 2038 on the fixed architectures should
be a big worry.
The other breakages you describe are things that would break immediately.
Most would be found during the years before the new port would be part
of a Debian release, and users would encounter remaining ones when
switching to the new architecture at a time that is convenient for them
(ideally first in a test environment).
Running test builds (as reproducible builds is already doing) and
autopkgtests with time set in the future might catch bugs that are
covered by tests, but would still miss many.
On Wed, Sep 28, 2022 at 08:21:00AM +0200, Arnd Bergmann wrote:
>...
> 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.
>...
IMHO there is little point in spending work anywhere on this unless
there is a commitment and schedule for the whole big amount of work
of setting up the new port.
The port would need all of:
- finding bugs
- fixing bugs
- adding the new architecture to debian/ in ~ 1k packages
And all this with a schedule to have it in a releasable state by the end
of 2024 or 2026 if it would start today.
Without such a schedule, other distributions will be faster then Debian
at switching to 64bit time_t, already resolving many of the issues you
are planning to find with the rebootstrap.
Having the new port in a releasable state in 2032, with a Debian release
with both old and new port in mid-2033, might be the last possible
schedule for Debian.
cu
Adrian
Reply to: