date:20140812

William Hubbs:
 On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
  
  *snip*
 
 These links might be helpful:

 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914

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

 http://comments.gmane.org/gmane.linux.gentoo.devel/80786


 What's still missing is a patch for devmanual (if we still really want
 to enforce this).
 
 I read the thread, and there was no concensus about making this a
 repoman check. Some people thought it was a good idea, but there was a
 feeling that this sort of thing is trivial and shouldn't be worried
 about.
 

That thread is pretty odd.

First, a sentence does not need to have a predicate. I know that for 99%
sure in german and the english wikipedia article seems to suggest the
same. Correct me if I am wrong.

Second, there are valid descriptions that are full ordinary sentences
without referencing ${PN}:
Access a working SSH implementation by means of a library.

In addition, repoman doesn't check for full sentences that reference
${PN}, such as:
Portage is the package management and distribution system for Gentoo.

So we have another (useless) repoman warning with false positives.

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

2014-08-12 Thread Rich Freeman

On Tue, Aug 12, 2014 at 8:47 AM, hasufell hasuf...@gentoo.org wrote:

 First, a sentence does not need to have a predicate. I know that for 99%
 sure in german and the english wikipedia article seems to suggest the
 same. Correct me if I am wrong.


In English your typical English class would teach that every sentence
must have a predicate.  From what Google tells me it technically isn't
entirely true, but every sentence generally does contain a verb.  So,
library that implements SSL is not a sentence under any
circumstances.

 Second, there are valid descriptions that are full ordinary sentences
 without referencing ${PN}:
 Access a working SSH implementation by means of a library.

 In addition, repoman doesn't check for full sentences that reference
 ${PN}, such as:
 Portage is the package management and distribution system for Gentoo.

 So we have another (useless) repoman warning with false positives.


Yeah, at best this seems a bit trivial.  Do we have a policy that
descriptions aren't allowed to be complete sentences?  Many of our
developers are not native English speakers in the first place, so
striving for grammatical perfection is a bit optimistic.  On top of
that, repoman certainly isn't a native English speaker, so expecting
it to achieve grammatical perfection is a really tall order.  And
please don't suggest making languagetool a dependency for portage...

I don't have a problem with QA recommending new tree policies, but if
they're going to do this the QA team ought to first ensure that the
team agrees (however they want to govern that), and then communicate
the policy before implementing it.  I'd also implement it in
documentation before doing so in repoman, otherwise we're going to
have a repoman full of 800 rules whose origin is a mystery.  I'm fine
with QA policies going into effect by default, but communicating them
allows objections to be raised and an appeal made to Council if
necessary before we get too far along.  This isn't just about due
process - it is hard for developers to even comply with a policy they
are unaware of.

Rich

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/14 08:47 AM, hasufell wrote:
William Hubbs:
On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512

*snip*

These links might be helpful:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914

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

http://comments.gmane.org/gmane.linux.gentoo.devel/80786

What's still missing is a patch for devmanual (if we still
really want to enforce this).

I read the thread, and there was no concensus about making this
a repoman check. Some people thought it was a good idea, but
there was a feeling that this sort of thing is trivial and
shouldn't be worried about.

That thread is pretty odd.

First, a sentence does not need to have a predicate. I know that
for 99% sure in german and the english wikipedia article seems to
suggest the same. Correct me if I am wrong.

Second, there are valid descriptions that are full ordinary
sentences without referencing ${PN}: Access a working SSH
implementation by means of a library.

In addition, repoman doesn't check for full sentences that
reference ${PN}, such as: Portage is the package management and
distribution system for Gentoo.

So we have another (useless) repoman warning with false positives.

TL;DR -- is there any technical reason as to why a DESCRIPTION ending
in '.' is bad? Other than the fact that it adds 3000 unnecessary
bytes to the portage tree? IE, does it have the possibility of
throwing off tools that strictly adhere to some random spec (although
it doesn't seem like PMS declares anything bad about this either)??

Perhaps we need to have a less-important repoman warning level
(something that can be quieted with a flag) for things like this? In
terms of DESCRIPTION consistency I don't see it being a bad thing that
we have the warning, but i also don't see a point in changing the
entire tree to get rid of 3000 bytes, esp. since the ChangeLog entries
added to the tree will add at least 30,000 bytes :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqHIYACgkQ2ugaI38ACPCvXQD7BQYtciffNZDCM03vMSlNAgQh
s4j3dw3tL9VDe/oiq7kA/25lVdaRqAc/mbdiI5surUOG9a0J+1sk/nrVft4ocnSs
=8273
-END PGP SIGNATURE-

[gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/14 09:54 AM, Ian Stakenvicius wrote:
 
 Perhaps we need to have a less-important repoman warning level 
 (something that can be quieted with a flag) for things like this?
 In terms of DESCRIPTION consistency I don't see it being a bad
 thing that we have the warning, but i also don't see a point in
 changing the entire tree to get rid of 3000 bytes, esp. since the
 ChangeLog entries added to the tree will add at least 30,000 bytes
 :)
 

I'm wondering what everyone thinks of having a --nonag option to
repoman and shoving some of the more trivial/style-related repoman
'warnings' into a 'nag' level warning?  IIRC at least one of the QA
team members is so tired of the warnings that they want to make every
single one of them errors; the --nonag option would allow those
warnings to remain in repoman (ie to help guide new dev's or non-dev's
using repoman on their local repos) but since they don't relate to
actual technical breakage they can just be turned off during QA runs, etc.

Thoughts?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqHwoACgkQ2ugaI38ACPAVvgEAqNY3pl+QartxGxiTnEPuycl3
4za+QK26KuNUGO0RJewA/0EIV6z92TG3hr+eLDViIJxfdB0GVTl6JV6ha/EQUZcY
=49jq
-END PGP SIGNATURE-

Re: [gentoo-dev] A constructive reommendation on stablity improvemt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/08/14 05:03 PM, Thomas Kahle wrote:
 Hi,
 
 On 09/08/14 18:18, Igor wrote:
 Hi all,
 
 Hereby the summary of my personal suggestions to increase GENTOO
 stability and help it's maintainers and developers.
 
 1. make.conf
 
 Add
 
 BUG_REPORT_URL  http://;(or similar name) BUG_REPORT ON/OFF 
 BUG_REPORT_LEVEL
 
 to make.conf
 
 Apart from the huge work to implement this, I think any automatic 
 reporting of build failures will not be useful due to a very bad 
 signal to noise ratio.  Bug wrangling will be insane.  What are the
 experiences in the industry.  Is Mozilla getting anything useful
 out of their automatic crash reports?
 
 Cheers, Thomas
 
 


I haven't been able to track down the right people in mozilla to ask,
yet.  I have seen some bugs where the developers that work on fixing
an issue are indeed referencing the crash dumps that were submitted; i
don't know if or how well the crash report submitting links multiple
crashes together to the same issue, though.

Mozilla also has a very hefty 'try' (tinderbox) system, though, that
runs builds on every single commit across every platform that is
supported -- I believe they have a number of tools that help aggregate
the errors and warnings from those logs to provide useful output to
support development, and I think that model might be more comparable
to what we would need in Gentoo -- essentially, this project Igor is
suggesting would turn the Gentoo community into one massive tinderbox.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqIO0ACgkQ2ugaI38ACPBfaAD+IKBIQWf0L4WF2pd6iCzdDUU0
l11GSV6NfnpQYG/qilYBAI+bEUHYqxA75Uhrg+m9lqJ0CzwBpm4Tn0ya1MzmiXxC
=gi7Q
-END PGP SIGNATURE-

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

Rich Freeman:
 so striving for grammatical perfection is a bit optimistic.

In that case, we should just rm the repoman warning and stop discussing
this matter.

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

2014-08-12 Thread William Hubbs

On Tue, Aug 12, 2014 at 09:26:07AM -0400, Rich Freeman wrote:
 
 *snip*

 Yeah, at best this seems a bit trivial.  Do we have a policy that
 descriptions aren't allowed to be complete sentences?  Many of our
 developers are not native English speakers in the first place, so
 striving for grammatical perfection is a bit optimistic.  On top of
 that, repoman certainly isn't a native English speaker, so expecting
 it to achieve grammatical perfection is a really tall order.  And
 please don't suggest making languagetool a dependency for portage...
 
No, we do not have, and there has been no request for, a qa policy that
requires description to not end with a '.'. Also, it is not documented
in the devmanual. So, it appears that this warning was put in place
without involving the QA team at all.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

2014-08-12 Thread Rich Freeman

On Tue, Aug 12, 2014 at 10:04 AM, Ian Stakenvicius a...@gentoo.org wrote:

 I'm wondering what everyone thinks of having a --nonag option to
 repoman and shoving some of the more trivial/style-related repoman
 'warnings' into a 'nag' level warning?  IIRC at least one of the QA
 team members is so tired of the warnings that they want to make every
 single one of them errors; the --nonag option would allow those
 warnings to remain in repoman (ie to help guide new dev's or non-dev's
 using repoman on their local repos) but since they don't relate to
 actual technical breakage they can just be turned off during QA runs, etc.


What, specifically, are we considering trivial?

The whole point of repoman is to prevent devs from making mistakes.
Being able to turn off warnings is counterproductive.  Eliminating
warnings that don't need to be warnings is of course fine.

There is no value in having an escalating battle between warnings and
options to suppress them.

Rich

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/14 12:36 PM, Rich Freeman wrote:
 On Tue, Aug 12, 2014 at 10:04 AM, Ian Stakenvicius a...@gentoo.org
 wrote:
 
 I'm wondering what everyone thinks of having a --nonag option to 
 repoman and shoving some of the more trivial/style-related
 repoman 'warnings' into a 'nag' level warning?  IIRC at least one
 of the QA team members is so tired of the warnings that they want
 to make every single one of them errors; the --nonag option would
 allow those warnings to remain in repoman (ie to help guide new
 dev's or non-dev's using repoman on their local repos) but since
 they don't relate to actual technical breakage they can just be
 turned off during QA runs, etc.
 
 
 What, specifically, are we considering trivial?
 
 The whole point of repoman is to prevent devs from making
 mistakes. Being able to turn off warnings is counterproductive.
 Eliminating warnings that don't need to be warnings is of course
 fine.
 
 There is no value in having an escalating battle between warnings
 and options to suppress them.
 
 Rich
 

Well, there's warnings related to style, like
DESCRIPTION-ending-in-period, and then there's warnings relating to
technical or functional issues.  Of the second set, there are fatal
ones and then there are ones that aren't fatal but still important
(DEPENDENCY.badindev comes to mind).  I think the style or other
non-functional warnings (i can't actually think of any that aren't
style related, tbh) are great to have, and perhaps should even be
expanded if someone felt so inclined, but not at the expense of
additional noise all the time for groups like QA that are primarily
concerned about maintaining functionality.  So instead of, for
instance, dropping the DESCRIPTION-ending-in-period check, it could
instead be relegated to a nag that could be hidden with --nonag.

Essentially what it boils down to is that I don't see every non-fatal
warning as being equivalent in importance, and it might make sense to
push the ones that could be construed as recommendations rather than
warnings to a lighter level.

If there isn't any support for this idea, then of course let's skip it
and we can drop the check(s) instead if that's what's desired by the
community.  Then it's just a question of how far we might want to go
in terms of dropping checks.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqR28ACgkQ2ugaI38ACPCQfQEAgs9Zbpw9rkXjZpJUrM6s0/LZ
mGm1UeLe0iNN0zKn8JwBAJZ2NL1tEDA+8X15UHsT4mBTevK+I3cv9+l6R7j6AtGq
=ptmP
-END PGP SIGNATURE-

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

Ian Stakenvicius:
 So instead of, for
 instance, dropping the DESCRIPTION-ending-in-period check, it could
 instead be relegated to a nag that could be hidden with --nonag.

It will still be broken, even if you hide it.

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/14 01:08 PM, hasufell wrote:
 Ian Stakenvicius:
 So instead of, for instance, dropping the
 DESCRIPTION-ending-in-period check, it could instead be relegated
 to a nag that could be hidden with --nonag.
 
 It will still be broken, even if you hide it.
 

Say it's fixed so it doesn't do false-positives anymore, etc. etc.

I don't consider a recommended style message to be 'broken' just
because it's not listed in the devmanual/PMS/etc as a requirement.
The implementation of it, on the other hand, yes that could be broken
and in this case should be fixed if we keep the check around.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqSyYACgkQ2ugaI38ACPAMZAD/QMy3mmz9yL9kKLfcrNlf737X
9+iJjspqMrp/h8PV19oA/3fQExM/yGUBinM5CWFx6lvYz1pL2daeyxUgMRxtcxDB
=ki6s
-END PGP SIGNATURE-

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

2014-08-12 Thread Rich Freeman

On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius a...@gentoo.org wrote:

 I don't consider a recommended style message to be 'broken' just
 because it's not listed in the devmanual/PMS/etc as a requirement.
 The implementation of it, on the other hand, yes that could be broken
 and in this case should be fixed if we keep the check around.


If we are bothered enough by something to have repoman check it, we
can be bothered enough to add it to the devmanual.

I think we need to decide whether we care about periods at the ends of
DESCRIPTIONs.  If we do, then it should be a warning and devs should
fix their ebuilds at the next convenient opportunity.  If we don't,
then let's just drop the warning.

I'm fine with the separation of hard/soft errors, because some issues
could be situational and left to developer discretion.  However, we
wouldn't want to hide those, because if a dev introduces a new issue
we don't want them to not see the warning.

If somebody has a whitespace issue they should get a warning.  They
should be doing a scan before commit, and they should generally take
the time to fix the issue, even though it is just style.  What is the
point in having a style guideline if half of us are just going to
ignore warnings related to it.  That doesn't mean that our style
guidelines have to be over-the-top - the solution to that is to drop
requirements that aren't important, not to hide them.

If somebody wants to come up with a bunch of extra optional repoman
warnings for stuff like style, I think their time would be better
spent coming up with an ebuild pretty-printer or something which just
fixes things instead of whining about things that aren't policy.

Ultimately quality has to be something we invest in for each other's
sake.  If a rule isn't really benefiting anybody, then it doesn't
belong.  Within reason good style helps us all out - bash doesn't care
if the whole ebuild fits on one line with all the phases/variables/etc
in semi-random order, but we impose some sane style so that we can
work in the tree and not rip our eyes out.

--
Rich

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

2014-08-12 Thread William Hubbs

On Tue, Aug 12, 2014 at 01:25:44PM -0400, Rich Freeman wrote:
 On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius a...@gentoo.org wrote:
 
  I don't consider a recommended style message to be 'broken' just
  because it's not listed in the devmanual/PMS/etc as a requirement.
  The implementation of it, on the other hand, yes that could be broken
  and in this case should be fixed if we keep the check around.
 
 
 If we are bothered enough by something to have repoman check it, we
 can be bothered enough to add it to the devmanual.

I also think that something should be added to the devmanual before it
is added to repoman so that developers aren't blind-sided by repoman
warnings like this.


 I think we need to decide whether we care about periods at the ends of
 DESCRIPTIONs.  If we do, then it should be a warning and devs should
 fix their ebuilds at the next convenient opportunity.  If we don't,
 then let's just drop the warning.
 
I think some will have periods and some won't depending on how the
description is written, so this warning is not one that should stay.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

Dnia 2014-08-11, o godz. 22:34:06
Bertrand Jacquin be...@meleeweb.net napisał(a):

 Hi,
 
 On 2014-08-10 14:22, Sergei Trofimovich wrote:
 
  The script does not handle case of multiline description:
  DESCRIPTION=You have to
  clean that yourself.
 
 You could handle this by reading metadata/md5-cache/*/* instead of 
 ebuild itself
 
 But is multiline DESCRIPTION something recommended as it should contain 
 a short description ?

Considering that we have length limit on DESCRIPTION that is shorter
than typical line wrapping position, I don't think that we need to
consider multiline DESCRIPTIONs.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

2014-08-12 Thread Chris Reffett

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/12/2014 9:26 AM, Rich Freeman wrote:
[snip]
 I don't have a problem with QA recommending new tree policies, but 
 if they're going to do this the QA team ought to first ensure that 
 the team agrees (however they want to govern that), and then 
 communicate the policy before implementing it.  I'd also implement 
 it in documentation before doing so in repoman, otherwise we're 
 going to have a repoman full of 800 rules whose origin is a 
 mystery.  I'm fine with QA policies going into effect by default, 
 but communicating them allows objections to be raised and an
 appeal made to Council if necessary before we get too far along.
 This isn't just about due process - it is hard for developers to
 even comply with a policy they are unaware of.
 
 Rich
 
This isn't a QA policy, was not run by us as far as I can tell, and I
don't know where it came from or why it was added. +1 for revert, if
people want to run this by Council or QA later and actually get an
official decision we can talk about putting it back, but for now it's
generating a lot of noise for no real benefit. It's useless checks
like this that make people ignore repoman warnings.

Chris Reffett
QA Team Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAlPqXvAACgkQ23laikJhg1QvTQCffjAZYIzBGBRlp1l/y6iydzTQ
3d0An12lbTbzr7nWe37qtoay7ktWUAs6
=6c3E
-END PGP SIGNATURE-

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

Dnia 2014-08-11, o godz. 20:48:20
William Hubbs willi...@gentoo.org napisał(a):

 On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote:
  Hello World!
  
  TL;DR:
This evening I plan to mangle ~3000 ebuilds in the main tree
by dropping trailing '.' in all 'DESCRIPTION=' fields (except etc. case)
  
  Long story:
  
  As you may know newest portage release 2.2.11
  got a minor (but chatty) QA warning:
  DESCRIPTION ends with a '.' character
 
 Why is this a QA warning in the first place?

Because it is a common mistake, and having the warning in-place should
help people avoid repeating it.

 I don't recall a policy mandating that descriptions can't end with '.'. I
 asked our QA lead about it and was told that he didn't recall that we
 have an official policy about it either. Also, the devmanual never
 mentions any such requirement.

I don't know if and where it is documented but that's what I was taught
when I started contributing to Gentoo, and it pretty much follows
the common sense. DESCRIPTION is supposed to be short and descriptive.
So you do an elliptical sentence (if I got the right translation),
and that doesn't end with a dot.

If you have any fair reason to not follow this, please speak of it.
Otherwise, this is pure bikeshed and waste of time. This thread already
took much more time than fixing your packages if repoman complained
about them.

 If someone can point me to something I'm missing, let me know.
 Otherwise, I think the warning should be removed.

Even if there were no written-down policy, why would it be removed?
What is the benefit of removing the check that resulted in many fixes
already? Do you want to revert the removals afterwards? Or do you want
to introduce new packages which use '.' there?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

Dnia 2014-08-12, o godz. 10:04:58
Ian Stakenvicius a...@gentoo.org napisał(a):

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 12/08/14 09:54 AM, Ian Stakenvicius wrote:
  
  Perhaps we need to have a less-important repoman warning level 
  (something that can be quieted with a flag) for things like this?
  In terms of DESCRIPTION consistency I don't see it being a bad
  thing that we have the warning, but i also don't see a point in
  changing the entire tree to get rid of 3000 bytes, esp. since the
  ChangeLog entries added to the tree will add at least 30,000 bytes
  :)
  
 
 I'm wondering what everyone thinks of having a --nonag option to
 repoman and shoving some of the more trivial/style-related repoman
 'warnings' into a 'nag' level warning?  IIRC at least one of the QA
 team members is so tired of the warnings that they want to make every
 single one of them errors; the --nonag option would allow those
 warnings to remain in repoman (ie to help guide new dev's or non-dev's
 using repoman on their local repos) but since they don't relate to
 actual technical breakage they can just be turned off during QA runs, etc.

Just don't. I think you missed the point hard and I don't want to know
where the ricochet ended.

First of all, the QA's issue is not really about verbosity of repoman.
It's more about developers who ignore repoman output and commit broken
ebuilds which QA needs to fix afterwards. '--nonag' would mean that
some developers will introduce even more warnings for others...

Secondly, AutoRepoman is already filtering repoman's output. If Patrick
disliked a particular warning, he'd filter it already. He doesn't need
easy-available repoman option for that.

Thirdly, I'm pretty sure I had a third argument but I forgot what it
was. But it was totally convincing, I'm sure of it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] repoman --nonag (was Re: gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings )

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/08/14 03:01 PM, Michał Górny wrote:
 Dnia 2014-08-12, o godz. 10:04:58 Ian Stakenvicius a...@gentoo.org
 napisał(a):
 On 12/08/14 09:54 AM, Ian Stakenvicius wrote:
 
 Perhaps we need to have a less-important repoman warning level
  (something that can be quieted with a flag) for things like
 this? In terms of DESCRIPTION consistency I don't see it being
 a bad thing that we have the warning, but i also don't see a
 point in changing the entire tree to get rid of 3000 bytes,
 esp. since the ChangeLog entries added to the tree will add at
 least 30,000 bytes :)
 
 
 I'm wondering what everyone thinks of having a --nonag option to 
 repoman and shoving some of the more trivial/style-related
 repoman 'warnings' into a 'nag' level warning?  IIRC at least one
 of the QA team members is so tired of the warnings that they want
 to make every single one of them errors; the --nonag option would
 allow those warnings to remain in repoman (ie to help guide new
 dev's or non-dev's using repoman on their local repos) but since
 they don't relate to actual technical breakage they can just be
 turned off during QA runs, etc.
 
 Just don't. I think you missed the point hard and I don't want to
 know where the ricochet ended.

The ricochet more or less ended with the notion that repoman shouldn't
be a random style guide, or rather, development time is better spent
elsewhere rather than making it into one -- and so there's no use case
for nag level messages and a flag that would disable them.


 Thirdly, I'm pretty sure I had a third argument but I forgot what
 it was. But it was totally convincing, I'm sure of it.

Yep, that one was definitely the clincher.  you've convinced me! :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlPqZtEACgkQ2ugaI38ACPCDBAD/WJQ8JBPnYD5XuqTMqHygYd5L
K24oZzyhAsR1vkSahhgBAIW+hia5MXJd4T4AD8u9hi4xzdxGg/2xpwlYMs0u9VQ8
=vQMn
-END PGP SIGNATURE-

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

Chris Reffett:
 
 if people want to run this by Council

I'll laugh my ass off if this thing makes it on the council agenda xD

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-08-12 Thread Tom Wijsman

On Wed, 30 Jul 2014 15:38:43 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:

 That's what I've been trying to point out, people are seriously
 suggesting disabling dynamic deps for race conditions
 It's like fixing one audio driver in the kernel by deleting whole
 ALSA block

It is more like fixing multiple broken audio drivers; if there is only
a single problem with dynamic deps, it wouldn't receive much attention.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-08-12 Thread Tom Wijsman

On Sun, 27 Jul 2014 05:30:26 +1000
Michael Palimaka kensing...@gentoo.org wrote:

 On 07/27/2014 05:21 AM, Tom Wijsman wrote:
  On Sun, 27 Jul 2014 03:12:07 +1000
  Michael Palimaka kensing...@gentoo.org wrote:
  
  On 07/26/2014 07:59 AM, Tom Wijsman wrote:
  On Wed, 23 Jul 2014 22:14:41 +1000
  Michael Palimaka kensing...@gentoo.org wrote:
 
  Shouldn't we strive to avoid the unnecessary rebuilds in the
  first place? Doing updates on your schedule only avoids the
  symptom, not the problem.
 
  We should strive to do both; cause less rebuilds, update less
  often.
 
  It is comparable to flooding on IRC channels; if you send much
  more messages, you are much more likely to experience a kick
  and/or a ban.
 
  It is easier not to flood than to convince people there is no
  problem with you flooding the channel; out of all the IRC channels
  I know of, I've only come across one where they don't mind pasted
  long code blocks but that's mostly because of the lack of active
  moderation and people.
 
  (With flooding as updating and kick/ban as rebuilds)
 
  Each person should update at a frequency that suits them.
  Recommending to update every $period is not a valid solution to
  unnecessary rebuilds.
  
  The more one floods, the more one accepts kicks and/or bans;
  expected.
  
 
 How about just not causing the problem in the first place? :-)

That's the ideal, no revision bumps needed at all; though, the lack of
resources doesn't make that possible. Attempts to do it stall the
introduction of the ebuild; so, that's why we release and revbump it.

This story goes further upstream; if they would list deps right, we
wouldn't need to revbump. So; if we want to fix the cause, we would
need to fix it upstream although they experience a lack of resources.

TL;DR: With the water tap wide open, we'll keep mopping.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] gentoo-x86 tree cleanup for 'DESCRIPTION ends with a '.' character' warnings

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Friends,

the repoman patch is reverted. And that is the end of this.

I do not have gx86 access, so if someone wants me to revert 3K commits
there, I'll need a proxy...
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlPqjnIACgkQRtClrXBQc7W8NwD8CuFNEf7Bwn28Nej6hU2rx+eh
Ms0J17N1k4kj4uEGb4YA/jPWqlOzm9kf0AvR6rQXZzusNmpAsFOTokrO8A98Kza9
=2zAm
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-08-12 Thread Tom Wijsman

On Sat, 26 Jul 2014 14:25:23 + (UTC)
Martin Vaeth mar...@mvath.de wrote:

 Tom Wijsman tom...@gentoo.org wrote:
  Michael Palimaka kensing...@gentoo.org wrote:
 
  What a great way to kill the distro.
 
  I can already heat my house with the number of unnecessary rebuilds
 
  Do you upgrade @world every hour and thus have it cause excessive
  heat?
 
  If I upgrade every X weeks they become much more cool and
  necessary...
 
 One of the main advantages of gentoo is the flowing upgrade,
 especially since this can only be very poorly emulated by
 a binary distro.
 
 If you really suggest that the user waits one month and
 then recompiles the whole installation, you give up
 this advantage of gentoo: The user is not up-to-date
 for a long time, and moreover, then needs practically
 a full reinstall; both are things which he wants to avoid
 and why perhaps he has chosen gentoo in the first place.
 
 At least, for me it is the case: if I have to reinstall
 all packages every months - and even have delay in security
 updates for a month - I will certainly switch the
 distribution. I guess many others think similarly.

Simple equation: The more frequent the user updates, the more frequent
the user will experience the minor inconveniences by upstream and
distribution maintainers. Otherwise we'd be using a -only system.

Dynamic deps, as well as rev bumps, alter this equation; the problem
with that is that such alterations don't come free and without flaws,
which is essentially where you get to reconsider how you alter it.

In a similar way the user has to reconsider whether updating less is
acceptable compared to compiling an occasional inconvenience. Choosing
between a stable and non-stable tree is a big gap of difference in
convenience, choosing how often you update is fine tuning.

To get the idea: Upstream released W.X.Y.Z+1; it was only yesterday
I've compiled W.X.Y.Z, turns out the difference is not so important.
Agreed that this can very well be an important security update; but
if you go back to the equation, that still is a minor inconvenience.

PS: Not suggesting 1 month; but rather that updating not enough, or too
much, can make one experience serious effects that such choices imply.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

[gentoo-portage-dev] [PATCH 4/4] emerge: Let --autounmask=n override other options

From: Alexander Berntsen alexan...@plaimi.net

Signed-off-by: Alexander Berntsen berna...@gentoo.org
---
 pym/_emerge/depgraph.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index bfa63fa..37b3a54 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -418,7 +418,8 @@ class _dynamic_depgraph_config(object):
self._backtrack_infos = {}
 
self._buildpkgonly_deps_unsatisfied = False
-   self._autounmask = True
+   self._autounmask = \
+   
depgraph._frozen_config.myopts.get(--autounmask) != 'n'
self._success_without_autounmask = False
self._traverse_ignored_deps = False
self._complete_mode = False
@@ -7333,8 +7334,11 @@ class depgraph(object):

 
ask = --ask in self._frozen_config.myopts
-   autounmask_write = ask or \
-   self._frozen_config.myopts.get(--autounmask, 
n) == True
+   autounmask = self._frozen_config.myopts.get(--autounmask, y)
+   # Write if *either* --autounmask is explicitly *true*, *or* if
+   # ask is *true* and --autounmask is *not* explicitly *false*
+   autounmask_write = autounmask is True or \
+   (autounmask != 'n'and ask != False)
autounmask_unrestricted_atoms = \

self._frozen_config.myopts.get(--autounmask-unrestricted-atoms, n) == True
quiet = --quiet in self._frozen_config.myopts
-- 
1.8.5.5

[gentoo-portage-dev] [PATCH 0/4] Autounmask changes

Here are the infamous autounmask changes agreed to on the last meeting:
  http://article.gmane.org/gmane.linux.gentoo.portage.devel/4351




They behave like this:

sudo ./emerge =gcc-4.8.3
Calculating dependencies... done!
[ebuild  NS   ~] sys-devel/gcc-4.8.3 [4.7.3-r1] USE=cxx fortran gcj (multilib) 
nls nptl objc openmp (-altivec) -awt -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -mudflap (-multislot) -nopie -nossp -objc++ -objc-gc 
-regression-test -vanilla 

The following keyword changes are necessary to proceed:
 (see package.accept_keywords in the portage(5) man page for more details)
# required by =gcc-4.8.3 (argument)
=sys-devel/gcc-4.8.3 ~amd64

Use --autounmask to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.




sudo ./emerge =gcc-4.8.3 --autounmask
Calculating dependencies... done!
[ebuild  NS   ~] sys-devel/gcc-4.8.3 [4.7.3-r1] USE=cxx fortran gcj (multilib) 
nls nptl objc openmp (-altivec) -awt -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -mudflap (-multislot) -nopie -nossp -objc++ -objc-gc 
-regression-test -vanilla 

The following keyword changes are necessary to proceed:
 (see package.accept_keywords in the portage(5) man page for more details)
# required by =gcc-4.8.3 (argument)
=sys-devel/gcc-4.8.3 ~amd64

Autounmask changes successfully written.

 * IMPORTANT: config file '/etc/portage/package.accept_keywords' needs updating.
 * See the CONFIGURATION FILES section of the emerge
 * man page to learn how to update config files.



sudo ./emerge =gcc-4.8.3 --autounmask=n
Calculating dependencies... done!

!!! All ebuilds that could satisfy =gcc-4.8.3 have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-devel/gcc-4.8.3::gentoo (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.



sudo ./emerge =gcc-4.8.3 -a
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS   ~] sys-devel/gcc-4.8.3 [4.7.3-r1] USE=cxx fortran gcj (multilib) 
nls nptl objc openmp (-altivec) -awt -doc (-fixed-point) -go -graphite 
(-hardened) (-libssp) -mudflap (-multislot) -nopie -nossp -objc++ -objc-gc 
-regression-test -vanilla 

The following keyword changes are necessary to proceed:
 (see package.accept_keywords in the portage(5) man page for more details)
# required by =gcc-4.8.3 (argument)
=sys-devel/gcc-4.8.3 ~amd64

Would you like to add these changes to your config files? [Yes/No] No




sudo ./emerge =gcc-4.8.3 -a --autounmask=n
These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy =gcc-4.8.3 have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-devel/gcc-4.8.3::gentoo (masked by: ~amd64 keyword)


Please review  test.

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
Alexander Berntsen (4):
  emerge: Deprecate --autounmask
  emerge: Rename --autounmask-write to --autounmask
  emerge: Make --autounmask=y if --ask=y
  emerge: Let --autounmask=n override other options

 man/emerge.1| 43 +--
 pym/_emerge/depgraph.py | 14 +-
 pym/_emerge/main.py |  9 -
 3 files changed, 26 insertions(+), 40 deletions(-)

-- 
1.8.5.5

[gentoo-portage-dev] [PATCH 3/4] emerge: Make --autounmask=y if --ask=y

From: Alexander Berntsen alexan...@plaimi.net

Signed-off-by: Alexander Berntsen berna...@gentoo.org
---
 man/emerge.1| 9 +
 pym/_emerge/depgraph.py | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index be52f25..c52cd0a 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -345,10 +345,11 @@ Write required unmask changes to the relevant config 
files, respecting
 \fBCONFIG_PROTECT\fR. If invoked together with \fB\-\-ask\fR, emerge will
 prompt you to write the changes. If invoked along with \fB\-\-pretend\fR,
 emerge will merely output the required changes and not make any of them by
-itself. If the corresponding package.* is a file, the changes are appended to
-it, if it is a directory, changes are written to the lexicographically last
-file. This way it is always ensured that the new changes take precedence over
-existing changes.
+itself. This option is enabled by default if are running emerge with
+\fB\-\-ask\fR or \fB\-\-pretend\fR, and disabled by default elsewise. If the
+corresponding package.* is a file, the changes are appended to it, if it is a
+directory, changes are written to the lexicographically last file. This way it
+is always ensured that the new changes take precedence over existing changes.
 .TP
 .BR \-\-autounmask\-unrestricted\-atoms [ y | n ]
 Keyword and mask changes using the \'=\' operator will be written. With this
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 0c6b8e3..bfa63fa 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -7332,12 +7332,13 @@ class depgraph(object):
(using CONFIG_PROTECT). The message includes the comments and 
the changes.

 
-   autounmask_write = 
self._frozen_config.myopts.get(--autounmask, n) == True
+   ask = --ask in self._frozen_config.myopts
+   autounmask_write = ask or \
+   self._frozen_config.myopts.get(--autounmask, 
n) == True
autounmask_unrestricted_atoms = \

self._frozen_config.myopts.get(--autounmask-unrestricted-atoms, n) == True
quiet = --quiet in self._frozen_config.myopts
pretend = --pretend in self._frozen_config.myopts
-   ask = --ask in self._frozen_config.myopts
enter_invalid = '--ask-enter-invalid' in 
self._frozen_config.myopts
 
def check_if_latest(pkg):
-- 
1.8.5.5

[gentoo-portage-dev] [PATCH] --sync: properly decode getaddrinfo() errors.