Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland

[Raymond Jennings]

On Wed, Aug 30, 2017 at 12:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:

> William L. Thomson Jr. posted on Wed, 30 Aug 2017 14:01:08 -0400 as
> excerpted:
>
> > This is more food for thought to start a discussion on new category
> > names. With Wayland becoming more of a reality every day. I think some
> > of the x11-* categories may need to change. Stuff in there may not be
> > bound to X and can run on Wayland or X.
> >
> > Examples x11-libs/gtk+
> > x11-terms/terminology
> >
> > Not sure what better "universal" category names would be. But seems it
> > maybe time for a discussion on such and some new categories and package
> > moves. Given thus stuff can run under X or Wayland. Not sure x11 makes
> > sense anymore.
> >
> > I can do this on my own in my own overlay. But likely best for official
> > categories as this effects the tree not just others overlays etc. I do
> > not really have any ideas for better names. Just seems like a need.
>
> That could be a lot of package-move churn.  It arguably might make sense
> to keep the current names "for legacy reasons".  (Or not.  Just
> speculating here.)
>
> FWIW, there was some related discussion awhile back on USE=X, proposing
> USE=gui instead, but I don't know what became of it.  Perhaps gui-*
> category names if that's actually moving forward, in ordered to maintain
> a bit of consistency and for lack of a better idea?
>

I think "USE=X" should be reserved for X specific stuff.  If it's being
used to control gui in general IMHO that's not appropriate.  It's bad on
principle and is likely to cause practical difficulties later if confusion
arises vs competing guis, like qt, gtk, wayland, etc.

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

[gentoo-portage-dev] [PATCH v2 1/2] repoman: Unify usage of --bug and --closes options

[Michał Górny]

Replace the different logic used for --bug and --closes options with
a uniform solution. As a result, --closes now interprets numbers
as Gentoo bug numbers rather than GitHub pull request numbers.

This change is mostly done since the 'Closes' tag now started being used
to resolve Gentoo bugs. While changing the logic could be confusing,
it has not made it into a release yet and the GitHub default would not
be very useful anyway.

After all, repoman is normally used to commit the changes before a pull
request is created, which implies that the user does not know the pull
request number yet. The 'Closes' tag for pull request is usually added
by the reviewer before merging, using 'git --amend' since repoman has
no amending option. That considered, it is quite unlikely that anyone
would find --closes with pull request numbers useful.
---
 repoman/man/repoman.1  |  7 ---
 repoman/pym/repoman/actions.py | 17 -
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/repoman/man/repoman.1 b/repoman/man/repoman.1
index a49c72c0d..41df8ed2f 100644
--- a/repoman/man/repoman.1
+++ b/repoman/man/repoman.1
@@ -31,9 +31,10 @@ is forced for known bug trackers.
 \fB-c\fR, \fB--closes\fR
 Include a \fBCloses\fR tag in the commit message footer that can be used
 to close pull requests (and issues) on GitHub and other compatible
-services (GitLab, Bitbucket). The argument can be either a PR number for
-the gentoo/gentoo GitHub repository or a full PR/bug URL. For bug URLs,
-HTTPS is forced automatically for known bug/PR trackers.
+services (GitLab, Bitbucket). The argument can be either a Gentoo bug
+number or a full PR/bug URL. Gentoo bug URLs are automatically shortened
+to the canonical \fBhttps://bugs.gentoo.org/NN\fR form, and HTTPS
+is forced for known bug trackers.
 .TP
 \fB\-\-digest=\fR
 Automatically update Manifest digests for modified files. This
diff --git a/repoman/pym/repoman/actions.py b/repoman/pym/repoman/actions.py
index 2112299c0..b76a6e466 100644
--- a/repoman/pym/repoman/actions.py
+++ b/repoman/pym/repoman/actions.py
@@ -357,7 +357,9 @@ class Actions(object):
 
