Re: [gentoo-dev] NEWS item for games destabling

[Alec Warner]

On Mon, Nov 27, 2017 at 3:44 PM, Michael Orlitzky  wrote:

> On 11/27/2017 03:37 PM, Arve Barsnes wrote:
> >
> > Sounds kind of weird? If he has keyworded the game package, shouldn't it
> > just never install that version if it depends on an unstable package?
>
> That's right, but if there are two available ~arch versions, one of
> which has all stable dependencies and (the newer) one of which has all
> ~arch dependencies, then portage will try to install the newer one and
> tell you to keyword a million things -- even though it could install the
> first one with less hassle.
>
>
In theory the resolver could support such a scheme, no?

Currently it prefers "best_visible" where best == "highest version"

But other predicates might be possible like "tightest_visible"

Note that currently best_visible is fairly straightforward to implement:

visible = find_all_visible()
best_visible = max(visible) # simple ver_cmp

tightest_visible:
visible = find_all_visible()
tightest_visible = min(visible, key=cpv.tightness)

# A weird predicate where 'tightness' implies dependencies are already
visible? I can't think of a better term.
def tightness(self):
  return len([atom for atom in self.dependencies if atom.is_visible()])

So "tighter" packages have dependencies that are visible / installed.
"Loose" packages have unmet dependencies or dependencies that are not
currently visible.

I have not messed with the portage resolver in some time; in theory given
perfect code you just plum this in once
but I'm skeptical its that easy (and I suspect best_visible is in fact
'presumed' in many places.

But Zac would probably know best.

-A



> For example, if you're on a system with no ruby packages, then it's the
> difference between having to keyword 10 packages for rails-x.y.z versus
> 200 packages for rails-x.y.(z+1). I'd rather have the slightly older
> version that requires less configuration.
>
>
>

Re: [gentoo-dev] NEWS item for games destabling

[Arve Barsnes]

On 27 November 2017 at 20:44, Michael Orlitzky  wrote:

> On 11/27/2017 03:37 PM, Arve Barsnes wrote:
> >
> > Sounds kind of weird? If he has keyworded the game package, shouldn't it
> > just never install that version if it depends on an unstable package?
>
> That's right, but if there are two available ~arch versions, one of
> which has all stable dependencies and (the newer) one of which has all
> ~arch dependencies, then portage will try to install the newer one and
> tell you to keyword a million things -- even though it could install the
> first one with less hassle.
>
> Ah, hadn't thought of that scenario. Reading the emerge man pages, I would
try the --autounmask-keep-masks option, but emerge might never consider
anything but the latest stable version either way.

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:44, Michael Orlitzky wrote:
> On 11/27/2017 03:37 PM, Arve Barsnes wrote:
>> Sounds kind of weird? If he has keyworded the game package, shouldn't it
>> just never install that version if it depends on an unstable package?
> That's right, but if there are two available ~arch versions, one of
> which has all stable dependencies and (the newer) one of which has all
> ~arch dependencies, then portage will try to install the newer one and
> tell you to keyword a million things -- even though it could install the
> first one with less hassle.
>
> For example, if you're on a system with no ruby packages, then it's the
> difference between having to keyword 10 packages for rails-x.y.z versus
> 200 packages for rails-x.y.(z+1). I'd rather have the slightly older
> version that requires less configuration.
>
>
You might achieve something with one of the new
"autounmask-keep-keywords" -type parameters to portage .. although YMMV,
etc ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[Michael Orlitzky]

On 11/27/2017 03:37 PM, Arve Barsnes wrote:
> 
> Sounds kind of weird? If he has keyworded the game package, shouldn't it
> just never install that version if it depends on an unstable package?

That's right, but if there are two available ~arch versions, one of
which has all stable dependencies and (the newer) one of which has all
~arch dependencies, then portage will try to install the newer one and
tell you to keyword a million things -- even though it could install the
first one with less hassle.

For example, if you're on a system with no ruby packages, then it's the
difference between having to keyword 10 packages for rails-x.y.z versus
200 packages for rails-x.y.(z+1). I'd rather have the slightly older
version that requires less configuration.

Re: [gentoo-dev] NEWS item for games destabling

[Arve Barsnes]

On 27 November 2017 at 20:34, Rich Freeman  wrote:

> To answer his question, there is not any way out-of-the-box to tell
> portage to install the latest ~arch version of a package that has only
> stable or already-accepted dependencies.  Certainly it should be
> possible to build such a feature, but it doesn't exist today.
>

