Re: [gentoo-portage-dev] [PATCH 2/2] repoman: Enable testing exp profiles by default

[Michał Górny]

Dnia 11 stycznia 2018 07:54:40 CET, Mike Gilbert  
napisał(a):
>On Wed, Jan 10, 2018 at 11:10 PM, Michał Górny 
>wrote:
>> W dniu śro, 10.01.2018 o godzinie 21∶45 -0500, użytkownik Mike
>Gilbert
>> napisał:
>>> On Wed, Jan 10, 2018 at 5:56 PM, Zac Medico 
>wrote:
>>> > On 01/10/2018 02:24 PM, Michał Górny wrote:
>>> > > Enable repoman checks on exp profiles by default to improve
>>> > > the dependency graph integrity on those profiles and help them
>on their
>>> > > way towards stable status. This is possible now that the
>dependency
>>> > > graph problems are warnings rather than errors.
>>> > > ---
>>> > >  repoman/pym/repoman/argparser.py | 2 +-
>>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> > >
>>> > > diff --git a/repoman/pym/repoman/argparser.py
>b/repoman/pym/repoman/argparser.py
>>> > > index f32972288..d49147366 100644
>>> > > --- a/repoman/pym/repoman/argparser.py
>>> > > +++ b/repoman/pym/repoman/argparser.py
>>> > > @@ -167,7 +167,7 @@ def parse_args(argv, qahelp,
>repoman_default_opts):
>>> > >
>>> > >   parser.add_argument(
>>> > >   '-e', '--include-exp-profiles', choices=('y',
>'n'), metavar='',
>>> > > - default=False,
>>> > > + default='y',
>>> > >   help='include exp profiles in dependency checks')
>>> > >
>>> > >   parser.add_argument(
>>> > >
>>> >
>>> > We have dev and exp profiles disabled by default because the time
>>> > consumed by repoman is proportional to the number of profiles.
>>> >
>>> > The current counts are as follows:
>>> >
>>> > stable 87
>>> > dev 88
>>> > exp 149
>>>
>>> Yeah, I really don't like the idea of making repoman even slower by
>default.
>>
>> The alternative is to go for all profiles being stable. Because
>> accepting developers randomly breaking profiles 'because repoman
>speed'
>> is not acceptable.
>
>I disagree. Many of these are profiles that are seldom used and very
>few users are affected by any breakage.
>
>There's a balance to be struck here, and I think it's pretty good
>right where it is.

Just to be clear, the current counts are irrelevant. The goal is to have a 
second status that covers profiles on their way to becoming stable. This patch 
is part of that thread.


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

Re: [gentoo-dev] [PATCH 1/2] profiles.desc: Reduce the status of most exp profiles to dev

[Ulrich Mueller]

> On Thu, 11 Jan 2018, Michał Górny wrote:

>> So you're *promoting* the ones considered to be broken from "exp"
>> to "dev"?

> Please point me to one bit of documentation that says that 'dev' is
> better than 'exp' because I haven't been able to find any. Well,
> except the fact that PMS lists 'stable' and 'dev' as example
> statuses, and doesn't list 'exp' at all.

Initially, "exp" profiles were introduced here:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/profiles.desc?revision=1.149=markup
with the commit message "*Drop* all Prefix profiles to experimental
state for the time being" (my emphasis). From this it seems to be
clear that "exp" was intended to be less stable than "dev".

Later, there was this council decision:
https://projects.gentoo.org/council/meeting-logs/20140225-summary.txt

- Vote: Minor archs with inconsistent stable keywording should be
  marked "exp".
  Accepted unanimously.

Subsequently, these arches were dropped from "dev" to "exp" status:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/profiles.desc?revision=1.238=markup

> That said, repoman currently treats failures in exp as errors, while
> in dev as warnings. This makes me believe 'exp' was considered
> higher.

> Furthermore, the switch for -e is boolean, while -d is unary.

How can syntax of an option in one of our tools be an argument here?
Also, isn't that simply inconsistent? If anything, they should both
changed to be consistent, e.g., changed into simple switches -d and -e
without option argument.

> So we can enable testing exp by default without having to change
> usage of repoman.

So repoman will become even slower, by about a factor of about three
(assuming that time is linear with the number of profiles)? That's not
acceptable, because it will impede on maintainers' workflow.

Ulrich


pgpeEKYMYtvff.pgp
Description: PGP signature

[gentoo-dev] about stable, dev and exp profile status

[Fabian Groffen]

On 07-01-2018 21:25:28 +0100, Michał Górny wrote:
> I'd like to follow this with a more precise proposal. Namely, redefine
> the current profile statuses to apply the following:
> 
> a. stable -> fully tested, all depgraph breakages are errors,
> 
> b. exp -> fully tested, all depgraph breakages are warnings,
> 
> c. dev -> developer's playground, not tested.

I always was under the impression the following order (and explanation)
was the case:

stable -> development -> experimental

For this reason, e.g. Prefix profiles are (still) experimental, which
means they really shouldn't bother non-Prefix people.  Prefix users and
developers work on an environment where those profiles are promoted to
development ones, such that repoman kicks in for their work.  (At least
that was the idea.)

I see you (re-)define dev as "developer's playground", and I wonder if
in that case it wouldn't be better to introduce a new one instead?

Maybe I'm just one of a few who thinks the order is reversed now.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 1/2] profiles.desc: Reduce the status of most exp profiles to dev

[Michał Górny]

Dnia 11 stycznia 2018 07:07:30 CET, Ulrich Mueller  napisał(a):
>> On Thu, 11 Jan 2018, Michał Górny wrote:
>
>> Given the new semantic meaning of profile statuses,
>
>Huh? Have I missed something? Please provide a pointer to the
>discussion.

https://archives.gentoo.org/gentoo-dev/message/81afaadf4caa1e733cb058a37d3638c4

If you can call it a discussion, given it's much less important than whether 
people will be able to theoretically freely reply to threads such as that.

It's also on the agenda, so I'm adding patches.

>
>> reduce most of the current exp profiles that are known or likely to
>> have broken depgraph to dev status. Those profiles will be moved
>> one-by-one back to exp once the integrity of their depgraph is
>> confirmed.
>
>So you're *promoting* the ones considered to be broken from "exp"
>to "dev"?

Please point me to one bit of documentation that says that 'dev' is better than 
'exp' because I haven't been able to find any. Well, except the fact that PMS 
lists 'stable' and 'dev' as example statuses, and doesn't list 'exp' at all.

That said, repoman currently treats failures in exp as errors, while in dev as 
warnings. This makes me believe 'exp' was considered higher.

Furthermore, the switch for -e is boolean, while -d is unary. So we can enable 
testing exp by default without having to change usage of repoman.

>
>Ulrich


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

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Eray Aslan]

On Wed, Jan 10, 2018 at 08:55:11AM +0100, Lars Wendler wrote:
> Seems we're turning into an elitist club or something... 

Elitist seems too kind a word.  Knee-jerk reaction, petty vendetta,
impulsive emotional reaction comes to mind - instead of articulating and
implementing a vision for the distribution, principled action, making
all devs work together towards the goals that have been set.  Not day to
day reactions and bad ones at that.  Council is failing its one main
task - it prolly has been for some time, this one also fails "first, do
no harm" test.

Mind you they are not harming willingly.  I am pretty sure they are all
well intentioned.  They, as a group, just do not have, I dont know, the
vision, the experience, the personality to lead a distro.

We need a change as otherwise I am afraid the future is not bright.  I
think with this last straw I lost faith in the current setup.  Death by
a committee.  Yey.

-- 
Eray

Re: [gentoo-portage-dev] [PATCH 2/2] repoman: Enable testing exp profiles by default

[Mike Gilbert]

On Wed, Jan 10, 2018 at 11:10 PM, Michał Górny  wrote:
> W dniu śro, 10.01.2018 o godzinie 21∶45 -0500, użytkownik Mike Gilbert
> napisał:
>> On Wed, Jan 10, 2018 at 5:56 PM, Zac Medico  wrote:
>> > On 01/10/2018 02:24 PM, Michał Górny wrote:
>> > > Enable repoman checks on exp profiles by default to improve
>> > > the dependency graph integrity on those profiles and help them on their
>> > > way towards stable status. This is possible now that the dependency
>> > > graph problems are warnings rather than errors.
>> > > ---
>> > >  repoman/pym/repoman/argparser.py | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/repoman/pym/repoman/argparser.py 
>> > > b/repoman/pym/repoman/argparser.py
>> > > index f32972288..d49147366 100644
>> > > --- a/repoman/pym/repoman/argparser.py
>> > > +++ b/repoman/pym/repoman/argparser.py
>> > > @@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
>> > >
>> > >   parser.add_argument(
>> > >   '-e', '--include-exp-profiles', choices=('y', 'n'), 
>> > > metavar='',
>> > > - default=False,
>> > > + default='y',
>> > >   help='include exp profiles in dependency checks')
>> > >
>> > >   parser.add_argument(
>> > >
>> >
>> > We have dev and exp profiles disabled by default because the time
>> > consumed by repoman is proportional to the number of profiles.
>> >
>> > The current counts are as follows:
>> >
>> > stable 87
>> > dev 88
>> > exp 149
>>
>> Yeah, I really don't like the idea of making repoman even slower by default.
>
> The alternative is to go for all profiles being stable. Because
> accepting developers randomly breaking profiles 'because repoman speed'
> is not acceptable.

I disagree. Many of these are profiles that are seldom used and very
few users are affected by any breakage.

There's a balance to be struck here, and I think it's pretty good
right where it is.

Re: [gentoo-dev] [PATCH 1/2] profiles.desc: Reduce the status of most exp profiles to dev

[Ulrich Mueller]

> On Thu, 11 Jan 2018, Michał Górny wrote:

> Given the new semantic meaning of profile statuses,

Huh? Have I missed something? Please provide a pointer to the
discussion.

> reduce most of the current exp profiles that are known or likely to
> have broken depgraph to dev status. Those profiles will be moved
> one-by-one back to exp once the integrity of their depgraph is
> confirmed.

So you're *promoting* the ones considered to be broken from "exp"
to "dev"?

Ulrich


pgpiaVGwn4Peq.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list

[Gordon Pettey]

On Wed, Jan 10, 2018 at 10:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as excerpted:
>
>> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL:
>>> Le 2018-01-10 10:53, Michał Górny a écrit :
>>> > Last I checked, Gentoo was a Linux distribution. However, some people
>>> > prefer to turn it into open discussion forum that has nothing to do
>>> > with making a distribution.
>>>
>>> No it has. Giving power to a subset of users, denying interaction with
>>> future contributors unless they enroll is the eaxct way to kill Gentoo
>>> as a community !
>>
>> We wouldn't have needed to go this far if not for a few outside trolls
>> who
>> * keep pushing their personal agenda in endless threads,
>> * confuse their own inability to contribute with being a mistreated
>> underdog,
>> * and keep commenting opinionated on technical things they
>> plainly have no clue about (while whining when are told they sprout
>> bulls##t).
>>
>> We do not have a problem with "future contributors". I wager those will
>> rather increase in numbers once the list spam is gone.
>
>
> This has been my biggest concern about the whole thing:
>
> Are we going to be nipping future devs in the bud because there's now too
> many hoops to jump thru too early, and it's simply not worth the trouble
> when they can (and will) go elsewhere where it's easier,
>
> OR
>
> Are we going to be lowering the unwelcoming noise, confusion and name-
> calling threshold and making the community more welcoming for those who
> have a serious interest, clearing out some of the stuff that could
> otherwise discourage them.
>
>
> It's pretty clear that council believes it's the latter, at least to the
> degree that they're willing to try it for a time, effectively a wager of
> sorts, but I don't believe anyone can honestly say what the real effect
> one way or the other will be until it /is/ tried.
>
>
> Personally, my viewpoint is that while over the last year or so there
> were some 1-2 level frustrating posters on a 5-point scale, it's nothing
> compared to the level-4 (direct name calling, just short of physical
> threats that justify getting the law involved) stuff that I've seen on
> this list in the some-years-distant past.  In my mind, unquestionably
> that level-4 stuff required action, and it was taken.
>
> The recent stuff seems so much milder in comparison that IMO it's hard to
> see what the hubbub is all about, but there's certainly an argument to be
> made that the previous experience simply desensitized our detection
> meters, and that were it not for that, the recent stuff would seem rather
> more shocking and horrible than it does, and that even if it's /less/
> horrible, it's horrible /enough/ that it remains unacceptable in a
> civilized society, and if we /do/ accept it, we're effectively pushing
> others that won't, out.

Given the quantity of relevant problem-mail that came from
@gentoo.org, maybe the glass house dwellers should be careful where
they aim their stones. I considered taking the dev quiz and everything
instead of just posting a few ebuilds on bugzilla years ago, but the
elitist, as Alex labelled it, voices from @gentoo.org are what made me
decide not to, and my decision keeps getting reinforced. That
impression has been there for years, and it's not getting better by
this.

[gentoo-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list

[Duncan]

Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as excerpted:

> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL:
>> Le 2018-01-10 10:53, Michał Górny a écrit :
>> > Last I checked, Gentoo was a Linux distribution. However, some people
>> > prefer to turn it into open discussion forum that has nothing to do
>> > with making a distribution.
>> 
>> No it has. Giving power to a subset of users, denying interaction with
>> future contributors unless they enroll is the eaxct way to kill Gentoo
>> as a community !
> 
> We wouldn't have needed to go this far if not for a few outside trolls
> who
> * keep pushing their personal agenda in endless threads,
> * confuse their own inability to contribute with being a mistreated
> underdog,
> * and keep commenting opinionated on technical things they
> plainly have no clue about (while whining when are told they sprout
> bulls##t).
> 
> We do not have a problem with "future contributors". I wager those will
> rather increase in numbers once the list spam is gone.


This has been my biggest concern about the whole thing:

Are we going to be nipping future devs in the bud because there's now too 
many hoops to jump thru too early, and it's simply not worth the trouble 
when they can (and will) go elsewhere where it's easier,

OR

Are we going to be lowering the unwelcoming noise, confusion and name-
calling threshold and making the community more welcoming for those who 
have a serious interest, clearing out some of the stuff that could 
otherwise discourage them.


It's pretty clear that council believes it's the latter, at least to the 
degree that they're willing to try it for a time, effectively a wager of 
sorts, but I don't believe anyone can honestly say what the real effect 
one way or the other will be until it /is/ tried.


Personally, my viewpoint is that while over the last year or so there 
were some 1-2 level frustrating posters on a 5-point scale, it's nothing 
compared to the level-4 (direct name calling, just short of physical 
threats that justify getting the law involved) stuff that I've seen on 
this list in the some-years-distant past.  In my mind, unquestionably 
that level-4 stuff required action, and it was taken.

The recent stuff seems so much milder in comparison that IMO it's hard to 
see what the hubbub is all about, but there's certainly an argument to be 
made that the previous experience simply desensitized our detection 
meters, and that were it not for that, the recent stuff would seem rather 
more shocking and horrible than it does, and that even if it's /less/ 
horrible, it's horrible /enough/ that it remains unacceptable in a 
civilized society, and if we /do/ accept it, we're effectively pushing 
others that won't, out.


So I'm worried; I honestly don't know which way this will go, but I 
expect it /will/ have a noticeable impact one way or the other.

Of course as others I do wish it never would have come to this, as well, 
but then again we live in a world where some people will always be 
pushing the borders, no matter where they are set, and where regardless 
of where the line is drawn, some people will be excluded, ether because 
of the abuse they refuse to tolerate so they go elsewhere, or because of 
the infringement of what they see as rightful liberty to heap that abuse 
on others, so they go elsewhere.


But the council has made one of the hard calls they're elected to make, 
for which tho I may be worried I can't fault them, and now we get to see 
how it all plays out.  But whether they, and gentoo as a whole, wins that 
effective wager, or loses it, the bet has now been placed, so nothing to 
do but wait and see the results. =:^/

-- 
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-dev] [PATCH 2/2] profiles.desc: Move known-good amd64 profiles to exp

[Michał Górny]

---
 profiles/profiles.desc | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index b929cb89e109..44709983f9e3 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -20,7 +20,7 @@ alpha   default/linux/alpha/17.0/developer
  exp
 
 # AMD64 Profiles
 amd64   default/linux/amd64/13.0stable
-amd64   default/linux/amd64/13.0/selinuxdev
+amd64   default/linux/amd64/13.0/selinuxexp
 amd64   default/linux/amd64/13.0/desktopstable
 amd64   default/linux/amd64/13.0/desktop/gnome  stable
 amd64   default/linux/amd64/13.0/desktop/gnome/systemd  stable
@@ -29,11 +29,11 @@ amd64   
default/linux/amd64/13.0/desktop/plasma/systemd stable
 amd64   default/linux/amd64/13.0/developer  stable
 amd64   default/linux/amd64/13.0/no-multilibstable
 amd64   default/linux/amd64/13.0/systemdstable
-amd64   default/linux/amd64/13.0/x32dev
+amd64   default/linux/amd64/13.0/x32exp
 amd64   default/linux/amd64/17.0stable
-amd64   default/linux/amd64/17.0/selinuxdev
-amd64   default/linux/amd64/17.0/hardened   dev
-amd64   default/linux/amd64/17.0/hardened/selinux   dev
+amd64   default/linux/amd64/17.0/selinuxexp
+amd64   default/linux/amd64/17.0/hardened   exp
+amd64   default/linux/amd64/17.0/hardened/selinux   exp
 amd64   default/linux/amd64/17.0/desktopstable
 amd64   default/linux/amd64/17.0/desktop/gnome  stable
 amd64   default/linux/amd64/17.0/desktop/gnome/systemd  stable
@@ -41,8 +41,8 @@ amd64   default/linux/amd64/17.0/desktop/plasma   
  stable
 amd64   default/linux/amd64/17.0/desktop/plasma/systemd stable
 amd64   default/linux/amd64/17.0/developer  stable
 amd64   default/linux/amd64/17.0/no-multilibstable
-amd64   default/linux/amd64/17.0/no-multilib/hardened   dev
-amd64   default/linux/amd64/17.0/no-multilib/hardened/selinux   dev
+amd64   default/linux/amd64/17.0/no-multilib/hardened   exp
+amd64   default/linux/amd64/17.0/no-multilib/hardened/selinux   exp
 amd64   default/linux/amd64/17.0/systemdstable
 amd64   default/linux/amd64/17.0/x32dev
 
-- 
2.16.0.rc1

[gentoo-dev] [PATCH 1/2] profiles.desc: Reduce the status of most exp profiles to dev

[Michał Górny]

Given the new semantic meaning of profile statuses, reduce most
of the current exp profiles that are known or likely to have broken
depgraph to dev status. Those profiles will be moved one-by-one
back to exp once the integrity of their depgraph is confirmed.
---
 profiles/profiles.desc | 248 -
 1 file changed, 124 insertions(+), 124 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index 4e3223a76b14..b929cb89e109 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -91,15 +91,15 @@ arm default/linux/arm/13.0/armv7a/developer 
dev
 
 # ARM64 Profiles
 arm64   default/linux/arm64/13.0dev
-arm64   default/linux/arm64/13.0/desktopexp
+arm64   default/linux/arm64/13.0/desktopdev
 arm64   default/linux/arm64/13.0/desktop/systemddev
-arm64   default/linux/arm64/13.0/developer  exp
-arm64   default/linux/arm64/13.0/systemdexp
+arm64   default/linux/arm64/13.0/developer  dev
+arm64   default/linux/arm64/13.0/systemddev
 arm64   default/linux/arm64/17.0dev
-arm64   default/linux/arm64/17.0/desktopexp
+arm64   default/linux/arm64/17.0/desktopdev
 arm64   default/linux/arm64/17.0/desktop/systemddev
-arm64   default/linux/arm64/17.0/developer  exp
-arm64   default/linux/arm64/17.0/systemdexp
+arm64   default/linux/arm64/17.0/developer  dev
+arm64   default/linux/arm64/17.0/systemddev
 
 # HPPA Profiles
 hppadefault/linux/hppa/13.0 stable
@@ -122,32 +122,32 @@ ia64
default/linux/ia64/17.0/desktop/gnome/systemd   stable
 ia64default/linux/ia64/17.0/developer   stable
 
 # M68K Profiles
-m68kdefault/linux/m68k/13.0 exp
-m68kdefault/linux/m68k/13.0/desktop exp
-m68kdefault/linux/m68k/13.0/desktop/gnome   exp
-m68kdefault/linux/m68k/13.0/developer   exp
-m68kdefault/linux/m68k/17.0 exp
-m68kdefault/linux/m68k/17.0/desktop exp
-m68kdefault/linux/m68k/17.0/desktop/gnome   exp
-m68kdefault/linux/m68k/17.0/developer   exp
+m68kdefault/linux/m68k/13.0 dev
+m68kdefault/linux/m68k/13.0/desktop dev
+m68kdefault/linux/m68k/13.0/desktop/gnome   dev
+m68kdefault/linux/m68k/13.0/developer   dev
+m68kdefault/linux/m68k/17.0 dev
+m68kdefault/linux/m68k/17.0/desktop dev
+m68kdefault/linux/m68k/17.0/desktop/gnome   dev
+m68kdefault/linux/m68k/17.0/developer   dev
 
 # MIPS Profiles
 mipsdefault/linux/mips/13.0/o32 dev
 mipsdefault/linux/mips/13.0/n32 dev
-mipsdefault/linux/mips/13.0/n64 exp
+mipsdefault/linux/mips/13.0/n64 dev
 mipsdefault/linux/mips/13.0/multilib/o32dev
 mipsdefault/linux/mips/13.0/multilib/n32dev
-mipsdefault/linux/mips/13.0/multilib/n64exp
+mipsdefault/linux/mips/13.0/multilib/n64dev
 mipsdefault/linux/mips/13.0/mipsel/o32  dev
 mipsdefault/linux/mips/13.0/mipsel/n32  dev
-mipsdefault/linux/mips/13.0/mipsel/n64  exp
+mipsdefault/linux/mips/13.0/mipsel/n64  dev
 mipsdefault/linux/mips/13.0/mipsel/multilib/o32 dev
 mipsdefault/linux/mips/13.0/mipsel/multilib/n32 dev
-mipsdefault/linux/mips/13.0/mipsel/multilib/n64 exp
+mipsdefault/linux/mips/13.0/mipsel/multilib/n64 dev
 
 # Nios II Profiles
-nios2   default/linux/nios2/13.0exp
-nios2   default/linux/nios2/17.0exp
+nios2   default/linux/nios2/13.0dev
+nios2   default/linux/nios2/17.0dev
 
 # PPC32 Profiles
 ppc default/linux/powerpc/ppc32/13.0   stable
@@ -188,36 +188,36 @@ ppc64 
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian   exp
 ppc64  
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd   exp
 
 # RISC-V Profiles
-riscv   default/linux/riscv/13.0exp
-riscv   

Re: [gentoo-portage-dev] [PATCH 2/2] repoman: Enable testing exp profiles by default

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 21∶45 -0500, użytkownik Mike Gilbert
napisał:
> On Wed, Jan 10, 2018 at 5:56 PM, Zac Medico  wrote:
> > On 01/10/2018 02:24 PM, Michał Górny wrote:
> > > Enable repoman checks on exp profiles by default to improve
> > > the dependency graph integrity on those profiles and help them on their
> > > way towards stable status. This is possible now that the dependency
> > > graph problems are warnings rather than errors.
> > > ---
> > >  repoman/pym/repoman/argparser.py | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/repoman/pym/repoman/argparser.py 
> > > b/repoman/pym/repoman/argparser.py
> > > index f32972288..d49147366 100644
> > > --- a/repoman/pym/repoman/argparser.py
> > > +++ b/repoman/pym/repoman/argparser.py
> > > @@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
> > > 
> > >   parser.add_argument(
> > >   '-e', '--include-exp-profiles', choices=('y', 'n'), 
> > > metavar='',
> > > - default=False,
> > > + default='y',
> > >   help='include exp profiles in dependency checks')
> > > 
> > >   parser.add_argument(
> > > 
> > 
> > We have dev and exp profiles disabled by default because the time
> > consumed by repoman is proportional to the number of profiles.
> > 
> > The current counts are as follows:
> > 
> > stable 87
> > dev 88
> > exp 149
> 
> Yeah, I really don't like the idea of making repoman even slower by default.

The alternative is to go for all profiles being stable. Because
accepting developers randomly breaking profiles 'because repoman speed'
is not acceptable.

> 
> Also, I'm not sure why exp profiles are to be treated as more stable
> than dev profiles. I was always under the impression that the reverse
> was true, though I cannot recall where that assumption was formed.

A lot of people have different impressions, and noone really ever
bothered trying to document what means what. 'exp' is easier to change
because the argument takes y/n, so '-e n' can easily be done by user,
unlike '-d' that is pure boolean flag.

> 
> I would like to see this formally documented somewhere before we start
> changing repoman defaults.

It's part of my proposal for Sunday's Council meeting.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [gentoo-dev-announce] Upcoming posting restrictions on the gentoo-dev mailing list

[Benda Xu]

Hi,

"Andreas K. Huettel"  writes:

> If, as a non-developer, you want to participate in a discussion on 
> gentoo-dev, 
> - either reply directly to the author of a list mail and ask him/her to 
> forward your message,

With this item in mind, shall we set the default "Reply-To:" to the
author instead of the list?

Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[Benda Xu]

Hi MJ,

"M. J. Everitt"  writes:

> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
> different between 2.6.16+ and 2.6.32+ .. should this potentially be
> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
> and more confusing to others

2.6.16+ means that it can be used in any cases when the kernel is newer
than 2.6.16.  For example, you can use it on linux-4.14, just with
unnecessary backward compatibility code.

Besides, with the newest profile, kernel-3.2+, the ending kernel version
is not known.  We will have to rename it when glibc jumps if the profile
is named with a version range.


Hope this addresses your concern.

Cheers,
Benda


signature.asc
Description: PGP signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier JUMEL:
> Le 2018-01-10 10:53, Michał Górny a écrit :
> > Last I checked, Gentoo was a Linux distribution. However, some people
> > prefer to turn it into open discussion forum that has nothing to do
> > with
> > making a distribution.
> 
> No it has. Giving power to a subset of users, denying interaction with
> future contributors unless they enroll is the eaxct way to kill Gentoo
> as a community !

We wouldn't have needed to go this far if not for a few outside trolls who
* keep pushing their personal agenda in endless threads,
* confuse their own inability to contribute with being a mistreated underdog,
* and keep commenting opinionated on technical things they plainly have no 
clue about (while whining when are told they sprout bulls##t).

We do not have a problem with "future contributors". I wager those will rather 
increase in numbers once the list spam is gone.

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

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

> Does being 'struck off' the list in this way apply to devs, including
> Council and comrel members?

So far noone has even considered "striking" devs off the list. If this even 
were to happen ever, it would have to be backed by a full comrel team decision 
/ vote. And these don't happen often, don't happen quickly, and don't happen 
lightly. (I much prefer fixing the glibc ebuilds, horrible as these may be.)

We have now an imperfect solution to an unneccessary problem. If anyone can 
come up with a better solution (that is still an improvement over doing 
nothing), I'm all ears. List moderation is not one, since a) it still hasn't 
been implemented technically, b) even if that were done, we would still 
require an active moderation team, and c) then we start bikeshedding about the 
moderation rules.


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

signature.asc
Description: This is a digitally signed message part.

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

[Aaron W. Swenson]

On 2018-01-10 22:53, Ciaran McCreesh wrote:
> On Wed, 10 Jan 2018 17:48:32 -0500
> "Aaron W. Swenson"  wrote:
> > Modified a bit. This should show for anyone who has GnuCash installed.
> 
> For anyone who has any version of GnuCash installed, either now or at
> any point in the future. (See the recent thread on expiring news
> items...) Are you sure you don't just want to target this at people who
> have the old version installed, instead?

As mentioned, the concern is that someone will try to use a new version
and old version simultaneously.

How about “

signature.asc
Description: Digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:35, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 6:27 PM, M. J. Everitt  wrote:
>
>> I think Roy's point is quite valid .. if you want to cut out users from
>> contribution why are you even posting on -dev ML in the first place?
> Probably because we don't want to cut out users from contribution.
>
I think the proverb "don't throw the baby out with the bathwater"
probably applies here ...

[With apologies for all the proverbs and metaphors lately!]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Rich Freeman]

On Wed, Jan 10, 2018 at 6:27 PM, M. J. Everitt  wrote:
> On 10/01/18 23:20, Rich Freeman wrote:
>> On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford  wrote:
>>> Being somwhat old and cynical, I'm seeing signs of history
>>> repeating itself.
>>>
>>> Does being 'struck off' the list in this way apply to devs, including
>>> Council and comrel members?
>>>
>> It would seem that this question is already answered:
>> https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct#Consequences
>>
>> Being banned from lists or removal of dev status (which would also
>> remove posting privs unless whitelisted) are already listed as
>> potential consequences for refusal to comply with the CoC.
>>
> I have to ask a stupid question here .. how do devs apply to return to
> the list? Via other devs, council, Comrel, the Foundation, Infra, or
> what? (the "select few"/clique/club/etc?)

Go figure, the answer was linked from the previously posted URL:

https://wiki.gentoo.org/wiki/Project:ComRel#The_Policy_for_Resolution_of_Conflicts

> I think Roy's point is quite valid .. if you want to cut out users from
> contribution why are you even posting on -dev ML in the first place?

Probably because we don't want to cut out users from contribution.

-- 
Rich

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[Michael Orlitzky]

On 01/10/2018 05:18 PM, James Le Cuirot wrote:
> 
> The init script used to call chown/chmod -R, which is
> obviously bad. I've compromised by only calling these on the
> directories themselves (ignoring symlinks). I believe this is safe
> because it's not possible to create hard linked directories these days?
> Would you agree?

Are you still using chown and chmod? If so, you should switch to
checkpath -- chown and chmod don't even try to avoid hard links. I would
be surprised to see a "chown" or "chmod" in an init script that can't be
replaced by something better.

The race condition that we're talking about here is trying to squeeze
the last 1% of security out of checkpath; it's already much safer than
chown/chmod.

For example, if your script is calling chown and chmod on two
directories /foo and /foo/bar, then whoever owns /foo can kill /foo/bar
entirely and replace it with a hard link to /etc/passwd. When the
service restarts, chown and chmod won't care that you think /foo/bar
should be a directory instead.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:20, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford  wrote:
>> Being somwhat old and cynical, I'm seeing signs of history
>> repeating itself.
>>
>> Does being 'struck off' the list in this way apply to devs, including
>> Council and comrel members?
>>
> It would seem that this question is already answered:
> https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct#Consequences
>
> Being banned from lists or removal of dev status (which would also
> remove posting privs unless whitelisted) are already listed as
> potential consequences for refusal to comply with the CoC.
>
I have to ask a stupid question here .. how do devs apply to return to
the list? Via other devs, council, Comrel, the Foundation, Infra, or
what? (the "select few"/clique/club/etc?)

I think Roy's point is quite valid .. if you want to cut out users from
contribution why are you even posting on -dev ML in the first place? Use
-core and/or #-dev IRC .. or is this simply an attempt to replicate
#-dev IRC as a ML .. and you simply move the "problem" elsewhere .. and
then apply sanctions to that system also .. you create a rod for your
own back ...

I'm tending towards the idea that this is a technical "solution" to a
non-technical problem, and as such, nobody is capable of "fixing" that ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Rich Freeman]

On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford  wrote:
>
> Being somwhat old and cynical, I'm seeing signs of history
> repeating itself.
>
> Does being 'struck off' the list in this way apply to devs, including
> Council and comrel members?
>

It would seem that this question is already answered:
https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct#Consequences

Being banned from lists or removal of dev status (which would also
remove posting privs unless whitelisted) are already listed as
potential consequences for refusal to comply with the CoC.

-- 
Rich

Re: [gentoo-portage-dev] [PATCH 2/2] repoman: Enable testing exp profiles by default

[Zac Medico]

On 01/10/2018 02:24 PM, Michał Górny wrote:
> Enable repoman checks on exp profiles by default to improve
> the dependency graph integrity on those profiles and help them on their
> way towards stable status. This is possible now that the dependency
> graph problems are warnings rather than errors.
> ---
>  repoman/pym/repoman/argparser.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/repoman/pym/repoman/argparser.py 
> b/repoman/pym/repoman/argparser.py
> index f32972288..d49147366 100644
> --- a/repoman/pym/repoman/argparser.py
> +++ b/repoman/pym/repoman/argparser.py
> @@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
>  
>   parser.add_argument(
>   '-e', '--include-exp-profiles', choices=('y', 'n'), 
> metavar='',
> - default=False,
> + default='y',
>   help='include exp profiles in dependency checks')
>  
>   parser.add_argument(
> 

We have dev and exp profiles disabled by default because the time
consumed by repoman is proportional to the number of profiles.

The current counts are as follows:

stable 87
dev 88
exp 149
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

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

[Ciaran McCreesh]

On Wed, 10 Jan 2018 17:48:32 -0500
"Aaron W. Swenson"  wrote:
> Modified a bit. This should show for anyone who has GnuCash installed.

For anyone who has any version of GnuCash installed, either now or at
any point in the future. (See the recent thread on expiring news
items...) Are you sure you don't just want to target this at people who
have the old version installed, instead?

-- 
Ciaran McCreesh

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

[Aaron W. Swenson]

Modified a bit. This should show for anyone who has GnuCash installed.

The 2.7.3 ebuild I have in my overlay does have a postinst note about
this as well, but I think this is important enough to tell them as soon
as possible and on systems that may never have had GnuCash installed but
will be working with files/databases that are made by GnuCash 2.6.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson 
Posted: 2018-01-10
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-office/gnucash

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files. GnuCash
will automatically modify the file or database in place upon open.

Therefore, it is imperative that you back up any files or databases
before using GnuCash 2.7 in case you run into an issue and want or need
to revert back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
$ cp /path/to/gnucash/sqlite.file.gnucash 
/path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson 
Posted: 2018-01-10
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-office/gnucash

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files. GnuCash
will automatically modify the file or database in place upon open.

Therefore, it is imperative that you back up any files or databases
before using GnuCash 2.7 in case you run into an issue and want or need
to revert back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
$ cp /path/to/gnucash/sqlite.file.gnucash 
/path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature

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

[Aaron W. Swenson]

On 2018-01-10 19:33, Kristian Fiskerstrand wrote:
> On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > It is imperative that you back up any files or databases that GnuCash
> > uses in case you run into an issue with 2.7+ and want or need to revert
> > back to 2.6.
> 
> This seems to imply that upgrading from 2.6 to 2.7+ does not require any
> changes / auto-upgrades schema, maybe it should be stated explicitly
> early on?

Good point. Added explicit statement.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Roy Bamford]

On 2018.01.09 21:20, Andreas K. Huettel wrote:

[snip]
> * Obviously, repeated off-topic posting as well as behaviour against
> the
>   Code of Conduct [2] will lead to revocation of the posting
> permission.
> 

[snip]

> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)

Andreas,

Being somwhat old and cynical, I'm seeing signs of history 
repeating itself.

Does being 'struck off' the list in this way apply to devs, including 
Council and comrel members? 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpeMAJ1kh9Zo.pgp
Description: PGP signature

[gentoo-portage-dev] [PATCH 2/2] repoman: Enable testing exp profiles by default

[Michał Górny]

Enable repoman checks on exp profiles by default to improve
the dependency graph integrity on those profiles and help them on their
way towards stable status. This is possible now that the dependency
graph problems are warnings rather than errors.
---
 repoman/pym/repoman/argparser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/repoman/pym/repoman/argparser.py b/repoman/pym/repoman/argparser.py
index f32972288..d49147366 100644
--- a/repoman/pym/repoman/argparser.py
+++ b/repoman/pym/repoman/argparser.py
@@ -167,7 +167,7 @@ def parse_args(argv, qahelp, repoman_default_opts):
 
parser.add_argument(
'-e', '--include-exp-profiles', choices=('y', 'n'), 
metavar='',
-   default=False,
+   default='y',
help='include exp profiles in dependency checks')
 
parser.add_argument(
-- 
2.16.0.rc1

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[James Le Cuirot]

On Tue, 9 Jan 2018 18:07:41 -0600
William Hubbs  wrote:

> All,
> 
> please take a look at the following issue.
> 
> https://github.com/openrc/openrc/issues/195
> 
> The first part of the fix is committed to master as shown on the issue;
> checkpath should *never* follow symbolic links when changing ownership,
> so I have moved to the lchown call instead of chown.
> 
> However, I'm not sure how to deal with the hard link issue in a way that
> will not break service scripts.
> 
> If anyone has any suggestions for this, let me know.

I faced the hard link problem in another package (bug still restricted)
recently. I'm about to push the fix out but I just want check what I've
done is okay. The init script used to call chown/chmod -R, which is
obviously bad. I've compromised by only calling these on the
directories themselves (ignoring symlinks). I believe this is safe
because it's not possible to create hard linked directories these days?
Would you agree?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgptjfZgxZGvt.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 15∶39 -0500, użytkownik Michael
Orlitzky napisał:
> On 01/10/2018 03:13 PM, Michał Górny wrote:
> > Remove empty directories in install-qa-check phase in order to prevent
> > Portage from installing them, and therefore from developers relying
> > on them being installed.
> 
> This is going to break a lot of packages whose build systems create e.g.
> /var/lib/foo and do nothing with it immediately. The ebuild should be
> calling keepdir on those paths, but how would anyone know that?
> 

I personally think it'd be best to return to having a stable and testing
branch of Portage, with the latter targeted at developers who are
supposed to test for this kind of breakage and fix it, and the former
keeping the safe behavior longer for end users.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[William Hubbs]

On Wed, Jan 10, 2018 at 03:25:55PM -0500, Michael Orlitzky wrote:
> On 01/10/2018 01:04 PM, William Hubbs wrote:
> > On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:
> > 
> >> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
> >> that is not writable only by yourself and root.
> > 
> > Let me try to phrase this another way.
> > 
> > If the directory we are in is not owned by us or root and is group or
> > world writable, checkpath should not change the ownership or permissions
> > of the file passed to it.
> 
> There are also POSIX ACLs, NFSv4 ACLs, and god-knows-what-else to worry
> about, but the above is a good start.
> 
> 
> >> Here's a very tedious proposal for OpenRC: ...
> >>
> >>   2. Have newpath throw a warning if it's used in a directory that is
> >>  writable by someone other than root and the OpenRC user. This will
> >>  prevent people from creating /foo/bar after /foo has already been
> >>  created with owner "foo:foo". In other words, service script
> >>  writers will be encouraged to do things in a safe order. Since
> >>  we're starting over, this might even be made an error.
> > 
> > I'm not really a fan of creating a new helper unless I have to; I would
> > rather modify checkpath's behaviour.
> > 
> > The first stage of that modification would be to release a version that
> > outputs error messages, then convert the error messages to hard failures
> > in a later release.
> > 
> > Is this reasonable? If we go this route, what should checkpath start
> > complaining about?
> 
> /*
>  Disclaimer: I'm not even sure that this difficult proposal will solve
>  the problem. Moreover there may be legitimate things going on in some
>  init scripts that I haven't accounted for.
> */
> 
> The downside to keeping the name "checkpath" is that it makes it
> difficult to identify unfixed scripts. If we change the name, then "grep
> -rl checkpath" points them out for you; but if checkpath is modified,
> you have to install the package and attempt to start/stop/save/reload it
> and look for warnings.

Good point, this may be a good reason to make a new helper and deprecate
checkpath. What I would do is make checkpath throw an error but keep
running,. It would have a message, something like:

"Checkpath is deprecated, please use newpath instead."

What are we saying newpath should do differently than checkpath if I
go this route?

William


signature.asc
Description: Digital signature

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

[Aaron W. Swenson]

On 2018-01-10 19:07, Ciaran McCreesh wrote:
> On Wed, 10 Jan 2018 19:35:52 +0100
> Kristian Fiskerstrand  wrote:
> > On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > > Display-If-Installed: >=app-office/gnucash-2.7.0  
> > 
> > And we might want to display it before users actually upgrades if it
> > is for backing up an auto migrated change?
> 
> Yes, this header is backwards. It's a message to be displayed to users
> who have the old version, not a message to be displayed to users who
> install the new version for the first time ever and who have never used
> the old version.

Perhaps the version restriction should be removed.

People could install GnuCash for the first time ever, then use it to
open files previously handled by 2.6.

If we’re not terribly concerned about that, I can flip the comparison.


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Zac Medico]

On 01/10/2018 01:15 PM, Michael Orlitzky wrote:
> On 01/10/2018 03:55 PM, Zac Medico wrote:
>>>
>>> This is going to break a lot of packages whose build systems create e.g.
>>> /var/lib/foo and do nothing with it immediately. The ebuild should be
>>> calling keepdir on those paths, but how would anyone know that?
>>
>> If we consider that portage already removes these directories if they
>> are still empty when the package is re-merged or upgraded, then maybe
>> the risk is low enough?
>>
> 
> Does it? (Are we talking about the same thing?)
> 
> For example, the nagios-core build system creates a bunch of empty
> directories under /var/nagios:
> 
>   $ find /var/nagios
>   /var/nagios
>   /var/nagios/rw
>   /var/nagios/home
>   /var/nagios/spool
>   /var/nagios/spool/checkresults
>   /var/nagios/archives
> 
> Re-emerging the same version of nagios-core doesn't kill them off.

Oh, you're right, I was mistaken. It's possible that the behavior
changed at some point, but currently it protects directories installed
by the new instance, as shown here:

--- replaced dir /var/nagios/spool/checkresults
--- replaced dir /var/nagios/spool
--- replaced dir /var/nagios/rw
--- replaced dir /var/nagios/archives
--- replaced dir /var/nagios
-- 
Thanks,
Zac

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

[Aaron W. Swenson]

On 2018-01-10 22:38, Peter Volkov wrote:
> On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson 
> 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.

GnuCash 2.6 relies on net-libs/webkit-gtk:2 which will be removed from
the tree soon. If GnuCash doesn’t make the jump to 2.7, then it’ll be
removed from the tree as well. [1]

We’re going to try to introduce it a bit sooner.

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


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Michael Orlitzky]

On 01/10/2018 03:55 PM, Zac Medico wrote:
>>
>> This is going to break a lot of packages whose build systems create e.g.
>> /var/lib/foo and do nothing with it immediately. The ebuild should be
>> calling keepdir on those paths, but how would anyone know that?
> 
> If we consider that portage already removes these directories if they
> are still empty when the package is re-merged or upgraded, then maybe
> the risk is low enough?
> 

Does it? (Are we talking about the same thing?)

For example, the nagios-core build system creates a bunch of empty
directories under /var/nagios:

  $ find /var/nagios
  /var/nagios
  /var/nagios/rw
  /var/nagios/home
  /var/nagios/spool
  /var/nagios/spool/checkresults
  /var/nagios/archives

Re-emerging the same version of nagios-core doesn't kill them off.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Alec Warner]

On Wed, Jan 10, 2018 at 3:48 PM, M. J. Everitt  wrote:

> On 10/01/18 19:31, Alec Warner wrote:
>
> On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  wrote:
>
>> W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
>> napisał:
>> > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny 
>> wrote:
>> > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
>> > > napisał:
>> > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel <
>> dilfri...@gentoo.org> wrote:
>> > > > > During the last Gentoo council meeting, the decision was made to
>> implement
>> > > > > changes to the gentoo-dev mailing list [1].
>> > > > >
>> > > > > These changes affect only the gentoo-dev mailing list, and will
>> come into
>> > > > > effect on 23 January 2018.
>> > > > >
>> > > > > * Subscribing to the list and receiving list mail remains as it
>> is now.
>> > > > > * Posting to the list will only be possible to Gentoo developers
>> and
>> > > > >   whitelisted additional participants.
>> > > > > * Whitelisting requires that one developer vouches for you. We
>> intend this
>> > > > >   to be as unbureaucratic as possible.
>> > > > > * Obviously, repeated off-topic posting as well as behaviour
>> against the
>> > > > >   Code of Conduct [2] will lead to revocation of the posting
>> permission.
>> > > > >
>> > > > > If, as a non-developer, you want to participate in a discussion on
>> > > > > gentoo-dev,
>> > > > > - either reply directly to the author of a list mail and ask
>> him/her to
>> > > > > forward your message,
>> > > > > - or ask any Gentoo developer of your choice to get you
>> whitelisted.
>> > > > >
>> > > > > If, as a developer, you want to have someone whitelisted, please
>> comment on
>> > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you
>> are vouching
>> > > > > for a contributor you are expected to keep an eye on their
>> activity.
>> > > >
>> > > > It seems like the obvious way this fails is some Gentoo developer
>> acks
>> > > > one of the problem people. I don't think that's particularly
>> unlikely.
>> > > > Then what do we do?
>> > > >
>> > >
>> > > Then it becomes comrel business.
>> >
>> > If that was an effective solution, wouldn't the problem already be
>> solved?
>>
>> One of the problems mentioned before was that a person could easily
>> evade the ban via subscribing from another e-mail address. In this case
>> it's no longer possible, as he would need to obtain the vouching for his
>> new e-mail address, and for that he would first have to have something
>> positive to post.
>>
>> Of course this relies on developers not vouching for new people out of
>> the blue but expecting them to have something to contribute first.
>>
>
> This sounds like an amazing fundraising opportunity.
>
> https://www.gentoo.org/donate/
>
> Get membership posting privs.
>
> -A
>
>
>>
>> --
>> Best regards,
>> Michał Górny
>>
>>
>>
> Do I read a hint of sarcasm there too Alec?! :]
>

As I (attempted badly) to explain on IRC; I don't like this decision. But
ultimately the project elects the council to do stuff like this.
As engineers I think we remain bad at making decisions that are imperfect,
or based on incomplete information. I don't
fault the council for taking action (even action I don't like) because I
believe they felt something had to be done to improve the lists.

No one should be afraid to try something because it might not work; trying
things are how we learn.

-A

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Zac Medico]

On 01/10/2018 12:39 PM, Michael Orlitzky wrote:
> On 01/10/2018 03:13 PM, Michał Górny wrote:
>> Remove empty directories in install-qa-check phase in order to prevent
>> Portage from installing them, and therefore from developers relying
>> on them being installed.
> 
> This is going to break a lot of packages whose build systems create e.g.
> /var/lib/foo and do nothing with it immediately. The ebuild should be
> calling keepdir on those paths, but how would anyone know that?

If we consider that portage already removes these directories if they
are still empty when the package is re-merged or upgraded, then maybe
the risk is low enough?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 19:31, Alec Warner wrote:
> On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  > wrote:
>
> W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
> napisał:
> > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  > wrote:
> > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt
> Turner
> > > napisał:
> > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel
> > wrote:
> > > > > During the last Gentoo council meeting, the decision was
> made to implement
> > > > > changes to the gentoo-dev mailing list [1].
> > > > >
> > > > > These changes affect only the gentoo-dev mailing list, and
> will come into
> > > > > effect on 23 January 2018.
> > > > >
> > > > > * Subscribing to the list and receiving list mail remains
> as it is now.
> > > > > * Posting to the list will only be possible to Gentoo
> developers and
> > > > >   whitelisted additional participants.
> > > > > * Whitelisting requires that one developer vouches for
> you. We intend this
> > > > >   to be as unbureaucratic as possible.
> > > > > * Obviously, repeated off-topic posting as well as
> behaviour against the
> > > > >   Code of Conduct [2] will lead to revocation of the
> posting permission.
> > > > >
> > > > > If, as a non-developer, you want to participate in a
> discussion on
> > > > > gentoo-dev,
> > > > > - either reply directly to the author of a list mail and
> ask him/her to
> > > > > forward your message,
> > > > > - or ask any Gentoo developer of your choice to get you
> whitelisted.
> > > > >
> > > > > If, as a developer, you want to have someone whitelisted,
> please comment on
> > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission,
> if you are vouching
> > > > > for a contributor you are expected to keep an eye on their
> activity.
> > > >
> > > > It seems like the obvious way this fails is some Gentoo
> developer acks
> > > > one of the problem people. I don't think that's particularly
> unlikely.
> > > > Then what do we do?
> > > >
> > >
> > > Then it becomes comrel business.
> >
> > If that was an effective solution, wouldn't the problem already
> be solved?
>
> One of the problems mentioned before was that a person could easily
> evade the ban via subscribing from another e-mail address. In this
> case
> it's no longer possible, as he would need to obtain the vouching
> for his
> new e-mail address, and for that he would first have to have something
> positive to post.
>
> Of course this relies on developers not vouching for new people out of
> the blue but expecting them to have something to contribute first.
>
>
> This sounds like an amazing fundraising opportunity.
>
> https://www.gentoo.org/donate/
>
> Get membership posting privs.
>
> -A
>  
>
>
> --
> Best regards,
> Michał Górny
>
>
>
Do I read a hint of sarcasm there too Alec?! :]


signature.asc
Description: OpenPGP digital signature

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

[Mart Raudsepp]

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.

Regarding the Display-If-Installed, it should indeed be shown before
upgrade, in my opinion; otherwise so easy to already get things
migrated to new format before any backups are made. Then again, as 2.6
will go away soon anyway, the usefulness of these backups is limited,
without some local overlay. I didn't quite understand Ciaran mail; if
the header actually means "display when an upgrade to 2.7 is possible",
then that's best.

Regarding elog vs news, please keep in mind that this is limited to
ONLY those that have gnucash installed, so this isn't one of these
"will be shown forever in 5 years for fresh stage3 install starts". We
should be able to use per-package news items much more freely for leaf
packages.


Mart

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Michael Orlitzky]

On 01/10/2018 03:13 PM, Michał Górny wrote:
> Remove empty directories in install-qa-check phase in order to prevent
> Portage from installing them, and therefore from developers relying
> on them being installed.

This is going to break a lot of packages whose build systems create e.g.
/var/lib/foo and do nothing with it immediately. The ebuild should be
calling keepdir on those paths, but how would anyone know that?

Re: [gentoo-portage-dev] [PATCH] install-qa-check: Do not install empty directories

[Zac Medico]

On 01/10/2018 12:13 PM, Michał Górny wrote:
> W dniu śro, 10.01.2018 o godzinie 11∶55 -0500, użytkownik Alec Warner
> napisał:
>> Please link to documentation on keepdir (e.g.
>> https://devmanual.gentoo.org/function-reference/install-functions/index.html)
>> in the helper?
>>
>> I'm not sure there is better keepdir document?
> 
> Done.
> 
>>
>> Also looking at https://devmanual.gentoo.org/eclass-reference/ebuild/
>>
>> It says "keepdir functions the same as dodir" but this has not been true
>> for a while?
> 
> No clue where that comes from. I suppose it's some Portage manpage?

Yes, it's copied directly from the ebuild.5 man page. I think the
intended meaning is essentially that it "runs dodir for you".
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] dep_zapdeps: install new package, allow upgrade (bug 643974)

[Zac Medico]

On 01/10/2018 09:00 AM, Alec Warner wrote:
> The code lgtm.

Thanks!

> Slightly unsure if we need an entirely new test, as opposed to just
> generalizing the test cases (like you did the code). But either way is
> probably fine.

Well, it seems like the only benefit of combining the tests together
would be to share the 'ebuilds' variable. All of the same cases that
I've covered would still need to be covered separately.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] install-qa-check: Do not install empty directories

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 11∶55 -0500, użytkownik Alec Warner
napisał:
> Please link to documentation on keepdir (e.g.
> https://devmanual.gentoo.org/function-reference/install-functions/index.html)
> in the helper?
> 
> I'm not sure there is better keepdir document?

Done.

> 
> Also looking at https://devmanual.gentoo.org/eclass-reference/ebuild/
> 
> It says "keepdir functions the same as dodir" but this has not been true
> for a while?

No clue where that comes from. I suppose it's some Portage manpage?

> 
> -A
> 
> 
> 
> On Wed, Jan 10, 2018 at 11:48 AM, Michał Górny  wrote:
> 
> > Remove empty directories in install-qa-check phase in order to prevent
> > Portage from installing them, and therefore from developers relying
> > on them being installed.
> > 
> > The PMS specifies the behavior upon merging empty directories
> > as undefined, and specifically prohibits ebuilds from attempting
> > to install empty directories. However, ebuilds occasionally still fall
> > into the trap of relying on 'dodir' preserving the directory. Make
> > the Portage behavior more strict in order to prevent that.
> > 
> > Use 'install-qa-check.d' machinery for this as this provides an easy way
> > for users to restore the old behavior (by overriding the check) if they
> > need it for their private ebuilds. It also makes it possible to extend
> > the check with some QA warnings, if we figure out how to do them.
> > 
> > Currently no QA warnings are emitted as we do not want to pursue
> > upstream build systems that create empty directories but the packages
> > themselves do not rely on them being installed, e.g. when some files
> > are installed into the directory conditionally.
> > ---
> >  bin/install-qa-check.d/95empty-dirs | 21 +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 bin/install-qa-check.d/95empty-dirs
> > 
> > diff --git a/bin/install-qa-check.d/95empty-dirs b/bin/install-qa-check.d/
> > 95empty-dirs
> > new file mode 100644
> > index 0..6b8790f59
> > --- /dev/null
> > +++ b/bin/install-qa-check.d/95empty-dirs
> > @@ -0,0 +1,21 @@
> > +# Remove empty directories installed by ebuild.
> > +
> > +# Rationale: PMS prohibits ebuilds from installing empty directories.
> > +# Cleaning them up from the installation image provides an easy way
> > +# to make sure that ebuilds are not relying on it while making it easy
> > +# for users to override this if they need to.
> > +#
> > +# Technically, we could emit QA warnings here. However, we do not want
> > +# to pursue every upstream build system that creates a directory
> > +# and does not install any file into it (think of files installed
> > +# conditionally), as long as the package functions correctly without
> > +# the directory being actually installed.
> > +
> > +strip_empty_dirs() {
> > +   find "${ED}" -mindepth 1 -type d -empty -delete
> > +}
> > +
> > +strip_empty_dirs
> > +: # guarantee successful exit
> > +
> > +# vim:ft=sh
> > --
> > 2.16.0.rc1
> > 
> > 
> > 

-- 
Best regards,
Michał Górny

[gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

[Michał Górny]

Remove empty directories in install-qa-check phase in order to prevent
Portage from installing them, and therefore from developers relying
on them being installed.

The PMS specifies the behavior upon merging empty directories
as undefined, and specifically prohibits ebuilds from attempting
to install empty directories. However, ebuilds occasionally still fall
into the trap of relying on 'dodir' preserving the directory. Make
the Portage behavior more strict in order to prevent that.

Use 'install-qa-check.d' machinery for this as this provides an easy way
for users to restore the old behavior (by overriding the check) if they
need it for their private ebuilds. It also makes it possible to extend
the check with some QA warnings, if we figure out how to do them.

Currently no QA warnings are emitted as we do not want to pursue
upstream build systems that create empty directories but the packages
themselves do not rely on them being installed, e.g. when some files
are installed into the directory conditionally.
---
 bin/install-qa-check.d/95empty-dirs | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 bin/install-qa-check.d/95empty-dirs

diff --git a/bin/install-qa-check.d/95empty-dirs 
b/bin/install-qa-check.d/95empty-dirs
new file mode 100644
index 0..92f3da86d
--- /dev/null
+++ b/bin/install-qa-check.d/95empty-dirs
@@ -0,0 +1,25 @@
+# Remove empty directories installed by ebuild.
+
+# Rationale: PMS prohibits ebuilds from installing empty directories.
+# Cleaning them up from the installation image provides an easy way
+# to make sure that ebuilds are not relying on it while making it easy
+# for users to override this if they need to.
+#
+# The ebuilds that need to preserve empty directories should use keepdir
+# as documented e.g.:
+# https://devmanual.gentoo.org/function-reference/install-functions/index.html
+#
+# Technically, we could emit QA warnings here. However, we do not want
+# to pursue every upstream build system that creates a directory
+# and does not install any file into it (think of files installed
+# conditionally), as long as the package functions correctly without
+# the directory being actually installed.
+
+strip_empty_dirs() {
+   find "${ED}" -mindepth 1 -type d -empty -delete
+}
+
+strip_empty_dirs
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.16.0.rc1

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Fabian Groffen]

On 09-01-2018 22:20:56 +0100, Andreas K. Huettel wrote:
> If, as a non-developer, you want to participate in a discussion on 
> gentoo-dev, 
> - either reply directly to the author of a list mail and ask him/her to 
> forward your message,
> - or ask any Gentoo developer of your choice to get you whitelisted.
>
> If, as a developer, you want to have someone whitelisted, please comment on
> bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching
> for a contributor you are expected to keep an eye on their activity.

For the record, I do not like this decision.  Not just because it puts a
burden on developers to become comrel agents.  A technical solution like
this, doesn't solve the actual problem.  Unfortunately this solution
destroys much more than it intends to fix, which is a loss for Gentoo.

Since this turns -dev into -core-light, I suggest to anyone who doesn't
like this direction that we move discussions to -project instead.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: PGP signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 14∶31 -0500, użytkownik Alec Warner
napisał:
> On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  wrote:
> 
> > W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
> > napisał:
> > > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  wrote:
> > > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
> > > > napisał:
> > > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel <
> > 
> > dilfri...@gentoo.org> wrote:
> > > > > > During the last Gentoo council meeting, the decision was made to
> > 
> > implement
> > > > > > changes to the gentoo-dev mailing list [1].
> > > > > > 
> > > > > > These changes affect only the gentoo-dev mailing list, and will
> > 
> > come into
> > > > > > effect on 23 January 2018.
> > > > > > 
> > > > > > * Subscribing to the list and receiving list mail remains as it is
> > 
> > now.
> > > > > > * Posting to the list will only be possible to Gentoo developers
> > 
> > and
> > > > > >   whitelisted additional participants.
> > > > > > * Whitelisting requires that one developer vouches for you. We
> > 
> > intend this
> > > > > >   to be as unbureaucratic as possible.
> > > > > > * Obviously, repeated off-topic posting as well as behaviour
> > 
> > against the
> > > > > >   Code of Conduct [2] will lead to revocation of the posting
> > 
> > permission.
> > > > > > 
> > > > > > If, as a non-developer, you want to participate in a discussion on
> > > > > > gentoo-dev,
> > > > > > - either reply directly to the author of a list mail and ask
> > 
> > him/her to
> > > > > > forward your message,
> > > > > > - or ask any Gentoo developer of your choice to get you
> > 
> > whitelisted.
> > > > > > 
> > > > > > If, as a developer, you want to have someone whitelisted, please
> > 
> > comment on
> > > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you
> > 
> > are vouching
> > > > > > for a contributor you are expected to keep an eye on their
> > 
> > activity.
> > > > > 
> > > > > It seems like the obvious way this fails is some Gentoo developer
> > 
> > acks
> > > > > one of the problem people. I don't think that's particularly
> > 
> > unlikely.
> > > > > Then what do we do?
> > > > > 
> > > > 
> > > > Then it becomes comrel business.
> > > 
> > > If that was an effective solution, wouldn't the problem already be
> > 
> > solved?
> > 
> > One of the problems mentioned before was that a person could easily
> > evade the ban via subscribing from another e-mail address. In this case
> > it's no longer possible, as he would need to obtain the vouching for his
> > new e-mail address, and for that he would first have to have something
> > positive to post.
> > 
> > Of course this relies on developers not vouching for new people out of
> > the blue but expecting them to have something to contribute first.
> > 
> 
> This sounds like an amazing fundraising opportunity.
> 
> https://www.gentoo.org/donate/
> 
> Get membership posting privs.
> 

I should point out that even as a joke this is highly inappropriate.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 18∶16 +0100, użytkownik Vincent-Xavier 
JUMEL napisał:
> Le 2018-01-10 10:53, Michał Górny a écrit :
> > Last I checked, Gentoo was a Linux distribution. However, some people
> > prefer to turn it into open discussion forum that has nothing to do 
> > with
> > making a distribution.
> > 
> 
> No it has. Giving power to a subset of users, denying interaction with
> future contributors unless they enroll is the eaxct way to kill Gentoo
> as a community !

Nobody's denying interaction with future contributors. We're just
closing one of discussion forum that doesn't work for us.

> > And if you are curious, then I've been asked by multiple developers
> > (and a few users) requesting the restriction, and I haven't been
> > contacted by a single one who asked otherwise.
> 
> People have voiced against this proposals before. So you want to protect
> some developper instead of getting an open community.

Yes, if I have to choose between:

a. a developer, a person who I know is spending a significant effort
making Gentoo a better distribution, and

b. an 'open community' which focuses around a few vocal users whose only
'contribution' so far were negative and/or insulting mailing list posts
towards Gentoo developers,

then I'm sorry but I'm going to go for protecting the developer. Because
in the end, our users benefit from working distribution more than from
having a discussion forum where they can complain that the distribution
does not work and debate which of the developers they blame for it.

> As I've already said, Gentoo community is taking (and part is because of
> lack of user consideration) a very bad direction.
> 
> I might want to spread the word that Gentoo is not anymore a welcoming
> community for people who want to delve inside GNU/Linux and easily
> understant how is build a complete OS.
> 

Thank you for proving our point.


-- 
Best regards,
Michał Górny

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

[Peter Volkov]

On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson 
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.

--
Peter.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Alec Warner]

On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  wrote:

> W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
> napisał:
> > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  wrote:
> > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
> > > napisał:
> > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel <
> dilfri...@gentoo.org> wrote:
> > > > > During the last Gentoo council meeting, the decision was made to
> implement
> > > > > changes to the gentoo-dev mailing list [1].
> > > > >
> > > > > These changes affect only the gentoo-dev mailing list, and will
> come into
> > > > > effect on 23 January 2018.
> > > > >
> > > > > * Subscribing to the list and receiving list mail remains as it is
> now.
> > > > > * Posting to the list will only be possible to Gentoo developers
> and
> > > > >   whitelisted additional participants.
> > > > > * Whitelisting requires that one developer vouches for you. We
> intend this
> > > > >   to be as unbureaucratic as possible.
> > > > > * Obviously, repeated off-topic posting as well as behaviour
> against the
> > > > >   Code of Conduct [2] will lead to revocation of the posting
> permission.
> > > > >
> > > > > If, as a non-developer, you want to participate in a discussion on
> > > > > gentoo-dev,
> > > > > - either reply directly to the author of a list mail and ask
> him/her to
> > > > > forward your message,
> > > > > - or ask any Gentoo developer of your choice to get you
> whitelisted.
> > > > >
> > > > > If, as a developer, you want to have someone whitelisted, please
> comment on
> > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you
> are vouching
> > > > > for a contributor you are expected to keep an eye on their
> activity.
> > > >
> > > > It seems like the obvious way this fails is some Gentoo developer
> acks
> > > > one of the problem people. I don't think that's particularly
> unlikely.
> > > > Then what do we do?
> > > >
> > >
> > > Then it becomes comrel business.
> >
> > If that was an effective solution, wouldn't the problem already be
> solved?
>
> One of the problems mentioned before was that a person could easily
> evade the ban via subscribing from another e-mail address. In this case
> it's no longer possible, as he would need to obtain the vouching for his
> new e-mail address, and for that he would first have to have something
> positive to post.
>
> Of course this relies on developers not vouching for new people out of
> the blue but expecting them to have something to contribute first.
>

This sounds like an amazing fundraising opportunity.

https://www.gentoo.org/donate/

Get membership posting privs.

-A


>
> --
> Best regards,
> Michał Górny
>
>
>

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

[Ciaran McCreesh]

On Wed, 10 Jan 2018 19:35:52 +0100
Kristian Fiskerstrand  wrote:
> On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> > Display-If-Installed: >=app-office/gnucash-2.7.0  
> 
> And we might want to display it before users actually upgrades if it
> is for backing up an auto migrated change?

Yes, this header is backwards. It's a message to be displayed to users
who have the old version, not a message to be displayed to users who
install the new version for the first time ever and who have never used
the old version.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
napisał:
> On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  wrote:
> > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
> > napisał:
> > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel  
> > > wrote:
> > > > During the last Gentoo council meeting, the decision was made to 
> > > > implement
> > > > changes to the gentoo-dev mailing list [1].
> > > > 
> > > > These changes affect only the gentoo-dev mailing list, and will come 
> > > > into
> > > > effect on 23 January 2018.
> > > > 
> > > > * Subscribing to the list and receiving list mail remains as it is now.
> > > > * Posting to the list will only be possible to Gentoo developers and
> > > >   whitelisted additional participants.
> > > > * Whitelisting requires that one developer vouches for you. We intend 
> > > > this
> > > >   to be as unbureaucratic as possible.
> > > > * Obviously, repeated off-topic posting as well as behaviour against the
> > > >   Code of Conduct [2] will lead to revocation of the posting permission.
> > > > 
> > > > If, as a non-developer, you want to participate in a discussion on
> > > > gentoo-dev,
> > > > - either reply directly to the author of a list mail and ask him/her to
> > > > forward your message,
> > > > - or ask any Gentoo developer of your choice to get you whitelisted.
> > > > 
> > > > If, as a developer, you want to have someone whitelisted, please 
> > > > comment on
> > > > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are 
> > > > vouching
> > > > for a contributor you are expected to keep an eye on their activity.
> > > 
> > > It seems like the obvious way this fails is some Gentoo developer acks
> > > one of the problem people. I don't think that's particularly unlikely.
> > > Then what do we do?
> > > 
> > 
> > Then it becomes comrel business.
> 
> If that was an effective solution, wouldn't the problem already be solved?

One of the problems mentioned before was that a person could easily
evade the ban via subscribing from another e-mail address. In this case
it's no longer possible, as he would need to obtain the vouching for his
new e-mail address, and for that he would first have to have something
positive to post.

Of course this relies on developers not vouching for new people out of
the blue but expecting them to have something to contribute first.

-- 
Best regards,
Michał Górny

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

[Kristian Fiskerstrand]

On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> Display-If-Installed: >=app-office/gnucash-2.7.0

And we might want to display it before users actually upgrades if it is
for backing up an auto migrated change?

Since it doesn't require user changes I'm not entirely sure news item is
correct approach, seems like an elog could satisfy this

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

[Kristian Fiskerstrand]

On 01/10/2018 07:31 PM, Aaron W. Swenson wrote:
> It is imperative that you back up any files or databases that GnuCash
> uses in case you run into an issue with 2.7+ and want or need to revert
> back to 2.6.

This seems to imply that upgrading from 2.6 to 2.7+ does not require any
changes / auto-upgrades schema, maybe it should be stated explicitly
early on?

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

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

[Aaron W. Swenson]

Please review.

Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson 
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=app-office/gnucash-2.7.0

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files.

It is imperative that you back up any files or databases that GnuCash
uses in case you run into an issue with 2.7+ and want or need to revert
back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a
Title: GnuCash 2.7+ Breaking Change
Author: Aaron W. Swenson 
Posted: 2018-01-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: >=app-office/gnucash-2.7.0

Along with changes to updates to use modern libraries, GnuCash 2.7+ has
changed the schema [1] it uses for both databases and files.

It is imperative that you back up any files or databases that GnuCash
uses in case you run into an issue with 2.7+ and want or need to revert
back to 2.6.

Instructions for backing up are as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | mysql gnucash_db_bak

For PostgreSQL:
$ createdb -U dbadmin -T gnucash_db -O gnucash_user gnucash_db_bak

For SQLite:
cp /path/to/gnucash/sqlite.file.gnucash /path/to/gnucash/sqlite.file.gnucash.bak

[1] https://github.com/Gnucash/gnucash/releases/tag/2.7.0a


signature.asc
Description: Digital signature

[gentoo-dev] Last-rites: dev-perl/SVN-Simple

[Kent Fredric]

# Kent Fredric  (10 Jan 2018)
# Dead upstream, Broken since 2009.
# Bug #644146. Removal in 30 days
dev-perl/SVN-Simple


pgp1f0Hmg13QE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[Kristian Fiskerstrand]

On 01/10/2018 02:19 AM, Michael Orlitzky wrote:
> On 01/09/2018 07:07 PM, William Hubbs wrote
>>
>> However, I'm not sure how to deal with the hard link issue in a way that
>> will not break service scripts.
>>
> 
> Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by
> default, but they have the liberty of requiring a relatively new Linux

so does gentoo-sources since discussion in
https://bugs.gentoo.org/540006#c19
> 
> (I didn't realize at the time that the OpenRC fix still contained a race
> condition.)

This was mentioned already in https://bugs.gentoo.org/540006#c15
-- 
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] rfc: ideas for fixing OpenRC checkpath issue

[William Hubbs]

On Tue, Jan 09, 2018 at 08:19:24PM -0500, Michael Orlitzky wrote:

*snip*

> Ultimately, it's not safe to chown/chmod/setfacl/whatever in a directory
> that is not writable only by yourself and root.

Let me try to phrase this another way.

If the directory we are in is not owned by us or root and is group or
world writable, checkpath should not change the ownership or permissions
of the file passed to it.

> Here's a very tedious proposal for OpenRC:
> 
>   1. Create a new helper, called e.g. "newpath", that is like checkpath
>  but only creates things, and doesn't modify them.
> 
>   2. Have newpath throw a warning if it's used in a directory that is
>  writable by someone other than root and the OpenRC user. This will
>  prevent people from creating /foo/bar after /foo has already been
>  created with owner "foo:foo". In other words, service script
>  writers will be encouraged to do things in a safe order. Since
>  we're starting over, this might even be made an error.
> 
>   3. Deprecate checkpath
> 
>   4. Wait a million years for people to switch from checkpath to newpath
> 
>   5. Get rid of checkpath
> 
> I'm not even sure that this solves the problem completely, but it's the
> only idea I've got left.

I'm not really a fan of creating a new helper unless I have to; I would
rather modify checkpath's behaviour.

The first stage of that modification would be to release a version that
outputs error messages, then convert the error messages to hard failures
in a later release.

Is this reasonable? If we go this route, what should checkpath start
complaining about?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Vincent-Xavier JUMEL]

Le 2018-01-10 10:53, Michał Górny a écrit :

Last I checked, Gentoo was a Linux distribution. However, some people
prefer to turn it into open discussion forum that has nothing to do 
with

making a distribution.


No it has. Giving power to a subset of users, denying interaction with
future contributors unless they enroll is the eaxct way to kill Gentoo
as a community !



I guess you should have voiced your opinion back when discussion was
taking place instead of being hostile *now* because the Council 
listened

to what the developers requested.


I've voiced my opinion as a 10 year user. I've never take nor the
quizzes, nor made any move to become a Gentoo Developper beacause of
this kind of closedmind state.


And if you are curious, then I've been asked by multiple developers
(and a few users) requesting the restriction, and I haven't been
contacted by a single one who asked otherwise.

People have voiced against this proposals before. So you want to protect
some developper instead of getting an open community.

As I've already said, Gentoo community is taking (and part is because of
lack of user consideration) a very bad direction.

I might want to spread the word that Gentoo is not anymore a welcoming
community for people who want to delve inside GNU/Linux and easily
understant how is build a complete OS.

Cheers
--
Vincent-Xavier JUMEL GPG Id: 0x14ABB3F2 http://thetys-retz.net

Rejoignez les 5334 adhérents de l'April http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Matt Turner]

On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  wrote:
> W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
> napisał:
>> On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel  
>> wrote:
>> > During the last Gentoo council meeting, the decision was made to implement
>> > changes to the gentoo-dev mailing list [1].
>> >
>> > These changes affect only the gentoo-dev mailing list, and will come into
>> > effect on 23 January 2018.
>> >
>> > * Subscribing to the list and receiving list mail remains as it is now.
>> > * Posting to the list will only be possible to Gentoo developers and
>> >   whitelisted additional participants.
>> > * Whitelisting requires that one developer vouches for you. We intend this
>> >   to be as unbureaucratic as possible.
>> > * Obviously, repeated off-topic posting as well as behaviour against the
>> >   Code of Conduct [2] will lead to revocation of the posting permission.
>> >
>> > If, as a non-developer, you want to participate in a discussion on
>> > gentoo-dev,
>> > - either reply directly to the author of a list mail and ask him/her to
>> > forward your message,
>> > - or ask any Gentoo developer of your choice to get you whitelisted.
>> >
>> > If, as a developer, you want to have someone whitelisted, please comment on
>> > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are 
>> > vouching
>> > for a contributor you are expected to keep an eye on their activity.
>>
>> It seems like the obvious way this fails is some Gentoo developer acks
>> one of the problem people. I don't think that's particularly unlikely.
>> Then what do we do?
>>
>
> Then it becomes comrel business.

If that was an effective solution, wouldn't the problem already be solved?

Re: [gentoo-portage-dev] [PATCH] dep_zapdeps: install new package, allow upgrade (bug 643974)

[Alec Warner]

The code lgtm.

Slightly unsure if we need an entirely new test, as opposed to just
generalizing the test cases (like you did the code). But either way is
probably fine.

-A

On Tue, Jan 9, 2018 at 2:55 PM, Zac Medico  wrote:

> Prefer to install a new package in order to allow upgrade of an
> installed package. This generalizes the code from bug 635540 so
> that it both allows desirable upgrades and prevents unwanted
> downgrades.
>
> Fixes: 7c58e3737616 ("dep_zapdeps: install new package, avoid downgrade
> (bug 635540)")
> Bug: https://bugs.gentoo.org/643974
> ---
>  pym/portage/dep/dep_check.py   | 11 ++-
>  .../tests/resolver/test_or_upgrade_installed.py| 94
> ++
>  2 files changed, 99 insertions(+), 6 deletions(-)
>  create mode 100644 pym/portage/tests/resolver/
> test_or_upgrade_installed.py
>
> diff --git a/pym/portage/dep/dep_check.py b/pym/portage/dep/dep_check.py
> index 2bb9dc339..291626f56 100644
> --- a/pym/portage/dep/dep_check.py
> +++ b/pym/portage/dep/dep_check.py
> @@ -366,10 +366,8 @@ def dep_zapdeps(unreduced, reduced, myroot,
> use_binaries=0, trees=None):
> want_update_pkg = trees[myroot].get("want_update_pkg")
> downgrade_probe = trees[myroot].get("downgrade_probe")
> vardb = None
> -   vardb_match_pkgs = None
> if "vartree" in trees[myroot]:
> vardb = trees[myroot]["vartree"].dbapi
> -   vardb_match_pkgs = getattr(vardb, 'match_pkgs', None)
> if use_binaries:
> mydbapi = trees[myroot]["bintree"].dbapi
> else:
> @@ -465,10 +463,11 @@ def dep_zapdeps(unreduced, reduced, myroot,
> use_binaries=0, trees=None):
> avail_pkg = avail_pkg_use
> avail_slot = Atom("%s:%s" %
> (atom.cp, avail_pkg.slot))
>
> -   if vardb_match_pkgs is not None and
> downgrade_probe is not None:
> -   inst_pkg = vardb_match_pkgs(avail_slot)
> -   if (inst_pkg and avail_pkg < inst_pkg[-1]
> and
> -   not downgrade_probe(inst_pkg[-1]))
> :
> +   if downgrade_probe is not None:
> +   highest_in_slot =
> mydbapi_match_pkgs(avail_slot)
> +   if (avail_pkg and highest_in_slot and
> +   avail_pkg < highest_in_slot[-1] and
> +   not downgrade_probe(avail_pkg)):
> installed_downgrade = True
>
> slot_map[avail_slot] = avail_pkg
> diff --git a/pym/portage/tests/resolver/test_or_upgrade_installed.py
> b/pym/portage/tests/resolver/test_or_upgrade_installed.py
> new file mode 100644
> index 0..70703a614
> --- /dev/null
> +++ b/pym/portage/tests/resolver/test_or_upgrade_installed.py
> @@ -0,0 +1,94 @@
> +# Copyright 2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +from portage.tests import TestCase
> +from portage.tests.resolver.ResolverPlayground import (
> +   ResolverPlayground,
> +   ResolverPlaygroundTestCase,
> +)
> +
> +class OrUpgradeInstalledTestCase(TestCase):
> +
> +   def testOrUpgradeInstalled(self):
> +   ebuilds = {
> +   'net-misc/foo-1': {
> +   'EAPI': '6',
> +   'RDEPEND': '|| ( sys-libs/glibc[rpc(-)]
> net-libs/libtirpc )'
> +   },
> +   'net-libs/libtirpc-1': {
> +   'EAPI': '6',
> +   },
> +   'sys-libs/glibc-2.26': {
> +   'EAPI': '6',
> +   'IUSE': ''
> +   },
> +   'sys-libs/glibc-2.24': {
> +   'EAPI': '6',
> +   'IUSE': '+rpc'
> +   },
> +   }
> +
> +   installed = {
> +   'sys-libs/glibc-2.24': {
> +   'EAPI': '6',
> +   'IUSE': '+rpc',
> +   'USE': 'rpc',
> +   },
> +   }
> +
> +   world = ['sys-libs/glibc']
> +
> +   test_cases = (
> +   # Test bug 643974, where we need to install
> libtirpc
> +   # in order to upgrade glibc.
> +   ResolverPlaygroundTestCase(
> +   ['net-misc/foo', '@world'],
> +   options={'--update': True, '--deep': True},
> +   success=True,
> +   mergelist=['net-libs/libtirpc-1',
> 'sys-libs/glibc-2.26', 'net-misc/foo-1']
> +   

Re: [gentoo-portage-dev] [PATCH] install-qa-check: Do not install empty directories

[Alec Warner]

Please link to documentation on keepdir (e.g.
https://devmanual.gentoo.org/function-reference/install-functions/index.html)
in the helper?

I'm not sure there is better keepdir document?

Also looking at https://devmanual.gentoo.org/eclass-reference/ebuild/

It says "keepdir functions the same as dodir" but this has not been true
for a while?

-A



On Wed, Jan 10, 2018 at 11:48 AM, Michał Górny  wrote:

> Remove empty directories in install-qa-check phase in order to prevent
> Portage from installing them, and therefore from developers relying
> on them being installed.
>
> The PMS specifies the behavior upon merging empty directories
> as undefined, and specifically prohibits ebuilds from attempting
> to install empty directories. However, ebuilds occasionally still fall
> into the trap of relying on 'dodir' preserving the directory. Make
> the Portage behavior more strict in order to prevent that.
>
> Use 'install-qa-check.d' machinery for this as this provides an easy way
> for users to restore the old behavior (by overriding the check) if they
> need it for their private ebuilds. It also makes it possible to extend
> the check with some QA warnings, if we figure out how to do them.
>
> Currently no QA warnings are emitted as we do not want to pursue
> upstream build systems that create empty directories but the packages
> themselves do not rely on them being installed, e.g. when some files
> are installed into the directory conditionally.
> ---
>  bin/install-qa-check.d/95empty-dirs | 21 +
>  1 file changed, 21 insertions(+)
>  create mode 100644 bin/install-qa-check.d/95empty-dirs
>
> diff --git a/bin/install-qa-check.d/95empty-dirs b/bin/install-qa-check.d/
> 95empty-dirs
> new file mode 100644
> index 0..6b8790f59
> --- /dev/null
> +++ b/bin/install-qa-check.d/95empty-dirs
> @@ -0,0 +1,21 @@
> +# Remove empty directories installed by ebuild.
> +
> +# Rationale: PMS prohibits ebuilds from installing empty directories.
> +# Cleaning them up from the installation image provides an easy way
> +# to make sure that ebuilds are not relying on it while making it easy
> +# for users to override this if they need to.
> +#
> +# Technically, we could emit QA warnings here. However, we do not want
> +# to pursue every upstream build system that creates a directory
> +# and does not install any file into it (think of files installed
> +# conditionally), as long as the package functions correctly without
> +# the directory being actually installed.
> +
> +strip_empty_dirs() {
> +   find "${ED}" -mindepth 1 -type d -empty -delete
> +}
> +
> +strip_empty_dirs
> +: # guarantee successful exit
> +
> +# vim:ft=sh
> --
> 2.16.0.rc1
>
>
>

[gentoo-portage-dev] [PATCH] install-qa-check: Do not install empty directories

[Michał Górny]

Remove empty directories in install-qa-check phase in order to prevent
Portage from installing them, and therefore from developers relying
on them being installed.

The PMS specifies the behavior upon merging empty directories
as undefined, and specifically prohibits ebuilds from attempting
to install empty directories. However, ebuilds occasionally still fall
into the trap of relying on 'dodir' preserving the directory. Make
the Portage behavior more strict in order to prevent that.

Use 'install-qa-check.d' machinery for this as this provides an easy way
for users to restore the old behavior (by overriding the check) if they
need it for their private ebuilds. It also makes it possible to extend
the check with some QA warnings, if we figure out how to do them.

Currently no QA warnings are emitted as we do not want to pursue
upstream build systems that create empty directories but the packages
themselves do not rely on them being installed, e.g. when some files
are installed into the directory conditionally.
---
 bin/install-qa-check.d/95empty-dirs | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 bin/install-qa-check.d/95empty-dirs

diff --git a/bin/install-qa-check.d/95empty-dirs 
b/bin/install-qa-check.d/95empty-dirs
new file mode 100644
index 0..6b8790f59
--- /dev/null
+++ b/bin/install-qa-check.d/95empty-dirs
@@ -0,0 +1,21 @@
+# Remove empty directories installed by ebuild.
+
+# Rationale: PMS prohibits ebuilds from installing empty directories.
+# Cleaning them up from the installation image provides an easy way
+# to make sure that ebuilds are not relying on it while making it easy
+# for users to override this if they need to.
+#
+# Technically, we could emit QA warnings here. However, we do not want
+# to pursue every upstream build system that creates a directory
+# and does not install any file into it (think of files installed
+# conditionally), as long as the package functions correctly without
+# the directory being actually installed.
+
+strip_empty_dirs() {
+   find "${ED}" -mindepth 1 -type d -empty -delete
+}
+
+strip_empty_dirs
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.16.0.rc1

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[kuzetsa]

On 01/10/2018 09:55 AM, Alexander Berntsen wrote:
> On 10/01/18 08:55, Lars Wendler wrote:
>> Seems we're turning into an elitist club or something... 
> Gentoo has already had the reputation of being an elitist club for
> years. As such I'd like to see steps to remedy this status, rather than
> taking steps like this, which just exacerbates the unfortunate status.

Definitions matter:

An impressive skillset could be called elite.

One form could be an elected set of people who have
veto power for decisions about the gentoo project.

Another definition could focus on social standing,
influence, the ability to control peers and apply
pressure to defend one's status. This is not often
welcoming to outsiders with differing viewpoints.

Many aspects of gentoo development can be called
elite. The 3rd definition is the one which I'm
least comfortable with. Elaboration follows:

If the merits of organizational and technical goals
are the only definitions used, there is no reason
for the elitism to be feared. Competency is not a
problem.

Perhaps this is a discussion more suited to the
gentoo-project mailing list. It's taking a turn
away from development concerns again. That's part
of the point for this new posting restriction.

On-topic subject matter can be relayed, and/or
persons prone to development concerns are still
able to be whitelisted. I see no problem here.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 14:55, Alexander Berntsen wrote:
> On 10/01/18 08:55, Lars Wendler wrote:
>> Seems we're turning into an elitist club or something... 
> Gentoo has already had the reputation of being an elitist club for
> years. As such I'd like to see steps to remedy this status, rather than
> taking steps like this, which just exacerbates the unfortunate status.
At the risk of earning myself an outright ban may I propose the following:

Perhaps some of the devs still reading this thread, may wish to table a
discussion at the forthcoming Gentoo council meeting, that this subject
is given some discussion by those [supposedly] steering the
distribution. Perhaps some of those elected representatives(!) who could
potentially be considered perpetrators of this problem would then be
tasked with addressing the issue properly, both in their own courts, and
more widely ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Alexander Berntsen]

On 10/01/18 08:55, Lars Wendler wrote:
> Seems we're turning into an elitist club or something... 
Gentoo has already had the reputation of being an elitist club for
years. As such I'd like to see steps to remedy this status, rather than
taking steps like this, which just exacerbates the unfortunate status.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 13:49, kuzetsa wrote:
> On 01/10/2018 05:57 AM, David Seifert wrote:
>> On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote:
>>> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:
>>>
 On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
> * Posting to the list will only be possible to Gentoo developers
> and
>   whitelisted additional participants.  
 This is so contrary to what I and I thought Gentoo stands for:
 openness, transparency, inclusiveness even when these require a
 rather
 thick skin and result in high noise.  It's a price worth paying.

 I guess I should a) pay more attention to council elections b)
 consider
 the idea that the whole council thing as it stands now is just not
 working.

