Re: The future of mipsel port

2023-08-07 Thread 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



Re: The future of mipsel port

2023-08-07 Thread 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

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


signature.asc
Description: PGP signature


Re: The future of mipsel port

2023-08-07 Thread 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.

Regards
Aurelien

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


signature.asc
Description: PGP signature


Re: The future of mipsel port

2023-08-06 Thread 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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Re: The future of mipsel port

2023-08-06 Thread 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.


signature.asc
Description: PGP signature


Re: The future of mipsel port

2023-08-05 Thread Adrian Bunk
On Wed, Jul 26, 2023 at 06:24:49PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-24 23:07, Adrian Bunk wrote:
> > On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> > > 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
> > 
> > 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.
> 
> 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.

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



Re: The future of mipsel port

2023-07-26 Thread Aurelien Jarno
Hi,

On 2023-07-24 23:07, Adrian Bunk wrote:
> On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> > 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
> 
> 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.

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

Regards
Aurelien

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



Re: The future of mipsel port

2023-07-24 Thread Adrian Bunk
On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> 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

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



Re: The future of mipsel port

2023-07-23 Thread 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

Mark


-- 
Mark Hymers 



Re: The future of mipsel port

2023-07-23 Thread 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


OpenPGP_signature
Description: OpenPGP digital signature


Re: The future of mipsel port

2023-07-23 Thread 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 


signature.asc
Description: PGP signature


Re: The future of mipsel port

2023-07-19 Thread YunQiang Su
Aurelien Jarno  于2023年7月19日周三 14:43写道:
>
> 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.
>

I am working on getting more NaN1985 hardware for Debian.

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



-- 
YunQiang Su



Re: The future of mipsel port

2023-07-18 Thread 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
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature


Re: The future of mipsel port

2023-07-18 Thread YunQiang Su
Paul Wise  于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



Re: The future of mipsel port

2023-07-18 Thread 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


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


Re: The future of mipsel port

2023-07-18 Thread 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?



The future of mipsel port

2023-07-17 Thread 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