Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Alfredo Tupone]

On 23:45 Thu 05 Sep , Mike Gilbert wrote:
> On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann  wrote:
> >
> > On 2019-09-05 22:16, Michał Górny wrote:
> > >> But as per the way the dev manual is written, he arguably *is*
> > >> following policy.
> > >>
> > >> Stop taking the line of assuming he's trying to be belligerent.
> > >
> > > He says explicitly that he is against fixing devmanual because he likes
> > > the way he can abuse it right now.
> >
> > You are the only one adding _abuse_ here. Stop that, thanks. When I
> > replied to your mail I was just asking... nothing more. I don't
> > understand why you are reading so much into it.
> 
> The devmanual o clearly indicates that an email to gentoo-dev is
> strongly preferred. I don't see any reason why tupone could not have
> done this.
> 
> You seem to be trying to take this opportunity to prove some loosely
> related point.
> 
> > But yes, I like the current exception for "per-package" eclasses like I
> > am concerned that a review requirement would cause a significant delay:
> >
> > Back to my example, imagine we would move pkg_config to new mysql
> > eclass. If we would bump mysql/percona-server/mariadb package and will
> > receive bug reports later because upstream changed something causing
> > pkg_config to fail we would now have to propose a patch, wait 48
> > hours... i.e. package would be broken for ~72 hours just because of a
> > policy I don't reject in general (yes, I like reviews) but where I think
> > exceptions must be possible.
> 
> This argument is stupid. If you need to push a critical bug fix, then
> do it. Nobody will fault you for it.
> 
> This clearly does not apply to ada.eclass.
> 
I am going just to explain the reason why I did not ask ml about review the 
first time.
1) ada.eclass is copied from python-single-r1 eclass with s/PYTHON/ADA/ and 
removing pieces that I don't need
2) The eclass is only for packages that I mantains exclusively and they are not 
such a great number

The eclass is an effort to avoid in the future the same problems raised from 
qa-check
All comes from a suggestion to use USE_EXPAND for gnat_2016 gnat_2017 ...

My opinion is that the ml review should be mandatory only for new eclasses that 
are meant to be used by all the tree or by a great number of packages (>= 100 ?)

However, as stated in the email I reverted my changes and add the eclass to the 
ml.

Then, what a review means, when it is approved or denied, I will try to learn

Alfredo

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Fri, 2019-09-06 at 00:47 +0200, Thomas Deutschmann wrote:
> On 2019-09-05 22:16, Michał Górny wrote:
> > > But as per the way the dev manual is written, he arguably *is*
> > > following policy.
> > > 
> > > Stop taking the line of assuming he's trying to be belligerent. 
> > 
> > He says explicitly that he is against fixing devmanual because he likes
> > the way he can abuse it right now.
> 
> You are the only one adding _abuse_ here. Stop that, thanks. When I
> replied to your mail I was just asking... nothing more. I don't
> understand why you are reading so much into it.
> 
> But yes, I like the current exception for "per-package" eclasses like I
> am concerned that a review requirement would cause a significant delay:
> 
> Back to my example, imagine we would move pkg_config to new mysql
> eclass. If we would bump mysql/percona-server/mariadb package and will
> receive bug reports later because upstream changed something causing
> pkg_config to fail we would now have to propose a patch, wait 48
> hours... i.e. package would be broken for ~72 hours just because of a
> policy I don't reject in general (yes, I like reviews) but where I think
> exceptions must be possible.

Are you really saying that if you push buggy eclass (without review?),
then you need to push yet another eclass to fix it?  If so, then it
looks like something is really wrong with your workflow.

> So for my understanding this is not about 'fixing' devmanual. It's about
> *changing* devmanual which I *just* pointed out. But whoever will
> propose changing devmanual should support such a change because he/she
> will probably have to argue for that change. Something I cannot do when
> I like status quo like I do currently or have concerns.

So you don't believe in civil duty over your private interest.  Okay,
understood.

-- 
Best regards,
Michał Górny



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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Wed, Sep 4, 2019 at 7:26 PM Thomas Deutschmann  wrote:
> If you want to make it clear, change "should" to "must" and maybe
> clarify per-package exception and limit to update case if you believe
> that really *all* *new* eclasses must be send to mailing list.

As a native English speaker/writer, I find this "should" versus "must"
argument very tedious.

If a technical document says I "should" do something, and I don't do
it, I probably have very good reason for not doing it and should be
able to easily explain that reason. There's nothing wrong with that,
and calling it out on a mailing list is entirely appropriate.

If a technical document says I "must" do something, I take that
somewhat more seriously, and I expect bad things will happen if I go
against it. In the case of Gentoo, I would expect a revert with no
questions asked if the procedure is not followed.

In either case, it's clear that the advice given in the document is
something I should pay attention to.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Thu, Sep 5, 2019 at 6:47 PM Thomas Deutschmann  wrote:
>
> On 2019-09-05 22:16, Michał Górny wrote:
> >> But as per the way the dev manual is written, he arguably *is*
> >> following policy.
> >>
> >> Stop taking the line of assuming he's trying to be belligerent.
> >
> > He says explicitly that he is against fixing devmanual because he likes
> > the way he can abuse it right now.
>
> You are the only one adding _abuse_ here. Stop that, thanks. When I
> replied to your mail I was just asking... nothing more. I don't
> understand why you are reading so much into it.

The devmanual o clearly indicates that an email to gentoo-dev is
strongly preferred. I don't see any reason why tupone could not have
done this.

You seem to be trying to take this opportunity to prove some loosely
related point.

> But yes, I like the current exception for "per-package" eclasses like I
> am concerned that a review requirement would cause a significant delay:
>
> Back to my example, imagine we would move pkg_config to new mysql
> eclass. If we would bump mysql/percona-server/mariadb package and will
> receive bug reports later because upstream changed something causing
> pkg_config to fail we would now have to propose a patch, wait 48
> hours... i.e. package would be broken for ~72 hours just because of a
> policy I don't reject in general (yes, I like reviews) but where I think
> exceptions must be possible.

This argument is stupid. If you need to push a critical bug fix, then
do it. Nobody will fault you for it.

This clearly does not apply to ada.eclass.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

On 2019-09-05 22:16, Michał Górny wrote:
>> But as per the way the dev manual is written, he arguably *is*
>> following policy.
>>
>> Stop taking the line of assuming he's trying to be belligerent. 
>
> He says explicitly that he is against fixing devmanual because he likes
> the way he can abuse it right now.

You are the only one adding _abuse_ here. Stop that, thanks. When I
replied to your mail I was just asking... nothing more. I don't
understand why you are reading so much into it.

But yes, I like the current exception for "per-package" eclasses like I
am concerned that a review requirement would cause a significant delay:

Back to my example, imagine we would move pkg_config to new mysql
eclass. If we would bump mysql/percona-server/mariadb package and will
receive bug reports later because upstream changed something causing
pkg_config to fail we would now have to propose a patch, wait 48
hours... i.e. package would be broken for ~72 hours just because of a
policy I don't reject in general (yes, I like reviews) but where I think
exceptions must be possible.

So for my understanding this is not about 'fixing' devmanual. It's about
*changing* devmanual which I *just* pointed out. But whoever will
propose changing devmanual should support such a change because he/she
will probably have to argue for that change. Something I cannot do when
I like status quo like I do currently or have concerns.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Fri, 2019-09-06 at 08:08 +1200, Kent Fredric wrote:
> On Thu, 05 Sep 2019 21:47:11 +0200
> Michał Górny  wrote:
> 
> > So to summarize, instead of working together in order to follow a well-
> > established policy,
> 
> You're reading it wrong. If its "established policy", dev manual must
> reflect that.
> 
> If the dev-manual writes "should" in one place, and implies "must" in
> another for a same thing, then either:
> 
> - The dev manual needs to be fixed
> - The policy is not as you suggest it is.
> 
> If the dev-manual is written correctly for the policy, then I expect he
> is saying he'll follow it.

We've already established that the wording in devmanual is unfortunate,
and I've asked him to submit a patch.  It would be really nice if more
than three developers cared to actually work on devmanual which is
probably the most important document for devs.

> But as per the way the dev manual is written, he arguably *is*
> following policy.
> 
> Stop taking the line of assuming he's trying to be belligerent. 

He says explicitly that he is against fixing devmanual because he likes
the way he can abuse it right now.


-- 
Best regards,
Michał Górny



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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

On Thu, 05 Sep 2019 21:47:11 +0200
Michał Górny  wrote:

> So to summarize, instead of working together in order to follow a well-
> established policy,

You're reading it wrong. If its "established policy", dev manual must
reflect that.

If the dev-manual writes "should" in one place, and implies "must" in
another for a same thing, then either:

- The dev manual needs to be fixed
- The policy is not as you suggest it is.

If the dev-manual is written correctly for the policy, then I expect he
is saying he'll follow it.

But as per the way the dev manual is written, he arguably *is*
following policy.

Stop taking the line of assuming he's trying to be belligerent. 


pgpNdfaSqqSRB.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michael Everitt]

On 05/09/19 20:47, Michał Górny wrote:
> On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote:
>> On 2019-09-05 06:02, Michał Górny wrote:
 In my case I am working on a new mysql eclass to outsource pkg_config
 function which is shared at least between dev-db/mysql and
 dev-db/percona-server (and maybe dev-db/mariadb).

 For this new eclass I would say it's a "per-package" eclass and would
 probably have skipped mailing list review, too.
>>> Everyone can skip as many paragraphs as they want, and then apply what's
>>> said later to something said way earlier.
>> Could you please stop adding any bad interpretation?
>>
>> That was a serious question. For you, it's pretty clear. I am showing
>> you, that for me, it isn't pretty clear. When you believe I skipped
>> important lines in my quote please outline what I have missed and I will
>> take the blame.
>>
>>
 If you want to make it clear, change "should" to "must" and maybe
 clarify per-package exception and limit to update case if you believe
 that really *all* *new* eclasses must be send to mailing list.
>>> Submit a part.  This is a community effort.  Nitpicking and complaining
>>> doesn't make things better.  Fixing them does.
>> Sure, but at the moment *you* are the one who are saying it's a MUST. I
>> don't understand it that way and I am fine with my understanding that
>> per-package eclasses *should* but *must not* get reviewed through
>> mailing list. In other words I am asking you to show us where it's
>> written that *all* *new* eclasses *must* get reviewed through mailing
>> list. I cannot find something like that in current devmanual (the link
>> you showed).
>>
>> Maybe I am still missing something after reading
>> https://devmanual.gentoo.org/eclass-writing/ 3 times...
>>
>> In case I am not missing anything I suggested to improve devmanual in
>> case you believe this should be a hard requirement. Because at the
>> moment I don't believe it should be a hard requirement, *I* will not
>> propose any changes.
>>
> So to summarize, instead of working together in order to follow a well-
> established policy, you prefer to do whatever you find convenient
> at the moment, as long as you justify it by finding some document whose
> wording does not perfectly prevent you from bending the policy?  Yes,
> that sounds like a very good attitude for a Council member.
>
Pot meet Kettle ..





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote:
> On 2019-09-05 06:02, Michał Górny wrote:
> > > In my case I am working on a new mysql eclass to outsource pkg_config
> > > function which is shared at least between dev-db/mysql and
> > > dev-db/percona-server (and maybe dev-db/mariadb).
> > > 
> > > For this new eclass I would say it's a "per-package" eclass and would
> > > probably have skipped mailing list review, too.
> > 
> > Everyone can skip as many paragraphs as they want, and then apply what's
> > said later to something said way earlier.
> 
> Could you please stop adding any bad interpretation?
> 
> That was a serious question. For you, it's pretty clear. I am showing
> you, that for me, it isn't pretty clear. When you believe I skipped
> important lines in my quote please outline what I have missed and I will
> take the blame.
> 
> 
> > > If you want to make it clear, change "should" to "must" and maybe
> > > clarify per-package exception and limit to update case if you believe
> > > that really *all* *new* eclasses must be send to mailing list.
> > 
> > Submit a part.  This is a community effort.  Nitpicking and complaining
> > doesn't make things better.  Fixing them does.
> 
> Sure, but at the moment *you* are the one who are saying it's a MUST. I
> don't understand it that way and I am fine with my understanding that
> per-package eclasses *should* but *must not* get reviewed through
> mailing list. In other words I am asking you to show us where it's
> written that *all* *new* eclasses *must* get reviewed through mailing
> list. I cannot find something like that in current devmanual (the link
> you showed).
> 
> Maybe I am still missing something after reading
> https://devmanual.gentoo.org/eclass-writing/ 3 times...
> 
> In case I am not missing anything I suggested to improve devmanual in
> case you believe this should be a hard requirement. Because at the
> moment I don't believe it should be a hard requirement, *I* will not
> propose any changes.
> 

So to summarize, instead of working together in order to follow a well-
established policy, you prefer to do whatever you find convenient
at the moment, as long as you justify it by finding some document whose
wording does not perfectly prevent you from bending the policy?  Yes,
that sounds like a very good attitude for a Council member.

-- 
Best regards,
Michał Górny



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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[James Le Cuirot]

On Fri, 6 Sep 2019 07:26:42 +1200
Kent Fredric  wrote:

> On Thu, 5 Sep 2019 09:04:23 -0500
> Gordon Pettey  wrote:
> 
> > You'll note the bit you quoted in defense of skipping review says
> > "changes", and the bit about new eclasses says "do not skip this step".  
> 
> Emphasis added:
> 
> -
> BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
> gentoo-dev mailing list with a justification and a proposed
> implementation. DO NOT SKIP this step — sometimes a better
> implementation or an alternative which does not require a new eclass
> will be suggested. 
> -
> 
> 
> If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a
> suggestion, following a suggestion with an imperative just adds
> predictable confusion.
> 
> Either fix the "should", or drop the "DO NOT SKIP".
> 
> Otherwise you're just giving mixed messages.

+1

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpJgXWi9pLeE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

On Thu, 5 Sep 2019 09:04:23 -0500
Gordon Pettey  wrote:

