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 otheros

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

[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

[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

[i386] adlibtracker2 and fp-units-i386

[Ivan Shmakov]

> On 2023-06-07, 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?

 > 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 signed bootloader packages and such.  Lets remove
 > those and see what we have left.

[...]

 > Old soundblaster card related:

 >>  adlibtracker2 deb sound optional arch=i386

"Related," yet not "dependent."  This package allows one to
compose /and play/ music composed for the OPL3 FM synthesis
chip (and its clones), such as was (historically) used in
Adlib and compatible boards.  Naturally, it contains an OPL3
emulator and, in recent versions, has no support for hardware
OPL3 chips.

This package is similar in spirit to, e. g., goattracker for SID
(or the recently removed aylet for AY-3-8912.)

I've been meaning to check why it's i386-only for a while now.
As a (not particularly educated) guess, it might have something
to do with it being written in Free Pascal.

 >>  sb16ctrl-bochs deb otherosfs optional arch=any-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

... For instance, at [1], I only see "Kylix" mentioned for:

  fp-units-i386
Free Pascal - Kylix compatibility units dependency package

  fp-units-i386-3.2.2
Free Pascal - Kylix compatibility units

[1] http://packages.debian.org/sid/source/fpc

-- 
FSF associate member #7257  http://am-1.org/~ivan/

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

[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 u

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

[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

[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