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
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 ava
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
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 an
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, b
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
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
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 st
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 a
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
> On Mon, 27 Nov 2017, Aaron W Swenson wrote:
> This was deemed no longer necessary…
Applied, thanks.
pgpUVuOaSVc3v.pgp
Description: PGP signature
> 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
>
> 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
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_eb
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 deploy
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``, wher
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``),
> ``m
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" mea
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 detach
---
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-M
20 matches
Mail list logo