> You'll note the bit you quoted in defense of skipping review says
> "changes", and the bit about new eclasses says "do not skip this step".

Emphasis added:

-
BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
gentoo-dev mailing list with a justification and a proposed
implementation. DO NOT SKIP this step — sometimes a better
implementation or an alternative which does not require a new eclass
will be suggested. 
-


If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a
suggestion, following a suggestion with an imperative just adds
predictable confusion.

Either fix the "should", or drop the "DO NOT SKIP".

Otherwise you're just giving mixed messages.


pgp3DvpDDsd3I.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gordon Pettey]

On Thu, Sep 5, 2019 at 8:15 AM Thomas Deutschmann  wrote:

> On 2019-09-05 06:02, Michał Górny wrote:
> >> In my case I am working on a new mysql eclass to outsource pkg_config
> >> function which is shared at least between dev-db/mysql and
> >> dev-db/percona-server (and maybe dev-db/mariadb).
> >>
> >> For this new eclass I would say it's a "per-package" eclass and would
> >> probably have skipped mailing list review, too.
> >
> > Everyone can skip as many paragraphs as they want, and then apply what's
> > said later to something said way earlier.
>
> Could you please stop adding any bad interpretation?
>
> That was a serious question. For you, it's pretty clear. I am showing
> you, that for me, it isn't pretty clear. When you believe I skipped
> important lines in my quote please outline what I have missed and I will
> take the blame.
>

You'll note the bit you quoted in defense of skipping review says
"changes", and the bit about new eclasses says "do not skip this step".

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

On 2019-09-05 06:02, Michał Górny wrote:
>> In my case I am working on a new mysql eclass to outsource pkg_config
>> function which is shared at least between dev-db/mysql and
>> dev-db/percona-server (and maybe dev-db/mariadb).
>>
>> For this new eclass I would say it's a "per-package" eclass and would
>> probably have skipped mailing list review, too.
> 
> Everyone can skip as many paragraphs as they want, and then apply what's
> said later to something said way earlier.

Could you please stop adding any bad interpretation?

That was a serious question. For you, it's pretty clear. I am showing
you, that for me, it isn't pretty clear. When you believe I skipped
important lines in my quote please outline what I have missed and I will
take the blame.


>> If you want to make it clear, change "should" to "must" and maybe
>> clarify per-package exception and limit to update case if you believe
>> that really *all* *new* eclasses must be send to mailing list.
> 
> Submit a part.  This is a community effort.  Nitpicking and complaining
> doesn't make things better.  Fixing them does.

Sure, but at the moment *you* are the one who are saying it's a MUST. I
don't understand it that way and I am fine with my understanding that
per-package eclasses *should* but *must not* get reviewed through
mailing list. In other words I am asking you to show us where it's
written that *all* *new* eclasses *must* get reviewed through mailing
list. I cannot find something like that in current devmanual (the link
you showed).

Maybe I am still missing something after reading
https://devmanual.gentoo.org/eclass-writing/ 3 times...

In case I am not missing anything I suggested to improve devmanual in
case you believe this should be a hard requirement. Because at the
moment I don't believe it should be a hard requirement, *I* will not
propose any changes.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Thu, 2019-09-05 at 01:26 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> On 2019-09-04 20:59, Michał Górny wrote:
> > Devmanual is pretty clear on the fact that *all* new eclasses require ml
> >   ^^^
> > review *before* committing:
> 
> I am also working on a new eclass so I looked up details regarding
> what's needed to add a new eclass recently.
> 
> I must say that I disagree that it's *pretty* clear.
> 
> > Adding and Updating Eclasses
> > 
> > Before committing a new eclass to the tree, it should be emailed
> >^^
> > to the gentoo-dev mailing list with a justification and a
> > proposed implementation. Do not skip this step — sometimes a
> > better implementation or an alternative which does not require a
> > new eclass will be suggested.
> > 
> > Before updating [...]
> > 
> > The exceptions to this rule are per-package eclasses. For
> > 
> > example, the apache-2 eclass is only used by the www-servers/apache
> > package, and thus does not typically require changes to be emailed
> > for review.
> 
> In my case I am working on a new mysql eclass to outsource pkg_config
> function which is shared at least between dev-db/mysql and
> dev-db/percona-server (and maybe dev-db/mariadb).
> 
> For this new eclass I would say it's a "per-package" eclass and would
> probably have skipped mailing list review, too.

Everyone can skip as many paragraphs as they want, and then apply what's
said later to something said way earlier.

> 
> If you want to make it clear, change "should" to "must" and maybe
> clarify per-package exception and limit to update case if you believe
> that really *all* *new* eclasses must be send to mailing list.

Submit a part.  This is a community effort.  Nitpicking and complaining
doesn't make things better.  Fixing them does.

> 
> 

-- 
Best regards,
Michał Górny



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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

Hi,

On 2019-09-04 20:59, Michał Górny wrote:
> Devmanual is pretty clear on the fact that *all* new eclasses require ml
>   ^^^
> review *before* committing:

I am also working on a new eclass so I looked up details regarding
what's needed to add a new eclass recently.

I must say that I disagree that it's *pretty* clear.

> Adding and Updating Eclasses
>
> Before committing a new eclass to the tree, it should be emailed
>^^
> to the gentoo-dev mailing list with a justification and a
> proposed implementation. Do not skip this step — sometimes a
> better implementation or an alternative which does not require a
> new eclass will be suggested.
>
> Before updating [...]
>
> The exceptions to this rule are per-package eclasses. For
> 
> example, the apache-2 eclass is only used by the www-servers/apache
> package, and thus does not typically require changes to be emailed
> for review.

In my case I am working on a new mysql eclass to outsource pkg_config
function which is shared at least between dev-db/mysql and
dev-db/percona-server (and maybe dev-db/mariadb).

For this new eclass I would say it's a "per-package" eclass and would
probably have skipped mailing list review, too.

If you want to make it clear, change "should" to "must" and maybe
clarify per-package exception and limit to update case if you believe
that really *all* *new* eclasses must be send to mailing list.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[David Seifert]

On Wed, 2019-09-04 at 20:59 +0200, Michał Górny wrote:
> On Wed, 2019-09-04 at 18:00 +, Alfredo Tupone wrote:
> > commit: 63486fef43c2e0dee3b4128db18fd1a6b4bf9381
> > Author: Tupone Alfredo  gentoo  org>
> > AuthorDate: Wed Sep  4 17:58:49 2019 +
> > Commit: Alfredo Tupone  gentoo  org>
> > CommitDate: Wed Sep  4 17:58:49 2019 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef
> > 
> > ada.eclass: New eclass for dev-ada packages
> > 
> > Signed-off-by: Alfredo Tupone  gentoo.org>
> > 
> >  eclass/ada.eclass | 431
> > ++
> >  1 file changed, 431 insertions(+)
> > 
> 
> Devmanual is pretty clear on the fact that *all* new eclasses require
> ml
> review *before* committing:
> 
> https://devmanual.gentoo.org/eclass-writing/index.html
> 

Please revert.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Wed, 2019-09-04 at 18:00 +, Alfredo Tupone wrote:
> commit: 63486fef43c2e0dee3b4128db18fd1a6b4bf9381
> Author: Tupone Alfredo  gentoo  org>
> AuthorDate: Wed Sep  4 17:58:49 2019 +
> Commit: Alfredo Tupone  gentoo  org>
> CommitDate: Wed Sep  4 17:58:49 2019 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63486fef
> 
> ada.eclass: New eclass for dev-ada packages
> 
> Signed-off-by: Alfredo Tupone  gentoo.org>
> 
>  eclass/ada.eclass | 431 
> ++
>  1 file changed, 431 insertions(+)
> 

Devmanual is pretty clear on the fact that *all* new eclasses require ml
review *before* committing:

https://devmanual.gentoo.org/eclass-writing/index.html

-- 
Best regards,
Michał Górny



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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Matt Turner]

On Mon, Jul 29, 2019 at 10:20 PM Michał Górny  wrote:
>
> On Tue, 2019-07-30 at 01:49 +, Matt Turner wrote:
> > commit: 6f680e4fe73925ae130343e02adb416cb799ce7d
> > Author: Chris Mayo  gmail  com>
> > AuthorDate: Fri Jul 26 18:48:13 2019 +
> > Commit: Matt Turner  gentoo  org>
> > CommitDate: Tue Jul 30 01:49:41 2019 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> >
> > virtualx.eclass: Fix no display for an emerge following a failure
> >
> > If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> > /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> > a previous emerge left /tmp/.X1-lock behind.
> >
> > Closes: https://bugs.gentoo.org/690778
> > Signed-off-by: Chris Mayo  gmail.com>
> > Signed-off-by: Matt Turner  gentoo.org>
> >
> >  eclass/virtualx.eclass | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> > index fb6a867a35c..40eeea5463b 100644
> > --- a/eclass/virtualx.eclass
> > +++ b/eclass/virtualx.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2018 Gentoo Foundation
> > +# Copyright 1999-2019 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: virtualx.eclass
> > @@ -178,7 +178,10 @@ virtx() {
> >   # Xvfb is started, else bump the display number
> >   #
> >   # Azarah - 5 May 2002
> > - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; 
> > echo ${i})
> > + # GNOME GDM may have started X on DISPLAY :0 with a
> > + # lock file /tmp/.X1024-lock, therefore start the search at 1.
> > + # Else a leftover /tmp/.X1-lock will prevent finding an available 
> > display.
> > + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; 
> > echo ${i})
> >   debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
> >
> >   # We really do not want SANDBOX enabled here
>
> Isn't this a cheap hack that doesn't fix the underlying issue but shifts
> the problem into hopefully-won't-happen-this-time?

Yes, but given that the prior code was a cheap hack as well (from
2002, no less!) and has worked out well enough for 17 years that no
one has reported problems with it until now, I don't think it's
critical to make it bullet-proof.

Of course I'm happy to accept patches.

> Also, why are you skipping mailing list review for eclass changes?

Ah, you are right. My apologies.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Tue, 2019-07-30 at 01:49 +, Matt Turner wrote:
> commit: 6f680e4fe73925ae130343e02adb416cb799ce7d
> Author: Chris Mayo  gmail  com>
> AuthorDate: Fri Jul 26 18:48:13 2019 +
> Commit: Matt Turner  gentoo  org>
> CommitDate: Tue Jul 30 01:49:41 2019 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> 
> virtualx.eclass: Fix no display for an emerge following a failure
> 
> If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> a previous emerge left /tmp/.X1-lock behind.
> 
> Closes: https://bugs.gentoo.org/690778
> Signed-off-by: Chris Mayo  gmail.com>
> Signed-off-by: Matt Turner  gentoo.org>
> 
>  eclass/virtualx.eclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> index fb6a867a35c..40eeea5463b 100644
> --- a/eclass/virtualx.eclass
> +++ b/eclass/virtualx.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: virtualx.eclass
> @@ -178,7 +178,10 @@ virtx() {
>   # Xvfb is started, else bump the display number
>   #
>   # Azarah - 5 May 2002
> - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo 
> ${i})
> + # GNOME GDM may have started X on DISPLAY :0 with a
> + # lock file /tmp/.X1024-lock, therefore start the search at 1.
> + # Else a leftover /tmp/.X1-lock will prevent finding an available 
> display.
> + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo 
> ${i})
>   debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
>  
>   # We really do not want SANDBOX enabled here

Isn't this a cheap hack that doesn't fix the underlying issue but shifts
the problem into hopefully-won't-happen-this-time?

Also, why are you skipping mailing list review for eclass changes?

-- 
Best regards,
Michał Górny



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

Re: Implicit use of versionator.eclass in ebuilds and eclasses (was: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/)

[M. J. Everitt]

On 19/05/18 01:01, Andreas Sturmlechner wrote:
> On Freitag, 18. Mai 2018 23:53:06 CEST Michał Górny wrote:
>> One of the reasons we do mailing list reviews of widely used eclasses is
>> to let people tell you that you've left 'version_is_at_least' here.
> I see the error of my ways.
>
> Meanwhile, here's a list of packages implicitly using versionator.eclass 
> functions:
>
> eclasses:
>
> haskell-cabal.eclass
> mozextension.eclass
>
> ebuilds:
>
> app-admin/rsyslog/rsyslog-8.28.0-r1.ebuild
> app-admin/rsyslog/rsyslog-8.32.0-r4.ebuild
> app-admin/rsyslog/rsyslog-8.33.1-r1.ebuild
> app-admin/rsyslog/rsyslog-8.34.0.ebuild
> app-admin/rsyslog/rsyslog-8.35.0.ebuild
> app-emulation/qemu/qemu-2.11.1-r2.ebuild
> app-emulation/qemu/qemu-2.11.1-r53.ebuild
> app-emulation/qemu/qemu-2.12.0.ebuild
> app-emulation/qemu/qemu-.ebuild
> dev-java/htmlparser-org/htmlparser-org-1.6.ebuild
> dev-java/vecmath/vecmath-1.6.0_pre12.ebuild
> dev-ruby/rspec-core/rspec-core-3.5.4.ebuild
> dev-ruby/rspec-core/rspec-core-3.6.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.1.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.5.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.6.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.7.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.5.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.6.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.7.0.ebuild
> dev-vcs/bzr/bzr-2.7.1_pre.ebuild
> net-fs/samba/samba-4.2.14.ebuild
> net-fs/samba/samba-4.5.16.ebuild
> net-fs/samba/samba-4.6.15.ebuild
> net-fs/samba/samba-4.7.7.ebuild
> net-fs/samba/samba-4.8.1.ebuild
> net-fs/samba/samba-4.8.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2-r1.ebuild
> net-misc/openvswitch/openvswitch-2.8.1.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20170901.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20180318.ebuild
> sys-kernel/mips-sources/mips-sources-4.13.16.ebuild
> sys-kernel/mips-sources/mips-sources-4.4.110.ebuild
> sys-kernel/mips-sources/mips-sources-4.9.75.ebuild
>
>
>
>
Can that be parsed into a list of (unique) maintainers to ping maybe?

