[gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

TL;DR
ia64/ppc/sparc teams are pretty much dead. They have been for a long
time and this won't change any time soon. Gentoo should focus its
resources on archs that are important and has the manpower to support.
Let us please drop these 3 archs to dev profiles to ease maintenance.

Dear all,
I'd like to request Council to consider my motion to drop the
ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much
dead, minus the automated workflows of ago. Two months ago I have
written to these 3 archs, and only received one reply from ppc agreeing
with my sentiment, with no response from ia64 or sparc, which in itself
is pretty telling.

Currently, architecture projects think adding their keywords is a
right, which I strongly disagree with. I believe being able to add (and
stable) your keywords is a privilege - namely it carries with it the
duty to react to keywording and stabilization requests in a timely
manner. Let's compare the state of ia64/ppc/sparc to, say alpha:

https://bugs.gentoo.org/show_bug.cgi?id=605278

alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still
not keyworded (the bot had some breakages due to jer again shifting
around all the bugs). Within 4 months these arches have not managed to
keyword those 4 packages. This is I believe the most striking example
of how the only work done for these archs are ago's automated stablereq
scripts. Why do I saw that keywording+stabling your arch is a
privilege? Maintenance of packages is hampered by archs not stabling,
because we cannot clean up broken packages. Adding keywords is a two-
way street - if you don't act speedily, you're breaking part of the
maintainer-arch social contract.

Please don't turn this into a massive bikeshedding contest and just
admit that it is extremely unlikely that these archs will see more
activity in the near future. We should focus our resources on more
important archs (arm64 maybe?) instead of these. I know you have that
old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away
from installing Gentoo on, but the pain for maintainers and the rest of
the community is just too great. If someone steps up to do the work, we
can then move archs back to a stable profile, but so long as they
linger in their present state, let's call a spade a spade.

Anyhow, I formally request the Council to vote on dropping these archs
to unstable/exp profiles for the next Council meeting, explicitly
overriding any arch concerns that are likely to awake now and going to
be running around like headless chicken.

David

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Dirkjan Ochtman]

On Sun, May 7, 2017 at 9:23 PM, David Seifert <soap@gentoo.org> wrote:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.

+1 good idea. The slowest arches slow things down for everyone else.

Cheers,

Dirkjan

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

On nie, 2017-05-07 at 21:23 +0200, David Seifert wrote:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.
> 
> Dear all,
> I'd like to request Council to consider my motion to drop the
> ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much
> dead, minus the automated workflows of ago. Two months ago I have
> written to these 3 archs, and only received one reply from ppc agreeing
> with my sentiment, with no response from ia64 or sparc, which in itself
> is pretty telling.
> 
> Currently, architecture projects think adding their keywords is a
> right, which I strongly disagree with. I believe being able to add (and
> stable) your keywords is a privilege - namely it carries with it the
> duty to react to keywording and stabilization requests in a timely
> manner. Let's compare the state of ia64/ppc/sparc to, say alpha:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=605278
> 
> alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still
> not keyworded (the bot had some breakages due to jer again shifting
> around all the bugs). Within 4 months these arches have not managed to
> keyword those 4 packages. This is I believe the most striking example
> of how the only work done for these archs are ago's automated stablereq
> scripts. Why do I saw that keywording+stabling your arch is a
> privilege? Maintenance of packages is hampered by archs not stabling,
> because we cannot clean up broken packages. Adding keywords is a two-
> way street - if you don't act speedily, you're breaking part of the
> maintainer-arch social contract.
> 
> Please don't turn this into a massive bikeshedding contest and just
> admit that it is extremely unlikely that these archs will see more
> activity in the near future. We should focus our resources on more
> important archs (arm64 maybe?) instead of these. I know you have that
> old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away
> from installing Gentoo on, but the pain for maintainers and the rest of
> the community is just too great. If someone steps up to do the work, we
> can then move archs back to a stable profile, but so long as they
> linger in their present state, let's call a spade a spade.
> 
> Anyhow, I formally request the Council to vote on dropping these archs
> to unstable/exp profiles for the next Council meeting, explicitly
> overriding any arch concerns that are likely to awake now and going to
> be running around like headless chicken.
> 

I'm against. Turning more arches into dev/exp only introduces hidden
depgraph breakages. I think it'd be better if we looked into
the arch.desc proposal and just disabled stable keywords for those
architectures.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Am Sonntag, 7. Mai 2017, 22:24:35 CEST schrieb Michał Górny:
>
> > Anyhow, I formally request the Council to vote on dropping these archs
> > to unstable/exp profiles for the next Council meeting, explicitly
> > overriding any arch concerns that are likely to awake now and going to
> > be running around like headless chicken.
> 
> I'm against. Turning more arches into dev/exp only introduces hidden
> depgraph breakages. I think it'd be better if we looked into
> the arch.desc proposal and just disabled stable keywords for those
> architectures.

That's also what I would prefer (this is exactly what arches.desc is good 
for).

[I'm later going to make some updates over there taking the feedback into 
account.]

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Sun, 2017-05-07 at 22:24 +0200, Michał Górny wrote:
> I'm against. Turning more arches into dev/exp only introduces hidden
> depgraph breakages. I think it'd be better if we looked into
> the arch.desc proposal and just disabled stable keywords for those
> architectures.
> 

This is probably the smaller problem. The link shows a bug where none
of the aforementioned arch teams have keyworded the requested packages
in 4 months. How would the arches.desc proposal fix "dead arch teams"?
Sure, it will make maintenance easier for pure stablereqs, but the
other half of keywording does not happen. All the ia64/ppc/sparc
KEYWORDREQs I have filed for sci-* packages I have closed and
dekeyworded for revdeps. We have had KEYWORDREQs open for over a year
with 0 activity. If the keywording inactivity continues, I will also
continue to dekeyword packages.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

On Sun, 07 May 2017 22:53:52 +0200
David Seifert <soap@gentoo.org> wrote:

> This is probably the smaller problem. The link shows a bug where none
> of the aforementioned arch teams have keyworded the requested packages
> in 4 months. How would the arches.desc proposal fix "dead arch teams"?
> Sure, it will make maintenance easier for pure stablereqs, but the
> other half of keywording does not happen. All the ia64/ppc/sparc
> KEYWORDREQs I have filed for sci-* packages I have closed and
> dekeyworded for revdeps. We have had KEYWORDREQs open for over a year
> with 0 activity. If the keywording inactivity continues, I will also
> continue to dekeyword packages

I think its more "and" not "or", wherein arches.desc provides a pathway
that makes dropping these profiles to exp less problematic.

1. Introduce arches.desc
2. Brand problem arches with the relevant flags
3. Drop problem arches to dev/exp

