Re: The future of mipsel port
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
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
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
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
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
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=1.3.0-2
Re: The future of mipsel port
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
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
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
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
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
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
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
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
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
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?