Someone might have to pick up any maintainer-needed ones I s'pose.



signature.asc
Description: OpenPGP digital signature

Implicit use of versionator.eclass in ebuilds and eclasses (was: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/)

[Andreas Sturmlechner]

On Freitag, 18. Mai 2018 23:53:06 CEST Michał Górny wrote:
> One of the reasons we do mailing list reviews of widely used eclasses is
> to let people tell you that you've left 'version_is_at_least' here.

I see the error of my ways.

Meanwhile, here's a list of packages implicitly using versionator.eclass 
functions:

eclasses:

haskell-cabal.eclass
mozextension.eclass

ebuilds:

app-admin/rsyslog/rsyslog-8.28.0-r1.ebuild
app-admin/rsyslog/rsyslog-8.32.0-r4.ebuild
app-admin/rsyslog/rsyslog-8.33.1-r1.ebuild
app-admin/rsyslog/rsyslog-8.34.0.ebuild
app-admin/rsyslog/rsyslog-8.35.0.ebuild
app-emulation/qemu/qemu-2.11.1-r2.ebuild
app-emulation/qemu/qemu-2.11.1-r53.ebuild
app-emulation/qemu/qemu-2.12.0.ebuild
app-emulation/qemu/qemu-.ebuild
dev-java/htmlparser-org/htmlparser-org-1.6.ebuild
dev-java/vecmath/vecmath-1.6.0_pre12.ebuild
dev-ruby/rspec-core/rspec-core-3.5.4.ebuild
dev-ruby/rspec-core/rspec-core-3.6.0.ebuild
dev-ruby/rspec-core/rspec-core-3.7.0.ebuild
dev-ruby/rspec-core/rspec-core-3.7.1.ebuild
dev-ruby/rspec-expectations/rspec-expectations-3.5.0.ebuild
dev-ruby/rspec-expectations/rspec-expectations-3.6.0.ebuild
dev-ruby/rspec-expectations/rspec-expectations-3.7.0.ebuild
dev-ruby/rspec-mocks/rspec-mocks-3.5.0.ebuild
dev-ruby/rspec-mocks/rspec-mocks-3.6.0.ebuild
dev-ruby/rspec-mocks/rspec-mocks-3.7.0.ebuild
dev-vcs/bzr/bzr-2.7.1_pre.ebuild
net-fs/samba/samba-4.2.14.ebuild
net-fs/samba/samba-4.5.16.ebuild
net-fs/samba/samba-4.6.15.ebuild
net-fs/samba/samba-4.7.7.ebuild
net-fs/samba/samba-4.8.1.ebuild
net-fs/samba/samba-4.8.2.ebuild
net-misc/openvswitch/openvswitch-2.7.2.ebuild
net-misc/openvswitch/openvswitch-2.7.2-r1.ebuild
net-misc/openvswitch/openvswitch-2.8.1.ebuild
sys-apps/lm_sensors/lm_sensors-3.4.0_p20170901.ebuild
sys-apps/lm_sensors/lm_sensors-3.4.0_p20180318.ebuild
sys-kernel/mips-sources/mips-sources-4.13.16.ebuild
sys-kernel/mips-sources/mips-sources-4.4.110.ebuild
sys-kernel/mips-sources/mips-sources-4.9.75.ebuild

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