That way we can still do some relevant keyword consistency checks
while not holding back stable. 

Currently dropping arches to dev/exp tends to imply that *all* keywording
consistency goes out the window into the EDONTCARE bucket, where the desired
outcome may only be certain *types* of keywording consistency (namely: stable)
is EDONTCARE but overall consistency (keywords being present) is still desired.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Mikle Kolyada]

07.05.2017 22:23, David Seifert пишет:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.
>
> Dear all,
> I'd like to request Council to consider my motion to drop the
> ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much
> dead, minus the automated workflows of ago. Two months ago I have
> written to these 3 archs, and only received one reply from ppc agreeing
> with my sentiment, with no response from ia64 or sparc, which in itself
> is pretty telling.
>
> Currently, architecture projects think adding their keywords is a
> right, which I strongly disagree with. I believe being able to add (and
> stable) your keywords is a privilege - namely it carries with it the
> duty to react to keywording and stabilization requests in a timely
> manner. Let's compare the state of ia64/ppc/sparc to, say alpha:
>
> https://bugs.gentoo.org/show_bug.cgi?id=605278
>
> alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still
> not keyworded (the bot had some breakages due to jer again shifting
> around all the bugs). Within 4 months these arches have not managed to
> keyword those 4 packages. This is I believe the most striking example
> of how the only work done for these archs are ago's automated stablereq
> scripts. Why do I saw that keywording+stabling your arch is a
> privilege? Maintenance of packages is hampered by archs not stabling,
> because we cannot clean up broken packages. Adding keywords is a two-
> way street - if you don't act speedily, you're breaking part of the
> maintainer-arch social contract.
>
> Please don't turn this into a massive bikeshedding contest and just
> admit that it is extremely unlikely that these archs will see more
> activity in the near future. We should focus our resources on more
> important archs (arm64 maybe?) instead of these. I know you have that
> old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away
> from installing Gentoo on, but the pain for maintainers and the rest of
> the community is just too great. If someone steps up to do the work, we
> can then move archs back to a stable profile, but so long as they
> linger in their present state, let's call a spade a spade.
>
> Anyhow, I formally request the Council to vote on dropping these archs
> to unstable/exp profiles for the next Council meeting, explicitly
> overriding any arch concerns that are likely to awake now and going to
> be running around like headless chicken.
>
> David
>
Against. Do not touch things you are not working on, council has already
dropped m68k s390 and sh to exp few years ago. Now we have a big mess
there and only, while ia64 sparc and co have slow but progress and
mature enough stable profiles.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Dirkjan Ochtman]

On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada <zlogene@gentoo.org> wrote:
> Against. Do not touch things you are not working on, council has already
> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
> there and only, while ia64 sparc and co have slow but progress and
> mature enough stable profiles.

Obviously we should prevent big messes from happening. But it's a
mistake that things I don't work on don't affect me -- work left over
by lagging arch teams can affect me in many ways, in terms of having
to keep older versions of my packages working and in the tree, and
having to keep track of many more KEYWORDREQs and STABLEREQs.

To me it's likely that the pace of stabilization for everyone is
affected by the slower arches, in the sense that maintainers are less
likely to stabilize newer versions if they see that arches can't keep
up with previous requests. This means that even stable amd64 users are
affected to some extent by ppc being slow to stabilize.

Cheers,

Dirkjan

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michał Górny]

Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman <djc@gentoo.org> napisał(a):
>On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada <zlogene@gentoo.org>
>wrote:
>> Against. Do not touch things you are not working on, council has
>already
>> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
>> there and only, while ia64 sparc and co have slow but progress and
>> mature enough stable profiles.
>
>Obviously we should prevent big messes from happening. But it's a
>mistake that things I don't work on don't affect me -- work left over
>by lagging arch teams can affect me in many ways, in terms of having
>to keep older versions of my packages working and in the tree, and
>having to keep track of many more KEYWORDREQs and STABLEREQs.
>
>To me it's likely that the pace of stabilization for everyone is
>affected by the slower arches, in the sense that maintainers are less
>likely to stabilize newer versions if they see that arches can't keep
>up with previous requests. This means that even stable amd64 users are
>affected to some extent by ppc being slow to stabilize.

Plus the usual mess of having to keep up with multiple large stablereqs for stuff where we need to stabilize newer while some arches are still two stabilizations behind.

Not to mention when we want to stabilize a new version but the arches still haven't even keyworded it...

>
>Cheers,
>
>Dirkjan


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Ultrabug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/05/2017 15:49, Michał Górny wrote:
> Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman <djc@gentoo.org>
> napisał(a):
>> On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada
>> <zlogene@gentoo.org> wrote:
>>> Against. Do not touch things you are not working on, council
>>> has
>> already
>>> dropped m68k s390 and sh to exp few years ago. Now we have a
>>> big mess there and only, while ia64 sparc and co have slow but
>>> progress and mature enough stable profiles.
>> 
>> Obviously we should prevent big messes from happening. But it's
>> a mistake that things I don't work on don't affect me -- work
>> left over by lagging arch teams can affect me in many ways, in
>> terms of having to keep older versions of my packages working and
>> in the tree, and having to keep track of many more KEYWORDREQs
>> and STABLEREQs.
>> 
>> To me it's likely that the pace of stabilization for everyone is 
>> affected by the slower arches, in the sense that maintainers are
>> less likely to stabilize newer versions if they see that arches
>> can't keep up with previous requests. This means that even stable
>> amd64 users are affected to some extent by ppc being slow to
>> stabilize.
> 
> Plus the usual mess of having to keep up with multiple large
> stablereqs for stuff where we need to stabilize newer while some
> arches are still two stabilizations behind.
> 
> Not to mention when we want to stabilize a new version but the
> arches still haven't even keyworded it...

That !

We can all face that our latency is not good for our traction on a
wider user base.

Freeing ourselves from this kind of latency is energy saving and thus
a positive move imho.

> 
>> 
>> Cheers,
>> 
>> Dirkjan
> 
> 
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSqwxDKv5211qJQBiIqJBJLtlj6EwUCWRHIfQAKCRAqJBJLtlj6
EwmzAPwP2a6MgG3aE6EdSuPLjsabytT+qRskanNMJtiVsQqWpwD+NsGzWk9ff1RS
2mZYazWC5U9HBD3MzPG65jhX8Dl43jA=
=h+5a
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Am Montag, 8. Mai 2017, 12:49:32 CEST schrieb Mikle Kolyada:
>
> Against. Do not touch things you are not working on, council has already
> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
> there and only, while ia64 sparc and co have slow but progress and
> mature enough stable profiles.

