On Thu, Sep 29, 2022, at 2:05 AM, Wookey wrote: > 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').
Ah nice! Once you actually get to it, feel free to contact me in private if you would like me to walk you through what I did last time, and what problems I had. > 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? Right, I think it's fairly safe to assume that the other three (i386, mipsel and armel) will be discontinued well before armhf, and early enough that they are not affected too badly by the y2038 overflow. There is a chance that there is a use case for having a minimal i386-y2038 target for the purpose of running proprietary 32-bit software (i.e. windows games using wine), but that can come later. >> 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. +1 > 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). I was not aware of Arch linux using a time64 build. The main ones 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. https://wiki.musl-libc.org/projects-using-musl.html lists a few other distros that I'm not familiar with. Arnd