W dniu pią, 18.05.2018 o godzinie 20∶36 +, użytkownik Andreas
Sturmlechner napisał:
> commit: d780c05e4459175eb314c82de9f3b998e2b4fc6e
> Author: Andreas Sturmlechner  gentoo  org>
> AuthorDate: Thu May 10 20:42:15 2018 +
> Commit: Andreas Sturmlechner  gentoo  org>
> CommitDate: Fri May 18 20:36:12 2018 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d780c05e
> 
> cmake-utils.eclass: Switch to eapi7-ver
> 
>  eclass/cmake-utils.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 3302f27608b..cbce280625e 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -109,11 +109,11 @@ case ${EAPI} in
>   *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
>  
> -inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing versionator 
> xdg-utils
> +inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils
>  
>  case ${EAPI} in
>   7) ;;
> - *) inherit eutils multilib ;;
> + *) inherit eapi7-ver eutils multilib ;;
>  esac
>  
>  EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
> @@ -512,7 +512,7 @@ cmake-utils_src_configure() {
>   # we need to add ""
>   local includes=
>   if [[ ${PN} == cmake ]] ; then
> - if $(version_is_at_least 3.4.0 $(get_version_component_range 
> 1-3 ${PV})) ; then
> + if $(version_is_at_least 3.4.0 $(ver_cut 1-3 ${PV})) ; then

One of the reasons we do mailing list reviews of widely used eclasses is
to let people tell you that you've left 'version_is_at_least' here.

>   includes=""
>   fi
>   elif ROOT=/ has_version \>=dev-util/cmake-3.4.0_rc1 ; then
> 

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

W dniu pią, 05.01.2018 o godzinie 13∶13 +, użytkownik Lars Wendler
napisał:
> commit: 1e09cba657ccb2b8e6fbcbeb28c5c593da2127eb
> Author: Gary Macindoe  garymacindoe  co  uk>
> AuthorDate: Thu Sep 28 21:32:34 2017 +
> Commit: Lars Wendler  gentoo  org>
> CommitDate: Fri Jan  5 13:13:40 2018 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e09cba6
> 
> Fix handling of multiple CDs
> 
> Closes: https://github.com/gentoo/gentoo/pull/5818
> 
>  eclass/cdrom.eclass | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> index 47e2c6342e0..7b0eb9c6c3b 100644
> --- a/eclass/cdrom.eclass
> +++ b/eclass/cdrom.eclass
> @@ -71,7 +71,12 @@ fi
>  # eclass, see that function's description.
>  cdrom_get_cds() {
>   unset CDROM_SET
> - export CDROM_CURRENT_CD=0 CDROM_CHECKS=( "${@}" )
> + export CDROM_CURRENT_CD=0
> +export CDROM_NUM_CDS="${#}"
> +local i
> +for i in $(seq ${#}); do
> +export CDROM_CHECK_${i}="${!i}"
> +done

Please fix the indentation.

>  
>   # If the user has set CD_ROOT or CD_ROOT_1, don't bother informing
>   # them about which discs are needed as they presumably already know.
> @@ -190,7 +195,8 @@ cdrom_load_next_cd() {
>   local i cdset
>   : CD_ROOT_${CDROM_CURRENT_CD}
>   export CDROM_ROOT=${CD_ROOT:-${!_}}
> - IFS=: read -r -a cdset -d "" <<< 
> "${CDROM_CHECKS[$((${CDROM_CURRENT_CD} - 1))]}"
> + local var="CDROM_CHECK_${CDROM_CURRENT_CD}"
> + IFS=: read -r -a cdset -d "" <<< "${!var}"
>  
>   for i in $(seq ${CDROM_SET:-0} ${CDROM_SET:-$((${#cdset[@]} - 
> 1))}); do
>   local f=${cdset[${i}]} point= node= fs= opts=
> @@ -222,7 +228,7 @@ cdrom_load_next_cd() {
>   fi
>  
>   if [[ ${showedmsg} -eq 0 ]] ; then
> - if [[ ${#CDROM_CHECKS[@]} -eq 1 ]] ; then
> + if [[ ${CDROM_NUM_CDS} -eq 1 ]] ; then
>   einfo "Please insert+mount the ${CDROM_NAME:-CD 
> for ${PN}} now !"
>   else
>   local var="CDROM_NAME_${CDROM_CURRENT_CD}"
> 

This looks like a major change which also pretty much reverts
the direction the previous (ml-reviewed) patches took. As such,
it would be really desirable to post it for review instead of stealthily
committing to an eclass which -- as far as metadata says -- you aren't
even maintainer of.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luis Ressel]

On Sun, 21 May 2017 10:46:25 -0700
Raymond Jennings  wrote:

> Just out of curiosity, and for the curious:
> 
> 1.  How often do cache updates happen?
> 2.  How long do they take?
> 3.  Is there any downside to only having one such update running at a
> time and just skipping them if there's already an update pending?

I'm generating metadata locally. There are changes to some of the more
important eclasses roughly every other week; and after such a change,
the regen takes 10-25 minutes on my hardware.

I don't understand your question (3).

Regards,
Luis Ressel


pgpnERfyAGpjK.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 21/05/17 20:32, Kent Fredric wrote:
> But I'd also like a pony.
>
I'm hoping for a unicorn still ...

[apologies, resending as hit the wrong button in the Compose button..]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

binsSfjd9wdyD.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

On Sun, 21 May 2017 19:34:26 +0200
Michał Górny  wrote:

> Like, by not using eclasses and instead inlining all the stuff?

I'd personally suggest we endeavour towards making systems in place so
that the performance overheads of metadata generation is much lower, to
the point it can be done efficiently without needing cache
provisioning.

But I'd also like a pony.

( I have ideas using daemons, inotify, and persistent databases as the
primary metadata layer instead of millions of files, but they're all
too complicated and hard )


pgpmH8Qp__3gM.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Martin Vaeth]

Michał Górny  wrote:
>> If this is such a big problem, maybe we should be discussing how to
>> redesign things to improve it?
>
> Like, by not using eclasses and instead inlining all the stuff?

There are other ways.

One way to mitigate the problem might be to require that
eclasses contain some

# @VERSION: major.minor-revision

line and that the metadata cache of an ebuild contains that version
number (or at least the major component of it) instead of an md5 sum.
Then the commiter of the eclass has full control whether a metadata
regeneration will happen or not:

For trivial changes (see below), the committer simply does not
increase that version number (or increase only minor-revision),
and one could agree that a rebuild of the metadata only happens
if the major version number of an eclass changes.

By "trivial changes" I mean in this connection not only changes
in comments but also minor changes in functionality or even in
the API: The only strict requirement is that the major version
has to increase if the eclass change can induce a change in the
metadata of some ebuild using it (e.g. if a value printed by
some function changes which might involve IUSE, REQUIRED_USE,
DEPEND, ...)

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Raymond Jennings]

On Tue, May 16, 2017 at 12:20 PM, Michał Górny  wrote:

> Mike,
>
> I would really appreciate if you cared to follow procedures for eclass
> changes. Most notably, if you at least bothered to either ping us *or*
> sent the patch to the mailing list beforehand.
>
> This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
> changes in large patchsets to reduce cache updates. Of course it is all
> pointless if a random Mike Frysinger, developer on special rights, goes
> ahead and commits whatever he wants to whatever eclasses he wants to
> commit to, whatever time he pleases.
>
> Normally, I would revert it but I don't feel like causing third huge
> cache update today.
>

Just out of curiosity, and for the curious:

1.  How often do cache updates happen?
2.  How long do they take?
3.  Is there any downside to only having one such update running at a time
and just skipping them if there's already an update pending?

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On nie, 2017-05-21 at 11:29 -0500, William Hubbs wrote:
> On Sun, May 21, 2017 at 02:46:54PM +, Martin Vaeth wrote:
> > Kent Fredric  wrote:
> > > Fabian Groffen  wrote:
> > > 
> > > >  Hardware or more deltas to
> > > > download by users?  Just wondering.
> > > 
> > > Both.
> > > 
> > > - End users using git end up having to do massive metadata-updates.
> > > - Infra needs to have massive hits to metadata regeneration
> > > - End users using rsync have to fetch large deltas
> > 
> >   - Users using git repositories with pre-generated metadata have to
> > download/store much more history data
> 
> If this is such a big problem, maybe we should be discussing how to
> redesign things to improve it?
> 

Like, by not using eclasses and instead inlining all the stuff?


-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[William Hubbs]

On Sun, May 21, 2017 at 02:46:54PM +, Martin Vaeth wrote:
> Kent Fredric  wrote:
> > Fabian Groffen  wrote:
> >
> >>  Hardware or more deltas to
> >> download by users?  Just wondering.
> >
> > Both.
> >
> > - End users using git end up having to do massive metadata-updates.
> > - Infra needs to have massive hits to metadata regeneration
> > - End users using rsync have to fetch large deltas
> 
>   - Users using git repositories with pre-generated metadata have to
> download/store much more history data

If this is such a big problem, maybe we should be discussing how to
redesign things to improve it?

William


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Martin Vaeth]

Kent Fredric  wrote:
> Fabian Groffen  wrote:
>
>>  Hardware or more deltas to
>> download by users?  Just wondering.
>
> Both.
>
> - End users using git end up having to do massive metadata-updates.
> - Infra needs to have massive hits to metadata regeneration
> - End users using rsync have to fetch large deltas

  - Users using git repositories with pre-generated metadata have to
download/store much more history data

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Kent Fredric]

On Tue, 16 May 2017 21:36:15 +0200
Fabian Groffen  wrote:

>  Hardware or more deltas to
> download by users?  Just wondering.

Both.

- End users using git end up having to do massive metadata-updates.
- Infra needs to have massive hits to metadata regeneration
- End users using rsync have to fetch large deltas

So its all-round sadness :(


pgphkCeDa8pjW.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Fabian Groffen]

On 16-05-2017 21:20:01 +0200, Michał Górny wrote:
> This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
> changes in large patchsets to reduce cache updates.
[snip]
> Normally, I would revert it but I don't feel like causing third huge
> cache update today.

What is the actual problem with that?  Hardware or more deltas to
download by users?  Just wondering.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

Mike,

On wto, 2017-05-16 at 19:10 +, Mike Frysinger wrote:
> commit: d1b05bcf81e5058c20615179fb83a90c45daa487
> Author: Mike Frysinger  chromium  org>
> AuthorDate: Tue May  9 02:34:53 2017 +
> Commit: Mike Frysinger  gentoo  org>
> CommitDate: Tue May 16 19:10:31 2017 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1b05bcf
> 
> python-utils-r1.eclass: add more info to stub python wrappers
> 
> The short terse error messages here are not easy to track down.  Add
> a few more details so people can figure out what's going wrong faster.
> 
>  eclass/python-utils-r1.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index c1349ff277b..0bf7e7ec1a3 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1041,7 +1041,7 @@ python_wrapper_setup() {
>   for x in "${nonsupp[@]}"; do
>   cat >"${workdir}"/bin/${x} <<-_EOF_ || die
>   #!/bin/sh
> - echo "${x} is not supported by ${EPYTHON}" >&2
> + echo "${ECLASS}: ${FUNCNAME}: ${x} is not 
> supported by ${EPYTHON} (PYTHON_COMPAT)" >&2
>   exit 127
>   _EOF_
>   chmod +x "${workdir}"/bin/${x} || die

I would really appreciate if you cared to follow procedures for eclass
changes. Most notably, if you at least bothered to either ping us *or*
sent the patch to the mailing list beforehand.

This eclass is used by almost 6700 ebuilds. I am trying *hard* to commit
changes in large patchsets to reduce cache updates. Of course it is all
pointless if a random Mike Frysinger, developer on special rights, goes
ahead and commits whatever he wants to whatever eclasses he wants to
commit to, whatever time he pleases.

Normally, I would revert it but I don't feel like causing third huge
cache update today.

-- 
Best regards,
Michał Górny


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

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Fri, 20 May 2016 19:47:55 + (UTC)
"Johannes Huber"  wrote:

> commit: 548f4ee19c6b0fe0d5e87e84a5a82c421229e0ce
> Author: Michael Palimaka  gentoo  org>
> AuthorDate: Fri May 20 19:46:11 2016 +
> Commit: Johannes Huber  gentoo  org>
> CommitDate: Fri May 20 19:47:15 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=548f4ee1
> 
> kde5.eclass: install all translations when LINGUAS is undefined
> 
> This mirrors the behaviour of the gettext autotools macros.
> 
> Gentoo-bug: 581382
> 
> Signed-off-by: Johannes Huber  gentoo.org>
> 
>  eclass/kde5.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/kde5.eclass b/eclass/kde5.eclass
> index 377d2c5..eaffb9e 100644
> --- a/eclass/kde5.eclass
> +++ b/eclass/kde5.eclass
> @@ -397,7 +397,7 @@ kde5_src_prepare() {
>  
>   # enable only the requested translations
>   # when required
> - if [[ -d po ]] ; then
> + if [[ -d po && -v LINGUAS ]] ; then
>   pushd po > /dev/null || die
>   for lang in *; do
>   if [[ -d ${lang} ]] && ! has ${lang} ${LINGUAS} ; then

This doesn't really make any difference since per EAPI 6 all USE_EXPAND
variables (incl. LINGUAS) are always defined. The only reason it seems
to work for you is due to a Portage bug.

-- 
Best regards,
Michał Górny



pgpz7E6VJkrDc.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Montag, 16. Mai 2016, 18:21:27 schrieb Andrew Savchenko:
>
> Everyone can and will make mistakes, this is normal. Only those who
> do nothing make no mistakes. I see no reason why developer should
> be discouraged from contributing for a single blunder. Of course,
> if blunder rate is too high, comrel should take an action; but this
> is not the case here.
> 

Just for the record, this is where qa should step in, not comrel. 

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOfYWXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkx8UP/RyUttstbaWVUMiAQ1gZBYeh
Ry93bojoZ+nV/H/vjVOGb6f2X2TtbyOx4c8krm/QekA/pMZCppn1oIpNRRaZdoPN
TB165er/86NzXmoez9Hq5HFVFNbT56SFSyiTTT8uzbn2/phOsWy1FkwRD1Fjs4OA
x9TZgrlFrnfwMlUHhtjbVQTuz0Cn+SYo1HSZ61hV5Y1YLm8MwSWZoS1mRDp65rD/
G5umBuhTHQplBY/ZBdvuR2R8/6/hQQfqI7E7wEj5MvUp98nReJjtYSP3c8WWQYhg
3OeGzyO+USIBGciSXu01ZUGQE4r7XnJ7uiq84wbp1PTVWXYCd8G6tmF7dMzgK8EO
GfCfQuDNIAFgJSzIT0u0D1VltX47kdaWVzpet8qsjP+Ucr4cMvYyaDkrTP7cg0cY
8viaMpG3skVsiDRxRBy/E0mBbl0NxzSehZVxGV9x7f/lfsN8WIIlxID4RfisAWPf
haXtclEKppbK9BdHXrBCYKFOBd0botAjYQhGylhwtnM/22N7v5SaHRezV7qaWYhw
VsQiPht9NCZxkG9yVe/sz1J34YtQ8pB/qG2FJ+A7GQd8fjsay3M75UBQ2AJDLLhf
CUOuyLCfZySMbdCPzPw4XevpMEsADnOMd6bal5uyUxQ2SvFDR0ub04mDf52p81Cd
Qme479L9QJk3gKHzoGBw
=uk3n
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andrew Savchenko]

On Mon, 16 May 2016 10:05:33 +0100 Ciaran McCreesh wrote:
> On Mon, 16 May 2016 15:56:01 +0800
> Ian Delaney  wrote:
> > As long as this persists and is not intervened to polish and tidy up,
> > g-devs will persist in making innocent, naive or incompetent blunders
> > and run the gauntlet of being publicly scolded over errata. I can only
> > express my view that this style of personal demeaning potentially
> > results in embarrassment, public humiliation and drives community
> > members away from participation. The ultimate negative influence. I
> > would never entertain taking on eclass writing with the incumbent qa
> > member delivering assessments under the title of 'code review' in the
> > style he does.
> 
> If you're writing the kind of code that results in you being subjected
> to scathing criticism for breaking metadata generation for the entire
> tree, then discouraging you from contributing can only be good for the
> distribution...
 
Everyone can and will make mistakes, this is normal. Only those who
do nothing make no mistakes. I see no reason why developer should
be discouraged from contributing for a single blunder. Of course,
if blunder rate is too high, comrel should take an action; but this
is not the case here.



Best regards,
Andrew Savchenko


pgpfYLIkdBuJr.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Mon, 16 May 2016 15:56:01 +0800
Ian Delaney  wrote:
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders
> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.

If you're writing the kind of code that results in you being subjected
to scathing criticism for breaking metadata generation for the entire
tree, then discouraging you from contributing can only be good for the
distribution...

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Monday, May 16, 2016 3:56:01 PM JST Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman  wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> >  [...]
> >  [...]
> >  [...]
> >  
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?
> 

Apparently we do, because people will continue to find ways to complain about 
words and feelings.

> This undescribed level of professionalism is presumed assumed
> knowledge, or 'understood', however the evidence suggests it is FAR
> from 'understood'.
> 

No, everyone just has a different tolerance for words that hurt or don't hurt.  
Perceived intentions or the tone of a person behind a computer really doesn't 
matter to most. 

> Here is a point worth highlighting.  While I find the language used to
> deliver the message an affront to my social senses, b-man does not and
> deems it apt to the situation. Herein therefore lies the dilemma.
> Being a communication instance, there are no clear rights or wrongs,
> but pure shades of grey. There are forms that most find fine and other

Next on bookshelves we will have "50 shades of Gentoo"... who is ready?!

> most find a violation of social etiquette. The result is that this
> style of submissions and responses re issues over QA are tacitly
> accepted as valid and therefore endorsed. There is at least one other
> dev in high authority who has all but ticked the message as justified
> in the circumstances, while in other instances has placed a cross to
> the same dev's reply in a separate thread.
> 
> This is predominantly why I refrain from sticking my neck out over
> this type of issue. Inevitably, by weight of numbers in the community,
> there will be someone who will vehemently reject and counter the point
> posed and attempt to shout it down as tripe. The point will be lost, or
> at least diluted to a meaningless mush.
> 

I appluad your efforts to ensure that the social aspect of Gentoo is a 
pleasant one.  The bottom line is that nothing wrong was said in this 
instance.

> > If you're only able to behave in a professional manner if the
> > standards of professionalism are explicitly spelled out, I think
> > you're missing the point.
> > 

Again, people come from various backgrounds and ideals so maybe it should be 
spelled out?  That is completely unfeasible though hence the new book...

> > Ultimately it is an attitude.  When you point out a mistake make it
> > either about:
> > 1.  Helping the person who made the mistake to improve because you
> > want to see them make better contributions (which they aren't going to
> > do if you drive them off).
> > 2.  If you feel that somebody simply isn't going to cut it, then by
> > all means report them so that their commit access can be revoked.
> 

I would prefer a simple "seriously" email vice a report to QA and the 
revocation of my commit access.

> rich0 here has hit the target a bullseye. The underlying attitude in
> the initial post displays a belief of justification and entitlement to
> 'shout down' the colleague and treat him with disdain over the blunder.
> This is NOT a bootcamp with paid drill sargeants.
> 
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders

blunder: "a stupid or careless mistake."  Are you redefining the word here or 
just calling the original violation stupid?  Because that would seriously hurt 
some feelings.  Semantics... what a condundrum.

> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.
> 

Thankfully someone is doing it.  If you choose not to contribute, out of fear 
of an individual behind a computer, you should reevaluate why you are doing 
this.

> It is clear he has learned that he is not only entitled but expected to
> shout at folk for misdemeanours. hasufell also believed this, and
> scoffed when I suggested to him directly one never needs to shout, but
> rather speak in tempered moderate terms.
> 
> Try it some time mgorny. The sky will not cave in.
> 

Entitlement and privilege.  The true essence of this whole problem.  No one 
here wants to feel as though someone else is better or superior to them.  I 
can only imagine though, that people believe 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Consus]

On 15:56 Mon 16 May, Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman  wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:  
> >  [...]  
> >  [...]  
> >  [...]  
> > >
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> > >  
> > 
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?

You need a better pair of balls; there is a chance that you will stop
getting offended by random emails.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 23:55, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
>
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
>
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
>
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
>
Surely it should be possible to fire some QA scripts on pre-commit on
the central gentoo repos (ie. at the push target end)?!
Or am I being a bit optimistic ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Committing without testing, as long as you don't push, is fine, even
> meritorious.  It's the push that uploads those commits to the gentoo
> reference repo, however, and testing should *definitely* be done before
> pushing, with more commits /before/ the push to fix what the tests found
> to be broken, should they be necessary.
>

Of course.  In fact, this is often the type of workflow you'd tend to
employ in a CI setup.  I believe that pull requests submitted on
github get automatically tinderboxed, though I have no idea whether
that provides any benefits to something like an eclass (if the CI
script just tests the ebuilds being modified it obviously would not).
Maybe in a perfect world we'd actually have a CI testing package
category with dummy packages that do nothing but run tests to cover
this sort of thing.

Even so, I would imagine that in most organizations CI is intended
more as a sanity check than a substitute for testing your own work.
Certainly where I work the expectation is that somebody would have at
least compiled and run something before putting it into some kind of
QA workflow, even with CI.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 03:55 PM, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
> 
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> 
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
> 
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
> 
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
> 
Sorry. I've actually been using git for years, but since I got started
with Gentoo on CVS and I try to be careful with my commits to the gentoo
repo, I conflated them. You're right, the push is what matters the most.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:

> If the dev in question hasn't done that before, then it's entirely
> possible they *thought* they tested, or tested it *before* making some
> other edit and absent-mindedly committed.

Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
push that's critical.

Commit all you want without testing.  Just test (and fix if necessary) 
before you push those commits up to the gentoo master repo. =:^)

(Of course, rebasing to fold the broken commit and its fix into one 
before pushing doesn't hurt, either.)

-- 
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] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:16:30 -0700 as excerpted:

> On 05/15/2016 03:29 AM, Michał Górny wrote:

>> However, is it that much of
>> an effort to test eclass changes using ebuilds *before* committing it?
>> It wasn't that hard even in times of CVS (esp. that we're talking about
>> separate directories), and it is even easier in times of git.
>> 
> One can't coddle someone who's breaking the tree, especially
> when we expect people to test before committing.

Orthogonal to the general discussion, but could be critical for some...

Both the above comments reflect legacy CVS thought patterns in regard to 
commits.  In git, commit != push , and here it's the push, not the 
commit, that's critical and that testing needs done before.

Committing without testing, as long as you don't push, is fine, even 
meritorious.  It's the push that uploads those commits to the gentoo 
reference repo, however, and testing should *definitely* be done before 
pushing, with more commits /before/ the push to fix what the tests found 
to be broken, should they be necessary.

(Tho in keeping with the principle of ultimately atomic commits that 
don't break bisections, if a commit is found to be broken and is then 
fixed by another commit, a rebase to combine the two into one should be 
considered, thus avoiding breakage of bisections ending up with a commit 
between the break and its fix.  Not that bisection is particularly 
practical in the gentoo repo context anyway, but that's a separate 
discussion, and good habits here will carry over to repos where bisection 
is actually practical and critically important.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sonntag, 15. Mai 2016, 11:53:27 schrieb Ryan Hill:
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 

+1

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOMNKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnk+j8P/0EpX59Qy0s6K9kuSvZTkzki
w/P3jDKqfcFSkyZQFBHRXGKkyME/9uvCDxjvUzNlSGaw5Ukvl1CWzFN5Z1sxzLVU
wcu5nMaumt26egFmTliGwIWLXT7dbaqIyprCUPCF2HMbvsSBWKJ0Us+36Saz0NA3
G69ZBuO7Ig8t+yS5pcXkUUy6yqbDL2zaStIDxM5V5N0joVwetKt6CIXWiBMprRGP
L64VPi3FkVuuf4a04HMLzBl27kNRPiCvNMPZlf8Sp5b0ve4C6MapUvJ5BHSX64Hy
CtXEMPHrLtfFPE7fAW7EQlXKSRbpgkw3SIRI+TgpeMbwLaYkPkqf3NH5J3z1Gph+
CIhceVFq5gXexsbo4O3+deRXXSYraEZhZfYJKrXpiwEVVBTEpdtPrugOQoPMRo4H
pAlG8dQA456IqXGS4nur4sRljQg8rhfPnx5/vD6AnD+9gCM0qF9V/GinIBDvXOZd
QPzcaJn14MBS7xvN/jcy3Lf/ZJvjUMqb4MGKvCxvhNUFDIXHWRvqv5br3eMw6JSB
78wmN4kTcfFeQ9ywCChSKZDRZTziLVWifAORSJduGuyP/NthzPFMT3OrYS1Mze8v
JIHB+9HsmCG5RwXuP/DMAb0t0dg6Lbg8qKBtRvsO72/bsVfU50AtDDFXGowaK386
A24gQh9cIvtqRo8lU+nY
=vysH
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

On Sun, 15 May 2016 04:18:39 -0700
Daniel Campbell  wrote:

> On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> > On Sun, 15 May 2016 11:05:21 +0200
> > Jeroen Roovers  wrote:
> >   
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> Michał Górny  wrote:
> >>  
> >>> Do you seriously expect this code to work? How about testing? Or
> >>> reading diffs before committing?
> >>
> >>
> >> Somebody could have a go at implementing this:
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=390651
> >>
> >> It's been brewing for half a decade. Maybe it's time. :)
> >>
> >>
> >> Regards,
> >>  jer
> >>  
> > 
> > With the new repoman code structure, yes, it would be a lot easier
> > to implement.
> > 
> > Also with the gen-b0rk test repo, that will be a good testing ground
> > for eclass changes too.  It just needs more devs to make test
> > ebuilds to get it fully populated ;)
> >   
> What sort of test ebuilds are you looking for? There are a few
> packages I'd like to see get into Gentoo but I don't want to break
> anything. :P
> 

Have a look at the gen-b0rk repo, See how the ebuilds are done, follow
those examples.  There are lots more errors that repoman looks for that
are not yet covered by test ebuilds.

There are a few more in other areas of code, but here is the biggest
list of errors/warnings that repoman can test for.

https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman

-- 
Brian Dolbec 



pgpRMqKiMf0hB.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> On Sun, 15 May 2016 11:05:21 +0200
> Jeroen Roovers  wrote:
> 
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny  wrote:
>>
>>> Do you seriously expect this code to work? How about testing? Or
>>> reading diffs before committing?  
>>
>>
>> Somebody could have a go at implementing this:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=390651
>>
>> It's been brewing for half a decade. Maybe it's time. :)
>>
>>
>> Regards,
>>  jer
>>
> 
> With the new repoman code structure, yes, it would be a lot easier to
> implement.
> 
> Also with the gen-b0rk test repo, that will be a good testing ground
> for eclass changes too.  It just needs more devs to make test ebuilds
> to get it fully populated ;)
> 
What sort of test ebuilds are you looking for? There are a few packages
I'd like to see get into Gentoo but I don't want to break anything. :P

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 03:29 AM, Michał Górny wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman  wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
 On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> On Sat, 7 May 2016 23:25:58 +0200