No objections against having many arches, but:

If an arch is keyworded / stable on more packages than that team can 
reasonably take care of, that needs to be corrected somehow. 

The easiest solution is for the arch team to remove keywords until they have a 
reasonable response time again. And if the arch team doesn't do that by 
itself, well, ...

Having one-man teams block everybody else hurts Gentoo as a whole.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Mikle Kolyada]

08.05.2017 21:55, Andreas K. Huettel пишет:
> Am Montag, 8. Mai 2017, 12:49:32 CEST schrieb Mikle Kolyada:
>> Against. Do not touch things you are not working on, council has already
>> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
>> there and only, while ia64 sparc and co have slow but progress and
>> mature enough stable profiles.
> No objections against having many arches, but:
>
> If an arch is keyworded / stable on more packages than that team can 
> reasonably take care of, that needs to be corrected somehow. 
>
> The easiest solution is for the arch team to remove keywords until they have a 
> reasonable response time again. And if the arch team doesn't do that by 
> itself, well, ...
>
> Having one-man teams block everybody else hurts Gentoo as a whole.
>
We have appropriate hardware if people wanna do the work, jut go & make
things better :), I do not think someone from existing arch teams has
something against that

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Mon, 2017-05-08 at 22:08 +0300, Mikle Kolyada wrote:
> We have appropriate hardware if people wanna do the work, jut go &
> make
> things better :), I do not think someone from existing arch teams has
> something against that

Ok so let me get the logic right:

1) Arch teams can add their keywords to ebuilds in general, without the
maintainer having a say in that.
2) Arch team goes MIA because <reasons/>.
3) Now the maintainer has to chase down machines and do KEYWORDREQ
testing on other arches because we cannot admit that some archs are not
maintained.

Please confirm the above logic. If that logic is about right, I am
sorry, but I disagree. I will rather dekeyword unmaintained archs. I am
not going to babysit arch teams in doing their work for them.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Mikle Kolyada]

08.05.2017 22:21, David Seifert пишет:
> On Mon, 2017-05-08 at 22:08 +0300, Mikle Kolyada wrote:
>> We have appropriate hardware if people wanna do the work, jut go &
>> make
>> things better :), I do not think someone from existing arch teams has
>> something against that
> Ok so let me get the logic right:
>
> 1) Arch teams can add their keywords to ebuilds in general, without the
> maintainer having a say in that.
> 2) Arch team goes MIA because <reasons/>.
> 3) Now the maintainer has to chase down machines and do KEYWORDREQ
> testing on other arches because we cannot admit that some archs are not
> maintained.
>
> Please confirm the above logic. If that logic is about right, I am
> sorry, but I disagree. I will rather dekeyword unmaintained archs. I am
> not going to babysit arch teams in doing their work for them.
>
To clarify:

I have not seen the draft of proper reverting these arches to exp or
dev, if it will be like sh or s390, better kill the horse like debian
did to alpha and hppa, without riding it.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

> 
> I have not seen the draft of proper reverting these arches to exp or
> dev, if it will be like sh or s390, better kill the horse like debian
> did to alpha and hppa, without riding it.

The current state of sh and s390 happened because vapier suggested the profiles 
should become "exp". 

My original plan back then was to just drop all stable keywords (but have 
repoman continue checking ~arch).

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Mart Raudsepp]

Ühel kenal päeval, E, 08.05.2017 kell 22:08, kirjutas Mikle Kolyada:
> 
> 08.05.2017 21:55, Andreas K. Huettel пишет:
> > Am Montag, 8. Mai 2017, 12:49:32 CEST schrieb Mikle Kolyada:
> > > Against. Do not touch things you are not working on, council has
> > > already
> > > dropped m68k s390 and sh to exp few years ago. Now we have a big
> > > mess
> > > there and only, while ia64 sparc and co have slow but progress
> > > and
> > > mature enough stable profiles.
> > 
> > No objections against having many arches, but:
> > 
> > If an arch is keyworded / stable on more packages than that team
> > can 
> > reasonably take care of, that needs to be corrected somehow. 
> > 
> > The easiest solution is for the arch team to remove keywords until
> > they have a 
> > reasonable response time again. And if the arch team doesn't do
> > that by 
> > itself, well, ...
> > 
> > Having one-man teams block everybody else hurts Gentoo as a whole.
> > 
> 
> We have appropriate hardware if people wanna do the work, jut go &
> make
> things better :), I do not think someone from existing arch teams has
> something against that

We do not want to do the work, as the benefit ratio is bordering zero.
IA64 is dead hardware. PPC is dead (ppc != ppc64). SPARC, well, I guess
Fujitsu is trying, maybe they should provide a modern dev machine :D

Lets have the time of those just keeping it alive by semi-automated
scripted STABLEREQ fulfilling spend that time on alive hardware
instead.

Meanwhile I have various stuff sticking around due to lack of handling
keyword requests, including stuff that really needs cleaning up to
finish things being really fixed.
I actually see one person who seems to care about IA64 a but, but looks
like no-one is actioning arch testing anymore.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

Am Montag, 8. Mai 2017, 21:08:26 CEST schrieb Mikle Kolyada:

> > The easiest solution is for the arch team to remove keywords until they
> > have a reasonable response time again. And if the arch team doesn't do
> > that by itself, well, ...
> > 
> > Having one-man teams block everybody else hurts Gentoo as a whole.
> 
> We have appropriate hardware if people wanna do the work, jut go & make
> things better :), I do not think someone from existing arch teams has
> something against that

I'm sorry, but I can think of about a dozen things where my Gentoo time is 
spent in a more useful way.

(With useful being not so much defined with what I personally find fun, but with 
what brings Gentoo and its userbase forward.)

Prove to me that more than 10 persons are interested in Gentoo on any of sh, 
s390, m68k, ia64, sparc.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[James McMechan]

> > > The easiest solution is for the arch team to remove keywords until they
> > > have a reasonable response time again. And if the arch team doesn't do
> > > that by itself, well, ...
> > > 
> > > Having one-man teams block everybody else hurts Gentoo as a whole.
> > 
> > We have appropriate hardware if people wanna do the work, jut go & make
> > things better :), I do not think someone from existing arch teams has
> > something against that
>
> I'm sorry, but I can think of about a dozen things where my Gentoo time is 
> spent in a more useful way.
>
> (With useful being not so much defined with what I personally find fun, but with 
> what brings Gentoo and its userbase forward.)
>
> Prove to me that more than 10 persons are interested in Gentoo on any of sh, 
> s390, m68k, ia64, sparc.

well I currently have Gentoo up on
bunch of arm v5,v6,v7
1 arm64
5 mips
1 mips64
2 ppc
1 ppc64
2 sparc (64bit)
bunch of x86
bunch of amd64
and am still playing with
1 sh3

So how many do I count as 1,2,3-12? ;)

Silly Notes:
While I personally considered IA64 useless shortly after arrival, Intel has just (5/11/17) announced another bump in that family the 9700 Series.

SPARC hardware is stilling being sold by both Fujistu and Oracle, e.g. the M12 series released in April,
but it is mostly sold to those already invested in it.
Looking I also saw updates in January for the SPARC32:LEON4 processor
The OpenSPARC.net SPARC64:T1 & T2 seem less active, may just be my lack of google-fu

PowerPC is still running along, mostly embedded for the 32bit version, and IBM still likes to sell big iron with 64bit Power processors.

SuperH is even having a tiny bit of a renaissance, what with the J-core.org people building a VHDL open source version for FPGA/ASIC


Please note: that I am not objecting to having arch keywords on only the base @system packages for the minor archs, hopefully it will save a small mountain of effort.

Would it be worthwhile to have an other/minor/general keyword shared among the arches?
e.g. have keywords always try their arch keyword first and if it is not present look for other/minor/general keyword?
sort of like */~*/-* except if your arch is mentioned use that instead.
It could make things easier many packages /should/ not care about which arch it is exactly.
I could see it as trying a stable request: 3 arches send yes and dead silence from everybody else...
So after a reasonable time mark the 3 that replied and let everyone who did not follow the general keyword until they reply.

My current interpretation:

amd64 recent desktops/laptops
x86 most older desktops/laptops
arm most cellphones/tablets
arm64 upcoming cellphones/tablets e.g. raspberry pi3. not yet common running 64bit.
mips gobs of routers & embedded systems.
everything else niche markets <- Hi, I fit in here a lot.

Jim McMechan

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Walter Dnes]

On Sun, May 14, 2017 at 04:56:29PM +0000, James McMechan wrote

> Silly Notes:
> While I personally considered IA64 useless shortly after arrival,
> Intel has just (5/11/17) announced another bump in that family the
> 9700 Series.

  And it will also be the last Itanium released http://www.pcworld.com/article/3196080/data-center/intels-itanium-once-destined-to-replace-x86-in-pcs-hits-end-of-line.html

  The contract/agreement, between HPE and Intel, covers development of
Itanium through to the end of 2017.  Intel is not selling enough of them
to warrant further development.  Intel has been urging Itanium users to
migrate to high-end Xeons.  Some features, formerly available from Intel
only on Itanium, have started showing up on high-end Xeons.

  An interesting, somewhat cynical, post on Slashdot...
https://hardware.slashdot.org/comments.pl?sid=10604939&cid=54412501
suggests that Intel came up with a radically different design for
Itanium, versus x86, specifically to avoid a cross-licencing agreement
that allows AMD to clone Intel x86 and x86_64 cpus.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Mon, 2017-05-08 at 13:49 +0300, Mikle Kolyada wrote:
> Against. Do not touch things you are not working on, council has
> already
> dropped m68k s390 and sh to exp few years ago. Now we have a big mess
> there and only, while ia64 sparc and co have slow but progress and
> mature enough stable profiles.

Again, I have had KEYWORDREQs open for more than a year with 0
activity. The only way to get any activity on these arches is to
trigger the easteregg of going straight-to-stable, which ago's scripts
catch (unlike KEYWORDREQs). This is ofc the total antithesis of using
~arch as a staging ground for stable keywords, but apparently that
seems to be desired.

I am absolutely willing to postpone the vote on this to after the
arches.desc GLEP is finished, but being in denial over dead archs is
helping no-one.

If all of this ends in one big bikeshedding fest again, I will start
dekeywording packages. Fortunately for me, I won't get any complaints
(because the arch teams are dead).

If the walls are mouldy, do you just paint over them and pretend
everything is fine?

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michael Weber]

On 05/08/2017 09:13 PM, David Seifert wrote:
> If all of this ends in one big bikeshedding fest again, I will start
> dekeywording packages. Fortunately for me, I won't get any complaints
> (because the arch teams are dead).
formal complaint, powerpc team is alive, and I'm lead.



-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
> On 05/08/2017 09:13 PM, David Seifert wrote:
> > If all of this ends in one big bikeshedding fest again, I will
> > start
> > dekeywording packages. Fortunately for me, I won't get any
> > complaints
> > (because the arch teams are dead).
> 
> formal complaint, powerpc team is alive, and I'm lead.

https://bugs.gentoo.org/show_bug.cgi?id=546082

You call that alive?

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michael Weber]

On 05/14/2017 12:44 PM, David Seifert wrote:
> On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
>> On 05/08/2017 09:13 PM, David Seifert wrote:
>>> If all of this ends in one big bikeshedding fest again, I will
>>> start
>>> dekeywording packages. Fortunately for me, I won't get any
>>> complaints
>>> (because the arch teams are dead).
>>
>> formal complaint, powerpc team is alive, and I'm lead.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=546082
> 
> You call that alive?
> 
Well, I'm working on stabilization for some months and started 
keywordings just recently.

FTR, nobody saw the need to migrated this bug Component:Keywording (was 
[old] ...) and it didn't show up on my radar, nor on x86s.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

On nie, 2017-05-14 at 12:52 +0200, Michael Weber wrote:
> On 05/14/2017 12:44 PM, David Seifert wrote:
> > On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
> > > On 05/08/2017 09:13 PM, David Seifert wrote:
> > > > If all of this ends in one big bikeshedding fest again, I will
> > > > start
> > > > dekeywording packages. Fortunately for me, I won't get any
> > > > complaints
> > > > (because the arch teams are dead).
> > > 
> > > formal complaint, powerpc team is alive, and I'm lead.
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=546082
> > 
> > You call that alive?
> > 
> 
> Well, I'm working on stabilization for some months and started 
> keywordings just recently.
> 
> FTR, nobody saw the need to migrated this bug Component:Keywording (was 
> [old] ...) and it didn't show up on my radar, nor on x86s.
> 

Why would you expect to developers spend their effort on moving bugs to
new keywording workflow *after* the arch teams have been neglecting them
for 1.5 years?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michael Weber]

