Re: 64-bit time_t transition for 32-bit archs: a proposal

[Thorsten Glaser]

Simon McVittie dixit:

>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly

Right, but e.g.  refuses to work under it.

>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic linker doesn't guarantee not to look at libraries from other
>architectures' multiarch library directories, or even know which directory
>is for which architecture. There's only one /etc/ld.so.conf(.d), which

Oh okay.

>I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
>armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe

Indeed.

>32-bit mips also has more than one ABI ("o32" and "n32") which might be

n32 is 64-bit, but from a short research, let’s not look at how
MIPS did this because it’s apparently convoluted and “historical
reasons” enough to make people despair (and apparently one can
compile an o32 file for MIPS64…).

But, yes, e_flags seems to be the way to go.

>(Of course, orthogonally, it would be nice if we could finally stop
>shipping shared libraries in the non-multiarch directories before trixie.)

Wouldn’t help here, considering that the old i386 has to be there
for legacy reasons so people might manually throw in, oh idk, an
OpenSSL 0.x and libstdc++5 even. But, yeah, M-A is nice now that
it works.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Thu, 06 Jul 2023 at 16:33:22 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
> >architecture would need to have a new dpkg architecture name, multiarch
> >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.
> 
> Bit of bikeshedding on the name, of course. timet64 (or a shortened
> version) is a possibility but I’d also want off_t to be 64 bit in it
> like the BSDs have been doing for decades, for example.

That's easy, because glibc doesn't support 64-bit time_t without also
having 64-bit off_t (to avoid combinatorial explosion), so there are
three possible 32-bit ABIs instead of the four that you might expect:

1. 32-bit everything
2. large file support (64-bit off_t and inode numbers) but 32-bit time_t
3. large file support as above, and also 64-bit time_t

The current (backwards-compatible) i386 port is (1.) by default. An
opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
of libraries that can support it without breaking ABI, and similarly
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 is an opt-in to (3.).
Specifying -D_TIME_BITS=64 on its own is an error, to avoid creating
a fourth mutually incompatible ABI.

Newer 32-bit ports like x32 started as (2.) or maybe even (3.) by
default.

Your proposed port would be (3.) from the beginning.

On the backwards-compatible i386 port, a lot of libraries already opt-in
to (2.), because it's relatively rare to have off_t or struct stat in
the ABI, therefore a lot of libraries can safely do this without breaking
their own ABI (for example libdbus, GLib and SDL all do this).

*Some* libraries can safely opt-in to (3.) as well (for example I proposed
a merge request for libdbus, and it looks as though SDL is also going
to do this, at least in version 3), but time_t in the ABI seems to be a
lot more common than struct stat in the ABI, so not all libraries can
safely do this (for example, GLib can't do this because unfortunately
it has some time_t in its ABI), hence the need to consider doing this
as a more general transition.

> I would like for things to be coïnstallable, of course. But why would
> the dynamic linker attempt to load the respective foreign libraries…
> oh right, not all are in the M-A path yet

That wasn't actually the reason for my concern. As far as I'm aware, the
glibc dynamic linker doesn't guarantee not to look at libraries from other
architectures' multiarch library directories, or even know which directory
is for which architecture. There's only one /etc/ld.so.conf(.d), which
all architectures share, and similarly there's only one ld.so.cache, so
the dynamic linker needs to be able to distinguish between co-installable
architectures and avoid loading "wrong" libraries.

You can see this by the error message you get if you try to load a
dlopen'd plugin for the wrong architecture, for example running an i386
Vulkan app if you only have amd64 Vulkan drivers: it's often something
like "wrong ELF type", as opposed to the "not found" that you might
expect.

I agree that this is less like amd64 vs x32 vs i386, and more like arm vs
armel vs armhf (all 32-bit ARM and all mutually incompatible). I believe
32-bit mips also has more than one ABI ("o32" and "n32") which might be
useful prior art for what you can and can't do in the ELF header.

(Of course, orthogonally, it would be nice if we could finally stop
shipping shared libraries in the non-multiarch directories before trixie.)

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> I concur. Given Simon's analysis and the replies even when
Helmut> combined with earlier messages, I now see significantly more
Helmut> voices for the opinion:

Helmut> i386 primarily exists for running legacy binaries and
Helmut> binary compatibility with legacy executables is more
Helmut> important than correct representation of time beyond 2038.

Helmut> I'm inclined to call this consensus now and therefore ask
Helmut> those that do not agree with it to reply here - even if your
Helmut> reply is only stating that you disagree. As such, I think we
Helmut> can skip the GR part unless we get (5?) disagreeing replies
Helmut> here.

I agree this represents consensus of the thread here.


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Thu, Jul 06, 2023 at 04:49:34PM +, Thorsten Glaser wrote:
> The Wanderer dixit:

> >> snes emulator. last upstream release 2007
> >>>  zsnes deb otherosfs optional arch=any-i386

> >FWIW: though I haven't touched it in quite some while, I recall from all 

> FWIW, I occasionally use zsnes and it works well.
> But yes, hand-written assembly was part of that IIRC.

=
[Date: Wed, 28 Jun 2023 15:25:56 -] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

 zsnes | 1.510+bz2-10.2 | source, i386
Closed bugs: 1039568

--- Reason ---
ROM; i386-only, abandoned upstream, alternatives exist
--
Also closing bug(s): 510238 544313 609524 610313 680073 727781 792420 1038482 
1039564
Also closing WNPP bug(s):
=


-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Thorsten Glaser]

The Wanderer dixit:

>> snes emulator. last upstream release 2007
>>>  zsnes deb otherosfs optional arch=any-i386
>
>FWIW: though I haven't touched it in quite some while, I recall from all 

FWIW, I occasionally use zsnes and it works well.
But yes, hand-written assembly was part of that IIRC.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Thorsten Glaser]

Simon McVittie dixit:

>On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
[…]
>> i.e we could keep the existing i386 for the gamers and have i386t64
>> (or whatever we call it) for ongoing use of i386 as a real OS.
>
>On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser wrote:
>> Ideally we’d keep the old i386 around for legacy binary-only libraries
>> and executables and add an i586 architecture with a differing dynamic
>> linker path
>
>These are essentially the same suggestion, and if there are enough

Right. However, my suggestion involves *reducing* the architecture
baseline again to make it accessible to more real-existing systems.
But that’s orthogonal from the rest. (In fact, we might even want
to do that for both.)

>Because legacy binaries already "know" that the backwards-compatible
>architecture is labelled i386 and i?86-linux-gnu with its dynamic linker

Oh, i?86-linux-gnu is a good point I had not considered.

>architecture would need to have a new dpkg architecture name, multiarch
>tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.

Definitely (and let’s just use the multiarch path for the ELF linker).

Bit of bikeshedding on the name, of course. timet64 (or a shortened
version) is a possibility but I’d also want off_t to be 64 bit in it
like the BSDs have been doing for decades, for example. Ideas welcome,
but it’s not important upfront.

>If the new architecture is fully co-installable and distinguishable via
>ELF flags (like the way amd64, i386 and x32 are), then the procedure to

It will unfortunately have to be more than just how these three differ.

i386 is ELF32 (ELFCLASS32) with e_machine EM_386 and ELFOSABI_LINUX
or possibly ELFOSABI_NONE(?).

amd64 is ELF64 (ELFCLASS64) with e_machine EM_X86_64.

x32 is ELF32 (ELFCLASS32) with e_machine EM_X86_64.

The new architecture would also have to be ELFCLASS32 and EM_386.
Maybe we can distinguish them using e_flags… using a new EI_OSABI
or, worse, e_machine sounds bad.

How do we distinguish arm, armel and armhf? They all use EM_ARM
probably (armeb is probably distinguished via ELFDATA2MSB).

>"crossgrade" core system packages to it. If it isn't distinguishable by
>ELF flags (so the dynamic linker would attempt to load i386t64 libraries
>into an i386 process or vice versa, and sometimes crash as a result)

I would like for things to be coïnstallable, of course. But why would
the dynamic linker attempt to load the respective foreign libraries…
oh right, not all are in the M-A path yet (on my box, they are, but
legacy i386 systems would not have that).

So we need a way to distinguish them in the ELF header and possibly
also patch the i386 loader to check the new bit? field? note? and
not load the solib if set.

We’ll also need a cpp define, like we have…

#if defined(__amd64__) && defined(__ILP32__)
// x32
#if defined(__amd64__) && !defined(__ILP32__)
// amd64