Sounds kind of weird? If he has keyworded the game package, shouldn't it
just never install that version if it depends on an unstable package? I
know I've seen errors of that kind on a machine running stable, but
shouldn't emerge just skip the package update if you can't satisfy its
dependencies? In my head it sounds like that should be something of a
default, but maybe I'm missing something.

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:34, Rich Freeman wrote:
> On Mon, Nov 27, 2017 at 3:15 PM, M. J. Everitt  wrote:
>> On 27/11/17 18:44, Christopher Head wrote:
>>> For those of us who run mostly stable systems, there is one question I 
>>> don’t know a good answer to.
>>>
>>> If I add a specific version of a game to package.accept_keywords, I will 
>>> get that version forever. That’s not really what I want: I prefer to stay 
>>> up to date as new versions are packaged.
>>>
>>> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
>>> latest version. If that version has some unstable dependencies which I 
>>> haven’t also accepted, Portage will yell at me. An example of this is 
>>> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter 
>>> of which is unstable.
>>>
>>> What I really want to install is, “the latest version of the package that 
>>> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
>>> don’t know any way to tell Portage that. Am I missing something, or is that 
>>> indeed impossible?
>> Sounds to me a failure in adhering to the stabilisation criterion that
>> state that all deps must be stabilised FIRST .. as the bugzilla
>> stable-bot will now automagically check ...
>>
> Nobody is stabilizing anything.  That is the whole reason he raised
> that concern.  He wants to use ~arch versions of games, with stable
> dependencies.
>
> To answer his question, there is not any way out-of-the-box to tell
> portage to install the latest ~arch version of a package that has only
> stable or already-accepted dependencies.  Certainly it should be
> possible to build such a feature, but it doesn't exist today.
>
Ah my apologies .. that's definitely what most would consider a bit of
an 'edge case' then ..

Thanks for the clarification, Rich.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[Rich Freeman]

On Mon, Nov 27, 2017 at 3:15 PM, M. J. Everitt  wrote:
> On 27/11/17 18:44, Christopher Head wrote:
>> For those of us who run mostly stable systems, there is one question I don’t 
>> know a good answer to.
>>
>> If I add a specific version of a game to package.accept_keywords, I will get 
>> that version forever. That’s not really what I want: I prefer to stay up to 
>> date as new versions are packaged.
>>
>> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
>> latest version. If that version has some unstable dependencies which I 
>> haven’t also accepted, Portage will yell at me. An example of this is 
>> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter 
>> of which is unstable.
>>
>> What I really want to install is, “the latest version of the package that 
>> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
>> don’t know any way to tell Portage that. Am I missing something, or is that 
>> indeed impossible?
> Sounds to me a failure in adhering to the stabilisation criterion that
> state that all deps must be stabilised FIRST .. as the bugzilla
> stable-bot will now automagically check ...
>

Nobody is stabilizing anything.  That is the whole reason he raised
that concern.  He wants to use ~arch versions of games, with stable
dependencies.

To answer his question, there is not any way out-of-the-box to tell
portage to install the latest ~arch version of a package that has only
stable or already-accepted dependencies.  Certainly it should be
possible to build such a feature, but it doesn't exist today.

-- 
Rich

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 18:44, Christopher Head wrote:
> For those of us who run mostly stable systems, there is one question I don’t 
> know a good answer to.
>
> If I add a specific version of a game to package.accept_keywords, I will get 
> that version forever. That’s not really what I want: I prefer to stay up to 
> date as new versions are packaged.
>
> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
> latest version. If that version has some unstable dependencies which I 
> haven’t also accepted, Portage will yell at me. An example of this is 
> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter of 
> which is unstable.
>
> What I really want to install is, “the latest version of the package that 
> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
> don’t know any way to tell Portage that. Am I missing something, or is that 
> indeed impossible?
Sounds to me a failure in adhering to the stabilisation criterion that
state that all deps must be stabilised FIRST .. as the bugzilla
stable-bot will now automagically check ...



signature.asc
Description: OpenPGP digital signature

[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] NEWS item for games destabling

[Christopher Head]

For those of us who run mostly stable systems, there is one question I don’t 
know a good answer to.

If I add a specific version of a game to package.accept_keywords, I will get 
that version forever. That’s not really what I want: I prefer to stay up to 
date as new versions are packaged.