>
> Michał Górny  wrote:  
>> Do you seriously expect this code to work? How about testing? Or
>> reading diffs before committing?  

 Absolutely nothing wrong was said here.  Obviously the code was not tested
 and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> Since the anti-productivity of this thread is getting impressively high
> even for Gentoo standards, I'd like to point out a few things.
> 
> It was impolite. It was supposed to be. Not offensive but impolite. It
> ain't cool to get responses like this but it ain't cool to break stuff
> like this either.
> 
> For those who don't have a broader view, it wasn't a single commit but
> a followup to a commit adding EAPI=6 support to the eclass -- clearly
> untested. I didn't bother complaining about the first one since issues
> would clearly pop up if someone actually tried to use the eclass
> in EAPI=6. However, the second commit actually introduced a syntax
> error that broke all the ebuilds, including stable and caused metadata
> generation failure. This is real bad.
> 
> Of course, it could have been worse. It looks like no ebuilds with
> EAPI=6 'support' were committed following the eclass. Which is a good
> sign that some testing eventually occurred. However, is it that much of
> an effort to test eclass changes using ebuilds *before* committing it?
> It wasn't that hard even in times of CVS (esp. that we're talking about
> separate directories), and it is even easier in times of git.
> 
> I don't really see the benefit of whole of this discussion. He
> committed a bad thing, I shouted at him, end of story. If you want to
> take it to comrel, just do it. However, discussing whether it was right
> or wrong is really unproductive here.
> 
I felt it was a bit strong, but you make a good case. There certainly is
a balance. One can't coddle someone who's breaking the tree, especially
when we expect people to test before committing. Since it was an eclass,
wasn't that supposed to be discussed on here first, too? Still, we're
going to make mistakes and dressing someone down won't fix it.

When I was adding multilib support to media-sound/apulse I recall you
strongly telling me that I screwed up and it shouldn't have been done
the way I originally committed. There wasn't a nudge in the right
direction, though. I imagine it was clear that I hadn't done multilib
scripts before. If I had been more sensitive or less willing to fix it,
what would have happened? You or someone else may have reverted it
and/or reported to QA and started a ruckus.

I mean, I don't hold a grudge or anything. I'm glad you told me it
wasn't right, because if I'm contributing to Gentoo I want it to be done
well. I learned something from it. But a dev being told that they're
screwing up without also being specific (or at least a hint) about a way
to fix it or *why* it's wrong doesn't help them fix their screw up and
ensure it doesn't happen again.

That sort of criticism, which may be warranted in terms of "they screwed
the tree up due to something stupid!", isn't productive if the dev
doesn't know how to fix it.

This particular screw-up is different since it was simpler, but less
trivial screw ups do happen and without _constructive_ criticism, devs
(and Gentoo, by extension) won't get better.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 02:53 AM, Ryan Hill wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman  wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
 On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> On Sat, 7 May 2016 23:25:58 +0200
>
> Michał Górny  wrote:  
>> Do you seriously expect this code to work? How about testing? Or
>> reading diffs before committing?  

 Absolutely nothing wrong was said here.  Obviously the code was not tested
 and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 
> But if you guys just want to hug it out that's cool too.
> 
I think that depends on history. If the dev in question hasn't done that
before, then it's entirely possible they *thought* they tested, or
tested it *before* making some other edit and absent-mindedly committed.
That's a screw-up, and devs should be notified. Ideally, they should be
told *what* they screwed up and *how* to ensure it doesn't happen again.

Admonishing them as if they were a child is not going to engender
motivation to continue participation. We're all devs because we want to
make Gentoo better (I hope, anyway), and part of that means we'll have
to help each other out sometimes.

There's more to it than coddling vs tearing someone down.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/14/2016 01:23 PM, Rich Freeman wrote:
> On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt  wrote:
>> On 14/05/16 18:52, Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>>>  wrote:
 No fun allowed

>>> Are you saying that you don't want people to have fun developing
>>> Gentoo?  Or are you trying to say that it is impossible to have fun
>>> developing Gentoo without insulting strangers?  I don't think anybody
>>> minds two friends teasing each other.
>>>
>> I think my gut feeling would go "there's a time and a place..." .. and
>> err on the g-dev ML probably not being it .. unless everyone else is in
>> on the 'joke' ..
>>
> 
> Sure, and just to be clear I don't think we should be bothered by
> informality and joking around.  If you have a good relationship with
> somebody and poking at each other is just how you relate, you can get
> away with it.  We shouldn't have to walk on eggshells, but it just
> seems like we get a lot of flames in general going around and IMO at
> least it seems like it makes the distro a bit less fun.
> 
> Of course we shouldn't lower our standards for quality, and I suspect
> that most of the people who do commit mistakes to the tree would
> probably agree, at least when they're sober.  :)
> 

I agree. Some of us have reputations for being hard to work with or
being misunderstood, and it would go a long way for us to try to be
honest and -- for lack of a better word -- nicer. I've not personally
experienced much of that, but I can understand why someone wouldn't want
to work with (on a volunteer basis, of course) someone calling them
stupid or incompetent.

Mistakes happen and I gladly fix anything I've screwed up. I could have
taken some of the criticism personally due to the tone, however, if I
hadn't been 'seasoned' by the Internet to expect the worst.

That said, I like that those of us who are close can joke. We're all
volunteers, so why not have fun *while* we build what we think is the
ideal distro? I don't think quality and fun are mutually exclusive.

"at least when they're sober" -- I had a hearty laugh at that one. :)

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny  wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

Since the anti-productivity of this thread is getting impressively high
even for Gentoo standards, I'd like to point out a few things.

It was impolite. It was supposed to be. Not offensive but impolite. It
ain't cool to get responses like this but it ain't cool to break stuff
like this either.

For those who don't have a broader view, it wasn't a single commit but
a followup to a commit adding EAPI=6 support to the eclass -- clearly
untested. I didn't bother complaining about the first one since issues
would clearly pop up if someone actually tried to use the eclass
in EAPI=6. However, the second commit actually introduced a syntax
error that broke all the ebuilds, including stable and caused metadata
generation failure. This is real bad.

Of course, it could have been worse. It looks like no ebuilds with
EAPI=6 'support' were committed following the eclass. Which is a good
sign that some testing eventually occurred. However, is it that much of
an effort to test eclass changes using ebuilds *before* committing it?
It wasn't that hard even in times of CVS (esp. that we're talking about
separate directories), and it is even easier in times of git.

I don't really see the benefit of whole of this discussion. He
committed a bad thing, I shouted at him, end of story. If you want to
take it to comrel, just do it. However, discussing whether it was right
or wrong is really unproductive here.

-- 
Best regards,
Michał Górny



pgpJldPE9ttEf.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny  wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

I thought his response was pretty tame actually.  If you break the tree
because you couldn't be bothered to do the barest minimum of testing you
absolutely deserve to be called out on it.

But if you guys just want to hug it out that's cool too.

-- 


pgp6v204Sg7ZU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

On Sun, 15 May 2016 11:05:21 +0200
Jeroen Roovers  wrote:

> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny  wrote:
> 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?  
> 
> 
> Somebody could have a go at implementing this:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=390651
> 
> It's been brewing for half a decade. Maybe it's time. :)
> 
> 
> Regards,
>  jer
> 

With the new repoman code structure, yes, it would be a lot easier to
implement.

Also with the gen-b0rk test repo, that will be a good testing ground
for eclass changes too.  It just needs more devs to make test ebuilds
to get it fully populated ;)

-- 
Brian Dolbec 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Jeroen Roovers]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?


Somebody could have a go at implementing this:

https://bugs.gentoo.org/show_bug.cgi?id=390651

It's been brewing for half a decade. Maybe it's time. :)


Regards,
 jer

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 02:04, Rich Freeman wrote:
> On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
>> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>>> On Sun, 15 May 2016 08:40:39 +0900
>>>
>>> Aaron Bauman  wrote:
 Please enlighten me as to what was impolite here?  The strong
 language of "seriously" or definitively stating that the individual
 did not perform the necessary QA actions before committing?  Both of
 which are completely called for and appropriate.  No vulgarity,
 insults, or demeaning words were used. How would you have responded
 professionally?
>>> It's important to remember that Gentoo is run by volunteers. Expecting
>>> a professional standard when it comes to the quality of commit
>>> criticism is unfair.
>> Applying that same rationale, it would be unfair to say that an undescribed
>> level of professionalism in communication is required as well.  Nothing here
>> violates the CoC.
>>
> If you're only able to behave in a professional manner if the
> standards of professionalism are explicitly spelled out, I think
> you're missing the point.
>
> Ultimately it is an attitude.  When you point out a mistake make it
> either about:
> 1.  Helping the person who made the mistake to improve because you
> want to see them make better contributions (which they aren't going to
> do if you drive them off).
> 2.  If you feel that somebody simply isn't going to cut it, then by
> all means report them so that their commit access can be revoked.
>
> Either of these has the potential to make Gentoo better.  Simply
> posting flames isn't likely to change the behavior of people who need
> #2, and it is likely to discourage people who need #1.  Either is
> against all of our interests in making the distro we benefit from
> better.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 01:59, Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman  wrote:
>> Please enlighten me as to what was impolite here?  The strong language of
>> "seriously" or definitively stating that the individual did not perform the
>> necessary QA actions before committing?
> He actually didn't "state" anything at all - he posted a set of
> rhetorical questions.  And the use of "seriously" was inflammatory.
> In fact, if you're trying to avoid injecting passion into a discussion
> it is worth thinking carefully about just about any word ending in
> "ly" that you put into a sentence.  Nine times out of ten the word
> isn't necessary and can cause more harm than good.
>
>> Both of which are completely called
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.
> I disagree.  The tone was uncivil and demeaning.
>
>> How would you have responded professionally?
>>
> How about this:
>
> You inserted this code snippet into the middle of a command line, so
> it is certain to break in either case.  This should have been detected
> during testing; please be sure to test changes to ebuilds/eclasses
> before committing them.  Additionally eclass changes should be
> submitted to the lists for review in any case prior to being
> committed.
>
> Or by all means refer the issue to QA/Comrel if you want to escalate it.
>
> I'm in no way suggesting that we should accept bad commits.  IMO when
> we see bad commits we should:
>
> 1.  Just point them out politely if it is a one-off.  ANYBODY can make
> a mistake.
> 2.  If they're a trend or show signs of bad practices like not testing
> changes then escalate to QA/Comrel.
> 3.  Let QA/Comrel do their job and block commit access or refer the
> dev for more mentoring/etc as appropriate.  Then we actually fix the
> problem instead of just yelling at each other.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>> On Sun, 15 May 2016 08:40:39 +0900
>>
>> Aaron Bauman  wrote:
>> > Please enlighten me as to what was impolite here?  The strong
>> > language of "seriously" or definitively stating that the individual
>> > did not perform the necessary QA actions before committing?  Both of
>> > which are completely called for and appropriate.  No vulgarity,
>> > insults, or demeaning words were used. How would you have responded
>> > professionally?
>>
>> It's important to remember that Gentoo is run by volunteers. Expecting
>> a professional standard when it comes to the quality of commit
>> criticism is unfair.
>
> Applying that same rationale, it would be unfair to say that an undescribed
> level of professionalism in communication is required as well.  Nothing here
> violates the CoC.
>