… and 「echo | gcc -m32 -E -dD - | less」 does not yet have anything
suitable. Either patch it into gcc… (I’ve patched gcc/config/**.h
files before) or… apparently, /usr/include/stdc-predef.h is included
by recent GCC, if that were in the M-A path it might work.

Is there any cross-distro effort for such a thing that we’d need to
coordinate with?

>(It's perhaps also worth noting that it's possible to upgrade from
>i386 to amd64 without a net increase in e-waste by switching from i386
>hardware to older amd64 hardware that has already been discarded by its
>original owner: I'm typing this into a second-hand ex-corporate Lenovo
>T480s, built in 2018 according to its serial number label, and the X220
>that was previously very popular with DDs was a UEFI-capable amd64 from
>around 2012.)

Right, that’s possible for part of the use cases, and not a bad
idea anyway.

(Radical idea: application and framework developers ought to still
test their things on low-spec machines, to get a feeling for just
how much bloat they introduce…)

bye,
//mirabilos
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
> On 2023-06-06 11:45 +0100, Simon McVittie wrote:
> > 1. i386 as a fully-featured architecture that you can run independently
> >on 32-bit x86 systems from roughly the 2000-2010 era
> > 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >modern x86_64 systems
>
> It is possible to have both these things, by treating this transtion
> as a new-ABI (i.e new architecture) transition, not a within-arch ABI 
> transition.
> 
> i.e we could keep the existing i386 for the gamers and have i386t64
> (or whatever we call it) for ongoing use of i386 as a real OS.

On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser wrote:
> Ideally we’d keep the old i386 around for legacy binary-only libraries
> and executables and add an i586 architecture with a differing dynamic
> linker path

These are essentially the same suggestion, and if there are enough
developers interested in the use-case that I labelled (1.) above, then
I agree that i386t64 (or i586t64 or ia32 or whatever its newly-formed
porting team wants to call it) would be the way to achieve that.

Because legacy binaries already "know" that the backwards-compatible
architecture is labelled i386 and i?86-linux-gnu with its dynamic linker
at /lib/ld-linux.so.2, and by definition legacy binaries don't have
the opportunity to to change their assumptions, I think the new time64
architecture would need to have a new dpkg architecture name, multiarch
tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.

If the new architecture is fully co-installable and distinguishable via
ELF flags (like the way amd64, i386 and x32 are), then the procedure to
switch to it could be similar to switching from i386 to amd64, or armhf to
arm64: either reinstall, or add it as a foreign architecture and gradually
"crossgrade" core system packages to it. If it isn't distinguishable by
ELF flags (so the dynamic linker would attempt to load i386t64 libraries
into an i386 process or vice versa, and sometimes crash as a result)
then a reinstall would be required.

I am personally only interested in i386 for the use-case that I labelled
(2.) above, but I don't want to prevent anyone else from working on (1.).

(It's perhaps also worth noting that it's possible to upgrade from
i386 to amd64 without a net increase in e-waste by switching from i386
hardware to older amd64 hardware that has already been discarded by its
original owner: I'm typing this into a second-hand ex-corporate Lenovo
T480s, built in 2018 according to its serial number label, and the X220
that was previously very popular with DDs was a UEFI-capable amd64 from
around 2012.)

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Wookey]

On 2023-06-06 11:45 +0100, Simon McVittie wrote:

I missed most of this conversation due to being on holiday, so just catching up 
now.

I hesitate to continue the i386-distraction thread because what's
actually important is getting this transition underway on the other
arches, particularly arm32 (hf/el). But at least one aspect seems to
have been missed in the discussion so I thought I should point this
out (and we can't easily move forward without a plan for i386 as dpkg
defaults affect all arches unless we make explicit excetions).

> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
> 
> 1. i386 as a fully-featured architecture that you can run independently
>on 32-bit x86 systems from roughly the 2000-2010 era
> 
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>modern x86_64 systems
>2a. legacy native Linux i386 binaries
>2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>complete i386 Linux library stack)

It is possible to have both these things, by treating this transtion
as a new-ABI (i.e new architecture) transition, not a within-arch ABI 
transition.

i.e we could keep the existing i386 for the gamers and have i386t64
(or whatever we call it) for ongoing use of i386 as a real OS.

This seems to me the 'right' way to deal with this 'the two possible
i386 ABIs are different but both useful in different ways'. 

That way we don't have to choose one or the other and everyone could be happy.

If we do that for other arches too then it greatly simplifies the
transition because we don't have to do a library transition at all. And
bootstrapping an arch is dramatically easier than it used to be thanks
to rebootstrap.

However there are major disadvantages too.

We'd end up quite a few new arches for at least one release, and we'd
spoil the upgrade path for people who would like their existing arch
to just move with the times. We'd have to think up and agree new
triplets and get them into toolchains, and fix architecture exceptions
in packaging.

There is no appetite for this (new triplet) work outside debian, but
if we do it right people will probably agree/follow (because it is
technically correct).

My assessment is that this is just as much work as doing the
transition in-arch, and will probably take longer due to the external
co-ordination needed.

Given all that I don't think the option of 'new arch for everyone' makes much 
sense.

Which gets us back to 'new arch for i386, other arches do in-arch
transition'. So we still get to do the library transition anyway.

But we _could_ also make a new i386t64 arch to enable i386-the-real-OS
a post 2038 future.  Does anyone care enough about that to do the
work?  If so I think we should let them.  This is the only i386
use-case I care about, but in practice I'm only going to care about it
for a few more years which will be served by the current releases so I
don't think I'm going to bother bootstrapping the new version. Happy
to help others though. 

Just thought this was worth bringing up because whilst the existing
'i386' arch has to choose one ABI or another, nothing stops us from
having both variants in the archive if we want them enough.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[James Addison]

On Mon, 26 Jun 2023 at 20:33, Aurelien Jarno  wrote:
>
> On 2023-06-09 16:39, Thorsten Glaser wrote:
> > In particular I would, at the same time, like the baseline lowered
> > to i586 again. It was raised mostly for multimedia stuff, and it’s
> > now justifyable to ask people to use amd64 or armhf or something for
> > that.
>
> This is plainly wrong. The current baseline of the i386 architecture
> does NOT include any multimedia extension, and certainly not MMX nor
> SSE.
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net

I agree with Aurelien on this.

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Aurelien Jarno]

On 2023-06-09 16:39, Thorsten Glaser wrote:
> In particular I would, at the same time, like the baseline lowered
> to i586 again. It was raised mostly for multimedia stuff, and it’s
> now justifyable to ask people to use amd64 or armhf or something for
> that.

This is plainly wrong. The current baseline of the i386 architecture
does NOT include any multimedia extension, and certainly not MMX nor
SSE.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Olaf Titz]

> > Oh, wait!  No, I'm wrong, CNFS actually does something smart and encodes
> > the header in ASCII when writing it to disk.
> >
> > Okay, phew, this isn't going to be nearly as bad as I had thought.
>
> Good news. It would be great if you could add relevant info to the wiki page:
> https://wiki.debian.org/ReleaseGoals/64bit-time#Known_Issues

That page now says
< The CNFS storage format does not have problems with its disk format,
< but the less-used timecaf storage format might (yet to be confirmed).

Yes, timecaf does have a problem, two actually.

1. The CF file header contains a field time_t LastCleaned. Changing
sizeof(time_t) will change sizeof(CAFHEADER) and make existing CF file
unreadable with newly compiled code.

AFAICT that field is only written once and never read, so it could be
patched out, but that requires some care.

2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
the storage class and aabbccxx the time of arrival, changing the file
name in 256-second intervals. The code using %02x format strings to
determine the file name, and everything else checking them for
validity, will have to be changed appropriately.

Olaf

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Guillem Jover]

On Tue, 2023-06-13 at 21:41:50 -0700, Steve Langasek wrote:
> After thinking about it, I'd like to suggest the following approach.
> 
> - dpkg with the new default behavior uploaded to experimental
> - libraries uploaded to experimental with the new package names (so, NEW
>   processing gets done) and with a versioned build-dependency (easy to
>   automate with sed on debian/control)
> - once all the libraries have cleared NEW, copy to unstable without dropping
>   the versioned build-dependency; it will never be wrong, it will always at
>   most be cruft that can be cleaned up lazily
> 
> What do you think?

Yeah, sounds good to me.

> On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:
> > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> > > > Hmm, rechecking the script, I think we'd want to at least
> > > > unconditionally add the Breaks and Replaces (no need for substvars
> > > > then), otherwise we'd get upgrade errors?
> 
> > > > That would leave only the Provides as potentially conditional…
> 
> > > You're absolutely right, thanks for catching this!  Fixed in git.
> 
> > As hinted above, I think the source:Version substvar should be
> > switched to a hardcoded version at the point the migration was done,
> > otherwise it will be floating forward and not catch older affected
> > versions?
> 
> Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
> what you mean by "not catch older affected versions" - why would it be wrong
> to Breaks/Replaces against non-existent, newer versions of an obsolete
> binary package name?

Err, sorry right, that paragraph didn't make much sense, I think I might
have lost context between the first time I checked this and the next. :)

> It's not a difficult change to make, I just don't understand why it's
> important.

Rereading my own comment, I think what I might have been thinking about
was that the version restrictions do not make much sense, and would not
protect against potential reintroduction of those obsolete package
(probably not in Debian but elsewhere). So probably not important in
the Debian context, but it would seem more correct and future-proof to
me to completely drop the version restrictions?

> > Just to try to understand whether we are on the same page. If these
> > libraries have no time_t usage at all, then disabling time64 should
> > then provoke no time_t issue and should stop implicitly enabling LFS.
> > But if the library contains internal time_t usage that is not part of
> > the exposed ABI, but part of its operation, then I'm not sure I see
> > how we can patch them to disable LFS w/o at the same time losing
> > time64 support (as the latter forces/requires the former).
> 
> > I'm not sure whether you are talking about the first or second case?
> > And whether we have no libraries at all falling under the second case?
> 
> I was only thinking about the first case, I had not previously considered
> the second case.  We should be able to determine fairly easily whether there
> are any in the second case; for all ELF binaries which are built from the
> same source package as an LFS-sensitive library, check whether they have
> references to any of the static list of symbols in glibc that are affected
> by time_t, and if they are, add them to the list of libraries to transition.
> 
> I'll add this to the analysis in progress.

Perfect, thanks!

Regards,
Guillem

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:

> On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:

> > The difference in my view is that the changes to handle Provides: are
> > something that should persist in the packaging (until the next soname
> > change, at which point it's easy to handle as part of the overall renaming),
> > whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
> > something that ideally would be dropped immediately after dpkg-buildflags is
> > updated, and could (though unlikely) be a source of bugs later.  I'd prefer
> > to avoid any transition plan which means I should be NMUing all of the
> > affected library packages twice.

> I think I understand where you are coming from, and I see how ideally
> these would be dropped soon, but I also don't see this as a pressing
> matter that would even need NMUs, as the explicit settings should map
> to the then current defaults. Of course that precludes those defaults
> then changing globally in the future, but if needed (!?) that could be
> handled later on. But again, I think the flag day can potentially be
> done in multiple other ways that might avoid the breakage w/o needing
> these changes, and if so I'm happy with that as well.

After thinking about it, I'd like to suggest the following approach.

- dpkg with the new default behavior uploaded to experimental
- libraries uploaded to experimental with the new package names (so, NEW
  processing gets done) and with a versioned build-dependency (easy to
  automate with sed on debian/control)
- once all the libraries have cleared NEW, copy to unstable without dropping
  the versioned build-dependency; it will never be wrong, it will always at
  most be cruft that can be cleaned up lazily

What do you think?

> > > Hmm, rechecking the script, I think we'd want to at least
> > > unconditionally add the Breaks and Replaces (no need for substvars
> > > then), otherwise we'd get upgrade errors?

> > > That would leave only the Provides as potentially conditional…

> > You're absolutely right, thanks for catching this!  Fixed in git.

> As hinted above, I think the source:Version substvar should be
> switched to a hardcoded version at the point the migration was done,
> otherwise it will be floating forward and not catch older affected
> versions?

Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
what you mean by "not catch older affected versions" - why would it be wrong
to Breaks/Replaces against non-existent, newer versions of an obsolete
binary package name?

It's not a difficult change to make, I just don't understand why it's
important.

> > > > And btw, given the analysis that there are likely < 100 shared libraries
> > > > overall whose ABI changes when enabling LFS, this might be a change we 
> > > > want
> > > > to consider in the trixie cycle as well - just preferably not bundled 
> > > > with
> > > > the time_t transition at the same time, as that would just cause more 
> > > > delays
> > > > for testing migration vs splitting the two transitions.

> > > If the plan is to go with a flag day by switching the default for
> > > time64, then I don't see how the LFS change can be decoupled, as that
> > > automatically will also forcibly enable LFS globally on glibc arches.
> > > I've also in general been worried about automatically enabling LFS w/o
> > > someone looking into each package, given the greater potential for
> > > data loss. :/

> > I think in the case of LFS-sensitive libraries that aren't part of the
> > dependency graph of packages affected by the time_t change, it's easy enough
> > to patch them to not turn on the LFS flag and avoid a transition.

> Just to try to understand whether we are on the same page. If these
> libraries have no time_t usage at all, then disabling time64 should
> then provoke no time_t issue and should stop implicitly enabling LFS.
> But if the library contains internal time_t usage that is not part of
> the exposed ABI, but part of its operation, then I'm not sure I see
> how we can patch them to disable LFS w/o at the same time losing
> time64 support (as the latter forces/requires the former).

> I'm not sure whether you are talking about the first or second case?
> And whether we have no libraries at all falling under the second case?

I was only thinking about the first case, I had not previously considered
the second case.  We should be able to determine fairly easily whether there
are any in the second case; for all ELF binaries which are built from the
same source package as an LFS-sensitive library, check whether they have
references to any of the static list of symbols in glibc that are affected
by time_t, and if they are, add them to the list of libraries to transition.

I'll add this to the analysis in progress.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the 

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Thorsten Glaser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Helmut Grohne dixit:

>I'm inclined to call this consensus now and therefore ask those that do
>not agree with it to reply here - even if your reply is only stating

I disagree.

I would like to see a long-term commitment against electronic waste
and to see support for i386 as a second-class but fully supported
platform, with 64-bit time_t and off_t, d-i, kernel and everything.

In particular I would, at the same time, like the baseline lowered
to i586 again. It was raised mostly for multimedia stuff, and it’s
now justifyable to ask people to use amd64 or armhf or something for
that.

Besides being a fully supported bootable platform for old but still
serviceable hardware the M-A support is also worthwhile. I run the
i386 version of firefox-esr on some systems to naturally limit its
resource usage, for example.

Ideally we’d keep the old i386 around for legacy binary-only libraries
and executables and add an i586 architecture with a differing dynamic
linker path; all solibs would be in the M-A-qualified path anyway. Maybe
we could even use one of the various existing ELF header fields to
distinguish them for the kernel, if needed.

I’m mildly willing to help out as part of a porter team, but not be the
only porter. I do have an affected system (EeePC, though I need to
do some hardware maintenance (HDD swap etc.) first) which I occasionally
use. That being said I’ve reduced my involvement in bookworm/sid due to
the systemdification, so I would prefer to not be the primarily respon‐
sible developer.

bye,
//mirabilos
- -- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８　☕☂☄

iQIcBAEBCQAGBQJkg1XOAAoJEHa1NLLpkAfgTvYP/ie/yyFeDYQTGJjKdjYoFThr
ckaL1VYC2C1pBQLFbcdeRG2Zy2VyQQzJQnFxfBey4PKJAvvY78VyI/1Kn4eGXWKE
7KNPB11tm5IZaQa/fIUpWDTruzkFydkuYAjT72qiHqkBphF32YbiNSLeQEf8pEfJ
bbk2Z1awKM5wm6dw0iXEn+IV2YDXzPt2Mb0HgLu08b2MjyFI6pou6UjLmriqeKd6
qpiTH1XzKGkOrRh00LRGEg4GuRpjboaxtaJoTykEj+42xxyy21yzrxigrpxc7fpl
7gkCfpBvf8XFORHsZuLA/ZoepKpII4BIP8qgwip3D8sy9kyJRlFpN87KGJhMiTMz
2cPtXHtwYkMMRjMcOJazaGXm3QgzOKF1cNBaQFer/N74X9P8k5ax4e9B6plrsDdX
eI62d8U2D9IUSHE3S+OWRIqXhb/2RJ+DcCca182344PyDKz+j0x3RLwXcAPTGTZS
Dxf7LSSZ4nOFUAW31ZNbeByjM40RXlzGbQu63Bps1Vwzy3N+xMNfj0fd3XEx+rDd
edDYXHe2gt5lQJuG6n6REs/DdoBD1724IOIAm0j4IF4UDPuhpILN9RSmvSECDDnP
+aPQ+P8YkKOP3NeVnE/Jd7pbqvt0vvYjXUhuXEMf2I2UT2KG1j0tonv/5G8W4ui0
+ZX+kIdFDYBmx2opmp/Z
=lfL0
-END PGP SIGNATURE-

Constructive contributions (was: Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Jonathan Carter]

Hi Everyone

It goes without saying that the Debian Code of Conduct applies to all 
Debian communication platforms (https://www.debian.org/code_of_conduct), 
but in addition to that, please try to go further when it comes to 
potentially long, and technical discussions that many will try to follow.


Remember some good netiquette principles:

 - Reply below the the parts you're responding to
 - Snip out any parts that is not pertinent to your reply
 - If there's no need to repeat yourself, then don't.
   Once you've made your position, there is no need to reply
   to every mail that doesn't match yours.
 - If your message doesn't contribute to the discussion,
   please consider not sending it at all.

It basically all boils down to the "Try to be concise" part in our code 
of conduct, but not everyone quite understands what that means.


Thank you to everyone who contributes to making Debian lists more 
productive, informative and enjoyable to use.


-Jonathan

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Ansgar]

On Fri, 2023-06-09 at 09:22 +, Holger Levsen wrote:
> On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > > You mean by somehow refreshing the signatures there?
> > Some ideas for that are here:
> > https://bugs.debian.org/763419
> > https://bugs.debian.org/820423
> 
> interesting. thanks for those pointers!

I did write a prototype once, but haven't touched it for some time. For
example:

https://defi.43-1.org/debian-defi-archive/debian/dists/stretch-backports/InRelease

(It should also work for other things.)

The test key is available from
https://defi.43-1.org/defibrillator-test-key.asc

Ansgar

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Fri, 09 Jun 2023 at 11:04:47 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> 
> Are these use-cases likely to work with future library ABIs, or
> do they need old library ABIs from when the binaries were compiled?

I'm not sure how this could be in question? They're legacy binaries,
so almost by definition, legacy ABIs.

> >    2a. legacy native Linux i386 binaries
> 
> It seems like modern Debian library ABIs will be bumped away from what
> the old i386 binaries were built against, so future Debian i386 won't
> be useful for this use-case anyway, except for very stable libraries,
> symbol versioned libraries or libraries with multiple ABIs. That sounds
> like glibc, X11 and SDL with compat libs. Anything else?

When you say "ABIs will be bumped", do you mean SONAME transitions like
libtiff.so.4 -> .5 -> .6?

Those don't have to prevent running legacy binaries if we don't want them
to, because the whole point of SONAMEs is that different versions of the
same library are co-installable: if you have a legacy binary linked to
libtiff4, you can still run it on a system that normally uses libtiff6
by keeping a copy of libtiff4 from an old Debian suite (I know it's in
Ubuntu 12.04, but I've lost track of how old you would need to go in
Debian-world to get it).

This will generally work fine as long as the legacy binary doesn't
also link to a higher-level library that depends on a modern version of
libtiff, like for example libsdl-image1.2 or libsdl2-image-2.0-0. Even if
the legacy binary *does* link to such a library, then it might still work,
if both the old and new versions of libtiff have ELF symbol versioning
(libtiff6 does, I think libtiff4 also did) and the higher-level library
doesn't expose libtiff objects through its own ABI (SDL_image doesn't).

If the legacy binary mostly calls into higher-level "middleware" libraries
like SDL_image, then it is quite likely that it doesn't actually directly
reference any symbols from a lower-level library like libtiff, and the
lower-level libraries tend to be the ones that break ABI most often.

>From my experience in dealing with the Steam Runtime, I can tell you that
surprisingly many of the libraries linked by legacy binaries still have
an ABI that is backwards-compatible with versions of the same library from
more than 10 years ago. For example, PulseAudio never bumped SONAME; GLib,
libdrm and fontconfig had some SONAME bumps in their early history but
are long-term-backwards-compatible now; and libjpeg bumped SONAME somewhat
recently, but Debian is using the maximally-backwards-compatible ABI.

I can't tell you a comprehensive list of libraries used by legacy binaries,
but if someone wants to audit all the "commonly used" libraries for whether
64-bit time_t breaks their ABIs, the Steam Runtime is probably quite a good
approximation of what is "commonly used":
https://repo.steampowered.com/steamrt-images-sniper/snapshots/latest-container-runtime-public-beta/com.valvesoftware.SteamRuntime.Platform-amd64%2Ci386-sniper.source-required.txt

I must admit that I stopped looking when I saw that libX11 and libasound
have time_t in their ABI, because those are both going to be extremely
common dependencies, and I am not optimistic about the prospects of
getting glibc-style parallel ABIs into libX11.

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Holger Levsen]

On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > You mean by somehow refreshing the signatures there?
> Some ideas for that are here:
> https://bugs.debian.org/763419
> https://bugs.debian.org/820423

interesting. thanks for those pointers!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

https://showyourstripes.info


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Bastian Blank]

On Fri, Jun 09, 2023 at 12:25:21PM +0800, Paul Wise wrote:
> Has anyone checked what percentage of these binaries will still run
> adequately after 2038 with 32-bit time_t?

All, because you don't need to provide those programs with a correct
time.  But this is all a positive decisions.

> Presumably any network components will be dead or require modern
> protocols by then, so this could only be offline programs?

What difference does this make?

Bastian

-- 
He's dead, Jim.
-- McCoy, "The Devil in the Dark", stardate 3196.1

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

Has anyone checked what percentage of these binaries will still run
adequately after 2038 with 32-bit time_t?

Presumably any network components will be dead or require modern
protocols by then, so this could only be offline programs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Thu, 2023-06-08 at 08:57 +, Holger Levsen wrote:

> You mean by somehow refreshing the signatures there?

Some ideas for that are here:

https://bugs.debian.org/763419
https://bugs.debian.org/820423

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems

Are these use-cases likely to work with future library ABIs, or
do they need old library ABIs from when the binaries were compiled?

>    2a. legacy native Linux i386 binaries

It seems like modern Debian library ABIs will be bumped away from what
the old i386 binaries were built against, so future Debian i386 won't
be useful for this use-case anyway, except for very stable libraries,
symbol versioned libraries or libraries with multiple ABIs. That sounds
like glibc, X11 and SDL with compat libs. Anything else?

>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

I guess Wine provides a translation layer between legacy 32-bit Windows
APIs/ABIs and modern Debian library ABIs, so this should still work?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[nick black]

Simon McVittie left as an exercise for the reader:
>   Debian-style multiarch or Fedora/Arch-style multilib is a much, much

this is at least the second time you've drawn this distinction
in this thread. for anyone else who, like me, was uneasy with
their understanding of the concept:

https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib

seems to be a solid resource (and sadly low on my google
returns).

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Wed, 07 Jun 2023 at 12:25:58 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > When considering the future of i386, a factor that we need to bear in
> > mind is that there are two major use-cases for i386, with requirements
> > that sometimes conflict:
> 
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
> 
> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.

Showing my $WORK bias a bit here by using the latest version of the
Steam Runtime (based on Debian 11) as an example of a "reasonably small"
library stack for running 32-bit binaries:

$ podman pull registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ podman run --rm -it registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ grep -rl '\' /usr/include

I see that libX11, ALSA, libstdc++, libcups, GLib, GNUTLS, GTK 3, libelf,
libpng, libsoup, libllvm, NSPR and OpenSSL all have time_t in their
APIs. In most cases that's going to reflect it being in their ABIs too.

In many cases it's probably a deprecated library call
(like g_bookmark_file_set_app_info(), which takes a time_t argument,
and is deprecated in favour of g_bookmark_file_set_application_info()
which takes a GDateTime object) but one of the things about legacy
binaries is that they'll continue to call into old ABIs, however hard
you might try to deprecate them.

Doing similar searches for timeval and timespec (which contain a time_t)
finds more relatively low-level libraries with time_t-sensitive ABIs.

glibc supports both time_t sizes by using heroic efforts to do so,
and conditionally redefining various symbols. I'm not at all sure that
that scales beyond glibc, particularly for libraries like libX11 that
are already on life-support; and if we switch to 64-bit time_t *before*
giving all of those libraries similar elaborate symbol-renaming, then
it'll be too late, because their ABI will have already changed and it
would be equally disruptive to go back.

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Tue, 06 Jun 2023 at 21:45:31 +0200, Alexis Murzeau wrote:
> On 06/06/2023 12:45, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> > complete i386 Linux library stack)
> > 
> 
> Windows already uses 64 bits time_t on i386 since Visual Studio 2005,
> unless _USE_32BIT_TIME_T is defined ([msvcrt-time]), and even if it is
> defined, Wine implementation of 32 bits time() will not use Linux' time_t.
> 
> So I'm not sure Windows i386 binaries will be affected by a Linux-side change 
> of
> time_t, unless you think about something else.

If the point you're making is this:

We have source code for the whole Wine stack, and the size of Linux time_t
used to compile/implement that stack does not affect the time_t used for
the Windows-side ABI presented to the binaries Wine runs, therefore we
could recompile all of i386 (including Wine) with a 64-bit time_t and
still be able to run 32-bit Windows binaries

then, yes, that's all true, if we assume the whole of the stack
"underneath" Wine copes gracefully with 64-bit time_t on an otherwise
ILP32 ABI (I think implementation experience from x32 might indicate
otherwise, but that'll need to be solved for a 64-bit-time_t transition
in other ILP32 architectures like armhf anyway).

However, I would argue that providing i386 as a multiarch foreign
architecture that can run 32-bit Windows binaries via Wine (2b), but can
no longer safely run 32-bit Linux binaries (2a) because they're relatively
likely to crash, is less useful than being able to have both 2a and 2b.

Do we expect users of old 32-bit Linux binary-only software to always
obtain and run the corresponding Windows software instead, via Wine,
assuming it's available? I know people like to complain about Linux not
having stable ABIs and/or troll us with comparisons to things that Windows
does better, but it would seem like a shame if the solution for (for
example) players of TF2 and Portal is "stop running the Linux version,
start running the Windows version via Wine/Proton".

> This means that Wine will probably require 32 bits Linux libraries for
> probably a long time and not only for legacy Windows binaries.

I was assuming that 32-bit Windows binaries can be considered to be
inherently legacy software at this point, even if people are still
releasing them today :-)

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Thu, Jun 08, 2023 at 05:57:49PM +, Holger Levsen wrote:
> RFC on d-d-a? That's at least less heavy than a GR and yet way more
> visible than just a thread on d-d.

The problem with doing an RFC on d-d-a is that it doesn't give us a clear,
timeboxed path to converging on a decision if we find that there isn't
consensus.  If we need more assurance that the project supports the
decision, I think it's better to go straight for a GR.

I wouldn't like this to drag on too long into the trixie release cycle.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Holger Levsen]

On Thu, Jun 08, 2023 at 07:14:17PM +0200, Helmut Grohne wrote:
> I concur. Given Simon's analysis and the replies even when combined with
> earlier messages, I now see significantly more voices for the opinion:
> 
> i386 primarily exists for running legacy binaries and binary
> compatibility with legacy executables is more important than correct
> representation of time beyond 2038.

I agree. (And personally I don't care about i386 at all. I'm happy if
we support i386 usecases if this seems reasonable for all involved.)
 
> I'm inclined to call this consensus now [...]

I'm inclined to call this consensus of the few people who participated
(activly or passivly) in this short & short-lived thread, but I'm not
sure we can call this project wide consensus *yet*.

RFC on d-d-a? That's at least less heavy than a GR and yet way more
visible than just a thread on d-d.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just because other people are also responsible, does not mean you are not
responsible.


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Helmut Grohne]

Hi Steve,

On Tue, Jun 06, 2023 at 12:45:42PM -0700, Steve Langasek wrote:
> I have a different read on the consensus here.  While there has been a lot
> of discussion about whether to continue supporting i386 as a host arch,
> almost everyone participating in the thread who said they want this is not a
> voting member of Debian.  The lone exception that I can recall from the
> thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in
> this decision (and since we don't really have an "i386 porting team",
> probably the most important individual stakeholder).

I concur. Given Simon's analysis and the replies even when combined with
earlier messages, I now see significantly more voices for the opinion:

i386 primarily exists for running legacy binaries and binary
compatibility with legacy executables is more important than correct
representation of time beyond 2038.

I'm inclined to call this consensus now and therefore ask those that do
not agree with it to reply here - even if your reply is only stating
that you disagree. As such, I think we can skip the GR part unless we
get (5?) disagreeing replies here.

Guillem, I understand that you see things differently, but that now
seems like a minority opinion to me. Are you ok with moving forward with
the proposed consensus-or-GR process? My understanding is that you
disagree with the opinion stated above, correct?

While Gunar also raises the question of whether i386 should continue as
a full or partial architecture, I do not think this is influences the
time_t bits decision. The default for now is keeping it as a full
architecture and the time_t migration does not benefit from changing
this. Therefore, I propose restricting the potential GR to the binary
way that Simon presented.

> Since my read is that Guillem was in the "rough" of "rough consensus", I
> asked him directly how we should move forward on a decision.  A GR is one
> option, and I think it's definitely a better option than going through the
> TC: while there is a decision to be made here about a "technical" detail of
> what dpkg-buildflags will do, you're right to point out that it's really a
> decision about what we want to support as a project.

Yes, dragging this question on is - as usual - the worst of options.

> Hmm, I don't share this particular concern.  PIE is a change to compiler
> behavior.  32-bit time_t is a change to defines that modify types (and
> prototypes) used in header files.  Maintaining a compiler is hard,
> maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25
> years so far.

The similarity is that both is changing flags. I expect that some
packages will need special handling for time64 and some of them may fail
to handle i386 correctly when they only match on bits. If we can get
maintainers to match on the resulting dpkg-buildflags rather than bits,
that's a non-issue probably.

> I am not keen to try to drive a GR on this, but if you raised one I'm likely
> to second it.

Cool. From my point of view consensus is better than GR is better than
deferring or invoking the CTTE. Hope consensus works out. :)

Helmut

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Gunnar Wolf]

Simon McVittie dijo [Thu, Jun 08, 2023 at 10:33:45AM +0100]:
> - For game-related use cases in particular, 2030 GPU models aren't going
>   to work with 2023 user-space graphics drivers (typically Mesa or
>   NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
>   the 2023 driver was written, so if we don't compile a modern Mesa
>   for i386, all i386 programs will eventually lose the ability to do
>   accelerated graphics and end up using the 2023 version of llvmpipe.

This makes the case for an ideal GPU paravirtualized implementation!

(yes, yes, I know it's not doable... Just had to say it!)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Thu, 08 Jun 2023 at 11:19:15 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> >    2a. legacy native Linux i386 binaries
> >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >    complete i386 Linux library stack)
> 
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

Not really, for two reasons. Suppose we had done as you suggest in trixie,
and then a user in 2030 tries to run legacy binaries.

- Multiarch co-installability requires a matching version, so you can't
  co-install libc6:amd64 from 2030 with libc6:i386 from 2023. That would
  mean requiring use of a pure i386 chroot/container to run i386 binaries,
  which doesn't really work well for something like Steam or Wine that
  wants to provide a mixed x86_64/i386 environment that can run x86_64
  or i386 binaries interchangeably. Steam has both x86_64 and i386 games
  available (most of which will never be recompiled or updated by their
  developers), and Wine wants to provide an environment compatible
  with modern Windows, which is essentially the same shape as amd64
  Debian in terms of architecture support: it's an x86_64 OS (kernel,
  services and core libraries) with a secondary i386 library stack
  ("WoW64" in Windows' case).

  Debian-style multiarch or Fedora/Arch-style multilib is a much, much
  more convenient way to handle legacy i386 binaries than a chroot or
  container - there's a reason that essentially all distros supporting
  x86_64 have one or the other of those.

  Even if you use a container framework like Flatpak to run Steam,
  it isn't an i386 container - in Debian terminology, it's an x86_64
  container with i386 as a foreign architecture (and in fact the fd.o
  Flatpak runtimes use Debian-style multiarch paths for this).

- For game-related use cases in particular, 2030 GPU models aren't going
  to work with 2023 user-space graphics drivers (typically Mesa or
  NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
  the 2023 driver was written, so if we don't compile a modern Mesa
  for i386, all i386 programs will eventually lose the ability to do
  accelerated graphics and end up using the 2023 version of llvmpipe.

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Bastian Blank]

On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >    modern x86_64 systems
> >    2a. legacy native Linux i386 binaries
> >    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >    complete i386 Linux library stack)
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

No.  One package for different architectures is only co-installable if
they have the same version.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Holger Levsen]

On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

You mean by somehow refreshing the signatures there?

Would IMO also be useful for other archs. :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Climate change" is an euphenism. "Global warming" as well.


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Hakan Bayındır]

> On 8 Jun 2023, at 06:19, Paul Wise  wrote:
> 
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 
>> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>>modern x86_64 systems
>>2a. legacy native Linux i386 binaries
>>2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>>complete i386 Linux library stack)
> 
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

Wouldn’t this make installation of i386 packages harder and harder as packages 
diverge from the dependencies stated in the historical packages? This will 
defeat the very purpose of having i386 as an installable compatibility layer in 
my opinion.

Cheers,

H.

> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Bastien ROUCARIES]

Le jeu. 8 juin 2023 à 05:31, Paul Wise  a écrit :
>
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >modern x86_64 systems
> >2a. legacy native Linux i386 binaries
> >2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> >complete i386 Linux library stack)
>
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?

In some countries wine (32 bits) is the only solution to run software
as a citizen needed for relation to some state administration...

Regards
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>    modern x86_64 systems
>    2a. legacy native Linux i386 binaries
>    2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>    complete i386 Linux library stack)

Would it be feasible to drop i386 but still support this use-case by
requiring folks to use historical releases on archive.debian.org?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Andreas Metzler]

On 2023-06-07 Paul Wise  wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.

> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.

> This would be more work for Debian and a lot more work for upstreams
> but would be a better outcome for the diversity of uses for 32-bit.

Hello,

I doubt it is a realistic option, though. This is a non-trivial change
and imho way over Debian's resources.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Guillem Jover]

Hi!

On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:
> > Enabling time64 explicitly is what also had first come to my mind,
> > which does not seem too onerous if all the debhelper override
> > disappears? :) Then NEW processing could be done in one go to let the
> > flood gates open at a specific coordinated date and time range (or
> > staged via NEW into experimental, then mass uploaded to unstable to
> > reduce the pressure on the ftpmaster(s) having to approve those), at
> > which point dpkg could also be uploaded with the default switched.
> 
> The difference in my view is that the changes to handle Provides: are
> something that should persist in the packaging (until the next soname
> change, at which point it's easy to handle as part of the overall renaming),
> whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
> something that ideally would be dropped immediately after dpkg-buildflags is
> updated, and could (though unlikely) be a source of bugs later.  I'd prefer
> to avoid any transition plan which means I should be NMUing all of the
> affected library packages twice.

I think I understand where you are coming from, and I see how ideally
these would be dropped soon, but I also don't see this as a pressing
matter that would even need NMUs, as the explicit settings should map
to the then current defaults. Of course that precludes those defaults
then changing globally in the future, but if needed (!?) that could be
handled later on. But again, I think the flag day can potentially be
done in multiple other ways that might avoid the breakage w/o needing
these changes, and if so I'm happy with that as well.

> Either way, we will need to come to some sort of decision about what to do
> on i386 before we can move forward.  How should we reach that decision?  Are
> you persuaded by the arguments presented in this thread?

I think it depends a bit on the overall timing and support guarantees.
If say i386 was to be dropped very soon from the archive, then it does
not seem to me that making it an exception might be a good trade-off,
because people could then use an unsupported release for time32 and
a later unsupported one for time64 if they want to use either of those
ABIs. If there is a will to keep it longer (either as a full or partial
arch), then that changes the equation and it depends what people would
value more between ABI compat or time64-ready.

I think I covered part of this in
. So if
there's consensus either way, I'm OK with that, but given that this is
a matter of trade-offs and what we'd want to support, Helmut's proposal
for a GR also sounds very enticing TBH, and would be a clear signal
and remove ambiguity over what the project wants to do.

> > Hmm, rechecking the script, I think we'd want to at least
> > unconditionally add the Breaks and Replaces (no need for substvars
> > then), otherwise we'd get upgrade errors?
> 
> > That would leave only the Provides as potentially conditional…
> 
> You're absolutely right, thanks for catching this!  Fixed in git.

As hinted above, I think the source:Version substvar should be
switched to a hardcoded version at the point the migration was done,
otherwise it will be floating forward and not catch older affected
versions?

> > > And btw, given the analysis that there are likely < 100 shared libraries
> > > overall whose ABI changes when enabling LFS, this might be a change we 
> > > want
> > > to consider in the trixie cycle as well - just preferably not bundled with
> > > the time_t transition at the same time, as that would just cause more 
> > > delays
> > > for testing migration vs splitting the two transitions.
> 
> > If the plan is to go with a flag day by switching the default for
> > time64, then I don't see how the LFS change can be decoupled, as that
> > automatically will also forcibly enable LFS globally on glibc arches.
> > I've also in general been worried about automatically enabling LFS w/o
> > someone looking into each package, given the greater potential for
> > data loss. :/
> 
> I think in the case of LFS-sensitive libraries that aren't part of the
> dependency graph of packages affected by the time_t change, it's easy enough
> to patch them to not turn on the LFS flag and avoid a transition.

Just to try to understand whether we are on the same page. If these
libraries have no time_t usage at all, then disabling time64 should
then provoke no time_t issue and should stop implicitly enabling LFS.
But if the library contains internal time_t usage that is not part of
the exposed ABI, but part of its operation, then I'm not sure I see
how we can patch them to disable LFS w/o at the same time losing
time64 support (as the latter forces/requires the former).

I'm not sure whether you are talking about the first or second case?
And whether we have no libraries at all falling 

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Lisandro Damián Nicanor Pérez Meyer]

Hi, late on the thread, but...

On Tue, 30 May 2023 at 19:51, Diederik de Haas  wrote:
>
> [Please CC me in replies as I'm not subscribed to this list]
>
> I hope I'm not too late for this discussion ...
>
> Steve McIntyre  wrote:
> > Luca Boccassi wrote:
> > >On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
> > >> I'm planning on stopping publishing installer images for i386
> > >> soon. Why? We should be strongly encouraging users to move away from
> > >> If they're still running i386 *hardware*, then they should be replacing
> > >> that hardware with more modern, more capable, more *efficient* stuff.
> > >>
> > >+1 for stopping publishing installers for i386, it has been mentioned
> > >many times but it's always worth repeating: electricity costs to keep
> > >running i386 hardware are already way higher than what it costs to buy
> > >a cheap, low-power replacement like a raspberry pi, that also provides
> > >better performance.
> >
> > Exactly.
> > ...
> > If people have strong opinions about that plan, let us know please.
>
> I have *strong* opinions about this.
>
> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.
>
> While it may be a no-brainer for a person with a $/€ 1000 a month residual
> income to just buy new hardware whenever they feel like it, that is not the
> case for everyone.
>
> To quote (a part) of that email:
> > I happen to know of a few derivative projects that have been using
> > Debian technology that have brought new life to some really aging equipment
> > and some people in either Third World countries or in communities with low
> > incomes and either limited or non-existent access to modern equipment. One
> > such effort, the antiX distribution, has been effective in reaching poor
> > communities in Brazil recently, and has long been able to reach people with
> > scaled down Debian technology all over the world.
> >
> > I'm wondering if there is some way to provide a "hook" or a way for some of
> > these ten to twenty year old systems to remain functional for those who may
> > not otherwise have a way, other than to run insecure, out of date systems.
> > If there is a way, even a "side project", I hope that the Debian community
> > can help a few of these derivative distributions assist people worldwide to
> > have access to modern technology,
> > even from systems that are barely "modern" any more.
>
> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work 
> their
> asses off just to put food on the table, and thus also don't have the money to
> buy new equipment. But if you want to interact with your own government, you
> highly likely will need to have some PC (type) equipment.
> It could also provide a way to learn/develop new skills.
>
> It's absolutely true that modern machines are more energy efficient. What is
> also true is that the production of new devices has a big environmental
> impact.

Well, I do consider myself someone living in a third world country,
possibly already a four world by now. Some years ago I would have
certainly totally concurred with your observation. Nowadays? No. amd64
systems are old enough that you can find them in old machines too. My
PoV is that we reached the point at which we can safely say there are
replacements. Ecologically it is better to refurbish old amd64 systems
rather than trying to keep the i386 alive.

My personal PoV, but...



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: 64-bit time_t transition for 32-bit archs: a proposal

[The Wanderer]

On 2023-06-07 at 03:19, Sune Vuorela wrote:

> On 2023-06-07, Paul Wise  wrote:
>
>> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>>
>>> I've been reading the discussion around i386 a bit and found the
>>> direction it has taken a little unproductive.
>>
>> I note that there are a number of packages available on i386 but not
>> available on amd64, is anyone planning on an MBF about this issue?
> 
> I got curious. Some of them are hurd specific. Others are a i386
> specific version, either for fewer processor capabilities or just a
> specific one, like sigend bootloader packages and such. Lets remove
> those and see what we have left. 
> 
> oh. and a few are miscategorized. And some binary-only non-free.

> snes emulator. last upstream release 2007
>>  zsnes deb otherosfs optional arch=any-i386

FWIW: though I haven't touched it in quite some while, I recall from all
those years ago that the reason zsnes is i386-only is that part of its
code is hand-written assembly language for (some variant of) that
architecture, and that rewriting it for that not to be the case would be
at best impractical.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Wed, 07 Jun 2023 at 07:19:39 -, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise  wrote:
> > I note that there are a number of packages available on i386 but not
> > available on amd64, is anyone planning on an MBF about this issue?
> 
> game stuff, mostly contrib, likely binary data for binary blobs
> >  steam deb contrib/oldlibs optional arch=i386
> >  steam-libs-i386 deb metapackages optional arch=i386
> >  steamcmd deb non-free/games optional arch=i386

Steam consists of proprietary binaries which are a mixture of i386 and
amd64. It functionally requires *both* architectures to work. The top-level
package for how this now works in Debian is steam-installer.

The 'steam' package is a transitional package from an older packaging
scheme where it was possible to run on purely 32-bit systems (that is
not true any more), so it is only useful when upgrading existing
32-bit-capable machines.

Even if Valve chose to port the main Steam client executable to amd64,
the purpose of Steam is to run Steam games, and a lot of the older
games (like Team Fortress 2) are proprietary i386 binaries. As long as
that's the case, which in practice it will be forever, we'll need the
steam-libs-i386 metapackage to pull in at least the subset of those games'
dependencies that they cannot usefully bundle (mainly glibc and Mesa).

steamcmd is a proprietary i386 binary. No amd64 version exists, so
until/unless Valve produce one (likely to be a vanishingly low priority),
the only options are i386 or remove.

> >  etqw deb contrib/games optional arch=i386
> >  etqw-server deb contrib/games optional arch=i386
> >  quake4 deb contrib/games optional arch=i386
> >  quake4-server deb contrib/games optional arch=i386

These are wrappers around proprietary i386 binaries which are not in
Debian for licensing reasons, but can be packaged locally by using
game-data-packager. No amd64 version exists, and only their developer
(indirectly Microsoft, which owns ZeniMax, which owns id Software)
could produce one, which in practice is unlikely to happen; so the only
options are i386 or remove.

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Peter Van Eynde]

Hi,

On Wed, Jun 7, 2023, at 09:19, Sune Vuorela wrote:
> lisp runtie. unsure why restricted
>>  cmucl deb lisp optional arch=i386
>>  cmucl-clm deb lisp optional arch=i386

cmucl contains a compiler and is self hosting (the compiler is used to create 
the new version of the environment). x86 is the last active architecture for 
this system, but as a whole it is slowly drying.

Most people moved on to using sbcl, which supports amd64 and has a more active 
development. I planned to ask for removal of cmucl after the next release. End 
of an era...

Best regards, Peter

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Sune Vuorela]

On 2023-06-07, Paul Wise  wrote:
> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>
>> I've been reading the discussion around i386 a bit and found the
>> direction it has taken a little unproductive.
>
> I note that there are a number of packages available on i386 but not
> available on amd64, is anyone planning on an MBF about this issue?

I got curious. Some of them are hurd specific. Others are a i386
specific version, either for fewer processor capabilities or just a
specific one, like sigend bootloader packages and such. Lets remove
those and see what we have left. 

oh. and a few are miscategorized. And some binary-only non-free.

Some byte code interpreter for games and games. Apparantly puts pointers
in ints.
>  fenix deb devel optional 
> arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
>  fenix-plugin-mpeg deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins-system deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  pixbros deb games optional 
> arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
>  pixfrogger deb games optional 
> arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4

Last upstream release uploaded in 2004. Unsure why restricted
>  fnfx-client deb utils optional arch=i386
>  fnfxd deb utils optional arch=i386

TV card grabber. Last upstream release uploaded in 2002. Unsure why
restricted
>  gatos deb misc extra arch=i386
>  libgatos-dev deb libdevel extra arch=i386
>  libgatos0 deb libs extra arch=i386

Tv card configuration. Last upstream uploadde in 2002. Unsure why
restricted
>  atitvout deb misc optional arch=i386,ia64

loads vst plugins. But others does that on 64bit as well
>  lmms-vst-server deb sound optional arch=i386

Hardware driver helper. The accompanying dkms package seems to also be
x86_86
>  sl-modem-daemon deb non-free/misc optional arch=i386

playstation2 emulator. Requires sse2.
>  pcsx2 deb games optional arch=i386

snes emulator. last upstream release 2007
>  zsnes deb otherosfs optional arch=any-i386


Old soundblaster card related:
>  adlibtracker2 deb sound optional arch=i386
>  sb16ctrl-bochs deb otherosfs optional arch=any-i386

m68k helper. Unsure why restricted
>  mac-fdisk-cross deb otherosfs optional arch=i386,m68k
>  pmac-fdisk-cross deb otherosfs optional arch=i386,m68k

lisp runtie. unsure why restricted
>  cmucl deb lisp optional arch=i386
>  cmucl-clm deb lisp optional arch=i386

game stuff, mostly contrib, likely binary data for binary blobs
>  steam deb contrib/oldlibs optional arch=i386
>  steam-libs-i386 deb metapackages optional arch=i386
>  etqw deb contrib/games optional arch=i386
>  etqw-server deb contrib/games optional arch=i386
>  quake4 deb contrib/games optional arch=i386
>  quake4-server deb contrib/games optional arch=i386
>  steamcmd deb non-free/games optional arch=i386

Non-free or non-free binary dependencies
>  intel-mkl-linktool deb non-free/utils optional arch=i386
>  libmkl-gf deb non-free/libs optional arch=i386
>  libmkl-intel deb non-free/libs optional arch=i386
>  libmkl-p4 deb non-free/libs optional arch=i386
>  libmkl-p4m deb non-free/libs optional arch=i386
>  libmkl-p4m3 deb non-free/libs optional arch=i386
>  libmkl-vml-ia deb non-free/libs optional arch=i386
>  libmkl-vml-p4 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m deb non-free/libs optional arch=i386
>  libmkl-vml-p4m2 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m3 deb non-free/libs optional arch=i386
>  speech-dispatcher-ibmtts deb contrib/sound optional arch=i386

i386-version of something and helpers and hardware enablement:
>  fp-units-i386 deb devel optional arch=i386
>  fp-units-i386-3.2.2 deb devel optional arch=i386
>  fwupd-i386-signed-template deb admin optional arch=i386
>  fwupd-i386-signed deb admin optional arch=i386
>  libnvidia-legacy-340xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-340xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  libnvidia-legacy-390xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-nonglvnd-i386 deb non-free/libs optional 
> arch=i386
>  grub-efi-ia32-signed deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  sse2-support deb misc optional arch=any-i386
>  shim-helpers-i386-signed-template deb admin optional arch=i386
>  shim-helpers-i386-signed deb admin optional arch=i386
>  strace64 deb utils optional arch=i386,powerpc,s390,sparc
>  wine32 deb 

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 12:45 -0700, Steve Langasek wrote:

> since we don't really have an "i386 porting team"

The release team have registered Adrian Bunk as an i386 porter:

https://release.debian.org/testing/arch_spec.yaml

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:

> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive.

I note that there are a number of packages available on i386 but not
available on amd64, is anyone planning on an MBF about this issue?

$ grep -h arch=.*i386 /var/lib/apt/lists/*Sources | grpe -v amd64 | grep -v -- 
-modules- | grep -v  -- -image- | grep -v -- -headers- | grep -v -- -dbg  | 
grep -v lib64 | grep -v x86-64-linux-gnu
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 sse2-support deb misc optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 etqw deb contrib/games optional arch=i386
 etqw-server deb contrib/games optional arch=i386
 quake4 deb contrib/games optional arch=i386
 quake4-server deb contrib/games optional arch=i386
 speech-dispatcher-ibmtts deb contrib/sound optional arch=i386
 adlibtracker2 deb sound optional arch=i386
 atitvout deb misc optional arch=i386,ia64
 sb16ctrl-bochs deb otherosfs optional arch=any-i386
 cmucl deb lisp optional arch=i386
 cmucl-clm deb lisp optional arch=i386
 fenix deb devel optional 
arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
 fenix-plugin-mpeg deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fenix-plugins-system deb devel optional 
arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
 fnfx-client deb utils optional arch=i386
 fnfxd deb utils optional arch=i386
 fp-units-i386 deb devel optional arch=i386
 fp-units-i386-3.2.2 deb devel optional arch=i386
 fwupd-i386-signed-template deb admin optional arch=i386
 fwupd-i386-signed deb admin optional arch=i386
 gatos deb misc extra arch=i386
 libgatos-dev deb libdevel extra arch=i386
 libgatos0 deb libs extra arch=i386
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 libc0.3 deb libs optional arch=hurd-i386 profile=!stage1
 libc0.3-dev deb libdevel optional arch=hurd-i386
 libc0.3-udeb udeb debian-installer optional arch=hurd-i386 
profile=!noudeb,!stage1
 grub-efi-ia32-signed deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 grub-efi-ia32-signed-template deb admin optional arch=i386
 sse2-support deb misc optional arch=any-i386
 lmms-vst-server deb sound optional arch=i386
 longrun deb utils optional arch=i386
 lphdisk deb admin optional arch=i386
 mig-i686-gnu deb devel optional arch=any-i386
 netdata-core-no-sse deb net optional arch=i386
 pcsx2 deb games optional arch=i386
 pixbros deb games optional 
arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 pixfrogger deb games optional 
arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
 shim-helpers-i386-signed-template deb admin optional arch=i386
 shim-helpers-i386-signed deb admin optional arch=i386
 sqlite3-tools deb database optional arch=linux-any,hurd-i386
 steam deb contrib/oldlibs optional arch=i386
 steam-libs-i386 deb metapackages optional arch=i386
 strace64 deb utils optional arch=i386,powerpc,s390,sparc
 syslog-ng-mod-snmp deb admin optional arch=linux-any,hurd-i386
 wine32 deb otherosfs optional arch=i386,armel,armhf
 wine32-preloader deb otherosfs optional arch=i386,armel,armhf
 wine32-tools deb libdevel optional arch=i386,armel,armhf
 xserver-xorg-video-geode deb x11 optional arch=any-i386
 zsnes deb otherosfs optional arch=any-i386
 intel-mkl-linktool deb non-free/utils optional arch=i386
 libmkl-gf deb non-free/libs optional arch=i386
 libmkl-intel deb non-free/libs optional arch=i386
 libmkl-p4 deb non-free/libs optional arch=i386
 libmkl-p4m deb non-free/libs optional arch=i386
 libmkl-p4m3 deb non-free/libs optional arch=i386
 libmkl-vml-ia deb non-free/libs optional arch=i386
 libmkl-vml-p4 deb non-free/libs optional arch=i386
 libmkl-vml-p4m deb non-free/libs optional arch=i386
 

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Paul Wise]

On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:

> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:

There was another option mentioned earlier in the thread that could
help resolve some aspects of these conflicts; make 32-bit arches
(or just i386) support both time_t ABIs, like glibc and Linux do.

The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
would be present for running old binaries that still kind of work with
the 32-bit ABIs after 2038, or under faketime when they do not.

This would be more work for Debian and a lot more work for upstreams
but would be a better outcome for the diversity of uses for 32-bit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Tue, 06 Jun 2023 at 12:27:56 -0600, Gunnar Wolf wrote:
> there is the possible
> case of people running I-don't-know-which proprietay productivity tool
> provided as a binary that cannot be convinced of a 64-bit time_t that
> will receive errors when the timeocalypse approaches

Sure, and that's unfortunate; but if those same people run the same binary
on i386 + 64-bit time_t, and it gets memory corruption and crashes
because some library that was recompiled for this transition is now trying
to put a 64-bit time_t into a 32-bit location, that's not actually going
to be any more suitable for their needs.

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

Hi Helmut,

On Tue, Jun 06, 2023 at 09:33:22AM +0200, Helmut Grohne wrote:
> On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> > * … but NOT on i386.  Because i386 as an architecture is primarily of
> >   interest for running legacy binaries which cannot be rebuilt against a new
> >   ABI, changing the ABI on i386 would be counterproductive, as mentioned in
> >   https://wiki.debian.org/ReleaseGoals/64bit-time.

> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive. I hope we can agree that
> there is no consensus on keeping or changing the time ABI for i386 while
> there is quite some consensus for your plan on changing the time ABI for
> all other 32bit architectures in roughly the way you brought forward.

I have a different read on the consensus here.  While there has been a lot
of discussion about whether to continue supporting i386 as a host arch,
almost everyone participating in the thread who said they want this is not a
voting member of Debian.  The lone exception that I can recall from the
thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in
this decision (and since we don't really have an "i386 porting team",
probably the most important individual stakeholder).

Since my read is that Guillem was in the "rough" of "rough consensus", I
asked him directly how we should move forward on a decision.  A GR is one
option, and I think it's definitely a better option than going through the
TC: while there is a decision to be made here about a "technical" detail of
what dpkg-buildflags will do, you're right to point out that it's really a
decision about what we want to support as a project.

> While the i386 discussion seemed a little unproductive at times, I think
> there is one major argument that I feel is missing here. If keeping the
> 32bit time ABI for i386, that effectively becomes a divergence from
> every other architecture. i386 will be the one and only architecture to
> be time32. As it happens, I have some experience with such divergence
> from how bootstrapping interacted with other transitions such as PIE.
> Maintaining this kind of divergence has a non-trivial cost. Over time it
> becomes more and more difficult and less and less people are interested
> in doing it. As such, I see the addition of this kind of divergence as a
> way of killing i386.

Hmm, I don't share this particular concern.  PIE is a change to compiler
behavior.  32-bit time_t is a change to defines that modify types (and
prototypes) used in header files.  Maintaining a compiler is hard,
maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25
years so far.

> Judging from the conversation, killing i386 quite obviously is desired
> by some participants, but evidently not by all. How quickly we want to
> kill it is not obvious to me. However, I think it is fair to say that
> keeping time32 on i386 will kill it rather sooner than later. With
> time32, we cannot reasonably extend i386 beyond forky as we'd be running
> too close to the final deadline.

As a reliable host OS, sure.  As a compatibility layer, as Simon has pointed
out, having a wrong idea of the time is not a big deal for a lot of
applications.

> Some of you may have been aware of that Debian Reunion in Hamburg
> recently. There was a BoF on how Debian should decide about non-trivial
> matters and one result of that BoF was "maybe we should GR more often".
> I think the decision of what to do with time32 is not a really important
> one despite some people being very opinionated about it. How about
> settling it using a GR anyway? We perceive GRs as painful and there is a
> saying that if something is difficult, let's do it more often. How about
> trying to do GRs more often with this decision? I think it is pretty
> clear that neither answer is wrong. It's a choice that we have make and
> then to stick to. And we can learn something about whether GRs really
> are painful. I think the worst of outcomes we could get here is going
> into much further detail in a GR and adding lots of competing proposals
> there. If that were to happen, I'd consider the experiment as failed.
> Leaving the details to those who put up with the work (and that quite
> obviously is Steve et al here) is important in my book. So unless we can
> do it as simple as "i386 should keep being time32" vs "i386 should
> become time64 by default", we probably shouldn't GR it.

I am not keen to try to drive a GR on this, but if you raised one I'm likely
to second it.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Alexis Murzeau]

Hi,

On 06/06/2023 12:45, Simon McVittie wrote:

2. i386 as a multiarch foreign architecture to run legacy binaries on
modern x86_64 systems
2a. legacy native Linux i386 binaries
2b. legacy Windows i386 binaries via Wine (which requires a somewhat
complete i386 Linux library stack)



Windows already uses 64 bits time_t on i386 since Visual Studio 2005,
unless _USE_32BIT_TIME_T is defined ([msvcrt-time]), and even if it is
defined, Wine implementation of 32 bits time() will not use Linux' time_t.

So I'm not sure Windows i386 binaries will be affected by a Linux-side change of
time_t, unless you think about something else.


For the same reason, this line in the wiki [wiki] may not be true:
32-bit wine (i386 only). This does not make much sense with 64-bit time. It's whole purpose is to run old i386-ABI binaries. The ABI for this arch (and thus wine-32) should not change. 




Also, as said in this interesting Wine-devel thread about i386 
[wine-devel-32bits]:

Many 64-bit applications still use either a 32-bit installer or some
32-bit components. In comparison 64-bit Windows will support 32-bit
(probably) forever.


And even if newer Wine versions supports WoW (32 bits Windows on 64 bits
within the same Wine prefix), 64 bit Wine still require 32 bits Linux
libraries to run 32 bits Windows programs.

This means that Wine will probably require 32 bits Linux libraries for
probably a long time and not only for legacy Windows binaries.



[msvcrt-time]
 - https://sources.debian.org/src/wine/8.0~repack-4/include/msvcrt/time.h/#L92
 - https://sources.debian.org/src/wine/8.0~repack-4/dlls/msvcrt/time.c/#L781

[wiki] https://wiki.debian.org/ReleaseGoals/64bit-time
[wine-devel-32bits] 
https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_signature
Description: OpenPGP digital signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Gunnar Wolf]

Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]:
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not obvious to me.
> 
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
> 
> 1. i386 as a fully-featured architecture that you can run independently
>on 32-bit x86 systems from roughly the 2000-2010 era
> 
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>modern x86_64 systems
>2a. legacy native Linux i386 binaries
>2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>complete i386 Linux library stack)
> (...)

I completely agree with your analysis here, and I agree we should
strive to keep 2a and 2b covered, as they are (and they will be, every
time by a bigger margin) by far more common and productive than 1.  I
agree with your assessment that date woes will be minor for the i386
user than incompatibility woes going forward; there is the possible
case of people running I-don't-know-which proprietay productivity tool
provided as a binary that cannot be convinced of a 64-bit time_t that
will receive errors when the timeocalypse approaches, but I guess the
gaming use cases will be much more frequent than that; even though
your vision might be somewhat skewed by the fact that you work in
Steam, it makes complete sense.

Of course, given our i386 users would be running (>10 years for now) a
Debian architecture used mostly for compatibility with old non-free
binaries, we'd have to think whether it makes sense to provide a full
Debian experience (i.e. you don't want i386 users to have a PostgreSQL
with a known-borked time implementation storing important information
in it -- and of course, this is only the first of too many examples
that comes to my mind, but won the race to get to my fingers )

But anyway, back to what matters here: I support Helmut's idea. I have
long thought we fear the GR process too much, and we should excercise
it more. Not every GR has to be a flamefest. Having a clear statement
of what is being voted on, and the possible consequences on each of
the options, can lead to a civil, useful way to measure the opinion of
project members interested in the subject.

Right now, I imagine a ballot similar to:

The future of i386 in Debian from Trixie onwards

   A. Drop support of i386 completely
   B. Keep support of i386 as a multiarch-foreign arch, with 32-bit time_t
   C. Keep support of i386 as a multiarch-foreign arch, with 64-bit time_t
   D. Commit to supporting i386 as a full-featured arch, with 32-bit time_t
   E. Commit to supporting i386 as a full-featured arch, with 64-bit time_t
   F. Further discussion

I know this woul conflate two decisions in one ballot, but arguably
they are part of the same issue. I do not feel qualified to draft the
full vote, as I have not followed the discussion as closely as I'd
like to and I'm not directly affected anyway, but would be very happy
to second it.

FWIW, I believe the only real danger in having non-controversial GRs
would be that a vote does not reach quorum (48 voters in the last GR),
but I don't believe it is a real danger to worry about; in any case,
failure to reach quorum would mean the project does not _mandate_ a
decision, but it can be anyway implemented by porters / RT.

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Marco d'Itri]

On Jun 06, Simon McVittie  wrote:

> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
Agreed. I will be more blunt: an i386 port which cannot run old i386 
binaries would be almost useless.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Luca Boccassi]

On Tue, 6 Jun 2023 at 11:46, Simon McVittie  wrote:
>
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not obvious to me.
>
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
>
> 1. i386 as a fully-featured architecture that you can run independently
>on 32-bit x86 systems from roughly the 2000-2010 era
>
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>modern x86_64 systems
>2a. legacy native Linux i386 binaries
>2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>complete i386 Linux library stack)
>
> For example, Ubuntu has ceased to support i386 for the first use-case,
> and only supports the second use-case. I personally think that Ubuntu
> has made a good pragmatic decision here, which Debian should seriously
> consider adopting.

+1

Given native 32-bit x86 hardware is no longer produced (and has not
been produced for a good while), so it has a de-facto limited life, as
consumer-grade electronics are what they are. Let's say hypothetically
that Trixie is the last full-i386 release, going out in 2025 plus 10
years of LTS+ELTS support that gives a supported OS till 2035, just
shy of the Y2038 deadline and with ~25 years of full support for the
most recent piece of hardware that was produced. And it's not like
those OSes versions are going to evaporate into thin air at that point
- they can still be used. Probably should not be connected to the open
internet and used to browse the web, but realistically already today I
doubt browsing the modern web is a good experience on 32bit hardware
from 2010, I can't imagine it would much better be in 2035...

On the other hand, i386 binaries that can run on x86_64 are
realistically going to be around for much, much longer as you pointed
out, so to me prioritizing this use case seems more prudent and
future-proof between the two alternatives.

Kind regards,
Luca Boccassi

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Simon McVittie]

On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> Judging from the conversation, killing i386 quite obviously is desired
> by some participants, but evidently not by all. How quickly we want to
> kill it is not obvious to me.

When considering the future of i386, a factor that we need to bear in
mind is that there are two major use-cases for i386, with requirements
that sometimes conflict:

1. i386 as a fully-featured architecture that you can run independently
   on 32-bit x86 systems from roughly the 2000-2010 era

2. i386 as a multiarch foreign architecture to run legacy binaries on
   modern x86_64 systems
   2a. legacy native Linux i386 binaries
   2b. legacy Windows i386 binaries via Wine (which requires a somewhat
   complete i386 Linux library stack)

For example, Ubuntu has ceased to support i386 for the first use-case,
and only supports the second use-case. I personally think that Ubuntu
has made a good pragmatic decision here, which Debian should seriously
consider adopting.

Most non-Debian-derived distributions like Fedora and Arch seem to be in
approximately the same position as Ubuntu for their i386 support, although
they tend to use multilib (lib64+lib or lib+lib32) instead of multiarch.

Which of these use-cases is more interesting to us has an impact on how
we (should) want to do the time32 transition. For users who do not have
any legacy i386 binaries and only use open source software that can be
recompiled, the need to recompile everything is a one-time cost for the
distribution or for users of locally-compiled software, but does not make
anything impossible.

However, if the ABI of commonly-used libraries like libX11 undergoes an
incompatible change for the time32 transition, in a way that breaks the
ability to run legacy i386 binaries, then the second use-case is going
to become essentially impossible for native Linux binaries.

Conversely, the ability to tell the time correctly is probably less
important for games and similar legacy i386 binaries than it would be for
a full, bootable OS, because timestamps that can be subtracted to get a
relative time interval are probably sufficient for many legacy uses of
time_t. Even in cases where a time_t is used for an absolute date/time,
displaying the wrong date/time after 2038 seems like a less bad failure
mode than a segmentation fault caused by disagreeing on the size of a
struct in memory.

The i386-legacy-binaries use-case is particularly visible to game players,
because older proprietary native Linux games, including a number of
older games available on Steam, are a high-visibility source of legacy
i386 binaries that we cannot recompile. At the moment, the Steam client
is also an example of a legacy i386 binary: this was originally for
portability to 32-bit hardware, which it no longer supports, but the
bootstrap executable that launches the rest of Steam has continued to be
32-bit, partly for historical reasons and partly as a canary to detect and
diagnose non-32-bit-capable OSs before the user tries to run any actual
games. Steam does have the ability to run legacy games in a container
(which I've spent a lot of time working on over the last few years),
but that still requires the host system to contribute at least glibc
and Mesa, together with their dependencies.

Whether we care about the 32-bit-system use case or only the
i386-legacy-binaries use case is also a key input into other decisions
that need to be made around x86, like whether we raise the baseline
to include SSE2: if we want to be able to run i386 on older 32-bit
CPUs indefinitely, then that's a reason to keep the current baseline,
but if we are no longer interested in supporting 32-bit x86 hardware,
then we can (and arguably should) raise the baseline to require all the
features that are mandatory for x86_64, notably SSE2 (which would allow
compiling everything with -mfpmath=sse and therefore avoiding weird
i386-specific bugs caused by excess precision in the legacy i387 FPU).

smcv

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Helmut Grohne]

Hi Steve,

On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> * … but NOT on i386.  Because i386 as an architecture is primarily of
>   interest for running legacy binaries which cannot be rebuilt against a new
>   ABI, changing the ABI on i386 would be counterproductive, as mentioned in
>   https://wiki.debian.org/ReleaseGoals/64bit-time.

I've been reading the discussion around i386 a bit and found the
direction it has taken a little unproductive. I hope we can agree that
there is no consensus on keeping or changing the time ABI for i386 while
there is quite some consensus for your plan on changing the time ABI for
all other 32bit architectures in roughly the way you brought forward.

While the i386 discussion seemed a little unproductive at times, I think
there is one major argument that I feel is missing here. If keeping the
32bit time ABI for i386, that effectively becomes a divergence from
every other architecture. i386 will be the one and only architecture to
be time32. As it happens, I have some experience with such divergence
from how bootstrapping interacted with other transitions such as PIE.
Maintaining this kind of divergence has a non-trivial cost. Over time it
becomes more and more difficult and less and less people are interested
in doing it. As such, I see the addition of this kind of divergence as a
way of killing i386.

Judging from the conversation, killing i386 quite obviously is desired
by some participants, but evidently not by all. How quickly we want to
kill it is not obvious to me. However, I think it is fair to say that
keeping time32 on i386 will kill it rather sooner than later. With
time32, we cannot reasonably extend i386 beyond forky as we'd be running
too close to the final deadline.

Some of you may have been aware of that Debian Reunion in Hamburg
recently. There was a BoF on how Debian should decide about non-trivial
matters and one result of that BoF was "maybe we should GR more often".
I think the decision of what to do with time32 is not a really important
one despite some people being very opinionated about it. How about
settling it using a GR anyway? We perceive GRs as painful and there is a
saying that if something is difficult, let's do it more often. How about
trying to do GRs more often with this decision? I think it is pretty
clear that neither answer is wrong. It's a choice that we have make and
then to stick to. And we can learn something about whether GRs really
are painful. I think the worst of outcomes we could get here is going
into much further detail in a GR and adding lots of competing proposals
there. If that were to happen, I'd consider the experiment as failed.
Leaving the details to those who put up with the work (and that quite
obviously is Steve et al here) is important in my book. So unless we can
do it as simple as "i386 should keep being time32" vs "i386 should
become time64 by default", we probably shouldn't GR it.

Helmut

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

On Friday, 2 June 2023 20:59:27 CEST Wouter Verhelst wrote:
> "complain on -devel" is not part of the job

That wasn't my intend, but I obviously horribly failed at that.
Won't happen again o/

signature.asc
Description: This is a digitally signed message part.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
[...]
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi. If
> > you want to support people who can't afford shiny new hardware, I think
> > pointing them to raspberry pi-class hardware is a better idea than
[...]
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry. 
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
> clear what they need, namely keeping support for i386, a bunch of people feel 
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.

That's actually a bit of a misrepresentation of what I said.

I do believe there are still people using i386 hardware. I know for a
fact that there are still people using m68k hardware, too.

My argument is that "it is still used" is an argument that, due to the
very fact that retrocomputing exists, will never be a wrong statement.
To name an extreme example, there exist a handful of apple I devices
that are in working order today, but nobody would reasonably suggest
that it is a platform that still matters today.

Since it is always possible to come up with an example of someone still
using some old piece of hardware, I therefore think that it is not a
very compelling argument, in and of itself.

I also specifically said that older systems *typically* require more
power for less performance (etc). Of course there are exceptions, but
those are much more rare than the more common case of 20 year old
desktop-class hardware.

As an ex contributor to the m68k port who was active on the port when
our buildd hosts were still running on actual m68k hardware, I can tell
you that 20 year old hardware is not reliable *at all*. I have forgotten
how many times we've had to scrounge for older hard drives to replace
ones that died, wiggle RAM modules around, or do various types of
insane hardware maintenance that on modern hardware just isn't
necessary (I .. remember the one time where the one host
had to be moved because it was in a hot attic and the cooling system
had Opinions on having been run 24/7 for over a decade). As such, if
your choice is between a 20 year old piece of hardware or a brand new
one that has similar performance, your better choice is almost always
going to be the latter.

Note again how I said "almost always" here. Exceptions exist.

In my opinion, the question we should be asking ourselves is therefore
not "can we still find valid use cases for the port", because the answer
to that is always "yes" and therefore not interesting, but rather, "how
much effort will it cost us to keep the old port running".

Note that the answer to that very valid question will be influenced by
"who is interested in keeping the port available". If there is a strong
feeling that the i386 port needs to go, and there is a bunch of people
with the skills required and the interest in changing that, then there
is a fairly straightforward thing they can do to avoid the port being
binned. It requires you do lot of work, but "complain on -devel" is not
part of the job.

I was part of the team that kept doing the necessary work for years, and
we saved the port from being removed from Debian several times. If you
want to do the same for i386, the path is clear...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[nick black]

Adam Borowski left as an exercise for the reader:
> Instead of RasPis as suggested by many in this thread, I'd instead suggest
> whatever is the current model of Odroid-H2+:

I was intrigued, but https://ameridroid.com/products/odroid-h2
suggests it's been out of stock since 2021?

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Adam Borowski]

On Wed, May 31, 2023 at 10:10:56PM +, Andrew M.A. Cater wrote:
> As someone who owned and happily used an Asus eePC several years ago: very
> nice, silent - it also had a flash disk from the earliest days of flash disks.

Instead of RasPis as suggested by many in this thread, I'd instead suggest
whatever is the current model of Odroid-H2+:
* x86
* no moving parts
* either my meter is broken or it's 4.6W under full load (specs say 14W?!?)
* fat i/o
* 2×2.5Gbe

> The same arguments that I would now apply to the i386 port I'd also 
> apply to early AMD64 hardware - whoever had my first machine with it,
> it should now be long gone as power inefficient beyond words and 
> 15 years old.

At that time the concept of a daily driver capable machine taking low power
was in its infancy, they just can't come close to newer designs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Theodore Ts'o]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> 
> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

Debian is a Do-ocracy.  Which is to say, it's a volunteer project.
People work on what they feel like working on.  Trying to guilt-trip
people into working on something because they *should* often doesn't
work well.

If you'd like to make sure that i386 isn't abandoned, why don't you
roll up your sleeves, step forward, and volunteer to help?

Cheers,

- Ted

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Paul Wise]

On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote:

> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

There are Debian contributors who are in this position (although
perhaps not with i386 hardware) and would likely appreciate hardware
donations to upgrade to more modern hardware. At the same time we have
contributors who regularly buy, stop using and discard old hardware.

It would be great if our more fortunate contributors would be willing
to donate hardware to less fortunate contributors and could register
their available hardware on the wiki page for this. Perhaps this could
be extended to users of i386 hardware too.

https://wiki.debian.org/Hardware/Wanted#Donations

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Andrew M.A. Cater]

On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> > On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> My point is: what about people who don't have the option to *buy*
> anything (new or used), for financial, logistical or other reasons?
> 
> I've been keeping an eye on developments in the upstream linux kernel
> and saw there was a 'spring cleaning' (i.e. removal of old HW support).
> Reading through the commit messages, I noticed 2 criteria for removal:
> - Code has (effectively) been unmaintained for MANY years
> - The maintainers have not seen any indication for several years that
>   ANYONE is actually using that hardware.
> 
> I think those are very reasonable criteria.
> In my initial reply I quoted someone who EXPLICITLY said there were
> people who actually used those i386 devices.
> 
> On the kernel team I've an actual valid argument why supporting i386
> hardware is *difficult* as they don't have the HW (themselves) to
> reproduce an i386-specific issue or to test a potential fix for that.
> 
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry. 
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
> clear what they need, namely keeping support for i386, a bunch of people feel 
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.
> 
> Maybe it's an option to answer the ACTUAL question?
> (and that answer could be 'no')
> 
> > I don't think "but old hardware is still used" is a very good argument
> > for keeping i386 around.
> 
> I think that's actually an excellent reason.
> 
> I've likely missed prior discussions around this subject, but I haven't
> seen and can't think of the reasons why so many people seem so adament
> to get rid of i386 ASAP.

I think I raised this some months ago and was told that it was too late to
make a decision to stop for bookworm but that this was something that 
should be decided early in a release cycle and not at the end when deciding
which architectures wouldn't actually make the cut for release.

It is already hard to test i386 on i686 hardware: as others have said,
most of the tests would be on >> 10 year old hardware.

It does become a law of diminishing returns: if i386 programs had to 
be pulled for security or unmaintainability reasons in the course of bookworm, 
nobody would be surprised.

> 
> Assuming there are indeed valid reasons to get rid of i386, I think it
> would be a far better plan to announce that **Trixie** will be the last
> release that will support i386.

No: announce it at the start of bookworm release and have the Trixie release
team immediately drop it for Trixie
- that way you have five years of support to transition off it.
Otherwise, you've just added _another_ five years of lessening support to
an architecture that won't have been produced for >15 years.


> That way people who care about i386 have a full development cycle to
> make i386 the best it can be for as long as they can still use that HW.
> Maybe they can also make arrangements with CIP to designate the Trixie
> kernel as a Super Long Term Support kernel release.
> 
> But tackling on the release notes at the very last moment that Bookworm

> will be the last supported release, seems not so 'nice' IMO.
> 

As someone who owned and happily used an Asus eePC several years ago: very
nice, silent - it also had a flash disk from the earliest days of flash disks.
If the person who has them still has them all running in another five years,
he will have got an excpetional lifespan out of them. There comes a time
when ports and architectures have to die through lack of hardware or 
maintenance: we've seen that for alpha, varieties of mips and sparc, 
effectively, and the maintainers behind the Debian bsd ports have just
suggested that it should end.

The same arguments that I would now apply to the i386 port I'd also 
apply to early AMD64 hardware - whoever had my first machine with it,
it should now be long gone as power inefficient beyond words and 
15 years old.
> Cheers,
>   Diederik

With best wishes, as ever,

Andy Cater

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> > income to just buy new hardware whenever they feel like it, that is not 
the 
> > case for everyone.
> [...]
> > It's absolutely true that modern machines are more energy efficient. What 
> > is 
> > also true is that the production of new devices has a big environmental 
> > impact. 
>
> 20+ year old machines are typically more power hungry, more expensive,
> less performant, and less reliable than an up-to-date raspberry pi. If
> you want to support people who can't afford shiny new hardware, I think
> pointing them to raspberry pi-class hardware is a better idea than

I have worked to improve support for Pine64 devices (too), so that
people who can afford it, can buy power-efficient SBCs (instead of
horrible RPi's where the non-free firmware is the least of their sins).

My point is: what about people who don't have the option to *buy*
anything (new or used), for financial, logistical or other reasons?

I've been keeping an eye on developments in the upstream linux kernel
and saw there was a 'spring cleaning' (i.e. removal of old HW support).
Reading through the commit messages, I noticed 2 criteria for removal:
- Code has (effectively) been unmaintained for MANY years
- The maintainers have not seen any indication for several years that
  ANYONE is actually using that hardware.

I think those are very reasonable criteria.
In my initial reply I quoted someone who EXPLICITLY said there were
people who actually used those i386 devices.

On the kernel team I've an actual valid argument why supporting i386
hardware is *difficult* as they don't have the HW (themselves) to
reproduce an i386-specific issue or to test a potential fix for that.

In the responses here, I've mostly seen the *assumption* that those old
devices must be power hungry. While I'm quite sure modern hardware is
more power *efficient*, that doesn't mean old hardware is thus power
hungry. 
But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
clear what they need, namely keeping support for i386, a bunch of people feel 
the need to respond like "Well, actually, you need this (other thing)".
I find that extremely condescending.

Maybe it's an option to answer the ACTUAL question?
(and that answer could be 'no')

> I don't think "but old hardware is still used" is a very good argument
> for keeping i386 around.

I think that's actually an excellent reason.

I've likely missed prior discussions around this subject, but I haven't
seen and can't think of the reasons why so many people seem so adament
to get rid of i386 ASAP.

Assuming there are indeed valid reasons to get rid of i386, I think it
would be a far better plan to announce that **Trixie** will be the last
release that will support i386.
That way people who care about i386 have a full development cycle to
make i386 the best it can be for as long as they can still use that HW.
Maybe they can also make arrangements with CIP to designate the Trixie
kernel as a Super Long Term Support kernel release.

But tackling on the release notes at the very last moment that Bookworm
will be the last supported release, seems not so 'nice' IMO.

Cheers,
  Diederik


signature.asc
Description: This is a digitally signed message part.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Wed, 2023-05-31 at 19:48 +0100, Wookey wrote:
> On 2023-05-31 07:29 -0500, John Goerzen wrote:
> 
> > > Hanging on to systems using power-hungry chips from 20 years ago instead 
> > > of
> > > intercepting a system such as this is not reducing the number of computers
> > > that end up in the waste stream, it just keeps you stuck with a more
> > > power-hungry system.
> 
> a) That's not necessarily a problem if the machine is running from a
> renewable supply. The issue is emissions, not power consumption per
> se.

Thankfully I have a spiritual power filter[1] based on anthroposophic
principles that makes my computers consume only renewable energy ;-)

> and b) as both John and I have pointed out there are low-power i386
> systems still in use.
> 
> c) it's not our choice to make. If people insist on using more
> electricity than they need to for their computing, that's on them.
> (we
> enable enormous amounts of this already - old i386 systems probably
> barely register at this point)
> 
> Debian should be supporting people using whatever suits them where
> that effort is reasonably proportionate. We are not driven by the
> 'sell new stuff' goals of hardware manufactuers so we should IMHO be
> erring on the side of keeping stuff going as long as there is
> sufficient community support.

I doubt we have that, see some of the issues listed for i386 on
https://release.debian.org/testing/arch_qualify.html

I would not be surprised if we consider dropping leaf software where
builds start to hit the address space limit (I expect browsers & such).

Plus the broken FPU implementation as we don't require SSE.

And it *is* our choice to make to not spend time on dead architectures.

Ansgar

  [1]: It also works for other carbon emissions!

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wookey]

On 2023-05-31 07:29 -0500, John Goerzen wrote:

> > Hanging on to systems using power-hungry chips from 20 years ago instead of
> > intercepting a system such as this is not reducing the number of computers
> > that end up in the waste stream, it just keeps you stuck with a more
> > power-hungry system.

a) That's not necessarily a problem if the machine is running from a renewable 
supply.
The issue is emissions, not power consumption per se.

and b) as both John and I have pointed out there are low-power i386 systems 
still in use.

c) it's not our choice to make. If people insist on using more
electricity than they need to for their computing, that's on them. (we
enable enormous amounts of this already - old i386 systems probably
barely register at this point)

Debian should be supporting people using whatever suits them where
that effort is reasonably proportionate. We are not driven by the
'sell new stuff' goals of hardware manufactuers so we should IMHO be
erring on the side of keeping stuff going as long as there is
sufficient community support.

However, to get back to the topic at hand, old atoms being used by
radio nerds and cavers, effectively as convenient form-factor
'embedded' devices, do not actually care whether the time ABI changes
or not. They are not (SFAIK) running proprietary windows binaries or
games, so the debate about how long support is maintained, at least
for this type of usage, is independent of the 'should the i386 ABI
switch along with other 32-bit ABIs'.

Switching or not (so long as the fairly small subset of the distro we
use keeps working) would not affect our usage of the device, for example.

So if we could try and consider these questions separately, that would be 
helpful.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

John Goerzen dijo [Wed, May 31, 2023 at 07:29:38AM -0500]:
> (...)
> I guess the question is: is this use case too niche for Debian to
> continue supporting?  I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?

Do note, however, the ARM64 started appearing in consumer devices
maybe around 2015, ten years later than AMD64. And nowadays there are
still (although few) ARM32 systems being produced --- I know it's even
funny to refer to them giving the stock shortage that's been biting
them for already too long, but i.e. the lowest Raspberry Pi models
(Zero, 1A, 1B -- the ones that need armel) have "obsolescence
statements" committing to have them produced at least until January
2026¹.


¹ https://www.raspberrypi.com/products/raspberry-pi-zero-w/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-a-plus/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-b-plus/
  (end of page)

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

Alexandre Detiste dijo [Wed, May 31, 2023 at 01:00:42PM +0200]:
> Le mer. 31 mai 2023 à 12:44, Wouter Verhelst  a écrit :
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi.
> 
> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more
> (had to manage some still running on DOS recently ...),
> there's also much of amd64 HW running on i386 because of lazyness/cost
> for hybrid fleets; energy efficiency is there the least of concerns.

You point out a valid and important use case. However... how should I
name this for the sake of the argument... "Large embedded" systems
(i.e. systems that act as embedded because they are the
general-purpose computer that lives inside a very purpose-specific bit
of equipement) are very unlikely to be a compelling use case to keep
producing i386 install media.

Medical equipment is usually tied to a very old computer because it
sports an ancient installation and set of binaries. Those systems are
(thankfully!) most often not internet-connected, so as long as you can
deal with DOS or Win9x quirks, and the gaping security holes won't be
of great importance.

Oh, did your medical imaging system ship with Debian 3.1 Sarge? Sweet!
Beautiful! However, it's quite unlikely you will want to upgrade it to
current-day Debian. Not only you will have to get enough memory for
the very hungry 6.x Linux kernel (I once built a boot floppy disk to
use a given system as an X terminal, and it all fit in 2MB
RAM... Nowadays that would be plainly impossible), but quite likely,
the specialized drivers for the vey one-of-a-kind imaging device would
not work.

And if you manage to replace the old install for said i386 system with
a recent one, I'm sure you would be able to replace the i386 system
with an ARM-based or AMD64-based system as well -- After all, the old
computer is not only needlessly power-hungry, but much more likely to
break.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Sven Hoexter]

On Wed, May 31, 2023 at 07:29:38AM -0500, John Goerzen wrote:

Hi,

> I guess the question is: is this use case too niche for Debian to
> continue supporting?  I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?

If I assume for a moment that the Debian LTS guys (I'm not affiliated
and did not speak to anyone) continue to support at least bookworm
including i386, that would give you roughly another five years of
support for those i386 devices. So can we add that timeframe
as well to our consideration, and ask ourselfs if there is a need
for fresh Debian installations on i386 five years from now?
Assuming the device from 2008 that would correspond to a lifetime
of around 20 years by then.

As much as I love the idea of some small device still humming along
five years from now, it sounds more likely that either the device
will die, or you replace it anyway with some other spare device.
Yeah I know stories of forgotten systems somewhere in a corner of
a room, but maybe we can stick to more common cases.

If the i386 support without an installer is kept for another release,
maybe that extends the support for existing installations even further.
That would only add some burden for fresh installations to install
bookworm first, and upgrade later on. At that point I guess we could
start to talk about retro computing if it's still running on i386. :)

Sven

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Sven Hoexter]

On Wed, May 31, 2023 at 01:00:42PM +0200, Alexandre Detiste wrote:

Hi,

> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more

The question is: Is that a target for a future Debian installation and/or
a target for a recent Debian release?
It sounds more like cases which require a certification of some kind, and are
more likely to stay on very old releases for a long a time anyway (which
sometimes is problematic in different ways). It's likely the owner of such
long running device must now think about the plans for Y2038 anyway.

Sven

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[John Goerzen]

On Tue, May 30 2023, Steve Langasek wrote:

> For businesses, the transition from 32-bit to 64-bit was several
> depreciation cycles ago.
>
> In my city, there is a non-profit that accepts donations of old computers,
> refurbishes them, installs Linux, and both sells them and provides them free
> to people in need.
>
> They receive x86-64 systems that they determine are *too old to be worth
> refurbishing* and they e-cycle them.
>
> Hanging on to systems using power-hungry chips from 20 years ago instead of
> intercepting a system such as this is not reducing the number of computers
> that end up in the waste stream, it just keeps you stuck with a more
> power-hungry system.

I still have several Asus EeePCs (Atom N270 which had a TDP of 2.5W)
from around 2008ish.  One of them is in active use as an amateur radio
digipeater, while the others see occasional use.  These don't support a
64-bit instruction set but are perfectly servicable for certain use
cases.

I understand that a 9" screen and an Atom isn't going to be suitable for
the segment of the population that wants to use it for modern web
browsing and video calling, so I understand why your nonprofit is doing
that.

I wouldn't buy a used EeePC today.  Still, I see no reason to contribute
to the waste and carbon stream by replacing these perfectly usable
machines with something newer.  Capability-wise, they are roughly
similar to a Raspberry Pi, but they have the added benefit of a screen,
keyboard, and battery all integrated in a small device.

Not everything from that age was power-hungry.

I guess the question is: is this use case too niche for Debian to
continue supporting?  I would suggest that as long as we have 32-bit
ARM, are the challenges for 32-bit x86 really worse?

- John

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Alexandre Detiste]

Le mer. 31 mai 2023 à 12:44, Wouter Verhelst  a écrit :
> 20+ year old machines are typically more power hungry, more expensive,
> less performant, and less reliable than an up-to-date raspberry pi.

Embedded systems and medical one can be crazily expensive to maintain
and even more to replace but some will run on i386 for a long time more
(had to manage some still running on DOS recently ...),
there's also much of amd64 HW running on i386 because of lazyness/cost
for hybrid fleets; energy efficiency is there the least of concerns.

Some things _do_ start to fall apart: some nasty memory corruption bug in nginx
that only shows up on i386 code path ... :-(

Greetings

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.
[...]
> It's absolutely true that modern machines are more energy efficient. What is 
> also true is that the production of new devices has a big environmental 
> impact. 

20+ year old machines are typically more power hungry, more expensive,
less performant, and less reliable than an up-to-date raspberry pi. If
you want to support people who can't afford shiny new hardware, I think
pointing them to raspberry pi-class hardware is a better idea than
trying to recycle old hardware. As such, I don't think "but old hardware
is still used" is a very good argument for keeping i386 around.

If they can afford 10 year old hardware, the situation is different; but
no 10 year old hardware that is worth recycling does not support x86-64.

I'm not saying we shouldn't support old hardware at all -- I fought for
a long time to keep m68k hardware a supported architecture in Debian --
but this is not the best argument for it, IMO.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

If there's a well-supported social or technical reason to remove the
i386 Debian installer, I think that it would still be disappointing,
but acceptable.

I don't know what those reasons are yet (I've imagined that they could
be maintainer burden -- but as mentioned, I don't think there's much
compiled-binary or i386-specific support required within d-i itself;
key packages etc yes, but the installer itself, I'm less sure), and I
still think that the strongest indicator of usage would probably be
download statistics for i386 ISO images (in other words: are many
people still requesting them?).

Looking ahead, I think it would be good to try to figure out ways to
avoid some of the frustrations caused by technological platform
shifts.  Yes, we probably learned some things collectively during each
of those transitions, but also, the 40-year-or-so old computer that I
have on a side table could be used for word processing, creating
shopping lists, and probably saving and searching fairly large lists
of food recipes (some of the tasks that I now use a much more powerful
laptop for).

The economic impact can either be phrased as an opportunity (hardware,
software sales) and/or as a burden (finding new equipment, discovering
incompatibilities, re-learning how to perform similar tasks using
different systems.  how much the vendor cares can also make a
difference with each of these).  Some amount of diversity in systems
allows for comparison and improvement (maybe one design team -- or
even one designer -- found a technique that applies to their system
that makes it much more efficient at some workloads; that discovery
can then be shared and adapted by others).

The argument that people can still install manually using debootstrap
or other methods is kinda fine - although in the same way that I like
to refactor code so that there are fewer 'if' conditions and
workarounds for particular situations (and to work towards removing
those if conditions by fixing adjacent/surrounding components and then
gradually updating when possible), we should be aware that there are
communication (users, documentation) and comprehension (keeping
per-architecture limitations in mind) overheads when creating
additional tiers/partitions of support and functionality.

So in summary: probably fine, some i386 ISO download stats would be
nice, and is there a particular key package or packages that are
causing problems here?

On Wed, 31 May 2023 at 05:55, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi,
>
> Quoting Diederik de Haas (2023-05-31 00:51:06)
> > > If people have strong opinions about that plan, let us know please.
> >
> > I have *strong* opinions about this.
> >
> > https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> > plea to not forget about supporting OLD systems.
> >
> > While it may be a no-brainer for a person with a $/€ 1000 a month residual
> > income to just buy new hardware whenever they feel like it, that is not the
> > case for everyone.
>
> I think that depends on where you live. As Steve has said, if you live in a
> place with tons of rich people around, so many "old" computers are discarded 
> by
> them that it's not a problem for anybody to get hold of one of those for near
> to nothing. People with too much money just go through way too many computers
> per year, thereby creating a vast amount of old but still usable computers. At
> my university I recently saw a whole container filled with "old" desktop
> machines to be discarded (systems from 10 years ago, so definitely 64bit
> machines). This is just disturbing in my opinion but hey, those old systems
> don't run the most recent MS Windows anymore...
>
> This situation is probably very different around the world and I guess there
> are many places where it is very hard to get hold of a machine younger than a
> decade? Are you talking about those places?
>
> > Besides people in 'third world countries' (I actually don't like such
> > qualifications at all), there are also people in the '1st world' who work
> > their asses off just to put food on the table, and thus also don't have the
> > money to buy new equipment. But if you want to interact with your own
> > government, you highly likely will need to have some PC (type) equipment.  
> > It
> > could also provide a way to learn/develop new skills.
>
> In my own "1st world" country I know a number of people in that situation and
> at least over here, a "computer" doesn't help them to do the daily life 
> things.
> They need a smartphone to stay connected with their employer via Whatsapp or
> download the apps to participate in the things everybody else participates in.
> In Germany they just rolled out a monthly ticket for trains and buses for the
> whole country which will be smartphone-only starting next year -- will a 
> person
> with less income invest in a new/old desktop machine or in a smartphone new
> enough to run such an app? Yes, this is another discussion but I also do not
> 

Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Diederik de Haas (2023-05-31 00:51:06)
> > If people have strong opinions about that plan, let us know please.
> 
> I have *strong* opinions about this.
> 
> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.
> 
> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.

I think that depends on where you live. As Steve has said, if you live in a
place with tons of rich people around, so many "old" computers are discarded by
them that it's not a problem for anybody to get hold of one of those for near
to nothing. People with too much money just go through way too many computers
per year, thereby creating a vast amount of old but still usable computers. At
my university I recently saw a whole container filled with "old" desktop
machines to be discarded (systems from 10 years ago, so definitely 64bit
machines). This is just disturbing in my opinion but hey, those old systems
don't run the most recent MS Windows anymore...

This situation is probably very different around the world and I guess there
are many places where it is very hard to get hold of a machine younger than a
decade? Are you talking about those places?

> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work
> their asses off just to put food on the table, and thus also don't have the
> money to buy new equipment. But if you want to interact with your own
> government, you highly likely will need to have some PC (type) equipment.  It
> could also provide a way to learn/develop new skills.

In my own "1st world" country I know a number of people in that situation and
at least over here, a "computer" doesn't help them to do the daily life things.
They need a smartphone to stay connected with their employer via Whatsapp or
download the apps to participate in the things everybody else participates in.
In Germany they just rolled out a monthly ticket for trains and buses for the
whole country which will be smartphone-only starting next year -- will a person
with less income invest in a new/old desktop machine or in a smartphone new
enough to run such an app? Yes, this is another discussion but I also do not
think your argument applies well to "1st world" countries because of this
reason and the reasons I gave above.

> It's absolutely true that modern machines are more energy efficient. What is
> also true is that the production of new devices has a big environmental
> impact.
> 
> https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> > The European Environmental Bureau has stated that extending the lifespan of
> > smartphones and other electronics by just one year would save the EU as
> > much carbon emissions as taking two million cars off the roads annually.
> 
> I would be VERY disappointed if Debian would abandon people who do NOT have
> the means to just buy new equipment whenever they feel like it.

That argument goes both ways. You could also say that for people with less
income, the electricity costs make using a more modern system cheaper for them.

This of course does not negate the environmental argument but the environmental
argument is a tricky one. A 20 year old machine bought 20 years ago will have
racked up a lot of electricity usage which pales against the energy required to
build and run small single-board machines that are similarly powerful built
today. There is a cut-off point where using an energy-hungry old system *does*
have a higher environmental impact than building a small new system.

> Especially when I see various proposals to make the 'life'/work of companies
> who make BILLIONS a YEAR, easier.  (I'll leave my moral objections to several
> of those aside this time)
> 
> Cheers,
>   Diederik
> 
> PS: Nothing in here should be taken as a personal attack, but as I said I 
> feel 
> rather strongly about this subject. (And communication isn't my strong suit)

There are probably many places in the world where your argument applies well.
Remember though, that this is also a person-power problem. If we can find many
more people interested to keep 20 year old systems alive by working on that in
their free-time, I do not think we would have this discussion. A lot of work is
required to keep an architecture and its installer alive. I suspect kibi would
*love* more hands helping maintain d-i. There will always be someone with real
reasons for using 20 year old systems and wanting to do a fresh installation on
one. The question is, is this worth our free-time or should we do other things
instead? Who is having fun doing that?  We can argue a lot about the social and
environmental reasons for supporting 20 year old systems but the sad fact of
the matter is: if there is nobody there doing the work then that discussion is

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve Langasek]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > >+1 for stopping publishing installers for i386, it has been mentioned
> > >many times but it's always worth repeating: electricity costs to keep
> > >running i386 hardware are already way higher than what it costs to buy
> > >a cheap, low-power replacement like a raspberry pi, that also provides
> > >better performance.

> > Exactly.
> > ...
> > If people have strong opinions about that plan, let us know please.

> I have *strong* opinions about this.

> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.

> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.

> To quote (a part) of that email:
> > I happen to know of a few derivative projects that have been using
> > Debian technology that have brought new life to some really aging equipment
> > and some people in either Third World countries or in communities with low
> > incomes and either limited or non-existent access to modern equipment. One
> > such effort, the antiX distribution, has been effective in reaching poor
> > communities in Brazil recently, and has long been able to reach people with
> > scaled down Debian technology all over the world.
> >
> > I'm wondering if there is some way to provide a "hook" or a way for some of
> > these ten to twenty year old systems to remain functional for those who may
> > not otherwise have a way, other than to run insecure, out of date systems. 
> > If there is a way, even a "side project", I hope that the Debian community
> > can help a few of these derivative distributions assist people worldwide to
> > have access to modern technology,
> > even from systems that are barely "modern" any more.

> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work
> their asses off just to put food on the table, and thus also don't have
> the money to buy new equipment.  But if you want to interact with your own
> government, you highly likely will need to have some PC (type) equipment. 
> It could also provide a way to learn/develop new skills.

> It's absolutely true that modern machines are more energy efficient. What is 
> also true is that the production of new devices has a big environmental 
> impact. 

> https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> > The European Environmental Bureau has stated that extending the lifespan of
> > smartphones and other electronics by just one year would save the EU as
> > much carbon emissions as taking two million cars off the roads annually.

> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

> Especially when I see various proposals to make the 'life'/work of companies 
> who make BILLIONS a YEAR, easier.
> (I'll leave my moral objections to several of those aside this time)

For businesses, the transition from 32-bit to 64-bit was several
depreciation cycles ago.

In my city, there is a non-profit that accepts donations of old computers,
refurbishes them, installs Linux, and both sells them and provides them free
to people in need.

They receive x86-64 systems that they determine are *too old to be worth
refurbishing* and they e-cycle them.

Hanging on to systems using power-hungry chips from 20 years ago instead of
intercepting a system such as this is not reducing the number of computers
that end up in the waste stream, it just keeps you stuck with a more
power-hungry system.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

[Please CC me in replies as I'm not subscribed to this list]

I hope I'm not too late for this discussion ...

Steve McIntyre  wrote:
> Luca Boccassi wrote:
> >On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
> >> I'm planning on stopping publishing installer images for i386
> >> soon. Why? We should be strongly encouraging users to move away from
> >> If they're still running i386 *hardware*, then they should be replacing
> >> that hardware with more modern, more capable, more *efficient* stuff.
> >> 
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to buy
> >a cheap, low-power replacement like a raspberry pi, that also provides
> >better performance.
> 
> Exactly.
> ...
> If people have strong opinions about that plan, let us know please.

I have *strong* opinions about this.

https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
plea to not forget about supporting OLD systems.

While it may be a no-brainer for a person with a $/€ 1000 a month residual 
income to just buy new hardware whenever they feel like it, that is not the 
case for everyone.

To quote (a part) of that email:
> I happen to know of a few derivative projects that have been using
> Debian technology that have brought new life to some really aging equipment
> and some people in either Third World countries or in communities with low
> incomes and either limited or non-existent access to modern equipment. One
> such effort, the antiX distribution, has been effective in reaching poor
> communities in Brazil recently, and has long been able to reach people with
> scaled down Debian technology all over the world.
>
> I'm wondering if there is some way to provide a "hook" or a way for some of
> these ten to twenty year old systems to remain functional for those who may
> not otherwise have a way, other than to run insecure, out of date systems. 
> If there is a way, even a "side project", I hope that the Debian community
> can help a few of these derivative distributions assist people worldwide to
> have access to modern technology,
> even from systems that are barely "modern" any more.

Besides people in 'third world countries' (I actually don't like such 
qualifications at all), there are also people in the '1st world' who work their 
asses off just to put food on the table, and thus also don't have the money to 
buy new equipment. But if you want to interact with your own government, you 
highly likely will need to have some PC (type) equipment.
It could also provide a way to learn/develop new skills.

It's absolutely true that modern machines are more energy efficient. What is 
also true is that the production of new devices has a big environmental 
impact. 

https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> The European Environmental Bureau has stated that extending the lifespan of
> smartphones and other electronics by just one year would save the EU as
> much carbon emissions as taking two million cars off the roads annually.


I would be VERY disappointed if Debian would abandon people who do NOT have 
the means to just buy new equipment whenever they feel like it.

Especially when I see various proposals to make the 'life'/work of companies 
who make BILLIONS a YEAR, easier.
(I'll leave my moral objections to several of those aside this time)

Cheers,
  Diederik

PS: Nothing in here should be taken as a personal attack, but as I said I feel 
rather strongly about this subject. (And communication isn't my strong suit)

signature.asc
Description: This is a digitally signed message part.

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Helmut Grohne]

Hi Steve,

On Wed, May 17, 2023 at 10:39:21PM -0700, Steve Langasek wrote:
> > I note that this may pose problems with intra-library interaction. Say
> > we need to enable time64 on a higher level library and a lower level
> > library does not use time_t, but uses off_t. As such, you'd opt out of
> > lfs on the lower level library, but the upper one uses it with lfs by
> > having enabled time64. How do you intend to deal with such cases?
> 
> In such a case the lower-level library should opt in to lfs and have a
> package name change as well.  Up to this point I've casually assumed there
> weren't any such packages, but this can also be detected via static analysis
> of the archive.

Did you encounter such cases in your updated analysis?

> > Something that would help with this transition would be a
> > checker-as-a-service kind of thing that indicates:
> >  * Is my package affected by time64?
> >  * Does my package enable time64?
> >+ On i386?
> >  * Do time64 changes affect downstream packages?
> >+ Which?
> 
> > I understand that answering these questions on a per-package basis is
> > far from trivial. That much is evident from your analysis. I think this
> > is ok. Even if such a service says "unknown" 10% of the time, that'd
> > still be very useful. Do you think you could turn your analysis into a
> > continuous checking service?
> 
> This sounds like a substantial amount of work (and computing resources, to
> enable this to "continuously" check) and I don't think I understand how it
> would help the transition, if all of the library transitions are being
> coordinated centrally.  Could you elaborate?

I'm not sure how this would look like exactly. I see some options:
 + The lists that already exist describe the second level of
   affectedness (changes ABI) already.
 + A double-rebuild varying time64 could employ reproducible builds to
   judge affectedness (generally) and we would get a list of unaffected
   packages in particular.
 + If we enable this via dpkg, .buildinfo files can be used to track how
   many packages have been rebuilt with time64 (given that ben will not
   always see a difference).
 + Finally the benfile you proposed may also help to judge this.

I don't yet quite see how this transition can accurately be tracked
using ben, but I'm hoping for a positive surprise here. Failing that,
fusing some of these information sources into a continously updated view
would improve our understanding of how far this went.

I agree that the amount of work to spend on such tracking needs to be
balanced. In effect, we practically do want to rebuild much of the
archive here and while some of that will cause dependency changes, there
are enough examples that will be invisible to ben to justify a bit more
tracking effort here in my view. I hope you can agree with this view.

Helmut

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 26 May 2023 at 00:27, Roger Lynn  wrote:
>
> On 21/05/2023 07:00, James Addison wrote:
> > On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
> >> One of the problems with popcon is that it draws too much attention to
> >> old releases which isn't really interesting when talking about future
> >> developments.  If one looks at arch usage per release (as reported to
> >> popcon) one gets this table:
> >>
> >> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
> >> |++-++--+--|
> >> | alpha  |  1 | ||  |4 |
> >> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
> >> | arm64  ||   1 | 93 |  937 |  203 |
> >> | armel  | 21 |  47 | 67 |   68 |   10 |
> >> | armhf  |  7 |  18 |216 |  429 |   49 |
> >> | hppa   || ||  |8 |
> >> | hurd-i386  || ||4 |6 |
> >> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
> >> | ia64   || ||  |3 |
> >> | kfreebsd-amd64 |  2 | ||  |  |
> >> | m68k   ||   1 ||  |4 |
> >> | mips   |  2 | |  6 |  |  |
> >> | mips64el   || |  6 |4 |  |
> >> | mipsel |  2 |   1 |  7 |  |  |
> >> | powerpc| 13 |   1 |  1 |1 |   18 |
> >> | ppc64  || ||1 |   28 |
> >> | ppc64el||   5 | 16 |  |   12 |
> >> | riscv64|| ||  |   15 |
> >> | s390x  || ||8 |3 |
> >> | sh4|| ||  |1 |
> >> | sparc64|| ||  |   11 |
> >> | x32|| ||  |2 |
> >> |++-++--+--|
> >> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
> >> #+TBLFM: @>$2..@>$>=vsum(@I..II)
> >>
> >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
> >> Also interesting is that arm64 has taken over i386 on bookwork/sid.
> >>
> >> We don't know how many people downloaded i386 instead of amd64 as they
> >> have an Intel CPU.
> >>
> >> What is also not clear is the bias of systems having popcon enabled at
> >> all (it seems to be mostly desktop systems) and how it looks on the
> >> total population.
> >
> > Thanks, those are better statistics (and good notes about their 
> > limitations).
> >
> > I may be playing devil's advocate, but I do also read from those that
> > the i386 install-base, even dwindled as it has to ~1%, remains more
> > popular than many other architectures (within whatever dimension of
> > users enable popcon) where we do provide install images, and then that
> > those users tend to upgrade to the latest i386 release of Debian that
> > they can -- and/or that despite the percentage-of-total trend
> > reducing, the absolute population of those i386 users is growing (I
> > guess the former is the larger contributing factor, but it's hard to
> > determine from the numbers only).
>
> The popcon graphs clearly show that the absolute number (not proportion) of
> i386 reports flattened off in 2008 at about 65000, when AMD64 became
> popular. The number of i386 reports has been falling since 2014, and is now
> about 1, most of which are from old releases (oldstable or older). It
> seems likely that the number of i386 reports from stable will be overtaken
> by ARM64 during the period of Bookworm.

Thanks Roger.  I concede that the absolute number of i386 popcon
reports has been falling; this graph makes that clear[1]:
https://web.archive.org/web/20221223090933/https://popcon.debian.org/stat/sub-i386.png

Also, yep, it does seem possible that i386's position in terms of
total popcon reports could fall into third place behind AMD64 and
ARM64 over the next two years or so.

Is an architecture's ranking position within popcon reports a
significant factor in whether it should be installer-supported?  Or is
it perhaps only a secondary indicator and there are other
considerations that are more important?  (for example, whether we have
volunteers keen to support it..)


An aside: the trend for ARM64 reports appears to include a few steep
increments followed by pauses.  I'm left wondering whether those
correspond to additional hardware support, arrival of popular packages
in the ARM64 archive, or other factors[2]:

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Roger Lynn]

On 21/05/2023 07:00, James Addison wrote:
> On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
>> One of the problems with popcon is that it draws too much attention to
>> old releases which isn't really interesting when talking about future
>> developments.  If one looks at arch usage per release (as reported to
>> popcon) one gets this table:
>>
>> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
>> |++-++--+--|
>> | alpha  |  1 | ||  |4 |
>> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
>> | arm64  ||   1 | 93 |  937 |  203 |
>> | armel  | 21 |  47 | 67 |   68 |   10 |
>> | armhf  |  7 |  18 |216 |  429 |   49 |
>> | hppa   || ||  |8 |
>> | hurd-i386  || ||4 |6 |
>> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
>> | ia64   || ||  |3 |
>> | kfreebsd-amd64 |  2 | ||  |  |
>> | m68k   ||   1 ||  |4 |
>> | mips   |  2 | |  6 |  |  |
>> | mips64el   || |  6 |4 |  |
>> | mipsel |  2 |   1 |  7 |  |  |
>> | powerpc| 13 |   1 |  1 |1 |   18 |
>> | ppc64  || ||1 |   28 |
>> | ppc64el||   5 | 16 |  |   12 |
>> | riscv64|| ||  |   15 |
>> | s390x  || ||8 |3 |
>> | sh4|| ||  |1 |
>> | sparc64|| ||  |   11 |
>> | x32|| ||  |2 |
>> |++-++--+--|
>> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
>> #+TBLFM: @>$2..@>$>=vsum(@I..II)
>>
>> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
>> Also interesting is that arm64 has taken over i386 on bookwork/sid.
>>
>> We don't know how many people downloaded i386 instead of amd64 as they
>> have an Intel CPU.
>>
>> What is also not clear is the bias of systems having popcon enabled at
>> all (it seems to be mostly desktop systems) and how it looks on the
>> total population.
> 
> Thanks, those are better statistics (and good notes about their limitations).
> 
> I may be playing devil's advocate, but I do also read from those that
> the i386 install-base, even dwindled as it has to ~1%, remains more
> popular than many other architectures (within whatever dimension of
> users enable popcon) where we do provide install images, and then that
> those users tend to upgrade to the latest i386 release of Debian that
> they can -- and/or that despite the percentage-of-total trend
> reducing, the absolute population of those i386 users is growing (I
> guess the former is the larger contributing factor, but it's hard to
> determine from the numbers only).

The popcon graphs clearly show that the absolute number (not proportion) of
i386 reports flattened off in 2008 at about 65000, when AMD64 became
popular. The number of i386 reports has been falling since 2014, and is now
about 1, most of which are from old releases (oldstable or older). It
seems likely that the number of i386 reports from stable will be overtaken
by ARM64 during the period of Bookworm.

Roger

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Mon, May 22, 2023 at 06:24:53PM -0700, Steve Langasek wrote:
> > We don't need to enable/fix it for everything though.  A rebuild check of
> > affected libraries to see how much work this adds would be a good idea.

> Isn't it a problem not just for library ABIs but also for any other packages
> rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit
> prototype from the headers but using the 32-bit symbol at runtime?

To clarify: not every package will be affected by this because not every
package is going to use the libc time_t functions.  But enough will that I
think the better path forward is to enable
-Werror=implicit-function-declaration across the board and fix any build
failures, which makes for better code in the long run anyway, than to enable
this by hand only for affected libraries and then have to deal with a bunch
of runtime bugs.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Sat, May 20, 2023 at 12:28:41PM +0100, Wookey wrote:
> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.

> So having re-read that, if I understand this correctly, we do need to
> be mindful that software which looks up functions or function
> parameters in unusual ways (e.g. cross-language Foreign Function
> Interfaces, or using implicit declarations) is likely to get the
> wrong-size definition (because glibc makes both versions available).

> So we should enable -Wimplicit-function-declaration on libraries being
> rebuilt because their ABIs changed.

I guess this needs to be -Werror=implicit-function-declaration, to ensure it
fails the build if used, regardless of whether -Werror is set elsewhere?

> We don't need to enable/fix it for everything though.  A rebuild check of
> affected libraries to see how much work this adds would be a good idea.

Isn't it a problem not just for library ABIs but also for any other packages
rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit
prototype from the headers but using the 32-bit symbol at runtime?

(Which is a better answer in terms of automation, because then we can just
put it in dpkg-buildflags)

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:

> > The proposal is to treat this as a flag day, where the toolchain (in this
> > case, dpkg-buildflags) changes, then we upload the affected libraries in a
> > short period of time, then once they're built and through new we rebuild the
> > reverse-dependencies.  This is basically the same approach as was used for
> > past ABI transitions (ldbl, c102, c2) with the only difference here that the
> > change triggering the flag day would be in dpkg rather than gcc(-defaults).

> > There could be some misbuilt binaries in unstable if the maintainer uploads
> > them after dpkg is uploaded, but before the libraries are built.  If we
> > uploaded all of the library packages to set DEB_BUILD_MAINT_OPTIONS =
> > feature=+time64 we would avoid this race, but it would mean more
> > non-scriptable changes to debian/rules which I would rather avoid, and this
> > didn't prove necessary in past transitions; the impact of any misbuilt
> > binaries would be short-lived as they would be replaced ASAP with binNMUs.

> Given the potential amount of libraries involved that would need an
> upload and the chokepoint in NEW, to me this seems like a big window
> of opportunity for unstable users that might not be following along
> to get a broken system (I mean yes «unstable» and all that, but if it
> can be avoided?).

Some options that I can see here:

- Do the NEW processing in experimental first.  In order to avoid additional
  per-source changes that should be cleaned up later, if we go that route I
  suggest doing it with an intentionally-incorrect ABI (i.e.: no versioned
  build-dep on dpkg and no manual enabling with DEB_BUILD_MAINT_OPTIONS).
- Get a committment from the ftp team to prioritize binary NEW review for
  this transition (and without blocking on unrelated source issues, such as
  buggy debian/copyright...) so that these can all be accepted in a fairly
  narrow window

> Enabling time64 explicitly is what also had first come to my mind,
> which does not seem too onerous if all the debhelper override
> disappears? :) Then NEW processing could be done in one go to let the
> flood gates open at a specific coordinated date and time range (or
> staged via NEW into experimental, then mass uploaded to unstable to
> reduce the pressure on the ftpmaster(s) having to approve those), at
> which point dpkg could also be uploaded with the default switched.

The difference in my view is that the changes to handle Provides: are
something that should persist in the packaging (until the next soname
change, at which point it's easy to handle as part of the overall renaming),
whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
something that ideally would be dropped immediately after dpkg-buildflags is
updated, and could (though unlikely) be a source of bugs later.  I'd prefer
to avoid any transition plan which means I should be NMUing all of the
affected library packages twice.

> Another option, perhaps, could be to flip the defaults, but then block
> uploads for affected packages using
> , which I think the
> release team controls?

I wasn't familiar with this interface, but it sounds like a good option - I
can easily provide the list of source packages to populate it with.

> But, if people in general are not bothered about this transitory
> breakage, and say, an announcement is considered enough, then sure
> I guess.


> If the other concern is that this would make Ubuntu's life harder due
> having chosen to keep i386 as such compat arch, I don't see why the
> Ubuntu vendor code in dpkg could not disable the switch for i386 there.

We would certainly do this in Ubuntu no matter what decision Debian takes. 
I am advocating it in Debian because I think it is the right thing for
Debian to do as well.

Either way, we will need to come to some sort of decision about what to do
on i386 before we can move forward.  How should we reach that decision?  Are
you persuaded by the arguments presented in this thread?

> Hmm, rechecking the script, I think we'd want to at least
> unconditionally add the Breaks and Replaces (no need for substvars
> then), otherwise we'd get upgrade errors?

> That would leave only the Provides as potentially conditional…

You're absolutely right, thanks for catching this!  Fixed in git.

> > And btw, given the analysis that there are likely < 100 shared libraries
> > overall whose ABI changes when enabling LFS, this might be a change we want
> > to consider in the trixie cycle as well - just preferably not bundled with
> > the time_t transition at the same time, as that would just cause more delays
> > for testing migration vs splitting the two transitions.

> If the plan is to go with a flag day by switching the default for
> time64, then I don't see how the LFS change can be decoupled, as that
> automatically will also forcibly enable LFS globally on glibc arches.
> I've 

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Jonathan Carter]

Hi Simon

On 2023/05/19 17:30, Simon McVittie wrote:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
configure it as a multiarch foreign architecture on an amd64 system,
and run legacy Linux i386 binaries directly or legacy Windows i386
binaries via Wine

2. same as (1), plus basic utilities (coreutils, etc.) and optionally an
init system, to be able to make a pure i386 container or chroot
that can run on an externally-provided amd64 kernel

3. same as (2), plus kernel, bootloader and init system to be able to:
(a) construct a complete bootable installation using debootstrap or
similar;
(b) upgrade existing i386 installations


All of the above sounds reasonable, all those options acknowledge that 
we need some method to support a subset of packages for an architecture. 
It would be nice to see this extend to more than just 32bit x86. A while 
back someone from release team mentioned to me that they toyed with the 
idea of adding a new 32bit x86 architecture for Debian that's called 
i686 instead (and enable things that might not actually work on actual 
32bit binary), so it would really just be for 
compatibility/containers/etc, and then dropping the entire i386 
architecture completely. Not sure how viable that is in practice, but it 
sounds like a good idea.



4. user-facing media like debian-installer and Debian Live


I think we already have broad enough consensus that we don't need this. 
If there's enough Debian binaries to make that happen, and a user who 
has a niche enough use case for that, then they should have no problem 
just performing a local debootstrap install themselves.


-Jonathan

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Florian Lohoff]

On Wed, May 17, 2023 at 01:45:10PM +0800, YunQiang Su wrote:
> For mipsel, we have one more thing to do:
> - NaN2008 vs NaN legacy
> So I'd prefer rebootstrap (only for mipsel).
> And In fact we did it: https://repo.oss.cipunited.com/debian/

I am also rebuilding Debian/mipsel from stretch on for mips2 as the
mips32 transition unnecessarily dropped 70% of the available machines under
the bus in preference of some rare species.

So in "rebootstrapping" which might want to change the debian
architecture name as this is getting pretty confusing. The Debian/mipsel
of today is not what we had when i initiated that Port 20 years ago.

Flo
-- 
Florian Lohoff f...@zz.de
  Any sufficiently advanced technology is indistinguishable from magic.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
>
> On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> > Do we know how often the i386 installer is downloaded compared to
> > amd64, and could/should we start with updated messaging where those
> > are provided before removing users' ability to install on their
> > systems?
> >
> > (i386 remains the second-most-popular architecture behind amd64 today
> > going by popcon[1] stats - perhaps a lot of that is people using i386
> > as a compatibility architecture only, but it'd be nice to be
> > reasonably confident about that)
>
> One of the problems with popcon is that it draws too much attention to
> old releases which isn't really interesting when talking about future
> developments.  If one looks at arch usage per release (as reported to
> popcon) one gets this table:
>
> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
> |++-++--+--|
> | alpha  |  1 | ||  |4 |
> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
> | arm64  ||   1 | 93 |  937 |  203 |
> | armel  | 21 |  47 | 67 |   68 |   10 |
> | armhf  |  7 |  18 |216 |  429 |   49 |
> | hppa   || ||  |8 |
> | hurd-i386  || ||4 |6 |
> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
> | ia64   || ||  |3 |
> | kfreebsd-amd64 |  2 | ||  |  |
> | m68k   ||   1 ||  |4 |
> | mips   |  2 | |  6 |  |  |
> | mips64el   || |  6 |4 |  |
> | mipsel |  2 |   1 |  7 |  |  |
> | powerpc| 13 |   1 |  1 |1 |   18 |
> | ppc64  || ||1 |   28 |
> | ppc64el||   5 | 16 |  |   12 |
> | riscv64|| ||  |   15 |
> | s390x  || ||8 |3 |
> | sh4|| ||  |1 |
> | sparc64|| ||  |   11 |
> | x32|| ||  |2 |
> |++-++--+--|
> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
> #+TBLFM: @>$2..@>$>=vsum(@I..II)
>
> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
> Also interesting is that arm64 has taken over i386 on bookwork/sid.
>
> We don't know how many people downloaded i386 instead of amd64 as they
> have an Intel CPU.
>
> What is also not clear is the bias of systems having popcon enabled at
> all (it seems to be mostly desktop systems) and how it looks on the
> total population.

Thanks, those are better statistics (and good notes about their limitations).

I may be playing devil's advocate, but I do also read from those that
the i386 install-base, even dwindled as it has to ~1%, remains more
popular than many other architectures (within whatever dimension of
users enable popcon) where we do provide install images, and then that
those users tend to upgrade to the latest i386 release of Debian that
they can -- and/or that despite the percentage-of-total trend
reducing, the absolute population of those i386 users is growing (I
guess the former is the larger contributing factor, but it's hard to
determine from the numbers only).

Meanwhile my understanding is that most of the i386 installer package
-- although I referred to it as a binary package in another thread,
using the source/binary package naming terminology -- is mostly shell
scripting and architecture-independent logic.

So I guess I will ask: is there a technical reason we want to drop d-i
images on i386, or is it primarily about trying to reduce our
anticipated support burden for one architecture?

(and if people clamoured for an i386 installer to download, would we
reverse the decision?)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Andreas Metzler]

On 2023-05-20 Wookey  wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."

>> Has that issue been considered here? (I can't speak intelligently on it at
>> this time. I just want to make sure it's on your radar.)

> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another transition into this one). Thanks for the reminder.
[...]

Hello,

There is an ongoing Fedora project by Florian Weimer which includes this
issue.

https://fedoraproject.org/wiki/Changes/PortingToModernC

Not sure whether there is a similar effort for Debian but it should help
a lot, everything with active upstream that is packaged by Fedora will
be fixed.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Sat, 20 May 2023 at 09:39, Cyril Brulebois  wrote:>
> James Addison  (2023-05-20):
> > Replying individually, but may bring this back on-list depending on
> > what I learn:
> >
> > On Sat, 20 May 2023 at 06:00, Cyril Brulebois  wrote:
> > >
> > > If you're concerned about the impact of no longer producing installation
> > > images for this use case, you shouldn't. Building netinst, CD, DVD, BD,
> > > etc. images happens via debian-cd
>
> Stopping that is the plan.
>
> > > using artifacts produced by a src:debian-installer build, which are stored
> > > under installer-/ directories in the archive. Those wouldn't go away
> > > in this scenario.
> > >   http://ftp.debian.org/debian/dists/bookworm/main/installer-i386/
> >
> > I'm confused: I thought Steve's suggestion was exactly that these i386
> > installer builds would no longer occur after the bookworm release.
> >
> > Did I misunderstand the plan?
>
> I suppose so?

Ok, thanks.  I was uncertain what you were referring to with "Those
wouldn't go away" - and that potentially raised conflicts with my
reading of Steve's suggestion.

Updated understanding:

  * planned to go away: Debian-distributed images as built using
debian-cd for i386 (where the images include: debian-installer + a
subset of packages from a Debian mirror + supporting stuff to provide
a complete installation environment).
  * _not_ planned to go away: standalone binary package builds of the
i386 debian-installer package itself in the archives.

And so the result should be: it'd still be possible for people to
build-their-own i386 ISO images by using the debian-cd tooling; there
won't be officially-distributed images provided by Debian, though.

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Wookey]

On 2023-05-17 20:14 -0500, Richard Laager wrote:
> 
> They mention, "We likely have to complete Modern C porting first to remove
> any instances of -Wimplicit-function-declaration otherwise the redirects in
> glibc for e.g. time->time64 won't actually work."

> Has that issue been considered here? (I can't speak intelligently on it at
> this time. I just want to make sure it's on your radar.)

I was aware of it (the gentoo info is linked on the 64bit-time wiki
page), but had not yet looked into how significant an issue this actually
was, so had not documented it. (frankly, I was hoping we could avoid
tying yet another transition into this one). Thanks for the reminder.

So having re-read that, if I understand this correctly, we do need to
be mindful that software which looks up functions or function
parameters in unusual ways (e.g. cross-language Foreign Function
Interfaces, or using implicit declarations) is likely to get the
wrong-size definition (because glibc makes both versions available).

So we should enable -Wimplicit-function-declaration on libraries being
rebuilt because their ABIs changed. We don't need to enable/fix it for
everything though. A rebuild check of affected libraries to see how
much work this adds would be a good idea.

I'll add this info the the wiki and do some tests.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Cyril Brulebois]

(2-in-1 reply.)

Ansgar  (2023-05-19):
> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> > Hmm.  I find the netboot installer archives very useful for rescue
> > purposes.  This sometimes involves PC hardware too old for amd64. I
> > PXE booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo
> > N410c - CD drive was part of the optional docking station) using a
> > bullseye netboot.tar not long ago.

If you're concerned about the impact of no longer producing installation
images for this use case, you shouldn't. Building netinst, CD, DVD, BD,
etc. images happens via debian-cd, using artifacts produced by a
src:debian-installer build, which are stored under installer-/
directories in the archive. Those wouldn't go away in this scenario.
  http://ftp.debian.org/debian/dists/bookworm/main/installer-i386/

If you're thinking about debian-installer--netboot-i386 binaries,
that would be the exact same story, since those are built by packing the
contents of those directories.

> You can keep using the bullseye netboot.tar for the next 20+ years to
> rescue boot an ancient system, copy the data off of it, and then
> responsibly dispose the system.

If the system to be rescued is older than the netboot being considered,
that should be possible. If it's newer, that might not be possible. See
what happened when we moved from LUKS to LUKS2: an older d-i couldn't
rescue a newer system because it just didn't know about the new format.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote:
> Based on the analysis to date, we can say there is a lower bound of ~4900
> source packages which will need to be rebuilt for the transition, and an
> upper bound of ~6200.  I believe this is a manageable transition, and
> propose that we proceed with it at the start of the trixie release cycle.

With more progress on making the headers analyzable, the lower bound is now
5063 and the upper bound is 5975 (not counting any entanglement with
lfs-sensitive libraries whose reverse-dependencies also depend on
time_t-sensitive libraries, that's still to be worked out).

In case that gives anyone more confidence in the plan :)

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> Do we know how often the i386 installer is downloaded compared to
> amd64, and could/should we start with updated messaging where those
> are provided before removing users' ability to install on their
> systems?
> 
> (i386 remains the second-most-popular architecture behind amd64 today
> going by popcon[1] stats - perhaps a lot of that is people using i386
> as a compatibility architecture only, but it'd be nice to be
> reasonably confident about that)

One of the problems with popcon is that it draws too much attention to
old releases which isn't really interesting when talking about future
developments.  If one looks at arch usage per release (as reported to
popcon) one gets this table:

| Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
|++-++--+--|
| alpha  |  1 | ||  |4 |
| amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
| arm64  ||   1 | 93 |  937 |  203 |
| armel  | 21 |  47 | 67 |   68 |   10 |
| armhf  |  7 |  18 |216 |  429 |   49 |
| hppa   || ||  |8 |
| hurd-i386  || ||4 |6 |
| i386   |   1318 |1231 |   1495 | 3042 |  168 |
| ia64   || ||  |3 |
| kfreebsd-amd64 |  2 | ||  |  |
| m68k   ||   1 ||  |4 |
| mips   |  2 | |  6 |  |  |
| mips64el   || |  6 |4 |  |
| mipsel |  2 |   1 |  7 |  |  |
| powerpc| 13 |   1 |  1 |1 |   18 |
| ppc64  || ||1 |   28 |
| ppc64el||   5 | 16 |  |   12 |
| riscv64|| ||  |   15 |
| s390x  || ||8 |3 |
| sh4|| ||  |1 |
| sparc64|| ||  |   11 |
| x32|| ||  |2 |
|++-++--+--|
| ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
#+TBLFM: @>$2..@>$>=vsum(@I..II)

where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
Also interesting is that arm64 has taken over i386 on bookwork/sid.

We don't know how many people downloaded i386 instead of amd64 as they
have an Intel CPU.

What is also not clear is the bias of systems having popcon enabled at
all (it seems to be mostly desktop systems) and how it looks on the
total population.

Ansgar

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Ansgar  writes:

> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
>> Hmm.  I find the netboot installer archives very useful for rescue
>> purposes.  This sometimes involves PC hardware too old for amd64. I PXE
>> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
>> drive was part of the optional docking station) using a bullseye
>> netboot.tar not long ago.
>
> You can keep using the bullseye netboot.tar for the next 20+ years to
> rescue boot an ancient system, copy the data off of it, and then
> responsibly dispose the system.

That won't work, will it?  netboot must match the kernel version in the
archive to be useful.  Or am I missing something?


> I don't think this is a good argument to keep generating i386 install
> media.

Maybe not.  Just wanted to mention the use case so it can be
considered. I understand that it might not justify the resources
required.



Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> Hmm.  I find the netboot installer archives very useful for rescue
> purposes.  This sometimes involves PC hardware too old for amd64. I PXE
> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
> drive was part of the optional docking station) using a bullseye
> netboot.tar not long ago.

You can keep using the bullseye netboot.tar for the next 20+ years to
rescue boot an ancient system, copy the data off of it, and then
responsibly dispose the system.

I don't think this is a good argument to keep generating i386 install
media.

> Not a major thing, but if you're going to keep most of i386 anyway...

I would hope we could eventually drop some expensive, useless packages
from i386 like src:linux.

Ansgar

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Steve McIntyre  writes:

> I had been thinking about doing similar for installer images too, but
> with other work going on too I think it got too late in the cycle to
> make that change. My plan is therefore to ship i386 installer images
> for bookworm as normal (including bookworm point releases going
> forwards), but to disable those builds for testing/trixie ~immediately
> after the release.

Hmm.  I find the netboot installer archives very useful for rescue
purposes.  This sometimes involves PC hardware too old for amd64. I PXE
booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
drive was part of the optional docking station) using a bullseye
netboot.tar not long ago.

Not a major thing, but if you're going to keep most of i386 anyway...


Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
>
> I'm planning on stopping publishing installer images for i386
> soon. Why? We should be strongly encouraging users to move away from
> it as a main architecture. If they're still installing i386 on 64-bit
> hardware, then that's a horrible mistake. If they're still running
> i386 *hardware*, then they should be replacing that hardware with more
> modern, more capable, more *efficient* stuff.

Do we know how often the i386 installer is downloaded compared to
amd64, and could/should we start with updated messaging where those
are provided before removing users' ability to install on their
systems?

(i386 remains the second-most-popular architecture behind amd64 today
going by popcon[1] stats - perhaps a lot of that is people using i386
as a compatibility architecture only, but it'd be nice to be
reasonably confident about that)

[1] - https://popcon.debian.org/

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Michael Biebl]

Am 19.05.23 um 19:23 schrieb Cyril Brulebois:

Hi,

Andrew M.A. Cater  (2023-05-19):

I'd honestly suggest *just* publishing DVD1 for i386.

Netinst requires internet access: DVD1 can be used to install a basic
system without this. Scrap *everything else* for i386 installation media.


I'm not sure how dropping one netinst ISO is going to change anything in
debian-cd: that's a very fast build, that's a small, single ISO, and not
having to download several GBs seems quite appealing to me. Having DVD1
only would really not seem acceptable to me.

I'm also very much *not* in favour of dropping images just *days* before
the release, without any kind of heads-up.



+1

That said, I also support the idea of dropping (at least) the installer 
media for i386 in trixie, so I like Ansgar's proposal of using the 
bookworm release notes to prepare our users for that.




OpenPGP_signature
Description: OpenPGP digital signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Guillem Jover]

Hi!

On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote:
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> >> > […], I'm also dubious about this, and introduces a special case
> >> > and complexity that does not seem warranted TBH. If this was the case it
> >> > would seem to me it would disallow SOVERSION bumps for example, which we
> >> > have never been concerned with.

Err, sorry the SOVERSION example does not make sense here, precisely
because in those cases the dependency system works for the user and
(in general) should let the old versions of those shared libraries
even if now obsolete packages be co-installed along the new versions.

> >The problem with obsolete packages is also shared by all other arches,
> >and for those and for local packages the dependency system works for
> >the user and should let them know whether they can upgrade or they
> >would need to remove such packages. For other local FOSS packages
> >they might just be able to rebuild them.
> >
> >Excluding i386 from this transition seems to me will pretty much
> >sentence it, and would also make it rather hard to perform that
> >transition cleanly going forward if people want to keep it alive. And
> >while Debian might eventually remove it from its official ports, we
> >have multiple old ports that are still maintained and used.
> >
> >If the main reason is to support non-free binaries, at least to me
> >that does not seem like a very compelling reason. And people can
> >always use old chroots or similar I guess?
> 
> i386 is in a really awkward situation here, I think. Nobody is working
> on it explicitly any more (AFAICS?),

I assume because it seems to "work" and people might have not seen the
need to jump in, compared to say if it was in ports.d.o, but I might be
wrong.

> but its history as by far the
> most common architecture means that:
> 
>  * we still have a (very!) long tail of installations using it
>  * there are *massively* more old binaries available for it, free,
>proprietary *and* locally-built
> 
> Moving forwards, we need to make a call on what we want i386 for. I
> was hoping to wait until after bookworm is released to have the meat
> of that discussion, but...

> […]

> As and when we switch i386 to a secondary status like this (however we
> label it!), then I think we should *only* consider it as a
> compatibility layer for older software. People *could* just use old
> chroots or similar, but the need is likely to be around for a
> while.

> There's a tension here: I think it's important to keep the old ABI
> around for those old binaries, and I genuinely don't see a use case
> for a new incompatible ABI on a mostly-dead architecture that won't
> support those binaries. *But* I think we'll also need to keep the port
> going with security fixes - it's still likely to be quite common and
> we need to keep users safe.

> People are even likely to want to keep old software running beyond
> 2038, in which case I envisage clock hacks coming to keep things
> limping on. :-/

So I guess my concern is three fold:

  a) There's the part that I mentioned where excluding it means it is
 destined to die in exchange for that backwards binary compat,
 although it's not clear for how long this all will be supported
 by Debian (and where I consider I've registered my concern here,
 but if people in general think the backwards compat trumps other
 stuff I'm fine with that).
  b) I still keep at least one 32-bit Athlon system around mostly to
 be able to support 3Dfx hardware, which I'll have to stop
 supporting either when the machine, the port or time dies. OTOH
 I've been pondering stopping the support in the future anyway so
 it's not such a great concern for me.
  c) And then there's the port support long term in dpkg, where my
 expectation is that when and if Debian does not officially support
 it, people that might still want to use that port on vintage
 hardware will most probably request to flip the switch, and then
 me and/or the ports.d.o maintainers might need to decide between
 users that have expected such backwards compat and porters that
 might want to be able to continue using the port. :/

(I also keep that Athlon around as I need to recover data from a bunch
of 3.5" floppy disks! But that should stop being relevant once I sit down
through the drudge of changing the piles of disks every few minutes. :)

Thanks,
Guillem

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Steve Langasek wrote:
>
>On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
>> >If the main reason is to support non-free binaries, at least to me
>> >that does not seem like a very compelling reason. And people can
>> >always use old chroots or similar I guess?
>
>> i386 is in a really awkward situation here, I think. Nobody is working
>> on it explicitly any more (AFAICS?), but its history as by far the
>> most common architecture means that:
>
>>  * we still have a (very!) long tail of installations using it
>>  * there are *massively* more old binaries available for it, free,
>>proprietary *and* locally-built
>
>FTR this includes wine, and 30 years of 32-bit Windows executables that
>people want to be able to run, including games.  (for which inaccurate times
>are not going to be hugely important, in general.) And some of those games
>are going to require e.g. library packages for 3d acceleration that are in
>sync with kernel drivers (nvidia).  This was ultimately what made "just use
>an older version in a chroot/container" untenable for Ubuntu and led to
>keeping i386 as a partial port.

ACK!

>So one may not think that support for legacy, proprietary programs is a
>compelling reason to keep binary-compatibility on i386.  But I counter that
>unless you care about this, there's no reason to keep i386 as an
>architecture *at all*.

That's exactly my reasoning, yup!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

partial support for i386 (Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal))

[Michael Biebl]

Am 19.05.23 um 17:30 schrieb Simon McVittie:

On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:

I have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.


I see four levels of support that we could reasonably have for i386:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
configure it as a multiarch foreign architecture on an amd64 system,
and run legacy Linux i386 binaries directly or legacy Windows i386
binaries via Wine



While I wouldn't mind dropping support for i386 to something like 1, I 
do wish we don't end up doing it exactly the same as in Ubuntu, where we 
now have to apply i386 specific code to e.g. debian/rules, i386 specific 
build-deps etc.


The prospect of something 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/158 
doesn't make me too happy.


Removing (partial) support for an architecture shouldn't lead to 
additional work and maintenance burden.



Michael



OpenPGP_signature
Description: OpenPGP digital signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Andrew Cater wrote:
>On Fri, May 19, 2023 at 03:03:40PM +0100, Steve McIntyre wrote:
>> 
>> I had been thinking about doing similar for installer images too, but
>> with other work going on too I think it got too late in the cycle to
>> make that change. My plan is therefore to ship i386 installer images
>> for bookworm as normal (including bookworm point releases going
>> forwards), but to disable those builds for testing/trixie ~immediately
>> after the release.
>
>I'd honestly suggest *just* publishing DVD1 for i386.
>
>Netinst requires internet access: DVD1 can be used to install a basic
>system without this. Scrap *everything else* for i386 installation media.

We've had this discussion before. I don't see the point in removing
choice here at *really* short notice before bookworm, but still
keeping a non-zero number of installer images for the architecture. It
saves us very little effort and doesn't really gain us anything.

This is why I'm talking *now* about dropping things for trixie.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Colin Watson wrote:
>On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
>> Well, maybe not a strong view, but a sense of vague unease--possibly an
>> ill-informed one.  As someone who has used SIMH for "real" work[1], I
>> have to ask how someone would conduct an install to a 32-bit x86 machine
>> running under emulation, assuming no OS on the simulated machine.
>
>I occasionally use 32-bit x86 even today (mostly for not very good
>historical reasons, but nevertheless), and I do it by using a 32-bit
>container on a 64-bit x86 machine instead.  It's much faster to run, and
>it doesn't depend on installer support.  There are doubtless edge cases
>where you need a completely separate kernel, but they aren't really ones
>I run into.

ACK. For people needing/testing i386 stuff, even just a simple
debootstrap and {s,}chroot will cover the vast majority of
needs. That's how we've been building i386 software already for ages
in Debian already.

More complex things can be done if needed: loopback mount an image,
debootstrap, install a kernel, etc. I don't see this as something we
should be spending much effort on in the future.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Cyril Brulebois]

Hi,

Andrew M.A. Cater  (2023-05-19):
> I'd honestly suggest *just* publishing DVD1 for i386.
> 
> Netinst requires internet access: DVD1 can be used to install a basic
> system without this. Scrap *everything else* for i386 installation media.

I'm not sure how dropping one netinst ISO is going to change anything in
debian-cd: that's a very fast build, that's a small, single ISO, and not
having to download several GBs seems quite appealing to me. Having DVD1
only would really not seem acceptable to me.

I'm also very much *not* in favour of dropping images just *days* before
the release, without any kind of heads-up.

If the point is to limit the amount of testing done before publishing,
it would seem acceptable to me to limit i386 testing, and to only be
“reacting” to user reports about things that might not be working for
them (instead of proactively checking various combinations).

Cc-ing debian-boot@ and debian-cd@ for information, seeing such an idea
mentioned only on debian-devel@ feels weird.

> Update media for i386 - no, really, don't bother. One DVD per point
> release and have done with it. The utility for i386 was questioned by
> me (amongst others) late in Bookworm planning and it was suggested
> that it should be decided for Trixie immediately bookworm is released.

No opinion on that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature