[gentoo-dev] Python 2 cleanup update

2020-09-27 Thread Michał Górny
Hello, everyone.

TL;DR: we're nearing the total annihilation of Python 2 software
in Gentoo.  Most users could safely disable py2 USE flags today.
Python 2 vulns have been patched recently, the interpreter and a few
packages using Python at build time (with no deps) will stay.  Should we
change PYTHON_TARGETS now, or wait some more and just annihilate
the py2 flag from all packages?


Long version:

We're reached the point where the majority of packages relying on py2
have either been ported to py3, removed or masked for removal.
As a result, I've been able to eliminate python2_7 target from the vast
majority of dev-python/* packages.  On their next system upgrade, our
users are going to notice most of Python 2.7 modules gone from their
systems.

However, because of their reverse dependencies a few packages can't lose
their py2.7-iness, and therefore are going to block depcleaning Python
2.7 for now.  These include old versions of setuptools, numpy, pillow,
as well as all versions of cython, nose, pykerberos, pyyaml and their
dependencies.  The major blockers for them are:

- dev-lang/gdl (py entirely optional but the package itself is seriously
broken)

- dev-db/mongodb (py3 version was just stabilized, need to decide how to
clean old versions up)

- games-engines/renpy (no py3 version yet)

- media-tv/kodi (py3 version in alpha)

We plan to have these packages fixed or removed by the deadline. 


However, we already know that there are some packages that use Python 2
at build time and that will keep requiring it past the deadline.
The initial list includes:

- dev-python/pypy* (TODO: need to figure bootstrap out)

- dev-lang/spidermonkey, www-client/seamonkey, www-client/firefox...
(thank you, Mozilla)

- www-client/chromium, dev-qt/qtwebengine... (thank you, Google)

Sadly, the big corps are too busy improving their spying functionality
and creating NIH programming languages to take care of such minor
matters as cleaning up.

The general rule is that py2.7 may remain in packages that use it
at build time only (i.e. don't install anything depending on Python)
and have no dependencies on Python packages (i.e. don't require any
other packages to install py2.7 modules).  Or to put it otherwise,
python-r1 and python-single-r1 will lose py2.7 support entirely, while
python-any-r1 will retain minimal support without dependencies.


This also implies that we're going to keep Python 2.7 itself for as long
as necessary, and patch it if possible.  I should take this opportunity
to remind you that it's quite possible that the interpreter itself has
unknown vulnerabilities.  Only recently I've backported two sec fixes
from Python 3 which no other distribution (including the one promising
paid support for Python 2 for next years) or upstream (including all
these boasting that they're going to maintain Python 2 themselves) has
even noticed (to the best of my knowledge).


An open question is whether we should remove python2_7 from
PYTHON_TARGETS now.  If we do that, it will permit the vast majority of
Gentoo users to depclean Python 2.7 today, independently of how long
the maintainer of renpy is going to block it, with only a few users
having to enable the flag manually.  However, doing this makes sense
only if we're really going to delay the impeding doom long.

I will probably prepare an updated news item for Python 2.7 removal,
to replace the one from February with the updated plan, current
information and helpful tips.


Finally, I would like to thank all the helpful package maintainers, arch
teams and other developers who have made this possible.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-voip/telepathy-haze

2020-09-27 Thread Michał Górny
# Michał Górny  (2020-09-27)
# Discontinued upstream.  Not ported to Python 3, and no patches seem
# readily available.
# Removal in 30 days.  Bug #714636.
net-voip/telepathy-haze

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-util/gtk-builder-convert, games-arcade/diameter, games-board/gnome-hearts, net-analyzer/tcpflow and revdeps

2020-09-26 Thread Michał Górny
# Michał Górny  (2020-09-26)
# These packages still require Python 2.7, or are dependencies of py2.7
# packages.  They are either dead upstream, their Python 3 porting
# efforts are not progressing or their maintainers are simply
# unresponsive.  Please do not remove any packages from this list unless
# you actually port them to Python 3.
# Removal in 30 days.  Please find relevant bugs on tracker bug #694800.
app-misc/klavaro
dev-util/gtk-builder-convert
games-arcade/diameter
games-board/gnome-hearts
net-analyzer/sguil-server
net-analyzer/tcpflow
sci-chemistry/rasmol
sys-apps/gsmartcontrol

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/mysql-python

2020-09-26 Thread Michał Górny
# Michał Górny  (2020-09-26)
# Dead Python 2-only package.  No significant revdeps left.
# Removal in 30 days.  Bug #710024.
dev-python/mysql-python

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/singledispatch

2020-09-26 Thread Michał Górny
# Michał Górny  (2020-09-26)
# Python 2.7 backport with no revdeps left.
# Removal in 30 days.  Bug #734636.
dev-python/singledispatch

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: Python 2 dev-util/scons revdeps (mongo-cxx-driver, a few games, freelan, mapnik, nonolith-connect, lcdtest)

2020-09-26 Thread Michał Górny
# Michał Górny  (2020-09-26)
# These packages either use obsolete scons-utils.eclass API that
# does not support Python 3, or do not support Python 3 at all.
# Their maintainers are unresponsive.  Please do not remove any packages
# from this list unless you actually port them to Python 3.
# Removal in 30 days.  Please find relevant bugs on tracker bug #635934.
dev-libs/mongo-cxx-driver
games-action/btanks
games-emulation/gambatte
games-sports/vdrift
games-strategy/endless-sky
games-strategy/glob2
net-vpn/freelan
sci-geosciences/mapnik
sci-visualization/nonolith-connect
sys-apps/lcdtest

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-libs/shogun

2020-09-25 Thread Michał Górny
# Michał Górny  (2020-09-25)
# Effectively unmaintained.  Not ported to py3.7.  Multiple unresolved
# build failures reported.  No reverse dependencies.
# Removal in 30 days.  Bug #737412.
sci-libs/shogun

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] Subslots for sys-devel/llvm and sys-devel/clang

2020-09-24 Thread Michał Górny
Dnia September 24, 2020 10:35:12 AM UTC, Marek Szuba  
napisał(a):
>Hi all,
>
>While fighting with https://bugs.gentoo.org/743992 I discovered that it
>is necessary for dev-libs/opencl-clang to be rebuilt after EVERY update
>of LLVM and Clang - even such a supposedly trivial one as from 10.0.0
>to
>10.0.1. To the best of my knowledge there is currently no way in-slot
>LLVM/Clang updates to trigger rebuilds of dependent packages, and the
>simplest (only?) way of doing this would be to add subslots to
>sys-devel/llvm and sys-devel/clang ebuilds.
>
>Therefore:
>
>1. Is the above correct? I shall be happy to be proven wrong if there
>is
>a simpler way of achieving this after all;

That's really weird, point releases should not include breaking changes. Could 
you try to figure out why this happens? Also, are you aware if 9.0.0 vs 9.0.1 
had the same problem? Maybe it's one time upstream screwup.

>
>2. If I am not wrong about the current state of affairs, what are your
>opinions about adding subslots to LLVM and Clang ebuilds?

I would like to avoid that, as it would prevent us from using ':=' to match 
slots, and cause unnecessary rebuilds in lots of packages.

A somewhat ugly alternative would be to ~ dep on specific version and make 
revbumps for minor llvm bumps.

--
Best regards, 
Michał Górny



[gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*

2020-09-22 Thread Michał Górny
# Michał Górny  (2020-09-22)
# Poorly maintained suite of NIH packages.  Only live ebuilds left
# for over a year.  This really belongs in an overlay.  Some of them
# depend on deprecated dev-qt/qtwebkit (#684672).
# Removal in 14 days.  Bug #693328.
app-leechcraft/laretz
app-leechcraft/lc-advancednotifications
app-leechcraft/lc-aggregator
app-leechcraft/lc-anhero
app-leechcraft/lc-auscrie
app-leechcraft/lc-azoth
app-leechcraft/lc-bittorrent
app-leechcraft/lc-blasq
app-leechcraft/lc-blogique
app-leechcraft/lc-certmgr
app-leechcraft/lc-core
app-leechcraft/lc-cpuload
app-leechcraft/lc-cstp
app-leechcraft/lc-dbusmanager
app-leechcraft/lc-deadlyrics
app-leechcraft/lc-devmon
app-leechcraft/lc-dolozhee
app-leechcraft/lc-eleeminator
app-leechcraft/lc-fenet
app-leechcraft/lc-gacts
app-leechcraft/lc-glance
app-leechcraft/lc-gmailnotifier
app-leechcraft/lc-historyholder
app-leechcraft/lc-hotsensors
app-leechcraft/lc-hotstreams
app-leechcraft/lc-htthare
app-leechcraft/lc-imgaste
app-leechcraft/lc-intermutko
app-leechcraft/lc-kbswitch
app-leechcraft/lc-kinotify
app-leechcraft/lc-knowhow
app-leechcraft/lc-krigstask
app-leechcraft/lc-lackman
app-leechcraft/lc-lastfmscrobble
app-leechcraft/lc-laughty
app-leechcraft/lc-launchy
app-leechcraft/lc-lemon
app-leechcraft/lc-lhtr
app-leechcraft/lc-liznoo
app-leechcraft/lc-lmp
app-leechcraft/lc-mellonetray
app-leechcraft/lc-monocle
app-leechcraft/lc-musiczombie
app-leechcraft/lc-nacheku
app-leechcraft/lc-netstoremanager
app-leechcraft/lc-networkmonitor
app-leechcraft/lc-newlife
app-leechcraft/lc-ooronee
app-leechcraft/lc-otlozhu
app-leechcraft/lcpackgen
app-leechcraft/lc-pintab
app-leechcraft/lc-pogooglue
app-leechcraft/lc-popishu
app-leechcraft/lc-poshuku
app-leechcraft/lc-qrosp
app-leechcraft/lc-rosenthal
app-leechcraft/lc-sb2
app-leechcraft/lc-scroblibre
app-leechcraft/lc-secman
app-leechcraft/lc-seekthru
app-leechcraft/lc-summary
app-leechcraft/lc-sysnotify
app-leechcraft/lc-tabsessmanager
app-leechcraft/lc-tabslist
app-leechcraft/lc-touchstreams
app-leechcraft/lc-tpi
app-leechcraft/lc-vrooby
app-leechcraft/lc-xproxy
app-leechcraft/lc-xtazy
app-leechcraft/leechcraft-meta
app-leechcraft/liblaretz
virtual/leechcraft-browser
virtual/leechcraft-downloader-http
virtual/leechcraft-notifier
virtual/leechcraft-quark-sideprovider
virtual/leechcraft-search-show
virtual/leechcraft-storage-device-manager
virtual/leechcraft-task-show
virtual/leechcraft-trayarea
virtual/leechcraft-wysiwyg-editor

eclass/leechcraft.eclass

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-libs/plotmm, sci-physics/h2o-gtk

2020-09-22 Thread Michał Górny
# Michał Górny  (2020-09-22)
# sci-libs/plotmm is unmaintained.  It had its last release in 2005.
# It has no chances of porting to GTK+3.  It suffers from major compiler
# warnings.
#
# sci-physics/h2o-gtk is its only reverse dependency.  It crashes
# on start, possibly because of problems with plotmm.  I have
# no intention of rewriting it right now.
#
# Removal in 30 days.  Bug #744073.
sci-libs/plotmm
sci-physics/h2o-gtk

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/flask-themes

2020-09-22 Thread Michał Górny
# Michał Górny  (2020-09-22)
# No activity since Jan 2019.  Broken with current versions of werkzeug.
# Removal in 30 days.  Bug #743259.
dev-python/flask-themes

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: games-board/pouetchess

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Last release in 2006.  Requires Python 2 SCons to build.
# Removal in 30 days.  Bug #677622.
games-board/pouetchess

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: x11-misc/ipager

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Unmaintained.  Homepage gone.  Not bumped since its initial addition
# in 2008.  Uses SCons incorrectly and fails to build.
# Removal in 30 days.  Bug #677446.
x11-misc/ipager

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/configparser, dev-python/functools32

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backports with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/configparser
dev-python/functools32

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/backports-functools-lru-cache, dev-python/enum34

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backports with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/backports-functools-lru-cache
dev-python/enum34

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-tv/plex-media-server

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Bundles vulnerable version of Python 2.7, also boost and other
# libraries in undetermined versions.  Simultaneously blocks removal
# of Python 2.7 packages.
# Removal in 30 days.  Bug #735396.
media-tv/plex-media-server

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/ipaddress

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backports with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/ipaddress

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/futures

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backport with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/futures

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pyogg, dev-python/python-fchksum

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Obsolete Python 2 packages with no revdeps.
# Removal in 30 days.  Bug #743727.
dev-python/pyogg
dev-python/python-fchksum

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/subprocess32

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backport with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/subprocess32

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pathlib

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Python 2 backport with no revdeps left.
# Removal in 30 days.  Bug #743724.
dev-python/pathlib

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/cliapp, dev-python/coverage-test-runner, dev-python/ttystatus

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Unmaintained NIH libraries for app-backup/genbackupdata that is masked
# for removal.
# Removal in 30 days.  Bug #743721.
dev-python/cliapp
dev-python/coverage-test-runner
dev-python/ttystatus

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: gnome-base/libgnome-keyring

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Obsolete library, replaced by app-crypt/libsecret.  All remaining
# revdeps have been masked.  Requires Python 2.
# Removal in 30 days.  Bug #713010.
gnome-base/libgnome-keyring

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: gnome-base/libbonoboui, gnome-base/libgnome, gnome-base/libgnomeui

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Obsolete GNOME libraries.  All remaining revdeps have been lastrited.
# Removal in 30 days.  Bug #726784.
gnome-base/libbonoboui
gnome-base/libgnome
gnome-base/libgnomeui

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-misc/gwget

2020-09-20 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Abandoned upstream, homepage gone.  Last release in 2009.  Uses
# deprecated gnome-base/libgnomeui.  Arch apparently has patches to keep
# it alive, if anyone wants to.
# Removal in 30 days.  Bug #726796.
net-misc/gwget

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: next batch of py2 packages

2020-09-19 Thread Michał Górny
# Michał Górny  (2020-09-19)
# These packages (or package versions) still require Python 2.7.
# They are either dead upstream, their Python 3 porting efforts are
# not progressing or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port them to Python 3.
# Removal in 30 days.  Please find relevant bugs on tracker bug #694800.
app-admin/github-backup-utils
app-backup/genbackupdata
app-i18n/pology
app-pda/gtkpod
app-text/pdf2djvu
app-text/sgmltools-lite
dev-util/anjuta
dev-util/gyp
app-i18n/mozc
sci-libs/magma
sys-firmware/nvidia-firmware

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH 2/2] distutils-r1.eclass: Remove obsolete DISTUTILS_USE_SETUPTOOLS check

2020-09-18 Thread Michał Górny
The DISTUTILS_USE_SETUPTOOLS check is now done in install-qa-check.d,
so remove the duplicate.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 42 --
 1 file changed, 42 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index e0e7a945ab87..25cb67b78a31 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -455,47 +455,6 @@ distutils_enable_tests() {
return 0
 }
 
-# @FUNCTION: _distutils-r1_verify_use_setuptools
-# @INTERNAL
-# @DESCRIPTION:
-# Check setup.py for signs that DISTUTILS_USE_SETUPTOOLS have been set
-# incorrectly.
-_distutils_verify_use_setuptools() {
-   [[ ${DISTUTILS_OPTIONAL} ]] && return
-   [[ ${DISTUTILS_USE_SETUPTOOLS} == manual ]] && return
-   [[ ${DISTUTILS_USE_SETUPTOOLS} == pyproject.toml ]] && return
-
-   # ok, those are cheap greps.  we can try toimprove them if we hit
-   # false positives.
-   local expected=no
-   if [[ ${CATEGORY}/${PN} == dev-python/setuptools ]]; then
-   # as a special case, setuptools provides itself ;-)
-   :
-   elif grep -E -q -s '(from|import)\s+setuptools' setup.py; then
-   if grep -E -q -s 'entry_points\s*=' setup.py; then
-   expected=rdepend
-   elif grep -F -q -s '[options.entry_points]' setup.cfg; then
-   expected=rdepend
-   elif grep -F -q -s '[entry_points]' setup.cfg; then  # pbr
-   expected=rdepend
-   else
-   expected=bdepend
-   fi
-   fi
-
-   if [[ ${DISTUTILS_USE_SETUPTOOLS} != ${expected} ]]; then
-   if [[ ! ${_DISTUTILS_SETUPTOOLS_WARNED} ]]; then
-   _DISTUTILS_SETUPTOOLS_WARNED=1
-   local def=
-   [[ ${DISTUTILS_USE_SETUPTOOLS} == bdepend ]] && def=' 
(default?)'
-
-   eqawarn "DISTUTILS_USE_SETUPTOOLS value is probably 
incorrect"
-   eqawarn "  value:
DISTUTILS_USE_SETUPTOOLS=${DISTUTILS_USE_SETUPTOOLS}${def}"
-   eqawarn "  expected: 
DISTUTILS_USE_SETUPTOOLS=${expected}"
-   fi
-   fi
-}
-
 # @FUNCTION: esetup.py
 # @USAGE: [...]
 # @DESCRIPTION:
@@ -518,7 +477,6 @@ esetup.py() {
[[ ${EAPI} != [45] ]] && die_args+=( -n )
 
[[ ${BUILD_DIR} ]] && _distutils-r1_create_setup_cfg
-   _distutils_verify_use_setuptools
 
set -- "${EPYTHON:-python}" setup.py "${mydistutilsargs[@]}" "${@}"
 
-- 
2.28.0




[gentoo-dev] [PATCH 1/2] install-qa-check.d: add DISTUTILS_USE_SETUPTOOLS check

2020-09-18 Thread Michał Górny
Move DISTUTILS_USE_SETUPTOOLS check from distutils-r1.eclass to install
QA checks, and rewrite it to use installed egg-info rather than greps
on input files.  This produces less false positives, particularly
in packages that use boilerplate empty 'entry_points' in their setup
script or configuration file.

We also no longer require explicit setuptools RDEPEND for packages using
other entry point types than console_scripts -- instead, we assume that
the package consuming these entry points will bring setuptools
as necessary.

The rough idea is to look at egg-info metadata installed by distutils
or setuptools.  Plain distutils installs it as a regular file, while
setuptools as a directory, and that's how we distinguish the two.
For setuptools, we additionally grep entry_points.txt for
`[console_scripts]`, and require RDEPEND when they are present.

Signed-off-by: Michał Górny 
---
 .../60distutils-use-setuptools| 60 +++
 1 file changed, 60 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60distutils-use-setuptools

diff --git a/metadata/install-qa-check.d/60distutils-use-setuptools 
b/metadata/install-qa-check.d/60distutils-use-setuptools
new file mode 100644
index ..db07212cce48
--- /dev/null
+++ b/metadata/install-qa-check.d/60distutils-use-setuptools
@@ -0,0 +1,60 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: verify correctness of DISTUTILS_USE_SETUPTOOLS
+# Maintainer: Python project 
+
+get_expected_distutils_use_setuptools() {
+   local sitedir=${D}$(python_get_sitedir)
+   local egg new_expected
+   while read -d $'\0' -r egg; do
+   if [[ -f ${egg} ]]; then
+   # if .egg-info is a file, it's plain distutils
+   new_expected=no
+   elif grep -q -s -F '[console_scripts]' "${egg}"/entry_points.txt
+   then
+   # entry_points == we need rdepend
+   new_expected=rdepend
+   else
+   new_expected=bdepend
+   fi
+
+   if [[ ${expected} && ${new_expected} != ${expected} ]]; then
+   expected=integrity-error
+   else
+   expected=${new_expected}
+   fi
+   done < <(find "${sitedir}" -name '*.egg-info' -print0)
+}
+
+distutils_use_setuptools_check() {
+   # applicable only to ebuilds inheriting distutils-r1
+   [[ ${_DISTUTILS_R1} ]] || return
+   # 'manual' means no checking
+   [[ ${DISTUTILS_USE_SETUPTOOLS} == manual ]] && return
+   # pyproject.toml is verified by using it
+   [[ ${DISTUTILS_USE_SETUPTOOLS} == pyproject.toml ]] && return
+
+   local expected
+   _distutils-r1_run_foreach_impl get_expected_distutils_use_setuptools
+
+   if [[ ${expected} == integrity-error ]]; then
+   eerror "DISTUTILS_USE_SETUPTOOLS integrity error!"
+   eerror "expected was:${expected}"
+   eerror "new_expected is: ${new_expected}"
+   eerror "Please report a bug about this and CC python@"
+   elif [[ ${DISTUTILS_USE_SETUPTOOLS} != ${expected} ]]; then
+   local def=
+   [[ ${DISTUTILS_USE_SETUPTOOLS} == bdepend ]] && def=' 
(or unset)'
+
+   eqawarn "DISTUTILS_USE_SETUPTOOLS value is probably 
incorrect"
+   eqawarn "  have: 
DISTUTILS_USE_SETUPTOOLS=${DISTUTILS_USE_SETUPTOOLS}${def}"
+   eqawarn "  expected: 
DISTUTILS_USE_SETUPTOOLS=${expected}"
+   fi
+}
+
+distutils_use_setuptools_check
+
+: # guarantee successful exit
+
+# vim:ft=ebuild
-- 
2.28.0




Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
> Hi Michał,
> 
> Thanks for your efforts.  This looks interesting at the very least, and
> whilst in many cases on posts on this ML I'm on the "don't care" stance,
> this one looks like it could solve some problems for me. 
> net-misc/asterisk + friends will definitely make use of this.
> 
> Two nitpicks below that doesn't really carry significant meaning.
> 
> On 2020/09/16 07:48, Michał Górny wrote:
> 
> > Signed-off-by: Michał Górny 
> > ---
> >  glep-0068.rst | 62 ---
> >  1 file changed, 59 insertions(+), 3 deletions(-)
> > 
> > diff --git a/glep-0068.rst b/glep-0068.rst
> > index d8fc379..5b7e2b9 100644
> > --- a/glep-0068.rst
> > +++ b/glep-0068.rst
> > @@ -4,10 +4,10 @@ Title: Package and category metadata
> >  Author: Michał Górny 
> >  Type: Standards Track
> >  Status: Final
> > -Version: 1.1
> > +Version: 1.2
> >  Created: 2016-03-14
> > -Last-Modified: 2020-05-06
> > -Post-History: 2016-03-16, 2018-02-20
> > +Last-Modified: 2020-09-16
> > +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
> >  Content-Type: text/x-rst
> >  Requires: 67
> >  Replaces: 34, 46, 56
> > @@ -149,6 +149,10 @@ element can contain, in any order:
> >languages (at most one for each language), as detailed
> >in `Slot descriptions`_.
> >  
> > +- at most one  element containing version
> > +  constraints used to determine stabilization candidates, as detailed
> > +  in `Stabilization candidates`_.
> > +
> At most one ...

Do you mean capatilization?  It's following suit with other items here.

> >  - zero or more  elements, possibly restricted
> >to specific package versions (at most one for each version) whose 
> > presence
> >indicates that the appropriate ebuilds are suitable for simultaneously
> > @@ -199,6 +203,25 @@ The  element can contain the following 
> > elements:
> >  - at most one  element describing the role of subslots (all
> >of them) as text.
> >  
> > +Stabilization candidates
> > +
> > +Each  element describes version
> 
> vs each (implies any number).  I'd simply say, "If present, the `` 
> > +constraints used to determine package versions eligible
> > +for stabilization.  Should this element be missing, the tooling assumes
> > +a default of any version with any keywords present (i.e. the equivalent
> > +of ``>=0``).
> > +
> > +The  element can contain the following
> > +elements:
> > +
> > +- one or more  elements, each containing a version
> > +  constraint in the format matching EAPI 0 dependency specification
> > +  with the package category and name parts omitted, e.g. ``<1.7``.
> > +  The tooling considers any ebuild version that satisfies the constraint
> > +  and has any keywords.  If multiple constraints are provided, every one
> > +  of them is matched separately, and multiple stabilization candidates
> > +  can be reported.
> 
> I think it's clear from context that there should be one or more, but
> the language ("can contain" in the leading paragraph) implies all sub
> elements are optional.  Perhaps:
> 
> The ... element:
> 
> - must contain one or more ...
> 
> Which also allows for future "may contain" sub elements.
> 

To be honest, I'm not sure if we should permit or prohibit empty element
in the spec.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 10:26 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote:
> > It has two advantages:
> > 1. It reduces the risk of accidentally leaving it in the stable ebuild.
> 
> Huh, you mean you would remove the PROPERTIES token again, after the
> version has been stabilised? Why?

No, I mean removing it when bumping from version unsuitable to
be a stable candidate to one that is suitable.  What's really
problematic is that this mistake will be easy to miss, especially if
someone relies on pkgcheck entirely to determine when to stabilize
stuff.

> 
> Ebuilds could do conditionals like this (again, an example that would
> work for app-editors/emacs):
> 
> [[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"

Yes, provided that developers will actually do that.

> > 2. It handles specifying multiple stabilization candidates on different
> > branches.  I don't see how ebuilds would do that.
> 
> I don't understand. Why couldn't PROPERTIES be specified in different
> slots?
> 

How would you distinguish the ebuild group that represent the same
upstream branch (i.e. expecting only one report from the group) from
other upstream branches?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Michał Górny
On Wed, 2020-09-16 at 08:18 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote:
>  
> > +- one or more  elements, each containing a version
> > +  constraint in the format matching EAPI 0 dependency specification
> > +  with the package category and name parts omitted, e.g. ``<1.7``.
> 
> That's not a very powerful syntax, so unless I miss something,
> metadata.xml would have to be updated for almost every stable candidate.
> 
> To give an example, released versions of app-editors/emacs have exactly
> two numerical components, while prereleases and release candidates have
> three components or are marked _rc. Both would be impossible to match
> with the proposed syntax.

It's not 'one size fits all'.  It will work for a number of packages,
e.g. XFCE without too frequent updates.  In the end, it's primarily
designed around 'silencing' StableRequest results once they are
reported, i.e. for packages that have long-ish RC periods.

> So IMHO this has no advantage over keeping the information in the ebuild
> (e.g. as a PROPERTIES token).
> 

It has two advantages:

1. It reduces the risk of accidentally leaving it in the stable ebuild.

2. It handles specifying multiple stabilization candidates on different
branches.  I don't see how ebuilds would do that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-15 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 glep-0068.rst | 62 ---
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/glep-0068.rst b/glep-0068.rst
index d8fc379..5b7e2b9 100644
--- a/glep-0068.rst
+++ b/glep-0068.rst
@@ -4,10 +4,10 @@ Title: Package and category metadata
 Author: Michał Górny 
 Type: Standards Track
 Status: Final
-Version: 1.1
+Version: 1.2
 Created: 2016-03-14
-Last-Modified: 2020-05-06
-Post-History: 2016-03-16, 2018-02-20
+Last-Modified: 2020-09-16
+Post-History: 2016-03-16, 2018-02-20, 2020-09-16
 Content-Type: text/x-rst
 Requires: 67
 Replaces: 34, 46, 56
@@ -149,6 +149,10 @@ element can contain, in any order:
   languages (at most one for each language), as detailed
   in `Slot descriptions`_.
 
+- at most one  element containing version
+  constraints used to determine stabilization candidates, as detailed
+  in `Stabilization candidates`_.
+
 - zero or more  elements, possibly restricted
   to specific package versions (at most one for each version) whose presence
   indicates that the appropriate ebuilds are suitable for simultaneously
@@ -199,6 +203,25 @@ The  element can contain the following 
elements:
 - at most one  element describing the role of subslots (all
   of them) as text.
 
+Stabilization candidates
+
+Each  element describes version
+constraints used to determine package versions eligible
+for stabilization.  Should this element be missing, the tooling assumes
+a default of any version with any keywords present (i.e. the equivalent
+of ``>=0``).
+
+The  element can contain the following
+elements:
+
+- one or more  elements, each containing a version
+  constraint in the format matching EAPI 0 dependency specification
+  with the package category and name parts omitted, e.g. ``<1.7``.
+  The tooling considers any ebuild version that satisfies the constraint
+  and has any keywords.  If multiple constraints are provided, every one
+  of them is matched separately, and multiple stabilization candidates
+  can be reported.
+
 USE flag descriptions
 ~
 Each  element describes USE flags of a package (in specific
@@ -378,6 +401,39 @@ package version restrictions and maintainer descriptions 
were also implicitly
 allowed on them. Since neither of the two was allowed by GLEP 46, this
 specification disallows them.
 
+Stabilization candidates
+
+Version 1.2 of the specification adds stabilization candidate versions.
+The primary goal of this is to provide a more fine-grained control
+of tooling reporting stabilization candidates.  Previously, pkgcheck
+reported only the newest keyworded version that was eligible for
+stabilization according to the 30-day testing period.  This had two
+limitations.
+
+Firstly, it did not account for development branches properly
+and reported them as stabilization candidates.  While we could
+technically blacklist ``_alpha``, ``_beta``, ``_rc`` versions,
+this would not work for all packages.  Some GNOME and XFCE packages use
+odd numbers in minor version to indicate development branch.
+On the other hand, there are stagnant packages that stay in pre-release
+state for months, and stabilizing these versions also makes sense.
+
+Secondly, it did not account for software maintaining multiple parallel
+stable branches.  As soon as the newer version became eligible
+for stabilization, new releases of the older branches were not reported.
+In some cases, users are bound to old versions because of dependencies
+(e.g. on Python 2.7).
+
+The proposed ‘whitelist-override’ syntax aims to help with both cases.
+The default preserves current behavior.  A single override such
+as ``<1.7`` can be used to explicitly ignore development branch,
+and request stabilization candidates from earlier versions.  Multiple
+version constraints (say, ``<5.9`` and ``<5.5``) can be used to request
+monitoring multiple upstream branches.
+
+This information can also be consumed by users to opt-out of development
+versions and keep their systems running potential stable candidates.
+
 
 Backwards Compatibility
 ===
-- 
2.28.0




[gentoo-dev] Last rites: dev-python/matplotlib-python2

2020-09-15 Thread Michał Górny
All revdeps are already masked for removal, so let's add it to their
pmask:

# Michał Górny  (2020-07-13)
# Python 2 dev-python/pillow revdeps with extended removal time.
# Also the only revdeps of dev-python/matplotlib-python2.
# Removal in 90 days.  Bug #729672.
dev-python/matplotlib-python2

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] How to stabilize packages with frequent release cycles?

2020-09-15 Thread Michał Górny
Hi,

The regular stabilization workflow works for the majority of packages.
 However, it makes little sense for packages with frequent release
cycles.  Examples of these are boto3/botocore (daily release cycle) or
hypothesis (upstream conflates commits with releases).

When the latest release remains 'latest ~arch' for less than 3 days,
stabilizing it after 30 days makes little sense.  After all, people with
frequent upgrade cycle will test it for no more than that, and people
with infrequent upgrade cycle may miss the version entirely.

In the end, we stabilize an entirely arbitrary version at an arbitrary
point in time, and even if users were willing to give it better testing,
they can't guess which version will be the next stable candidate.

Do you have any suggestions how we could improve this?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-09-14 Thread Michał Górny
Dnia September 13, 2020 11:21:28 AM UTC, Andrew Savchenko  
napisał(a):
>On Sat, 29 Aug 2020 21:53:45 +0200 Michał Górny wrote:
>> Thanks to David Michael for the initial patch and upstream fixes.
>> 
>> Signed-off-by: Michał Górny 
>> ---
>>  eclass/acct-group.eclass | 16 +++-
>>  eclass/acct-user.eclass  | 16 +++-
>>  2 files changed, 30 insertions(+), 2 deletions(-)
>> 
>> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
>> index 5550e4a2fb10..dc1562974870 100644
>> --- a/eclass/acct-group.eclass
>> +++ b/eclass/acct-group.eclass
>> @@ -80,7 +80,7 @@ S=${WORKDIR}
>>  
>>  
>>  # << Phase functions >>
>> -EXPORT_FUNCTIONS pkg_pretend pkg_preinst
>> +EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
>>  
>>  # @FUNCTION: acct-group_pkg_pretend
>>  # @DESCRIPTION:
>> @@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
>>  fi
>>  }
>>  
>> +# @FUNCTION: acct-group_src_install
>> +# @DESCRIPTION:
>> +# Installs sysusers.d file for the group.
>> +acct-group_src_install() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +insinto /usr/lib/sysusers.d
>> +newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
>> +printf "g\t%q\t%q\n" \
>> +"${ACCT_GROUP_NAME}" \
>> +"${ACCT_GROUP_ID/#-*/-}"
>> +)
>> +}
>> +
>>  # @FUNCTION: acct-group_pkg_preinst
>>  # @DESCRIPTION:
>>  # Creates the group if it does not exist yet.
>> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
>> index e82f3c56dbbe..f9772c3cb111 100644
>> --- a/eclass/acct-user.eclass
>> +++ b/eclass/acct-user.eclass
>> @@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
>>  # @FUNCTION: acct-user_src_install
>>  # @DESCRIPTION:
>>  # Installs a keep-file into the user's home directory to ensure it
>is
>> -# owned by the package.
>> +# owned by the package, and sysusers.d file.
>>  acct-user_src_install() {
>>  debug-print-function ${FUNCNAME} "${@}"
>>  
>> @@ -321,6 +321,20 @@ acct-user_src_install() {
>>  # created yet
>>  keepdir "${ACCT_USER_HOME}"
>>  fi
>> +
>> +insinto /usr/lib/sysusers.d
>> +newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
>> +printf "u\t%q\t%q\t%q\t%q\t%q\n" \
>> +"${ACCT_USER_NAME}" \
>> +"${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
>> +"${DESCRIPTION//[:,=]/;}" \
>> +"${ACCT_USER_HOME}" \
>> +"${ACCT_USER_SHELL/#-*/-}"
>> +if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
>> +printf "m\t${ACCT_USER_NAME}\t%q\n" \
>> +"${ACCT_USER_GROUPS[@]:1}"
>> +fi
>> +)
>>  }
>
>Why these files are installed unconditionally?
>
>Of course we have a common "small files" policy that USE flags
>should not control small files in packages, such rule was designed
>for common packages where:
>  1) small files are insignificant disk usage compared to a whole
>package;
>  2) an average package takes significant time to rebuild and mass
>rebuild will cause problems during USE flip.
>
>While both arguments are valid for a common packages which provide
>real software, this is not true for very special acct-* packages:
>  1) They may (and usually do) have zero size of installed files,
>this makes sysusers.d stuff an infinite times larger than a
>whole typical acct-* package (it will still be much larger if one
>will consider size of new passw/group records).