If you're only able to behave in a professional manner if the
standards of professionalism are explicitly spelled out, I think
you're missing the point.

Ultimately it is an attitude.  When you point out a mistake make it
either about:
1.  Helping the person who made the mistake to improve because you
want to see them make better contributions (which they aren't going to
do if you drive them off).
2.  If you feel that somebody simply isn't going to cut it, then by
all means report them so that their commit access can be revoked.

Either of these has the potential to make Gentoo better.  Simply
posting flames isn't likely to change the behavior of people who need
#2, and it is likely to discourage people who need #1.  Either is
against all of our interests in making the distro we benefit from
better.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman  wrote:
>
> Please enlighten me as to what was impolite here?  The strong language of
> "seriously" or definitively stating that the individual did not perform the
> necessary QA actions before committing?

He actually didn't "state" anything at all - he posted a set of
rhetorical questions.  And the use of "seriously" was inflammatory.
In fact, if you're trying to avoid injecting passion into a discussion
it is worth thinking carefully about just about any word ending in
"ly" that you put into a sentence.  Nine times out of ten the word
isn't necessary and can cause more harm than good.

> Both of which are completely called
> for and appropriate.  No vulgarity, insults, or demeaning words were used.

I disagree.  The tone was uncivil and demeaning.

> How would you have responded professionally?
>

How about this:

You inserted this code snippet into the middle of a command line, so
it is certain to break in either case.  This should have been detected
during testing; please be sure to test changes to ebuilds/eclasses
before committing them.  Additionally eclass changes should be
submitted to the lists for review in any case prior to being
committed.

Or by all means refer the issue to QA/Comrel if you want to escalate it.

I'm in no way suggesting that we should accept bad commits.  IMO when
we see bad commits we should:

1.  Just point them out politely if it is a one-off.  ANYBODY can make
a mistake.
2.  If they're a trend or show signs of bad practices like not testing
changes then escalate to QA/Comrel.
3.  Let QA/Comrel do their job and block commit access or refer the
dev for more mentoring/etc as appropriate.  Then we actually fix the
problem instead of just yelling at each other.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> 
> Aaron Bauman  wrote:
> > Please enlighten me as to what was impolite here?  The strong
> > language of "seriously" or definitively stating that the individual
> > did not perform the necessary QA actions before committing?  Both of
> > which are completely called for and appropriate.  No vulgarity,
> > insults, or demeaning words were used. How would you have responded
> > professionally?
> 
> It's important to remember that Gentoo is run by volunteers. Expecting
> a professional standard when it comes to the quality of commit
> criticism is unfair.

Applying that same rationale, it would be unfair to say that an undescribed 
level of professionalism in communication is required as well.  Nothing here 
violates the CoC.

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:
> Please enlighten me as to what was impolite here?  The strong
> language of "seriously" or definitively stating that the individual
> did not perform the necessary QA actions before committing?  Both of
> which are completely called for and appropriate.  No vulgarity,
> insults, or demeaning words were used. How would you have responded
> professionally?

It's important to remember that Gentoo is run by volunteers. Expecting
a professional standard when it comes to the quality of commit
criticism is unfair.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:
> > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> 
> >> Michał Górny  wrote:
> >> > Do you seriously expect this code to work? How about testing? Or
> >> > reading diffs before committing?
> > 
> > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > and Michal pointed that out very plainly.
> 
> It is actually possible to communicate both plainly and politely at
> the same time.  This does not require sacrificing any commitment to
> quality at all.  Really the only downside is having more of an
> appearance of professionalism.

Please enlighten me as to what was impolite here?  The strong language of 
"seriously" or definitively stating that the individual did not perform the 
necessary QA actions before committing?  Both of which are completely called 
for and appropriate.  No vulgarity, insults, or demeaning words were used.  
How would you have responded professionally?

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt  wrote:
> On 14/05/16 18:52, Rich Freeman wrote:
>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>>  wrote:
>>> No fun allowed
>>>
>> Are you saying that you don't want people to have fun developing
>> Gentoo?  Or are you trying to say that it is impossible to have fun
>> developing Gentoo without insulting strangers?  I don't think anybody
>> minds two friends teasing each other.
>>
> I think my gut feeling would go "there's a time and a place..." .. and
> err on the g-dev ML probably not being it .. unless everyone else is in
> on the 'joke' ..
>

Sure, and just to be clear I don't think we should be bothered by
informality and joking around.  If you have a good relationship with
somebody and poking at each other is just how you relate, you can get
away with it.  We shouldn't have to walk on eggshells, but it just
seems like we get a lot of flames in general going around and IMO at
least it seems like it makes the distro a bit less fun.

Of course we shouldn't lower our standards for quality, and I suspect
that most of the people who do commit mistakes to the tree would
probably agree, at least when they're sober.  :)

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Samstag, 14. Mai 2016, 18:59:02 schrieb M. J. Everitt:
> 
> I think the time is coming, given the diversity of members of this list,
> to add  tags when we are not describing something
> literally. 

wouldnt a  tag be sufficient?

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXN4VVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXskQAJJ6LWQ1b0Ap27SAFGnTIqJb
oYhGf8r3VoOxjVbqOKRVZnOZkudQ5KiURxUv+vAZbbomw4SMiV/gn1T/8V8xafbv
KCL7UJOaW4AXgCZ+dFaV2jjTbVrFSMtvkeKwl3klpqPgylk9Q0Vudm1a058iBPRQ
9VPNX14Ooj3cKyimCYesznwH8cGv7cCUZA/MmjnqCQyKy+N5kxDyKyVdEECQ2bEY
D/YDFoTtizixC8HS/OmOzRfCGRe3aPzHyzOMWL7FgCr9fnOE4METSa2kf9GQgViv
9g3RMfpQ4gudCQ/WcqEVDWUt8XlHxFvwdmleywP+Rh81MbUnkaLCA3dnk2Ev86su
s2g5ltS2ozOlCkeryzenbZ1Ezk66kE6o+lBtC1MGWL5MDZVRZvIM1zCaYEqAwabC
jDikqnGxWT3Lvyi7Jmus1p+vjty2LV00yA0JczED7tXSILUqW9ym2Trm/fAd1O+x
NBMMnrrzWW28lyLFUZ+akRFvR35shE1KiISW7GVoorVKtmL8er6LkxYVkvjYi2Vn
Ze+/mlxHNpJh1KjfQ3MC1MOqJQO3ZeOF0AFMPjxMvHFP+5J52PUdtTQeo68080kr
UpFzlwE4nJj5CxMMYgqn7XVjgoaI/jZKqWdUN2h6cj2OwZIe58rIvKroWnUYaVOD
4IsP85PN+scg0Evuj4wa
=jNhK
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:52, Rich Freeman wrote:
> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>  wrote:
>> No fun allowed
>>
> Are you saying that you don't want people to have fun developing
> Gentoo?  Or are you trying to say that it is impossible to have fun
> developing Gentoo without insulting strangers?  I don't think anybody
> minds two friends teasing each other.
>
I think my gut feeling would go "there's a time and a place..." .. and
err on the g-dev ML probably not being it .. unless everyone else is in
on the 'joke' ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 1:07 PM, landis blackwell
 wrote:
> No fun allowed
>

Are you saying that you don't want people to have fun developing
Gentoo?  Or are you trying to say that it is impossible to have fun
developing Gentoo without insulting strangers?  I don't think anybody
minds two friends teasing each other.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[landis blackwell]

No fun allowed
On May 14, 2016 12:06 PM, "Rich Freeman"  wrote:

> On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt 
> wrote:
> > On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> >> Gordon Pettey schrieb:
> >>
> >>> So, it's perfectly okay to make direct commits of obviously broken
> >>> code that
> >>> has no chance of working, because community something mumble...
> >>
> >> You may have missed some sarcasm in the post which you replied to.
> >> Plus, I don't think anybody said or implied that committing broken
> >> things is ok.
> >>
> >>
> >> Best regards,
> >> Chí-Thanh Christopher Nguyễn
> >>
> > I think the time is coming, given the diversity of members of this list,
> > to add  tags when we are not describing something
> > literally. It becomes very difficult to follow the thread of
> > conversation when people are (not) communicating their true thoughts!!
> >
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
> --
> Rich
>
>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:06, Rich Freeman wrote:
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
+1 .. is it time to add  tags too?! :]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 12:59 PM, M. J. Everitt  wrote:
> On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
>> Gordon Pettey schrieb:
>>
>>> So, it's perfectly okay to make direct commits of obviously broken
>>> code that
>>> has no chance of working, because community something mumble...
>>
>> You may have missed some sarcasm in the post which you replied to.
>> Plus, I don't think anybody said or implied that committing broken
>> things is ok.
>>
>>
>> Best regards,
>> Chí-Thanh Christopher Nguyễn
>>
> I think the time is coming, given the diversity of members of this list,
> to add  tags when we are not describing something
> literally. It becomes very difficult to follow the thread of
> conversation when people are (not) communicating their true thoughts!!
>

While this is certainly sensible, the irony here is that this whole
discussion was started by somebody making a sarcastic remark when
simply pointing out a mistake would have been just as functional.

Nobody thinks it is ok to commit broken code.  What it seems like
we'll be debating until there is only one of us left is how
unprofessional we should be when pointing that out.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> Gordon Pettey schrieb:
>
>> So, it's perfectly okay to make direct commits of obviously broken
>> code that
>> has no chance of working, because community something mumble...
>
> You may have missed some sarcasm in the post which you replied to.
> Plus, I don't think anybody said or implied that committing broken
> things is ok.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
I think the time is coming, given the diversity of members of this list,
to add  tags when we are not describing something
literally. It becomes very difficult to follow the thread of
conversation when people are (not) communicating their true thoughts!!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Chí-Thanh Christopher Nguyễn]

Gordon Pettey schrieb:


So, it's perfectly okay to make direct commits of obviously broken code that
has no chance of working, because community something mumble...


You may have missed some sarcasm in the post which you replied to.
Plus, I don't think anybody said or implied that committing broken things is ok.


Best regards,
Chí-Thanh Christopher Nguyễn



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gordon Pettey]

On Sat, May 14, 2016 at 6:35 AM, Ciaran McCreesh <
ciaran.mccre...@googlemail.com> wrote:

> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
> So, it's perfectly okay to make direct commits of obviously broken code
that has no chance of working, because community something mumble...

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:
> On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny  wrote:
>> >
>> > Do you seriously expect this code to work? How about testing? Or
>> > reading diffs before committing?
>> >
>
> Absolutely nothing wrong was said here.  Obviously the code was not tested and
> Michal pointed that out very plainly.
>

It is actually possible to communicate both plainly and politely at
the same time.  This does not require sacrificing any commitment to
quality at all.  Really the only downside is having more of an
appearance of professionalism.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:
> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny  wrote:
> >
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> >

Absolutely nothing wrong was said here.  Obviously the code was not tested and 
Michal pointed that out very plainly.

> >
> 
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times

In one sentence you question him about putting someone down then in the next 
sentence you say he is lacking a cerebral cortex... hypocritical.

> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Not even really sure what that means?  dead cvs?

> 

> --
> kind regards
> 
> Ian Delaney


-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 12:35, Ciaran McCreesh wrote:
> On Sat, 14 May 2016 11:55:42 +0200
>> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
>>> On Sat, 7 May 2016 23:25:58 +0200  
 Do you seriously expect this code to work? How about testing? Or
 reading diffs before committing?  
>>> Do you seriously expect us to sit and absorb this form of pious
>>> put down? From one who knows far better who is entitled to speak
>>> down to colleagues as is completely lacking a cerebral cortex?
>>> Those times are drawing to an end. Did anyone ever teach you to
>>> treat folk in such manner and expect them to respect it? I don't
>>> think so Not over my dead cvs perhaps  
>> Well, we still do need some commit quality, you know...
> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
In defense of Gentoo at large .. the entry-level to contribute is really
quite low .. and all the documentation for gentoo 'standards' is widely
documented in both the Devmanual (under revision currently) and the
Package Manager Spec. Not only this, but there are active projects
within gentoo to welcome, nurture and develop devs and contributors
alike so that there is a sustainable level of man-power available to
keep up with the demands of users and pace of code development. Ok, it
can be off-putting to those looking in from the outside, but really I
think it benefits more than it costs.

I agree broadly with the ethos of the QA team, gentoo tends to focus on
quality over quantity where commits are concerned. It's better to retain
a stable, reliable set of packages, with additional untested/unstable
packages available via overlays, rather than a massive, unwieldy number
of packages in a broadly unknown state. As it is, there is a deficit of
active people maintaining the less-widely used packages, and also people
able to add new packages to the tree, and this means that resources are
inevitably spread more thinly.

As always there will be a balance, but this thread did start out with
some tit-for-tat between devs, totally unnecessary either in private or
public. So, ditch that bike-shed, and get on with fixing bugs, closing
issues, adding, updating and deprecating packages, folks :]. Thank you.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Sat, 14 May 2016 11:55:42 +0200
> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> > On Sat, 7 May 2016 23:25:58 +0200  
> > > Do you seriously expect this code to work? How about testing? Or
> > > reading diffs before committing?  
> > 
> > Do you seriously expect us to sit and absorb this form of pious
> > put down? From one who knows far better who is entitled to speak
> > down to colleagues as is completely lacking a cerebral cortex?
> > Those times are drawing to an end. Did anyone ever teach you to
> > treat folk in such manner and expect them to respect it? I don't
> > think so Not over my dead cvs perhaps  
> 
> Well, we still do need some commit quality, you know...

Why? Gentoo is about the community. Requiring a basic standard of commit
quality a) reduces the number of community members who are able to
contribute, 2) leads to fewer forums posts discussing how to fix
problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
volume of commits, and fourthly, discriminates unfairly against
competency-challenged developers by imposing subjective interpretations
of the value of source code from a position of unearned authority. This
is against the code of conduct, and is bad for the community!

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
> On Sat, 7 May 2016 23:25:58 +0200

