Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Tue, 16 Jan 2018 22:19:15 +
"M. J. Everitt"  wrote:

> On 16/01/18 21:56, Róbert Čerňanský wrote:
> > On Tue, 16 Jan 2018 15:58:11 +0100
> > Kristian Fiskerstrand  wrote:
> >  
> >> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:  
> >>> Given the situation, we have a choice: Remove GnuCash altogether,
> >>> or press ahead with recommending a version upstream considers
> >>> unstable.
> >> Or 3, discuss with upstream to see if they can release an updated
> >> version as stable branch.  
> > 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> > B. Manual action is required to continue using such package.
> >
> > I see this as the most obvious choice considering that I am still
> > unable to find any possible attack vector against GnuCash.  If it
> > is me and only me who enters data.  Webkit reports are generated
> > from those data.  How can anyone hack me through GnuCash?
> >
> > In general, many times users use applications in a way that
> > vulnerabilities does not apply to their use cases.  I would prefer
> > to be informed and allowed to continue using such application as a
> > part of the distro.
> >
> > Robert
> >
> >  
> Forgive my potential misunderstanding here .. but who's actively
> preventing you from using GnuCash 2.6? You can take a copy locally to
> /usr/local/portage so that When/If finally it gets removed from the
> central package 'tree' it will run for you provided its requirements
> are still met on your system ...

That's correct, nobody is preventing me and I already have copies of
several packages.  But with each additional package Gentoo becomes less
and less valuable.  You can say the same thing about every package.  But
what would be the point of linux distribution then?

I worked with assumption that there is a motivation in Gentoo to provide
a value in a form of stable GnuCash and I merely presented a way which I
see as most pragmatic.  It allows to continue to provide that value and
raises awarenes about webkit-gtk security vulnerabilities.

Of course there is also a possibility that maintainters may have lost
interest/motivation to maintain old webkit-gtk.  Which would be normal
and prefectly fine but completelly different matter than security.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

Re: [gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Zac Medico]

On 01/16/2018 08:32 PM, Mike Gilbert wrote:
> On Tue, Jan 16, 2018 at 4:46 PM, Mike Frysinger  wrote:
>> From: Mike Frysinger 
>>
>> Some ebuilds are a bit hard to fix their use of the network in src
>> phases, so allow them to disable things.  This allows us to turn off
>> access by default and for the vast majority while we work out how to
>> fix the few broken packages.
> 
> If we are going to allow network sandboxing to be disabled in
> individual ebuilds, we should also allow the other sandboxes to be
> disabled for the same reasons. sys-apps/sandbox has been notoriously
> buggy, for example.

Yeah, that sounds reasonable. We have ACCEPT_RESTRICT and
package.accept_restrict in case people want to mask packages with
certain restrict values.

> Also, valid RESTRICT values are specified in PMS, so this really
> belongs in an a new EAPI.

PMS says: Package managers may recognise other tokens, but ebuilds may
not rely upon them being supported.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Gilbert]

On Tue, Jan 16, 2018 at 4:46 PM, Mike Frysinger  wrote:
> From: Mike Frysinger 
>
> Some ebuilds are a bit hard to fix their use of the network in src
> phases, so allow them to disable things.  This allows us to turn off
> access by default and for the vast majority while we work out how to
> fix the few broken packages.

If we are going to allow network sandboxing to be disabled in
individual ebuilds, we should also allow the other sandboxes to be
disabled for the same reasons. sys-apps/sandbox has been notoriously
buggy, for example.

Also, valid RESTRICT values are specified in PMS, so this really
belongs in an a new EAPI.

Re: [gentoo-portage-dev] [PATCH v2] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Zac Medico]

On 01/16/2018 02:19 PM, Mike Frysinger wrote:
> From: Mike Frysinger 
> 
> Some ebuilds are a bit hard to fix their use of the network in src
> phases, so allow them to disable things.  This allows us to turn off
> access by default and for the vast majority while we work out how to
> fix the few broken packages.
> 
> URL: https://crbug.com/731905
> ---
>  man/ebuild.5   | 4 
>  pym/portage/package/ebuild/doebuild.py | 3 ++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/man/ebuild.5 b/man/ebuild.5
> index 42a0599fe3a9..1f2d4219e93e 100644
> --- a/man/ebuild.5
> +++ b/man/ebuild.5
> @@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
>  .I mirror
>  files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
>  .TP
> +.I network\-sandbox
> +Disables the network namespace for specific packages.
> +Should not be used in the main Gentoo tree.
> +.TP
>  .I preserve\-libs
>  Disables preserve\-libs for specific packages. Note than when a package is
>  merged, RESTRICT=preserve\-libs applies if either the new instance or the
> diff --git a/pym/portage/package/ebuild/doebuild.py 
> b/pym/portage/package/ebuild/doebuild.py
> index 0be148fd408e..f75f11a1a424 100644
> --- a/pym/portage/package/ebuild/doebuild.py
> +++ b/pym/portage/package/ebuild/doebuild.py
> @@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
> **kwargs):
>   kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
>   phase in _ipc_phases
>   kwargs['networked'] = 'network-sandbox' not in settings.features or \
> - phase in _networked_phases
> + phase in _networked_phases or \
> + 'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
>  
>   if phase == 'depend':
>   kwargs['droppriv'] = 'userpriv' in settings.features
> 

