Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[Zac Medico]

On 08/05/2018 09:59 PM, Ulrich Mueller wrote:
>> On Sun, 5 Aug 2018, Zac Medico wrote:
> 
>> --- a/cnf/make.conf.example
>> +++ b/cnf/make.conf.example
>> [...]
> 
>> @@ -119,16 +119,16 @@
>>  # fetched on demand for a given build. If you would like to
>>  # selectively prune obsolete files from this directory, see
>>  # eclean from the gentoolkit package. Note that locations under
>> -# /usr/portage are not necessarily safe for data storage. See the
>> +# /var/db/repos/gentoo are not necessarily safe for data storage. See 
>> the
>>  # PORTDIR documentation for more information.
>> -#DISTDIR=/usr/portage/distfiles
>> +#DISTDIR=/var/db/repos/gentoo/distfiles
> 
> Shouldn't this be /var/cache/distfiles ...
> 
>>  #
>>  # PKGDIR is the location of binary packages that you can have created
>>  # with '--buildpkg' or '-b' while emerging a package. This can get
>>  # up to several hundred megs, or even a few gigs. Note that
>> -# locations under /usr/portage are not necessarily safe for data
>> +# locations under /var/db/repos/gentoo are not necessarily safe for data
>>  # storage. See the PORTDIR documentation for more information.
>> -#PKGDIR=/usr/portage/packages
>> +#PKGDIR=/var/db/repos/gentoo/packages
> 
> ... and /var/cache/binpkgs?

Thanks, I've fixed the /var/cache/{distfiles,binpkgs} locations in v2.

>> --- a/lib/portage/cache/flat_hash.py
>> +++ b/lib/portage/cache/flat_hash.py
>> @@ -144,7 +144,7 @@ class database(fs_template.FsBased):
>>  # Only recurse 1 deep, in order to 
>> avoid iteration over
>>  # entries from another nested cache 
>> instance. This can
>>  # happen if the user nests an overlay 
>> inside
>> -# /usr/portage/local as in bug #302764.
>> +# /var/db/repos/gentoo/local as in bug 
>> #302764.
> 
> Shouldn't a local overlay be in /var/db/repos/local, but never inside
> of the gentoo repo?

Yes, but for a long time /usr/local/portage was somewhat standard, in
fact it's still mentioned here:

https://wiki.gentoo.org/wiki/Custom_repository

Nowadays, repository verification will prevent that from working...

>> --- a/man/make.conf.5
>> +++ b/man/make.conf.5
>> @@ -219,10 +219,10 @@ Use the \fBPORTAGE_RO_DISTDIRS\fR variable to specify 
>> one or
>>  more read-only directories containing distfiles.
>>  
>>  Note
>> -that locations under /usr/portage are not necessarily safe for data storage.
>> +that locations under /var/db/repos/gentoo are not necessarily safe for data 
>> storage.
> 
> IMHO this statement should be made much stronger.

Yes, we could also say something about repository verification here. The
old defaults set a really bad example, so we needed statements like this
to steer people in the right direction.
--
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH 2/2 v2] Update /usr/portage references (bug 378603)

[Zac Medico]

Update all relevant references in docs, messages, and comments
to refer to /var/db/repos/gentoo instead of /usr/portage. Also
update DISTDIR and PKGDIR references to refer to the new
/var/cache/{distfiles,binpkgs} locations.

Bug: https://bugs.gentoo.org/378603
---
[PATCH 2/2 v2] fixes DISTDIR and PKGDIR references to rever to the
new /var/cache/{distfiles,binpkgs} locations

 cnf/make.conf.example| 12 +--
 lib/portage/__init__.py  |  2 +-
 lib/portage/cache/flat_hash.py   |  2 +-
 lib/portage/tests/news/test_NewsItem.py  |  2 +-
 lib/portage/tests/resolver/ResolverPlayground.py |  2 +-
 lib/portage/xml/metadata.py  |  4 ++--
 man/ebuild.5 |  4 ++--
 man/emerge.1 |  6 +++---
 man/make.conf.5  | 20 +-
 man/portage.5| 26 
 man/quickpkg.1   |  2 +-
 repoman/lib/repoman/__init__.py  |  2 +-
 repoman/lib/repoman/checks/herds/herdbase.py |  2 +-
 13 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/cnf/make.conf.example b/cnf/make.conf.example
index 04f3a0274..c16f2afbd 100644
--- a/cnf/make.conf.example
+++ b/cnf/make.conf.example
@@ -14,7 +14,7 @@
 # https://wiki.gentoo.org/wiki/Handbook:X86/Working/USE
 #
 # The available list of use flags with descriptions is in your portage tree.
-# Use 'less' to view them:  --> less /usr/portage/profiles/use.desc <--
+# Use 'less' to view them:  --> less /var/db/repos/gentoo/profiles/use.desc <--
 #
 # 'ufed' is an ncurses/dialog interface available in portage to make handling
 # useflags for you. 'emerge app-portage/ufed'
@@ -111,7 +111,7 @@
 # will protect the default locations of DISTDIR and PKGDIR, but users are
 # warned that any other locations inside PORTDIR are not necessarily safe
 # for data storage.
-#PORTDIR=/usr/portage
+#PORTDIR=/var/db/repos/gentoo
 #
 # DISTDIR is where all of the source code tarballs will be placed for
 # emerges. After packages are built, it is safe to remove any and
@@ -119,16 +119,16 @@
 # fetched on demand for a given build. If you would like to
 # selectively prune obsolete files from this directory, see
 # eclean from the gentoolkit package. Note that locations under
-# /usr/portage are not necessarily safe for data storage. See the
+# /var/db/repos/gentoo are not necessarily safe for data storage. See the
 # PORTDIR documentation for more information.
-#DISTDIR=/usr/portage/distfiles
+#DISTDIR=/var/cache/distfiles
 #
 # PKGDIR is the location of binary packages that you can have created
 # with '--buildpkg' or '-b' while emerging a package. This can get
 # up to several hundred megs, or even a few gigs. Note that
-# locations under /usr/portage are not necessarily safe for data
+# locations under /var/db/repos/gentoo are not necessarily safe for data
 # storage. See the PORTDIR documentation for more information.
-#PKGDIR=/usr/portage/packages
+#PKGDIR=/var/cache/binpkgs
 #
 # PORT_LOGDIR is the location where portage will store all the logs it
 # creates from each individual merge. They are stored as
diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
index 166bfc700..61a240100 100644
--- a/lib/portage/__init__.py
+++ b/lib/portage/__init__.py
@@ -133,7 +133,7 @@ except ImportError as e:
sys.stderr.write("!!! Failed to complete portage imports. There are 
internal modules for\n")
sys.stderr.write("!!! portage and failure here indicates that you have 
a problem with your\n")
sys.stderr.write("!!! installation of portage. Please try a rescue 
portage located in the\n")
-   sys.stderr.write("!!! portage tree under 
'/usr/portage/sys-apps/portage/files/' (default).\n")
+   sys.stderr.write("!!! portage tree under 
'/var/db/repos/gentoo/sys-apps/portage/files/' (default).\n")
sys.stderr.write("!!! There is a README.RESCUE file that details the 
steps required to perform\n")
sys.stderr.write("!!! a recovery of portage.\n")
sys.stderr.write(""+str(e)+"\n\n")
diff --git a/lib/portage/cache/flat_hash.py b/lib/portage/cache/flat_hash.py
index 79783245b..1ec32fb5b 100644
--- a/lib/portage/cache/flat_hash.py
+++ b/lib/portage/cache/flat_hash.py
@@ -144,7 +144,7 @@ class database(fs_template.FsBased):
# Only recurse 1 deep, in order to 
avoid iteration over
# entries from another nested cache 
instance. This can
# happen if the user nests an overlay 
inside
-   # /usr/portage/local as in bug #302764.
+   # /var/db/repos/gentoo/local as in bug 
#302764.
 

Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[Ulrich Mueller]

> On Sun, 5 Aug 2018, Zac Medico wrote:

> --- a/cnf/make.conf.example
> +++ b/cnf/make.conf.example
> [...]

> @@ -119,16 +119,16 @@
>  # fetched on demand for a given build. If you would like to
>  # selectively prune obsolete files from this directory, see
>  # eclean from the gentoolkit package. Note that locations under
> -# /usr/portage are not necessarily safe for data storage. See the
> +# /var/db/repos/gentoo are not necessarily safe for data storage. See the
>  # PORTDIR documentation for more information.
> -#DISTDIR=/usr/portage/distfiles
> +#DISTDIR=/var/db/repos/gentoo/distfiles

Shouldn't this be /var/cache/distfiles ...

>  #
>  # PKGDIR is the location of binary packages that you can have created
>  # with '--buildpkg' or '-b' while emerging a package. This can get
>  # up to several hundred megs, or even a few gigs. Note that
> -# locations under /usr/portage are not necessarily safe for data
> +# locations under /var/db/repos/gentoo are not necessarily safe for data
>  # storage. See the PORTDIR documentation for more information.
> -#PKGDIR=/usr/portage/packages
> +#PKGDIR=/var/db/repos/gentoo/packages

... and /var/cache/binpkgs?

> --- a/lib/portage/cache/flat_hash.py
> +++ b/lib/portage/cache/flat_hash.py
> @@ -144,7 +144,7 @@ class database(fs_template.FsBased):
>   # Only recurse 1 deep, in order to 
> avoid iteration over
>   # entries from another nested cache 
> instance. This can
>   # happen if the user nests an overlay 
> inside
> - # /usr/portage/local as in bug #302764.
> + # /var/db/repos/gentoo/local as in bug 
> #302764.

Shouldn't a local overlay be in /var/db/repos/local, but never inside
of the gentoo repo?

> --- a/man/make.conf.5
> +++ b/man/make.conf.5
> @@ -219,10 +219,10 @@ Use the \fBPORTAGE_RO_DISTDIRS\fR variable to specify 
> one or
>  more read-only directories containing distfiles.
>  
>  Note
> -that locations under /usr/portage are not necessarily safe for data storage.
> +that locations under /var/db/repos/gentoo are not necessarily safe for data 
> storage.

IMHO this statement should be made much stronger.

>  See the \fBPORTDIR\fR documentation for more information.
>  .br
> -Defaults to /usr/portage/distfiles.
> +Defaults to /var/db/repos/gentoo/distfiles.

/var/cache/distfiles

> @@ -800,10 +800,10 @@ to it's category. However, for backward compatibility 
> with the layout
>  used by older versions of portage, if the \fI${PKGDIR}/All\fR directory
>  exists then all packages will be stored inside of it and symlinks to
>  the packages will be created in the category subdirectories. Note
> -that locations under /usr/portage are not necessarily safe for data storage.
> +that locations under /var/db/repos/gentoo are not necessarily safe for data 
> storage.

See above.

>  See the \fBPORTDIR\fR documentation for more information.
>  .br
> -Defaults to /usr/portage/packages.
> +Defaults to /var/db/repos/gentoo/packages.

/var/cache/binpkgs

> --- a/man/quickpkg.1
> +++ b/man/quickpkg.1
> @@ -17,7 +17,7 @@ modified since they were first installed.
>  .br
>  The packages, after being created, will be placed in \fBPKGDIR\fR.
>  This variable is defined in \fBmake.conf\fR(5) and defaults to
> -/usr/portage/packages.
> +/var/db/repos/gentoo/packages.

See above.

[gentoo-portage-dev] [PATCH 1/2] Change /usr/portage council approved locations (bug 378603)

[Zac Medico]

This includes a _compat_upgrade.default_locations script that the
ebuild can call in pkg_preinst in order to maintain backward-compatible
defaults when appropriate. The new defaults are specified in the
summary of the 20180729 council meeting:

Vote: Default locations for the Gentoo repository, distfiles, and
binary packages will be, respectively:
   /var/db/repos/gentoo
   /var/cache/distfiles
   /var/cache/binpkgs
Accepted with 6 yes votes and 1 no vote.

See: https://projects.gentoo.org/council/meeting-logs/20180729-summary.txt
Bug: https://bugs.gentoo.org/378603
---
 cnf/make.globals |  4 +-
 cnf/repos.conf   |  2 +-
 lib/portage/_compat_upgrade/__init__.py  |  0
 lib/portage/_compat_upgrade/default_locations.py | 82 
 4 files changed, 85 insertions(+), 3 deletions(-)
 create mode 100644 lib/portage/_compat_upgrade/__init__.py
 create mode 100644 lib/portage/_compat_upgrade/default_locations.py

diff --git a/cnf/make.globals b/cnf/make.globals
index 04a708af8..bc81a6a73 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -28,8 +28,8 @@ ACCEPT_PROPERTIES="*"
 ACCEPT_RESTRICT="*"
 
 # Miscellaneous paths
-DISTDIR="/usr/portage/distfiles"
-PKGDIR="/usr/portage/packages"
+DISTDIR="/var/cache/distfiles"
+PKGDIR="/var/cache/binpkgs"
 RPMDIR="/usr/portage/rpm"
 
 # Temporary build directory
diff --git a/cnf/repos.conf b/cnf/repos.conf
index 352073cfd..e84840bf2 100644
--- a/cnf/repos.conf
+++ b/cnf/repos.conf
@@ -2,7 +2,7 @@
 main-repo = gentoo
 
 [gentoo]
-location = /usr/portage
+location = /var/db/repos/gentoo
 sync-type = rsync
 sync-uri = rsync://rsync.gentoo.org/gentoo-portage
 auto-sync = yes
diff --git a/lib/portage/_compat_upgrade/__init__.py 
b/lib/portage/_compat_upgrade/__init__.py
new file mode 100644
index 0..e69de29bb
diff --git a/lib/portage/_compat_upgrade/default_locations.py 
b/lib/portage/_compat_upgrade/default_locations.py
new file mode 100644
index 0..484a2dea4
--- /dev/null
+++ b/lib/portage/_compat_upgrade/default_locations.py
@@ -0,0 +1,82 @@
+# Copyright 2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+import re
+
+import portage
+from portage import os
+from portage.const import GLOBAL_CONFIG_PATH
+
+COMPAT_DISTDIR = 'usr/portage/distfiles'
+COMPAT_PKGDIR = 'usr/portage/packages'
+COMPAT_MAIN_REPO = 'usr/portage'
+
+
+def main():
+   """
+   If the current installation is still configured to use any of the
+   legacy default /usr/portage locations, then patch make.globals and
+   repos.conf inside ${ED} to maintain compatible defaults. This is
+   intended to be called from the ebuild as follows:
+
+   pkg_preinst() {
+   python_setup
+   python_export PYTHON_SITEDIR
+   env -u DISTDIR \
+   -u PORTAGE_OVERRIDE_EPREFIX \
+   -u PORTAGE_REPOSITORIES \
+   -u PORTDIR \
+   -u PORTDIR_OVERLAY \
+   
PYTHONPATH="${ED%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" \
+   "${PYTHON}" -m 
portage._compat_upgrade.default_locations || die
+   }
+   """
+   out = portage.output.EOutput()
+   config = portage.settings
+
+   compat_distdir = os.path.join(portage.const.EPREFIX or '/', 
COMPAT_DISTDIR)
+   try:
+   do_distdir = os.path.samefile(config['DISTDIR'], compat_distdir)
+   except OSError:
+   do_distdir = False
+
+   compat_pkgdir = os.path.join(portage.const.EPREFIX or '/', 
COMPAT_PKGDIR)
+   try:
+   do_pkgdir = os.path.samefile(config['PKGDIR'], compat_pkgdir)
+   except OSError:
+   do_pkgdir = False
+
+   compat_main_repo = os.path.join(portage.const.EPREFIX or '/', 
COMPAT_MAIN_REPO)
+   try:
+   do_main_repo = 
os.path.samefile(config.repositories.mainRepoLocation(), compat_main_repo)
+   except OSError:
+   do_main_repo = False
+
+   if do_distdir or do_pkgdir:
+   config_path = os.path.join(os.environ['ED'], 
GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals')
+   with open(config_path) as f:
+   content = f.read()
+   if do_distdir:
+   compat_setting = 
'DISTDIR="{}"'.format(compat_distdir)
+   out.einfo('Setting make.globals default {} for 
backward compatibility'.format(compat_setting))
+   content = re.sub('^DISTDIR=.*$', 
compat_setting, content, flags=re.MULTILINE)
+   if do_pkgdir:
+   compat_setting = 
'PKGDIR="{}"'.format(compat_pkgdir)
+   out.einfo('Setting make.globals default {} for 
backward compatibility'.format(compat_setting))
+   content = 

[gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[Zac Medico]

Update all relevant references in docs, messages, and comments
to refer to /var/db/repos/gentoo instead of /usr/portage.

Bug: https://bugs.gentoo.org/378603
---
 cnf/make.conf.example| 12 +--
 lib/portage/__init__.py  |  2 +-
 lib/portage/cache/flat_hash.py   |  2 +-
 lib/portage/tests/news/test_NewsItem.py  |  2 +-
 lib/portage/tests/resolver/ResolverPlayground.py |  2 +-
 lib/portage/xml/metadata.py  |  4 ++--
 man/ebuild.5 |  4 ++--
 man/emerge.1 |  6 +++---
 man/make.conf.5  | 20 +-
 man/portage.5| 26 
 man/quickpkg.1   |  2 +-
 repoman/lib/repoman/__init__.py  |  2 +-
 repoman/lib/repoman/checks/herds/herdbase.py |  2 +-
 13 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/cnf/make.conf.example b/cnf/make.conf.example
index 04f3a0274..539ea4e9b 100644
--- a/cnf/make.conf.example
+++ b/cnf/make.conf.example
@@ -14,7 +14,7 @@
 # https://wiki.gentoo.org/wiki/Handbook:X86/Working/USE
 #
 # The available list of use flags with descriptions is in your portage tree.
-# Use 'less' to view them:  --> less /usr/portage/profiles/use.desc <--
+# Use 'less' to view them:  --> less /var/db/repos/gentoo/profiles/use.desc <--
 #
 # 'ufed' is an ncurses/dialog interface available in portage to make handling
 # useflags for you. 'emerge app-portage/ufed'
@@ -111,7 +111,7 @@
 # will protect the default locations of DISTDIR and PKGDIR, but users are
 # warned that any other locations inside PORTDIR are not necessarily safe
 # for data storage.
-#PORTDIR=/usr/portage
+#PORTDIR=/var/db/repos/gentoo
 #
 # DISTDIR is where all of the source code tarballs will be placed for
 # emerges. After packages are built, it is safe to remove any and
@@ -119,16 +119,16 @@
 # fetched on demand for a given build. If you would like to
 # selectively prune obsolete files from this directory, see
 # eclean from the gentoolkit package. Note that locations under
-# /usr/portage are not necessarily safe for data storage. See the
+# /var/db/repos/gentoo are not necessarily safe for data storage. See the
 # PORTDIR documentation for more information.
-#DISTDIR=/usr/portage/distfiles
+#DISTDIR=/var/db/repos/gentoo/distfiles
 #
 # PKGDIR is the location of binary packages that you can have created
 # with '--buildpkg' or '-b' while emerging a package. This can get
 # up to several hundred megs, or even a few gigs. Note that
-# locations under /usr/portage are not necessarily safe for data
+# locations under /var/db/repos/gentoo are not necessarily safe for data
 # storage. See the PORTDIR documentation for more information.
-#PKGDIR=/usr/portage/packages
+#PKGDIR=/var/db/repos/gentoo/packages
 #
 # PORT_LOGDIR is the location where portage will store all the logs it
 # creates from each individual merge. They are stored as
diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
index 166bfc700..61a240100 100644
--- a/lib/portage/__init__.py
+++ b/lib/portage/__init__.py
@@ -133,7 +133,7 @@ except ImportError as e:
sys.stderr.write("!!! Failed to complete portage imports. There are 
internal modules for\n")
sys.stderr.write("!!! portage and failure here indicates that you have 
a problem with your\n")
sys.stderr.write("!!! installation of portage. Please try a rescue 
portage located in the\n")
-   sys.stderr.write("!!! portage tree under 
'/usr/portage/sys-apps/portage/files/' (default).\n")
+   sys.stderr.write("!!! portage tree under 
'/var/db/repos/gentoo/sys-apps/portage/files/' (default).\n")
sys.stderr.write("!!! There is a README.RESCUE file that details the 
steps required to perform\n")
sys.stderr.write("!!! a recovery of portage.\n")
sys.stderr.write(""+str(e)+"\n\n")
diff --git a/lib/portage/cache/flat_hash.py b/lib/portage/cache/flat_hash.py
index 79783245b..1ec32fb5b 100644
--- a/lib/portage/cache/flat_hash.py
+++ b/lib/portage/cache/flat_hash.py
@@ -144,7 +144,7 @@ class database(fs_template.FsBased):
# Only recurse 1 deep, in order to 
avoid iteration over
# entries from another nested cache 
instance. This can
# happen if the user nests an overlay 
inside
-   # /usr/portage/local as in bug #302764.
+   # /var/db/repos/gentoo/local as in bug 
#302764.
if depth < 1:
dirs.append((depth+1, p))
continue
diff --git 

[gentoo-portage-dev] [PATCH 0/2] Change /usr/portage council approved locations (bug 378603)

[Zac Medico]

This includes a _compat_upgrade.default_locations script that the
ebuild can call in pkg_preinst in order to maintain backward-compatible
defaults when appropriate. The new defaults are specified in the
summary of the 20180729 council meeting:

Vote: Default locations for the Gentoo repository, distfiles, and
binary packages will be, respectively:
   /var/db/repos/gentoo
   /var/cache/distfiles
   /var/cache/binpkgs
Accepted with 6 yes votes and 1 no vote.

See: https://projects.gentoo.org/council/meeting-logs/20180729-summary.txt
Bug: https://bugs.gentoo.org/378603

Zac Medico (2):
  Change /usr/portage council approved locations (bug 378603)
  Update /usr/portage references (bug 378603)

 cnf/make.conf.example| 12 ++--
 cnf/make.globals |  4 +-
 cnf/repos.conf   |  2 +-
 lib/portage/__init__.py  |  2 +-
 lib/portage/_compat_upgrade/__init__.py  |  0
 lib/portage/_compat_upgrade/default_locations.py | 82 
 lib/portage/cache/flat_hash.py   |  2 +-
 lib/portage/tests/news/test_NewsItem.py  |  2 +-
 lib/portage/tests/resolver/ResolverPlayground.py |  2 +-
 lib/portage/xml/metadata.py  |  4 +-
 man/ebuild.5 |  4 +-
 man/emerge.1 |  6 +-
 man/make.conf.5  | 20 +++---
 man/portage.5| 26 
 man/quickpkg.1   |  2 +-
 repoman/lib/repoman/__init__.py  |  2 +-
 repoman/lib/repoman/checks/herds/herdbase.py |  2 +-
 17 files changed, 128 insertions(+), 46 deletions(-)
 create mode 100644 lib/portage/_compat_upgrade/__init__.py
 create mode 100644 lib/portage/_compat_upgrade/default_locations.py

-- 
2.16.4

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-08-05 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2018-08-05 23:59 UTC.

Removals:

Additions:
app-admin/spectre-meltdown-checker 20180801-23:23 candrews  c048710cd14
app-misc/mkcert20180730-12:37 mrueg cf834f85f7a
app-portage/gverify20180801-20:53 mgornyb640e0eb72b
dev-libs/nsync 20180804-03:14 perfinion 46a0f1dc980
dev-python/ansi20180801-12:59 pinkbyte  5e677253c3a
dev-python/daemonize   20180801-12:55 pinkbyte  76ee312b49e
dev-python/precis-i18n 20180731-23:00 aidecoe   eb3ddb110e1
dev-python/pytest-describe 20180804-20:20 whissi1af688711db
dev-python/python-cstruct  20180731-22:46 zmedico   ad00fcb37f0
dev-python/serverfiles 20180805-16:18 amynkadf9c050629b
media-libs/graphene20180730-09:12 leio  ba8ab2aec22
sys-auth/sakcl 20180805-22:06 cardoe12a00a8b93e
sys-auth/ssh-ldap-pubkey   20180804-20:21 whissi1a2d49ef9bf

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
Added Packages:
sys-auth/sakcl,added,cardoe,20180805-22:06,12a00a8b93e
dev-python/serverfiles,added,amynka,20180805-16:18,df9c050629b
sys-auth/ssh-ldap-pubkey,added,whissi,20180804-20:21,1a2d49ef9bf
dev-python/pytest-describe,added,whissi,20180804-20:20,1af688711db
dev-libs/nsync,added,perfinion,20180804-03:14,46a0f1dc980
app-admin/spectre-meltdown-checker,added,candrews,20180801-23:23,c048710cd14
dev-python/precis-i18n,added,aidecoe,20180731-23:00,eb3ddb110e1
app-portage/gverify,added,mgorny,20180801-20:53,b640e0eb72b
dev-python/ansi,added,pinkbyte,20180801-12:59,5e677253c3a
dev-python/daemonize,added,pinkbyte,20180801-12:55,76ee312b49e
dev-python/python-cstruct,added,zmedico,20180731-22:46,ad00fcb37f0
app-misc/mkcert,added,mrueg,20180730-12:37,cf834f85f7a
media-libs/graphene,added,leio,20180730-09:12,ba8ab2aec22

Done.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 2:35 PM, Rich Freeman  wrote:
> 
>> On Sun, Aug 5, 2018 at 2:12 PM Richard Yao  wrote:
>> 
>> 
>> Prestige is good. We have prestige from our (myself and a few others) work 
>> in upstream ZFS and Gentoo is well respected there.
> 
> Sure, but ZFS on Linux isn't a Gentoo project.
> 
> I'm not saying people who are Gentoo devs can't also do other things.
> Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
> of respect. OpenRC is a big example of this.  From time to time I bump
> into signs of Gentoo on upstream projects (just today that included
> SoapySDRPlay).
> 
> Also, this gives us an opportunity to set an example, in helping to
> ensure the upstream project is maintained in a distro-friendly manner
> where Gentoo is a first class citizen.
> 
> I'm not saying that stuff like this should be banned from infra.  It
> just seems like an unnecessary constraint all-around.  It means that
> the project has to generally follow Gentoo policies/etc, and is
> limited to the tools we provide.  Just something to think about...
Which policies would those be? The upstream projects that we do have as Gentoo 
sub-projects seem to have plenty of freedom.
> 
> 
> -- 
> Rich
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 2:12 PM Richard Yao  wrote:
>
>
> Prestige is good. We have prestige from our (myself and a few others) work in 
> upstream ZFS and Gentoo is well respected there.

Sure, but ZFS on Linux isn't a Gentoo project.

I'm not saying people who are Gentoo devs can't also do other things.
Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
of respect. OpenRC is a big example of this.  From time to time I bump
into signs of Gentoo on upstream projects (just today that included
SoapySDRPlay).

Also, this gives us an opportunity to set an example, in helping to
ensure the upstream project is maintained in a distro-friendly manner
where Gentoo is a first class citizen.

I'm not saying that stuff like this should be banned from infra.  It
just seems like an unnecessary constraint all-around.  It means that
the project has to generally follow Gentoo policies/etc, and is
limited to the tools we provide.  Just something to think about...


-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 1:24 PM, Rich Freeman  wrote:
> 
>> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>> 
>> 
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>> 
> 
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.

Prestige is good. We have prestige from our (myself and a few others) work in 
upstream ZFS and Gentoo is well respected there. You will not hear binary 
package zealots bashing Gentoo in ZFS circles. If a sub-project that touches 
the entire OSS community can be even a tenth as effective as the efforts in ZFS 
have been in eliminating binary package zealotry, it would be well worth it.
> 
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
> 
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
> 
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
> 
> -- 
> Rich
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 1:01 PM, Alec Warner  wrote:
> 
> 
> 
>> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  wrote:
>> 
>> 
>>> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
>>> 
>>> 
>>> 
 On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer  
 wrote:
 On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
 > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
 > Plummer napisał:
 > > So, as you may be aware I've been doing some work on moving bzip2 to an
 > > autotools based build. Recently I've ran into app-crypt/mhash, which is
 > > in a semi-abandoned state (talking with the maintainer on twitter atm),
 > > and I was thinking it may be a good idea to set up a project for 
 > > keeping
 > > these semi-abandoned and really-abandoned libraries and projects up to
 > > date and such.
 > > 
 > > Basically, an upstream for packages who's upstream is either
 > > uncontactable or is otherwise not accepting bug fixes and patches. So
 > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
 > > there are others in this state.
 > > 
 > 
 > So in order to fix problem of semi-abandoned packages, you're creating
 > an indirect herd-like entity that will soon be semi-abandoned itself
 > because people will be dumping random packages into it and afterwards
 > nobody will claim responsibility for them.
 > 
 > -- 
 > Best regards,
 > Michał Górny
 
 No, I mean for packages which are important enough in gentoo to warrant
 such treatment. For instance, every email I've tried for bzip2's
 upstream bounced or recieved no reply. That, I assume, is important
 enough to actually maintain and improve. Any other library which may be
 as important which are as inactive would be added.
 
>>> 
>>> I suspect this might be better done in the Linux foundation itself as they 
>>> have staffing for core components that everyone is using.
>> This would put decision making power into the hands of bureaucrats. I would 
>> rather it remain in a community of volunteers.
> 
> Meh, it doesn't hurt to ask there about interest (they certainly fund 
> development of other components.) Its not like they have to accept, or that 
> declining somehow inhibits this development.
> 
> Part of my frustration is that seemingly "anything open source related can be 
> held in Gentoo" and I'm somewhat against that as I feel it dilutes the Gentoo 
> mission. We are here to make a distribution, not maintain random libraries. 
> If you want to do that feel free; but I don't see a need for that work to be 
> associated with Gentoo.

This could just be done as a downstream effort that carries patches without a 
subproject, but structuring it as a subproject would be a call for 
collaboration with other distributions, which would ultimately benefit us.

>  
>> 
>> I consider upstream development efforts by Gentoo developers to be 
>> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a 
>> priority quite like it affecting a key upstream developer in his day to day 
>> life.
>> 
>> 
>> Also, the Linux Foundation is not embarking on such a project and we clearly 
>> have someone willing to try, so I say that we should go for it. Having 
>> people that wish to take a more active role in upstream development would 
>> not make us any worse off. It is their time to volunteer, so it is not like 
>> they will volunteer it for something else if we discourage them.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:24, Rich Freeman wrote:
> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>>
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>>
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.
>
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
>
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
>
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
>
"Cloud-based Gentoo" - yeah I see *absolutely no issues* with this ...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>

Honestly, other than maybe some prestige I don't really get the point
of hosting random software in Gentoo either.  These days getting a
repo on github or any of its 47 competitors is a few clicks.  You have
zero overhead from a governance standpoint, and a dev can of course
stick ebuilds in the main repository with zero interference.  It seems
a lot cleaner from a copyright/etc standpoint as well.

Even openrc is hosted outside of Gentoo these days, which makes perfect sense.

With the distro as a whole it is a bit more complex, though honestly
I'd love to see us get to a point where the whole thing can be
SECURELY hosted entirely off-infra as well, even if we still chose to
run our own infra.  I just see it as a way to both provide options to
our users and ourselves.  For the latter, being able to host anything
on an outside service means that if some component of infra goes down
we could have mirrors already running and pulling from infra, or if
for some reason somebody sues us or roots us or whatever we can pick
up and move without much fuss.

Running your own wiki/bugzilla/lists/etc was about the only way to do
things in the 90s/etc, but these days there are other options...

-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:01, Alec Warner wrote [excerpted]:
>
>
> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  > wrote:
>
>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner  > wrote:
>
>>
>> I suspect this might be better done in the Linux foundation
>> itself as they have staffing for core components that everyone is
>> using.
> This would put decision making power into the hands of
> bureaucrats. I would rather it remain in a community of volunteers.
>
>
> Meh, it doesn't hurt to ask there about interest (they certainly fund
> development of other components.) Its not like they have to accept, or
> that declining somehow inhibits this development.
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>  
Maintaining a distro is increasingly becoming more a case of fixing
upstream's shortcomings, as they move towards completely-bundled
packages instead of thorough testing. Creating distribution packages,
especially in a source-based distro like Gentoo, requires quite a lot of
testing, and a lot of collating user feedback (in terms of bugs) to make
sure that the packages built do actually *work*.

So no, whilst it does seem on the surface to be a dilution of effort, if
it reduces the overall effort to generate robust packages, and
distributes it across multiple distros and developers, whilst
co-ordination and communication may prove a new challenge, I think this
is complementary to what everyone is trying to achieve.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Alec Warner]

On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  wrote:

>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
>
>
>
> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer 
> wrote:
>
>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
>> > Plummer napisał:
>> > > So, as you may be aware I've been doing some work on moving bzip2 to
>> an
>> > > autotools based build. Recently I've ran into app-crypt/mhash, which
>> is
>> > > in a semi-abandoned state (talking with the maintainer on twitter
>> atm),
>> > > and I was thinking it may be a good idea to set up a project for
>> keeping
>> > > these semi-abandoned and really-abandoned libraries and projects up to
>> > > date and such.
>> > >
>> > > Basically, an upstream for packages who's upstream is either
>> > > uncontactable or is otherwise not accepting bug fixes and patches. So
>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm
>> sure
>> > > there are others in this state.
>> > >
>> >
>> > So in order to fix problem of semi-abandoned packages, you're creating
>> > an indirect herd-like entity that will soon be semi-abandoned itself
>> > because people will be dumping random packages into it and afterwards
>> > nobody will claim responsibility for them.
>> >
>> > --
>> > Best regards,
>> > Michał Górny
>>
>> No, I mean for packages which are important enough in gentoo to warrant
>> such treatment. For instance, every email I've tried for bzip2's
>> upstream bounced or recieved no reply. That, I assume, is important
>> enough to actually maintain and improve. Any other library which may be
>> as important which are as inactive would be added.
>>
>>
> I suspect this might be better done in the Linux foundation itself as they
> have staffing for core components that everyone is using.
>
> This would put decision making power into the hands of bureaucrats. I
> would rather it remain in a community of volunteers.
>

Meh, it doesn't hurt to ask there about interest (they certainly fund
development of other components.) Its not like they have to accept, or that
declining somehow inhibits this development.

Part of my frustration is that seemingly "anything open source related can
be held in Gentoo" and I'm somewhat against that as I feel it dilutes the
Gentoo mission. We are here to make a distribution, not maintain random
libraries. If you want to do that feel free; but I don't see a need for
that work to be associated with Gentoo.


>
> I consider upstream development efforts by Gentoo developers to be
> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a
> priority quite like it affecting a key upstream developer in his day to day
> life.
>

>
> Also, the Linux Foundation is not embarking on such a project and we
> clearly have someone willing to try, so I say that we should go for it.
> Having people that wish to take a more active role in upstream development
> would not make us any worse off. It is their time to volunteer, so it is
> not like they will volunteer it for something else if we discourage them.
>

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Jun 23, 2018, at 9:05 AM, Jonas Stein  wrote:
> 
>> On 2018-06-23 04:57, Marty E. Plummer wrote:
>>> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
>>> So, as you may be aware I've been doing some work on moving bzip2 to an
>>> autotools based build. Recently I've ran into app-crypt/mhash, which is
>>> in a semi-abandoned state (talking with the maintainer on twitter atm),
>>> and I was thinking it may be a good idea to set up a project for keeping
>>> these semi-abandoned and really-abandoned libraries and projects up to
>>> date and such.
>>> 
>>> Basically, an upstream for packages who's upstream is either
>>> uncontactable or is otherwise not accepting bug fixes and patches. So
>>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>>> there are others in this state.
>>> 
>> Or... call it proxy-upstream, to be in line with the current proxy-maint
>> setup?
> 
> Please do not call it proxy-*.
> The invented word proxymaintainer and proxiedmaintainer are not usefull.
> They get always mixed, and are not understood outside of Gentoo.
> assistant developer or trainee developer would have been much more useful.

Until we have a better name, why not call it the GPL project? GPL meaning:

Gentoo
POSIX
Libraries

Misunderstandings from the obvious acronym collision aside, I think the name 
GPL Project would be more appealing to outsiders than “proxy-libs”, which I 
agree would be misunderstood in the worst possible ways.
> 
> Beside the naming I like the idea, that you want to take care for all
> abandoned libs.
> 
> Please note, that you can not generate more manpower by creating a
> project. In 2015 I calculated
In the case of creating a new upstream for key libraries shared by 
distributions, I disagree. As long as other distribution maintainers get on 
board, the deduplication of effort will result in more man power.
> 
> =
> 
> (Number of developers) / (Number of Projects) < 1.4
> 
> =
> 
> Which explains, why most projects today are run by mostly one active person.
> 
> If you find an important library, where upstream is dead, fork it and
> take responsibility for it.
I will call this point 1 of yours.

That sounds like what this project is intended to do.
> 
> It makes no sense to make a pool of dead and important software and
> delegate the responsibility to a team where nobody really knows the
> software.
I will call this point 2 of yours.

It depends on the importance of the software.
> 
> Better pick a library, communicate with maintainers of the other
> distributions and fork it. Keep the library alive in the fork.
I feel like this is the same as 1.
> 
> It is important for the security to let dead projects die.
I feel like this is 2, and that it contradicts 1.
> 
> -- 
> Best,
> Jonas
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Jun 23, 2018, at 6:59 AM, Alec Warner  wrote:
> 
> 
> 
>> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer  
>> wrote:
>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
>> > Plummer napisał:
>> > > So, as you may be aware I've been doing some work on moving bzip2 to an
>> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
>> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
>> > > and I was thinking it may be a good idea to set up a project for keeping
>> > > these semi-abandoned and really-abandoned libraries and projects up to
>> > > date and such.
>> > > 
>> > > Basically, an upstream for packages who's upstream is either
>> > > uncontactable or is otherwise not accepting bug fixes and patches. So
>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>> > > there are others in this state.
>> > > 
>> > 
>> > So in order to fix problem of semi-abandoned packages, you're creating
>> > an indirect herd-like entity that will soon be semi-abandoned itself
>> > because people will be dumping random packages into it and afterwards
>> > nobody will claim responsibility for them.
>> > 
>> > -- 
>> > Best regards,
>> > Michał Górny
>> 
>> No, I mean for packages which are important enough in gentoo to warrant
>> such treatment. For instance, every email I've tried for bzip2's
>> upstream bounced or recieved no reply. That, I assume, is important
>> enough to actually maintain and improve. Any other library which may be
>> as important which are as inactive would be added.
>> 
> 
> I suspect this might be better done in the Linux foundation itself as they 
> have staffing for core components that everyone is using.
This would put decision making power into the hands of bureaucrats. I would 
rather it remain in a community of volunteers.

I consider upstream development efforts by Gentoo developers to be beneficial 
to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite 
like it affecting a key upstream developer in his day to day life.

Also, the Linux Foundation is not embarking on such a project and we clearly 
have someone willing to try, so I say that we should go for it. Having people 
that wish to take a more active role in upstream development would not make us 
any worse off. It is their time to volunteer, so it is not like they will 
volunteer it for something else if we discourage them.
> 
> -A
> 
> 
>