If I add just a cat/pkg to p.a_k, Portage will always try to pull in the latest 
version. If that version has some unstable dependencies which I haven’t also 
accepted, Portage will yell at me. An example of this is 
games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter of 
which is unstable.

What I really want to install is, “the latest version of the package that 
doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
don’t know any way to tell Portage that. Am I missing something, or is that 
indeed impossible?
-- 
Christopher Head

signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

[Mike Gilbert]

On Mon, Nov 27, 2017 at 6:46 AM, Aaron W. Swenson  wrote:
> On 2017-11-26 10:02, Benda Xu wrote:
>> Hi Patrick,
>>
>> Patrick McLean  writes:
>>
>> > I use portage as non-root all the time when developing and testing
>> > ebuilds, via the "ebuild" command.
>>
>> The enewgroup and enewuser are used in pkg_* functions, as documented in
>> user.eclass _assert_pkg_ebuild_phase() function.  They require root to
>> execute.
>>
>> So no worries, your workflow will not be affected.
>
> Actually, it will probably be better.
>
> You should now be able to do compilation and tests without having the
> user/group created. For example, dev-db/postgresql doesn’t need the
> postgres system user and group in order to successfully run through
> src_test and src_install. It just needs the user/group at run time.

Sounds like the enewuser call should be moved from pkg_setup to
pkg_postinst in that case.

Re: [gentoo-dev] [PATCH 1/2] glep-0042: Drop requirement for detached signatures.

[Ulrich Mueller]

> On Mon, 27 Nov 2017, Aaron W Swenson wrote:

> This was deemed no longer necessary…

Applied, thanks.


pgpUVuOaSVc3v.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

[Ulrich Mueller]

> On Mon, 27 Nov 2017, Aaron W Swenson wrote:

> On 2017-11-27 10:54, Duncan wrote:
>> While there is no hard restriction on the length of short-name,
>> limiting it to 20 characters is strongly recommended.
>> 
>> [...]

> Does it matter if people notice the recommendation? Should it be its
> own paragraph for emphasis?

I guess that the devmanual section will be read more often, so I'll
prepare a patch for it when (and if) the GLEP changes are accepted:
https://devmanual.gentoo.org/general-concepts/news/index.html

That it currently has just "name" rather than "very short name" (as in
the GLEP) doesn't help, I suppose.

Ulrich


pgpkKIxwjcjik.pgp
Description: PGP signature

[gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

[Ulrich Mueller]

> On Mon, 27 Nov 2017, Duncan  wrote:

> Arguably bikeshedding but changing up the last sentence to read a
> bit smoother (I skipped formatting)...

> While there is no hard restriction on the length of short-name,
> limiting it to 20 characters is strongly recommended.

> (s/for/on/, reversing order of the limit and strongly recommended.)

Applied, thanks.


pgpvLy_HCfnj4.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

[Aaron W. Swenson]

On 2017-11-26 10:02, Benda Xu wrote:
> Hi Patrick,
> 
> Patrick McLean  writes:
> 
> > I use portage as non-root all the time when developing and testing
> > ebuilds, via the "ebuild" command.
> 
> The enewgroup and enewuser are used in pkg_* functions, as documented in
> user.eclass _assert_pkg_ebuild_phase() function.  They require root to
> execute.
> 
> So no worries, your workflow will not be affected.

Actually, it will probably be better.

You should now be able to do compilation and tests without having the
user/group created. For example, dev-db/postgresql doesn’t need the
postgres system user and group in order to successfully run through
src_test and src_install. It just needs the user/group at run time.


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 1/2] glep-0042: Drop requirement for detached signatures.

[Aaron W. Swenson]

