In the tree without changes since 2019-12-11 (except stabilization). This is following to bug#709248, where it stabilized arches that where for the previous version, this one is for stabilizing new ones that weren't before because of klibc (arm, arm64, ia64, ppc64, hppa, m68k, sh, sparc).
sparc stable
arm stable
ppc64 stable
SuperH port disbanded.
(In reply to Haelwenn Monnier from comment #0) > In the tree without changes since 2019-12-11 (except stabilization). > > This is following to bug#709248, where it stabilized arches that where for > the previous version, this one is for stabilizing new ones that weren't > before because of klibc (arm, arm64, ia64, ppc64, hppa, m68k, sh, sparc). Can you elaborate on how KEYWORDS for klibc and mksh are related?
(In reply to Sergei Trofimovich from comment #5) > (In reply to Haelwenn Monnier from comment #0) > > In the tree without changes since 2019-12-11 (except stabilization). > > > > This is following to bug#709248, where it stabilized arches that where for > > the previous version, this one is for stabilizing new ones that weren't > > before because of klibc (arm, arm64, ia64, ppc64, hppa, m68k, sh, sparc). > > Can you elaborate on how KEYWORDS for klibc and mksh are related? klibc was a dependency of mksh but it haven't been maintained ( bug#653388 ) and only supports few arches so it limited keywording, dietlibc seems to be in about the same shape, so instead I removed it in favor of the system libc and only masked USE=static for glibc.
(In reply to Haelwenn Monnier from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > (In reply to Haelwenn Monnier from comment #0) > > > In the tree without changes since 2019-12-11 (except stabilization). > > > > > > This is following to bug#709248, where it stabilized arches that where for > > > the previous version, this one is for stabilizing new ones that weren't > > > before because of klibc (arm, arm64, ia64, ppc64, hppa, m68k, sh, sparc). > > > > Can you elaborate on how KEYWORDS for klibc and mksh are related? > > klibc was a dependency of mksh but it haven't been maintained ( bug#653388 ) > and only supports few arches so it limited keywording, dietlibc seems to be > in about the same shape, so instead I removed it in favor of the system libc > and only masked USE=static for glibc. I still don't see why app-shells/mksh needs to be stabilized on m68k, hppa64 and other minor arches.
(In reply to Sergei Trofimovich from comment #7) > (In reply to Haelwenn Monnier from comment #6) > > (In reply to Sergei Trofimovich from comment #5) > > > (In reply to Haelwenn Monnier from comment #0) > > > > In the tree without changes since 2019-12-11 (except stabilization). > > > > > > > > This is following to bug#709248, where it stabilized arches that where for > > > > the previous version, this one is for stabilizing new ones that weren't > > > > before because of klibc (arm, arm64, ia64, ppc64, hppa, m68k, sh, sparc). > > > > > > Can you elaborate on how KEYWORDS for klibc and mksh are related? > > > > klibc was a dependency of mksh but it haven't been maintained ( bug#653388 ) > > and only supports few arches so it limited keywording, dietlibc seems to be > > in about the same shape, so instead I removed it in favor of the system libc > > and only masked USE=static for glibc. > > I still don't see why app-shells/mksh needs to be stabilized on m68k, hppa64 > and other minor arches. I had no reason to not include them into the list with the others, I don't think it's only my call to decide which arches should stabilize it depending on how more-or-less minor they seem to be (and other than the experimental ones it's not that obvious, and m68k/sh/hppa/sparc seem more-to-less historic but not sure where the limit would be), arch testers can decide to drop this possibility of stabilizing and I won't bother again. Maybe there is something I missed from the GLEPs or wiki, and then sorry for the noise?
"Stabilization rules" in https://devmanual.gentoo.org/keywording/ touch lightly on when to add new arches. The simplest rule of thumb is usually: do STABLEREQ only for arches that are already stable on older versions. Otherwise you need some justification when adding new arch. Example would be that you are using the package on that arch. x86/amd64 are straightforward ones. The others are frequently not as arch teams might not have manpower to perform re-testing of packages in every STABLEREQ. Let's remove hppa and m68k.
arm64 stable, closing
