Re: [gentoo-portage-dev] Tools-Portage Lead
On Tue, Oct 13, 2015 at 1:47 PM, Paul Varner wrote: > Reading GLEP-39, it is not clear to me if a sub-project needs to have > their leads elected or not. No interest in interfering with whatever you guys come up with, but as far as I'm aware subprojects are just projects as far as GLEP 39 goes - the hierarchy is intended to be more for organization than anything. So, you guys are welcome to and should of course consider selecting a lead. The motivation of the request was less about trying to dictate how projects run themselves and more about having somebody people can reach out to with questions/etc, and also to have a way to get a sense for how alive projects are. -- Rich
[gentoo-portage-dev] Tools-Portage Lead
All: I inherited the tools-portage lead position on 12/1/2008 when genone retired from Gentoo, and have been the lead since that time. Reading GLEP-39, it is not clear to me if a sub-project needs to have their leads elected or not. Anyhow, I'm asking the following: 1. Do we want to elect a tools-portage lead? 2. Do we want the portage lead to select/confirm the tools-portage lead when they are elected? 3. Do we just want continue as we have been until I get tired of the position and step down? 4. Any option not already listed. Since the tools-portage team is quite small, there hasn't been any real issues with the leadership or running the team, our problems are lack of manpower and time. I'm only asking this since the Council would like all projects to consider electing or confirming the project lead(s) If we do decide to hold an election, I will like to nominate myself and Brian as co-leads. Regards, Paul
Re: [gentoo-portage-dev] [PATCH] repoman: Set max DESCRIPTION length to 80, #562808
Dnia 2015-10-12, o godz. 08:58:10
Zac Medico napisał(a):
> On 10/12/2015 12:52 AM, Michał Górny wrote:
> > Correct the max DESCRIPTION length in qa_data, and remove the comment
> > confusingly suggesting that the variable name is taken into the count.
> >
> > Bug: https://bugs.gentoo.org/show_bug.cgi?id=562808
> > ---
> > pym/repoman/qa_data.py | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/pym/repoman/qa_data.py b/pym/repoman/qa_data.py
> > index dddfb98..df9b836 100644
> > --- a/pym/repoman/qa_data.py
> > +++ b/pym/repoman/qa_data.py
> > @@ -7,8 +7,7 @@ from _emerge.Package import Package
> > # import our initialized portage instance
> > from repoman._portage import portage
> >
> > -# 14 is the length of DESCRIPTION=""
> > -max_desc_len = 100
> > +max_desc_len = 80
> > allowed_filename_chars = "a-zA-Z0-9._-+:"
> >
> > qahelp = {
> >
>
> Looks good.
Merged.
--
Best regards,
Michał Górny
[gentoo-portage-dev] Re: [PATCH] SpawnProcess._set_returncode: handle missing cgroup IOError (bug 562964)
On 10/13/2015 09:10 AM, Zac Medico wrote:
> Handle EnvironmentError, which includes the IOError that is raised
> when the cgroup has been removed by cgroup-release-agent.
>
> Fixes: e6be71af3f67 ("AbstractEbuildProcess: remove cgroup with release_agent
> (bug 561264)")
> X-Gentoo-bug: 562964
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=562964
I've pushed this because it's a trivial bug fix.
--
Thanks,
Zac
[gentoo-portage-dev] [PATCH] SpawnProcess._set_returncode: handle missing cgroup IOError (bug 562964)
Handle EnvironmentError, which includes the IOError that is raised
when the cgroup has been removed by cgroup-release-agent.
Fixes: e6be71af3f67 ("AbstractEbuildProcess: remove cgroup with release_agent
(bug 561264)")
X-Gentoo-bug: 562964
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=562964
---
pym/_emerge/SpawnProcess.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pym/_emerge/SpawnProcess.py b/pym/_emerge/SpawnProcess.py
index 15d3dc5..5ab2e67 100644
--- a/pym/_emerge/SpawnProcess.py
+++ b/pym/_emerge/SpawnProcess.py
@@ -185,8 +185,8 @@ class SpawnProcess(SubProcess):
try:
with open(os.path.join(cgroup,
'cgroup.procs'), 'r') as f:
return [int(p) for p in
f.read().split()]
- except OSError:
- # cgroup removed already?
+ except EnvironmentError:
+ # removed by cgroup-release-agent
return []
def kill_all(pids, sig):
--
2.4.6