On 05/14/2017 01:05 PM, Michał Górny wrote:
> On nie, 2017-05-14 at 12:52 +0200, Michael Weber wrote:
>> On 05/14/2017 12:44 PM, David Seifert wrote:
>>> On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
>>>> On 05/08/2017 09:13 PM, David Seifert wrote:
>>>>> If all of this ends in one big bikeshedding fest again, I will
>>>>> start
>>>>> dekeywording packages. Fortunately for me, I won't get any
>>>>> complaints
>>>>> (because the arch teams are dead).
>>>>
>>>> formal complaint, powerpc team is alive, and I'm lead.
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=546082
>>>
>>> You call that alive?
>>>
>>
>> Well, I'm working on stabilization for some months and started
>> keywordings just recently.
>>
>> FTR, nobody saw the need to migrated this bug Component:Keywording (was
>> [old] ...) and it didn't show up on my radar, nor on x86s.
>>
> 
> Why would you expect to developers spend their effort on moving bugs to
> new keywording workflow *after* the arch teams have been neglecting them
> for 1.5 years?
> 
Because we (or some subset) agreed on the "new keywording workflow" and 
we all obliged to play by the rules?

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

[gentoo-dev] Re: Dropping ia64/ppc/sparc profiles to dev/exp

[Duncan]

Michael Weber posted on Sun, 14 May 2017 13:17:36 +0200 as excerpted:

> On 05/14/2017 01:05 PM, Michał Górny wrote:
>> On nie, 2017-05-14 at 12:52 +0200, Michael Weber wrote:
>>> On 05/14/2017 12:44 PM, David Seifert wrote:
>>>> On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote:
>>>>> On 05/08/2017 09:13 PM, David Seifert wrote:

>>>>>> If all of this ends in one big bikeshedding fest again, I will
>>>>>> start dekeywording packages. Fortunately for me, I won't get any
>>>>>> complaints (because the arch teams are dead).
>>>>>
>>>>> formal complaint, powerpc team is alive, and I'm lead.
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=546082
>>>>
>>>> You call that alive?
>>>>
>>>>
>>> Well, I'm working on stabilization for some months and started
>>> keywordings just recently.
>>>
>>> FTR, nobody saw the need to migrated this bug Component:Keywording
>>> (was [old] ...) and it didn't show up on my radar, nor on x86s.
>>>
>>>
>> Why would you expect to developers spend their effort on moving bugs to
>> new keywording workflow *after* the arch teams have been neglecting
>> them for 1.5 years?
>> 
> Because we (or some subset) agreed on the "new keywording workflow" and
> we all obliged to play by the rules?

Sure, for new bugs.

I don't believe it applies to still open old bugs, especially those filed 
and with no new activity for a year before the new workflow came to be.  
If they've not been touched in the then-current workflow in a year (and 
I'd argue something shorter, say 90 days, which just emphasizes how old 
those bugs really are), where's the justification to bother migrating 
them to the new workflow?  They should have been acted upon well before 
the new workflow came to be, and if people are bothering to migrate, I'd 
not blame that at all for migrating them to RESOLVED/WONTFIX (aka 
dekeywording as the older keyworded versions are removed), as to all 
indications that's the reality.

So maybe it's better for PPC they're /not/ migrated?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/14/17 6:38 AM, Michael Weber wrote:
> On 05/08/2017 09:13 PM, David Seifert wrote:
>> If all of this ends in one big bikeshedding fest again, I will start
>> dekeywording packages. Fortunately for me, I won't get any complaints
>> (because the arch teams are dead).
> formal complaint, powerpc team is alive, and I'm lead.
> 

I defer to the ppc lead's decision on this.  While I am okay with
dekeywording everything *but* @system for ppc, I prefer keeping ppc
keywords.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 1169 bytes --]

I would prefer PPC and for that matter arm (which are no longer security
supported) going the Non-stable route. This would prevent the need for
stabilization and everything but @system we can instruct the users to
use ~ppc.

This would also allow for security to not drop it from security
supported arches and just follow a more relaxed policy for non-stable
packages.

For those not familiar, we (security) only need to have the package in
tree and the vulnerable packages dropped, which is easily accomplished
by the maintainer with no need for arches to get involved.

Yury German (BlueKnight)

On 5/14/17 8:03 AM, Anthony G. Basile wrote:
> On 5/14/17 6:38 AM, Michael Weber wrote:
>> On 05/08/2017 09:13 PM, David Seifert wrote:
>>> If all of this ends in one big bikeshedding fest again, I will start
>>> dekeywording packages. Fortunately for me, I won't get any complaints
>>> (because the arch teams are dead).
>> formal complaint, powerpc team is alive, and I'm lead.
>>
> 
> I defer to the ppc lead's decision on this.  While I am okay with
> dekeywording everything *but* @system for ppc, I prefer keeping ppc
> keywords.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Mon, 2017-05-15 at 15:33 -0400, Yury German wrote:
> I would prefer PPC and for that matter arm (which are no longer
> security
> supported) going the Non-stable route. This would prevent the need
> for
> stabilization and everything but @system we can instruct the users to
> use ~ppc.
> 
> This would also allow for security to not drop it from security
> supported arches and just follow a more relaxed policy for non-stable
> packages.
> 
> For those not familiar, we (security) only need to have the package
> in
> tree and the vulnerable packages dropped, which is easily
> accomplished
> by the maintainer with no need for arches to get involved.
> 
> Yury German (BlueKnight)

This solution doesn't go far enough for me - mainly because it still
makes KEYWORDREQs a pain.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1901 bytes --]

On 2017-05-07 21:23, David Seifert wrote:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.

+1

In security project we are currently discussing something similar. I.e.
we wanted to ask council (after talking with ATs) to drop security
coverage for sparc like we have already dropped support for ia64.

While discussing I raised the question if it isn't confusing to have

  - ~arch (testing)
  - arch (stable)
  - arch with security coverage (stable without security)

and suggested to drop the latter. Given that gentoo.org says "Security
is a primary focus of Gentoo Linux" it doesn't make any sense for me to
have a *stable* architecture without security coverage.

It isn't like security project adds any additional load to any arch
team, an architecture capable to keep up with normal keyword and
stabilization requests should also be able to keep up with security. In
other words: Any architecture lacking behind security is also lacking
behind normal keyword and stabilization procedure...

So I would highly appreciate such a change.

If we won't do something like that but will drop security coverage,
managing all the open security bugs will become very challenging because
then we will also have to track bugs where architectures with security
coverage are done but stable architectures without security coverage
blocking cleanup and things like that.

But to be clear: I am just sharing *my* view with you. I am not security
project lead so I am not speaking for the project. I guess Yury
(blueknight), current security project lead, will jump into this
discussion very soon.


-- 
Regards,
Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Rich Freeman]

On Mon, May 8, 2017 at 9:21 AM, Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> It isn't like security project adds any additional load to any arch
> team, an architecture capable to keep up with normal keyword and
> stabilization requests should also be able to keep up with security.

What about arches that use stable keywords only on a core set of
system packages to indicate that they're usable, so that they can have
a stage3 that actually boots?  I'm not sure they even keep up with
security in this case.

Perhaps they could just use ~arch for the same purpose, but then we'd
need to have a policy that REMOVES ~arch when doing bumps on those
architectures, which is not our current practice.  Otherwise a revbump
could break stage3 on those arches.

I'm not sure that stable+secure is necessarily a black-and-white thing
on our non-mainstream arches.  Honestly, I think that people who want
to run linux on MIPS/sparc/etc are probably happy enough just to have
something that boots.

-- 
Rich

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Matt Turner]

On Mon, May 8, 2017 at 6:48 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, May 8, 2017 at 9:21 AM, Thomas Deutschmann <whissi@gentoo.org> wrote:
>>
>> It isn't like security project adds any additional load to any arch
>> team, an architecture capable to keep up with normal keyword and
>> stabilization requests should also be able to keep up with security.
>
> What about arches that use stable keywords only on a core set of
> system packages to indicate that they're usable, so that they can have
> a stage3 that actually boots?  I'm not sure they even keep up with
> security in this case.

Yes, this is the right thing to do.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]

Rich,

Core should be fine to have a system that at least boots. And security
still tracks ~arch's to get the system secured by removing vulnerable
packages as time permits.

We can not have an arch though blocking the security of the whole
distribution because we can not call for cleanup or release the GLSA,
waiting for a stabilization of a non-core package, while the actual
package has been in a tree in ~arch status for weeks or months. If we
limit the stable packages to only those that are required for core OS
boot, then the stabilization of the limited packages should be quicker.


On 5/8/17 6:48 AM, Rich Freeman wrote:
> On Mon, May 8, 2017 at 9:21 AM, Thomas Deutschmann <whissi@gentoo.org> wrote:
>>
>> It isn't like security project adds any additional load to any arch
>> team, an architecture capable to keep up with normal keyword and
>> stabilization requests should also be able to keep up with security.
> 
> What about arches that use stable keywords only on a core set of
> system packages to indicate that they're usable, so that they can have
> a stage3 that actually boots?  I'm not sure they even keep up with
> security in this case.
> 
> Perhaps they could just use ~arch for the same purpose, but then we'd
> need to have a policy that REMOVES ~arch when doing bumps on those
> architectures, which is not our current practice.  Otherwise a revbump
> could break stage3 on those arches.
> 
> I'm not sure that stable+secure is necessarily a black-and-white thing
> on our non-mainstream arches.  Honestly, I think that people who want
> to run linux on MIPS/sparc/etc are probably happy enough just to have
> something that boots.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Rich Freeman]

On Tue, May 9, 2017 at 12:23 AM, Yury German <blueknight@gentoo.org> wrote:
>
> we can not call for cleanup or release the GLSA,
> waiting for a stabilization of a non-core package, while the actual
> package has been in a tree in ~arch status for weeks or months.

Why not?  If an arch is considered a non-security-supported arch then
you would just ignore it in a security bug.

-- 
Rich

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1395 bytes --]

On 2017-05-09 10:12, Rich Freeman wrote:
> Why not?  If an arch is considered a non-security-supported arch
> then you would just ignore it in a security bug.

We dropped security coverage already for ia64 and are in the process to
drop it for sparc as well.

So how do you want to cleanup a package which is the last ebuild of the
package and still marked stabled for ia64/sparc? You cannot. If you are
lucky you would only remove a package without any rdeps. But in most
cases you are breaking the tree.


> Otherwise a revbump could break stage3 on those arches.

Is this really a problem? What could happen:

Worst case: Existing stage3 for this specific dev/exp architecture will
be very old because any attempt to refresh the stage3 image will fail
with a build error. However, the last working stage3 image won't go away
until it was replaced by a newer working one...

Also, is this different from current status? Not really: If this
architecture would be capable to keep up with all the other major
architectures the stage3 image would be in a current working state.
Build errors would be solved in time. We wouldn't discuss dropping them.
So we are only talking about architectures which have shown that they
are not able to keep up. And those architectures are already lacking
behind, i.e. they don't have a current stage3...


-- 
Regards,
Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/9/17 8:01 AM, Thomas Deutschmann wrote:
> On 2017-05-09 10:12, Rich Freeman wrote:
>> Why not?  If an arch is considered a non-security-supported arch
>> then you would just ignore it in a security bug.
> 
> We dropped security coverage already for ia64 and are in the process to
> drop it for sparc as well.
> 
> So how do you want to cleanup a package which is the last ebuild of the
> package and still marked stabled for ia64/sparc? You cannot. If you are
> lucky you would only remove a package without any rdeps. But in most
> cases you are breaking the tree.
> 
> 
>> Otherwise a revbump could break stage3 on those arches.
> 
> Is this really a problem? What could happen:
> 
> Worst case: Existing stage3 for this specific dev/exp architecture will
> be very old because any attempt to refresh the stage3 image will fail
> with a build error. However, the last working stage3 image won't go away
> until it was replaced by a newer working one...
> 

I maintain quite a few ppc stage3's for uclibc and musl.  I would
appreciate keeping ppc as is.  It is still a useful arch for many
devices today, eg. some high end Mikrotik routers.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Dirkjan Ochtman]

On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> I maintain quite a few ppc stage3's for uclibc and musl.  I would
> appreciate keeping ppc as is.  It is still a useful arch for many
> devices today, eg. some high end Mikrotik routers.

So are you willing to do the work? There are currently 68 open keyword
requests (oldest one reported in 2011) and 48 open stable requests
(oldest one reported in November).

Cheers,

Dirkjan

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> > I maintain quite a few ppc stage3's for uclibc and musl.  I would
> > appreciate keeping ppc as is.  It is still a useful arch for many
> > devices today, eg. some high end Mikrotik routers.
> 
> So are you willing to do the work? There are currently 68 open keyword
> requests (oldest one reported in 2011) and 48 open stable requests
> (oldest one reported in November).

+1000

If we are going to keep ppc as a stable profile, someone needs to do the
keywording and stabilization for it.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/10/17 11:08 AM, William Hubbs wrote:
> On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
>> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>> I maintain quite a few ppc stage3's for uclibc and musl.  I would
>>> appreciate keeping ppc as is.  It is still a useful arch for many
>>> devices today, eg. some high end Mikrotik routers.
>>
>> So are you willing to do the work? There are currently 68 open keyword
>> requests (oldest one reported in 2011) and 48 open stable requests
>> (oldest one reported in November).
> 
> +1000
> 
> If we are going to keep ppc as a stable profile, someone needs to do the
> keywording and stabilization for it.
> 
> William
> 