# Common part of commit footer
commit_footer = "\n"
-   for bug in self.options.bug:
+   for tag, bug in chain(
+   (('Bug', x) for x in self.options.bug),
+   (('Closes', x) for x in self.options.closes)):
# case 1: pure number NN
if bug.isdigit():
bug = 'https://bugs.gentoo.org/%s' % (bug, )
@@ -374,18 +376,7 @@ class Actions(object):
elif (purl.scheme == 'http' and
purl.netloc in 
self.https_bugtrackers):
bug = urlunsplit(('https',) + purl[1:])
-   commit_footer += "Bug: %s\n" % (bug, )
-
-   for closes in self.options.closes:
-   # case 1: pure number 
-   if closes.isdigit():
-   closes = 
'https://github.com/gentoo/gentoo/pull/%s' % (closes, )
-   else:
-   purl = urlsplit(closes)
-   # case 2: bug tracker w/ http -> https
-   if purl.netloc in self.https_bugtrackers:
-   closes = urlunsplit(('https',) + 
purl[1:])
-   commit_footer += "Closes: %s\n" % (closes, )
+   commit_footer += "%s: %s\n" % (tag, bug)
 
if dco_sob:
commit_footer += "Signed-off-by: %s\n" % (dco_sob, )
-- 
2.14.1

Re: [gentoo-portage-dev] [PATCH] repoman: Update --bug/--closes description for bugs.g.o hooks

[Michał Górny]

W dniu sob, 02.09.2017 o godzinie 14∶33 -0700, użytkownik Zac Medico
napisał:
> On 09/02/2017 12:10 PM, Michał Górny wrote:
> > Update the description for --bug and --closes to account for the fact
> > that the tags are now handled by git hooks on Gentoo Infra, and cause
> > actions on Gentoo Bugzilla.
> > 
> > // NB: It would probably make sense for --closes to default to Gentoo
> > bug numbers now. However, I have doubts that some people might have
> > already started using it for pull requests, and that might cause
> > confusion. What do you think?
> 
> Yeah it's hard do say, maybe add a --closes-bug option for gentoo bugs?
> 

I'm going to ask around. Thinking about it, having pull request closing
in repoman doesn't seem really useful. After all, people normally commit
stuff before creating a pull request, and so they don't have the pull
request number yet. And when they do, they rather 'git commit --amend'
after all.

-- 
Best regards,
Michał Górny

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Michał Górny]

W dniu sob, 02.09.2017 o godzinie 14∶23 -0700, użytkownik Zac Medico
napisał:
> On 09/02/2017 02:05 PM, Michał Górny wrote:
> > W dniu sob, 02.09.2017 o godzinie 12∶19 -0700, użytkownik Zac Medico
> > napisał:
> > > On 09/02/2017 10:46 AM, Michał Górny wrote:
> > > > dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
> > > > makes it unable to work with -OO code. Remove the optimizations from
> > > > Portage shebangs to prevent triggering the issue until we find a proper
> > > > solution for it.
> > > > 
> > > > Bug: https://bugs.gentoo.org/628386
> > > > ---
> > > >  bin/clean_locks   | 2 +-
> > > >  bin/dispatch-conf | 2 +-
> > > >  bin/ebuild| 2 +-
> > > >  bin/emaint| 2 +-
> > > >  bin/env-update| 2 +-
> > > >  bin/portageq  | 2 +-
> > > >  tabcheck.py   | 2 +-
> > > >  7 files changed, 7 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/bin/clean_locks b/bin/clean_locks
> > > > index 13af06197..fb245972f 100755
> > > > --- a/bin/clean_locks
> > > > +++ b/bin/clean_locks
> > > > @@ -1,4 +1,4 @@
> > > > -#!/usr/bin/python -bO
> > > > +#!/usr/bin/python -b
> > > 
> > > The diff shows -O, but the commit messages says -OO, so which one is it 
> > > really?
> > 
> > Yes, it's a curious problem. -OO is the one breaking it but py<3.5 seems
> > to be happy to load -OO files with -O:
> > 
> > $ python2.7 -O -c 'import pycparser; print(pycparser.__file__)'
> > /usr/lib64/python2.7/site-packages/pycparser/c_parser.py:20: 
> > RuntimeWarning: parsing methods must have __doc__ for pycparser to work 
> > properly
> >   class CParser(PLYParser):
> > /usr/lib64/python2.7/site-packages/pycparser/__init__.pyo
> > 
> > $ python3.4 -O -c 'import pycparser; print(pycparser.__cached__)'
> > /usr/lib64/python3.4/site-packages/pycparser/c_parser.py:20: 
> > RuntimeWarning: parsing methods must have __doc__ for pycparser to work 
> > properly
> >   class CParser(PLYParser):
> > /usr/lib64/python3.4/site-packages/pycparser/__pycache__/__init__.cpython-34.pyo
> > 
> > This doesn't seem to be the case anymore for py3.5+:
> > 
> > $ python3.5 -O -c 'import pycparser; print(pycparser.__cached__)'
> > /usr/lib64/python3.5/site-packages/pycparser/__pycache__/__init__.cpython-35.opt-1.pyc
> > 
> > > Are we sure that it's worth it to load all of the __doc__ strings into
> > > memory, given that we have alternative implementations for everything
> > > that pycrypto provides?
> > 
> > I dare say that if -O can cause completely random total breakage, then
> > we shouldn't risk doing that for the sake of some minor memory savings.
> > It's not a case of 'support for pycryptodome' vs '1M memory saving'.
> > It's a case of 'loading random module can wreak total havoc in Portage'.
> 
> Seems reasonable. Please merge.