Did you realize that your mail is infinite times larger than if you never wrote 
it? 

>  2) acct-* packages are very fast to rebuild, so such price will
>be small compared to other changes necessary when USE="systemd" is
>being flipped.

The price of reading it is also infinite times larger. Not to mention actually 
addressing it.

>
>So it will be reasonable to add USE="systemd" to acct-* eclasses
>to control the changes proposed above.
>
>Best regards,
>Andrew Savchenko


--
Best regards, 
Michał Górny



Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace

2020-09-13 Thread Michał Górny
On Sun, 2020-09-13 at 20:31 +0200, Thomas Deutschmann wrote:
> You maybe all remember what happened to stable-bot: Years ago,
> kensington created stable-bot on his own as PoC which revolutionized the
> way how we do package stabilization in bugzilla. The service run on his
> own infrastructure. Because of the benefit of the service the bot
> provided, arch team’s workflow became dependent on stable-bot. We were
> lucky that stable-bot just worked most of the time until the service was
> down for a while. Nobody was able to help here: Kensigton himself was
> unavailable, nobody had the sources… the end of the story: mgorny
> created nattka which replaced stable-bot.
> 
> However, we are still facing the same problem:

No, we're not.  Don't you see the huge difference between proprietary
closed-source software and free software?

>  Only one person is involved in development