the current plan by Soap et al is to drop all keywords except for
@system and leave the profiles stable.  this works for me and addresses
your concern.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Mart Raudsepp]

Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G.
Basile:
> On 5/10/17 11:08 AM, William Hubbs wrote:
> > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
> > > On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gento
> > > o.org> wrote:
> > > > I maintain quite a few ppc stage3's for uclibc and musl.  I
> > > > would
> > > > appreciate keeping ppc as is.  It is still a useful arch for
> > > > many
> > > > devices today, eg. some high end Mikrotik routers.
> > > 
> > > So are you willing to do the work? There are currently 68 open
> > > keyword
> > > requests (oldest one reported in 2011) and 48 open stable
> > > requests
> > > (oldest one reported in November).
> > 
> > +1000
> > 
> > If we are going to keep ppc as a stable profile, someone needs to
> > do the
> > keywording and stabilization for it.
> > 
> > William
> > 
> 
> the current plan by Soap et al is to drop all keywords except for
> @system and leave the profiles stable.  this works for me and
> addresses
> your concern.

Are we talking about dropping all keywords besides @system things from
ppc to ~ppc or completely?
I guess the latter as the former doesn't solve keywording lag?


Mart

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote:
> Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G.
> Basile:
> > On 5/10/17 11:08 AM, William Hubbs wrote:
> > > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
> > > > On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gen
> > > > to
> > > > o.org> wrote:
> > > > > I maintain quite a few ppc stage3's for uclibc and musl.  I
> > > > > would
> > > > > appreciate keeping ppc as is.  It is still a useful arch for
> > > > > many
> > > > > devices today, eg. some high end Mikrotik routers.
> > > > 
> > > > So are you willing to do the work? There are currently 68 open
> > > > keyword
> > > > requests (oldest one reported in 2011) and 48 open stable
> > > > requests
> > > > (oldest one reported in November).
> > > 
> > > +1000
> > > 
> > > If we are going to keep ppc as a stable profile, someone needs to
> > > do the
> > > keywording and stabilization for it.
> > > 
> > > William
> > > 
> > 
> > the current plan by Soap et al is to drop all keywords except for
> > @system and leave the profiles stable.  this works for me and
> > addresses
> > your concern.
> 
> Are we talking about dropping all keywords besides @system things
> from
> ppc to ~ppc or completely?
> I guess the latter as the former doesn't solve keywording lag?
> 
> 
> Mart
> 

The latter, as that is the only way to restore sanity. I will be
preparing a list.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/10/17 3:29 PM, David Seifert wrote:
> On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote:
>> Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G.
>> Basile:
>>> On 5/10/17 11:08 AM, William Hubbs wrote:
>>>> On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
>>>>> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gen
>>>>> to
>>>>> o.org> wrote:
>>>>>> I maintain quite a few ppc stage3's for uclibc and musl.  I
>>>>>> would
>>>>>> appreciate keeping ppc as is.  It is still a useful arch for
>>>>>> many
>>>>>> devices today, eg. some high end Mikrotik routers.
>>>>>
>>>>> So are you willing to do the work? There are currently 68 open
>>>>> keyword
>>>>> requests (oldest one reported in 2011) and 48 open stable
>>>>> requests
>>>>> (oldest one reported in November).
>>>>
>>>> +1000
>>>>
>>>> If we are going to keep ppc as a stable profile, someone needs to
>>>> do the
>>>> keywording and stabilization for it.
>>>>
>>>> William
>>>>
>>>
>>> the current plan by Soap et al is to drop all keywords except for
>>> @system and leave the profiles stable.  this works for me and
>>> addresses
>>> your concern.
>>
>> Are we talking about dropping all keywords besides @system things
>> from
>> ppc to ~ppc or completely?
>> I guess the latter as the former doesn't solve keywording lag?
>>
>>
>> Mart
>>
> 
> The latter, as that is the only way to restore sanity. I will be
> preparing a list.
> 

So let's make sure we're on the same page -- here's my understanding.

1) For @system packages, we will have KEYWORDS="ppc" for the stable
versions and KEYWORDS="~ppc" for the rest.

2) For non @system packages we will remove both ppc and ~ppc keywords.

3) If for some reason I need to add back a package to build/maintain
stage3/4, I will rekeyword myself, but other than that, we will *not*
balloon the keywords.

4) I will take on the responsibility of stabilizing ppc @system packages
if need be.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Wed, 2017-05-10 at 15:40 -0400, Anthony G. Basile wrote:
> On 5/10/17 3:29 PM, David Seifert wrote:
> > On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote:
> > > Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G.
> > > Basile:
> > > > On 5/10/17 11:08 AM, William Hubbs wrote:
> > > > > On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman
> > > > > wrote:
> > > > > > On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness
> > > > > > @gen
> > > > > > to
> > > > > > o.org> wrote:
> > > > > > > I maintain quite a few ppc stage3's for uclibc and
> > > > > > > musl.  I
> > > > > > > would
> > > > > > > appreciate keeping ppc as is.  It is still a useful arch
> > > > > > > for
> > > > > > > many
> > > > > > > devices today, eg. some high end Mikrotik routers.
> > > > > > 
> > > > > > So are you willing to do the work? There are currently 68
> > > > > > open
> > > > > > keyword
> > > > > > requests (oldest one reported in 2011) and 48 open stable
> > > > > > requests
> > > > > > (oldest one reported in November).
> > > > > 
> > > > > +1000
> > > > > 
> > > > > If we are going to keep ppc as a stable profile, someone
> > > > > needs to
> > > > > do the
> > > > > keywording and stabilization for it.
> > > > > 
> > > > > William
> > > > > 
> > > > 
> > > > the current plan by Soap et al is to drop all keywords except
> > > > for
> > > > @system and leave the profiles stable.  this works for me and
> > > > addresses
> > > > your concern.
> > > 
> > > Are we talking about dropping all keywords besides @system things
> > > from
> > > ppc to ~ppc or completely?
> > > I guess the latter as the former doesn't solve keywording lag?
> > > 
> > > 
> > > Mart
> > > 
> > 
> > The latter, as that is the only way to restore sanity. I will be
> > preparing a list.
> > 
> 
> So let's make sure we're on the same page -- here's my understanding.
> 
> 1) For @system packages, we will have KEYWORDS="ppc" for the stable
> versions and KEYWORDS="~ppc" for the rest.
> 
> 2) For non @system packages we will remove both ppc and ~ppc
> keywords.
> 
> 3) If for some reason I need to add back a package to build/maintain
> stage3/4, I will rekeyword myself, but other than that, we will *not*
> balloon the keywords.
> 
> 4) I will take on the responsibility of stabilizing ppc @system
> packages
> if need be.
> 