Merged, thanks.
-- 
Best regards,
Michał Górny

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Michał Górny]

W dniu sob, 02.09.2017 o godzinie 23∶05 +0200, użytkownik Michał Górny
napisał:
> W dniu sob, 02.09.2017 o godzinie 12∶19 -0700, użytkownik Zac Medico
> napisał:
> > On 09/02/2017 10:46 AM, Michał Górny wrote:
> > > dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
> > > makes it unable to work with -OO code. Remove the optimizations from
> > > Portage shebangs to prevent triggering the issue until we find a proper
> > > solution for it.
> > > 
> > > Bug: https://bugs.gentoo.org/628386
> > > ---
> > >  bin/clean_locks   | 2 +-
> > >  bin/dispatch-conf | 2 +-
> > >  bin/ebuild| 2 +-
> > >  bin/emaint| 2 +-
> > >  bin/env-update| 2 +-
> > >  bin/portageq  | 2 +-
> > >  tabcheck.py   | 2 +-
> > >  7 files changed, 7 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/bin/clean_locks b/bin/clean_locks
> > > index 13af06197..fb245972f 100755
> > > --- a/bin/clean_locks
> > > +++ b/bin/clean_locks
> > > @@ -1,4 +1,4 @@
> > > -#!/usr/bin/python -bO
> > > +#!/usr/bin/python -b
> > 
> > The diff shows -O, but the commit messages says -OO, so which one is it 
> > really?
> 
> Yes, it's a curious problem. -OO is the one breaking it but py<3.5 seems
> to be happy to load -OO files with -O:
> 
> $ python2.7 -O -c 'import pycparser; print(pycparser.__file__)'
> /usr/lib64/python2.7/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
> parsing methods must have __doc__ for pycparser to work properly
>   class CParser(PLYParser):
> /usr/lib64/python2.7/site-packages/pycparser/__init__.pyo
> 
> $ python3.4 -O -c 'import pycparser; print(pycparser.__cached__)'
> /usr/lib64/python3.4/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
> parsing methods must have __doc__ for pycparser to work properly
>   class CParser(PLYParser):
> /usr/lib64/python3.4/site-packages/pycparser/__pycache__/__init__.cpython-34.pyo
> 
> This doesn't seem to be the case anymore for py3.5+:
> 
> $ python3.5 -O -c 'import pycparser; print(pycparser.__cached__)'
> /usr/lib64/python3.5/site-packages/pycparser/__pycache__/__init__.cpython-35.opt-1.pyc

My roundabout thinking here was really silly. I was mistaking -O/-OO for
.pyc/.pyo. For the record, the correct explanation:

Python < 3.5 supports only either -O or -OO, and compiles both levels to
the same .pyo files. So if we compiled the relevant packages with -OO,
then -O implicitly meant -OO.

-- 
Best regards,
Michał Górny

Re: [gentoo-portage-dev] [PATCH] repoman: Update --bug/--closes description for bugs.g.o hooks

[Zac Medico]

On 09/02/2017 12:10 PM, Michał Górny wrote:
> Update the description for --bug and --closes to account for the fact
> that the tags are now handled by git hooks on Gentoo Infra, and cause
> actions on Gentoo Bugzilla.
> 
> // NB: It would probably make sense for --closes to default to Gentoo
> bug numbers now. However, I have doubts that some people might have
> already started using it for pull requests, and that might cause
> confusion. What do you think?

Yeah it's hard do say, maybe add a --closes-bug option for gentoo bugs?

