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&ver=1.3.0-2
Reply to: