[gentoo-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?

[Duncan]

Luigi Mantellini posted on Fri, 26 Jan 2018 16:02:39 +0100 as excerpted:

> can help?
> 
> https://lwn.net/Articles/74055/

Thanks.  I'd forgotten the (long) post I made there, but while it doesn't 
talk about the GPLv2-only stuff, it certainly reflects the zynot stuff in 
far more detail than I remembered or would write it again here.

(I had more written but deleted it as OT.)

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

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

[R0b0t1]

On Fri, Jan 26, 2018 at 7:48 PM, Michael Orlitzky  wrote:
> On 01/26/2018 06:24 PM, Michał Górny wrote:
>>
>> The alternate option of using file hash has the advantage of having
>> a more balanced split.  Furthermore, since hashes are stored
>> in Manifests using them is zero-cost.  However, this solution has two
>> significant disadvantages:
>>
>> 1. The hash values are unknown for newly-downloaded distfiles, so
>>``repoman`` (or an equivalent tool) would have to use a temporary
>>directory before locating the file in appropriate subdirectory.
>>
>> 2. User-provided distfiles (e.g. for fetch-restricted packages) with
>>hash mismatches would be placed in the wrong subdirectory,
>>potentially causing confusing errors.
>>
>
> The filename proposal sounds fine,

I've had to interact with the distfile server by hand, and would
appreciate it if the files can be maintained in some way that finding
them is obvious without tools.

Every once and a while I navigate to the distfile root and need to
forcefully exit Firefox.

Cheers,
 R0b0t1

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

[Michael Orlitzky]

On 01/26/2018 06:24 PM, Michał Górny wrote:
> 
> The alternate option of using file hash has the advantage of having
> a more balanced split.  Furthermore, since hashes are stored
> in Manifests using them is zero-cost.  However, this solution has two
> significant disadvantages:
> 
> 1. The hash values are unknown for newly-downloaded distfiles, so
>``repoman`` (or an equivalent tool) would have to use a temporary
>directory before locating the file in appropriate subdirectory.
> 
> 2. User-provided distfiles (e.g. for fetch-restricted packages) with
>hash mismatches would be placed in the wrong subdirectory,
>potentially causing confusing errors.
> 

The filename proposal sounds fine, so this is only academic, but: are
these two points really disadvantages?

What are we worried about in using a temporary directory? Copying across
filesystem boundaries? Except in rare cases, $DISTDIR itself will be
usable a temporary location (on the same filesystem), won't it?

For the second point, portage is going to tell me where to put the file,
isn't it? Then no matter what garbage I download, won't portage look for
it in the right place, because where-to-put-it is determined using the
same manifest hash that determines where-to-find-it?

[gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

[Michał Górny]

Hi, everyone.

Here's a little new something we've been silently debating back
in the day, then forgotten about it, then I've written a GLEP about it.
The number's not official yet.

HTML (with plots): https://dev.gentoo.org/~mgorny/tmp/glep-0075.html

---
GLEP: 75
Title: Split distfile mirror directory structure
Author:
Michał Górny ,
Robin H. Johnson 
Type: Standards Track
Status: Draft
Version: 1
Created: 2018-01-26
Las
t-Modified: 2018-01-27
Post-History: 2018-01-27
Content-Type: text/x-rst
--
-

Abstract

This GLEP describes the procedure for splitting the distfiles on mirrors
into multiple directories with the goal of reducing the number of files
in a single directory.


Motivation
==
At the moment, both the package manager and Gentoo mirrors use flat
directory structure to store files.  While this solution usually works,
it does not scale well.  Directories with large number of files usually
have significant performance penalty, unless using filesystems
specifically designed for that purpose.

According to the Gentoo repository state at 2018-01-26 16:23, there
was a total of 62652 unique distfiles in the repository.  While
the users realistically hit around 10% of that, distfile mirrors often
hold even more files --- more so if old distfiles are not wiped
immediately.

While all filesystems used on Linux boxes should be able to cope with
a number that large, they may suffer a performance penalty with even
a few thousand files.  Additionally, if mirrors enable directory indexes
then generating the index imposes both a significant server overhead
and a significant data transfer.  At this moment, the index
of distfiles.gentoo.org has around 17 MiB.

Splitting the distfiles into multiple directories makes it possible
to avoid those problems by reducing the number of files in a single
directory.  For example, splitting the forementioned set of distfiles
into 16 directories that are roughly balanced allows to reduce
the number of files in a single directory to around 4000.  Splitting
them further into 256 directories (16x16) results in 200-300 files
per directory which should avoid any performance problems long-term,
even assuming 300% growth of number of distfiles.


Specification
=
Mirror layout file
--
A mirror adhering to this specification should include a ``layout.conf``
file in the top distfile directory.  This file uses the format
derived from the freedesktop Desktop Entry Specification file format
[#DESKTOP_FORMAT]_.

Before using each Gentoo mirror, the package manager should attempt
to fetch (update) its ``layout.conf`` file and process it to determine
how to use the mirror.  If the file is not present, the package manager
should behave as if it were empty.

The package manager should recognize the sections and keys listed below.
It should ignore any unrecognized sections or keys --- the format
is intended to account for future extensions.

This specification currently defines one section: ``[structure]``.
This section defines one or more repository structure definitions
using sequential integer keys.  The definition keyed as ``0``
is the most preferred structure.  The package manager should use
the first structure format it recognizes as supported, and ignore any
it does not recognize.  If this section is not present, the package
manager should behave as if only ``flat`` structure were supported.

The following structure definitions are supported:

* ``flat`` to indicate the traditional flat structure where all
  distfiles are located in the top directory,

* ``filename-hash  `` to indicate the `filename
  hash structure`_ explained below.


Filename hash structure
---
When using the filename hash structure, the distfiles are split
into directories whose names are derived from the hash of distfile
filename.  This structure has two parameters: *algorithm name*
and *cutoffs* list.

The algorithm name must correspond to a valid Manifest hash name.
An informational list of hashes is included in GLEP 74 [#GLEP74]_,
and the policies for introducing new hashes are covered by GLEP 59
[#GLEP59]_.

The cutoffs list specifies one or more integers separated by colons
(``:``), indicating the number of bits (starting with the most
significant bit) of the hash used to form subsequent subdirectory names.
For example, the list of ``2:4`` would indicate that top-level directory
names are formed using 2 most significant bits of the hash (resulting
in 2² = 4 directories), and each of this directories would have
subdirectories formed using the next 4 bits of the hash (resulting
in 2⁴ = 8 subdirectories each).

The exact algorithm for determining the distfile location follows:

1. Let the distfile filename be **F**.

2. Compute the hash of **F** and store its binary value as **H**.

3. For each integer **C** in cutoff list:

   a. Take **C** most significant bits of **H** and store them as **V**.

   b. 

Re: [gentoo-portage-dev] [PATCH 8/8] eshowkw: Always group Prefix keywords last

[Zac Medico]

On 01/26/2018 12:47 AM, Michał Górny wrote:
> Dnia 26 stycznia 2018 06:45:25 CET, Zac Medico  
> napisał(a):
>> On 01/23/2018 03:25 PM, Alec Warner wrote:
>>>
>>>
>>> On Tue, Jan 23, 2018 at 4:48 PM, Michał Górny >> > wrote:
>>>
>>> Always group all Prefix keywords after other types of keywords.
>> This
>>> not only ensures that fbsd sorts first but more importantly
>> stabilizes
>>> the LHS output between regular and -P variant -- that is, -P
>> always adds
>>> additional keywords at the end.
>>> ---
>>>  pym/gentoolkit/eshowkw/keywords_header.py | 16 ++--
>>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/pym/gentoolkit/eshowkw/keywords_header.py
>>> b/pym/gentoolkit/eshowkw/keywords_header.py
>>> index 41b8ba4..1b64bfd 100644
>>> --- a/pym/gentoolkit/eshowkw/keywords_header.py
>>> +++ b/pym/gentoolkit/eshowkw/keywords_header.py
>>> @@ -142,12 +142,16 @@ class keywords_header:
>>>                                         break
>>>
>>>                 # sort by, in order (to match Bugzilla):
>>> -               # 1. arch, then ~arch
>>> -               # 2. profile stability
>>> -               # 3. short keywords, then long (prefix, fbsd)
>>> -               # 4. keyword name in reverse component order
>>> -               normal.sort(key=lambda kw: (kw in
>>> self.__TESTING_KW_ARCHS,
>>> -                       levels.get(kw, 99), kw.count('-'),
>>> list(reversed(kw.split('-')
>>> +               # 1. non-prefix, then prefix (stable output
>> between
>>> -P and not)
>>> +               # 2. arch, then ~arch
>>> +               # 3. profile stability
>>> +               # 4. short keywords, then long (prefix, fbsd)
>>> +               # 5. keyword name in reverse component order
>>> +               normal.sort(key=lambda kw: (self.__isPrefix(kw),
>>> +                       kw in self.__TESTING_KW_ARCHS,
>>> +                       levels.get(kw, 99),
>>> +                       kw.count('-'),
>>> +                       list(reversed(kw.split('-')
>>>
>>>
>>> I'm a bit sad about this lambda because its ended up a bit long.
>>>
>>> What are your thoughts on splitting it out?
>>
>> The fact that it's a lambda doesn't bother me so much as the
>> inefficiency of regenerating the key on every call. I've found this
>> cute
>> little memodict decorator that will optimize it nicely:
>>
>> http://code.activestate.com/recipes/578231-probably-the-fastest-memoization-decorator-in-the-/
>>
>> def memodict(f):
>>class memodict(dict):
>>def __missing__(self, key):
>>ret = self[key] = f(key)
>>return ret
>>return memodict().__getitem__
> 
> Do you really think saving a few microseconds is worth the added complexity? 
> Because if you do, then I'd rather turn keyword into a class and cache 
> everything properly rather than adding ugly hacks to optimize one call site. 

Actually, memoization is pointless here, because python's sort method
only calls the key function once per element.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?

[Ulrich Mueller]

> On Fri, 26 Jan 2018, Duncan  wrote:

> The switch to GPLv2-only would have been made in the fight for its life 
> that was the Gentoo/Zynot fork, and almost certainly had to do with 
> trying to ensure that the gentoo/x86 tree could not be taken private 
> without community recourse, in an era before GPLv3 existed and there was 
> some uncertainty about what its legal terms were going to be, while those 
> of the GPLv2 were known, it had broad community support, and was at 
> least /somewhat/ legally tested.

The timing isn't quite right, though. The license change for
skel.ebuild happened as early as 2002-05-07. According to [1], the
Zynot fork occured in 2003 (and zwelch got involved with Gentoo not
before June 2002). So maybe the Zynot fork reinforced the decision,
but it cannot be the original reason for the license change.

Ulrich

[1] 
https://web.archive.org/web/20030707080226/http://www.zynot.org:80/info/fork.html


pgpuTb_cPCXsg.pgp
Description: PGP signature

[gentoo-dev] [PATCH 2/2] php-ext-source-r3.eclass: Introduce PHP_EXT_NEEDED_USE

[Brian Evans]

This simplifies the dependencies in an ebuild

@DESCRIPTION:
A list of USE flags to append to each PHP target selected
as a valid USE-dependency string.  The value should be valid
for all targets so USE defaults may be necessary.
Example:
PHP_EXT_NEEDED_USE="mysql?,pdo,pcre(+)"

The PHP dependencies will result in:
php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
---
 eclass/php-ext-source-r3.eclass | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 315ce32887f..96d55f97a55 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -84,6 +84,22 @@ esac
 # @CODE@
 : ${PHP_INI_NAME:=${PHP_EXT_NAME}}
 
+# @ECLASS-VARIABLE: PHP_EXT_NEEDED_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A list of USE flags to append to each PHP target selected
+# as a valid USE-dependency string.  The value should be valid
+# for all targets so USE defaults may be necessary.
+# Example:
+# @CODE
+# PHP_EXT_NEEDED_USE="mysql?,pdo,pcre(+)"
+# @CODE
+#
+# The PHP dependencies will result in:
+# @CODE
+# php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
+# @CODE
+
 
 # Make sure at least one target is installed. First, start a USE
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -96,6 +112,9 @@ for _php_target in ${USE_PHP}; do
REQUIRED_USE+="php_targets_${_php_target} "
_php_slot=${_php_target/php}
_php_slot=${_php_slot/-/.}
+   if [[ ${PHP_EXT_NEEDED_USE} ]] ; then
+   _php_slot+=[${PHP_EXT_NEEDED_USE}]
+   fi
PHPDEPEND+=" php_targets_${_php_target}? ( dev-lang/php:${_php_slot} )"
 done
 
-- 
2.16.1

[gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: Introduce PHP_INI_NAME variable

[Brian Evans]

Currently php-ext-source-r3 saves the enabling ini file as
"${PHP_EXT_NAME}.ini".  This is problematic when foo module needs to be
loaded before bar module as things are read in directory order.

This patch introduces PHP_INI_NAME which defaults to PHP_EXT_NAME for
backwards-compatibility.
---
 eclass/php-ext-source-r3.eclass | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index bc6751562a5..315ce32887f 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: php-ext-source-r3.eclass
@@ -73,6 +73,17 @@ esac
 # the tree.
 [[ -z "${PHP_EXT_SAPIS}" ]] && PHP_EXT_SAPIS="apache2 cli cgi fpm embed phpdbg"
 
+# @ECLASS-VARIABLE: PHP_INI_NAME
+# @DESCRIPTION
+# An optional file name of the saved ini file minis the ini extension
+# This allows ordering of extensions such that one is loaded before
+# or after another.  Defaults to the PHP_EXT_NAME.
+# Example (produces 40-foo.ini file):
+# @CODE@
+# PHP_INI_NAME="40-foo"
+# @CODE@
+: ${PHP_INI_NAME:=${PHP_EXT_NAME}}
+
 
 # Make sure at least one target is installed. First, start a USE
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -295,7 +306,7 @@ php_slot_ini_files() {
local x
for x in ${PHP_EXT_SAPIS} ; do
if [[ -f "${EPREFIX}/etc/php/${x}-${1}/php.ini" ]] ; then
-   slot_ini_files+=" 
etc/php/${x}-${1}/ext/${PHP_EXT_NAME}.ini"
+   slot_ini_files+=" 
etc/php/${x}-${1}/ext/${PHP_INI_NAME}.ini"
fi
done
 
@@ -324,7 +335,7 @@ php-ext-source-r3_createinifiles() {
einfo "Added contents of 
${FILESDIR}/${PHP_EXT_INIFILE}" \
  "to ${file}"
fi
-   inidir="${file/${PHP_EXT_NAME}.ini/}"
+   inidir="${file/${PHP_INI_NAME}.ini/}"
inidir="${inidir/ext/ext-active}"
dodir "/${inidir}"
dosym "/${file}" "/${file/ext/ext-active}"
-- 
2.16.1

[gentoo-dev] [RFC] php-ext-source-r3 eclass improvements

[Brian Evans]

The following patches improve the php-ext-source-r3 eclass by introducing
two new variables.

The first allows the configration INI name to vary from a hard-coded default
of the module name.

The second allows USE dependencies to be added to each implementation
similar to python team's PYTHON_REQ_USE.

Comments are welcome

Brian

Re: [gentoo-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?

[Luigi Mantellini]

can help?

https://lwn.net/Articles/74055/


On Fri, Jan 26, 2018 at 3:47 PM, Duncan <1i5t5.dun...@cox.net> wrote:

> Ulrich Mueller posted on Fri, 26 Jan 2018 10:36:49 +0100 as excerpted:
>
> > Apparently licensing of the Gentoo repository was changed from GPL-2+
> > to GPL-2 (only) in 2002, see for example [1] and [2]. I cannot find any
> > announcement or discussion about this.
> >
> > Who was around in 2002 and still remembers what was the rationale?
> >
> > Ulrich
> >
> > [1]
> > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/skel.ebuild?
> id=e67af11c176e4dca33846e65c2649aa456de3099
> > [2]
> > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/header.txt?
> id=dc4dfe8aa903fb467e648da80f8bc3178411a77a
>
> I wasn't around in 2002, but I was researching it by late 2003 and began
> installing in early 2004, by which point Gentoo was suffering the
> aftermath of the bitter split with Zynot and DRobbins was pretty much out
> after having set up the Gentoo Foundation and (what became the) Council.
>
> The Zynot side was focused on embedding and trying to take things
> commercial, while accusing DRobbins of trying to do effectively the same
> thing but with a(n IIRC) gaming focus.
>
> That war has long since been fought and history has played out with
> Gentoo still around and Zynot... not, so I'll try to avoid inserting
> opinion /too/ much (tho I'm sure more recent events played out how they
> did in part due to that history, people around then simply weren't
> interested in what must have sounded rather similar), but...
>
> The switch to GPLv2-only would have been made in the fight for its life
> that was the Gentoo/Zynot fork, and almost certainly had to do with
> trying to ensure that the gentoo/x86 tree could not be taken private
> without community recourse, in an era before GPLv3 existed and there was
> some uncertainty about what its legal terms were going to be, while those
> of the GPLv2 were known, it had broad community support, and was at
> least /somewhat/ legally tested.
>
> Of course as we know it's possible for an entity owning copyright on a
> GPLed work to also sell the rights to use it commercially, with the GPL
> preventing others from doing the same, and that's what both sides were
> accusing the other of trying to do, but as we've seen play out in other
> contexts, the one thing the GPL /does/ do is provide a guarantee that the
> code as-is will remain free, and community improvements to it without a
> CLA letting the entity trying to take it proprietary are then disallowed
> from being used to further that entity's plots.  With the uncertainty
> surrounding the still coming GPLv3 at that point, I believe the intent
> was to ensure that continued.  OTOH, those on the Zynot side would surely
> argue that the intent was to ensure that Zynot couldn't take it private,
> while Gentoo/DRobbins could, especially since at the time copyright was
> assigned to Gentoo.  Of course now we have the advantage of looking back
> it it in history and can see how things turned out, but back then, it was
> far less clear how things would turn out.
>
> --
> 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
>
>
>


-- 
Luigi 'Comio' Mantellini
R - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy

Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantell...@idf-hit.com

Re: [gentoo-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack

[Michał Górny]

W dniu czw, 25.01.2018 o godzinie 22∶55 -0800, użytkownik Zac Medico
napisał:
> On 01/25/2018 10:42 PM, Michał Górny wrote:
> > W dniu czw, 25.01.2018 o godzinie 21∶30 -0800, użytkownik Zac Medico
> > napisał:
> > > On 01/25/2018 01:11 AM, Michał Górny wrote:
> > > > W dniu czw, 25.01.2018 o godzinie 10∶07 +0100, użytkownik Michael
> > > > Haubenwallner napisał:
> > > > > Hi,
> > > > > 
> > > > > ${Subject} ringing a bell here:
> > > > > 
> > > > > dev-db/oracle-instantclient is fetch restricted. As a binary package 
> > > > > with
> > > > > multiple USE options there's a bunch of files to download - even for
> > > > > multiple archs when multilib is active.
> > > > > 
> > > > > So in pkg_nofetch() I'm telling the user whether a file to download is
> > > > > "already here" or "still absent", by testing if $A exists in $DISTDIR.
> > > > > 
> > > > > With ${Subject}, I'm wondering if DISTDIR is created for pkg_nofetch 
> > > > > too.
> > > > > 
> > > > 
> > > > You're doing the wrong thing then. DISTDIR is not allowed
> > > > in pkg_nofetch().
> > > 
> > > It seems to be a common assumption that it's allowed, this command
> > > currently shows 163 results in the gentoo repo:
> > > 
> > > git grep -l pkg_nofetch | xargs grep 'e\(log\|info\).*DISTDIR' | wc -l
> > > 
> > > We should double check with the PMS maintainers to see if they think
> > > it's worthy of an exception. Otherwise, we need to announce the issue on
> > > the gentoo-dev mailing list.
> > 
> > PMS maintainers already verified that back during the first run of those
> > patches. However, we believe the only reasonable way to get this out of
> > pkg_nofetch() is to actually stop it from working, so people would stop
> > using it.
> 
> Okay, that works for me. The patches looks good. Please merge.

Merged, thanks.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?

[Duncan]

Ulrich Mueller posted on Fri, 26 Jan 2018 10:36:49 +0100 as excerpted:

> Apparently licensing of the Gentoo repository was changed from GPL-2+
> to GPL-2 (only) in 2002, see for example [1] and [2]. I cannot find any
> announcement or discussion about this.
> 
> Who was around in 2002 and still remembers what was the rationale?
> 
> Ulrich
> 
> [1]
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/skel.ebuild?
id=e67af11c176e4dca33846e65c2649aa456de3099
> [2]
> https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/header.txt?
id=dc4dfe8aa903fb467e648da80f8bc3178411a77a

I wasn't around in 2002, but I was researching it by late 2003 and began 
installing in early 2004, by which point Gentoo was suffering the 
aftermath of the bitter split with Zynot and DRobbins was pretty much out 
after having set up the Gentoo Foundation and (what became the) Council.

The Zynot side was focused on embedding and trying to take things 
commercial, while accusing DRobbins of trying to do effectively the same 
thing but with a(n IIRC) gaming focus.

That war has long since been fought and history has played out with 
Gentoo still around and Zynot... not, so I'll try to avoid inserting 
opinion /too/ much (tho I'm sure more recent events played out how they 
did in part due to that history, people around then simply weren't 
interested in what must have sounded rather similar), but...

The switch to GPLv2-only would have been made in the fight for its life 
that was the Gentoo/Zynot fork, and almost certainly had to do with 
trying to ensure that the gentoo/x86 tree could not be taken private 
without community recourse, in an era before GPLv3 existed and there was 
some uncertainty about what its legal terms were going to be, while those 
of the GPLv2 were known, it had broad community support, and was at 
least /somewhat/ legally tested.

Of course as we know it's possible for an entity owning copyright on a 
GPLed work to also sell the rights to use it commercially, with the GPL 
preventing others from doing the same, and that's what both sides were 
accusing the other of trying to do, but as we've seen play out in other 
contexts, the one thing the GPL /does/ do is provide a guarantee that the 
code as-is will remain free, and community improvements to it without a 
CLA letting the entity trying to take it proprietary are then disallowed 
from being used to further that entity's plots.  With the uncertainty 
surrounding the still coming GPLv3 at that point, I believe the intent 
was to ensure that continued.  OTOH, those on the Zynot side would surely 
argue that the intent was to ensure that Zynot couldn't take it private, 
while Gentoo/DRobbins could, especially since at the time copyright was 
assigned to Gentoo.  Of course now we have the advantage of looking back 
it it in history and can see how things turned out, but back then, it was 
far less clear how things would turn out.

-- 
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] Why are ebuilds licensed GPL v2 only (no later version)?

[Ulrich Mueller]

Apparently licensing of the Gentoo repository was changed from GPL-2+
to GPL-2 (only) in 2002, see for example [1] and [2]. I cannot find
any announcement or discussion about this.

Who was around in 2002 and still remembers what was the rationale?

Ulrich

[1] 
https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/skel.ebuild?id=e67af11c176e4dca33846e65c2649aa456de3099
[2] 
https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/header.txt?id=dc4dfe8aa903fb467e648da80f8bc3178411a77a


pgpgIH9avZXmc.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 8/8] eshowkw: Always group Prefix keywords last

[Michał Górny]

Dnia 26 stycznia 2018 06:45:25 CET, Zac Medico  napisał(a):
>On 01/23/2018 03:25 PM, Alec Warner wrote:
>> 
>> 
>> On Tue, Jan 23, 2018 at 4:48 PM, Michał Górny > > wrote:
>> 
>> Always group all Prefix keywords after other types of keywords.
>This
>> not only ensures that fbsd sorts first but more importantly
>stabilizes
>> the LHS output between regular and -P variant -- that is, -P
>always adds
>> additional keywords at the end.
>> ---
>>  pym/gentoolkit/eshowkw/keywords_header.py | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>> 
>> diff --git a/pym/gentoolkit/eshowkw/keywords_header.py
>> b/pym/gentoolkit/eshowkw/keywords_header.py
>> index 41b8ba4..1b64bfd 100644
>> --- a/pym/gentoolkit/eshowkw/keywords_header.py
>> +++ b/pym/gentoolkit/eshowkw/keywords_header.py
>> @@ -142,12 +142,16 @@ class keywords_header:
>>                                         break
>> 
>>                 # sort by, in order (to match Bugzilla):
>> -               # 1. arch, then ~arch
>> -               # 2. profile stability
>> -               # 3. short keywords, then long (prefix, fbsd)
>> -               # 4. keyword name in reverse component order
>> -               normal.sort(key=lambda kw: (kw in
>> self.__TESTING_KW_ARCHS,
>> -                       levels.get(kw, 99), kw.count('-'),
>> list(reversed(kw.split('-')
>> +               # 1. non-prefix, then prefix (stable output
>between
>> -P and not)
>> +               # 2. arch, then ~arch
>> +               # 3. profile stability
>> +               # 4. short keywords, then long (prefix, fbsd)
>> +               # 5. keyword name in reverse component order
>> +               normal.sort(key=lambda kw: (self.__isPrefix(kw),
>> +                       kw in self.__TESTING_KW_ARCHS,
>> +                       levels.get(kw, 99),
>> +                       kw.count('-'),
>> +                       list(reversed(kw.split('-')
>> 
>> 
>> I'm a bit sad about this lambda because its ended up a bit long.
>> 
>> What are your thoughts on splitting it out?
>
>The fact that it's a lambda doesn't bother me so much as the
>inefficiency of regenerating the key on every call. I've found this
>cute
>little memodict decorator that will optimize it nicely:
>
>http://code.activestate.com/recipes/578231-probably-the-fastest-memoization-decorator-in-the-/
>
>def memodict(f):
>class memodict(dict):
>def __missing__(self, key):
>ret = self[key] = f(key)
>return ret
>return memodict().__getitem__

Do you really think saving a few microseconds is worth the added complexity? 
Because if you do, then I'd rather turn keyword into a class and cache 
everything properly rather than adding ugly hacks to optimize one call site.

-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack

[Ulrich Mueller]

> On Thu, 25 Jan 2018, Zac Medico wrote:

> It seems to be a common assumption that it's allowed, this command
> currently shows 163 results in the gentoo repo:

> git grep -l pkg_nofetch | xargs grep 'e\(log\|info\).*DISTDIR' | wc -l

There will be little breakage if it is only used in elog messages.

> We should double check with the PMS maintainers to see if they think
> it's worthy of an exception. Otherwise, we need to announce the
> issue on the gentoo-dev mailing list.

PMS had never defined DISTDIR in pkg_* phases. You can see this e.g.
in the PMS version from 2010 [1].

In addition to this, the following clarification of variables' scope
was approved by the council in 2017 [2]:

| 6. Scope and consistency of FILESDIR and DISTDIR
| 
| Old: src_* (not consistent across ebuild phases)
| New: src_*, global scope (consistent). No access to the dir in
| global scope.
|
| Rationale: These variables must be defined in global scope for
| assignment of the PATCHES variable in EAPI 6. However, the actual
| directories are not necessarily present in global scope (e.g., when
| installing from a binary package) and therefore must not be accessed
| there.

Ulrich


[1] https://projects.gentoo.org/pms/3/pms.html#x1-117002
[2] https://bugs.gentoo.org/616206


pgpudLoADGanK.pgp
Description: PGP signature