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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2024-06-25 at 20:33 +0300, Arthur Zamarin wrote:

======== x86 ========

Stable 32-bit arch. I'll be honest, I don't believe at all this should
be stable arch anymore. I propose making it dev arch, and mass-dekeyword stuff we got because of inertia. This arch is close to HW die. (let's
not talk about i486 vs i686).

I don't use stable, so I'm biased, but I think this is long overdue.

======== ppc ========

Stable 32-bit arch. Becoming harder and harder with time, with more
broken stuff (which I just destable/dekeyword).

I propose we convert it into dev arch status, not stable. If folks
disagree, once again mass-dekeyword.

I'm inclined to kill it. I actively used hardware once upon a time, but that was nearly 20 years ago. When I dropped Java support for it around 2016ish, I literally one found user. I've never heard of one since.

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

I wasn't really in favour of having LE and BE under the same keyword, but I
was overruled. My fears have largely proven true. We have seen a lot of issues around graphical stuff. Sure, we've handled it in profiles, but it is a pain.

======== m68k ========

Exp arch, works ? maybe? I've no idea. Let's not touch :)

It's not too bad and generally works. I'm a little slow on keywording requests sometimes, but I mostly keep up. I have thought about promoting it from exp to dev now that the tree is in a better state than it was, but there is still
some work to do. We have an important ABI breakage ahead, but that is being discussed.

-----BEGIN PGP SIGNATURE-----

iQJFBAABCAAvFiEEPxcZ3tkwcedKm2a8EiZBXQDdMTcFAmZ7SsURHGNoZXdpQGdl bnRvby5vcmcACgkQEiZBXQDdMTfE3xAAnbi0wFm3kfeT4XOdShIr0qM9RAivVn+b 9rmPnt3L5ErdPI2FuDP358ZB3L3Kp87o/wQAr670a+GlmY2owqMagsVa4Xn/mZsM bVR0s82U6ioRJU26VzLS9uzzyvWGhYHg5yy7SMgmBET7460gwNmfTp4U87G4ZSzS p+8qyfWcupQgAyZx8HT0m8WC9Ys48KO9Gql5z83mWl1xfqgQ/X4s7CRUKhd6lzCV RP36Wa8SoJxPk2p27VdaI9uLfHbSA4SCGEhTD605r0nKJJbQxzrus+/DK12Qwmz4 Y2EseD0iVPQxRiH/GsVgm/87lRz53TDOdM699VWBLqHbgNnh955dG7WAHtkRshOS qUZhRzG9hgW/pCIQccFXFq6CZ7VljQq2NlF/G4Y4QBdoPxlZ6E9hvpCHoOYdQZM1 prVHx6NA8YKycX/9nEOTIVElEnocSDpcH2qCsZ5w1QMknmJdEo1/19r00jZv3Rta uLhJ33EcS6AOpzTp4Wp/p+sO9HI+s5OH2sNYi0r2cPrbD/le9SaMmMGl7GhQFgsO SoshtVmQVJnMkgEXHu+DflMup93XsHAoF4TNyOdxuHmKx9auB8MHsQgKfwOkWtug ftwxE2MQodILgYzfCszVX8aRaqPWPEDkyBwQre88pTiR5Bh9igrv50wbXupjKaHz
idTQHP1PW80=
=Bf5u
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected] (Arthur Zamarin)

======== 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".

======== m68 ========

Exp arch, works ? maybe? I've no idea. Let's not touch :)

======== mips ========

Exp arch, with mostly good dep-tree. Does mips team want to make it dev
arch?

What you call "exp arches" (i.e. architectures with no "stable profiles" at all) are a pain in the behind. Nobody checks if dependencies are correct,
and the dependency tree becomes randomly broken.

This should ideally only be a temporary status,
* either on the way to a consistent deptree (~arch)
* or on the way out the door.

My 2ct:

alpha: well, if it is in a decent state, and if Matoro promises to keep up
with keywording requests (important!), let's upgrade it.

m68k: dito as soon as Chewi thinks it's ready

mips: well... personally I'd love to have it back to a consistent deptree,
but right now it has still waaay too many packages keyworded for that.
also, this is a horrible beast, with 32bit, mixed, and 64bit ABI and both
big and little endian. we have no hardware at all, and even if we had it
would be slow...
that said, I dont see us dropping support for mips either. in particular
since we're one of the last distros to deal with it...




--
Andreas K. H�ttel
[email protected]
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmZ8d6BfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSqy9Q/8DemoFyXemBtZfDjU6kWwariI/kq3bmpFX1OMa4FEelySYfZCehlXlK5+ h4wvh0RTBhrEq8COqsdSLA4BLyZt7L2ebHJP1SeKDrZOsYNsj7+89oHZ0AmVwBf6 WXANTKSX9+iuxMSq66gzpErmb4WzvuKTj6z0l2FNaDVMF7rxE7Q9Nai9E8LVzqQp qViPzSmk55kl5DeXctvbjKk/xf6SF1OXIjLpJ9H/c2HBBdkX4bU0/R3YXlF/mLk0 TLK5AkukwFVLyO0zF6YbM1vchkmHSHJEWipRdR07iZDAZ51SqJNt5qdT1Gg7jvw0 xThOBJkvN66DWVm+82IPdb4l5kz9Cq1RCUuILMNUwNyXQCdR1m0QqpHtPYiqEUHW 6EdkpQdT1nX2A1zrrQgFzQiSakEN1RDbsTswcjnwjZdVoVR+m/aa6otCXQxhChW2 snjrGoM1ixxoIZr9vGvRIUJ4si5JJOkKtJhBIjd92qD7EeH4F12jhfc48+Z1LB5T jkV82YKyQ3fQRNwFdubo87/GxmGAf9ANdihQQWKzQoyQ/r2lbYD2+vlnVonA7SmX rRROsWqoBA96JCo7tJBYBoVFuEQmjaBQ1T7iUZProVLZJvVP9k1jKqXi