[gentoo-portage-dev] [PATCH v2: fix commitmsg thinko] portage.versions: Drop support for non-EAPI "cvs." version prefix

[gmt]

From: "Gregory M. Turner" 

This feature was introduced 12 years ago in (the cvs commit
corresponding to the git commit) 9f3a46665c.  There are a lot of
reasons not to continue to support it:

  o PMS permits no such prefix
  o Nobody uses it (perhaps nobody /ever/ used it)
  o It treats cvs as special, which doesn't make a ton of
sense in 2017
  o If this prefix /were/ added to PMS, it seems* to create
ambiguity between PN and V in obscure EAPIs which support
dots in package names

Therefore, remove it from from the version regular expression and
renumber the constants referring to the affected re groups.

*PMS would barely avoid true abiguity as §3.1.2 has a rule that
logically necessitates that any such ambiguity must be resolved in
favor of V.  Although this appears to be by design, expecting
people to figure this out seems a tad optimistic.

Signed-off-by: Gregory M. Turner 
---
 pym/portage/tests/versions/test_vercmp.py |  3 ---
 pym/portage/versions.py   | 38 +--
 2 files changed, 16 insertions(+), 25 deletions(-)

diff --git a/pym/portage/tests/versions/test_vercmp.py 
b/pym/portage/tests/versions/test_vercmp.py
index 78fe7ede8..b55518f02 100644
--- a/pym/portage/tests/versions/test_vercmp.py
+++ b/pym/portage/tests/versions/test_vercmp.py
@@ -15,7 +15,6 @@ class VerCmpTestCase(TestCase):
("6.0", "5.0"), ("5.0", "5"),
("1.0-r1", "1.0-r0"),
("1.0-r1", "1.0"),
-   ("cvs.", ""),
("99", 
"98"),
("1.0.0", "1.0"),
("1.0.0", "1.0b"),
@@ -36,7 +35,6 @@ class VerCmpTestCase(TestCase):
("1.0_alpha2", "1.0_p2"), ("1.0_alpha1", "1.0_beta1"), 
("1.0_beta3", "1.0_rc3"),
("1.00101", "1.00102"),
("1.001", "1.0010001"),
-   ("", "cvs."),
("98", 
"99"),
("1.01", "1.1"),
("1.0-r0", "1.0-r1"),
@@ -69,7 +67,6 @@ class VerCmpTestCase(TestCase):
tests = [
("1", "2"), ("1.0_alpha", "1.0_pre"), ("1.0_beta", 
"1.0_alpha"),
("0", "0.0"),
-   ("cvs.", ""),
("1.0-r0", "1.0-r1"),
("1.0-r1", "1.0-r0"),
("1.0", "1.0-r1"),
diff --git a/pym/portage/versions.py b/pym/portage/versions.py
index adfb1c3e2..7b6a57673 100644
--- a/pym/portage/versions.py
+++ b/pym/portage/versions.py
@@ -50,7 +50,7 @@ _pkg = {
"dots_allowed_in_PN":r'[\w+][\w+.-]*?',
 }
 
-_v = r'(cvs\.)?(\d+)((\.\d+)*)([a-z]?)((_(pre|p|beta|alpha|rc)\d*)*)'
+_v = r'(\d+)((\.\d+)*)([a-z]?)((_(pre|p|beta|alpha|rc)\d*)*)'
 _rev = r'\d+'
 _vr = _v + '(-r(' + _rev + '))?'
 
@@ -156,21 +156,15 @@ def vercmp(ver1, ver2, silent=1):
print(_("!!! syntax error in version: %s") % ver2)
return None
 
-   # shortcut for cvs ebuilds (new style)
-   if match1.group(1) and not match2.group(1):
-   return 1
-   elif match2.group(1) and not match1.group(1):
-   return -1
-
# building lists of the version parts before the suffix
# first part is simple
-   list1 = [int(match1.group(2))]
-   list2 = [int(match2.group(2))]
+   list1 = [int(match1.group(1))]
+   list2 = [int(match2.group(1))]
 
# this part would greatly benefit from a fixed-length version pattern
-   if match1.group(3) or match2.group(3):
-   vlist1 = match1.group(3)[1:].split(".")
-   vlist2 = match2.group(3)[1:].split(".")
+   if match1.group(2) or match2.group(2):
+   vlist1 = match1.group(2)[1:].split(".")
+   vlist2 = match2.group(2)[1:].split(".")
 
for i in range(0, max(len(vlist1), len(vlist2))):
# Implcit .0 is given a value of -1, so that 1.0.0 > 
1.0, since it
@@ -206,10 +200,10 @@ def vercmp(ver1, ver2, silent=1):
# may seem counter-intuitive. However, if you really think about it, it
# seems like it's probably safe to assume that this is the behavior that
# is intended by anyone who would use versions such as these.
-   if len(match1.group(5)):
-   list1.append(ord(match1.group(5)))
-   if len(match2.group(5)):
-   list2.append(ord(match2.group(5)))
+   if len(match1.group(4)):
+   list1.append(ord(match1.group(4)))
+   if len(match2.group(4)):
+   list2.append(ord(match2.group(4)))
 
for i in range(0, max(len(list1), len(list2))):
if 

[gentoo-portage-dev] [PATCH] portage.versions: Drop support for non-EAPI "cvs." version prefix

[gmt]

From: "Gregory M. Turner" 

This feature was introduced 12 years ago in (the cvs commit
corresponding to the git commit) 9f3a46665c.  There are a lot of
reasons not to continue to support it:

  o EAPI permits no such prefix
  o Nobody uses it (perhaps nobody /ever/ used it)
  o It treats cvs as special, which doesn't make a ton of
sense in 2017
  o If this prefix /were/ added to PMS, it seems* to create
ambiguity between PN and V in obscure EAPIs which support
dots in package names

Therefore, remove it from from the version regular expression and
renumber the constants referring to the affected re groups.

*PMS would barely avoid true abiguity as §3.1.2 has a rule that
logically necessitates that any such ambiguity must be resolved in
favor of V.  Although this appears to be by design, expecting
people to figure this out seems a tad optimistic.

Signed-off-by: Gregory M. Turner 
---
 pym/portage/tests/versions/test_vercmp.py |  3 ---
 pym/portage/versions.py   | 38 +--
 2 files changed, 16 insertions(+), 25 deletions(-)

diff --git a/pym/portage/tests/versions/test_vercmp.py 
b/pym/portage/tests/versions/test_vercmp.py
index 78fe7ede8..b55518f02 100644
--- a/pym/portage/tests/versions/test_vercmp.py
+++ b/pym/portage/tests/versions/test_vercmp.py
@@ -15,7 +15,6 @@ class VerCmpTestCase(TestCase):
("6.0", "5.0"), ("5.0", "5"),
("1.0-r1", "1.0-r0"),
("1.0-r1", "1.0"),
-   ("cvs.", ""),
("99", 
"98"),
("1.0.0", "1.0"),
("1.0.0", "1.0b"),
@@ -36,7 +35,6 @@ class VerCmpTestCase(TestCase):
("1.0_alpha2", "1.0_p2"), ("1.0_alpha1", "1.0_beta1"), 
("1.0_beta3", "1.0_rc3"),
("1.00101", "1.00102"),
("1.001", "1.0010001"),
-   ("", "cvs."),
("98", 
"99"),
("1.01", "1.1"),
("1.0-r0", "1.0-r1"),
@@ -69,7 +67,6 @@ class VerCmpTestCase(TestCase):
tests = [
("1", "2"), ("1.0_alpha", "1.0_pre"), ("1.0_beta", 
"1.0_alpha"),
("0", "0.0"),
-   ("cvs.", ""),
("1.0-r0", "1.0-r1"),
("1.0-r1", "1.0-r0"),
("1.0", "1.0-r1"),
diff --git a/pym/portage/versions.py b/pym/portage/versions.py
index adfb1c3e2..7b6a57673 100644
--- a/pym/portage/versions.py
+++ b/pym/portage/versions.py
@@ -50,7 +50,7 @@ _pkg = {
"dots_allowed_in_PN":r'[\w+][\w+.-]*?',
 }
 
-_v = r'(cvs\.)?(\d+)((\.\d+)*)([a-z]?)((_(pre|p|beta|alpha|rc)\d*)*)'
+_v = r'(\d+)((\.\d+)*)([a-z]?)((_(pre|p|beta|alpha|rc)\d*)*)'
 _rev = r'\d+'
 _vr = _v + '(-r(' + _rev + '))?'
 
@@ -156,21 +156,15 @@ def vercmp(ver1, ver2, silent=1):
print(_("!!! syntax error in version: %s") % ver2)
return None
 
-   # shortcut for cvs ebuilds (new style)
-   if match1.group(1) and not match2.group(1):
-   return 1
-   elif match2.group(1) and not match1.group(1):
-   return -1
-
# building lists of the version parts before the suffix
# first part is simple
-   list1 = [int(match1.group(2))]
-   list2 = [int(match2.group(2))]
+   list1 = [int(match1.group(1))]
+   list2 = [int(match2.group(1))]
 
# this part would greatly benefit from a fixed-length version pattern
-   if match1.group(3) or match2.group(3):
-   vlist1 = match1.group(3)[1:].split(".")
-   vlist2 = match2.group(3)[1:].split(".")
+   if match1.group(2) or match2.group(2):
+   vlist1 = match1.group(2)[1:].split(".")
+   vlist2 = match2.group(2)[1:].split(".")
 
for i in range(0, max(len(vlist1), len(vlist2))):
# Implcit .0 is given a value of -1, so that 1.0.0 > 
1.0, since it
@@ -206,10 +200,10 @@ def vercmp(ver1, ver2, silent=1):
# may seem counter-intuitive. However, if you really think about it, it
# seems like it's probably safe to assume that this is the behavior that
# is intended by anyone who would use versions such as these.
-   if len(match1.group(5)):
-   list1.append(ord(match1.group(5)))
-   if len(match2.group(5)):
-   list2.append(ord(match2.group(5)))
+   if len(match1.group(4)):
+   list1.append(ord(match1.group(4)))
+   if len(match2.group(4)):
+   list2.append(ord(match2.group(4)))
 
for i in range(0, max(len(list1), len(list2))):
if 

RE: [gentoo-dev] Temporary DevRel actions for CoC violations

[gmt]

on Wed, 19 Jun 2013, at 10:35, Markos Chandras thusly quipped:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Hi,
 
 It is unfortunate to observe constant bullying, insults and trolling
 across our public media. Developers have been warned over and over that
 such behaviour is not acceptable and they should try to behave
 properly. However, people have ignored such warnings for a very long
 time. This ends today.

Tough talk.  We'll see...

 The DevRel policy states that: If the issue is deemed critical,
 the developer in question may have his or her access suspended
 while a vote takes place. In such situations, the Developer
 Relations lead may act without a vote of the remaining Developer
 Relations team; this power is granted by Council. Except in
 critical situations where immediate action is required, such
 disciplinary action is determined by members of the Developer
 Relations project.[1]
 
 For me, this problem is critical. Devrel is working on formalizing a new
 policy, and we will announce news on this soon. In the meantime, to
 prevent further escalations,  I will use my lead powers to request
 immediate bans whenever I see one of you violate the CoC[2] and ignore
 the previous warnings.

Hmm... that's a serious responsibility you've assigned yourself.   I hope
you'll be a benevolent, impartial and reasonable interim judge, jury and
muzzler.

 My fellow developers, it's time you finally realize that
 you are part of a community and you must learn to behave
 and respect each other even if you have different technical views.
 We are all people sharing a common interest: Gentoo.
 
 [1] http://www.gentoo.org/proj/en/devrel/policy.xml#doc_chap2
 [2] http://www.gentoo.org/proj/en/council/coc.xml

Sorry to hear you have such a low opinion of the socialization of Gentoo
developers.  Since I'm not one of them, I'll just put forth my 2c in on
this, without fear of consequences.

Am I the only one who feels that trolling, abuse, and so forth, are largely
in the eye of the beholder, and that lively, impassioned, constructive
debate may seem to many readers like hyperbole and ad hominem attack?

As long as I can remember, candid and even ostensibly hostile debate and
argument have been a part of the Gentoo process (the same goes for a great
many open-source projects).  Thus far, although not without some frustration
and angst, Gentoo has weathered these storms, and somehow managed to make
sound decisions based on technical and practical merit, after all is said
and done.

Have you considered the possibility, Markos, that, although not pretty to
look at, such conflicts provide an important cathartic channel to relieve
certain psychological pressures?  In environments where everyone is
expected, on pain of discipline, to be civil all the time, my experience
is that folks start to build up resentments which eventually explode
forth, spectacularly, despite -- indeed, one might say, because of -- their
best efforts to conform to those expectations.

IIRC, Gentoo already has rules forbidding a laundry-list of antisocial
behaviors like racism, sexism, threats of violence, and so forth, and some
provisions in place to handle violators of that policy, does it not?

Further -- and please take this as more of a rhetorical flourish than a
genuine concern, but, I wonder, whose job it is to muzzle you, Markos, if
you, yourself get out of line, and will they dare perform it?

Has a clear consensus emerged that existing rules are not strong enough?
Or perhaps, are a vocal minority just butt-hurt about some particular
discussion that happened recently?  I'm asking fully in earnest, and I
sincerely hope -- and genuinely presume -- I don't have to worry that I'll
be muzzled for doing so, on the basis that I'm trolling or what-have-you.

Why should I even feel the need to say so?  Perhaps, that is my problem and
sheer paranoia, but surely, you can appreciate how such an announcement can
potentially have certain chilling effects, and that the merits of strict
enforcement of such well-intended policies are not necessarily so clear as
they might seem on first glance.

Wishing you the best in your effort to make Gentoo a more civil and
friendly community,

-gmt

attachment: winmail.dat

RE: [gentoo-portage-dev] [PATCH 0/3] Add cross-prefix support

[gmt]

On Mon, 17 Jun 2013, at 01:00, Ruud Koolen thusly quipped:
 I also didn't test whether these patches work on the prefix-portage branch. I
 don't really know much far prefix-portage diverges from mainline portage, so I
 don't know whether I should expect it to just work.

Prefix portage is literally a branch -- in the git sense of the term -- of the 
regular portage git repo on g.o.g.o.  So, a good place to start is to check out 
that branch and see if your diffs apply.  When I am doing work that I expect to 
flow into both branches, I typically maintain a master and prefix_master 
private branch, with the latter set to pull from origin/prefix, i.e.:

[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /usr/src/repos/git/portage.git
[branch master]
remote = origin
merge = refs/heads/master
 [branch prefix_master]
remote = origin
merge = refs/heads/prefix
 [branch cygwin_master]
remote = .
merge = refs/heads/prefix_master

Guess I didn't use very consistent naming.   The basic plan is, with the arrows 
representing flows of information to the right-hand side on git pull:

[upstream repo] - /usr/src/repos/git/portage.git -- a bare, vanilla clone of 
upstream
[portage.git/master] - master (which is a private branch with upstreamable 
patches)
[portage.git/prefix] - prefix_master (also a private branch, analogous to 
master, with forward-ported versions of my patches in master; upstreamable to 
origin/prefix)
[prefix_master] - cygwin (an experimental prefix portage fork, downstream to 
all of the above)

Usually I cherry-pick patches from master into prefix_master and perform up any 
merges at that phase, and then just git checkout cygwin ; git pull to merge 
those (vs.-vanilla-prefix-portage) patches into my experimental prefix portage 
fork.

I do that way because my eyes simply glaze over when I try to read that whole 
business about prune-and-graft in git merge --help; however if you end up with 
a huge pile of patches to merge, the prune-graft approach should work perfectly 
fine to move deltas from master to prefix-master.

-gmt

RE: [gentoo-dev] Packages up for grabs

[gmt]

On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
 Due ramereth lack of time:
 net-misc/stunnel

Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
never officially maintained anything, is there some documentation somewhere as 
to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of 
how proxy maintainer-ship actually works?  I.e.: would I need some particular 
person to agree to be my commit-bitch or can I just sign off on patches, 
somehow, and expect a pool of commit-bitches to magically push commits for me?

-gmt

RE: [gentoo-dev] Packages up for grabs

[gmt]

On Sun, 16 Jun 2013, at 05:27, Pacho Ramos thusly quipped:

 El dom, 16-06-2013 a las 05:19 -0700, g...@malth.us escribió:
 On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
 Due ramereth lack of time:
 net-misc/stunnel
 
 Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've 
 never
 officially maintained anything, is there some documentation somewhere as to
 what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of 
 how
 proxy maintainer-ship actually works?  I.e.: would I need some particular 
 person
 to agree to be my commit-bitch or can I just sign off on patches, somehow, and
 expect a pool of commit-bitches to magically push commits for me?
 
 -gmt
 
 
 I think you will need to simply contact proxy-maint people (CCing them)
 http://www.gentoo.org/proj/en/qa/proxy-maintainers/

Maybe I shouldn't do this just yet.  I need to figure out whether the box in 
question gets its stunnel from gentoo or some other distribution (it has a 
severe multiple personality disorder).

If I take on maintainer-ship and it turns out I don't actually use the ebuild 
in-house, dereliction of duty on my part is almost an inevitability.  On the 
other hand, if I am relying on the ebuild, I'll almost certainly want to 
proxy-maintain, once I get my hardware issues sorted out.  There'd be no 
problem resurrecting it from the grave, if need be, would there?

-gmt

RE: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[gmt]

 -Original Message-
 From: Michał Górny [mailto:mgo...@gentoo.org]
 Sent: Wednesday, June 12, 2013 9:51 AM
 To: Gentoo Developer Mailing List
 Subject: [gentoo-dev] Over-reliance of Gentoo projects on overlays 
 Hello,
 
 I'd like to raise another issue I've met again recently. Shortly put, 
 some of our projects are relying too much on their overlays. The net 
 result is that some of their packages in the tree are not well-tested, 
 semi-broken and users end up being hurt by that.

On the other hand, if those overlays' code, due to lack of sufficient manpower, 
interest, code quality, or whatever, is not able to bubble up through whatever 
chain of upstreams, perhaps the broken ebuilds or eclasses should be removed 
from gx86 or have non-gx86-compatible features masked or removed, so that 
overlay-specific code or features are maintained downstream, in the overlays 
that service them.

In short, is it not the idea that non-masked gx86 stable, (and, to a lesser 
extent, non-masked gx86 ~arch) should contain easy-to-use, working ebuilds for 
the vast majority of users and standard use-cases, whereas overlays, even 
official overlays, are free to implement whatever quality standards suit the 
needs of the projects that administer them?

Although there are clearly some Bad Things about overlays as a means of 
communicating features to end-users and organizing development, I'm not sure 
this implies there's anything wrong with the overlay mechanism per-se.  These 
Bad Things may, instead, arise from deficiencies in the modularity of ebuilds 
or portage itself.

Perhaps you should mention the specific bathwater you'd like to see thrown out, 
and, from there, folks can help determine where, if anywhere, is the baby?

-gmt