How is that a problem?  It is quite normal that simple tools are
developed primarily by one person, and nattka is not exactly rocket
science.  That said, nobody is stopping others from working on it, there
are surely some improvements to be done.

> and knows how to run it.

Everything is documented and fully contained in puppet.  Deploying it to
new server is as trivial as enabling it on host in question.

> In case something will
> break again and Michał will be unavailable, we can’t just push a fix and
> watch a CI pipeline picking up and deploying new nattka.

Who is 'we' here?  Our Infra does not use 'CI pipelines', it uses Gentoo
packages.  Deploying a new version means bumping the package, waiting
for rsync to distribute it (meh!) and telling puppet to upgrade.  No
buzz words involved, sorry.

>  Instead someone will have to fork repository from Michał’s private
> repository at GitHub, make the changes

It's not private, it's public.  And to be honest, forking it on GitHub
will certainly take less time and effort than dealing with
git.gentoo.org (which needs to happen via Infra).

> and hope that anyone within infrastructure team can
> help to deploy fixed nattka.

Are you suggesting there is a problem with Gentoo Infrastructure?
I really don't see where this is going.  You're concerned that Infra
can't handle it, yet you actually ask to make it more reliant
on Infra...

> This is what the motion is about: This is not about that Gentoo depends
> on single persons or things like that. It’s about the idea to
> *formalize* the requirement that any service and software which is
> critical for Gentoo (think about pkgcore) should live within Gentoo
> namespace (https://gitweb.gentoo.org/), i.e. be accessible for *any*
> Gentoo developer and deployments should be based on these repositories.

You should weigh your words more carefully.  Otherwise, we're going to
end up forking the whole base-system, kernel...

> Or in other words: Make sure that we adhere to social contract even for
> critical software and services Gentoo depends on. So that we will never
> ever face the situation that something we depend on doesn’t work
> anymore.

I fail to see how this is going to actually accomplish the goal.  Having
a different pipeline for committing does not make stuff not break, nor
makes it more likely for people to fix it.  In fact, I dare say having
nattka on GitHub increases the chances of someone (esp. non-developer)
submitting a fix, compared to obscure git.gentoo.org with no clear
contribution pipeline.

>  Taking care of working pipelines before something is broken
> should also help us in case something stops working so we don’t have to
> figure out how to fix and re-deploy when house is already burning (like
> portage: In case Zac can't do a release for some reason, in theory,
> every Gentoo developer would be able to roll a new release).

Please tell me how rolling a new release of nattka is exactly harder
than rolling a release of Portage?  I'm pretty sure most of Gentoo
developers can figure out how to use GitHub, how to fork a repository,
and if they use Python they can probably deal with pretty standard
setup.py.  Deployment can't be done without Infra's help anyway.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-10 Thread Michał Górny
On Thu, 2020-09-10 at 07:35 +0200, Hans de Graaff wrote:
> On Wed, 2020-09-09 at 13:35 +0300, Mikle Kolyada wrote:
> > Closes: https://bugs.gentoo.org/741380
> 
> Could you provide a rationale for removing this? The bug only has a
> single anecdotal report of a user who can run a desktop without it. I'm
> not sure if that is reason enough to remove this. I guess we won't be
> able to figure out easily how many of our desktop profile users are
> actually using LDAP, but changing this may cause surprises and I'm not
> sure if that's warranted.
> 

2020.  Gentoo discovers that people usually don't run LDAP on their
desktops.  Some developers can't believe their eyes!  Gentoo forms
a Working Group to establish whether using LDAP on desktops is really
that uncommon.

This fits nicely with the recently announced fact that Gentoo Foundation
has too much money and is looking for funding requests.  After all, what
could be a better use of Gentoo money than funding the work of a Working
Group trying to establish matters of such great importance as default
USE flags on desktop profiles.

After a lot of debate the Working Group concludes that there is no
conclusive answer whether LDAP should be enabled by default or not.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-sound/freebirth

2020-09-09 Thread Michał Górny
# Michał Górny  (2020-09-09)
# Last release in <2003.  Fails to build (bug #691690).
# Removal in 30 days.  Bug #731008.
media-sound/freebirth

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-crypt/acmebot, app-vim/conque, dev-python/redlock-py, dev-python/root_numpy, dev-python/rootpy, dev-util/setconf, sci-misc/vitables

2020-09-09 Thread Michał Górny
# Michał Górny  (2020-09-09)
# These packages still require Python 3.6.  They are either dead
# upstream or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port them to Python 3.7 *and* 3.8 (3.9 would also be nice).
# Removal in 30 days.  Please find relevant bugs on tracker bug #695996.
app-crypt/acmebot
app-vim/conque
dev-python/redlock-py
dev-python/root_numpy
dev-python/rootpy
dev-util/setconf
sci-misc/vitables

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: next Python 2 batch

2020-09-09 Thread Michał Górny
# These packages (or package versions) still require Python 2.7.
# They are either dead upstream, their Python 3 porting efforts are
# not progressing or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port them to Python 3.
# Removal in 30 days.  Please find relevant bugs on tracker bug #694800.
app-misc/mswinurl_launcher
app-misc/mtail
app-text/silvercity
dev-libs/qrosspython
dev-python/SchemaObject
dev-python/oauth
dev-ruby/pygments_rb
dev-util/doxy-coverage
dev-util/mpatch
dev-vcs/cvs2svn
dev-vcs/gitstats
games-rpg/adonthell
games-rpg/wastesedge
games-strategy/0ad
media-sound/codecgraph
net-misc/pssh
net-misc/ris-linux
net-wireless/mousejack
net-wireless/python-wifi
sci-biology/amos
sci-biology/embassy-meme
sci-biology/meme
sci-biology/shrimp
sci-misc/gato
sci-physics/rivet
sys-cluster/heartbeat
x11-misc/dsx

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: net-analyzer/mk-livestatus, sci-biology/vienna-rna, sci-libs/gmsh, sys-cluster/ganglia, sys-cluster/ganglia-web, sys-fs/owfs

2020-09-09 Thread Michał Górny
# Michał Górny  (2020-09-09)
# These packages are stuck on Python 2.7.  While the Python dependency
# is optional, I can't test removing it because the packages fail
# to build anyway.
#
# net-analyzer/mk-livestatus: py3 bug #735394, build failure bug #705430
# sci-biology/vienna-rna: py3 bug #735438, build failure bug #707158
# sci-libs/gmsh: py3 bug #735478, build failure bug #708386
# sys-cluster/ganglia: py3 bug #735496, build failure bug #631270
# sys-fs/owfs: py3 bug #735502, build failure bug #707438
net-analyzer/mk-livestatus
sci-biology/vienna-rna
sci-libs/gmsh
sys-cluster/ganglia
sys-cluster/ganglia-web
sys-fs/owfs

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: www-servers/cherokee

2020-09-09 Thread Michał Górny
# Michał Górny  (2020-09-09)
# Multiple unresolved vulnerabilities.  Last release in 2013 (but has
# some activity in git).  Not touched by maintainer since 2015.  Stuck
# on Python 2 (bug #735522) with incorrect eclass usage (bug #710258).
# Apparently broken with openssl-1.1 (bug #674246).
# Removal in 30 days.  Bug #715204.
www-servers/cherokee

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-misc/g15daemon, app-misc/g15{composer,macro,message,mpd,stats}

2020-09-09 Thread Michał Górny
# Michał Górny  (2020-09-09)
# Last release in 2008.  Fails to build with gcc-10 (bug #706712).
# Not ported to Python 3 (bug #735226).  The current revision
# is misconfigured by default (bug #481454), and the newer revision
# is masked for since 2012 (bug #587008).
# Removal in 30 days.  Bug #741382.
app-misc/g15daemon
app-misc/g15composer
app-misc/g15macro
app-misc/g15message
app-misc/g15mpd
app-misc/g15stats

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH 1/2] acct-group.eclass: declare the missing dependency on shadow