> > 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?
> 
> Do you seriously expect us to sit and absorb this form of pious
> put down? From one who knows far better who is entitled to speak down
> to colleagues as is completely lacking a cerebral cortex? Those times
> are drawing to an end. Did anyone ever teach you to treat folk in such
> manner and expect them to respect it? I don't think so
> Not over my dead cvs perhaps

Well, we still do need some commit quality, you know...

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXNvYeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXA4P/jDuTHnBkZfkzwjIbk6ZTi8J
/sb/ypGT3h+tXUoYei2978drsF091WnDU6H+RCj3Lk4LKtPR6pMzL9OEXdihQqJh
+OSZgh1T3pZJAjRWAVeXjgGmSlW9Pmxfnb1G9D9Zv+58cRohQhbZZG3baXih3QBY
2umIqYKgfbq+whtr49YYPVU6mVovQ8esWCAZWw5+vYqw2/9MDIUl4wWJVlDXgo7l
Bmb2t5XudJ5lApfDGhOSaxi2lacPK2WggAlN2XmG5MkjPuQAauEQly8MhxlSUQxX
Q8ZAyqzokPENXq0C+PwrF9TGBaFAQjMAnCLP7F4eo8jDqfsPhTxcthNQRhYXFpx6
/5aXEBb4DZwTOust9hdBUvUM5pUo7P9IyoBVGQdejo87YrLxy1MI0/J2E+GrRQfM
HNRdAwRrhUpQrF6sCyD5mH7uVWdVwdhIY70Lau4d8HIP/J5TRN2FwP7F2zqjjQmz
lUj20/meBvgHlGUgjsi2sb15HLwx2E2OkMrxhYcuE9JuBiaomBnz+OpSlzp2wGwR
X1rXBVz/nvn2nVTH75QybLcjvTO9FfdfGFEGOrjQ/f68sTHpcat+Co9wJjYgD/LA
EtUomNUkIFGcMJAyOBgdgZDiYREFXnlW1FlB94VS4SgcPpkcvxKBruM+DcJDgZ+h
/F5kkAuRtmOsXBN2e1MT
=5e68
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ian Delaney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel"  wrote:
> 
> > commit: 66afcab271f65b97330e610040ad3acc1b812a03
> > Author: Joerg Bornkessel  gentoo  org>
> > AuthorDate: Sat May  7 21:18:48 2016 +
> > Commit: Joerg Bornkessel  gentoo  org>
> > CommitDate: Sat May  7 21:18:48 2016 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> > 
> > fixed einstall vs. emake install for eapi=6
> > 
> >  eclass/vdr-plugin-2.eclass | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> > local SOFILE_STRING=$(grep SOFILE Makefile)
> > if [[ -n ${SOFILE_STRING} ]]; then
> > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
> > }}
> > -   einstall ${BUILD_PARAMS} \
> > +   if [[ ${EAPI} == 6 ]]; then
> > +   emake install ${BUILD_PARAMS} \
> > +   else
> > +   einstall ${BUILD_PARAMS} \
> > +   fi
> > ${BUILD_TARGETS} \
> > TMPDIR="${T}" \
> > DESTDIR="${D}" \
> >   
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Do you seriously expect us to sit and absorb this form of pious
put down? From one who knows far better who is entitled to speak down
to colleagues as is completely lacking a cerebral cortex? Those times
are drawing to an end. Did anyone ever teach you to treat folk in such
manner and expect them to respect it? I don't think so
Not over my dead cvs perhaps

- -- 
kind regards

Ian Delaney
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXNZW5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw
QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6mzcP/1BmrZw/EiuPlJh6MuufJ1/U
Zlg26d99Vvvji0VVHcz9lrDhk6ubYB3WrcrG3E2M1pVwXDTuy+z5ez7RXvuUMSSY
XiP4uWVWmlQoBlkAzAAvzKKVNsQvfOCif1x/b59Qjm9qAKQOwawTzCjOCHIrB08V
EXFuuo5gpHfkq5vtU7jK22/6Zo56w+A7xfgSKl96byepA4F++3vDH4kX3XTBVmtE
vlPn230CQqgP/YMZ/TBcQ4AE3r0fxPmGnAniZn/o5v2Zpzo1SZjrRlYJXDq3PnIa
Rjs6fWEvfA7xu8wDt05Xz+8bzVXmS//1ga0VB1dmcNlVelUY7Pwi1kR+nUF174Vo
/xLlTvK/EboliAMbviRwX9extWycWCB+iyBH/RkazaQQmSiW5tHlVPx8Wu7LiRay
O8eFks7LgenetNBymMaiPBNZJMo/I+Fnebk43qx0XfUyuANLsg3JnsY4WG+Evcjc
3XqkTePuDyFLQEgQlU417JSFRkyZ0odMqpVShqOxgv4EA/HAiCpWCHkE1ZuiLi1V
7bKQodOclD3jTmy6eJgLpoEhqphXCaX9bl5QcFyu3+La8r3YXOqErCbOECoJy0Np
lXwOCKZ9kvcv8iLygxKqP/0rxuAP0kzs5NSWd2zhHLRBihNvP+xkc2Pi4ztRT2LN
Hju+wa0/WdLLTEPCAe78
=4iJI
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Doug Goldstein]

On 5/7/16 4:25 PM, Michał Górny wrote:
> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel"  wrote:
> 
>> commit: 66afcab271f65b97330e610040ad3acc1b812a03
>> Author: Joerg Bornkessel  gentoo  org>
>> AuthorDate: Sat May  7 21:18:48 2016 +
>> Commit: Joerg Bornkessel  gentoo  org>
>> CommitDate: Sat May  7 21:18:48 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
>>
>> fixed einstall vs. emake install for eapi=6
>>
>>  eclass/vdr-plugin-2.eclass | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
>> index ae09a34..65f1409 100644
>> --- a/eclass/vdr-plugin-2.eclass
>> +++ b/eclass/vdr-plugin-2.eclass
>> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>>  local SOFILE_STRING=$(grep SOFILE Makefile)
>>  if [[ -n ${SOFILE_STRING} ]]; then
>>  BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
>> }}
>> -einstall ${BUILD_PARAMS} \
>> +if [[ ${EAPI} == 6 ]]; then
>> +emake install ${BUILD_PARAMS} \
>> +else
>> +einstall ${BUILD_PARAMS} \
>> +fi
>>  ${BUILD_TARGETS} \
>>  TMPDIR="${T}" \
>>  DESTDIR="${D}" \
>>
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Michal,

How about trying a different tone?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel"  wrote:
> 
> > commit: 66afcab271f65b97330e610040ad3acc1b812a03
> > Author: Joerg Bornkessel  gentoo  org>
> > AuthorDate: Sat May  7 21:18:48 2016 +
> > Commit: Joerg Bornkessel  gentoo  org>
> > CommitDate: Sat May  7 21:18:48 2016 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> > 
> > fixed einstall vs. emake install for eapi=6
> > 
> >  eclass/vdr-plugin-2.eclass | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> > index ae09a34..65f1409 100644
> > --- a/eclass/vdr-plugin-2.eclass
> > +++ b/eclass/vdr-plugin-2.eclass
> > @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
> > local SOFILE_STRING=$(grep SOFILE Makefile)
> > if [[ -n ${SOFILE_STRING} ]]; then
> > BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
> > }}
> > -   einstall ${BUILD_PARAMS} \
> > +   if [[ ${EAPI} == 6 ]]; then
> > +   emake install ${BUILD_PARAMS} \
> > +   else
> > +   einstall ${BUILD_PARAMS} \
> > +   fi
> > ${BUILD_TARGETS} \
> > TMPDIR="${T}" \
> > DESTDIR="${D}" \
> >   
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?

I reverted this commit since it broke sourcing any ebuild inheriting the eclass.

I'm going to assume this commit was made by accident, since any dev that would
commit code to an eclass without testing that it works, or even that it's
_valid bash_, would not continue to have unsupervised commit rights for very
long.


-- 


pgpJLToyOs0hS.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Sat,  7 May 2016 21:19:31 + (UTC)
"Joerg Bornkessel"  wrote:

> commit: 66afcab271f65b97330e610040ad3acc1b812a03
> Author: Joerg Bornkessel  gentoo  org>
> AuthorDate: Sat May  7 21:18:48 2016 +
> Commit: Joerg Bornkessel  gentoo  org>
> CommitDate: Sat May  7 21:18:48 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
> 
> fixed einstall vs. emake install for eapi=6
> 
>  eclass/vdr-plugin-2.eclass | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
> index ae09a34..65f1409 100644
> --- a/eclass/vdr-plugin-2.eclass
> +++ b/eclass/vdr-plugin-2.eclass
> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>   local SOFILE_STRING=$(grep SOFILE Makefile)
>   if [[ -n ${SOFILE_STRING} ]]; then
>   BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
> }}
> - einstall ${BUILD_PARAMS} \
> + if [[ ${EAPI} == 6 ]]; then
> + emake install ${BUILD_PARAMS} \
> + else
> + einstall ${BUILD_PARAMS} \
> + fi
>   ${BUILD_TARGETS} \
>   TMPDIR="${T}" \
>   DESTDIR="${D}" \
> 

Do you seriously expect this code to work? How about testing? Or
reading diffs before committing?

-- 
Best regards,
Michał Górny



pgp43fHBS5xV8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Luca Barbato]

On 18/04/16 00:50, Anthony G. Basile wrote:

> Does base-system object if I bump it to EAPI=5 before I commit the
> ssl-cert patch?  I'll start stabilization too obviously.
> 

Please do.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/17/16 4:28 AM, Anthony G. Basile wrote:
> On 4/17/16 4:15 AM, Fabian Groffen wrote:
>> On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
>>> Congratulations! You've just committed an invalid dependency that is
>>> going to cause true mayhem on every package using the eclass.
>>
>> I assume you've taken proper actions to mitigate this.
>>
>>> But why would anyone send patches for review, or even start wondering
>>> that we might be using USE=libressl all around for some reason...
>>
>> While I believe your point is right (patches for review), I think this
>> style of communication is unnecessary.
> 
> In case you haven't been following the other communications regarding
> the matter, the USE flag is not necessary here because ssl-cert.eclass
> does not involve any linking against openssl/libressl.  So I'll be
> recommitting the original patch without the slot operator.
> 
> The original patch is at
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f
> 
> plus s/:0=/:0/
> 
>>
>> Thanks,
>> Fabian
>>
> 
> 

mgorny suggested that i look for any EAPI=0 ebuild inheriting
ssl-cert.eclass.  I hacked up the following:

import portage

portdb = portage.db["/"]["porttree"].dbapi
gentoo_repo_location = portdb.repositories["gentoo"].location

for cp in portdb.cp_all(trees=[gentoo_repo_location]):
for cpv in portdb.cp_list(cp, mytree=gentoo_repo_location):
eapi, inherited = portdb.aux_get(cpv, ["EAPI", "INHERITED"],
myrepo="gentoo")
if eapi == '0' and 'ssl-cert' in inherited.split():
print(cpv)

and found net-ftp/netkit-ftpd-0.17-r8.  Its pretty ancient and belongs
to base system.

Does base-system object if I bump it to EAPI=5 before I commit the
ssl-cert patch?  I'll start stabilization too obviously.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/17/16 4:15 AM, Fabian Groffen wrote:
> On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
>> Congratulations! You've just committed an invalid dependency that is
>> going to cause true mayhem on every package using the eclass.
> 
> I assume you've taken proper actions to mitigate this.
> 
>> But why would anyone send patches for review, or even start wondering
>> that we might be using USE=libressl all around for some reason...
> 
> While I believe your point is right (patches for review), I think this
> style of communication is unnecessary.

In case you haven't been following the other communications regarding
the matter, the USE flag is not necessary here because ssl-cert.eclass
does not involve any linking against openssl/libressl.  So I'll be
recommitting the original patch without the slot operator.

The original patch is at

https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/ssl-cert.eclass?id=7a4d6bd5fcb25d8381bc08e20ad6a5c1c80ad78f

plus s/:0=/:0/

> 
> Thanks,
> Fabian
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Fabian Groffen]

On 16-04-2016 21:05:56 +0200, Michał Górny wrote:
> Congratulations! You've just committed an invalid dependency that is
> going to cause true mayhem on every package using the eclass.

I assume you've taken proper actions to mitigate this.

> But why would anyone send patches for review, or even start wondering
> that we might be using USE=libressl all around for some reason...

While I believe your point is right (patches for review), I think this
style of communication is unnecessary.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 6:46 PM, Mike Gilbert wrote:
> On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman  wrote:
>> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert  wrote:
>>>
>>> And I don't really see the point in the libressl USE flag in this
>>> case; I think that was only needed so the slot-operator would resolve
>>> correctly.
>>>
>>
>> Somebody else may be better informed, but I thought that there was a
>> concern with having both libressl and openssl linked into two
>> libraries that are in turn linked to by something else (causing a
>> symbol collision), and the USE flag was necessary to switch between
>> the two implementations since they aren't virtualized.
>>
>> If we've solved that problem in some other way then by all means say
>> so.  However, I thought this was the main tradeoff in letting it use
>> the same soname.
> 
> This eclass doesn't build/link anything. It just calls /usr/bin/openssl.
> 

You still need to be able to tell the difference between
dev-libs/{open,libre}ssl;

# openssl version
LibreSSL 2.2.6


# openssl version
OpenSSL 1.0.2g  1 Mar 2016

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 6:36 PM, Rich Freeman wrote:
> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert  wrote:
>>
>> And I don't really see the point in the libressl USE flag in this
>> case; I think that was only needed so the slot-operator would resolve
>> correctly.
>>
> 
> Somebody else may be better informed, but I thought that there was a
> concern with having both libressl and openssl linked into two
> libraries that are in turn linked to by something else (causing a
> symbol collision), and the USE flag was necessary to switch between
> the two implementations since they aren't virtualized.
> 
> If we've solved that problem in some other way then by all means say
> so.  However, I thought this was the main tradeoff in letting it use
> the same soname.
> 

