The future of mipsel port

[YunQiang Su]

Hi, folks,

Welcome to era of Trixie, and let's talk about the future of mipsel.

mipsel port has some problems as somebody may know:
1. 2G user RAM space make some packages FTBFS, especially with LTO enabled.
2. Y2038 problem, which requires almost rebootstrap.
3. The current hardwares, include MIPS P5600, Ingenic X2000, Loongson 3A4000,
are NAN2008 hardwares, and some new software supposed that NAN2008 is
always true.
[1] https://sourceware.org/binutils/docs-2.25/as/MIPS-NaN-Encodings.html
4. the maintenance status of big projects, like Firefox, Libreoffice
etc are not so good.

So I consider to suggest drop mipsel support from the list of official ports.
(And let's keep mips64el port).

As CIP United, we do maintain an unofficial port of mipsel.
So I wish that Debian can still accept our patch to support mipsel
port (source only).
https://repo.oss.cipunited.com/debian/

Debian mips32r2el port with:
* -mnan=2008
* -mfp64
* -mmsa (not yet, will have another port)
* -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
* -D_TIME_BITS=64

Known supported hardwares:
MIPS P5600
Ingenic X2000
Loongson 3A4000

[Matthew Garrett]

On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote:

> Known supported hardwares:
> MIPS P5600
> Ingenic X2000
> Loongson 3A4000

This sounds reasonable, but do you have a list of hardware currently
supported by the mipsel port that would be left unsupported by this?

[Mathieu Malaterre]

On Tue, Jul 18, 2023 at 6:46 AM YunQiang Su <s...@debian.org> wrote:
[...]

> Known supported hardwares:
> MIPS P5600
> Ingenic X2000
> Loongson 3A4000

Could you confirm that MIPS Creator CI20 (Ingenic JZ4780) would not be
supported anymore ?

Thanks

[YunQiang Su]

Mathieu Malaterre <ma...@debian.org> 于2023年7月18日周二 21:26写道：

All MIPS Release 2+ CPU (JZ4780 included) should continue supported,
just like the current status,
while you need pass ieee754=relaxed to kernel.

That's how we support NaN2008 hardwares with current release.

> Thanks
>

[Paul Wise]

On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:

> As CIP United, we do maintain an unofficial port of mipsel.
> So I wish that Debian can still accept our patch to support mipsel
> port (source only).
> https://repo.oss.cipunited.com/debian/

The closest Debian has to source-only ports are the ones that are
supported in rebootstrap but not on debian-ports. You could also
migrate mipsel to debian-ports instead of dropping it entirely.

https://wiki.debian.org/HelmutGrohne/rebootstrap
https://wiki.debian.org/PortsDocs/New

> (And let's keep mips64el port).

DSA would appreciate it if you could publicly document your plans for
trixie mips64el hardware qualification on the wiki, as riscv64 did:

https://dsa.debian.org/ports/hardware-requirements/
https://wiki.debian.org/HardwareQualification

--
bye,
pabs

https://wiki.debian.org/PaulWise

[YunQiang Su]

Paul Wise <pa...@debian.org> 于2023年7月19日周三 11:23写道：

>
> On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:
>
> > As CIP United, we do maintain an unofficial port of mipsel.
> > So I wish that Debian can still accept our patch to support mipsel
> > port (source only).
> > https://repo.oss.cipunited.com/debian/
>
> The closest Debian has to source-only ports are the ones that are
> supported in rebootstrap but not on debian-ports. You could also
> migrate mipsel to debian-ports instead of dropping it entirely.
>

Yes. It sound a good idea to migrate to debian-ports.
Since we have only 15 years to 2038, I hope the ports in debian-ports
should be y2038-free.

> https://wiki.debian.org/HelmutGrohne/rebootstrap
> https://wiki.debian.org/PortsDocs/New
>
> > (And let's keep mips64el port).
>
> DSA would appreciate it if you could publicly document your plans for
> trixie mips64el hardware qualification on the wiki, as riscv64 did:
>
> https://dsa.debian.org/ports/hardware-requirements/
> https://wiki.debian.org/HardwareQualification
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

--
YunQiang Su

[Aurelien Jarno]

On 2023-07-19 11:23, Paul Wise wrote:
> On Tue, 2023-07-18 at 12:45 +0800, YunQiang Su wrote:
>
> > As CIP United, we do maintain an unofficial port of mipsel.
> > So I wish that Debian can still accept our patch to support mipsel
> > port (source only).
> > https://repo.oss.cipunited.com/debian/
>
> The closest Debian has to source-only ports are the ones that are
> supported in rebootstrap but not on debian-ports. You could also
> migrate mipsel to debian-ports instead of dropping it entirely.

Please note that maintaining a port in debian-ports in good state
requires more work than an official port. Therefore this should only be
done if there are people actually going to do the work, otherwise it's
just a waste of time and resources.

> https://wiki.debian.org/HelmutGrohne/rebootstrap
> https://wiki.debian.org/PortsDocs/New
>
> > (And let's keep mips64el port).
>
> DSA would appreciate it if you could publicly document your plans for
> trixie mips64el hardware qualification on the wiki, as riscv64 did:

Yes. Please also clarify how do you plan to handle the NaN2008 issue for
mips64el. Some of the newer buildds have NaN2008 FPU, while the port and
the toolchain are configured for the old MIPS NaN. This causes some
issues in some packages, a lot of headaches to packages maintainers and
upstream that have to debug the issues, and eventually testsuites being
fully or partially disabled.

Regards
Aurelien

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

[YunQiang Su]

Aurelien Jarno <aur...@debian.org> 于2023年7月19日周三 14:43写道：

I am working on getting more NaN1985 hardware for Debian.

> Regards
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aure...@aurel32.net http://aurel32.net

--
YunQiang Su

[Mark Hymers]

On Tue, 18, Jul, 2023 at 12:45:51PM +0800, YunQiang Su spoke thus..

> So I consider to suggest drop mipsel support from the list of official ports.
> (And let's keep mips64el port).

Is there consensus on this point? If so, should we start making
arrangements to remove mipsel from the archive?

Thanks,

Mark

--
Mark Hymers <mhy at debian dot org>

[Paul Gevers]

Hi,

On 23-07-2023 17:51, Mark Hymers wrote:
> On Tue, 18, Jul, 2023 at 12:45:51PM +0800, YunQiang Su spoke thus..
>> So I consider to suggest drop mipsel support from the list of official ports.
>> (And let's keep mips64el port).
>
> Is there consensus on this point? If so, should we start making
> arrangements to remove mipsel from the archive?

Speaking as a member of the Release Team, but without having consulted
with the others, I think we're OK with the removal.

I have not been involved in removal of an architecture before, I think
it's the Release Team configuration of britney2 that needs to change as
the first step or at least at the same time as the actual removal from
the archive, correct?

Paul

[Mark Hymers]

On Sun, 23, Jul, 2023 at 08:36:15PM +0200, Paul Gevers spoke thus..

> Speaking as a member of the Release Team, but without having consulted with
> the others, I think we're OK with the removal.
>
> I have not been involved in removal of an architecture before, I think it's
> the Release Team configuration of britney2 that needs to change as the first
> step or at least at the same time as the actual removal from the archive,
> correct?

I don't want to get ahead of ourselves until we're sure that there's
consensus, but the procedure would normally be:

1. Release team: reconfigure britney2 to remove mipsel from testing
2. ftp-team remove architecture from testing and associated queues and
perform any needed cleanup
3. ftp-team remove architecture from unstable and experimental and
associated queues + cleanup

[Adrian Bunk]

It might be a good idea to have a 3 year gap between 2. and 3.

mipsel/bookworm is (security) supported by Debian until mid-2026.

Currently all MIPS buildds are shared between mips64el and mipsel.

Separate build infrastructures with differently configured buildds
running on different types of hardware between unstable/experimental
and oldstable/stable for the same architecture is something that
might not be a good idea.

> Mark

cu
Adrian

[Aurelien Jarno]

Hi,

Sorry but I don't see your point. The hardware currently building
mips64el will continue building mipsel for (old)stable(-security). This
is not an issue.

DSA will probably just have to reinstall the hosts running mipsel as
mips64el so that it can continue to be used for mips64el even when
bookworm is not supported anymore (or just get rid of it because is
likely going to be quite old at that time).

[Adrian Bunk]

It's about trying to avoid creating differences between unstable
and *stable-security.

We do have some packages where the latest upstream version from unstable
regularly get updated into *stable-security.

In ports we even have an architecture where all builders are qemu
running with nocheck, any build results from such a setup might
have problems different from what will fail in *stable-security.

Even the setup is subtly different, sometimes packages do build
on ports maintained buildds but FTBFS on DSA maintained buildds.[1]

If there turns out to be a reason why continuing to build
mipsel/unstable+experimental on DSA maintained hardware
might no longer be feasible then changing the setup would
be fair enough, but the default option should be to keep
the currently working setup for mipsel until 2026.

> DSA will probably just have to reinstall the hosts running mipsel as
> mips64el so that it can continue to be used for mips64el even when
> bookworm is not supported anymore (or just get rid of it because is
> likely going to be quite old at that time).

That's something that might have to happen in 2026, but it's invariant
to the discussion where mipsel/unstable+experimental is being built.

> Regards
> Aurelien

cu
Adrian

[1] An example from today would be
https://buildd.debian.org/status/logs.php?pkg=rust-fs-extra&ver=1.3.0-2

[Florian Lohoff]

Hi,

On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote:
> Hi, folks,
>
> Welcome to era of Trixie, and let's talk about the future of mipsel.

> So I consider to suggest drop mipsel support from the list of official ports.
> (And let's keep mips64el port).

I am late to the party but as i mentioned a couple times on debian-mips
already i'd like to keep mipsel as a debian-port - and i'd like to
revert away from mips32r2 back to mips2/mips3 - That change (with
stretch) basically dropped all of the supported platforms formerly
supported without a good reason - mips32r2 cpus would have been
able to run mips2 code. The now supported platforms are
basically non existent or available for the normal user.

So with that change we basically killed 90% of the Debian/mipsel
users/community e.g. Siemens RM series, Cobalt Cube/RAQ, Decstation R4k
and the like which are now all stuck with pre-Stretch Debian Releases.

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

[Paul Wise]

On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote:

> I am late to the party but as i mentioned a couple times on debian-mips
> already i'd like to keep mipsel as a debian-port - and i'd like to
> revert away from mips32r2 back to mips2/mips3 - That change (with
> stretch) basically dropped all of the supported platforms formerly
> supported without a good reason - mips32r2 cpus would have been
> able to run mips2 code. The now supported platforms are
> basically non existent or available for the normal user.

That sounds like a new port would be needed, some docs:

https://wiki.debian.org/PortsDocs/New

> So with that change we basically killed 90% of the Debian/mipsel
> users/community e.g. Siemens RM series, Cobalt Cube/RAQ, Decstation R4k
> and the like which are now all stuck with pre-Stretch Debian Releases.

The baseline bump of the mips port similarly lost MIPSr1 based routers,
some of which could run Debian in a chroot.

[Aurelien Jarno]

Hi,

On 2023-08-06 13:54, Florian Lohoff wrote:
>
> Hi,
>
> On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote:
> > Hi, folks,
> >
> > Welcome to era of Trixie, and let's talk about the future of mipsel.
>
> > So I consider to suggest drop mipsel support from the list of official ports.
> > (And let's keep mips64el port).
>
> I am late to the party but as i mentioned a couple times on debian-mips
> already i'd like to keep mipsel as a debian-port - and i'd like to

From what I have understood from YunQiang plans, it is currently not
planned to import mipsel on debian-ports. Are you volunteering for
maintaining such a port?

> revert away from mips32r2 back to mips2/mips3 - That change (with
> stretch) basically dropped all of the supported platforms formerly
> supported without a good reason - mips32r2 cpus would have been

The reason is that many upstream code do not support mips2 anymore,
especially for JIT languages or languages with their own code generator.
Be prepared for a lot of upstream work.

[Florian Lohoff]

Hi,

On Mon, Aug 07, 2023 at 10:53:02AM +0200, Aurelien Jarno wrote:
> From what I have understood from YunQiang plans, it is currently not
> planned to import mipsel on debian-ports. Are you volunteering for
> maintaining such a port?

I am not interested in mips32r2 as i have no hardware for that. So
everything debian-mipsel stretch++ is unusable.

> > revert away from mips32r2 back to mips2/mips3 - That change (with
> > stretch) basically dropped all of the supported platforms formerly
> > supported without a good reason - mips32r2 cpus would have been
>
> The reason is that many upstream code do not support mips2 anymore,
> especially for JIT languages or languages with their own code generator.
> Be prepared for a lot of upstream work.

I have already started with that on stretch - have 90% build - the issue
is that a lot of debian patches unconditionally enabled/switched to
mips32r2

[Adrian Bunk]

On Mon, Aug 07, 2023 at 10:09:40AM +0800, Paul Wise wrote:
> On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote:
>
> > I am late to the party but as i mentioned a couple times on debian-mips
> > already i'd like to keep mipsel as a debian-port - and i'd like to
> > revert away from mips32r2 back to mips2/mips3 - That change (with
> > stretch) basically dropped all of the supported platforms formerly
> > supported without a good reason - mips32r2 cpus would have been
> > able to run mips2 code. The now supported platforms are
> > basically non existent or available for the normal user.
>
> That sounds like a new port would be needed,

>...

No, that's not required.

We've already had baseline lowering in ports in the past (and could do
that even for a release architecture) by changing the default in gcc
and then binNMUing all packages.

> bye,
> pabs

cu
Adrian