> ---
>  repoman/man/repoman.1 | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/repoman/man/repoman.1 b/repoman/man/repoman.1
> index a49c72c0d..4b518e6f1 100644
> --- a/repoman/man/repoman.1
> +++ b/repoman/man/repoman.1
> @@ -27,13 +27,16 @@ be either a Gentoo bug number or a full bug URL (either 
> Gentoo
>  or upstream). Gentoo bug URLs are automatically shortened to
>  the canonical \fBhttps://bugs.gentoo.org/NN\fR form, and HTTPS
>  is forced for known bug trackers.
> +
> +When pushing to the Gentoo repository, the reference to the commit
> +will be automatically added as a comment on the bug.
>  .TP
>  \fB-c\fR, \fB--closes\fR
>  Include a \fBCloses\fR tag in the commit message footer that can be used
> -to close pull requests (and issues) on GitHub and other compatible
> -services (GitLab, Bitbucket). The argument can be either a PR number for
> -the gentoo/gentoo GitHub repository or a full PR/bug URL. For bug URLs,
> -HTTPS is forced automatically for known bug/PR trackers.
> +to close bugs and pull requests (e.g. on Gentoo Bugzilla, GitHub, GitLab,
> +Bitbucket). The argument can be either a PR number for the gentoo/gentoo
> +GitHub repository or a full PR/bug URL. For bug URLs, HTTPS is forced
> +automatically for known bug/PR trackers.
>  .TP
>  \fB\-\-digest=\fR
>  Automatically update Manifest digests for modified files. This
> 

Looks good.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Zac Medico]

On 09/02/2017 02:05 PM, Michał Górny wrote:
> W dniu sob, 02.09.2017 o godzinie 12∶19 -0700, użytkownik Zac Medico
> napisał:
>> On 09/02/2017 10:46 AM, Michał Górny wrote:
>>> dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
>>> makes it unable to work with -OO code. Remove the optimizations from
>>> Portage shebangs to prevent triggering the issue until we find a proper
>>> solution for it.
>>>
>>> Bug: https://bugs.gentoo.org/628386
>>> ---
>>>  bin/clean_locks   | 2 +-
>>>  bin/dispatch-conf | 2 +-
>>>  bin/ebuild| 2 +-
>>>  bin/emaint| 2 +-
>>>  bin/env-update| 2 +-
>>>  bin/portageq  | 2 +-
>>>  tabcheck.py   | 2 +-
>>>  7 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/bin/clean_locks b/bin/clean_locks
>>> index 13af06197..fb245972f 100755
>>> --- a/bin/clean_locks
>>> +++ b/bin/clean_locks
>>> @@ -1,4 +1,4 @@
>>> -#!/usr/bin/python -bO
>>> +#!/usr/bin/python -b
>>
>> The diff shows -O, but the commit messages says -OO, so which one is it 
>> really?
> 
> Yes, it's a curious problem. -OO is the one breaking it but py<3.5 seems
> to be happy to load -OO files with -O:
> 
> $ python2.7 -O -c 'import pycparser; print(pycparser.__file__)'
> /usr/lib64/python2.7/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
> parsing methods must have __doc__ for pycparser to work properly
>   class CParser(PLYParser):
> /usr/lib64/python2.7/site-packages/pycparser/__init__.pyo
> 
> $ python3.4 -O -c 'import pycparser; print(pycparser.__cached__)'
> /usr/lib64/python3.4/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
> parsing methods must have __doc__ for pycparser to work properly
>   class CParser(PLYParser):
> /usr/lib64/python3.4/site-packages/pycparser/__pycache__/__init__.cpython-34.pyo
> 
> This doesn't seem to be the case anymore for py3.5+:
> 
> $ python3.5 -O -c 'import pycparser; print(pycparser.__cached__)'
> /usr/lib64/python3.5/site-packages/pycparser/__pycache__/__init__.cpython-35.opt-1.pyc
> 
>> Are we sure that it's worth it to load all of the __doc__ strings into
>> memory, given that we have alternative implementations for everything
>> that pycrypto provides?
> 
> I dare say that if -O can cause completely random total breakage, then
> we shouldn't risk doing that for the sake of some minor memory savings.
> It's not a case of 'support for pycryptodome' vs '1M memory saving'.
> It's a case of 'loading random module can wreak total havoc in Portage'.

Seems reasonable. Please merge.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Michał Górny]