On 2017-11-27 00:13, Ulrich Müller wrote:
> …
> +.. Note:: A previous version of this GLEP had required that news items must
> +   be signed with a detached OpenPGP signature. This was no longer deemed
> +   necessary after moving news items to a Git repository with commit signing,
> +   and deployment of full-tree verification per GLEP 74 [#glep-74]_.

This was deemed no longer necessary…


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

[Aaron W. Swenson]

On 2017-11-27 10:54, Duncan wrote:
> Ulrich Müller posted on Mon, 27 Nov 2017 00:30:49 +0100 as excerpted:
> 
> > diff --git a/glep-0042.rst b/glep-0042.rst
> > index 7726ea4..90ae0b2 100644
> > --- a/glep-0042.rst
> > +++ b/glep-0042.rst
> > @@ -179,7 +179,9 @@ form ``-mm-dd-short-name``, where ```` is the 
> > year (e.g. ``2005``),
> >  ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
> >  (``01`` through ``31``). The ``short-name`` is a very short name 
> > describing the
> >  news item (e.g. ``yoursql-updates``), consisting only of the characters 
> > ``a-z``,
> > -``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
> > +``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). While there
> > +is no hard restriction for the length of ``short-name``, it is strongly
> > +recommended to limit it to at most 20 characters.
> 
> Arguably bikeshedding but changing up the last sentence to read a bit smoother
> (I skipped formatting)...
> 
> While there is no hard restriction on the length of short-name,
> limiting it to 20 characters is strongly recommended.
> 
> (s/for/on/, reversing order of the limit and strongly recommended.)

I agree. This one reads a bit better.

Does it matter if people notice the recommendation? Should it be its own
paragraph for emphasis?


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 2/2] glep-0042: Update and clarify naming rules.

[Duncan]

Ulrich Müller posted on Mon, 27 Nov 2017 00:30:49 +0100 as excerpted:

> diff --git a/glep-0042.rst b/glep-0042.rst
> index 7726ea4..90ae0b2 100644
> --- a/glep-0042.rst
> +++ b/glep-0042.rst
> @@ -179,7 +179,9 @@ form ``-mm-dd-short-name``, where ```` is the 
> year (e.g. ``2005``),
>  ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
>  (``01`` through ``31``). The ``short-name`` is a very short name describing 
> the
>  news item (e.g. ``yoursql-updates``), consisting only of the characters 
> ``a-z``,
> -``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
> +``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). While there
> +is no hard restriction for the length of ``short-name``, it is strongly
> +recommended to limit it to at most 20 characters.

Arguably bikeshedding but changing up the last sentence to read a bit smoother
(I skipped formatting)...

While there is no hard restriction on the length of short-name,
limiting it to 20 characters is strongly recommended.

(s/for/on/, reversing order of the limit and strongly recommended.)

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

[gentoo-dev] [PATCH 2/2] glep-0042: Update and clarify naming rules.

[Ulrich Müller]

Update the GLEP from ISO 639 to IETF language tags (BCP 47), in order
to make it consistent with usage in the L10N USE_EXPAND variable.
This will make no difference for most common languages. Also there are
currently no translations of news items at all.

Add a note clarifying what "very short" means.
---
 glep-0042.rst | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/glep-0042.rst b/glep-0042.rst
index 7726ea4..90ae0b2 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -179,7 +179,9 @@ form ``-mm-dd-short-name``, where ```` is the year 
(e.g. ``2005``),
 ``mm`` is the month (``01`` through ``12``) and dd is the day of the month
 (``01`` through ``31``). The ``short-name`` is a very short name describing the
 news item (e.g. ``yoursql-updates``), consisting only of the characters 
``a-z``,
-``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore).
+``0-9``, ``+`` (plus), ``-`` (hyphen) and ``_`` (underscore). While there
+is no hard restriction for the length of ``short-name``, it is strongly
+recommended to limit it to at most 20 characters.
 
 News Item Directories
 -
@@ -191,8 +193,8 @@ The directory will contain a file named 
``-mm-dd-short-name.en.txt``, which
 contains the text of the news item, in English, in the format described below.
 
 If a news item is translated, other files named 
``-mm-dd-short-name.xx.txt``
-(where ``xx`` is the ISO 639 [#iso-639]_ two letter language code, and the date
-remains the same as the original news item) will also be provided. However, 
only
+(where ``xx`` is a valid IETF language tag [#bcp-47]_, and the date remains
+the same as the original news item) will also be provided. However, only
 the English version of a news item is authoritative.  This anglocentricity is
 justified by precedent [#glep-34]_.
 
@@ -475,6 +477,8 @@ Example Files
 References
 ==
 
+.. [#bcp-47] BCP 47: "Tags for identifying languages",
+ https://tools.ietf.org/rfc/bcp/bcp47.txt
 .. [#bug-11359] Bugzilla Bug 11359
"[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
https://bugs.gentoo.org/show_bug.cgi?id=11359
@@ -500,7 +504,6 @@ References
 .. [#glep-74] GLEP 74: "Full-tree verification using Manifest files",
  Michał Górny, Robin Hugh Johnson, Ulrich Müller,
  https://www.gentoo.org/glep/glep-0074.html
-.. [#iso-639] ISO 639 "Code for the representation of names of languages"
 .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
  Albertson,
  
https://archives.gentoo.org/gentoo-dev/message/4204839d4091758c3bad1dbd18ed16f7
-- 
2.15.0


pgpSN2WafPRNC.pgp
Description: PGP signature

[gentoo-dev] [PATCH 0/2] Two updates for GLEP 42

[Ulrich Müller]

Here are two updates for GLEP 42, for review.

Currently it is required that every news item is accompanied by a
detached OpenPGP signature. To my knowledge, verification of these
signatures was never implemented. With Git commit signing and after
full-tree verification is implemented, these detached signatures will
become fully redundant. In addition, we noticed that several of the
signatures have a bad format (e.g., are not detached signatures
at all). Therefore the first patch drops the requirement for detached
OpenPGP signatures.

The second patch updates the GLEP from ISO 639 to IETF language codes
(BCP 47), in order to make it consistent with usage in the L10N
USE_EXPAND variable. This will make no difference for most common
languages. Please note that a BCP 47 language tag can in principle
be longer than two letters, and can contain characters [A-Za-z0-9-].
(Since there are currently no translations of news items, all this is
rather academic, though.)

Finally (also in the second patch) a note is added clarifying what
"very short" means in a filename context. Technically, the short-name
is needed only to distinguish between multiple news items posted at
the same day. However, there seems to be a tendency to repeat half
of the news item's content in its filename. ;-)

Ulrich Müller (2):
  glep-0042: Drop requirement for detached signatures.
  glep-0042: Update and clarify naming rules.

 glep-0042.rst | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

-- 
2.15.0


pgpa3ind7X16Y.pgp
Description: PGP signature

[gentoo-dev] [PATCH 1/2] glep-0042: Drop requirement for detached signatures.

[Ulrich Müller]

---
 glep-0042.rst | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/glep-0042.rst b/glep-0042.rst
index c6b41e9..7726ea4 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -9,7 +9,7 @@ Type: Standards Track
 Status: Final
 Version: 3
 Created: 2005-10-31
-Last-Modified: 2016-03-18
+Last-Modified: 2017-11-26
 Post-History: 2005-11-01, 2005-11-05, 2005-11-07, 2005-12-11, 2005-12-13,
   2005-12-18, 2006-01-05, 2006-03-02, 2006-03-06, 2006-06-12,
   2006-09-05, 2016-03-10
@@ -203,19 +203,16 @@ A news item file is a text file, encoded using UTF-8 
[#rfc-3629]_ for
 compatibility with and for the same reasons as existing Gentoo documentation
 [#docs-policy]_ and the tree [#glep-31]_.
 
-News items must be signed with a detached GPG signature.::
-
-gpg --armour --detach-sign -??-??-*.??.txt
-
-This GLEP does not specify the type or strength of signature to be used, nor
-does it discuss how, if at all, a centralised keychain will be provided. These
-issues should be handled as part of the signing policy discussions.
-
 A news item file's content will consist of an RFC 822 style header [#rfc-822]_
 followed by the main body of the message as plain text. This GLEP defines
 various optional and mandatory headers. Future GLEPs may propose new headers —
 tools handling these news items must ignore any unrecognised header.
 
+.. Note:: A previous version of this GLEP had required that news items must
+   be signed with a detached OpenPGP signature. This was no longer deemed
+   necessary after moving news items to a Git repository with commit signing,
+   and deployment of full-tree verification per GLEP 74 [#glep-74]_.
+
 News Item Headers
 '
 
@@ -500,6 +497,9 @@ References
  https://www.gentoo.org/glep/glep-0034.html
 .. [#glep-45] GLEP 45: "GLEP date format", Henrik Brix Andersen,
  https://www.gentoo.org/glep/glep-0045.html
+.. [#glep-74] GLEP 74: "Full-tree verification using Manifest files",
+ Michał Górny, Robin Hugh Johnson, Ulrich Müller,
+ https://www.gentoo.org/glep/glep-0074.html
 .. [#iso-639] ISO 639 "Code for the representation of names of languages"
 .. [#ramereth-repo] "Re: [gentoo-dev] GLEP ??: Critical News Reporting", Lance
  Albertson,
-- 
2.15.0


pgpOwZEhtTxGU.pgp
Description: PGP signature