Hello QA In the recent months the hppa stabilizations have been lacking for everything. This is affecting both regular stabilization but it is also affecting Security bugs where we can not follow the security process to secure Gentoo Linux. At this point we have been releasing the GLSA's around this, but it is affecting the Security of Gentoo Linux as we are unable to finish the process and clean up the vulnerable packages from tree leaving our users with the potential of running or installing known vulnerable packages. I have had communications with jer who is security liaison hppa and received a response (Non-relevant portion taken out): ______________________________ On August 24, 2017 at 5:08:00 AM, Jeroen Roovers (jer@gentoo.org) wrote: ... That's a show stopper and I can't fix it. I have done nothing with regard to stabilisation request bugs ever since. ______________________________ Since jer and vapier are the only members of the hippo team we (Security) would appreciate a review and a decision of what to do to the arch. From the security perspective we will be initiating removal of the hppa from the Security Supported Architectures [1] but that just masks the problem since there will be stable packages out there. The Security Team is also discussing internally and will put out a proposal to -dev@ list on changing the glsa-check and some other things. But at this point this is irrelevant to this discussion. BlueKnight - Security Team Lead
I've talked with Yury, and it seems he didn't summarize what I suggested, so I'll repeat it here. Given that no stabilizations are processed by the hppa team, and the arch has fallen behind a lot, I don't think there's really much value in keeping the existing stable keywords. So I'd suggest we drop everything to ~hppa to reach the goal with minimal effort from everyone involved.
(In reply to Michał Górny from comment #1) > I've talked with Yury, and it seems he didn't summarize what I suggested, so > I'll repeat it here. > > Given that no stabilizations are processed by the hppa team, and the arch > has fallen behind a lot, I don't think there's really much value in keeping > the existing stable keywords. So I'd suggest we drop everything to ~hppa to > reach > the goal with minimal effort from everyone involved. +1, I strongly support going this route.
Are keywording bugs being processed? If not, it may be time to drop support for hppa entirely. Of course, a nicer solution would be to resolve the "show stopper", but due to the missing text I have no idea what that could be.
I concur that HPPA should be dropped to unstable as well. https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&email1=hppa%40gentoo.org&emailassigned_to1=1&emailcc1=1&emailtype1=substring&list_id=3648778&query_format=advanced&resolution=---
Let's list all possible options: A. regarding stabilizations: A1. dilfridge's GLEP [1] -- let's us stop worrying about ~arch/arch while leaving keywords in place. However, it's not an option that we can expect to be finished and ready for use soon. A2. dropping everything to ~arch -- we lose current stable keywords, so if someone wants to restore stable hppa, he needs to start over. However, considering how far hppa is behind, I'm not sure if starting over wouldn't be better after all. This one can be done in 10-15 minutes ;-). B. regarding hppa in general: B1. dropping profiles to dev/exp -- we stop caring about hppa keywording in general. This has the disadvantage that the depgraph quickly becomes a mess, and if someone wants to resume it, it's a lot of work. B2. dropping ~hppa altogether -- probably we don't want to do. Do you see any other options? [1]:https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:72
Adding council to cc so we can monitor.
I would like to ask QA to move forward on a single recommendation now that the options have been listed. On behalf of security we are ready to take hppa to a non-supported arch as soon as possible.
Well, I'm going to repeat the plan I sent as a reply to the Council agenda. 1. Announce the planned actions along with a timeline. 2. Wait $m days to give people a chance to revive $arch before we start maneuvers. 3. If no noticeable improvement happens, drop $arch to ~$arch. 4. Wait $n days to see how pure ~$arch works out. 5. If no improvement still, drop $arch to exp.
Since slyfox has joined the hppa team, the council has decided to delay taking any action on this architecture until the next meeting.
Consensus during the council meeting was that the situation is improving and that currently no action has to be taken by the council.
This. From: Jeroen Roovers <jer@gentoo.org> To: Yury German <blueknight@gentoo.org> Cc: Gentoo Security <security@gentoo.org>, hppa@gentoo.org Subject: Re: hppa Stabilizations Date: Thu, 24 Aug 2017 11:07:52 +0200 X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) Organization: Gentoo Foundation Hi Yury, On Tue, 1 Aug 2017 23:27:58 -0400 Yury German <blueknight@gentoo.org> wrote: > Hello Jeroen (JER), > Please let us know what is going on so we can figure out further > steps together. I can't figure this out: " I have definitely been channeling my evil twin yesterday, indeed. Mwahahahaha... though I'm not sure I'll let him out of the basement soon again. The neighbours, you know, and cleaning up the mess afterwards. Anyway, my evil twin is 100% convinced that this is the way to go. Since he's completely right, nobody can really find the changes unsuitable. Or even unnecessary! I don't understand the fuss at all. Have to fix more bugs... Cheers, Andreas " That's a show stopper and I can't fix it. I have done nothing with regard to stabilisation request bugs ever since.
The Council has voted on this on 2017-11-12 meeting. With 4 'yes' votes, 1 'no' votes and 2 abstentions we've decided that the effort made so far is satisfactory enough to consider the issue solved and close the bug. If the hppa arch starts falling behind again in the future, feel free to reopen the bug and request a new resolution. As for Jeroen's comment, I don't really understand the purpose or meaning of it, and it doesn't really look like a Council problem. If you two have some kind of quarrel, please settle it between yourselves or ask ComRel for help/mediation.
<hat="qa"> <hat="arch_teams_member> I politely ask council to reconsider its state again, despite some efforts have been recently done to keep it stable, it seems to fell behind again, from my point of view it is not worth to support it anymore in any way. Debian dropped its support oficially (back to 2011). Only Gentoo and NetBSD are supporting this legacy thing. And no chance of getting really new hardware for this. I think it would be greate idea to say goodbye, at least move it to dev (exp?) and start package dekeywording. </hat> </hat>
Given how much time has passed, could you please explicitly submit this as agenda item, and restart discussion on -dev?
I've been slacking for a while as I've lost root wheel after account changes and was asked to use unprivileged containers on hake. This requires quite a bit of back and forth. Requested wheel back: https://bugs.gentoo.org/655050
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dbb698b2a25aa175868a2d33fe6c9cd39c740ae commit 0dbb698b2a25aa175868a2d33fe6c9cd39c740ae Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-05-06 09:16:31 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-05-08 21:26:29 +0000 profiles/profiles.desc: move hppa profiles stable->exp To release the burden on maintainers having to keep outdated latest stable versions of packages do not block them on hppa stabilization. hppa@ will still attempt to keep stable keywords for base packages. CC: hppa@gentoo.org CC: jer@gentoo.org CC: mattst88@gentoo.org Bug: https://bugs.gentoo.org/629554 Acked-by: Matt Turner <mattst88@gentoo.org> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> profiles/profiles.desc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
hppa@ was moved to exp profiles and should not be an obstacle.