Thanks, looks perfect now.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Frysinger]

From: Mike Frysinger 

Some ebuilds are a bit hard to fix their use of the network in src
phases, so allow them to disable things.  This allows us to turn off
access by default and for the vast majority while we work out how to
fix the few broken packages.

URL: https://crbug.com/731905
---
 man/ebuild.5   | 4 
 pym/portage/package/ebuild/doebuild.py | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe3a9..1f2d4219e93e 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
 .I mirror
 files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
 .TP
+.I network\-sandbox
+Disables the network namespace for specific packages.
+Should not be used in the main Gentoo tree.
+.TP
 .I preserve\-libs
 Disables preserve\-libs for specific packages. Note than when a package is
 merged, RESTRICT=preserve\-libs applies if either the new instance or the
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 0be148fd408e..f75f11a1a424 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
phase in _ipc_phases
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases
+   phase in _networked_phases or \
+   'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
 
if phase == 'depend':
kwargs['droppriv'] = 'userpriv' in settings.features
-- 
2.15.1

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[M. J. Everitt]

On 16/01/18 21:56, Róbert Čerňanský wrote:
> On Tue, 16 Jan 2018 15:58:11 +0100
> Kristian Fiskerstrand  wrote:
>
>> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>>> Given the situation, we have a choice: Remove GnuCash altogether, or
>>> press ahead with recommending a version upstream considers
>>> unstable.  
>> Or 3, discuss with upstream to see if they can release an updated
>> version as stable branch.
> 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> B. Manual action is required to continue using such package.
>
> I see this as the most obvious choice considering that I am still
> unable to find any possible attack vector against GnuCash.  If it is me
> and only me who enters data.  Webkit reports are generated from those
> data.  How can anyone hack me through GnuCash?
>
> In general, many times users use applications in a way that
> vulnerabilities does not apply to their use cases.  I would prefer to
> be informed and allowed to continue using such application as a part of
> the distro.
>
> Robert
>
>
Forgive my potential misunderstanding here .. but who's actively
preventing you from using GnuCash 2.6? You can take a copy locally to
/usr/local/portage so that When/If finally it gets removed from the
central package 'tree' it will run for you provided its requirements are
still met on your system ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Zac Medico]

On 01/16/2018 01:46 PM, Mike Frysinger wrote:
> From: Mike Frysinger 
> 
> Some ebuilds are a bit hard to fix their use of the network in src
> phases, so allow them to disable things.  This allows us to turn off
> access by default and for the vast majority while we work out how to
> fix the few broken packages.
> 
> URL: https://crbug.com/731905
> ---
>  man/ebuild.5   | 4 
>  pym/portage/package/ebuild/doebuild.py | 3 ++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/man/ebuild.5 b/man/ebuild.5
> index 42a0599fe3a9..a8fc3f86b68a 100644
> --- a/man/ebuild.5
> +++ b/man/ebuild.5
> @@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
>  .I mirror
>  files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
>  .TP
> +.I network-sandbox

Please use network\-sandbox so that it renders as a minus glyph as
described in the grof_char man page:

http://man7.org/linux/man-pages/man7/groff_char.7.html

> +Disables the network namespace for specific packages.
> +Should not be used in the main Gentoo tree.
> +.TP
>  .I preserve\-libs
>  Disables preserve\-libs for specific packages. Note than when a package is
>  merged, RESTRICT=preserve\-libs applies if either the new instance or the
> diff --git a/pym/portage/package/ebuild/doebuild.py 
> b/pym/portage/package/ebuild/doebuild.py
> index 0be148fd408e..f75f11a1a424 100644
> --- a/pym/portage/package/ebuild/doebuild.py
> +++ b/pym/portage/package/ebuild/doebuild.py
> @@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
> **kwargs):
>   kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
>   phase in _ipc_phases
>   kwargs['networked'] = 'network-sandbox' not in settings.features or \
> - phase in _networked_phases
> + phase in _networked_phases or \
> + 'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
>  
>   if phase == 'depend':
>   kwargs['droppriv'] = 'userpriv' in settings.features
> 

Looks good.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Tue, 16 Jan 2018 15:58:11 +0100
Kristian Fiskerstrand  wrote:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
> > Given the situation, we have a choice: Remove GnuCash altogether, or
> > press ahead with recommending a version upstream considers
> > unstable.  
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
B. Manual action is required to continue using such package.

I see this as the most obvious choice considering that I am still
unable to find any possible attack vector against GnuCash.  If it is me
and only me who enters data.  Webkit reports are generated from those
data.  How can anyone hack me through GnuCash?

In general, many times users use applications in a way that
vulnerabilities does not apply to their use cases.  I would prefer to
be informed and allowed to continue using such application as a part of
the distro.

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

[gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Frysinger]

From: Mike Frysinger 

Some ebuilds are a bit hard to fix their use of the network in src
phases, so allow them to disable things.  This allows us to turn off
access by default and for the vast majority while we work out how to
fix the few broken packages.

URL: https://crbug.com/731905
---
 man/ebuild.5   | 4 
 pym/portage/package/ebuild/doebuild.py | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe3a9..a8fc3f86b68a 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
 .I mirror
 files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
 .TP