W dniu sob, 02.09.2017 o godzinie 12∶19 -0700, użytkownik Zac Medico
napisał:
> On 09/02/2017 10:46 AM, Michał Górny wrote:
> > dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
> > makes it unable to work with -OO code. Remove the optimizations from
> > Portage shebangs to prevent triggering the issue until we find a proper
> > solution for it.
> > 
> > Bug: https://bugs.gentoo.org/628386
> > ---
> >  bin/clean_locks   | 2 +-
> >  bin/dispatch-conf | 2 +-
> >  bin/ebuild| 2 +-
> >  bin/emaint| 2 +-
> >  bin/env-update| 2 +-
> >  bin/portageq  | 2 +-
> >  tabcheck.py   | 2 +-
> >  7 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/bin/clean_locks b/bin/clean_locks
> > index 13af06197..fb245972f 100755
> > --- a/bin/clean_locks
> > +++ b/bin/clean_locks
> > @@ -1,4 +1,4 @@
> > -#!/usr/bin/python -bO
> > +#!/usr/bin/python -b
> 
> The diff shows -O, but the commit messages says -OO, so which one is it 
> really?

Yes, it's a curious problem. -OO is the one breaking it but py<3.5 seems
to be happy to load -OO files with -O:

$ python2.7 -O -c 'import pycparser; print(pycparser.__file__)'
/usr/lib64/python2.7/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
parsing methods must have __doc__ for pycparser to work properly
  class CParser(PLYParser):
/usr/lib64/python2.7/site-packages/pycparser/__init__.pyo

$ python3.4 -O -c 'import pycparser; print(pycparser.__cached__)'
/usr/lib64/python3.4/site-packages/pycparser/c_parser.py:20: RuntimeWarning: 
parsing methods must have __doc__ for pycparser to work properly
  class CParser(PLYParser):
/usr/lib64/python3.4/site-packages/pycparser/__pycache__/__init__.cpython-34.pyo

This doesn't seem to be the case anymore for py3.5+:

$ python3.5 -O -c 'import pycparser; print(pycparser.__cached__)'
/usr/lib64/python3.5/site-packages/pycparser/__pycache__/__init__.cpython-35.opt-1.pyc

> Are we sure that it's worth it to load all of the __doc__ strings into
> memory, given that we have alternative implementations for everything
> that pycrypto provides?

I dare say that if -O can cause completely random total breakage, then
we shouldn't risk doing that for the sake of some minor memory savings.
It's not a case of 'support for pycryptodome' vs '1M memory saving'.
It's a case of 'loading random module can wreak total havoc in Portage'.