>>> Wow. I couldn't have said it better. 
>>> Seems we're turning into an elitist club or something... 
>>> I wonder how many users we're going to loose on this one. Well done
>>> council :-(
>>>
>> If your only reason to use Gentoo is because you can post to the main
>> developer ML, and not because we try to provide a great distribution
>> with lots of choice, a current toolchain and lots of customization,
>> then you're likely using the wrong distribution.
>>
> If development of a quality distribution which meets
> these goals requires thick skin, something is broken:
>
> I've never seen anything from the gentoo foundation
> which suggests that the gentoo developer mail list
> should be considered a safe space for disparaging
> remarks. Think of the messaging on this - for every
> 1 or 2 people who are willing to come forward to
> address these concerns, there are likely "not zero"
> who didn't want to deal with confrontation and the
> risk that rudeness and hostile behavior would be
> defended.
>
Your argument seems partially contradictory here, and I think the
interpretation may be muddled with language barriers for those
developers/users with English as a foreign language ...

Are you reinforcing the point [widely accepted by many whose heads
aren't in the proverbial sand[0]] that Gentoo is [or is becoming] an
elitist club, or condoning "bad behaviour" by both devs and non-devs on
the mailing lists

Your final point, however, makes a lot of sense .. [1]


[0] - https://www.merriam-webster.com/dictionary/head-in-the-sand
[1] - https://idioms.thefreedictionary.com/keep+head+down



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[M. J. Everitt]

On 10/01/18 14:00, kuzetsa wrote:
> On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>>> Hi kuzetsa,
>>>
>>> kuzetsa  writes:
>>>
 The term "beyond" feels wrong & confusing.
 (Not sure what to replace it with though)
>>> How about this?
>>>
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>>
>>> Yours,
>>> Benda
>> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>>
>> -Aaron
> Yes. Using a plus looks nicer / cleaner to me too.
>
Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
different between 2.6.16+ and 2.6.32+ .. should this potentially be
2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
and more confusing to others

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[kuzetsa]

On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>
> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>> Hi kuzetsa,
>>
>> kuzetsa  writes:
>>
>>> The term "beyond" feels wrong & confusing.
>>> (Not sure what to replace it with though)
>> How about this?
>>
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>
>> Yours,
>> Benda
> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>
> -Aaron

Yes. Using a plus looks nicer / cleaner to me too.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[kuzetsa]

On 01/10/2018 05:57 AM, David Seifert wrote:
> On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote:
>> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:
>>
>>> On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
 * Posting to the list will only be possible to Gentoo developers
 and
   whitelisted additional participants.  
>>> This is so contrary to what I and I thought Gentoo stands for:
>>> openness, transparency, inclusiveness even when these require a
>>> rather
>>> thick skin and result in high noise.  It's a price worth paying.
>>>
>>> I guess I should a) pay more attention to council elections b)
>>> consider
>>> the idea that the whole council thing as it stands now is just not
>>> working.
>>>
>> Wow. I couldn't have said it better. 
>> Seems we're turning into an elitist club or something... 
>> I wonder how many users we're going to loose on this one. Well done
>> council :-(
>>
> If your only reason to use Gentoo is because you can post to the main
> developer ML, and not because we try to provide a great distribution
> with lots of choice, a current toolchain and lots of customization,
> then you're likely using the wrong distribution.
>

If development of a quality distribution which meets
these goals requires thick skin, something is broken:

I've never seen anything from the gentoo foundation
which suggests that the gentoo developer mail list
should be considered a safe space for disparaging
remarks. Think of the messaging on this - for every
1 or 2 people who are willing to come forward to
address these concerns, there are likely "not zero"
who didn't want to deal with confrontation and the
risk that rudeness and hostile behavior would be
defended.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-misc/openssh/

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 13∶26 +, użytkownik Ian Whyman
napisał:
> On Wed, 10 Jan 2018, at 12:52 PM, Michał Górny wrote:
> > W dniu śro, 10.01.2018 o godzinie 08∶35 +, użytkownik Mike Frysinger
> > napisał:
> > > commit: e65003579e31be4ff949cfa66df2511ecd4c44a0
> > > Author: Mike Frysinger  gentoo  org>
> > > AuthorDate: Wed Jan 10 08:28:35 2018 +
> > > Commit: Mike Frysinger  gentoo  org>
> > > CommitDate: Wed Jan 10 08:34:18 2018 +
> > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6500357
> > > 
> > > net-misc/openssh: mark 7.5_p1-r3 m68k/s390/sh stable
> > > 
> > >  net-misc/openssh/openssh-7.5_p1-r3.ebuild | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/net-misc/openssh/openssh-7.5_p1-r3.ebuild 
> > > b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > > index 83dcb1db429..1f173bc6211 100644
> > > --- a/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > > +++ b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > > @@ -25,7 +25,7 @@ 
> > > SRC_URI="mirror://openbsd/OpenSSH/portable/${PARCH}.tar.gz
> > >  
> > >  LICENSE="BSD GPL-2"
> > >  SLOT="0"
> > > -KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 
> > > ~sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd 
> > > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos 
> > > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> > > +KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh 
> > > sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd 
> > > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos 
> > > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> > >  # Probably want to drop ssl defaulting to on in a future version.
> > >  IUSE="abi_mips_n32 audit bindist debug ${HPN_PATCH:++}hpn kerberos 
> > > kernel_linux ldap ldns libedit libressl livecd pam +pie sctp selinux skey 
> > > ssh1 +ssl static test X X509"
> > >  REQUIRED_USE="ldns? ( ssl )
> > > 
> > 
> > This package has unkeyworded arm64 deps, so you've effectively
> > introduced new depgraph breakage here:
> > 
> > https://qa-reports.gentoo.org/output/gentoo-ci/b4c5efa7f/output.html#net-misc/openssh
> > 
> > Please take care to do things properly, and stabilize dependencies
> > *before* adding stable keywords to a package. Using repoman would also
> > be appreciated.
> > 
> > -- 
> > Best regards,
> > Michał Górny
> > 
> 
> As broken as this seems to be, I'm not sure why you chose Mike's commit to 
> reply to here, as clearly he didn't change the ARM64 keywords in this diff...
> 

I'm sorry about that, I've replied to the wrong mail. I've actually
meant to reply to net-libs/libtirpc commit. However, the commiter's
the same and the problem's the same, so I think the mail eventually
serves its purpose.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-misc/openssh/

[Ian Whyman]

On Wed, 10 Jan 2018, at 12:52 PM, Michał Górny wrote:
> W dniu śro, 10.01.2018 o godzinie 08∶35 +, użytkownik Mike Frysinger
> napisał:
> > commit: e65003579e31be4ff949cfa66df2511ecd4c44a0
> > Author: Mike Frysinger  gentoo  org>
> > AuthorDate: Wed Jan 10 08:28:35 2018 +
> > Commit: Mike Frysinger  gentoo  org>
> > CommitDate: Wed Jan 10 08:34:18 2018 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6500357
> > 
> > net-misc/openssh: mark 7.5_p1-r3 m68k/s390/sh stable
> > 
> >  net-misc/openssh/openssh-7.5_p1-r3.ebuild | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net-misc/openssh/openssh-7.5_p1-r3.ebuild 
> > b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > index 83dcb1db429..1f173bc6211 100644
> > --- a/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > +++ b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > @@ -25,7 +25,7 @@ SRC_URI="mirror://openbsd/OpenSSH/portable/${PARCH}.tar.gz
> >  
> >  LICENSE="BSD GPL-2"
> >  SLOT="0"
> > -KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh 
> > sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd 
> > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos 
> > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> > +KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh 
> > sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd 
> > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos 
> > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> >  # Probably want to drop ssl defaulting to on in a future version.
> >  IUSE="abi_mips_n32 audit bindist debug ${HPN_PATCH:++}hpn kerberos 
> > kernel_linux ldap ldns libedit libressl livecd pam +pie sctp selinux skey 
> > ssh1 +ssl static test X X509"
> >  REQUIRED_USE="ldns? ( ssl )
> > 
> 
> This package has unkeyworded arm64 deps, so you've effectively
> introduced new depgraph breakage here:
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/b4c5efa7f/output.html#net-misc/openssh
> 
> Please take care to do things properly, and stabilize dependencies
> *before* adding stable keywords to a package. Using repoman would also
> be appreciated.
> 
> -- 
> Best regards,
> Michał Górny
> 

As broken as this seems to be, I'm not sure why you chose Mike's commit to 
reply to here, as clearly he didn't change the ARM64 keywords in this diff...

Cheers,

Ian

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-misc/openssh/

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 08∶35 +, użytkownik Mike Frysinger
napisał:
> commit: e65003579e31be4ff949cfa66df2511ecd4c44a0
> Author: Mike Frysinger  gentoo  org>
> AuthorDate: Wed Jan 10 08:28:35 2018 +
> Commit: Mike Frysinger  gentoo  org>
> CommitDate: Wed Jan 10 08:34:18 2018 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6500357
> 
> net-misc/openssh: mark 7.5_p1-r3 m68k/s390/sh stable
> 
>  net-misc/openssh/openssh-7.5_p1-r3.ebuild | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net-misc/openssh/openssh-7.5_p1-r3.ebuild 
> b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> index 83dcb1db429..1f173bc6211 100644
> --- a/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> +++ b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> @@ -25,7 +25,7 @@ SRC_URI="mirror://openbsd/OpenSSH/portable/${PARCH}.tar.gz
>  
>  LICENSE="BSD GPL-2"
>  SLOT="0"
> -KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh 
> sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~amd64-linux 
> ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint 
> ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> +KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
> x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~amd64-linux 
> ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint 
> ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
>  # Probably want to drop ssl defaulting to on in a future version.
>  IUSE="abi_mips_n32 audit bindist debug ${HPN_PATCH:++}hpn kerberos 
> kernel_linux ldap ldns libedit libressl livecd pam +pie sctp selinux skey 
> ssh1 +ssl static test X X509"
>  REQUIRED_USE="ldns? ( ssl )
> 

This package has unkeyworded arm64 deps, so you've effectively
introduced new depgraph breakage here:

https://qa-reports.gentoo.org/output/gentoo-ci/b4c5efa7f/output.html#net-misc/openssh

Please take care to do things properly, and stabilize dependencies
*before* adding stable keywords to a package. Using repoman would also
be appreciated.

-- 
Best regards,
Michał Górny

[gentoo-dev] Last rites: dev-libs/libFuzzer

[Michał Górny]

# Michał Górny  (10 Jan 2018)
# The Fuzzer library is now installed as part of core LLVM. That's
# sys-devel/llvm in LLVM 5, and sys-libs/compiler-rt-sanitizers
# in LLVM 6 and newer. The separate ebuild was never approved by LLVM
# maintainers or actually maintained, and is obsolete for a long time.
# Removal in 30 days.
dev-libs/libFuzzer

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Andreas K. Huettel]

Am Mittwoch, 10. Januar 2018, 10:53:39 CET schrieb Michał Górny:
> 
> I guess you should have voiced your opinion back when discussion was
> taking place instead of being hostile *now* because the Council listened
> to what the developers requested.
> 
> And if you are curious, then I've been asked by multiple developers
> (and a few users) requesting the restriction, and I haven't been
> contacted by a single one who asked otherwise.

^ This. Same experience here.

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

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[David Seifert]

On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote:
> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:
> 
> > On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
> > > * Posting to the list will only be possible to Gentoo developers
> > > and
> > >   whitelisted additional participants.  
> > 
> > This is so contrary to what I and I thought Gentoo stands for:
> > openness, transparency, inclusiveness even when these require a
> > rather
> > thick skin and result in high noise.  It's a price worth paying.
> > 
> > I guess I should a) pay more attention to council elections b)
> > consider
> > the idea that the whole council thing as it stands now is just not
> > working.
> > 
> 
> Wow. I couldn't have said it better. 
> Seems we're turning into an elitist club or something... 
> I wonder how many users we're going to loose on this one. Well done
> council :-(
> 

If your only reason to use Gentoo is because you can post to the main
developer ML, and not because we try to provide a great distribution
with lots of choice, a current toolchain and lots of customization,
then you're likely using the wrong distribution.

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Michał Górny]

W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt Turner
napisał:
> On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel  
> wrote:
> > During the last Gentoo council meeting, the decision was made to implement
> > changes to the gentoo-dev mailing list [1].
> > 
> > These changes affect only the gentoo-dev mailing list, and will come into
> > effect on 23 January 2018.
> > 
> > * Subscribing to the list and receiving list mail remains as it is now.
> > * Posting to the list will only be possible to Gentoo developers and
> >   whitelisted additional participants.
> > * Whitelisting requires that one developer vouches for you. We intend this
> >   to be as unbureaucratic as possible.
> > * Obviously, repeated off-topic posting as well as behaviour against the
> >   Code of Conduct [2] will lead to revocation of the posting permission.
> > 
> > If, as a non-developer, you want to participate in a discussion on
> > gentoo-dev,
> > - either reply directly to the author of a list mail and ask him/her to
> > forward your message,
> > - or ask any Gentoo developer of your choice to get you whitelisted.
> > 
> > If, as a developer, you want to have someone whitelisted, please comment on
> > bug 644070 [3]. Similar to Bugzilla editbugs permission, if you are vouching
> > for a contributor you are expected to keep an eye on their activity.
> 
> It seems like the obvious way this fails is some Gentoo developer acks
> one of the problem people. I don't think that's particularly unlikely.
> Then what do we do?
> 

Then it becomes comrel business.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Michał Górny]

W dniu śro, 10.01.2018 o godzinie 08∶48 +0300, użytkownik Eray Aslan
napisał:
> On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
> > * Posting to the list will only be possible to Gentoo developers and
> >   whitelisted additional participants.
> 
> This is so contrary to what I and I thought Gentoo stands for:
> openness, transparency, inclusiveness even when these require a rather
> thick skin and result in high noise.  It's a price worth paying.

Last I checked, Gentoo was a Linux distribution. However, some people
prefer to turn it into open discussion forum that has nothing to do with
making a distribution.

> 
> I guess I should a) pay more attention to council elections b) consider
> the idea that the whole council thing as it stands now is just not
> working.

I guess you should have voiced your opinion back when discussion was
taking place instead of being hostile *now* because the Council listened
to what the developers requested.

And if you are curious, then I've been asked by multiple developers
(and a few users) requesting the restriction, and I haven't been
contacted by a single one who asked otherwise.

-- 
Best regards,
Michał Górny