That's the plan, correct.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]



On 5/10/17 12:40 PM, Anthony G. Basile wrote:
> On 5/10/17 3:29 PM, David Seifert wrote:

> So let's make sure we're on the same page -- here's my understanding.
> 
> 1) For @system packages, we will have KEYWORDS="ppc" for the stable
> versions and KEYWORDS="~ppc" for the rest.

So is this only for PPC or PPC64 as well?
Both are security supported arches, but if you are going this route they
will be dropped to non-secured arches leaving:

alpha, amd64, hppa, x86.

> 
> 2) For non @system packages we will remove both ppc and ~ppc keywords.
> 
> 3) If for some reason I need to add back a package to build/maintain
> stage3/4, I will rekeyword myself, but other than that, we will *not*
> balloon the keywords.
> 
> 4) I will take on the responsibility of stabilizing ppc @system packages
> if need be.
> 

So just to be clear, any developer can rekeyword a package to ~ppc?


-- 
________________
Yury German
Email: blueknight@gentoo.org

GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD  FA00 EEAF ED89 024C 043


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[David Seifert]

On Wed, 2017-05-10 at 22:01 -0700, Yury German wrote:
> 
> On 5/10/17 12:40 PM, Anthony G. Basile wrote:
> > On 5/10/17 3:29 PM, David Seifert wrote:
> > So let's make sure we're on the same page -- here's my
> > understanding.
> > 
> > 1) For @system packages, we will have KEYWORDS="ppc" for the stable
> > versions and KEYWORDS="~ppc" for the rest.
> 
> So is this only for PPC or PPC64 as well?
> Both are security supported arches, but if you are going this route
> they
> will be dropped to non-secured arches leaving:
> 
> alpha, amd64, hppa, x86.
> 
> > 
> > 2) For non @system packages we will remove both ppc and ~ppc
> > keywords.
> > 
> > 3) If for some reason I need to add back a package to
> > build/maintain
> > stage3/4, I will rekeyword myself, but other than that, we will
> > *not*
> > balloon the keywords.
> > 
> > 4) I will take on the responsibility of stabilizing ppc @system
> > packages
> > if need be.
> > 
> 
> So just to be clear, any developer can rekeyword a package to ~ppc?
> 
> 

1. ppc(= 32 bit) will be massively dekeyworded, ppc64 will stay
unchanged (also given that it is an active arch in general and gets CPU
upgrades from IBM/OpenPOWER).

2. In general, no. The proposal will be such that keywording should
only be done to aid bootstrapping, not randomly add packages you think
might be nice. The whole point of this exercise is to not have to
repeat this whole thing again in 2 years, just because someone found a
bunch of packages interesting. If there really is a dedicated team up
to the task and demonstrably active in keywording/stablereq'ing, we can
reconsider.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Yury German]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

David,

I never said anything about stablizing. But that is fine, thank you for
the answers.

Blueness,

When are you proposing to making the changes. As we are about to drop
sparc from security supported arches, so we might as well add PPC to the
list.

On 5/10/17 11:50 PM, David Seifert wrote:
> If there really is a dedicated team up
> to the task and demonstrably active in keywording/stablereq'ing, we can
> reconsider.

-- 
________________
Yury German
Gentoo Security Team Lead | Gentoo Infrastructure | Planet Gentoo
Email: blueknight@gentoo.org

GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD  FA00 EEAF ED89 024C 043


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/11/17 3:17 AM, Yury German wrote:
> David,
> 
> I never said anything about stablizing. But that is fine, thank you for
> the answers.
> 
> Blueness,
> 
> When are you proposing to making the changes. As we are about to drop
> sparc from security supported arches, so we might as well add PPC to the
> list.
> 
> On 5/10/17 11:50 PM, David Seifert wrote:
>> If there really is a dedicated team up
>> to the task and demonstrably active in keywording/stablereq'ing, we can
>> reconsider.
> 

Soap is working on the dekeywording.  I just jumped in because I wanted
to make sure we didn't break the catalyst runs for stage3's and he came
up with the dekeywording solution which I like.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Dirkjan Ochtman]

On Thu, May 11, 2017 at 8:50 AM, David Seifert <soap@gentoo.org> wrote:
> 1. ppc(= 32 bit) will be massively dekeyworded, ppc64 will stay
> unchanged (also given that it is an active arch in general and gets CPU
> upgrades from IBM/OpenPOWER).

Sounds good.

You started the thread also talking about ia64 and sparc. What about those?

Cheers,

Dirkjan

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michael Orlitzky]

On 05/09/2017 04:12 AM, Rich Freeman wrote:
> On Tue, May 9, 2017 at 12:23 AM, Yury German <blueknight@gentoo.org> wrote:
>>
>> we can not call for cleanup or release the GLSA,
>> waiting for a stabilization of a non-core package, while the actual
>> package has been in a tree in ~arch status for weeks or months.
> 
> Why not?  If an arch is considered a non-security-supported arch then
> you would just ignore it in a security bug.
> 

For example, I can't remove the ancient and vulnerable nagios-3.5.1
because an alternative is missing keywords:

  https://bugs.gentoo.org/show_bug.cgi?id=605724

If I drop nagios-3.5.1 without the keywords, pnp4nagios breaks.

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Anthony G. Basile]

On 5/9/17 8:33 AM, Michael Orlitzky wrote:
> On 05/09/2017 04:12 AM, Rich Freeman wrote:
>> On Tue, May 9, 2017 at 12:23 AM, Yury German <blueknight@gentoo.org> wrote:
>>>
>>> we can not call for cleanup or release the GLSA,
>>> waiting for a stabilization of a non-core package, while the actual
>>> package has been in a tree in ~arch status for weeks or months.
>>
>> Why not?  If an arch is considered a non-security-supported arch then
>> you would just ignore it in a security bug.
>>
> 
> For example, I can't remove the ancient and vulnerable nagios-3.5.1
> because an alternative is missing keywords:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=605724
> 
> If I drop nagios-3.5.1 without the keywords, pnp4nagios breaks.
> 
> 

Perhaps I'm missing the issue, but can you just follow the dependencies
and drop keywords accordingly so the tree remains consistent.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Michael Orlitzky]

On 05/09/2017 09:36 AM, Anthony G. Basile wrote:
> 
> Perhaps I'm missing the issue, but can you just follow the dependencies
> and drop keywords accordingly so the tree remains consistent.
> 

If we can make it policy that I'm allowed to edit a bunch of other
peoples' packages and de-keyword stable versions, then yeah; but I don't
think it's allowed currently and I'd probably get some angry emails.