+.I network-sandbox
+Disables the network namespace for specific packages.
+Should not be used in the main Gentoo tree.
+.TP
 .I preserve\-libs
 Disables preserve\-libs for specific packages. Note than when a package is
 merged, RESTRICT=preserve\-libs applies if either the new instance or the
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 0be148fd408e..f75f11a1a424 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
phase in _ipc_phases
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases
+   phase in _networked_phases or \
+   'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
 
if phase == 'depend':
kwargs['droppriv'] = 'userpriv' in settings.features
-- 
2.15.1

Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 20∶04 +, użytkownik Robin H.
Johnson napisał:
> On Tue, Jan 16, 2018 at 11:32:28AM -0800, Zac Medico wrote:
> > > But app-crypt/gentoo-keys doesn't include that executable, and it has
> > > no dependency on app-crypt/gkeys. I'd rather not introduce an artificial
> > > dependency here.
> > 
> > I suppose we could using a separate ebuild to install this hook, so that
> > we can update it separately from portage if necessary. The hook can
> > still live in the portage repository (like emerge-delta-webrsync which
> > is also installed by a separate ebuild).
> 
> How about shipping this hook with Gemato, since it's of no use without
> Gemato installed.
> 

I don't want to get into USE dependency hell. Portage needs gemato to do
rsync verification, so we need USE-conditional dep on gemato. However,
gemato doesn't require the hook unconditionally, so we end up with two
USE flags that need to be switched together == a mess.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: News Item: GnuCash 2.7+ Breaking Change

[Duncan]

Kristian Fiskerstrand posted on Tue, 16 Jan 2018 15:58:11 +0100 as
excerpted:

> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>> Given the situation, we have a choice: Remove GnuCash altogether, or
>> press ahead with recommending a version upstream considers unstable.
> 
> Or 3, discuss with upstream to see if they can release an updated
> version as stable branch.

This reminds me very much of the long-time stability situation with 
grub-0.9x vs. 1.9x.  Upstream insisted 0.9x was unsupported, and indeed, 
had abandoned it, such that it was the distros carrying upstream-
unapproved patches, but at the same time, pre-2.0 as 1.9x was still very 
much development-only and not ready for prime-time, according to 
upstream.  Just what were distros and users /supposed/ to do?

Both that and this gnucash thing are bad situations all around, but 
perhaps some lessons can be had.  And agreed that surely the first must 
be to /just/ /ask/ upstream whether they can release something stable 
that's at least based on something still getting maintenance, security 
and otherwise.  Then go from there.  Maybe they'll refuse and we'll have 
to move ahead with the new version regardless of upstream's wishes, but 
we'll never know if we don't ask.

(Of course it can go the other way too, upstream insisting the new 
version is stable even when it's still broken for normal users every 
which way to Sunday.  The kde3/kde4 transition is a prime example of 
that.  I honestly don't know which is worse, but the obvious ideal is a 
sane upstream that doesn't veer to either extreme, or lacking that, at 
least cooperates and provides support when a new at least /semi-/stable 
release is needed as the old is just outdated and broken, security or 
otherwise.)

-- 
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-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Robin H. Johnson]

On Tue, Jan 16, 2018 at 11:32:28AM -0800, Zac Medico wrote:
> > But app-crypt/gentoo-keys doesn't include that executable, and it has
> > no dependency on app-crypt/gkeys. I'd rather not introduce an artificial
> > dependency here.
> 
> I suppose we could using a separate ebuild to install this hook, so that
> we can update it separately from portage if necessary. The hook can
> still live in the portage repository (like emerge-delta-webrsync which
> is also installed by a separate ebuild).
How about shipping this hook with Gemato, since it's of no use without
Gemato installed.

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

Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Zac Medico]