2020-09-08 Thread Michał Górny
On Tue, 2020-09-08 at 11:57 -0400, David Michael wrote:
> Signed-off-by: David Michael 
> ---
>  eclass/acct-group.eclass | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> index 19a378e0b06..56e6391ef42 100644
> --- a/eclass/acct-group.eclass
> +++ b/eclass/acct-group.eclass
> @@ -34,8 +34,12 @@
>  if [[ -z ${_ACCT_GROUP_ECLASS} ]]; then
>  _ACCT_GROUP_ECLASS=1
>  
> +# The groupadd utility is called in pkg_preinst.  It should be in IDEPEND.
>  case ${EAPI:-0} in
> - 7) ;;
> + 7)
> + BDEPEND="userland_GNU? ( sys-apps/shadow )"

Nothing from shadow is used in src_install, so this BDEPEND is
unnecessary.

> + RDEPEND="${BDEPEND}"
> + ;;
>   *) die "EAPI=${EAPI:-0} not supported";;
>  esac
>  

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Crypto/GPG-related packages up for grabs

2020-09-07 Thread Michał Górny
Hi,

The following packages are up for grabs due to their maintainer being
MIA.

acct-group/monkeysphere
acct-user/monkeysphere
app-crypt/ekeyd
app-crypt/monkeysphere
app-crypt/nasty
app-crypt/pinentry
app-eselect/eselect-pinentry
dev-libs/libgcrypt
dev-libs/npth
net-misc/sks
www-apps/ampache

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Michał Górny
On Mon, 2020-09-07 at 09:46 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 07 Sep 2020, Michał Górny wrote:
> > +  
> > +If the virtual is being removed along with its second to last
> > +provider, include the virtual in the last-rites mail. However, please
> 
> Maybe write "any of its providers" instead of "its second to last
> provider"? It is simpler and still has the same meaning.

Done.

> 
> > +do not include it in the package.mask entry as users do not need
> > +to be forced to proactively unmerge it. Instead, add it
> > +to package.deprecated to warn developers not to depend on it.
> > +Wait the time appropriate for the last rites.
> > +  

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 ebuild-maintenance/removal/text.xml | 43 +
 1 file changed, 43 insertions(+)

diff --git a/ebuild-maintenance/removal/text.xml 
b/ebuild-maintenance/removal/text.xml
index eabbdaf..3575b5c 100644
--- a/ebuild-maintenance/removal/text.xml
+++ b/ebuild-maintenance/removal/text.xml
@@ -83,6 +83,49 @@ Date:   Tue Oct 3 21:43:03 2017 +1100
   Closes: https://bugs.gentoo.org/629144
 
 
+
+
+
+
+Removing a virtual package
+
+
+
+Virtual packages are generally removed when they have no more than one
+provider left. The removal is preceded by updating the remaining ebuilds
+not to use the virtual. Since virtuals do not install any files, there
+is little value in proactively forcing them to be uninstalled from user
+systems or unnecessarily informing the user about the fact. Therefore,
+an alternative removal process is recommended.
+
+
+
+In order to remove a virtual package, follow the following procedure:
+
+
+
+  
+If the virtual is being removed along with its second to last
+provider, include the virtual in the last-rites mail. However, please
+do not include it in the package.mask entry as users do not need
+to be forced to proactively unmerge it. Instead, add it
+to package.deprecated to warn developers not to depend on it.
+Wait the time appropriate for the last rites.
+  
+  
+Update all ebuilds not to reference the virtual. Since there is
+no urgent need to remove the virtual from user systems
+and the resulting rebuilds would be unnecessary, do not bump ebuilds
+when replacing the dependency.
+  
+  
+Remove the package directly
+  
+  
+Perform the post-removal cleanup, as with regular packages
+  
+
+
 
 
 
-- 
2.28.0




Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-02 Thread Michał Górny
On Tue, 2020-09-01 at 08:06 -0400, Rich Freeman wrote:
> On Tue, Sep 1, 2020 at 7:02 AM Michał Górny  wrote:
> > QA reports provide a list [2] and a graph [3] of packages needing
> > porting.
> 
> These lists would be far more useful if they actually listed the
> maintainer(s) of each package.  Then devs could just grep to discover
> if any of their packages need fixing.
> 
> Otherwise I fear that you're just going to run into the same issue as
> last time - most devs will just wait until you take the time to do
> this and file bugs.
> 

...and done.  Now you can grep by your name.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-portage-dev] [PATCH v2] emerge --search: auto-detect regular expressions (bug 737480)

2020-09-02 Thread Michał Górny
s for matches of the supplied string in the ebuild repository.
>  By default emerge uses a case-insensitive simple search, but you can
> -enable a regular expression search by prefixing the search string with %.
> +enable a regular expression search by prefixing the search string with %
> +(the % prefix can often be omitted if the
> +\fB\-\-regex\-search\-auto\fR option is enabled).
>  For example, \fBemerge \-\-search "%^kde"\fR searches for any package whose
>  name starts with "kde"; \fBemerge \-\-search "%gcc$"\fR searches for any
>  package that ends with "gcc"; \fBemerge \-\-search "office"\fR searches for
> @@ -764,6 +766,14 @@ matching packages due to \fB\-\-rebuild\fR.
>  A space separated list of package names or slot atoms. Emerge will not 
> rebuild
>  packages that depend on matching packages due to \fB\-\-rebuild\fR.
>  .TP
> +.BR "\-\-regex\-search\-auto < y | n >"
> +Enable or disable automatic regular expression detection for search actions.
> +If this option is enabled (the default), then regular expression search
> +is automatically enabled when the search string is a valid regular expression
> +which contains any of these commonly used regular expression characters or
> +character sequences:
> +^ $ * [ ] { } | ? .+
> +.TP
>  .BR \-\-oneshot ", " \-1
>  Emerge as normal, but do not add the packages to the world file
>  for later updating.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-01 Thread Michał Górny
On Tue, 2020-09-01 at 08:06 -0400, Rich Freeman wrote:
> On Tue, Sep 1, 2020 at 7:02 AM Michał Górny  wrote:
> > QA reports provide a list [2] and a graph [3] of packages needing
> > porting.
> 
> These lists would be far more useful if they actually listed the
> maintainer(s) of each package.  Then devs could just grep to discover
> if any of their packages need fixing.
> 
> Otherwise I fear that you're just going to run into the same issue as
> last time - most devs will just wait until you take the time to do
> this and file bugs.

Hmm, I suppose this won't be hard to add.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Please port your packages to Python 3.8

2020-09-01 Thread Michał Górny
Hello,

Following the timeline published earlier (and copied to [1]), Python 3.7
deprecation starts today.  All developers are requested to install
Python 3.8 and start testing their packages against it.  While at it,
testing against Python 3.9 would also be welcome.

QA reports provide a list [2] and a graph [3] of packages needing
porting.  To be honest, the only major nuisance in Python 3.8 I can
recall right now is that 'python-3.8' pkg-config file no longer includes
'-lpython3.8' and packages that need it need to switch to
'python-3.8-embed' instead.  If you can think of other problems, please
ping me and I'll add some tips to python-guide [4] soonish.

As usual, please add or fix tests to your packages.

Python 3.8 is planned to become the default on 2020-12-01.

Thank you all for your hard work!


[1] 
https://wiki.gentoo.org/wiki/Project:Python/Implementations#Implementation_support_timeline
[2] https://qa-reports.gentoo.org/output/gpyutils/37-to-38.txt
[3] https://qa-reports.gentoo.org/output/gpyutils/37-to-38.svg
[4] https://dev.gentoo.org/~mgorny/python-guide/

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-cpp/icnc, dev-db/tokumx, net-fs/nfstest, sys-boot/udk, sys-cluster/pbs-python

2020-09-01 Thread Michał Górny
# Michał Górny  (2020-09-01)
# The following packages are Python 2 only.  All but sys-boot/udk have
# no reverse dependencies; sys-boot/udk's only revdep is sys-boot/refind
# and it removed support for udk in its newest version.  Their
# maintainers have either not replied or requested removing the package.
# Please do not remove the mask unless you port the package to py3.7+.
# Removal in 30 days.  Package bugs found blocking tracker bug #694800.
dev-cpp/icnc
dev-db/tokumx
net-fs/nfstest
sys-boot/udk
sys-cluster/pbs-python

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-text/fbless

2020-09-01 Thread Michał Górny
# Michał Górny  (2020-09-01)
# The GitHub repository is gone and upstream's homepage lists only old
# versions.  Python 2 only.  Debian has a py3 patch but it is incomplete
# and fbless crashes when opening a file.
# Removal in 30 days.  Bug #734578.
app-text/fbless

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-08-29 Thread Michał Górny
On Sat, 2020-08-29 at 21:05 +0100, Alexey Sokolov wrote:
> As this doesn't depend on architecture, why /lib and not /share?
> 

I can only imagine how thrilled systemd authors will be when you ask
them.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files

2020-08-29 Thread Michał Górny
Thanks to David Michael for the initial patch and upstream fixes.

Signed-off-by: Michał Górny 
---
 eclass/acct-group.eclass | 16 +++-
 eclass/acct-user.eclass  | 16 +++-
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 5550e4a2fb10..dc1562974870 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -80,7 +80,7 @@ S=${WORKDIR}
 
 
 # << Phase functions >>
-EXPORT_FUNCTIONS pkg_pretend pkg_preinst
+EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst
 
 # @FUNCTION: acct-group_pkg_pretend
 # @DESCRIPTION:
@@ -116,6 +116,20 @@ acct-group_pkg_pretend() {
fi
 }
 
+# @FUNCTION: acct-group_src_install
+# @DESCRIPTION:
+# Installs sysusers.d file for the group.
+acct-group_src_install() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   insinto /usr/lib/sysusers.d
+   newins - ${CATEGORY}-${ACCT_GROUP_NAME}.conf < <(
+   printf "g\t%q\t%q\n" \
+   "${ACCT_GROUP_NAME}" \
+   "${ACCT_GROUP_ID/#-*/-}"
+   )
+}
+
 # @FUNCTION: acct-group_pkg_preinst
 # @DESCRIPTION:
 # Creates the group if it does not exist yet.
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index e82f3c56dbbe..f9772c3cb111 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -312,7 +312,7 @@ acct-user_pkg_pretend() {
 # @FUNCTION: acct-user_src_install
 # @DESCRIPTION:
 # Installs a keep-file into the user's home directory to ensure it is
-# owned by the package.
+# owned by the package, and sysusers.d file.
 acct-user_src_install() {
debug-print-function ${FUNCNAME} "${@}"
 
@@ -321,6 +321,20 @@ acct-user_src_install() {
# created yet
keepdir "${ACCT_USER_HOME}"
fi
+
+   insinto /usr/lib/sysusers.d
+   newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
+   printf "u\t%q\t%q\t%q\t%q\t%q\n" \
+   "${ACCT_USER_NAME}" \
+   "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
+   "${DESCRIPTION//[:,=]/;}" \
+   "${ACCT_USER_HOME}" \
+   "${ACCT_USER_SHELL/#-*/-}"
+   if [[ ${#ACCT_USER_GROUPS[@]} -gt 1 ]]; then
+   printf "m\t${ACCT_USER_NAME}\t%q\n" \
+   "${ACCT_USER_GROUPS[@]:1}"
+   fi
+   )
 }
 
 # @FUNCTION: acct-user_pkg_preinst
-- 
2.28.0




Re: [gentoo-dev] [PATCH] Add heptapod to remote-id list

2020-08-26 Thread Michał Górny
On Thu, 2020-08-27 at 02:15 +0300, Azamat H. Hackimov wrote:
> Heptapod (https://foss.heptapod.net/) is open-source hosting based on
> GitLab for Mercurial repositories.
> 

Please update the XML Schema as well.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pygtk

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# Dead since 2011.  Frowned upon for years now.  Python 2 only.
# Finally all reverse dependencies are masked.
# Tracker bug #706462.  Removal in 30 days.
dev-python/pygtk

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: Python 3.6 packages from last week's ping

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# These packages still require Python 3.6.  They are either dead
# upstream or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port them to Python 3.7 *and* 3.8 (3.9 would also be nice).
# Removal in 30 days.  Tracker bug #695996.
app-portage/pqlop
app-text/landslide
dev-python/corner
dev-python/dogpile-core
dev-python/girder-client
dev-python/ipynb
dev-python/jira
dev-python/jplephem
dev-python/metakernel
dev-python/natgrid
dev-python/nbdime
dev-python/oct2py
dev-python/octave_kernel
dev-python/pcapy
dev-python/promises
dev-python/pycuda
dev-python/pydotplus
dev-python/pyds9
dev-python/pyflann
dev-python/pygsl
dev-python/pyqt-distutils
dev-python/python-ntpdshm
dev-python/sphinxcontrib-napoleon
dev-python/textfsm
dev-python/whelk
dev-util/molecule
dev-util/molecule-core
dev-util/molecule-plugins
dev-vcs/git-spindle
media-gfx/birdfont
media-gfx/sigal
media-libs/libxmlbird
net-analyzer/nagstamon
net-dns/dnsviz
net-fs/s3ql
net-misc/dmr_utils
net-misc/s3cmd
sci-chemistry/ParmEd
sci-chemistry/freeon
sci-chemistry/openbabel-python
sci-libs/minfx
sci-mathematics/pymc3
sci-physics/qutip
sci-visualization/fityk
sci-visualization/yt
sys-apps/elivepatch-client
sys-apps/elivepatch-server
www-apps/nikola

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: app-office/openoffice-bin

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# Python 2 only.  You can use app-office/libreoffice{,-bin} instead.
# Removal in 30 days.  Bug #715400.
app-office/openoffice-bin

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/faulthandler, dev-python/fdsend

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# Python 2 only.  No reverse dependencies left.
# Removal in 30 days.  Bug #735604.
dev-python/faulthandler
dev-python/fdsend

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: Python 2 packages from last week's ping

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# These packages (or package versions) still require Python 2.7.
# They are either dead upstream, their Python 3 porting efforts are
# not progressing or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port it to Python 3.
# Removal in 30 days.  Tracker bug #694800.
app-emulation/ganeti
app-emulation/ganeti-instance-debootstrap
app-emulation/ganeti-instance-image
app-emulation/virtualbox-bin
app-forensics/openscap
app-misc/email2trac
app-misc/workrave
app-portage/etc-proposals
app-portage/gpytage


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: games-action/openclonk

2020-08-22 Thread Michał Górny
# Michał Górny  (2020-08-22)
# Effectively unmaintained.  Optionally uses Python 2.  I could remove
# that but it fails to build anyway.
# Removal in 30 days.  Bug #646748.
games-action/openclonk

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Michał Górny
On Tue, 2020-08-18 at 11:58 -0400, Mike Gilbert wrote:
> On Tue, Aug 18, 2020 at 11:48 AM Michał Górny  wrote:
> > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote:
> > > Joonas Niilola wrote:
> > > > some of you may already have seen the new packages.gentoo.org page,
> > > >   https://packages.gentoo.org/
> > > 
> > > I had not seen that - that's wonderful!
> > > 
> > > I would just request that /packages/ is removed from the start of
> > > package URLs. I understand how this makes request routing more
> > > complicated, but I consider it a significant usability improvement.
> > > 
> > > 
> > > ..anyway:
> > > 
> > > > I'm suggesting of adding a new metadata flag to our Wiki's
> > > > User:/Project: page which then prints a message to this page saying
> > > > whether the maintainer (be it project or user), "accepts" or "deals
> > > > with" Github contributions. The wording can be a bit better, but it'd be
> > > > there to **notify** our **contributors** whether their time and effort
> > > > will most likely be wasted making a pull request for this particular
> > > > maintainer.
> > > 
> > > I think this is a very good feature.
> > > 
> > > If I ever do become a proper Gentoo developer I will certainly not spend
> > > any time on anything to do with GitHub, and in my current position of
> > > occasional contributor I don't either. The workflow imposed by GitHub
> > > isn't good and it's important to demonstrate other methods.
> > > 
> > 
> > Read: it's important to slap users to satisfy developer's wannabes.
> 
> This sentence makes no sense, but it seems to be saying something rude.
> 
> Would you like to clarify?
> 

If user puts effort to make a good contribution, the developer shouldn't
be rejecting it to 'demonstrate other methods'.  This is the horrible
attitude that kills the project.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Michał Górny
On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote:
> Joonas Niilola wrote:
> > some of you may already have seen the new packages.gentoo.org page,
> >   https://packages.gentoo.org/
> 
> I had not seen that - that's wonderful!
> 
> I would just request that /packages/ is removed from the start of
> package URLs. I understand how this makes request routing more
> complicated, but I consider it a significant usability improvement.
> 
> 
> ..anyway:
> 
> > I'm suggesting of adding a new metadata flag to our Wiki's
> > User:/Project: page which then prints a message to this page saying
> > whether the maintainer (be it project or user), "accepts" or "deals
> > with" Github contributions. The wording can be a bit better, but it'd be
> > there to **notify** our **contributors** whether their time and effort
> > will most likely be wasted making a pull request for this particular
> > maintainer.
> 
> I think this is a very good feature.
> 
> If I ever do become a proper Gentoo developer I will certainly not spend
> any time on anything to do with GitHub, and in my current position of
> occasional contributor I don't either. The workflow imposed by GitHub
> isn't good and it's important to demonstrate other methods.
> 

Read: it's important to slap users to satisfy developer's wannabes.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pyblake2, dev-python/pysha3

2020-08-18 Thread Michał Górny
# Michał Górny  (2020-08-18)
# Backports of hash algorithms that are built-in since Python 3.6.
# No reverse dependencies left.
# Removal in 30 days.  Bug #737712.
dev-python/pyblake2
dev-python/pysha3

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/notify-python

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-17)
# Dead pygtk-2 era library.  No reverse dependencies left.
# Removal in 30 days.  Bug #706480.
dev-python/notify-python

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/robotframework

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Unmaintained.  Not ported to py3.7.  The only revdep is queued
# for removal.
# Removal in 30 days.  Bug #719544.
dev-python/robotframework

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Next Python 3.6 last rite batch next weekend

2020-08-16 Thread Michał Górny
On Sun, 2020-08-16 at 12:20 +0200, Michał Górny wrote:
> Hi, all.
> 
> Just a quick note: I went through unresolved py3.6 bugs today and pinged
> a number of them, adding treecleaner to CC.  Next weekend I'm going to
> last rite all of these packages if revdeps permit.
> 

Forgot an important point: if the package in question has Python support
entirely conditional (e.g. bindings), I will be just removing this
support.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Next Python 3.6 last rite batch next weekend

2020-08-16 Thread Michał Górny
Hi, all.

Just a quick note: I went through unresolved py3.6 bugs today and pinged
a number of them, adding treecleaner to CC.  Next weekend I'm going to
last rite all of these packages if revdeps permit.

Almost all of the relevant bugs were filed in April.  This is a total of
59 bugs.  Some bugs list two closely related packages.

If I made a mistake on one of the bugs, please let me know.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: media-video/photofilmstrip

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Unmaintained.  Not ported to py3.7.  Not bumped for over a year.
# Removal in 30 days.  Bug #737400.
media-video/photofilmstrip

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/sleekxmpp

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Unmaintained.  Broken with py3.7.  Upstream archived the repository.
# No reverse dependencies left.
# Removal in 30 days.  Bug #719554.
dev-python/sleekxmpp

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pyminuit

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Unmaintained.  Not ported to py3.7.  Not bumped since introduction
# in 2015.
# Removal in 30 days.  Bug #719422.
dev-python/pyminuit

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pygpu

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Not maintained since 2017.  Not ported to py3.7.  No reverse
# dependencies.
# Removal in 30 days.  Bug #719412.
dev-python/pygpu

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/maintboot, sys-block/blocks

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Unmaintained.  Not ported to py3.7.  'blocks' is a snapshot from 2013,
# last activity in 2014.  It is the only revdep of 'maintboot'.
# Removal in 30 days.  Bug #718522.
dev-python/maintboot
sys-block/blocks

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/emcee

2020-08-16 Thread Michał Górny
# Michał Górny  (2020-08-16)
# Outdated.  Not tested (successfully) on py3.7.  The current version
# fails tests.  No reverse dependencies.
# Removal in 30 days.  Bug #718814.
dev-python/emcee

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-portage-dev] profile masking

2020-08-14 Thread Michał Górny
On Fri, 2020-08-14 at 15:42 +, Joakim Tjernlund wrote:
> On Fri, 2020-08-14 at 17:31 +0200, Ulrich Mueller wrote:
> > > > > > > On Fri, 14 Aug 2020, Joakim Tjernlund wrote:
> > > When pkgs are masked in the profile, it affects all variants of that
> > > pkgs, even the ones that are in other overlays.
> > > Example:
> > > !!! The following installed packages are masked:
> > > - sys-auth/sssd-::transmode (masked by: package.mask)
> > > /usr/portage/profiles/package.mask:
> > > # Matt Turner  (2020-08-13)
> > > # Masked for testing
> > > My sssd- is now masked.
> > > Could the profile syntax be extended to include syntax allowed in
> > > /etc/portage ? Then one could use the ::gentoo syntax (or so I hope)
> > 
> > The :: syntax is Portage specific and doesn't exist in EAPI 7.
> > So there's no chance to get it into the profile dir anytime soon
> > (because that would imply :: to be added to a future EAPI and the
> > top-level profile dir to be bumped to that EAPI).
> 
> Is profile part of EAPI? masks are not defined/used in ebuilds directly.
> 
> > You could override the mask in your overlay's profile/package.mask
> > instead, using an entry with the "-" operator.
> 
> Yes, I know I can add that in profile/package.mask but I am looking for the 
> bigger
> picture here. This has to stop somehow, there need to be something that limits
> the mask scope to the repo/overlay it is defined.
> 

Why is that?  I dare say the bigger picture needs to include different
mask reasons.  Sure, 'masked for testing' may or may not make little
sense for live ebuilds.  However, 'masked for security issues' may
pretty apply to custom repo ebuilds as well.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Packages up for grabs: sys-fs/fuseiso

2020-08-13 Thread Michał Górny
On Thu, 2020-08-13 at 22:48 +0200, Jaco Kroon wrote:
> Hi,
> 
> On 2020/08/13 22:30, Jonas Stein wrote:
> 
> > Dear all
> > 
> > the following packages are up for grabs after retirement
> > of the proxied maintainer:
> > 
> > sys-fs/fuseiso
> > https://packages.gentoo.org/packages/sys-fs/fuseiso
> > 
> What's wrong with mount -o loop /path/to/iso /path/to/mount/point?

It does require root permissions, for a start.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Python 2.7 cleanup: plan B

2020-08-11 Thread Michał Górny
Hi, everyone.

TL;DR: we might keep Python 2.7 supported as a build-time dependency
of a few packages as necessary, while removing the eclass support for
installing packages for py2.7.


As I've mentioned earlier, the plan is to get rid of Python 2.7 target
support at the beginning of 2021.  The plan was to last rite all
remaining packages failing to support Python 3 at 2021-01-01, and remove
the eclass support on 2021-02-15.  At the same time, the Python
interpreter was going to stay around for as long as necessary.

I've also mentioned that there is a high risk that this will not be
possible because of a few large entities ignoring the problem
and failing to port their build system scripts away from Python 2.
We can't really last rite all major web browsers, and postponing
the deadline indefinitely is not a good solution either.

Therefore, I advise the following plan B: if it is impossible to remove
Python 2.7 support from packages entirely, the support for installing
Python packages for Python 2.7 will be removed.  However, there will be
exemptions granted for build-time dependencies on the Python interpreter
to keep things working, for as long as the interpreter itself is going
to stay.

The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed for
bootstrap on new platforms), Mozilla products, WebKit and WebKit-based
browsers.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Michał Górny
On Mon, 2020-08-10 at 21:55 -0400, Joshua Kinard wrote:
> On 8/10/2020 11:22, William Hubbs wrote:
> > On Mon, Aug 10, 2020 at 12:00:44AM -0400, Joshua Kinard wrote:
> > > On 8/8/2020 14:51, William Hubbs wrote:
> > > > All,
> > > > 
> > > > I would like to propose that we switch the default udev provider on new
> > > > systems from eudev to udev.
> > > > 
> > > > This is not a lastrites, and it will not affect current systems since
> > > > they have to migrate manually. Also, this change can be overridden at
> > > > the profile level if some profile needs eudev (the last time I checked,
> > > > this applies to non-glibc configurations).
> > > > 
> > > > What do people think?
> > > > 
> > > > Thanks,
> > > > 
> > > > William
> > > 
> > > Is eudev broken in some way?  If so, has a bug been filed?  If not, why 
> > > not?
> > > 
> > > If eudev is not broken, then why your proposed fix?
> > 
> > bitrot and bus factor.
> 
> Examples?

I suppose nobody remembers the time (the previous year) where eudev
broke reverse dependencies because of wrong version number, and it took
around 3 months to get a fix (read: changing the version number) into
~arch.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Michał Górny
On Tue, 2020-08-11 at 10:59 +0800, Benda Xu wrote:
> Hi William,
> 
> William Hubbs  writes:
> 
> > No one has offered to switch from eudev to udev and look at
> > regressions. People are asking me to show what features exist in udev
> > that aren't in eudev. I stuck with udev. I don't use eudev so I don't
> > know.
> 
> I don't think imposing a personal preference to the Gentoo default a good
> idea. One person who get stuck with udev does not bring everyone to
> stick with udev.
> 

So why is the current default based on a personal preference?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Michał Górny
On Mon, 2020-08-10 at 09:35 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 09 Aug 2020, William Hubbs wrote:
> > There are roughly 100 commits in the udev master branch since the date
> > of this sync:
> > https://github.com/systemd/systemd/commits/master/src/udev
> 
> And what does this tell us? Commit count isn't very useful as a metric.

Yes, contributor count is a more important metric.  It helps us tell
the original project that has community from fork with a bus factor
of one.

> 
> Do these commits fix any bugs that are still open in eudev? Do they add
> any important features?
> 

We can fork any random project and claim that our fork is better because
we consider it feature complete.  Then we can freely claim that upstream
commits don't fix any real bugs, and new features aren't important.  If
you don't change anything, you don't break anything, right?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Michał Górny
On Mon, 2020-08-10 at 13:52 +0200, Thomas Deutschmann wrote:
> On 2020-08-09 23:14, William Hubbs wrote:
> > Here is something else to consider.
> > 
> > Blueness and any of the other eudev maintainers are doing good work
> > for alternative c library support such as musl. In fact, the musl
> > profiles hard mask sys-fs/udev, so they are covered no matter what
> > happens as a result of this thread.
> > 
> > Eudev is supposed to be udev without systemd along with alternative c
> > library support, but it appears to be behind what eudev offers.
> > 
> > The following commit appears to be the last time eudev synced with udev:
> > 
> > https://github.com/gentoo/eudev/commit/2ab887ec67afd15eb9b0849467f1f9c036a2b6c8
> > 
> > There are roughly 100 commits in the udev master branch since the date of 
> > this
> > sync:
> > 
> > https://github.com/systemd/systemd/commits/master/src/udev
> > 
> > There are several new commits in libudev and udev rules since then as
> > well:
> > 
> > https://github.com/systemd/systemd/commits/master/src/libudev
> > https://github.com/systemd/systemd/commits/master/rules.d
> > 
> > I would like to publically thank Leio for providing me with the
> > information above.
> > 
> > I asked the council for guidance and was told that they don't need to be
> > involved, so I guess the best thing to do now is call for testers.
> > 
> > It would be helpful if people migrate their systems manually from eudev to 
> > udev
> > and report issues.
> > 
> > I'm not a valid test case because I have always run udev.
> 
> This is not answering my questions.
> 
> If anything from above would be valid (like others have asked you for
> bugs and already mentioned that commit count alone don't say anything)
> we wouldn't just be talking about switching default for *new*
> installations. Instead we would need to talk about ditching eudev in
> general...
> 
> So for me it still looks like change for change's sake without a real
> reason.
> 

...or a revert of a change made for change's sake.  In the end, it all
boils down to preference of a single person, and potential of another
person reverting it.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/paver

2020-08-09 Thread Michał Górny
# Michał Górny  (2020-08-09)
# Build tool with no revdeps left.
# Removal in 30 days.  Bug #736517.
dev-python/paver

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Packages up for grabs: www-apps/jekyll-coffeescript, www-apps/jekyll-sass-converter

2020-08-09 Thread Michał Górny
Hello,

I've taken over www-apps/jekyll* for Infra back in the day but I'm no
longer really maintaining it.  Two of the packages have another
maintainer but the two listed below are now maintainer-needed:

www-apps/jekyll-coffeescript
www-apps/jekyll-sass-converter

The first one has a test failure reported, both seem to be up-to-date.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-vcs/git-bz

2020-08-09 Thread Michał Górny
# Michał Górny  (2020-08-09)
# Python 2 only.  No commits since 2015.
# Removal in 30 days.  Bug #735334.
dev-vcs/git-bz

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Michał Górny
On Sat, 2020-08-08 at 21:17 +0100, Roy Bamford wrote:
> With the declared aim from upstream of making udev inseparable from 
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.

Really?  And I've thought that the primary reason was that udev upstream
has removed the 'repeatedly bash the rules until they succeed' feature
that required people to actually fix things.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-portage-dev] [PATCH 1/3] Add cached portage.getpid() function

2020-08-07 Thread Michał Górny
On Fri, 2020-08-07 at 21:08 -0700, Zac Medico wrote:
> Since getpid is a syscall, cache results, and update them
> via an after fork hook.
> 
> Signed-off-by: Zac Medico 
> ---
>  lib/portage/__init__.py   | 14 +++
>  .../tests/process/test_AsyncFunction.py   | 24 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
> index 916c93510..52902ba7d 100644
> --- a/lib/portage/__init__.py
> +++ b/lib/portage/__init__.py
> @@ -14,6 +14,7 @@ try:
>   if not hasattr(errno, 'ESTALE'):
>   # ESTALE may not be defined on some systems, such as interix.
>   errno.ESTALE = -1
> + import multiprocessing.util
>   import re
>   import types
>   import platform
> @@ -368,6 +369,19 @@ _internal_caller = False
>  
>  _sync_mode = False
>  
> +def _fork_watcher(_fork_watcher):
> + _fork_watcher.current_pid = _os.getpid()

I don't really like the idea of putting variables on functions.  Would
there be any problem with using a proper class here?

> +
> +_fork_watcher(_fork_watcher)
> +
> +multiprocessing.util.register_after_fork(_fork_watcher, _fork_watcher)
> +
> +def getpid():
> + """
> + Cached version of os.getpid(). ForkProcess updates the cache.
> + """
> + return _fork_watcher.current_pid
> +
>  def _get_stdin():
>   """
>   Buggy code in python's multiprocessing/process.py closes sys.stdin
> diff --git a/lib/portage/tests/process/test_AsyncFunction.py 
> b/lib/portage/tests/process/test_AsyncFunction.py
> index 55857026d..3b360e02f 100644
> --- a/lib/portage/tests/process/test_AsyncFunction.py
> +++ b/lib/portage/tests/process/test_AsyncFunction.py
> @@ -3,6 +3,7 @@
>  
>  import sys
>  
> +import portage
>  from portage import os
>  from portage.tests import TestCase
>  from portage.util._async.AsyncFunction import AsyncFunction
> @@ -36,3 +37,26 @@ class AsyncFunctionTestCase(TestCase):
>   def testAsyncFunctionStdin(self):
>   loop = asyncio._wrap_loop()
>   loop.run_until_complete(self._testAsyncFunctionStdin(loop))
> +
> + def _test_getpid_fork(self):
> + """
> + Verify that portage.getpid() cache is updated in a forked child 
> process.
> + """
> + loop = asyncio._wrap_loop()
> + proc = AsyncFunction(scheduler=loop, target=portage.getpid)
> + proc.start()
> + proc.wait()
> + self.assertEqual(proc.pid, proc.result)
> +
> + def test_getpid_fork(self):
> + self._test_getpid_fork()
> +
> + def test_getpid_double_fork(self):
> + """
> + Verify that portage.getpid() cache is updated correctly after
> + two forks.
> + """
> + loop = asyncio._wrap_loop()
> + proc = AsyncFunction(scheduler=loop, 
> target=self._test_getpid_fork)
> + proc.start()
> + self.assertEqual(proc.wait(), 0)

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Michał Górny
On Fri, 2020-08-07 at 20:03 +0100, Sergei Trofimovich wrote:
> On Fri, 7 Aug 2020 14:25:04 -0400
> Michael Orlitzky  wrote:
> 
> > When you ignore the devmanual and the pkgcheck warning and the 10+
> > threads I've started about the issue, and make changes like...
> > 
> >   --- a/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
> >   +++ b/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
> >   @@ -1,4 +1,4 @@
> >   -# Copyright 1999-2018 Gentoo Foundation
> >   +# Copyright 1999-2019 Gentoo Authors
> ># Distributed under the terms of the GNU General Public License v2
> > 
> >EAPI=6
> >   @@ -21,8 +21,7 @@ RDEPEND="${RDEPEND}
> >   x11-apps/bitmap
> >   x11-apps/iceauth
> >   x11-apps/luit
> >   -   x11-apps/mkfontdir
> >   -   x11-apps/mkfontscale
> >   +   >=x11-apps/mkfontscale-1.2.0
> >   x11-apps/sessreg
> > 
> > 
> > This is what portage does:
> > 
> >   $ sudo emerge -uDN @world
> >   Password:
> >   Calculating dependencies... done!
> > 
> >   emerge: there are no ebuilds to satisfy "x11-apps/mkfontdir".
> >   (dependency required by "x11-base/xorg-x11-7.4-r3::gentoo"
> >   [installed])
> >   (dependency required by "@selected" [set])
> >   (dependency required by "@world" [argument])
> 
> After PAM virtual removal and a bunch of similar large-scale
> changes done by QA members I assume it's a new norm and
> should be documented as such.
> 

You could also try to understand the difference between the two,
and the purpose in not causing unnecessary rebuilds just to make it
possible to depclean a zero-byte package.  But I suppose being sarcastic
is the new norm and should be documented as such.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-portage-dev] [PATCH] lib/*: Fix useless-return

2020-08-07 Thread Michał Górny
f print_changelog(self):
> @@ -687,7 +683,6 @@ class Display:
>   if ebuild_path_cl is not None:
>   self.changelogs.extend(_calc_changelog(
>   ebuild_path_cl, pkg_info.previous_pkg, 
> pkg.cpv))
> - return
>  
>  
>   def check_system_world(self, pkg):
> diff --git a/lib/portage/elog/mod_custom.py b/lib/portage/elog/mod_custom.py
> index 7cfafeccc..aaf1d3b1b 100644
> --- a/lib/portage/elog/mod_custom.py
> +++ b/lib/portage/elog/mod_custom.py
> @@ -18,4 +18,3 @@ def process(mysettings, key, logentries, fulltext):
>   retval = portage.process.spawn_bash(mylogcmd)
>   if retval != 0:
>   raise portage.exception.PortageException("!!! 
> PORTAGE_ELOG_COMMAND failed with exitcode %d" % retval)
> - return
> diff --git a/lib/portage/elog/mod_echo.py b/lib/portage/elog/mod_echo.py
> index 80f2b11ac..a026847b7 100644
> --- a/lib/portage/elog/mod_echo.py
> +++ b/lib/portage/elog/mod_echo.py
> @@ -3,9 +3,10 @@
>  # Distributed under the terms of the GNU General Public License v2
>  
>  import sys
> -from portage.output import EOutput, colorize
> +
>  from portage.const import EBUILD_PHASES
>  from portage.localization import _
> +from portage.output import EOutput, colorize
>  
>  
>  _items = []
> @@ -61,4 +62,3 @@ def _finalize():
>   for line in msgcontent:
>   fmap[msgtype](line.strip("\n"))
>   _items = []
> - return
> diff --git a/lib/portage/elog/mod_mail.py b/lib/portage/elog/mod_mail.py
> index 38eaa277f..f737a80ce 100644
> --- a/lib/portage/elog/mod_mail.py
> +++ b/lib/portage/elog/mod_mail.py
> @@ -41,5 +41,3 @@ def process(mysettings, key, logentries, fulltext):
>   portage.mail.send_mail(mysettings, mymessage)
>   except PortageException as e:
>   writemsg("%s\n" % str(e), noiselevel=-1)
> -
> - return
> diff --git a/lib/portage/glsa.py b/lib/portage/glsa.py
> index 9260e7e09..1870d9338 100644
> --- a/lib/portage/glsa.py
> +++ b/lib/portage/glsa.py
> @@ -492,7 +492,6 @@ class Glsa:
>   finally:
>   f.close()
>  
> - return None
>  
>   def parse(self, myfile):
>   """
> @@ -583,7 +582,6 @@ class Glsa:
>   self.packages[name].append(tmp)
>   # TODO: services aren't really used yet
>   self.services = self.affected.getElementsByTagName("service")
> - return None
>  
>   def dump(self, outstream=sys.stdout, encoding="utf-8"):
>   """
> @@ -684,7 +682,6 @@ class Glsa:
>   mode='a+', encoding=_encodings['content'], 
> errors='strict')
>   checkfile.write(_unicode_decode(self.nr + "\n"))
>   checkfile.close()
> - return None
>  
>   def getMergeList(self, least_change=True):
>   """
> diff --git a/lib/portage/mail.py b/lib/portage/mail.py
> index 6503b4cc9..f4fccd8c2 100644
> --- a/lib/portage/mail.py
> +++ b/lib/portage/mail.py
> @@ -136,4 +136,3 @@ def send_mail(mysettings, message):
>   raise portage.exception.PortageException(_("!!! An 
> error occurred while trying to send logmail:\n")+str(e))
>   except socket.error as e:
>   raise portage.exception.PortageException(_("!!! A 
> network error occurred while trying to send logmail:\n%s\nSure you configured 
> PORTAGE_ELOG_MAILURI correctly?") % str(e))
> - return
> diff --git a/lib/portage/sync/controller.py b/lib/portage/sync/controller.py
> index cb68e2c37..24ebf4ff8 100644
> --- a/lib/portage/sync/controller.py
> +++ b/lib/portage/sync/controller.py
> @@ -174,7 +174,7 @@ class SyncManager:
>  
>  
>   def do_callback(self, result):
> - #print("result:", result, "callback()", self.callback)
> + # print("result:", result, "callback()", self.callback)
>   exitcode, updatecache_flg = result
>   self.exitcode = exitcode
>   self.updatecache_flg = updatecache_flg
> @@ -184,7 +184,6 @@ class SyncManager:
>   writemsg_level(msg + "\n")
>   if self.callback:
>   self.callback(exitcode, updatecache_flg)
> - return
>  
>  
>   def perform_post_sync_hook(self, reponame, dosyncuri='', 
> repolocation='

[gentoo-dev] Last rites: app-i18n/sunpinyin & revdeps

2020-08-07 Thread Michał Górny
# Michał Górny  (2020-08-07)
# Last upstream (pre-)release in 2016.  Python 3 porting effort is not
# progressing since February, and PRs are stuck.  Homepage is gone.
# Removal in 30 days.  Bug #695010.
app-i18n/fcitx-sunpinyin
app-i18n/ibus-sunpinyin
app-i18n/scim-sunpinyin
app-i18n/sunpinyin
app-i18n/sunpinyin-data
app-i18n/xsunpinyin

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Michał Górny
On Thu, 2020-08-06 at 23:03 +0300, Joonas Niilola wrote:
> On 8/6/20 10:58 PM, Thomas Deutschmann wrote:
> > Well, the purpose of this is to educate and avoid problems for
> > headless/server users. But if so many devs seem to care about pushing
> > maybe unrelated information and believe that avoiding that has much more
> > value than avoid a problem like an unbootable system for just a few
> > people (and for headless/servers this is a major problem in case you
> > cannot trigger remote reboot)... ¯\_(ツ)_/¯
> > 
> Yeah let's break some setups and make people change distributions instead.
> 
> I'd support showing it. Weren't we all taught that too much
> communication is better than no communication?
> 

That's actually bullshit.  Too much noise leads to people stopping to
read stuff, and losing important info as a result.  Compare: our mailing
lists.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Michał Górny
On Thu, 2020-08-06 at 17:14 +0200, Thomas Deutschmann wrote:
> On 2020-08-06 14:22, Michał Górny wrote:
> > > - I am not 100% happy with the title but the 50 char limit
> > >   doesn't allow any more details.
> > 
> > Yes, the title doesn't say a thing why would anyone want to read this
> > news item or not.
> 
> Maybe
> 
> > Be aware of possible reboot problems
> 
> instead?
> 
> 
> > > - No Display-If condition because it is neither a genkernel nor
> > >   kexec-tools issue. We maybe even have additional packages
> > >   which are appending to kernel command-line I am not aware of.
> > 
> > Showing this news on all old and new Gentoo systems makes little sense.
> >  Either someone is newly affected, then Display-if should determine it,
> > or someone is *not* newly affected, then you're either telling him
> > something he already knows or something that is of little value to him.
> > 
> > News items should be precisely this -- news.  Not random pieces of
> > information you've just discovered and want to share with everyone.
> >  This is what documentation is about, and it should be in some kernel-
> > related piece of documentation (handbook?) and not scattered around
> > in news items.
> 
> Sure, you are basically repeating what I wrote in my prolog.
> 
> But the reason why I drafted that news item despite of this is the
> consideration that an unbootable system outweigh the risk to waste
> anyone's time to read something even if they are not affected. Note that
> news items will appear through multiple channels. So if this will help
> someone who didn't read documentation before or just didn't realize the
> obvious risk he/she is taking when using non-persistent names ("It
> worked that way for me past 15 years!") I believe it has served its purpose.

I'm not sure if you've noticed but there are people actively working
towards removing stale news items and trying not to dump everything
on once on a user freshly installing the system.  Don't you consider
this a worthwhile goal?


-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/pythonutils

2020-08-06 Thread Michał Górny
# Michał Górny  (2020-08-06)
# Py2.7 only.  Last release in 2009.  No reverse dependencies left.
# Removal in 30 days.  Bug #735610.
dev-python/pythonutils

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-python/gntp

2020-08-06 Thread Michał Górny
# Michał Górny  (2020-08-06)
# Py3.6 only.  Apparently randomly fails to build (bug #515736).
# Last release in 2016.  No reverse dependencies left.
# Removal in 30 days.  Bug #718968.
dev-python/gntp

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Michał Górny
On Wed, 2020-08-05 at 14:02 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> please review the news item below:
> 
> - I am not 100% happy with the title but the 50 char limit
>   doesn't allow any more details.

Yes, the title doesn't say a thing why would anyone want to read this
news item or not.

> 
> - No Display-If condition because it is neither a genkernel nor
>   kexec-tools issue. We maybe even have additional packages
>   which are appending to kernel command-line I am not aware of.

Showing this news on all old and new Gentoo systems makes little sense.
 Either someone is newly affected, then Display-if should determine it,
or someone is *not* newly affected, then you're either telling him
something he already knows or something that is of little value to him.

News items should be precisely this -- news.  Not random pieces of
information you've just discovered and want to share with everyone.
 This is what documentation is about, and it should be in some kernel-
related piece of documentation (handbook?) and not scattered around
in news items.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Packages up for grabs due to jlec being MIA

2020-08-05 Thread Michał Górny
On Wed, 2020-08-05 at 09:24 +0200, Michał Górny wrote:
> Hello,
> 
> The following packages are looking for a new maintainer:
> 

+ cuda.eclass

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Packages up for grabs due to jlec being MIA

2020-08-05 Thread Michał Górny
Hello,

The following packages are looking for a new maintainer:

[vB] app-backup/cachedir
[vB] app-benchmarks/bootchart2
[ B] app-benchmarks/ramspeed
[ B] app-office/scribus
[vB] dev-lua/luaposix
[ b] net-analyzer/zmap
[  ] net-libs/czmq
[  ] net-vpn/vpncwatch
[vB] sys-block/blocks
[  ] sys-boot/makebootfat
[v ] sys-fs/aufs-headers
[vB] sys-fs/aufs-util
[vB] sys-fs/bcache-tools
[v ] sys-kernel/aufs-sources
[vB] sys-kernel/kergen

Legend:

v - needs version bump
b - has trivial (QA) bug reported
B - has non-trivial bug reported

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Last-rites: dev-libs/liboobs

2020-08-03 Thread Michał Górny
On Mon, 2020-08-03 at 22:23 +, Peter Stuge wrote:
> Jimi Huotari wrote:
> > # Jimi Huotari  (2020-08-04)
> > # No consumers since 2015, and no known stand-alone use.
> > # Removal in 30 days.
> > dev-libs/liboobs
> 
> Wut - isn't that a really poor reason to remove from the tree? :\
> 
> Why not just keep it unless there is an actual technical problem?
> (Security, maintainability, etc.) If there is, then please mention it.
> 

Yes, having 1953 unmaintained packages is great PR for Gentoo.  Wait, it
will be 1954 now.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Guidelines on Python 2 cleanup

2020-08-03 Thread Michał Górny
Hello, everyone.

There has been some unrest wrt Python 2 removal lately.  To put things
back in order, I've spent a considerable time filing bugs for all
the remaining packages yesterday (some of them turned out to be false
positives, sorry) and I'd like to issue some official guidelines
to avoid misunderstandings.


The official deadline for Python 2 in Gentoo is 2021-01-01.  This means
that up to this date, all packages have to be ported to Python 3, with
new versions stable and the last old versions ready to be cleaned up.
All unported packages will be last rited with 30 day removal period
and no possible extension.

I would really like to avoid extending the deadline.  That is, unless
the big G. or the big M. forces us to.  Apparently they're too busy
inventing new programming languages to port their scripts.

However, we shouldn't wait till the last minute.  It makes sense
to wait  for packages that are high-profile and/or have good chances
of actually being ported.  It doesn't make sense to delay removing some
obscure package that hasn't seen any activity in 10 years.  The whole
point is that we last rite packages in smaller batches that make it
easier to deal with, and that we last rite them early to give more time
for users to react.  It would really suck if we did a 250-package last
rites on January 1st.


Now, to the guidelines:

1. Normally, last rites apply only to packages that *unconditionally*
need Python.  Please *do not* last rite packages if it is sufficient
to mask USE=python or alike.

1a. Masking or removing conditional Python support is not need
immediately necessary; however, it may be desirable to do it early
to give users more time to complain, and to unblock dependencies
if there are any.

1b. A corner case here are packages requiring Python for tests.
Restricting tests suck.

1c. In case of some unmaintained packages, where other treecleaning
conditions apply, it may be desirable to last rite anyway.


2. Give people a chance to react.  Last rite only if there is no reply
to the relevant bug for, say, 30 days.

2a. If maintainers point out that the work is underway, it's fine
to wait.

2b. But if the work has stopped progressing for a long time now
and it is unlikely that it will be completed before the deadline,
it may be better to stop waiting and warn the users.


3. Do not last rite reverse dependencies without warning.  If you
notice some last rite candidate is blocked, please *at the very least*
CC maintainers of revdeps to give them notice that their packages are
affected.  Filing extra bugs is even better.

3a. I suppose extra bugs shouldn't be necessary if revdeps belong to
the same family of packages and have the same maintainer (i.e. you can
clearly guess they need to go as well).


4. Leave high-profile and/or likely-to-be-ported packages for later.
At least right now we have enough obscure and dead packages to last
rite first.

4a. That doesn't mean wait with them forever.  It would be nice not to
last rite all high-profile packages in one go.


5. Please *verify* everything before proceeding.  As I've mentioned,
some bugs might be false positives.  Some packages may be fixed without
closing the bug.

5a. Also note that some packages have || deps that show up in rdep
reports but don't justify last riting reverse dependencies.

5b. Please file stabilization bugs (but do not CC arches without
approval) or ping maintainers wrt cleanup whenever appropriate.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-vcs/svnmailer

2020-08-03 Thread Michał Górny
# Michał Górny  (2020-08-03)
# Unmaintained.  Last release in 2011.  Py2 only.
# Removal in 30 days.  Bug #735362.
dev-vcs/svnmailer

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


  1   2   3   4   5   6   7   8   9   10   >