> For the record, I measure an increase of from 30248K to 31504K for -OO vs 
> without when
> importing all portage modules, tested as follows:
> 
> $ python3.6 -OO pym/portage/tests/runTests.py 
> pym/portage/tests/lint/test_import_modules.py
> testImportModules 
> (portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 30248
> 
> $ python3.6 -O pym/portage/tests/runTests.py 
> pym/portage/tests/lint/test_import_modules.py
> testImportModules 
> (portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 31468
> 
> $ python3.6  pym/portage/tests/runTests.py 
> pym/portage/tests/lint/test_import_modules.py
> testImportModules 
> (portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 31504
> 
> Using this patch:
> 
> diff --git a/pym/portage/tests/lint/test_import_modules.py 
> b/pym/portage/tests/lint/test_import_modules.py
> index fcdcb3b33..6350197eb 100644
> --- a/pym/portage/tests/lint/test_import_modules.py
> +++ b/pym/portage/tests/lint/test_import_modules.py
> @@ -2,6 +2,7 @@
>  # Distributed under the terms of the GNU General Public License v2
>  
>  from itertools import chain
> +import resource
>  
>  from portage.const import PORTAGE_PYM_PATH, PORTAGE_PYM_PACKAGES
>  from portage.tests import TestCase
> @@ -24,6 +25,7 @@ class ImportModulesTestCase(TestCase):
> if mod not in expected_failures:
> self.assertTrue(False, "failed to 
> import '%s': %s" % (mod, e))
> del e
> +   print(resource.getrusage(resource.RUSAGE_SELF).ru_maxrss)
>  
> def _iter_modules(self, base_dir):
> for parent, dirs, files in os.walk(base_dir):
> 

-- 
Best regards,
Michał Górny

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Zac Medico]

On 09/02/2017 12:19 PM, Zac Medico wrote:
> On 09/02/2017 10:46 AM, Michał Górny wrote:
>> dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
>> makes it unable to work with -OO code. Remove the optimizations from
>> Portage shebangs to prevent triggering the issue until we find a proper
>> solution for it.
>>
>> Bug: https://bugs.gentoo.org/628386
>> ---
>>  bin/clean_locks   | 2 +-
>>  bin/dispatch-conf | 2 +-
>>  bin/ebuild| 2 +-
>>  bin/emaint| 2 +-
>>  bin/env-update| 2 +-
>>  bin/portageq  | 2 +-
>>  tabcheck.py   | 2 +-
>>  7 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/bin/clean_locks b/bin/clean_locks
>> index 13af06197..fb245972f 100755
>> --- a/bin/clean_locks
>> +++ b/bin/clean_locks
>> @@ -1,4 +1,4 @@
>> -#!/usr/bin/python -bO
>> +#!/usr/bin/python -b
> 
> The diff shows -O, but the commit messages says -OO, so which one is it 
> really?
> 
> Are we sure that it's worth it to load all of the __doc__ strings into
> memory, given that we have alternative implementations for everything
> that pycrypto provides?

Seems that we inadvertently dropped -O from the emerge shebang during
some refactoring here:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=941dc5b26301075545e5fb3580f5d72c5f78c3cd
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] Do not enable optimizations by default to work-around pycparser issue

[Zac Medico]

On 09/02/2017 10:46 AM, Michał Górny wrote:
> dev-python/pycparser-2.18+ exposes a design flaw in dev-python/ply that
> makes it unable to work with -OO code. Remove the optimizations from
> Portage shebangs to prevent triggering the issue until we find a proper
> solution for it.
> 
> Bug: https://bugs.gentoo.org/628386
> ---
>  bin/clean_locks   | 2 +-
>  bin/dispatch-conf | 2 +-
>  bin/ebuild| 2 +-
>  bin/emaint| 2 +-
>  bin/env-update| 2 +-
>  bin/portageq  | 2 +-
>  tabcheck.py   | 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/bin/clean_locks b/bin/clean_locks
> index 13af06197..fb245972f 100755
> --- a/bin/clean_locks
> +++ b/bin/clean_locks
> @@ -1,4 +1,4 @@
> -#!/usr/bin/python -bO
> +#!/usr/bin/python -b

The diff shows -O, but the commit messages says -OO, so which one is it really?

Are we sure that it's worth it to load all of the __doc__ strings into
memory, given that we have alternative implementations for everything
that pycrypto provides?

For the record, I measure an increase of from 30248K to 31504K for -OO vs 
without when
importing all portage modules, tested as follows:

$ python3.6 -OO pym/portage/tests/runTests.py 
pym/portage/tests/lint/test_import_modules.py
testImportModules 
(portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 30248

$ python3.6 -O pym/portage/tests/runTests.py 
pym/portage/tests/lint/test_import_modules.py
testImportModules 
(portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 31468

$ python3.6  pym/portage/tests/runTests.py 
pym/portage/tests/lint/test_import_modules.py
testImportModules 
(portage.tests.lint.test_import_modules.ImportModulesTestCase) ... 31504

Using this patch:

diff --git a/pym/portage/tests/lint/test_import_modules.py 
b/pym/portage/tests/lint/test_import_modules.py
index fcdcb3b33..6350197eb 100644
--- a/pym/portage/tests/lint/test_import_modules.py
+++ b/pym/portage/tests/lint/test_import_modules.py
@@ -2,6 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 
 from itertools import chain
+import resource
 
 from portage.const import PORTAGE_PYM_PATH, PORTAGE_PYM_PACKAGES
 from portage.tests import TestCase
@@ -24,6 +25,7 @@ class ImportModulesTestCase(TestCase):
if mod not in expected_failures:
self.assertTrue(False, "failed to 
import '%s': %s" % (mod, e))
del e
+   print(resource.getrusage(resource.RUSAGE_SELF).ru_maxrss)
 
def _iter_modules(self, base_dir):
for parent, dirs, files in os.walk(base_dir):

-- 
Thanks,
Zac

[gentoo-portage-dev] [PATCH] repoman: Update --bug/--closes description for bugs.g.o hooks

[Michał Górny]

Update the description for --bug and --closes to account for the fact
that the tags are now handled by git hooks on Gentoo Infra, and cause
actions on Gentoo Bugzilla.

// NB: It would probably make sense for --closes to default to Gentoo
bug numbers now. However, I have doubts that some people might have
already started using it for pull requests, and that might cause
confusion. What do you think?
---
 repoman/man/repoman.1 | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/repoman/man/repoman.1 b/repoman/man/repoman.1
index a49c72c0d..4b518e6f1 100644
--- a/repoman/man/repoman.1
+++ b/repoman/man/repoman.1
@@ -27,13 +27,16 @@ be either a Gentoo bug number or a full bug URL (either 
Gentoo
 or upstream). Gentoo bug URLs are automatically shortened to
 the canonical \fBhttps://bugs.gentoo.org/NN\fR form, and HTTPS
 is forced for known bug trackers.
+
+When pushing to the Gentoo repository, the reference to the commit
+will be automatically added as a comment on the bug.
 .TP
 \fB-c\fR, \fB--closes\fR
 Include a \fBCloses\fR tag in the commit message footer that can be used
-to close pull requests (and issues) on GitHub and other compatible
-services (GitLab, Bitbucket). The argument can be either a PR number for
-the gentoo/gentoo GitHub repository or a full PR/bug URL. For bug URLs,
-HTTPS is forced automatically for known bug/PR trackers.
+to close bugs and pull requests (e.g. on Gentoo Bugzilla, GitHub, GitLab,
+Bitbucket). The argument can be either a PR number for the gentoo/gentoo
+GitHub repository or a full PR/bug URL. For bug URLs, HTTPS is forced
+automatically for known bug/PR trackers.
 .TP
 \fB\-\-digest=\fR
 Automatically update Manifest digests for modified files. This
-- 
2.14.1

[gentoo-dev] [RFC] sys-boot/grub:0 (GRUB legacy) sunset planning

[Robin H. Johnson]

Hi,

The base-system project would like to put forward a plan to sunset GRUB
Legacy, sys-boot/grub:0 (grub-0.97).

What does this cover?
-
- sys-boot/grub:0
- sys-boot/grub-static

What does this NOT cover?
-
- sys-boot/grub:2
- app-emulation/xen-pvgrub [1] 
- app-emulation/grub-xen-host [1]

Why should it go? 
-
- No longer supported by upstream
- no upstream fixes at all for 5+ years
- very fragile to toolchain changes.

Why does it need to stay at all? 

- grub:0 is still used by legacy systems where the upgrade is
  non-trivial (eg.  re-partitioning), or not supported (eg. vendor
  clouds)
- grub-static was heavily used in specific profiles [2] where the build
  system produced a grub that didn't work properly. I think (but would
  like confirmation) that the grub-static use cases are no longer in
  use.

What are other distributions doing? 
---
- Ubuntu shipped both versions of grub for Xenial, but dropped them
  entirely for Zesty & Artful.
- Debian: still offers grub-legacy, but defaults to grub-2.
- Fedora: hasn't shipped grub-0 in years.
- CentOS: 6 ships grub-0.97 only, 7 ships grub2 only.

The plan:
-
- To the extent possible, no new installs should use grub:0.
- package.mask grub:0
- Last-rite grub-static if not needed.
- No new functionality will be accepted
- Outstanding feature patches/bugs will be closed (e.g. btrfs, tpm)
- Fixes to keep it building correctly will be accepted (e.g. gcc-6)
- base-system, as a project, will only maintain grub:2 from this point
  forward.
- metadata.xml will mark base-system as maintaining grub:2 only.
- metadata.xml will list explicit grub:0 maintainers.
- This is only available while there is sufficient skilled
  manpower/maintainers.

Open questions:
--
- Are there more maintainers willing to put their name in the hat?
- Are there existing use cases that I've missed, where migration to
  grub-2 CANNOT be done?
- Are there other use cases that need grub-static?

[1] app-emulation/xen-pvgrub & app-emulation/grub-xen-host are
maintained by the Xen project. app-emulation/xen-pvgrub is the grub:0
part, and probably also deserving of sunset. app-emulation/grub-xen-host
depends on grub:2 and builds a specific config.
[2] hardened, no-multilib, mixed 64-bit kernel/32-ul systems.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

[gentoo-dev] Last rites: dev-qt/qtphonon

[Michael Palimaka]

# Michael Palimaka  (03 Sep 2017)
# Dead upstream. Use media-libs/phonon instead.
# Masked for removal in 30 days. Bug #629144.
dev-qt/qtphonon