On 01/16/2018 10:39 AM, Michał Górny wrote:
> W dniu wto, 16.01.2018 o godzinie 12∶44 -0500, użytkownik Alec Warner
> napisał:
>> On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny  wrote:
>>
>>> Include a repo.postsync.d hook to verify the rsync checkout using
>>> gemato. Given that not all people will want to have it enabled
>>> unconditionally, no setup.py rules are included -- instead, the file
>>> would be installed conditionally by the ebuild.
>>>
>>> [v2: included link to the wiki page]
>>> ---
>>>  MANIFEST.in   |  2 +-
>>>  misc/repo.postsync.d/00gemato | 18 ++
>>>  2 files changed, 19 insertions(+), 1 deletion(-)
>>>  create mode 100644 misc/repo.postsync.d/00gemato
>>>
>>> diff --git a/MANIFEST.in b/MANIFEST.in
>>> index 4f6cac162..edc6704e7 100644
>>> --- a/MANIFEST.in
>>> +++ b/MANIFEST.in
>>> @@ -14,4 +14,4 @@ include cnf/make.conf.example.*
>>>  include .portage_not_installed
>>>
>>>  # extra scripts
>>> -include misc/*
>>> +graft misc
>>> diff --git a/misc/repo.postsync.d/00gemato b/misc/repo.postsync.d/00gemato
>>> new file mode 100644
>>> index 0..f2af50925
>>> --- /dev/null
>>> +++ b/misc/repo.postsync.d/00gemato
>>> @@ -0,0 +1,18 @@
>>> +#!/bin/bash
>>> +# repo.postsync.d hook to verify ::gentoo checkout using gemato
>>> +
>>> +name=${1}
>>> +url=${2}
>>> +path=${3}
>>> +
>>> +# keyring installed by gentoo-keys
>>> +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
>>>
>>
>> This seems a bit leaky to me.
>>
>> Possible to get gentoo-keys to print it?
>>
>> e.g:
>>
>> openpgp_key=$(gentoo-keys --print-key-path)
> 
> But app-crypt/gentoo-keys doesn't include that executable, and it has
> no dependency on app-crypt/gkeys. I'd rather not introduce an artificial
> dependency here.

I suppose we could using a separate ebuild to install this hook, so that
we can update it separately from portage if necessary. The hook can
still live in the portage repository (like emerge-delta-webrsync which
is also installed by a separate ebuild).
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 12∶44 -0500, użytkownik Alec Warner
napisał:
> On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny  wrote:
> 
> > Include a repo.postsync.d hook to verify the rsync checkout using
> > gemato. Given that not all people will want to have it enabled
> > unconditionally, no setup.py rules are included -- instead, the file
> > would be installed conditionally by the ebuild.
> > 
> > [v2: included link to the wiki page]
> > ---
> >  MANIFEST.in   |  2 +-
> >  misc/repo.postsync.d/00gemato | 18 ++
> >  2 files changed, 19 insertions(+), 1 deletion(-)
> >  create mode 100644 misc/repo.postsync.d/00gemato
> > 
> > diff --git a/MANIFEST.in b/MANIFEST.in
> > index 4f6cac162..edc6704e7 100644
> > --- a/MANIFEST.in
> > +++ b/MANIFEST.in
> > @@ -14,4 +14,4 @@ include cnf/make.conf.example.*
> >  include .portage_not_installed
> > 
> >  # extra scripts
> > -include misc/*
> > +graft misc
> > diff --git a/misc/repo.postsync.d/00gemato b/misc/repo.postsync.d/00gemato
> > new file mode 100644
> > index 0..f2af50925
> > --- /dev/null
> > +++ b/misc/repo.postsync.d/00gemato
> > @@ -0,0 +1,18 @@
> > +#!/bin/bash
> > +# repo.postsync.d hook to verify ::gentoo checkout using gemato
> > +
> > +name=${1}
> > +url=${2}
> > +path=${3}
> > +
> > +# keyring installed by gentoo-keys
> > +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
> > 
> 
> This seems a bit leaky to me.
> 
> Possible to get gentoo-keys to print it?
> 
> e.g:
> 
> openpgp_key=$(gentoo-keys --print-key-path)

But app-crypt/gentoo-keys doesn't include that executable, and it has
no dependency on app-crypt/gkeys. I'd rather not introduce an artificial
dependency here.

-- 
Best regards,
Michał Górny

Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Alec Warner]

On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny  wrote:

> Include a repo.postsync.d hook to verify the rsync checkout using
> gemato. Given that not all people will want to have it enabled
> unconditionally, no setup.py rules are included -- instead, the file
> would be installed conditionally by the ebuild.
>
> [v2: included link to the wiki page]
> ---
>  MANIFEST.in   |  2 +-
>  misc/repo.postsync.d/00gemato | 18 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>  create mode 100644 misc/repo.postsync.d/00gemato
>
> diff --git a/MANIFEST.in b/MANIFEST.in
> index 4f6cac162..edc6704e7 100644
> --- a/MANIFEST.in
> +++ b/MANIFEST.in
> @@ -14,4 +14,4 @@ include cnf/make.conf.example.*
>  include .portage_not_installed
>
>  # extra scripts
> -include misc/*
> +graft misc
> diff --git a/misc/repo.postsync.d/00gemato b/misc/repo.postsync.d/00gemato
> new file mode 100644
> index 0..f2af50925
> --- /dev/null
> +++ b/misc/repo.postsync.d/00gemato
> @@ -0,0 +1,18 @@
> +#!/bin/bash
> +# repo.postsync.d hook to verify ::gentoo checkout using gemato
> +
> +name=${1}
> +url=${2}
> +path=${3}
> +
> +# keyring installed by gentoo-keys
> +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
>

This seems a bit leaky to me.

Possible to get gentoo-keys to print it?

e.g:

openpgp_key=$(gentoo-keys --print-key-path)

Or its fine if we think it won't move around. I guess that is mostly up to
dol-sen? :)

-A


> +
> +# apply only to ::gentoo, when synced over rsync.
> +if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
> +   if ! gemato verify -K "${openpgp_key}" -s "${path}"; then
> +   eerror "For troubleshooting the verification failures,
> please see:"
> +   eerror "  https://wiki.gentoo.org/wiki/
> Project:Portage/Repository_Verification"
> +   return 1
> +   fi
> +fi
> --
> 2.16.0.rc2
>
>
>

[gentoo-dev] Re: [PATCH] linux-mod.eclass: IUSE default support for MODULES_OPTIONAL_USE

[Martin Vaeth]

Robin H. Johnson  wrote:
> That is counter-intuitive for somebody that puts
> MODULES_OPTIONAL_USE_IUSE_DEFAULT=0
> Or tries to otherwise have it unset.

What I usually do is:

case ${MODULES_OPTIONAL_USE_IUSE_DEFAULT:-n} in
  [nNfF]*|[oO][fF]*|0|-)  # false case
;;
  *) # true case
esac

This covers most of the "intuitive" attempts (0 - Off FALSE no ...)
to switch it off, and everything else (nonempty) means "on".

[gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Michał Górny]

Include a repo.postsync.d hook to verify the rsync checkout using
gemato. Given that not all people will want to have it enabled
unconditionally, no setup.py rules are included -- instead, the file
would be installed conditionally by the ebuild.

[v2: included link to the wiki page]
---
 MANIFEST.in   |  2 +-
 misc/repo.postsync.d/00gemato | 18 ++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 misc/repo.postsync.d/00gemato

diff --git a/MANIFEST.in b/MANIFEST.in
index 4f6cac162..edc6704e7 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -14,4 +14,4 @@ include cnf/make.conf.example.*
 include .portage_not_installed
 
 # extra scripts
-include misc/*
+graft misc
diff --git a/misc/repo.postsync.d/00gemato b/misc/repo.postsync.d/00gemato
new file mode 100644
index 0..f2af50925
--- /dev/null
+++ b/misc/repo.postsync.d/00gemato
@@ -0,0 +1,18 @@
+#!/bin/bash
+# repo.postsync.d hook to verify ::gentoo checkout using gemato
+
+name=${1}
+url=${2}
+path=${3}
+
+# keyring installed by gentoo-keys
+openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
+
+# apply only to ::gentoo, when synced over rsync.
+if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
+   if ! gemato verify -K "${openpgp_key}" -s "${path}"; then
+   eerror "For troubleshooting the verification failures, please 
see:"
+   eerror "  
https://wiki.gentoo.org/wiki/Project:Portage/Repository_Verification;
+   return 1
+   fi
+fi
-- 
2.16.0.rc2

[gentoo-portage-dev] [PATCH] misc: Distribute a repo.postsync.d hook to run gemato verification

[Michał Górny]

Include a repo.postsync.d hook to verify the rsync checkout using
gemato. Given that not all people will want to have it enabled
unconditionally, no setup.py rules are included -- instead, the file
would be installed conditionally by the ebuild.
---
 MANIFEST.in   |  2 +-
 misc/repo.postsync.d/00gemato | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 misc/repo.postsync.d/00gemato

diff --git a/MANIFEST.in b/MANIFEST.in
index 4f6cac162..edc6704e7 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -14,4 +14,4 @@ include cnf/make.conf.example.*
 include .portage_not_installed
 
 # extra scripts
-include misc/*
+graft misc
diff --git a/misc/repo.postsync.d/00gemato b/misc/repo.postsync.d/00gemato
new file mode 100644
index 0..758716f16
--- /dev/null
+++ b/misc/repo.postsync.d/00gemato
@@ -0,0 +1,14 @@
+#!/bin/bash
+# repo.postsync.d hook to verify ::gentoo checkout using gemato
+
+name=${1}
+url=${2}
+path=${3}
+
+# keyring installed by gentoo-keys
+openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
+
+# apply only to ::gentoo, when synced over rsync.
+if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
+   gemato verify -K "${openpgp_key}" -s "${path}"
+fi
-- 
2.16.0.rc2

Re: [gentoo-dev] Re: vanilla-sources broken

[Nicolas Bock]

On Tue, Jan 16, 2018 at 03:38:42PM +0100, Holger Hoffstätte wrote:

On 01/05/18 15:08, Nicolas Bock wrote:

currently vanilla-sources are broken, but there is an upstream patch
that fixes it (appended at the end). I know that vanilla-sources are
supposed to be vanilla, but it would help if we added this patch
until upstream backports it. Any thoughts?


This is now fixed in 4.15-rc8 (with the patch you cited) and will be
in stable 4.14.15 (the one after the upcoming release).


Hi Holger,

thanks for the information!

Best,

Nick


cheers,
Holger



--
Nicolas Bock 


signature.asc
Description: PGP signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Kristian Fiskerstrand]

On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
> Given the situation, we have a choice: Remove GnuCash altogether, or
> press ahead with recommending a version upstream considers unstable.

Or 3, discuss with upstream to see if they can release an updated
version as stable branch.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Aaron W. Swenson]

On 2018-01-16 15:07, Róbert Čerňanský wrote:
> On Wed, 10 Jan 2018 22:46:04 +0200
> Mart Raudsepp  wrote:
> > 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> > we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> > uses it daily) to work quite nicely.
> > I want to last rite gnucash-2.6 used webkit-gtk before the month is
> > over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> > will simply be fully masked as well along it.
> 
> I assume that the motivation to get 2.7 stabilized early it to protect
> users from potentional damages caused via webkit-gtk security
> vulnerabilities.  However, provided that I use GnuCash to display only
> local web data (generated reports) I feel much more comfortable
> to entrust my data to the stable 2.6 version rather than unstable 2.7
> about which the upstream says:
> 
> "Unstable (development) releases are for testing purposes only. They
> contain the newest features and improvements, but may also contain
> serious bugs still. Don't install these releases for everyday use." [1]
> 
> "Due to the possibility of data corruption, unstable releases should
> only be used on a copy of live GnuCash data." [2]
> 
> I think generated reports are typical use of webkit in GnuCash.  Are
> attack vectors so severe also in this case?
> 
> Thank you.
> 
> 1. http://gnucash.org/download.phtml
> 2. https://wiki.gnucash.org/wiki/Development_Process
> 
> Robert

You are welcome to keep the insecure/outdated packages on your
machine. You do not have to update. We’re just working towards the long
overdue removal of a security risk from the tree.

Really, it isn’t so much that gnucash is at risk because it uses the old
insecure net-libs/webkit-gtk:2 (it may very well be, but there haven’t
been any reports that I’ve seen), but it is all the other packages that
use webkit-gtk to render HTML from untrusted sources that are at risk.

If we could have, we would have removed net-libs/webkit-gtk:{2,3} long
ago. This is nearly two years overdue. [1]

However, this removal will result in it being impossible for anyone to
build gnucash-2.6, so that must be removed as well.

Given the situation, we have a choice: Remove GnuCash altogether, or
press ahead with recommending a version upstream considers unstable.

[1]: https://bugs.gentoo.org/577068


signature.asc
Description: Digital signature

[gentoo-dev] Re: vanilla-sources broken

[Holger Hoffstätte]

On 01/05/18 15:08, Nicolas Bock wrote:
> currently vanilla-sources are broken, but there is an upstream patch
> that fixes it (appended at the end). I know that vanilla-sources are
> supposed to be vanilla, but it would help if we added this patch
> until upstream backports it. Any thoughts?

This is now fixed in 4.15-rc8 (with the patch you cited) and will be
in stable 4.14.15 (the one after the upcoming release).

cheers,
Holger

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Kristian Fiskerstrand]

On 01/16/2018 03:07 PM, Róbert Čerňanský wrote:
> I think generated reports are typical use of webkit in GnuCash.  Are
> attack vectors so severe also in this case?

Yes, as it would hinder upgrade / keep the vulnerable libraries on the
system that can possibly be used by other packages.

That said, I agree with the overall premise of discussion, and stability
guarantees for the stable keywords, have anyone been in contact with
upstream and discussed the issue of getting a stable release branch not
based on the old webkit?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[Róbert Čerňanský]

On Wed, 10 Jan 2018 22:46:04 +0200
Mart Raudsepp  wrote:

> On Wed, 2018-01-10 at 22:38 +0300, Peter Volkov wrote:
> > On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson
> >  > org> wrote:
> > > Title: GnuCash 2.7+ Breaking Change  
> > 
> > Aaron, but why do we need this news item? 2.7 version is a
> > development version that is not supposed to be used by end users. As
> > far as I understand this backup is a temporary measure until stable
> > release will be out. It's much better to have this version package
> > masked. Then in package mask comment we could note the need for
> > backup.  
> 
> 2.6 is insecure by 400+ ancient webkit-gtk security vulnerabilities,
> we can't responsibly wait anymore. 2.7.3 was tested by Aaron (who
> uses it daily) to work quite nicely.
> I want to last rite gnucash-2.6 used webkit-gtk before the month is
> over, as the maintainer of webkit-gtk, and if 2.7 isn't there, 2.6
> will simply be fully masked as well along it.

I assume that the motivation to get 2.7 stabilized early it to protect
users from potentional damages caused via webkit-gtk security
vulnerabilities.  However, provided that I use GnuCash to display only
local web data (generated reports) I feel much more comfortable
to entrust my data to the stable 2.6 version rather than unstable 2.7
about which the upstream says:

"Unstable (development) releases are for testing purposes only. They
contain the newest features and improvements, but may also contain
serious bugs still. Don't install these releases for everyday use." [1]

"Due to the possibility of data corruption, unstable releases should
only be used on a copy of live GnuCash data." [2]

I think generated reports are typical use of webkit in GnuCash.  Are
attack vectors so severe also in this case?

Thank you.

1. http://gnucash.org/download.phtml
2. https://wiki.gnucash.org/wiki/Development_Process

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Dirkjan Ochtman]

On Tue, Jan 16, 2018 at 11:19 AM, Michał Górny  wrote:

> I disagree. I think most of the developers are used to the lexical sort,
> and it keeps the order predictable. While I suppose keeping amd64
> and x86 alongside for the sake of being commonly used would make sense,
> I really have no clue how that would affect other arches.
>

It is a trade-off, of course. My hypothesis is that it would be easier to
use.


> By 'frequency' did you mean how many ebuilds are having the specific
> keyword? Could you make some quick stats that would show how this would
> look like right now?
>

Here's an estimation of the relative frequencies:

amd64 (37201)
x86 (33703)
ppc (15347)
arm (14387)
ppc64 (11647)
sparc (10054)
alpha (9219)
ia64 (8456)
hppa (8410)
arm64 (8194)
amd64-linux (7716)
mips (7602)
x86-linux (7409)
x86-fbsd (6102)
sh (4885)
s390 (4421)
ppc-macos (4098)
x86-macos (4028)
amd64-fbsd (3361)
x86-solaris (3202)
x64-macos (3187)
sparc-solaris (2464)
x64-solaris (2208)
m68k (2204)
sparc64-solaris (1344)
arm-linux (1135)
ppc-aix (971)
sparc-fbsd (902)
m68k-mint (626)
x64-cygwin (432)
x86-winnt (123)
x86-interix (5)
x86-cygwin (5)
ia64-hpux (5)
ppc64-linux (4)
arm64-linux (4)
x86-freebsd (1)

Regards,

Dirkjan

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 14∶09 +0100, użytkownik Francesco
Riosa napisał:
> 
> On 16/01/2018 08:57, Michał Górny wrote:
> > W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
> > Riosa napisał:
> > > In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added
> > > to all python eclasses, it's useful for developers that want test and
> > > mark the package for newer versions of python.
> > > 
> > > However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
> > > usable if:
> > > - the user want only python 2.7 and 3.6 (latest) installed
> > >   no python 3.5
> > > - don't want to mess dependencies (the warnings in the eclass are scary)
> > 
> > Because it is not meant to be used for that purpose, and it is not meant
> > to be used by users at all! It's just a quick hack for developer who
> > wants to UNLIKELY(check if package works with implementation X) before
> > he starts the effort on modifying PYTHON_COMPAT in ebuilds.
> 
> supposed that, but at this point I fail to see the benefit versus the
> added complexity in the eclasses, however that's not my business.
> > 
> > > So, what can be done to let the user choose it's preferred python
> > > version(s) without having to build it's own overlay?
> > > 
> > > One solution is to change ebuilds in tree to include a user variable in
> > > the PYTHON* arrays, example:
> > > 
> > > -PYTHON_COMPAT=( python3_{4,5} )
> > > +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> > > 
> > > if someone want to bet that packages are ok with 3.6/latest (even before
> > > a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> > > /etc/portage/make.conf and run egencache.
> > > 
> > > Indeed biggest problem in changing $PYTHON* variables is that metadata
> > > also change and cache is invalidated.
> > > 
> > > However if the problem is known (*), and if the change to metadata is
> > > stable per "system"/"gentoo repo clone", then the solution to the
> > > problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
> > > after each sync.
> > 
> > This won't work. You are wrongly presuming that egencache regenerates
> > cache unconditionally. It does so only if either ebuild or eclass
> > content changed. So it worked for you once because you modified ebuilds
> > and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
> > 
> > I haven't checked the Portage details but it may see the metadata change
> > when installing the package. Which means it would install package with
> > unsatisfied dependencies (because it satisfied dependencies from cache),
> > then store the final dependencies and TADAAM, you've got broken
> > depgraph.
> 
> ouch, that basically kill the proposal, unless portage is modified to
> check known cache modifying variables, which isn't something I'd like to
> create.
> > 
> > > The most important thing is that this solution is scriptable and need no
> > > human intervention.
> > 
> > So is gpy-upgrade-impl.
> 
> It seem to do the job, one piece missing is something that monitor
> gentoo repository to see if it has better version (still w/o wanted
> python), an inotify for ebuilds. Suggestions?

None. I think Alec's idea would work better for you.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Francesco Riosa]

On 16/01/2018 01:40, Alec Warner wrote:
>
>
> On Mon, Jan 15, 2018 at 7:05 PM, Francesco Riosa  > wrote:
>
>
>
> On 15/01/2018 18:07, Mike Gilbert wrote:
> > On Mon, Jan 15, 2018 at 10:27 AM, Francesco Riosa
> > wrote:
> >> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized
> and added
> >> to all python eclasses, it's useful for developers that want
> test and
> >> mark the package for newer versions of python.
> >>
> >> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE
> is not
> >> usable if:
> >> - the user want only python 2.7 and 3.6 (latest) installed
> >>   no python 3.5
> >> - don't want to mess dependencies (the warnings in the eclass
> are scary)
> >>
> >> So, what can be done to let the user choose it's preferred python
> >> version(s) without having to build it's own overlay?
> >>
> >> One solution is to change ebuilds in tree to include a user
> variable in
> >> the PYTHON* arrays, example:
> >>
> >> -PYTHON_COMPAT=( python3_{4,5} )
> >> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> >>
> >> if someone want to bet that packages are ok with 3.6/latest
> (even before
> >> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> >> /etc/portage/make.conf and run egencache.
> > I like the idea to inject values into PYTHON_COMPAT instead of
> > overriding it completely. I'm pretty sure this can/should be
> > implemented in the eclass without touching ebuilds.
> In my mind that was to leave ebuilds developers the ability to opt
> out,
> but well that could also be done in the eclasses.
> Opt out could be beneficial for packages that only support python 2.7,
> or where there are known and documented problems with different python
> versions.
> >
> > I'm not sure I really like the idea of affecting the other metadata
> > variables. I can see your point about wanting to remove python
> > versions that would otherwise satisfy dependencies. If metadata is
> > modified this way, it would definitely be "unsupported".
> I've not tought about remove python versions, only add them
> (beneficial
> for users that like to use experimental python versions)
> However the supported python version are translated and build
> important
> cached variables IUSE, DEPEND, etc. so there is no way to cleanly
> modify
> those variable after the cache has been generated.
> The only viable option is to regenerate, update or delete it.
>
> >
> > As far as implementation, you would probably need to write the
> patches for this.
> If there is consensus that's not a problem, cannot guarantee to be
> fast
> however
> >
> > Also, I expect the QA team might have some objections, so you
> may want
> > to discuss it with them (especially mgorny) before spending too much
> > time on it.
> I'd like to hear mgorny opinions but that should be a more extended
> decision than only QA and the python eclasses developer(s).
> If nothing else because deciding that sometimes may be good to let the
> user break the cache is a global decision and documentation need to be
> added.
>
>
> I'm seeing less value in this being a 'cache-breaking' exercise and
> more value in it simply being a custom eclass.
>
> If you hoist the eclass into an overlay and modify it (e.g. to set the
> var and get the deps you want) the caching
> all works out fine.
>
> 1. The source of the data is the hoisted eclass.
> 2. The eclass mtime changed.
> 3. package managers can see that and update cache metadata for
> inheriting ebuilds.
> 4. Bonus, once the cache is generated we have a valid means to see if
> the cache remains valid.
> 5. Double bonus, any ebuilds not inheriting the eclass are unaffected.
>
> I'm not sure why this is so onerous.
>
> -A
That's a good idea, in the past I've failed to completely understand how
portage inherit eclasses in overlays, but if I can figure that out
probably this could be a solution.
Also depending from the magnitude of changes the four python eclasses
need and the correlated maintenance burden.

Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

[Francesco Riosa]

On 16/01/2018 08:57, Michał Górny wrote:
> W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
> Riosa napisał:
>> In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added
>> to all python eclasses, it's useful for developers that want test and
>> mark the package for newer versions of python.
>>
>> However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
>> usable if:
>> - the user want only python 2.7 and 3.6 (latest) installed
>>   no python 3.5
>> - don't want to mess dependencies (the warnings in the eclass are scary)
> Because it is not meant to be used for that purpose, and it is not meant
> to be used by users at all! It's just a quick hack for developer who
> wants to UNLIKELY(check if package works with implementation X) before
> he starts the effort on modifying PYTHON_COMPAT in ebuilds.
supposed that, but at this point I fail to see the benefit versus the
added complexity in the eclasses, however that's not my business.
>
>> So, what can be done to let the user choose it's preferred python
>> version(s) without having to build it's own overlay?
>>
>> One solution is to change ebuilds in tree to include a user variable in
>> the PYTHON* arrays, example:
>>
>> -PYTHON_COMPAT=( python3_{4,5} )
>> +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
>>
>> if someone want to bet that packages are ok with 3.6/latest (even before
>> a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
>> /etc/portage/make.conf and run egencache.
>>
>> Indeed biggest problem in changing $PYTHON* variables is that metadata
>> also change and cache is invalidated.
>>
>> However if the problem is known (*), and if the change to metadata is
>> stable per "system"/"gentoo repo clone", then the solution to the
>> problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
>> after each sync.
> This won't work. You are wrongly presuming that egencache regenerates
> cache unconditionally. It does so only if either ebuild or eclass
> content changed. So it worked for you once because you modified ebuilds
> and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
>
> I haven't checked the Portage details but it may see the metadata change
> when installing the package. Which means it would install package with
> unsatisfied dependencies (because it satisfied dependencies from cache),
> then store the final dependencies and TADAAM, you've got broken
> depgraph.
ouch, that basically kill the proposal, unless portage is modified to
check known cache modifying variables, which isn't something I'd like to
create.
>
>> The most important thing is that this solution is scriptable and need no
>> human intervention.
> So is gpy-upgrade-impl.
It seem to do the job, one piece missing is something that monitor
gentoo repository to see if it has better version (still w/o wanted
python), an inotify for ebuilds. Suggestions?
>
>> Notice also that it's easy to have an array with duplicate values
>> PYTHON_COMPAT=( python3_6 python3_6 ) but at a first glance
>> _python_set_impls() is resilient to this.
>>
>> (*) In a perfect world, where global variables that can change metadata
>> are known {egencache,emerge} can be made conscious and warn if the cache
>> is invalid, but that's out of scope at the moment.
> This isn't perfect world. This is the exact opposite of it, it would be
> a mess. Also, conscious tools would probably start plotting against you
> if you'd give them such horrible tasks.
>

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Michał Górny]

W dniu wto, 16.01.2018 o godzinie 10∶15 +0100, użytkownik Dirkjan
Ochtman napisał:
> On Mon, Jan 15, 2018 at 11:01 PM, Michał Górny  wrote:
> 
> > Besides regrouping, I've also reordered the keywords to use the same
> > sorting order as eshowkw (i.e. ppc before ppc64), moved 'BSD' into teams
> 
> (in contrast to 'AMD64 FBSD' and 'X86 FBSD'), and added 'Prefix' team.
> > 
> 
> I think these are all good improvements. In terms of having the best user
> experience, I would actually advocate changing the order to sort by
> frequency/use. So the list would just start with amd64, then x86, arm64,
> ppc, or something like that? Probably we should still match order with
> eshowkw, maybe there should be a file somewhere that keeps the current
> order and we can regenerate it from time to time based on the latest use
> counts.
> 

I disagree. I think most of the developers are used to the lexical sort,
and it keeps the order predictable. While I suppose keeping amd64
and x86 alongside for the sake of being commonly used would make sense,
I really have no clue how that would affect other arches.

By 'frequency' did you mean how many ebuilds are having the specific
keyword? Could you make some quick stats that would show how this would
look like right now?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Dirkjan Ochtman]

On Mon, Jan 15, 2018 at 11:01 PM, Michał Górny  wrote:

> Besides regrouping, I've also reordered the keywords to use the same
> sorting order as eshowkw (i.e. ppc before ppc64), moved 'BSD' into teams

(in contrast to 'AMD64 FBSD' and 'X86 FBSD'), and added 'Prefix' team.
>

I think these are all good improvements. In terms of having the best user
experience, I would actually advocate changing the order to sort by
frequency/use. So the list would just start with amd64, then x86, arm64,
ppc, or something like that? Probably we should still match order with
eshowkw, maybe there should be a file somewhere that keeps the current
order and we can regenerate it from time to time based on the latest use
counts.

Regards,

Dirkjan