I was reasoning along the lines of Mike when I first committed this.
The eclass simply provides a series of functions for generating certs.
It is sufficient that the `openssl` utility be present whether its
provided by dev-libs/openssl or dev-libs/libressl.  You're not linking
against it so the ABI issue is a non-issue.  As far as being able to
tell the difference between the two, you can use `openssl version`.

The slot operator was more subtle.  I'm aware that := only means
something in RDEPENDs but people do RDEPEND="${DEPEND} ..." often and so
as a precaution, I included it.  However, the scope of DEPEND does not
cross the eclass-ebuild boundary and since there is no RDEPEND in that
eclass, its wrong to have :0= there.  :0 is sufficient.  inherit() in
ebuild.sh scrubs the value of DEPEND, so its not as simple as just "source".

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Sat, Apr 16, 2016 at 6:36 PM, Rich Freeman  wrote:
> On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert  wrote:
>>
>> And I don't really see the point in the libressl USE flag in this
>> case; I think that was only needed so the slot-operator would resolve
>> correctly.
>>
>
> Somebody else may be better informed, but I thought that there was a
> concern with having both libressl and openssl linked into two
> libraries that are in turn linked to by something else (causing a
> symbol collision), and the USE flag was necessary to switch between
> the two implementations since they aren't virtualized.
>
> If we've solved that problem in some other way then by all means say
> so.  However, I thought this was the main tradeoff in letting it use
> the same soname.

This eclass doesn't build/link anything. It just calls /usr/bin/openssl.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, Apr 16, 2016 at 6:24 PM, Mike Gilbert  wrote:
>
> And I don't really see the point in the libressl USE flag in this
> case; I think that was only needed so the slot-operator would resolve
> correctly.
>

Somebody else may be better informed, but I thought that there was a
concern with having both libressl and openssl linked into two
libraries that are in turn linked to by something else (causing a
symbol collision), and the USE flag was necessary to switch between
the two implementations since they aren't virtualized.

If we've solved that problem in some other way then by all means say
so.  However, I thought this was the main tradeoff in letting it use
the same soname.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Mike Gilbert]

On Sat, Apr 16, 2016 at 3:31 PM, Anthony G. Basile  wrote:
> On 4/16/16 3:27 PM, Anthony G. Basile wrote:
>> On 4/16/16 3:05 PM, Michał Górny wrote:
>>> On Sat, 16 Apr 2016 19:01:02 + (UTC)
>>> "Anthony G. Basile"  wrote:
>>
>> Okay for review.  Sorry for the wrap.
>>
>> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
>> index 002de76..fc2debd 100644
>> --- a/eclass/ssl-cert.eclass
>> +++ b/eclass/ssl-cert.eclass
>> @@ -30,10 +30,10 @@
>>
>>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>> if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
>> -   DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
>> +   DEPEND="${SSL_CERT_USE}? ( !libressl? (
>> dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
>> IUSE="${SSL_CERT_USE}"
>> else
>> -   DEPEND="dev-libs/openssl:0="
>> +   DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
>> dev-libs/librssl:0= )"
>> fi
>>  fi
>>
>>
>>
>
> Actually the eclass also needs IUSE="${IUSE} libressl"

As discussed in IRC, the slot-operator is unneeded, and has been removed.

And I don't really see the point in the libressl USE flag in this
case; I think that was only needed so the slot-operator would resolve
correctly.

My suggestion would be this:

DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0 dev-libs/libressl:0 ) )"

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:18 PM, Anthony G. Basile wrote:
> On 4/16/16 3:16 PM, Rich Freeman wrote:
>> On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny  wrote:
>>>
>>> Congratulations! ... But why would anyone...
>>
>> Not really picking on you in particular, but this is not the first
>> snarky comment on a commit we've seen today.
>>
>> If somebody makes a mistake, just point it out.  I think we can all
>> appreciate that glibc shouldn't break even in ~arch, and that libressl
>> needs a USE flag due to the whole ABI situation.
>>
>> I can't remember the last time I just factually pointed out a mistake
>> to somebody that they didn't just fix it.  When there are real
>> controversies then there are ways to escalate.  We don't need to
>> manufacture them out of accidents.
>>
> 
> I know it will cause rebuild but we are moving towards openssl:0=
> dependency.  Please look at the discussion on bug #569112.
> 

Sorry I originally thought mgorny was referring to the added slot
operators, but he meant the USE flags.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:27 PM, Anthony G. Basile wrote:
> On 4/16/16 3:05 PM, Michał Górny wrote:
>> On Sat, 16 Apr 2016 19:01:02 + (UTC)
>> "Anthony G. Basile"  wrote:
> 
> Okay for review.  Sorry for the wrap.
> 
> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
> index 002de76..fc2debd 100644
> --- a/eclass/ssl-cert.eclass
> +++ b/eclass/ssl-cert.eclass
> @@ -30,10 +30,10 @@
> 
>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
> if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
> -   DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
> +   DEPEND="${SSL_CERT_USE}? ( !libressl? (
> dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
> IUSE="${SSL_CERT_USE}"
> else
> -   DEPEND="dev-libs/openssl:0="
> +   DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
> dev-libs/librssl:0= )"
> fi
>  fi
> 
> 
> 

Actually the eclass also needs IUSE="${IUSE} libressl"

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:05 PM, Michał Górny wrote:
> On Sat, 16 Apr 2016 19:01:02 + (UTC)
> "Anthony G. Basile"  wrote:

Okay for review.  Sorry for the wrap.

diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 002de76..fc2debd 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -30,10 +30,10 @@

 if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
-   DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
+   DEPEND="${SSL_CERT_USE}? ( !libressl? (
dev-libs/openssl:0= ) libressl? ( dev-libs/librssl:0= ) )"
IUSE="${SSL_CERT_USE}"
else
-   DEPEND="dev-libs/openssl:0="
+   DEPEND="!libressl? ( dev-libs/openssl:0= ) libressl? (
dev-libs/librssl:0= )"
fi
 fi



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:16 PM, Rich Freeman wrote:
> On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny  wrote:
>>
>> Congratulations! ... But why would anyone...
> 
> Not really picking on you in particular, but this is not the first
> snarky comment on a commit we've seen today.
> 
> If somebody makes a mistake, just point it out.  I think we can all
> appreciate that glibc shouldn't break even in ~arch, and that libressl
> needs a USE flag due to the whole ABI situation.
> 
> I can't remember the last time I just factually pointed out a mistake
> to somebody that they didn't just fix it.  When there are real
> controversies then there are ways to escalate.  We don't need to
> manufacture them out of accidents.
> 

I know it will cause rebuild but we are moving towards openssl:0=
dependency.  Please look at the discussion on bug #569112.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sat, Apr 16, 2016 at 3:05 PM, Michał Górny  wrote:
>
> Congratulations! ... But why would anyone...

Not really picking on you in particular, but this is not the first
snarky comment on a commit we've seen today.

If somebody makes a mistake, just point it out.  I think we can all
appreciate that glibc shouldn't break even in ~arch, and that libressl
needs a USE flag due to the whole ABI situation.

I can't remember the last time I just factually pointed out a mistake
to somebody that they didn't just fix it.  When there are real
controversies then there are ways to escalate.  We don't need to
manufacture them out of accidents.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Anthony G. Basile]

On 4/16/16 3:05 PM, Michał Górny wrote:
> On Sat, 16 Apr 2016 19:01:02 + (UTC)
> "Anthony G. Basile"  wrote:
> 
>> commit: ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a
>> Author: Anthony G. Basile  gentoo  org>
>> AuthorDate: Sat Apr 16 19:08:23 2016 +
>> Commit: Anthony G. Basile  gentoo  org>
>> CommitDate: Sat Apr 16 19:08:23 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2
>>
>> ssl-cert.eclass: add libressl support
>>
>>  eclass/ssl-cert.eclass | 12 
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
>> index 002de76..2538f4d 100644
>> --- a/eclass/ssl-cert.eclass
>> +++ b/eclass/ssl-cert.eclass
>> @@ -30,10 +30,10 @@
>>  
>>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>>  if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
>> -DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
>> +DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= 
>> dev-libs/libressl:0= ) )"
>>  IUSE="${SSL_CERT_USE}"
>>  else
>> -DEPEND="dev-libs/openssl:0="
>> +DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )"
>>  fi
>>  fi
>>  
> 
> Congratulations! You've just committed an invalid dependency that is
> going to cause true mayhem on every package using the eclass.
> 
> But why would anyone send patches for review, or even start wondering
> that we might be using USE=libressl all around for some reason...
> 

It was discussed on the bug report and I asked robbat2.  Revert then.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Sat, 16 Apr 2016 19:01:02 + (UTC)
"Anthony G. Basile"  wrote:

> commit: ad0c2ab2bdbd34f4550e49c56cfd5974d6a2c07a
> Author: Anthony G. Basile  gentoo  org>
> AuthorDate: Sat Apr 16 19:08:23 2016 +
> Commit: Anthony G. Basile  gentoo  org>
> CommitDate: Sat Apr 16 19:08:23 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad0c2ab2
> 
> ssl-cert.eclass: add libressl support
> 
>  eclass/ssl-cert.eclass | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
> index 002de76..2538f4d 100644
> --- a/eclass/ssl-cert.eclass
> +++ b/eclass/ssl-cert.eclass
> @@ -30,10 +30,10 @@
>  
>  if [[ "${SSL_DEPS_SKIP}" == "0" ]]; then
>   if [[ "${SSL_CERT_MANDATORY}" == "0" ]]; then
> - DEPEND="${SSL_CERT_USE}? ( dev-libs/openssl:0= )"
> + DEPEND="${SSL_CERT_USE}? ( || ( dev-libs/openssl:0= 
> dev-libs/libressl:0= ) )"
>   IUSE="${SSL_CERT_USE}"
>   else
> - DEPEND="dev-libs/openssl:0="
> + DEPEND="|| ( dev-libs/openssl:0= dev-libs/libressl:0= )"
>   fi
>  fi
>  

Congratulations! You've just committed an invalid dependency that is
going to cause true mayhem on every package using the eclass.

But why would anyone send patches for review, or even start wondering
that we might be using USE=libressl all around for some reason...

-- 
Best regards,
Michał Górny



pgprh0pqHqBOU.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Sun, 22 Nov 2015 08:27:47 + (UTC)
"Michael Sterrett"  wrote:

> commit: a144d7480f781f21323943d87e6a56136add3830
> Author: Michael Sterrett  gentoo  org>
> AuthorDate: Sun Nov 22 08:26:57 2015 +
> Commit: Michael Sterrett  gentoo  org>
> CommitDate: Sun Nov 22 08:27:35 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a144d748
> 
> Stop inheriting base.eclass (bug #494208)
> 
>  eclass/games.eclass | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/games.eclass b/eclass/games.eclass
> index 7d231e1..aebf679 100644
> --- a/eclass/games.eclass
> +++ b/eclass/games.eclass
> @@ -24,11 +24,11 @@
>  if [[ -z ${_GAMES_ECLASS} ]]; then
>  _GAMES_ECLASS=1
>  
> -inherit base multilib toolchain-funcs eutils user
> +inherit multilib toolchain-funcs eutils user

This changes API in all existing eclasses. In paricular, src_unpack()
and src_prepare() stop being implicitly exported which can cause them
to being implicitly replaced by another eclass. Which is especially
relevant since you specifically required people to inherit games.eclass
last and force its overrides.

>  case ${EAPI:-0} in
>   0|1) EXPORT_FUNCTIONS pkg_setup src_compile pkg_preinst pkg_postinst ;;
> - 2|3|4|5) EXPORT_FUNCTIONS pkg_setup src_configure src_compile 
> pkg_preinst pkg_postinst ;;
> + 2|3|4|5|6) EXPORT_FUNCTIONS pkg_setup src_configure src_compile 
> pkg_preinst pkg_postinst ;;

This is irrelevant change and belongs in a separate commit.
Furthermore, I don't think it is appropriate to enable new EAPI support
until you perform the eclass changes requested by the Council.

>   *) die "no support for EAPI=${EAPI} yet" ;;
>  esac
>  
> @@ -302,12 +302,14 @@ games_src_configure() {
>  
>  # @FUNCTION: games_src_compile
>  # @DESCRIPTION:
> -# Runs base_src_make(). This function is exported as src_compile().
> +# This function is exported as src_compile().
>  games_src_compile() {
>   case ${EAPI:-0} in
>   0|1) games_src_configure ;;
>   esac
> - base_src_make
> + if [[ -f Makefile || -f GNUmakefile || -f makefile ]]; then
> + emake "$@" || die
> + fi
>  }
>  
>  # @FUNCTION: games_pkg_preinst
> 

I'm going to revert this commit on behalf of QA to avoid breakage.
The relevant bug specifically mentioned making the change conditional
to EAPI 6. Please either do that (and don't enable EAPI 6 until you
have performed all requested changes), or confirm that none of
the packages will be broken by removing it retroactively.

-- 
Best regards,
Michał Górny



pgpCgD1ysnvnc.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Tue, Nov 17, 2015 at 3:37 PM, Raymond Jennings  wrote:
> As a possibly relevant side note, I've observed how api changes are handled
> in the linux kernel:
>
> You can change whatever you want if it's a good idea, but as part of proving
> it, you have to be willing to take over the warranty for anything you break.
>
> So basically you change what you please ONLY if you also take the burden of
> fixing everything that depended on what you screwed with.
>
> Is this how things are handled by gentoo as well?
>

For the most part, yes, though sometimes changes are posted well in
advance with the goal of getting everybody to pitch in.

This is why a change like this was implemented with an EAPI change.
There is no retroactive impact of the change, so nothing in the tree
is affected.  Developers just have to fix their ebuilds before they
move to the new EAPI.

-- 
Rich