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

Re: [Y2038] debian/armhf time64 build?

On 2022-09-28 11:09 +0900, Dominique MARTINET wrote:
> As far as I'm aware, there haven't been any new public discussion since
> that 2020 thread

I mentioned it in the 'arm status' talk at debconf this year.

-- has there been any new attempt I missed?

I have been planning for a while to have a go at a bootstrap but have
not actually done anything yet. It is rising up my list as 'most
important task' (currently after 'fixing porterbox abel').

> I won't bring anything very useful to the table here: I'd be happy to
> give some limited time,

I'm glad to hear that there is some interest from others.

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

We don't have a mechanism for a flag day SFAIK. We can't suddenly
re-upload every package in the armhf archive. And people would still
download new 64bit time_t packages into their existing armhf
installations and (presumably) have everything break. It's a new ABI -
we have to assume the breakage would be pretty bad.

It would be nice to do it within the armhf archive but although we
have mechanisms for core library transitions (like we did for libc5 to
6) a) this affects all arches so is a lot of churn for an issue only
affecting one arch (or maybe all 32-bit arches, but I'm not sure how
many of those other than arm (v7) will be around much longer?

Given the nature of this change I'm not even sure this would work if
we were up for the work, and I don't think we collectively are.

> So that might be the first thing to think about again?

A new debian arm ABI arch is definitely the easiest way to do this, as
Arndt says.  Having thought about it a bit, I suggest we just call
it 'arm32' as in the future it will be useful to distinguish legacy
32-bit arm from arm64 (and maybe armv9 or whatever variants come in the
future).  And having just 'arm32' and 'arm64' arches will be quite
pleasing for however long it lasts.

Obviously bikeshedding about the name and triplet is the least important part of this.

Andt Bergman 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.

Agreed. And this was my plan. Just so we can check that stuff
basically works before patching toolchain builds. Given that arch have
it working it should be (?) as simple as setting some flags and
doing a rebuild (and fixing whatever breaks).

Principal hats:  Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: