From: matoro <matoro_mailinglist_gentoo-dev@matoro.tk>
To: gentoo-dev@lists.gentoo.org
Cc: Arthur Zamarin <arthurzam@gentoo.org>
Subject: Re: [gentoo-dev] Arch Status and Future Plans
Date: Tue, 25 Jun 2024 17:40:32 -0400 [thread overview]
Message-ID: <fc1736c140092fa9ce41e12c2cd0da3f@matoro.tk> (raw)
In-Reply-To: <75654daa-c5fc-45c8-a104-fae43b9ca490@gentoo.org>
On 2024-06-25 13:33, Arthur Zamarin wrote:
> So, are you ready for seeing the mess? Here we go.
Thanks Arthur, I can add some input as another AT.
> ======== 32-bit arches ========
>
> This includes stable arches x86, arm, ppc, sparc32, dev arches s390, and
> maybe more. Those are in much worse situation, with a mess on various
> fronts, some of them super hard to continue support. For example
> qtwebengine is less and less likely to manage to compile on a
> real-hardware, and not 32-bit chroot on 64-bit host. Arch Team want to
> minimize our work on those arches, meaning mass-destable and even
> mass-dekeyword, with potentially full drop of stable status.
I think all of these need to be moved to dev. Particular attention on ppc
because somebody seems to have gone on a rampage throwing keywords at it and
so I frequently see packages with things like KEYWORDS="amd64 ppc" which
makes no sense.
Also, hppa is 32-bit as well. The hardware is 64-bit, and so is the kernel,
but the userspace is 32-bit.
sparc32 and s390 I think need to be dropped or exp at least. For the former
we need to get sys-boot/silo out of tree.
Also, in https://wiki.gentoo.org/wiki/Handbook:Main_Page#SPARC_Handbook we
specifically call out:
> In Gentoo, only SPARC64-compatible CPUs are supported.
> ======== ppc64 ========
>
> Stable 64-bit arch. So, this is a mess of an arch. Consists of both
> ppc64ul (big-endian) and ppc64le (little-endian). The latter is much
> better supported by upstream. The profiles inheritance inside is a mess
> (we even added running 32 userspace on 64 bit kernel, called ppc64/32ul
> - just why?). We have devboxes for both BE and LE, so mostly fine. The
> profile inheritance is the messiest I've even seen.
>
> I would hope to split this arch into the two endianness, but I suspect
> nobody has the energy to do it. Oh well.
>
> Next proposal is to cleanup profiles: remove the ppc64/32ul, cleanup
> profile inheritance, cleanup the masks and unmasks, and continue with
> both ppc64ul & ppc64le supported.
Agree that this needs to be split. I could do the profile reorganization,
but would need a developer who would be able to in one shot replace all
KEYWORDS with both entries.
> ======== hppa ========
>
> Sigh. Stable 64-bit arch. Out main Gentoo devbox died, and the second
> one is always stuck compiling gcc for stage3 (a compilation takes 7
> days). Here we have a fight in Arch Team. I prefer to destable it, Sam
> prefers to stable it. This one is tough.
FWIW as the one handling these for now I also would prefer destable. I would
say that any wd40 profiles should be ineligible for stable.
> ======== ia64 ========
>
> Dev 64-bit arch. Kernel dropped support, glibc dropped support, devbox
> died - days are short before full exp status or full removal of arch.
I would prefer to see this go straight from dev to removed. Also, a timeline
on removal with respect to kernel/glibc EOL would be nice so that it doesn't
just stay up in the air indefinitely. Our python deprecation schedule is a
model of clarity.
> ======== alpha ========
>
> Exp arch, with nearly (or maybe already) full correct dep-tree. matoro
> did a lot of great work here, so I think we should promote it to dev
> arch, so dep-tree remains unbroken. We dekeyworded a lot of stuff,
> cleaned it up, so a nice "completion bonus".
Yes, this has been basically fully-correct for months now and it's very
annoying to play catch-up constantly. Please make this dev at the soonest
opportunity.
Also, current tree correctness is stuck on this:
https://github.com/gentoo/gentoo/pull/36711
> ======== mips ========
>
> Exp arch, with mostly good dep-tree. Does mips team want to make it dev
> arch?
Unfortunately this is in much worse state than alpha. For a long while it
was stuck on rust but luckily we now have rust and llvm, so I should be able
to make more progress on it, but it's slow going. Dekeywording efforts would
be hugely appreciated here.
next prev parent reply other threads:[~2024-06-25 21:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 17:33 [gentoo-dev] Arch Status and Future Plans Arthur Zamarin
2024-06-25 21:40 ` matoro [this message]
2024-06-25 22:55 ` James Le Cuirot
2024-06-26 0:06 ` Notion of stable depgraph vs stable keywords (Re: [gentoo-dev] Arch Status and Future Plans) Sam James
2024-06-28 4:17 ` [gentoo-dev] Re: Notion of stable depgraph vs stable keywords (Re: " Duncan
2024-06-28 5:16 ` Sam James
2024-06-26 0:14 ` Misc arch plans (Re: [gentoo-dev] " Sam James
2024-06-26 20:29 ` ia64, was: " Andreas K. Huettel
2024-06-26 20:45 ` matoro
2024-06-26 0:17 ` On the value (or not?) of stable keywords " Sam James
2024-06-26 0:19 ` time64 & LFS for 32-bit arches " Sam James
2024-06-26 0:20 ` x86 FP issues " Sam James
2024-06-28 5:20 ` Michał Górny
2024-06-26 7:38 ` [gentoo-dev] Re: Arch Status and Future Plans Florian Schmaus
2024-06-26 8:29 ` Christian Bricart
2024-06-26 20:44 ` Immolo
2024-06-26 19:47 ` nomenclature, was: Re: [gentoo-dev] " Andreas K. Huettel
2024-06-26 20:18 ` Andreas K. Huettel
2024-06-26 20:24 ` riscv, was: " Andreas K. Huettel
2024-06-26 21:08 ` 32bit vs 64bit, " Andreas K. Huettel
2024-06-28 16:12 ` splitting keywords, " Andreas K. Huettel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc1736c140092fa9ce41e12c2cd0da3f@matoro.tk \
--to=matoro_mailinglist_gentoo-dev@matoro.tk \
--cc=arthurzam@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox