[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1050872: marked as done (release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?)

Your message dated Sun, 8 Jun 2025 11:47:06 +0200
with message-id <fc036d1d-1059-41ff-abae-b5e2768470ea@debian.org>
and subject line Re: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?
has caused the Debian Bug report #1050872,
regarding release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1050872: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050872
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-mips@lists.debian.org, bluca@debian.org, debian-wb-team@lists.debian.org

Luca Boccassi and I have been preparing stable and oldstable updates for
debootstrap so that the transition described in DEP-17 can continue.
Because DEP-17 involves changes to trixie/sid chroots' bootstrap
procedures, the updated debootstrap needs to be deployable to every
official buildd, and we've been told that (old)stable point releases
are the preferred way to achieve that.

When Luca asked how many suites we needed this change in, we were hoping
the answer would be stable only, and maybe oldstable (which is still
in its 1 year of overlapping support from the security team and DDs
in general).

However, if I understand correctly, Luca has been told that some official
mips64el buildds are running mipsel user-space on mips64el hardware which
only works with the buster kernel, and therefore those official buildds
are still stuck on buster, meaning we also need to prepare a buster
version of debootstrap and get it into Debian 10 LTS via buster-security.

Is this true?

>From the point of view of the project having control over its own future,
I would have hoped that official Debian infrastructure would only be using
suites that are supported by Debian as a whole, rather than handing over
control and responsibility to the Debian-LTS subproject.

Also, from the point of view of continued development of testing/unstable,
I would have hoped that packages in testing/unstable could safely
assume that they will run on at least the kernel from stable (or maybe
oldstable for a short time after a new stable release), following our
usual "skipping a release is unsupported" rule. Obviously if the buildds
are running on an oldoldstable kernel, any mips64el package that might
be used at compile-time or for build-time tests will be unable to make
that assumption.

Please could someone with knowledge of the buildds clarify the situation?

If our official buildds for a release architecture are unable to run on
either the stable or oldstable kernel, I think that raises some important
questions about suitability for inclusion in future releases.

Thanks,
    smcv

--- End Message ---
--- Begin Message --- 
Hi
We have dropped mips64el from the list of supported architectures in trixie. I believe that from the Release Team point of view, there's nothing to be done for this bug report anymore. 

Paul

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: