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

2021-09-23 Thread Michał Górny
# Michał Górny  (2021-09-23)
# Ancient version from 2016 that collides with dev-python/pyjwt.
# Never bumped by the maintainer.  The only revdep turned out to be
# false positive.
# Removal on 2021-10-23.  Bug #814449.
dev-python/python-jwt

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [GLEP78] Updating specification

2021-09-13 Thread Michał Górny
On Mon, 2021-09-13 at 12:08 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 13 Sep 2021, Sheng Yu wrote:
> 
> > -The archive contains a number of files, stored in a single
> > directory
> > -whose name should match the basename of the package file.  However,
> > -the implementation must be able to process an archive where
> > -the directory name is mismatched.  There should be no explicit
> > archive
> > -member entry for the directory.
> > +The archive contains a number of files.  All package-related files
> > +should be stored in a single directory whose name matches the CPV
> > of
> > +the package file.  However, the implementation must be able to
> > process
> > +an archive where the directory name is mismatched.  There should be
> > no
> > +explicit archive member entry for the directory.
> 
> I wonder about CPV here. That's ${CATEGORY}/${P} and contains a slash,
> so it cannot be the name of a directory. Also, what about the package
> revision?

Please restore the previous wording.  The GLEP deliberately did not
enforce a specific filename because it's about internal format.

> 
> > +6. The package manifest data file ``Manifest`` (required).
> > +
> > +7. A signature for the package Manifest file ``Manifest.sig``
> > +   (optional).
> 
> Given that the outer archive is uncompressed tar, every file will be
> zero-padded to a full block which adds some amount of bloat. So, could
> the signature be inlined in the Manifest file? That's also what GLEP
> 74
> specifies.

Using inline signature in Manifest makes sense.

> 
> Also, IIRC one of the goals of the format was to allow partial
> download
> of metadata. That will only work if the Manifest file will be the
> first
> file in the archive (or at least appear before the image archive).

I disagree.  This is solved by having detached metadata signature -- you
can do a partial fetch and verify the metadata directly.

On the other hand, putting Manifest first would make it impossible to
create the archive from data stream without using temporary files,
effectively doubling the needed free space.  Well, technically you could
just reserve space and write Manifest later but that would strongly
depend on the size of PGP signature and that's not something I'd feel
comfortable relying on.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: add and use _python_check_EPYTHON

2021-09-13 Thread Michał Górny
On Mon, 2021-09-13 at 09:47 +0200, Florian Schmaus wrote:
> Signed-off-by: Florian Schmaus 
> ---
>  eclass/python-utils-r1.eclass | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 

Both patches LGTM.

-- 
Best regards,
Michał Górny





Re: [gentoo-portage-dev] [PATCH] eend: Output QA notice when called without argument

2021-09-03 Thread Michał Górny
On Fri, 2021-09-03 at 18:58 +0200, Ulrich Müller wrote:
> PMS says about eend: "Takes one fixed argument, which is a numeric
> return code, and an optional message in all subsequent arguments."
> 
> Bug: https://bugs.gentoo.org/703520
> Signed-off-by: Ulrich Müller 
> ---
>  bin/isolated-functions.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> index b495ae6c7..5b1f372d2 100644
> --- a/bin/isolated-functions.sh
> +++ b/bin/isolated-functions.sh
> @@ -364,6 +364,7 @@ __eend() {
>  }
>  
>  eend() {
> + [[ -n $1 ]] || eqawarn "QA Notice: eend called without return code"
>   local retval=${1:-0}
>   shift
>  

I think the message could be a bit confusing.  Maybe say explicitly that
it's missing an argument.

-- 
Best regards,
Michał Górny





[gentoo-portage-dev] [PATCH 4/4] Include INHERIT value in generated cache

2021-09-03 Thread Michał Górny
PkgCore uses an additional md5-cache INHERIT key to indicate eclasses
explicitly inherited in an ebuild.  Update Portage to emit the same key
to restore cache compatibility.

Signed-off-by: Michał Górny 
---
 bin/ebuild.sh  | 8 +++-
 bin/phase-functions.sh | 2 +-
 lib/portage/__init__.py| 2 +-
 lib/portage/package/ebuild/_config/special_env_vars.py | 2 +-
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 381bcb5c8..07ca58d22 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -402,6 +402,9 @@ inherit() {
unset $__export_funcs_var
 
has $1 $INHERITED || export INHERITED="$INHERITED $1"
+   if [[ ${ECLASS_DEPTH} -eq 1 ]]; then
+   export 
PORTAGE_EXPLICIT_INHERIT="${PORTAGE_EXPLICIT_INHERIT} $1"
+   fi
fi
 
shift
@@ -648,6 +651,7 @@ if ! has "$EBUILD_PHASE" clean cleanrm ; then
unset INHERITED IUSE REQUIRED_USE ECLASS E_IUSE E_REQUIRED_USE
unset E_DEPEND E_RDEPEND E_PDEPEND E_BDEPEND E_IDEPEND 
E_PROPERTIES
unset E_RESTRICT PROVIDES_EXCLUDE REQUIRES_EXCLUDE
+   unset PORTAGE_EXPLICIT_INHERIT
 
if [[ $PORTAGE_DEBUG != 1 || ${-/x/} != $- ]] ; then
source "$EBUILD" || die "error sourcing ebuild"
@@ -757,7 +761,7 @@ if [[ $EBUILD_PHASE = depend ]] ; then
metadata_keys=(
DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE REQUIRED_USE PDEPEND BDEPEND
-   EAPI PROPERTIES DEFINED_PHASES IDEPEND
+   EAPI PROPERTIES DEFINED_PHASES IDEPEND INHERIT
)
 
if ! ___eapi_has_BDEPEND; then
@@ -767,6 +771,8 @@ if [[ $EBUILD_PHASE = depend ]] ; then
unset IDEPEND
fi
 
+   INHERIT=${PORTAGE_EXPLICIT_INHERIT}
+
# The extra $(echo) commands remove newlines.
for f in "${metadata_keys[@]}" ; do
echo "${f}=$(echo ${!f})" >&${PORTAGE_PIPE_FD} || exit $?
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index 0bb5d86e1..d3221993d 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -20,7 +20,7 @@ PORTAGE_READONLY_VARS="D EBUILD EBUILD_PHASE 
EBUILD_PHASE_FUNC \
PORTAGE_BUILD_USER PORTAGE_BUNZIP2_COMMAND \
PORTAGE_BZIP2_COMMAND PORTAGE_COLORMAP PORTAGE_CONFIGROOT \
PORTAGE_DEBUG PORTAGE_DEPCACHEDIR PORTAGE_EBUILD_EXIT_FILE \
-   PORTAGE_ECLASS_LOCATIONS \
+   PORTAGE_ECLASS_LOCATIONS PORTAGE_EXPLICIT_INHERIT \
PORTAGE_GID PORTAGE_GRPNAME PORTAGE_INST_GID PORTAGE_INST_UID \
PORTAGE_INTERNAL_CALLER PORTAGE_IPC_DAEMON PORTAGE_IUSE 
PORTAGE_LOG_FILE \
PORTAGE_MUTABLE_FILTERED_VARS PORTAGE_OVERRIDE_EPREFIX 
PORTAGE_PROPERTIES \
diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
index 232d77f0e..a41ca4323 100644
--- a/lib/portage/__init__.py
+++ b/lib/portage/__init__.py
@@ -519,7 +519,7 @@ auxdbkeys = (
'RESTRICT',  'HOMEPAGE',  'LICENSE',   'DESCRIPTION',
'KEYWORDS',  'INHERITED', 'IUSE', 'REQUIRED_USE',
'PDEPEND',   'BDEPEND', 'EAPI',
-   'PROPERTIES', 'DEFINED_PHASES', 'IDEPEND',
+   'PROPERTIES', 'DEFINED_PHASES', 'IDEPEND', 'INHERIT',
 )
 
 def portageexit():
diff --git a/lib/portage/package/ebuild/_config/special_env_vars.py 
b/lib/portage/package/ebuild/_config/special_env_vars.py
index 456af1838..8e314a6d6 100644
--- a/lib/portage/package/ebuild/_config/special_env_vars.py
+++ b/lib/portage/package/ebuild/_config/special_env_vars.py
@@ -22,7 +22,7 @@ env_blacklist = frozenset((
"KEYWORDS", "LICENSE", "MERGE_TYPE",
"PDEPEND", "PF", "PKGUSE", "PORTAGE_BACKGROUND",
"PORTAGE_BACKGROUND_UNMERGE", "PORTAGE_BUILDDIR_LOCKED",
-   "PORTAGE_BUILT_USE", "PORTAGE_CONFIGROOT",
+   "PORTAGE_BUILT_USE", "PORTAGE_CONFIGROOT", "PORTAGE_EXPLICIT_INHERIT",
"PORTAGE_INTERNAL_CALLER", "PORTAGE_IUSE",
"PORTAGE_NONFATAL", "PORTAGE_PIPE_FD", "PORTAGE_REPO_NAME",
"PORTAGE_USE", "PROPERTIES", "RDEPEND", "REPOSITORY",
-- 
2.33.0




[gentoo-portage-dev] [PATCH 2/4] Switch internal metadata to key=value format

2021-09-03 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 bin/ebuild.sh  | 13 +++--
 lib/_emerge/EbuildMetadataPhase.py | 15 +--
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 32995d95b..381bcb5c8 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -754,10 +754,11 @@ if [[ $EBUILD_PHASE = depend ]] ; then
export SANDBOX_ON="0"
set -f
 
-   auxdbkeys="DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
+   metadata_keys=(
+   DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE REQUIRED_USE PDEPEND BDEPEND
-   EAPI PROPERTIES DEFINED_PHASES IDEPEND UNUSED_04
-   UNUSED_03 UNUSED_02 UNUSED_01"
+   EAPI PROPERTIES DEFINED_PHASES IDEPEND
+   )
 
if ! ___eapi_has_BDEPEND; then
unset BDEPEND
@@ -767,10 +768,10 @@ if [[ $EBUILD_PHASE = depend ]] ; then
fi
 
# The extra $(echo) commands remove newlines.
-   for f in ${auxdbkeys} ; do
-   eval "echo \$(echo \${!f}) 1>&${PORTAGE_PIPE_FD}" || exit $?
+   for f in "${metadata_keys[@]}" ; do
+   echo "${f}=$(echo ${!f})" >&${PORTAGE_PIPE_FD} || exit $?
done
-   eval "exec ${PORTAGE_PIPE_FD}>&-"
+   exec {PORTAGE_PIPE_FD}>&-
set +f
 else
# Note: readonly variables interfere with __preprocess_ebuild_env(), so
diff --git a/lib/_emerge/EbuildMetadataPhase.py 
b/lib/_emerge/EbuildMetadataPhase.py
index d00f194c2..5fd0e8a4d 100644
--- a/lib/_emerge/EbuildMetadataPhase.py
+++ b/lib/_emerge/EbuildMetadataPhase.py
@@ -151,13 +151,16 @@ class EbuildMetadataPhase(SubProcess):
metadata_lines = 
_unicode_decode(b''.join(self._raw_metadata),
encoding=_encodings['repo.content'],
errors='replace').splitlines()
+   metadata = {}
metadata_valid = True
-   if len(portage.auxdbkeys) != len(metadata_lines):
-   # Don't trust bash's returncode if the
-   # number of lines is incorrect.
-   metadata_valid = False
-   else:
-   metadata = dict(zip(portage.auxdbkeys, 
metadata_lines))
+   for l in metadata_lines:
+   if '=' not in l:
+   metadata_valid = False
+   break
+   key, value = l.split('=', 1)
+   metadata[key] = value
+
+   if metadata_valid:
parsed_eapi = self._eapi
if parsed_eapi is None:
parsed_eapi = "0"
-- 
2.33.0




[gentoo-portage-dev] [PATCH 3/4] Remove UNUSED* auxdbkeys

2021-09-03 Thread Michał Górny
The UNUSED* auxdbkeys are a relict of old metadata cache format that
required a fixed number of lines.  This format is no longer supported
by Portage, and all uses of auxdbkeys strip UNUSED values, so just
remove them entirely.

Signed-off-by: Michał Górny 
---
 bin/portageq   | 3 +--
 lib/_emerge/Package.py | 3 +--
 lib/portage/__init__.py| 4 +---
 lib/portage/dbapi/__init__.py  | 3 +--
 repoman/lib/repoman/qa_data.py | 2 +-
 5 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/bin/portageq b/bin/portageq
index 385259f9d..d3cb9f140 100755
--- a/bin/portageq
+++ b/bin/portageq
@@ -238,8 +238,7 @@ docstrings['metadata'] = """
[]+
 Returns metadata values for the specified package.
 Available keys: %s
-"""  % ','.join(sorted(x for x in portage.auxdbkeys \
-if not x.startswith('UNUSED_')))
+"""  % ','.join(sorted(x for x in portage.auxdbkeys))
 metadata.__doc__ = docstrings['metadata']
 
 
diff --git a/lib/_emerge/Package.py b/lib/_emerge/Package.py
index e8809a89d..4e25619ae 100644
--- a/lib/_emerge/Package.py
+++ b/lib/_emerge/Package.py
@@ -791,8 +791,7 @@ class Package(Task):
pkg = self
return pkg
 
-_all_metadata_keys = set(x for x in portage.auxdbkeys \
-   if not x.startswith("UNUSED_"))
+_all_metadata_keys = set(x for x in portage.auxdbkeys)
 _all_metadata_keys.update(Package.metadata_keys)
 _all_metadata_keys = frozenset(_all_metadata_keys)
 
diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
index 6e22a174b..232d77f0e 100644
--- a/lib/portage/__init__.py
+++ b/lib/portage/__init__.py
@@ -519,10 +519,8 @@ auxdbkeys = (
'RESTRICT',  'HOMEPAGE',  'LICENSE',   'DESCRIPTION',
'KEYWORDS',  'INHERITED', 'IUSE', 'REQUIRED_USE',
'PDEPEND',   'BDEPEND', 'EAPI',
-   'PROPERTIES', 'DEFINED_PHASES', 'IDEPEND', 'UNUSED_04',
-   'UNUSED_03', 'UNUSED_02', 'UNUSED_01',
+   'PROPERTIES', 'DEFINED_PHASES', 'IDEPEND',
 )
-auxdbkeylen = len(auxdbkeys)
 
 def portageexit():
pass
diff --git a/lib/portage/dbapi/__init__.py b/lib/portage/dbapi/__init__.py
index d7facc9b6..3caefb816 100644
--- a/lib/portage/dbapi/__init__.py
+++ b/lib/portage/dbapi/__init__.py
@@ -28,8 +28,7 @@ class dbapi:
_category_re = re.compile(r'^\w[-.+\w]*$', re.UNICODE)
_categories = None
_use_mutable = False
-   _known_keys = frozenset(x for x in auxdbkeys
-   if not x.startswith("UNUSED_0"))
+   _known_keys = frozenset(auxdbkeys)
_pkg_str_aux_keys = ("EAPI", "KEYWORDS", "SLOT", "repository")
 
def __init__(self):
diff --git a/repoman/lib/repoman/qa_data.py b/repoman/lib/repoman/qa_data.py
index afb403d8d..4785581e2 100644
--- a/repoman/lib/repoman/qa_data.py
+++ b/repoman/lib/repoman/qa_data.py
@@ -79,7 +79,7 @@ class QAData:
 
self.missingvars = qadata.get("missingvars", [])
logging.debug("QAData: missingvars: %s", self.missingvars)
-   self.allvars = set(x for x in portage.auxdbkeys if not 
x.startswith("UNUSED_"))
+   self.allvars = set(portage.auxdbkeys)
self.allvars.update(Package.metadata_keys)
self.allvars = sorted(self.allvars)
 
-- 
2.33.0




[gentoo-portage-dev] [PATCH 1/4] Remove deprecated dbkey support from doebuild/ebuild.sh

2021-09-03 Thread Michał Górny
Remove the support for the dbkey logic that used to write metadata into
a file.  This logic has stopped being used and became deprecated
in 2013.  If any external tool is still using it, it's probably been
broken by changes in metadata itself since, and would definitely
be broken by the incoming change in metadata format.

Signed-off-by: Michał Górny 
---
 bin/ebuild.sh  | 23 ---
 lib/portage/package/ebuild/doebuild.py | 22 +++---
 2 files changed, 7 insertions(+), 38 deletions(-)

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 3042e6c8c..32995d95b 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -754,14 +754,6 @@ if [[ $EBUILD_PHASE = depend ]] ; then
export SANDBOX_ON="0"
set -f
 
-   if [ -n "${dbkey}" ] ; then
-   if [ ! -d "${dbkey%/*}" ]; then
-   install -d -g ${PORTAGE_GID} -m2775 "${dbkey%/*}"
-   fi
-   # Make it group writable. 666&~002==664
-   umask 002
-   fi
-
auxdbkeys="DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE
DESCRIPTION KEYWORDS INHERITED IUSE REQUIRED_USE PDEPEND BDEPEND
EAPI PROPERTIES DEFINED_PHASES IDEPEND UNUSED_04
@@ -775,17 +767,10 @@ if [[ $EBUILD_PHASE = depend ]] ; then
fi
 
# The extra $(echo) commands remove newlines.
-   if [ -n "${dbkey}" ] ; then
-   > "${dbkey}"
-   for f in ${auxdbkeys} ; do
-   echo $(echo ${!f}) >> "${dbkey}" || exit $?
-   done
-   else
-   for f in ${auxdbkeys} ; do
-   eval "echo \$(echo \${!f}) 1>&${PORTAGE_PIPE_FD}" || 
exit $?
-   done
-   eval "exec ${PORTAGE_PIPE_FD}>&-"
-   fi
+   for f in ${auxdbkeys} ; do
+   eval "echo \$(echo \${!f}) 1>&${PORTAGE_PIPE_FD}" || exit $?
+   done
+   eval "exec ${PORTAGE_PIPE_FD}>&-"
set +f
 else
# Note: readonly variables interfere with __preprocess_ebuild_env(), so
diff --git a/lib/portage/package/ebuild/doebuild.py 
b/lib/portage/package/ebuild/doebuild.py
index 366cbb9ca..5115ff6a3 100644
--- a/lib/portage/package/ebuild/doebuild.py
+++ b/lib/portage/package/ebuild/doebuild.py
@@ -568,7 +568,7 @@ _doebuild_commands_without_builddir = (
 )
 
 def doebuild(myebuild, mydo, _unused=DeprecationWarning, settings=None, 
debug=0, listonly=0,
-   fetchonly=0, cleanup=0, dbkey=DeprecationWarning, use_cache=1, 
fetchall=0, tree=None,
+   fetchonly=0, cleanup=0, use_cache=1, fetchall=0, tree=None,
mydbapi=None, vartree=None, prev_mtimes=None,
fd_pipes=None, returnpid=False):
"""
@@ -591,9 +591,6 @@ def doebuild(myebuild, mydo, _unused=DeprecationWarning, 
settings=None, debug=0,
@type fetchonly: Boolean
@param cleanup: Passed to prepare_build_dirs (TODO: what does it do?)
@type cleanup: Boolean
-   @param dbkey: A file path where metadata generated by the 'depend' phase
-   will be written.
-   @type dbkey: String
@param use_cache: Enables the cache
@type use_cache: Boolean
@param fetchall: Used to wrap fetch(), fetches all URIs (even ones 
invalid due to USE conditionals)
@@ -637,11 +634,6 @@ def doebuild(myebuild, mydo, _unused=DeprecationWarning, 
settings=None, debug=0,
"settings['EROOT'] is used.",
DeprecationWarning, stacklevel=2)
 
-   if dbkey is not DeprecationWarning:
-   warnings.warn("portage.doebuild() called "
-   "with deprecated dbkey argument.",
-   DeprecationWarning, stacklevel=2)
-
if not tree:
writemsg("Warning: tree not specified to doebuild\n")
tree = "porttree"
@@ -836,16 +828,8 @@ def doebuild(myebuild, mydo, _unused=DeprecationWarning, 
settings=None, debug=0,
 
# get possible slot information from the deps file
if mydo == "depend":
-   writemsg("!!! DEBUG: dbkey: %s\n" % str(dbkey), 2)
-   if returnpid:
-   return _spawn_phase(mydo, mysettings,
-   fd_pipes=fd_pipes, returnpid=returnpid)
-   if dbkey and dbkey is not DeprecationWarning:
-   mysettings["dbkey"] = dbkey
-   else:
-   mysettings["dbkey"] = \
-   os.path.join(mysettings.depcachedir, 
"aux_db_key_temp")
-
+   if not returnpid:
+   raise TypeError("returnpid must be True for 
depend phase")
return _spawn_phase(mydo, mysettings,
fd_pipes=fd_pipes, returnpid=returnpid)
 
-- 
2.33.0




[gentoo-portage-dev] [PATCH 0/4] Modernize metadata passing & add INHERIT to md5-cache

2021-09-03 Thread Michał Górny
Hi,

Here's a patchset that:

1. Removes some leftover cruft from the old cache format.

2. Switches internal ebuild.sh/Python metadata logic from using a format
   resembling the old cache with hardcoded line number to data mapping
   (sic!) in favor of plain key=value format.

3. Adds INHERIT key to md5-cache for better compatibility with PkgCore.
   This key lists eclasses directly inherited by ebuild (vs _eclasses_
   that lists indirect inherits as well).

Michał Górny (4):
  Remove deprecated dbkey support from doebuild/ebuild.sh
  Switch internal metadata to key=value format
  Remove UNUSED* auxdbkeys
  Include INHERIT value in generated cache

 bin/ebuild.sh | 36 ---
 bin/phase-functions.sh|  2 +-
 bin/portageq  |  3 +-
 lib/_emerge/EbuildMetadataPhase.py| 15 
 lib/_emerge/Package.py|  3 +-
 lib/portage/__init__.py   |  4 +--
 lib/portage/dbapi/__init__.py |  3 +-
 .../ebuild/_config/special_env_vars.py|  2 +-
 lib/portage/package/ebuild/doebuild.py| 22 ++--
 repoman/lib/repoman/qa_data.py|  2 +-
 10 files changed, 33 insertions(+), 59 deletions(-)

-- 
2.33.0




Re: [gentoo-portage-dev] [PATCH v2 1/2] Revert "Revert "Generate a QA Notice when EXPORT_FUNCTIONS is called before inherit""

2021-09-03 Thread Michał Górny
On Mon, 2021-08-30 at 08:22 +0200, Ulrich Müller wrote:
> Reinstate the QA notice, because Portage behavior deviates from PMS,
> and breakage of eclasses with Pkgcore has been observed recently.
> 
> This reverts commit f44d32550861cb25c209ef61dcd7ae1aa230da1f.
> 
> Bug: https://bugs.gentoo.org/399039
> Signed-off-by: Ulrich Müller 
> ---
>  bin/ebuild.sh | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/bin/ebuild.sh b/bin/ebuild.sh
> index 5916bedfc..1bca2c965 100755
> --- a/bin/ebuild.sh
> +++ b/bin/ebuild.sh
> @@ -243,6 +243,14 @@ inherit() {
>   ECLASS_DEPTH=$(($ECLASS_DEPTH + 1))
>   if [[ ${ECLASS_DEPTH} -gt 1 ]]; then
>   debug-print "*** Multiple Inheritence (Level: ${ECLASS_DEPTH})"
> +
> + # Since ECLASS_DEPTH > 1, the following variables are locals 
> from the
> + # previous inherit call in the call stack.
> + if [[ -n ${ECLASS} && -n ${!__export_funcs_var} ]] ; then
> + eqawarn "QA Notice: EXPORT_FUNCTIONS is called before 
> inherit in ${ECLASS}.eclass."
> + eqawarn "For compatibility with <=portage-2.1.6.7, only 
> call EXPORT_FUNCTIONS"
> +     eqawarn "after inherit(s)."
> + fi
>   fi
>  
>   local -x ECLASS

Merged both.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH v3] linux-info.eclass : Support valid Make files

2021-09-03 Thread Michał Górny
On Thu, 2021-09-02 at 19:28 -0400, Mike wrote:
> Support the possibility that the Makefile could be
> one of the following and should be checked in the order described here:
> 
> https://www.gnu.org/software/make/manual/make.html
> 
> Order of checking and valid Makefiles names:
> GNUMakefile, makefile, Makefile
> 
> Bug: https://bugs.gentoo.org/663368
> 
> Signed-off-by: Mike Pagano 
> ---
>  eclass/linux-info.eclass | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
> index 0b6df1bf5..a6159eac2 100644
> --- a/eclass/linux-info.eclass
> +++ b/eclass/linux-info.eclass
> @@ -80,6 +80,15 @@ KERNEL_DIR="${KERNEL_DIR:-${ROOT%/}/usr/src/linux}"
>  # There are also a couple of variables which are set by this, and shouldn't 
> be
>  # set by hand. These are as follows:
>  
> +# @ECLASS-VARIABLE: KERNEL_MAKEFILE
> +# @INTERNAL
> +# @DESCRIPTION:
> +# According to upstream documentation, by default, when make looks for the 
> makefile, it tries
> +# the following names, in order: GNUmakefile, makefile and Makefile. Set 
> this variable to the
> +# proper Makefile name or the eclass will search in this order for it.
> +# See https://www.gnu.org/software/make/manual/make.html
> +: ${KERNEL_MAKEFILE:=""}
> +
>  # @ECLASS-VARIABLE: KV_FULL
>  # @OUTPUT_VARIABLE
>  # @DESCRIPTION:
> @@ -510,7 +519,9 @@ get_version() {
>   qeinfo "${KV_DIR}"
>   fi
>  
> - if [ ! -s "${KV_DIR}/Makefile" ]
> + get_makefile
> +
> + if [[ ! -s "${KERNEL_MAKEFILE}" ]]
>   then
>   if [ -z "${get_version_warning_done}" ]; then
>   get_version_warning_done=1
> @@ -526,9 +537,6 @@ get_version() {
>   # do we pass KBUILD_OUTPUT on the CLI?
>   local OUTPUT_DIR=${KBUILD_OUTPUT}
>  
> - # keep track of it
> - KERNEL_MAKEFILE="${KV_DIR}/Makefile"
> -
>   if [[ -z ${OUTPUT_DIR} ]]; then
>   # Decide the function used to extract makefile variables.
>   local mkfunc=$(get_makefile_extract_function 
> "${KERNEL_MAKEFILE}")
> @@ -971,3 +979,17 @@ linux-info_pkg_setup() {
>  
>   [ -n "${CONFIG_CHECK}" ] && check_extra_config;
>  }
> +
> +# @FUNCTION: get_makefile

Please prefix it so it doesn't pollute the global namespace.

> +# @DESCRIPTION:
> +# Support the possibility that the Makefile could be one of the following 
> and should
> +# be checked in the order described here:
> +# https://www.gnu.org/software/make/manual/make.html
> +# Order of checking and valid Makefiles names:  GNUMakefile, makefile, 
> Makefile
> +get_makefile() {
> +
> + [[ -s "${KV_DIR}"/GNUMakefile ]] && 
> KERNEL_MAKEFILE="${KV_DIR}/GNUMakefile"
> + [[ -s "${KV_DIR}"/makefile ]] && KERNEL_MAKEFILE="${KV_DIR}/makefile"
> + [[ -s "${KV_DIR}"/Makefile ]] && KERNEL_MAKEFILE="${KV_DIR}/Makefile"
> +
> +}

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
On Thu, 2021-09-02 at 09:50 -0400, Michael Orlitzky wrote:
> On Thu, 2021-09-02 at 14:58 +0200, Michał Górny wrote:
> > > 
> > Apparently, need_apache* is the problem.  Most of the ebuilds in www-
> > apache/* are calling it:
> > 
> 
> The apache-module eclass tells you to do that because it needs some of
> those APACHE_* paths. It should really be figuring them out itself
> rather than telling the user to call a function that does it in global
> scope. It's an easy fix:
> 
>   APXS=apxs
>   APACHE_MODULESDIR=$(apxs -q libexecdir)
>   APACHE_MODULES_CONFDIR=$(apxs -q sysconfdir)/modules.d
>   APACHE_VHOSTS_CONFDIR=$(apxs -q sysconfdir)/vhosts.d
> 
> On the one hand, we probably don't want ebuild maintainers trying to
> solve that themselves when the eclass could do it. But for whatever
> such a promise is worth, it also feels wrong to promise that apache-
> module will provide all of depend.apache -- what if we someday apply
> the fix above to apache-module and want to drop the depend.apache
> inherit?
> 
> If we do ever update apache-module, updating ebuilds and retiring
> depend.apache would be a lot easier if you could find the candidates
> with `git grep depend.apache`, rather than having to look through all
> consumers of apache-module for implicit uses of depend.apache.
> 

Ok, I've removed this commit from my branch.  If maintainers want it
otherwise, it's easy enough to do it again.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH 29/44] meson.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
On Thu, 2021-09-02 at 10:17 -0400, Mike Gilbert wrote:
> On Thu, Sep 2, 2021 at 6:47 AM Michał Górny  wrote:
> > 
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/meson.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index eaff26709a75..c5e3b91f9a15 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -6,6 +6,7 @@
> >  # William Hubbs 
> >  # Mike Gilbert 
> >  # @SUPPORTED_EAPIS: 6 7 8
> > +# @PROVIDES: ninja-utils
> >  # @BLURB: common ebuild functions for meson-based packages
> >  # @DESCRIPTION:
> >  # This eclass contains the default phase functions for packages which
> > --
> > 2.33.0
> 
> Please drop this patch. meson.eclass does not use ninja-utils since
> 5974284d8cb3c2b6d3dab3ad83c2f270db3b0798, and we certainly don't want
> to implicitly provide it to consumers.
> 
> We should probably remove the ninja-utils inherit from meson.eclass instead.
> 

Removed.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
On Thu, 2021-09-02 at 08:50 -0400, Michael Orlitzky wrote:
> On Thu, 2021-09-02 at 12:46 +0200, Michał Górny wrote:
> > Signed-off-by: Michał Górny 
> > ---
> >  eclass/apache-module.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> > ...
> >  # @SUPPORTED_EAPIS: 5 6 7
> > +# @PROVIDES: depend.apache
> 
> I'm not sure about this one. The depend.apache eclass is junk and we
> should be encouraging people to move away from it (bug 616612):
> 
>   * If you want to depend on apache, depend on apache.
> 
>   * If you need paths like APACHE_MODULESDIR, the "apxs" tool is now
> in PATH so you can get it from $(apxs -q libexecdir)
> 
>   * If you need paths like APACHE_MODULES_CONFDIR, the eclass doesn't 
> work anyway. You can hard-code those paths yourself (relative to
> apxs -q sysconfdir), or if anyone feels up to the task, they could
> write a greatly simplified apache-paths.eclass that provides these
> paths via functions that are to be called outside of global scope.
> 
> If people are using anything in depend.apache, I think a warning is
> appropriate. Making a promise that apache-module (which is not junk)
> provides depend.apache will moreover make it harder to disentangle them
> in the future if anyone decides to fix things.
> 

Apparently, need_apache* is the problem.  Most of the ebuilds in www-
apache/* are calling it:

libapreq2/libapreq2-2.15-r1.ebuild:need_apache2
libapreq2/libapreq2-2.16.ebuild:need_apache2
mod_auth_kerb/mod_auth_kerb-5.4-r2.ebuild:need_apache2
mod_auth_radius/mod_auth_radius-1.5.8.ebuild:need_apache2
mod_auth_tkt/mod_auth_tkt-2.1.0-r1.ebuild:need_apache2
mod_authnz_external/mod_authnz_external-3.3.2.ebuild:need_apache2_4
...

Ofc, I'm fine with leaving it as-is, i.e. assuming they all need to
inherit depend.apache explicitly.

-- 
Best regards,
Michał Górny





[gentoo-dev] [PATCH 44/44] xorg-3.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/xorg-3.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 7ed96c60848a..cfa679b766ce 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -9,6 +9,7 @@
 # Author: Donnie Berkholz 
 # Author: Matt Turner 
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: multilib-minimal
 # @BLURB: Reduces code duplication in the modularized X11 ebuilds.
 # @DESCRIPTION:
 # This eclass makes trivial X ebuilds possible for apps, drivers,
-- 
2.33.0




[gentoo-dev] [PATCH 43/44] xdg.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/xdg.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/xdg.eclass b/eclass/xdg.eclass
index 08dc8432a5e0..a3e75103a046 100644
--- a/eclass/xdg.eclass
+++ b/eclass/xdg.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Original author: Gilles Dartiguelongue 
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: xdg-utils
 # @BLURB: Provides phases for XDG compliant packages.
 # @DESCRIPTION:
 # Utility eclass to update the desktop, icon and shared mime info as laid
-- 
2.33.0




[gentoo-dev] [PATCH 42/44] ruby-single.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ruby-single.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ruby-single.eclass b/eclass/ruby-single.eclass
index e19597b99a01..ed230f4a84e5 100644
--- a/eclass/ruby-single.eclass
+++ b/eclass/ruby-single.eclass
@@ -8,6 +8,7 @@
 # Author: Hans de Graaff 
 # Based on python-single-r1 by: Michał Górny 
 # @SUPPORTED_EAPIS: 4 5 6 7 8
+# @PROVIDES: ruby-utils
 # @BLURB: An eclass for Ruby packages not installed for multiple 
implementations.
 # @DESCRIPTION:
 # An eclass for packages which don't support being installed for
-- 
2.33.0




[gentoo-dev] [PATCH 41/44] ruby-ng-gnome2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ruby-ng-gnome2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ruby-ng-gnome2.eclass b/eclass/ruby-ng-gnome2.eclass
index 3b18faf95aae..cc475b36b731 100644
--- a/eclass/ruby-ng-gnome2.eclass
+++ b/eclass/ruby-ng-gnome2.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Author: Hans de Graaff 
 # @SUPPORTED_EAPIS: 6 7
+# @PROVIDES: ruby-ng
 # @BLURB: An eclass to simplify handling of various ruby-gnome2 parts.
 # @DESCRIPTION:
 # This eclass simplifies installation of the various pieces of
-- 
2.33.0




[gentoo-dev] [PATCH 40/44] ruby-fakegem.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ruby-fakegem.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 76a80f6b9be2..d999ace34286 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -9,6 +9,7 @@
 # Author: Alex Legler 
 # Author: Hans de Graaff 
 # @SUPPORTED_EAPIS: 4 5 6 7 8
+# @PROVIDES: ruby-ng
 # @BLURB: An eclass for installing Ruby packages to behave like RubyGems.
 # @DESCRIPTION:
 # This eclass allows to install arbitrary Ruby libraries (including Gems),
-- 
2.33.0




[gentoo-dev] [PATCH 39/44] ros-catkin.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ros-catkin.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ros-catkin.eclass b/eclass/ros-catkin.eclass
index 48121bf1d2a1..906d76843574 100644
--- a/eclass/ros-catkin.eclass
+++ b/eclass/ros-catkin.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Alexis Ballier 
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: cmake python-single-r1
 # @BLURB: Template eclass for catkin based ROS packages.
 # @DESCRIPTION:
 # Provides function for building ROS packages on Gentoo.
-- 
2.33.0




[gentoo-dev] [PATCH 38/44] python-single-r1.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/python-single-r1.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/python-single-r1.eclass b/eclass/python-single-r1.eclass
index da0113b6d57b..228c66a77af6 100644
--- a/eclass/python-single-r1.eclass
+++ b/eclass/python-single-r1.eclass
@@ -8,6 +8,7 @@
 # Author: Michał Górny 
 # Based on work of: Krzysztof Pawlik 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: python-utils-r1
 # @BLURB: An eclass for Python packages not installed for multiple 
implementations.
 # @DESCRIPTION:
 # An extension of the python-r1 eclass suite for packages which
-- 
2.33.0




[gentoo-dev] [PATCH 37/44] python-r1.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/python-r1.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 3a4d257036c8..dc624946cfc1 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -8,6 +8,7 @@
 # Author: Michał Górny 
 # Based on work of: Krzysztof Pawlik 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: multibuild python-utils-r1
 # @BLURB: A common, simple eclass for Python packages.
 # @DESCRIPTION:
 # A common eclass providing helper functions to build and install
-- 
2.33.0




[gentoo-dev] [PATCH 36/44] python-any-r1.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/python-any-r1.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/python-any-r1.eclass b/eclass/python-any-r1.eclass
index eaae5379b732..7af9474d9a1f 100644
--- a/eclass/python-any-r1.eclass
+++ b/eclass/python-any-r1.eclass
@@ -8,6 +8,7 @@
 # Author: Michał Górny 
 # Based on work of: Krzysztof Pawlik 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: python-utils-r1
 # @BLURB: An eclass for packages having build-time dependency on Python.
 # @DESCRIPTION:
 # A minimal eclass for packages which need any Python interpreter
-- 
2.33.0




[gentoo-dev] [PATCH 35/44] postgres-multi.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/postgres-multi.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/postgres-multi.eclass b/eclass/postgres-multi.eclass
index acaa5077217f..5e37a7d0b471 100644
--- a/eclass/postgres-multi.eclass
+++ b/eclass/postgres-multi.eclass
@@ -11,6 +11,7 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_compile 
src_install src_test
 # @AUTHOR:
 # Aaron W. Swenson 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: multibuild postgres
 # @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
 # @DESCRIPTION:
 # postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
-- 
2.33.0




[gentoo-dev] [PATCH 34/44] php-ext-pecl-r3.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/php-ext-pecl-r3.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/php-ext-pecl-r3.eclass b/eclass/php-ext-pecl-r3.eclass
index f3977b225aa4..1727a53ebba6 100644
--- a/eclass/php-ext-pecl-r3.eclass
+++ b/eclass/php-ext-pecl-r3.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # Gentoo PHP team 
 # @SUPPORTED_EAPIS: 6 7
+# @PROVIDES: php-ext-source-r3
 # @BLURB: A uniform way to install PECL extensions
 # @DESCRIPTION:
 # This eclass should be used by all dev-php/pecl-* ebuilds as a uniform
-- 
2.33.0




[gentoo-dev] [PATCH 33/44] perl-module.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/perl-module.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
index 3c1b4c3c5acc..cff6f203ab8f 100644
--- a/eclass/perl-module.eclass
+++ b/eclass/perl-module.eclass
@@ -8,6 +8,7 @@
 # Seemant Kulleen 
 # Andreas K. Hüttel 
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: perl-functions
 # @BLURB: eclass for installing Perl module distributions
 # @DESCRIPTION:
 # The perl-module eclass is designed to allow easier installation of Perl
-- 
2.33.0




[gentoo-dev] [PATCH 32/44] multilib-minimal.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/multilib-minimal.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/multilib-minimal.eclass b/eclass/multilib-minimal.eclass
index 6c5c754381b5..9a1efe2cc466 100644
--- a/eclass/multilib-minimal.eclass
+++ b/eclass/multilib-minimal.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # Michał Górny 
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: multilib-build
 # @BLURB: wrapper for multilib builds providing convenient multilib_src_* 
functions
 # @DESCRIPTION:
 #
-- 
2.33.0




[gentoo-dev] [PATCH 31/44] multilib-build.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/multilib-build.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index e3e8730904ab..17cd7da0d189 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Author: Michał Górny 
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: multibuild
 # @BLURB: flags and utility functions for building multilib packages
 # @DESCRIPTION:
 # The multilib-build.eclass exports USE flags and utility functions
-- 
2.33.0




[gentoo-dev] [PATCH 30/44] meson-multilib.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/meson-multilib.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/meson-multilib.eclass b/eclass/meson-multilib.eclass
index 1ed95f99fa18..49c64418727e 100644
--- a/eclass/meson-multilib.eclass
+++ b/eclass/meson-multilib.eclass
@@ -8,6 +8,7 @@
 # Michał Górny 
 # Matt Turner 
 # @SUPPORTED_EAPIS: 7 8
+# @PROVIDES: meson multilib-minimal
 # @BLURB: meson wrapper for multilib builds
 # @DESCRIPTION:
 # The meson-multilib.eclass provides a glue between meson.eclass(5)
-- 
2.33.0




[gentoo-dev] [PATCH 29/44] meson.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/meson.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index eaff26709a75..c5e3b91f9a15 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -6,6 +6,7 @@
 # William Hubbs 
 # Mike Gilbert 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: ninja-utils
 # @BLURB: common ebuild functions for meson-based packages
 # @DESCRIPTION:
 # This eclass contains the default phase functions for packages which
-- 
2.33.0




[gentoo-dev] [PATCH 28/44] lua-single.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/lua-single.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index 26967000748c..2f4ebaa14198 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -9,6 +9,7 @@
 # Marek Szuba 
 # Based on python-single-r1.eclass by Michał Górny  et al.
 # @SUPPORTED_EAPIS: 7 8
+# @PROVIDES: lua-utils
 # @BLURB: An eclass for Lua packages not installed for multiple 
implementations.
 # @DESCRIPTION:
 # An extension of lua.eclass suite for packages which don't support being
-- 
2.33.0




[gentoo-dev] [PATCH 27/44] lua.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/lua.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index f1967ae6e015..5c2a7b290061 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -9,6 +9,7 @@
 # Marek Szuba 
 # Based on python-r1.eclass by Michał Górny  et al.
 # @SUPPORTED_EAPIS: 7 8
+# @PROVIDES: lua-utils
 # @BLURB: A common eclass for Lua packages
 # @DESCRIPTION:
 # A common eclass providing helper functions to build and install
-- 
2.33.0




[gentoo-dev] [PATCH 26/44] linux-mod.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/linux-mod.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index eda5e9aee013..4b61d2a8a62b 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -8,6 +8,7 @@
 # John Mylchreest ,
 # Stefan Schweizer 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: linux-info
 # @BLURB: It provides the functionality required to install external modules 
against a kernel source tree.
 # @DESCRIPTION:
 # This eclass is used to interface with linux-info.eclass in such a way
-- 
2.33.0




[gentoo-dev] [PATCH 25/44] kodi-addon.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/kodi-addon.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/kodi-addon.eclass b/eclass/kodi-addon.eclass
index fc2a7a8d8aa7..64f8426e9b4b 100644
--- a/eclass/kodi-addon.eclass
+++ b/eclass/kodi-addon.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # candr...@gentoo.org
 # @SUPPORTED_EAPIS: 4 5 6 7
+# @PROVIDES: cmake cmake-utils
 # @BLURB: Helper for correct building and (importantly) installing Kodi addon 
packages.
 # @DESCRIPTION:
 # Provides a src_configure function for correct CMake configuration
-- 
2.33.0




[gentoo-dev] [PATCH 24/44] kernel-install.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/kernel-install.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/kernel-install.eclass b/eclass/kernel-install.eclass
index b80a8d6ea93b..609afa754deb 100644
--- a/eclass/kernel-install.eclass
+++ b/eclass/kernel-install.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Michał Górny 
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: dist-kernel-utils
 # @BLURB: Installation mechanics for Distribution Kernels
 # @DESCRIPTION:
 # This eclass provides the logic needed to test and install different
-- 
2.33.0




[gentoo-dev] [PATCH 23/44] kernel-build.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/kernel-build.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/kernel-build.eclass b/eclass/kernel-build.eclass
index 28fed910fff8..279649301087 100644
--- a/eclass/kernel-build.eclass
+++ b/eclass/kernel-build.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Michał Górny 
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: kernel-install
 # @BLURB: Build mechanics for Distribution Kernels
 # @DESCRIPTION:
 # This eclass provides the logic to build a Distribution Kernel from
-- 
2.33.0




[gentoo-dev] [PATCH 22/44] java-pkg-opt-2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/java-pkg-opt-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/java-pkg-opt-2.eclass b/eclass/java-pkg-opt-2.eclass
index 7f1f5a2f8394..85783bae6e2d 100644
--- a/eclass/java-pkg-opt-2.eclass
+++ b/eclass/java-pkg-opt-2.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Thomas Matthijs 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: java-utils-2
 # @BLURB: Eclass for package with optional Java support
 # @DESCRIPTION:
 # Inherit this eclass instead of java-pkg-2 if you only need optional Java
-- 
2.33.0




[gentoo-dev] [PATCH 21/44] java-pkg-2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/java-pkg-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/java-pkg-2.eclass b/eclass/java-pkg-2.eclass
index 4d5cb7665728..96d33f9d1962 100644
--- a/eclass/java-pkg-2.eclass
+++ b/eclass/java-pkg-2.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Thomas Matthijs 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: java-utils-2
 # @BLURB: Eclass for Java Packages
 # @DESCRIPTION:
 # This eclass should be inherited for pure Java packages, or by packages which
-- 
2.33.0




[gentoo-dev] [PATCH 20/44] java-osgi.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/java-osgi.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/java-osgi.eclass b/eclass/java-osgi.eclass
index abbf73cdd3fa..74c7c1a07f5c 100644
--- a/eclass/java-osgi.eclass
+++ b/eclass/java-osgi.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Java maintainers 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: java-utils-2
 # @BLURB: Java OSGi eclass
 # @DESCRIPTION:
 # This eclass provides functionality which is used by packages that need to be
-- 
2.33.0




[gentoo-dev] [PATCH 19/44] java-ant-2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/java-ant-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass
index 5592186936c0..501d17ef229e 100644
--- a/eclass/java-ant-2.eclass
+++ b/eclass/java-ant-2.eclass
@@ -8,6 +8,7 @@
 # kiorky 
 # Petteri Räty 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: java-utils-2
 # @BLURB: eclass for ant based Java packages
 # @DESCRIPTION:
 # Eclass for Ant-based Java packages. Provides support for both automatic and
-- 
2.33.0




[gentoo-dev] [PATCH 18/44] haskell-cabal.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/haskell-cabal.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/haskell-cabal.eclass b/eclass/haskell-cabal.eclass
index 9587c33a12b6..ab1b865fda93 100644
--- a/eclass/haskell-cabal.eclass
+++ b/eclass/haskell-cabal.eclass
@@ -8,6 +8,7 @@
 # Original author: Andres Loeh 
 # Original author: Duncan Coutts 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: ghc-package
 # @BLURB: for packages that make use of the Haskell Common Architecture for 
Building Applications and Libraries (cabal)
 # @DESCRIPTION:
 # Basic instructions:
-- 
2.33.0




[gentoo-dev] [PATCH 17/44] gstreamer-meson.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/gstreamer-meson.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/gstreamer-meson.eclass b/eclass/gstreamer-meson.eclass
index 2a45df008c29..152a52b984f1 100644
--- a/eclass/gstreamer-meson.eclass
+++ b/eclass/gstreamer-meson.eclass
@@ -14,6 +14,7 @@
 # Steven Newbury
 # @SUPPORTED_EAPIS: 7
 # @BLURB: Helps building core & split gstreamer plugins
+# @PROVIDES: meson multilib-minimal
 # @DESCRIPTION:
 # Eclass to make external gst-plugins emergable on a per-plugin basis
 # and to solve the problem with gst-plugins generating far too much
-- 
2.33.0




[gentoo-dev] [PATCH 16/44] gstreamer.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/gstreamer.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/gstreamer.eclass b/eclass/gstreamer.eclass
index 301d0874106e..399fe1377329 100644
--- a/eclass/gstreamer.eclass
+++ b/eclass/gstreamer.eclass
@@ -11,6 +11,7 @@
 # foser 
 # zaheerm 
 # @SUPPORTED_EAPIS: 5 6
+# @PROVIDES: multilib-minimal
 # @BLURB: Helps building core & split gstreamer plugins.
 # @DESCRIPTION:
 # Eclass to make external gst-plugins emergable on a per-plugin basis
-- 
2.33.0




[gentoo-dev] [PATCH 15/44] go-module.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/go-module.eclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index d1e81babf1f8..110d3f039838 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -1,4 +1,4 @@
-# Copyright 2019-2020 Gentoo Authors
+# Copyright 2019-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: go-module.eclass
@@ -8,6 +8,7 @@
 # William Hubbs 
 # Robin H. Johnson 
 # @SUPPORTED_EAPIS: 7 8
+# @PROVIDES: golang-base
 # @BLURB: basic eclass for building software written as go modules
 # @DESCRIPTION:
 # This eclass provides basic settings and functions needed by all software
-- 
2.33.0




[gentoo-dev] [PATCH 14/44] golang-vcs-snapshot.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/golang-vcs-snapshot.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/golang-vcs-snapshot.eclass 
b/eclass/golang-vcs-snapshot.eclass
index abdb7fa119dd..66503e38b59d 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # William Hubbs 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: golang-base
 # @BLURB: eclass to unpack VCS snapshot tarballs for Go software
 # @DESCRIPTION:
 # This eclass provides a convenience src_unpack() which unpacks the
-- 
2.33.0




[gentoo-dev] [PATCH 13/44] golang-build.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/golang-build.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/golang-build.eclass b/eclass/golang-build.eclass
index d106a30eb58a..308503e84950 100644
--- a/eclass/golang-build.eclass
+++ b/eclass/golang-build.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # William Hubbs 
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: golang-base
 # @BLURB: Eclass for compiling go packages.
 # @DESCRIPTION:
 # This eclass provides default  src_compile, src_test and src_install
-- 
2.33.0




[gentoo-dev] [PATCH 12/44] gnustep-2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/gnustep-2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/gnustep-2.eclass b/eclass/gnustep-2.eclass
index 2d615db3a1f2..68c15bbc62e1 100644
--- a/eclass/gnustep-2.eclass
+++ b/eclass/gnustep-2.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # GNUstep Herd 
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: gnustep-base
 # @BLURB: eclass for GNUstep Apps, Frameworks, and Bundles build
 # @DESCRIPTION:
 # This eclass sets up GNUstep environment to properly install
-- 
2.33.0




[gentoo-dev] [PATCH 11/44] gnome2-utils.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/gnome2-utils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index 8513de0af4d6..f7d45090f820 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # gn...@gentoo.org
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: xdg-utils
 # @BLURB: Auxiliary functions commonly used by Gnome packages.
 # @DESCRIPTION:
 # This eclass provides a set of auxiliary functions needed by most Gnome
-- 
2.33.0




[gentoo-dev] [PATCH 10/44] gnome2.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/gnome2.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 27ea9f96c0d9..6fab55785be5 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # gn...@gentoo.org
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: gnome2-utils
 # @BLURB: Provides phases for Gnome/Gtk+ based packages.
 # @DESCRIPTION:
 # Exports portage base functions used by ebuilds written for packages using the
-- 
2.33.0




[gentoo-dev] [PATCH 09/44] eutils.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/eutils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 207d05e7f975..276d3ddace88 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # base-sys...@gentoo.org
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: desktop edos2unix epatch estack ltprune multilib preserve-libs 
strip-linguas toolchain-funcs vcs-clean wrapper
 # @BLURB: many extra (but common) functions that are used in ebuilds
 # @DESCRIPTION:
 # The eutils eclass contains a suite of functions that complement
-- 
2.33.0




[gentoo-dev] [PATCH 08/44] ecm.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ecm.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ecm.eclass b/eclass/ecm.eclass
index 5f10a7caf78d..c67a9784e716 100644
--- a/eclass/ecm.eclass
+++ b/eclass/ecm.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # k...@gentoo.org
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: cmake
 # @BLURB: Support eclass for packages that use KDE Frameworks with ECM.
 # @DESCRIPTION:
 # This eclass is intended to streamline the creation of ebuilds for packages
-- 
2.33.0




[gentoo-dev] [PATCH 07/44] distutils-r1.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 3207ed6f4b8e..75e8179c810e 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -8,6 +8,7 @@
 # Author: Michał Górny 
 # Based on the work of: Krzysztof Pawlik 
 # @SUPPORTED_EAPIS: 6 7 8
+# @PROVIDES: python-r1 python-single-r1
 # @BLURB: A simple eclass to build Python packages using distutils.
 # @DESCRIPTION:
 # A simple eclass providing functions to build Python packages using
-- 
2.33.0




[gentoo-dev] [PATCH 06/44] cmake-utils.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/cmake-utils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 8a4405bef86c..28753faf664b 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -10,6 +10,7 @@
 # (undisclosed contributors)
 # Original author: Zephyrus (zephy...@mirach.it)
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: ninja-utils
 # @BLURB: common ebuild functions for cmake-based packages
 # @DEPRECATED: cmake.eclass
 # @DESCRIPTION:
-- 
2.33.0




[gentoo-dev] [PATCH 05/44] cmake-multilib.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/cmake-multilib.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/cmake-multilib.eclass b/eclass/cmake-multilib.eclass
index 6b38d2606551..119ed1daff50 100644
--- a/eclass/cmake-multilib.eclass
+++ b/eclass/cmake-multilib.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Author: Michał Górny 
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: cmake cmake-utils multilib-minimal
 # @BLURB: cmake wrapper for multilib builds
 # @DESCRIPTION:
 # The cmake-multilib.eclass provides a glue between cmake.eclass(5)
-- 
2.33.0




[gentoo-dev] [PATCH 04/44] cmake.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/cmake.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea62..c19ea90264d1 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -10,6 +10,7 @@
 # (undisclosed contributors)
 # Original author: Zephyrus (zephy...@mirach.it)
 # @SUPPORTED_EAPIS: 7
+# @PROVIDES: ninja-utils
 # @BLURB: common ebuild functions for cmake-based packages
 # @DESCRIPTION:
 # The cmake eclass makes creating ebuilds for cmake-based packages much easier.
-- 
2.33.0




[gentoo-dev] [PATCH 03/44] autotools.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/autotools.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 66d4686849db..bded69fc8fb5 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # base-sys...@gentoo.org
 # @SUPPORTED_EAPIS: 5 6 7 8
+# @PROVIDES: libtool
 # @BLURB: Regenerates auto* build scripts
 # @DESCRIPTION:
 # This eclass is for safely handling autotooled software packages that need to
-- 
2.33.0




[gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/apache-module.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/apache-module.eclass b/eclass/apache-module.eclass
index 2594445c8b4f..16ebed9faa96 100644
--- a/eclass/apache-module.eclass
+++ b/eclass/apache-module.eclass
@@ -5,6 +5,7 @@
 # @MAINTAINER:
 # apache-b...@gentoo.org
 # @SUPPORTED_EAPIS: 5 6 7
+# @PROVIDES: depend.apache
 # @BLURB: Provides a common set of functions for apache modules
 # @DESCRIPTION:
 # This eclass handles apache modules in a sane way.
-- 
2.33.0




[gentoo-dev] [PATCH 01/44] ant-tasks.eclass: Set @PROVIDES

2021-09-02 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 eclass/ant-tasks.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
index ea347fd706af..71923261084c 100644
--- a/eclass/ant-tasks.eclass
+++ b/eclass/ant-tasks.eclass
@@ -7,6 +7,7 @@
 # @AUTHOR:
 # Vlastimil Babka 
 # @SUPPORTED_EAPIS: 6 7
+# @PROVIDES: java-utils-2
 # @BLURB: Eclass for building dev-java/ant-* packages
 # @DESCRIPTION:
 # This eclass provides functionality and default ebuild variables for building
-- 
2.33.0




[gentoo-dev] [PATCH 00/44] @PROVIDES for eclasses

2021-09-02 Thread Michał Górny
Hi,

Here are proposed @PROVIDES value for eclasses.

@PROVIDES is the new eclassdoc key that indicates that the eclass
indirectly provides API of another eclasses, i.e. if X has @PROVIDES
on Y, then you don't have to inherit Y explicitly when using X.

For example, python-r1 eclasses all provide python-utils-r1 since you
never have to inherit it when using python-r1 eclasses, and distutils-r1
provides python-r1 or python-single-r1.  @PROVIDES are processed
recursively, i.e. you don't need to list indirectly provided eclasses.

I've assembled the list by running `pkgcheck scan -c InheritsCheck`
until it didn't seem to list any obvious false positives.  However,
eclass maintainers probably know better which eclasses should be
provided indirectly, so please review.


Michał Górny (44):
  ant-tasks.eclass: Set @PROVIDES
  apache-module.eclass: Set @PROVIDES
  autotools.eclass: Set @PROVIDES
  cmake.eclass: Set @PROVIDES
  cmake-multilib.eclass: Set @PROVIDES
  cmake-utils.eclass: Set @PROVIDES
  distutils-r1.eclass: Set @PROVIDES
  ecm.eclass: Set @PROVIDES
  eutils.eclass: Set @PROVIDES
  gnome2.eclass: Set @PROVIDES
  gnome2-utils.eclass: Set @PROVIDES
  gnustep-2.eclass: Set @PROVIDES
  golang-build.eclass: Set @PROVIDES
  golang-vcs-snapshot.eclass: Set @PROVIDES
  go-module.eclass: Set @PROVIDES
  gstreamer.eclass: Set @PROVIDES
  gstreamer-meson.eclass: Set @PROVIDES
  haskell-cabal.eclass: Set @PROVIDES
  java-ant-2.eclass: Set @PROVIDES
  java-osgi.eclass: Set @PROVIDES
  java-pkg-2.eclass: Set @PROVIDES
  java-pkg-opt-2.eclass: Set @PROVIDES
  kernel-build.eclass: Set @PROVIDES
  kernel-install.eclass: Set @PROVIDES
  kodi-addon.eclass: Set @PROVIDES
  linux-mod.eclass: Set @PROVIDES
  lua.eclass: Set @PROVIDES
  lua-single.eclass: Set @PROVIDES
  meson.eclass: Set @PROVIDES
  meson-multilib.eclass: Set @PROVIDES
  multilib-build.eclass: Set @PROVIDES
  multilib-minimal.eclass: Set @PROVIDES
  perl-module.eclass: Set @PROVIDES
  php-ext-pecl-r3.eclass: Set @PROVIDES
  postgres-multi.eclass: Set @PROVIDES
  python-any-r1.eclass: Set @PROVIDES
  python-r1.eclass: Set @PROVIDES
  python-single-r1.eclass: Set @PROVIDES
  ros-catkin.eclass: Set @PROVIDES
  ruby-fakegem.eclass: Set @PROVIDES
  ruby-ng-gnome2.eclass: Set @PROVIDES
  ruby-single.eclass: Set @PROVIDES
  xdg.eclass: Set @PROVIDES
  xorg-3.eclass: Set @PROVIDES

 eclass/ant-tasks.eclass   | 1 +
 eclass/apache-module.eclass   | 1 +
 eclass/autotools.eclass   | 1 +
 eclass/cmake-multilib.eclass  | 1 +
 eclass/cmake-utils.eclass | 1 +
 eclass/cmake.eclass   | 1 +
 eclass/distutils-r1.eclass| 1 +
 eclass/ecm.eclass | 1 +
 eclass/eutils.eclass  | 1 +
 eclass/gnome2-utils.eclass| 1 +
 eclass/gnome2.eclass  | 1 +
 eclass/gnustep-2.eclass   | 1 +
 eclass/go-module.eclass   | 3 ++-
 eclass/golang-build.eclass| 1 +
 eclass/golang-vcs-snapshot.eclass | 1 +
 eclass/gstreamer-meson.eclass | 1 +
 eclass/gstreamer.eclass   | 1 +
 eclass/haskell-cabal.eclass   | 1 +
 eclass/java-ant-2.eclass  | 1 +
 eclass/java-osgi.eclass   | 1 +
 eclass/java-pkg-2.eclass  | 1 +
 eclass/java-pkg-opt-2.eclass  | 1 +
 eclass/kernel-build.eclass| 1 +
 eclass/kernel-install.eclass  | 1 +
 eclass/kodi-addon.eclass  | 1 +
 eclass/linux-mod.eclass   | 1 +
 eclass/lua-single.eclass  | 1 +
 eclass/lua.eclass | 1 +
 eclass/meson-multilib.eclass  | 1 +
 eclass/meson.eclass   | 1 +
 eclass/multilib-build.eclass  | 1 +
 eclass/multilib-minimal.eclass| 1 +
 eclass/perl-module.eclass | 1 +
 eclass/php-ext-pecl-r3.eclass | 1 +
 eclass/postgres-multi.eclass  | 1 +
 eclass/python-any-r1.eclass   | 1 +
 eclass/python-r1.eclass   | 1 +
 eclass/python-single-r1.eclass| 1 +
 eclass/ros-catkin.eclass  | 1 +
 eclass/ruby-fakegem.eclass| 1 +
 eclass/ruby-ng-gnome2.eclass  | 1 +
 eclass/ruby-single.eclass | 1 +
 eclass/xdg.eclass | 1 +
 eclass/xorg-3.eclass  | 1 +
 44 files changed, 45 insertions(+), 1 deletion(-)

-- 
2.33.0




Re: [gentoo-dev] [PATCH eclass2manpage] Add @PROVIDES tag to indicate transitive eclass inheritance

2021-09-01 Thread Michał Górny
On Sun, 2021-08-29 at 11:17 +0200, Michał Górny wrote:
> Add a @PROVIDES eclassdoc tag that can be used to indicate that
> a particular eclass transitively provides the functions from another
> eclass and therefore ebuilds inheriting it do not have to explicitly
> inherit the other eclass.
> 
> For example, distutils-r1 provides python-r1/python-single-r1, and all
> python*-r1 eclasse provide python-utils-r1.
> 
> This data will be used to drive pkgcheck checks for missing inherits.
> 

Merged.  Expect new pkgcore+pkgcheck release in a few days.

-- 
Best regards,
Michał Górny





[gentoo-portage-dev] [PATCH] post_emerge: Display all preserved libs with --verbose

2021-08-31 Thread Michał Górny
---
 lib/_emerge/post_emerge.py   |  2 +-
 lib/portage/util/_dyn_libs/display_preserved_libs.py | 11 +++
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/lib/_emerge/post_emerge.py b/lib/_emerge/post_emerge.py
index 0c4df0d32..c540308d3 100644
--- a/lib/_emerge/post_emerge.py
+++ b/lib/_emerge/post_emerge.py
@@ -140,7 +140,7 @@ def post_emerge(myaction, myopts, myfiles,
else:
print()
print(colorize("WARN", "!!!") + " existing preserved 
libs:")
-   display_preserved_libs(vardbapi)
+   display_preserved_libs(vardbapi, verbose="--verbose" in 
myopts)
print("Use " + colorize("GOOD", "emerge 
@preserved-rebuild") +
" to rebuild packages using these libraries")
 
diff --git a/lib/portage/util/_dyn_libs/display_preserved_libs.py 
b/lib/portage/util/_dyn_libs/display_preserved_libs.py
index 8deafc25e..5818501bb 100644
--- a/lib/portage/util/_dyn_libs/display_preserved_libs.py
+++ b/lib/portage/util/_dyn_libs/display_preserved_libs.py
@@ -6,7 +6,7 @@ import portage
 
 from portage.output import colorize
 
-def display_preserved_libs(vardb):
+def display_preserved_libs(vardb, verbose=False):
 
MAX_DISPLAY = 3
 
@@ -36,7 +36,8 @@ def display_preserved_libs(vardb):
consumers.append(c)
consumers.sort()
consumer_map[f] = consumers
-   
search_for_owners.update(consumers[:MAX_DISPLAY+1])
+   max_search = None if verbose else MAX_DISPLAY + 
1
+   search_for_owners.update(consumers[:max_search])
 
owners = {}
for f in search_for_owners:
@@ -75,7 +76,9 @@ def display_preserved_libs(vardb):
# they don't need to be rebuilt (see bug 
#461908).
consumers = consumers_non_preserved
 
-   if len(consumers) == MAX_DISPLAY + 1:
+   if verbose:
+   max_display = None
+   elif len(consumers) == MAX_DISPLAY + 1:
# Display 1 extra consumer, instead of 
displaying
# "used by 1 other files".
max_display = MAX_DISPLAY + 1
@@ -91,6 +94,6 @@ def display_preserved_libs(vardb):
owners_desc = ", ".join(x.mycpv for x 
in owners.get(c, []))
print(colorize("WARN", " * ") + " used by 
%s (%s)" % \
(c, owners_desc))
-   if len(consumers) > max_display:
+   if not verbose and len(consumers) > max_display:
print(colorize("WARN", " * ") + " used by 
%d other files" %
(len(consumers) - max_display))
-- 
2.33.0




Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.sh: Update QA notice in inherit()

2021-08-29 Thread Michał Górny
On Mon, 2021-08-30 at 00:47 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 29 Aug 2021, Michał Górny wrote:
> 
> > On Sun, 2021-08-29 at 22:06 +0200, Ulrich Müller wrote:
> > > - eqawarn "For compatibility with
> > > <=portage-2.1.6.7, only call EXPORT_FUNCTIONS"
> > > - eqawarn "after inherit(s)."
> > > + eqawarn "For compatibility with PMS, only
> > > call EXPORT_FUNCTIONS after inherit(s)."
> 
> > Could you add a sentence that the current Portage behavior is going
> > to
> > change in the future?
> 
> Sure, but do we actually know that?

That's the plan today, can't be 100% sure it'll happen.  You can say
'can change' if you think it's better -- but people need some motivation
or they're just going to ignore it as 'another PMS noise'.

Alternatively, we could mention that pkgcore is broken by this.
My point is mostly to say 'yes, this breaks stuff for users today, it's
not just some theory'.

-- 
Best regards,
Michał Górny





Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.sh: Update QA notice in inherit()

2021-08-29 Thread Michał Górny
On Sun, 2021-08-29 at 22:06 +0200, Ulrich Müller wrote:
> Bug: https://bugs.gentoo.org/399039
> Signed-off-by: Ulrich Müller 
> ---
>  bin/ebuild.sh | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/bin/ebuild.sh b/bin/ebuild.sh
> index 1bca2c965..f5f3d9eec 100755
> --- a/bin/ebuild.sh
> +++ b/bin/ebuild.sh
> @@ -248,8 +248,7 @@ inherit() {
>   # previous inherit call in the call stack.
>   if [[ -n ${ECLASS} && -n ${!__export_funcs_var} ]] ; then
>   eqawarn "QA Notice: EXPORT_FUNCTIONS is called before 
> inherit in ${ECLASS}.eclass."
> - eqawarn "For compatibility with <=portage-2.1.6.7, only 
> call EXPORT_FUNCTIONS"
> - eqawarn "after inherit(s)."
> + eqawarn "For compatibility with PMS, only call 
> EXPORT_FUNCTIONS after inherit(s)."
>   fi
>   fi
> 

Could you add a sentence that the current Portage behavior is going to
change in the future?


-- 
Best regards,
Michał Górny





Re: [gentoo-dev] The inherit-EXPORT_FUNCTIONS ordering problem

2021-08-29 Thread Michał Górny
On Sun, 2021-08-29 at 14:41 -0400, Ionen Wolkens wrote:
> On Sun, Aug 29, 2021 at 12:23:22PM -0500, William Hubbs wrote:
> > On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote:
> > > Hi,
> > > 
> > > I've been informed of a slight inconsistency in package manager behavior
> > > that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
> > > for the report!).  Please consider the three following snippets:
> >  
> >  ...
> > 
> > > 1. I'd like to propose that we explicitly require all inherits to happen
> > > before EXPORT_FUNCTIONS.  This will ensure consistent behavior across
> > > all package managers.
> > > 
> > > 2. I'd like to ask your opinion whether we should:
> > > 
> > > a. revert the Portage behavior to be consistent with PkgCore/Paludis
> > > 
> > > b. update PMS to identify the behavior as 'undefined', i.e. either
> > > solution is correct.
> > 
> > I would go with 1 and 2 b, but I also propose another option for the
> > next eapi which may be a bit controversial.
> > 
> > Starting with eapi 9, make export_functions a noop (you can't remove it
> > until all eclasses/ebuilds only support eapis that don't require it).
> > 
> > I understand that this is controversial, because it would require a lot
> > of work to convert ebuilds to eapi 9, but it would eliminate this
> > ambiguity/inconsistency in the future because it would require all
> > ebuilds to have phase functions unless they can use the default phases
> > the eapis provide.
> > 
> > Thoughts?
> 
> If anything I'd personally prefer the rough opposite of this, in the
> event multiple eclass export the same, have the package manager merge
> them.
> 
> e.g. rather than have `inherit cmake xdg` run xdg_src_prepare over
> cmake's, would export:
> 
> src_prepare() {
>   cmake_src_prepare
>   xdg_src_prepare
> }
> 
> unless the ebuild redefines it (which I imagine would often be because
> of optional support, e.g. use lua &&, or occasional incompatibilities)
> 
> Some ebuilds have special needs, but then there's all those generic
> ebuilds that should stay nearly empty.

What about transitive inherits?  Say, foo.eclass inherits bar.eclass. 
Does that imply that the ebuild calls foo_src_prepare
and bar_src_prepare, and the eclass has no way of overriding this?  What
if the eclass needs bar_src_prepare called explicitly before or after
its own src_prepare?

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] The inherit-EXPORT_FUNCTIONS ordering problem

2021-08-29 Thread Michał Górny
On Sun, 2021-08-29 at 12:23 -0500, William Hubbs wrote:
> On Sat, Aug 28, 2021 at 06:35:06PM +0200, Michał Górny wrote:
> > Hi,
> > 
> > I've been informed of a slight inconsistency in package manager behavior
> > that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
> > for the report!).  Please consider the three following snippets:
>  
>  ...
> 
> > 1. I'd like to propose that we explicitly require all inherits to happen
> > before EXPORT_FUNCTIONS.  This will ensure consistent behavior across
> > all package managers.
> > 
> > 2. I'd like to ask your opinion whether we should:
> > 
> > a. revert the Portage behavior to be consistent with PkgCore/Paludis
> > 
> > b. update PMS to identify the behavior as 'undefined', i.e. either
> > solution is correct.
> 
> I would go with 1 and 2 b, but I also propose another option for the
> next eapi which may be a bit controversial.
> 
> Starting with eapi 9, make export_functions a noop (you can't remove it
> until all eclasses/ebuilds only support eapis that don't require it).
> 
> I understand that this is controversial, because it would require a lot
> of work to convert ebuilds to eapi 9, but it would eliminate this
> ambiguity/inconsistency in the future because it would require all
> ebuilds to have phase functions unless they can use the default phases
> the eapis provide.
> 
> Thoughts?
> 

It would not only require work to convert ebuilds but it would also
require a lot of work when writing new ebuilds.  The developers would
have to explicitly remember to call the correct set of phases for each
inherited eclass, and this is a lot of work for the lot of otherwise
trivial ebuilds.

Not to mention the quite obvious risk of silent breakage when people
forget to call a phase function.  Just imagine that all python-single-r1
ebuilds would have to call python-single-r1_pkg_setup explicitly or they
would silently fall back to random Python version that's going to work
90% of the time, so people won't even notice that the ebuild is broken.

In the end, this would naturally lead to people hacking this around by
reinventing EXPORT_FUNCTIONS inside eclasses.  In the best case, we'd
see functions like 'cmake_export_phases' -- which maybe, just maybe,
would be better than implicit exports.

-- 
Best regards,
Michał Górny





[gentoo-dev] [PATCH eclass2manpage] Add @PROVIDES tag to indicate transitive eclass inheritance

2021-08-29 Thread Michał Górny
Add a @PROVIDES eclassdoc tag that can be used to indicate that
a particular eclass transitively provides the functions from another
eclass and therefore ebuilds inheriting it do not have to explicitly
inherit the other eclass.

For example, distutils-r1 provides python-r1/python-single-r1, and all
python*-r1 eclasse provide python-utils-r1.

This data will be used to drive pkgcheck checks for missing inherits.

Signed-off-by: Michał Górny 
---
 eclass-to-manpage.awk | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/eclass-to-manpage.awk b/eclass-to-manpage.awk
index 1ffafd1..cde7c2b 100755
--- a/eclass-to-manpage.awk
+++ b/eclass-to-manpage.awk
@@ -174,6 +174,7 @@ function handle_eclass() {
eclass_maintainer = ""
eclass_author = ""
supported_eapis = ""
+   provides = ""
blurb = ""
deprecated = ""
desc = ""
@@ -207,6 +208,8 @@ function handle_eclass() {
vcs_url = eat_line()
if ($2 == "@SUPPORTED_EAPIS:")
supported_eapis = eat_line()
+   if ($2 == "@PROVIDES:")
+   provides = eat_line()
if ($2 == "@BLURB:")
blurb = eat_line()
if ($2 == "@DEPRECATED:")
@@ -234,6 +237,10 @@ function handle_eclass() {
print ".SH \"SUPPORTED EAPIS\""
print man_text(supported_eapis)
}
+   if (provides != "") {
+   print ".SH \"TRANSITIVELY PROVIDED ECLASSES\""
+   print man_text(provides)
+   }
if (example != "") {
print ".SH \"EXAMPLE\""
print man_text(example)
-- 
2.33.0




[gentoo-dev] The inherit-EXPORT_FUNCTIONS ordering problem

2021-08-28 Thread Michał Górny
Hi,

I've been informed of a slight inconsistency in package manager behavior
that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
for the report!).  Please consider the three following snippets:

xdg.eclass:

  EXPORT_FUNCTIONS src_prepare

ecm-1.eclass:

  inherit xdg
  EXPORT_FUNCTIONS src_prepare

ecm-2.eclass:

  EXPORT_FUNCTIONS src_prepare
  inherit xdg


Now, ecm-1.eclass produces consistent behavior across all PMs --
ecm-1_src_prepare takes precedence.  However, ecm-2.eclass is not
consistent:

- Portage will take ecm-2_src_prepare, i.e. applies precedence based
on inherit order and not actual call order

- PkgCore and Paludis will take xdg_src_prepare since its
EXPORT_FUNCTIONS are called later (since the inherit is done later).

Apparently, the Portage behavior was changed in 2009 [1].  PMS is not
very clear on what should happen.


Therefore:

1. I'd like to propose that we explicitly require all inherits to happen
before EXPORT_FUNCTIONS.  This will ensure consistent behavior across
all package managers.

2. I'd like to ask your opinion whether we should:

a. revert the Portage behavior to be consistent with PkgCore/Paludis

b. update PMS to identify the behavior as 'undefined', i.e. either
solution is correct.


WDYT?


[1] 
https://github.com/gentoo/portage/commit/06d4433e8b8be60d606733b9e23f57f8a5869d8f

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Stabilization Detached from Security Bugs

2021-08-27 Thread Michał Górny
On Thu, 2021-08-26 at 19:11 -0500, John Helmert III wrote:
> In the past, stabilization for security bugs would be handled directly
> in that security bug. After some discussion on the gentoo-dev mailing
> list [1], there was some consensus on modifying this workflow to
> separate stabilization from security bugs. Going forward, separate bugs
> should be filed for security stabilizations and then the security bug
> will have a dependency on its stabilization bug.

Great!  I can make the field invisible on security bugs when you've
confirmed that all pending stabilizations are finished.  Or without
that, if you prefer ;-).

-- 
Best regards,
Michał Górny





[gentoo-dev] New project: Gentoo History

2021-08-25 Thread Michał Górny
Hi,

It is my pleasure to announce forming of a new Gentoo History project
[1].  We invite everyone who's interested in researching and documenting
Gentoo's past.  This is primarily an effort to create a single place
where our various works can be found.

[1] https://wiki.gentoo.org/wiki/Project:Gentoo_History

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] meson.eclass: stop calling ninja

2021-08-24 Thread Michał Górny
On Tue, 2021-08-24 at 00:35 -0500, William Hubbs wrote:
> Use the compile and install subcommands of meson instead of calling
> ninja. This allows for the possibility of a different back end.
> 
> Signed-off-by: William Hubbs 
> ---
>  eclass/meson.eclass | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 2a563e367c6..e9c9b155096 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -379,7 +379,21 @@ meson_src_configure() {
>  meson_src_compile() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - eninja -C "${BUILD_DIR}" "$@"
> + local mesoncompileargs=(
> + -C "${BUILD_DIR}"
> + )
> + if [[ -n ${NINJAOPTS} ]]; then

Shouldn't NINJAOPTS be only used with the ninja backend then?

> + mesoncompileargs+=(
> + --jobs "$(makeopts_jobs ${NINJAOPTS})"
> + --load-average "$(makeopts_loadavg ${NINJAOPTS})"
> + )
> + elif [[ -n ${MAKEOPTS} ]]; then
> + mesoncompileargs+=(
> + --jobs "$(makeopts_jobs ${MAKEOPTS})"
> + --load-average "$(makeopts_loadavg ${MAKEOPTS})"
> + )

Does this really work without a 'fi'?

Also, you could avoid repetition by putting NINJAOPTS/MAKEOPTS into
a local variable, and passing that to makeopts_*.

> +
> + meson compile "${mesoncompileargs[@]}" "$@" || die "compile failed"
>  }
>  
>  # @FUNCTION: meson_src_test
> @@ -406,13 +420,17 @@ meson_src_test() {
>  }
>  
>  # @FUNCTION: meson_src_install
> -# @USAGE: [extra ninja install arguments]
> +# @USAGE: [extra meson install arguments]
>  # @DESCRIPTION:
>  # This is the meson_src_install function.
>  meson_src_install() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - DESTDIR="${D}" eninja -C "${BUILD_DIR}" install "$@"
> + local mesoninstallargs=(
> + -C "${BUILD_DIR}" "$@"
> + --destdir "${D}"
> + )
> + meson install "${mesoninstallargs[@]}" "$@"
>  
>   pushd "${S}" > /dev/null || die
>   einstalldocs

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] linux-mod.eclass: respect INSTALL_MOD_PATH

2021-08-23 Thread Michał Górny
On Mon, 2021-08-23 at 14:32 -0400, Mike Pagano wrote:
> Change to respect INSTALL_MOD_PATH
> 
> Bug: https://bugs.gentoo.org/642240
> 
> Signed-off-by: Mike Pagano 
> ---
>   eclass/linux-mod.eclass | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> index e87c5ec0c..48d7a8cbb 100644
> --- a/eclass/linux-mod.eclass
> +++ b/eclass/linux-mod.eclass
> @@ -741,7 +741,7 @@ linux-mod_src_install() {
>   
>   einfo "Installing ${modulename} module"
>   cd "${objdir}" || die "${objdir} does not exist"
> - insinto /lib/modules/${KV_FULL}/${libdir}
> + insinto ${INSTALL_MOD_PATH}/lib/modules/${KV_FULL}/${libdir}

Double quotes?

>   doins ${modulename}.${KV_OBJ} || die "doins 
> ${modulename}.${KV_OBJ} failed"
>   cd "${OLDPWD}"
>   



-- 
Best regards,
Michał Górny





Re: [gentoo-dev] News item for eudev deprecation

2021-08-23 Thread Michał Górny
On Mon, 2021-08-23 at 16:36 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 23 Aug 2021, Anthony G Basile wrote:
> 
> > > > **WARNING**
> > > > 
> > > > If you happen to have an INSTALL_MASK with a blanket "*systemd*"
> > > > glob, you will inevitably break your system. sys-fs/udev
> > > > contains
> > > > "systemd" in some of its filenames, hence a blanket filter rule
> > > > will
> > > > likely lead to a non-functional udev installation.
> > > 
> > > Will an INSTALL_MASK of "/usr/lib/systemd /etc/systemd" cause any
> > > issues?
> 
> > I have not tested, but I think so since "systemd-" is used as a
> > prefix
> > for files installed by sys-fs/udev.
> 
> So, we've abandoned the systemd USE flag, and I remember that one of
> the arguments was that users could use INSTALL_MASK for precisely the
> above mentioned directories.
> 
> Now the message is that users' systems will be broken if they had
> followed our previous advice? Seriously?

I'm pretty sure we've never officially advised anyone to remove
important directories via INSTALL_MASK.  INSTALL_MASK on unit
directories will not affect udev users.  On the other hand, if someone
was overzealous and stripped whole /lib/systemd... no compassion from
me, sorry.

We don't go out of way to support people using USE=-* either, yet that
is certainly *less stupid* than stripping arbitrary directory trees.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH 4/4] cmake.eclass: Default CMAKE_BUILD_TYPE=RelWithDebInfo in EAPI 8

2021-08-20 Thread Michał Górny
On Fri, 2021-08-20 at 09:46 +0200, Guilherme Amadio wrote:
> Hi,
> 
> On Thu, Aug 19, 2021 at 07:45:16PM +0200, Andreas Sturmlechner wrote:
> > Signed-off-by: Michał Górny 
> > Signed-off-by: Andreas Sturmlechner 
> > ---
> >  eclass/cmake.eclass | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
> > index 8befd9e5a9f..3021a3a2b1e 100644
> > --- a/eclass/cmake.eclass
> > +++ b/eclass/cmake.eclass
> > @@ -42,14 +42,19 @@ _CMAKE_ECLASS=1
> >  # Eclass can use different cmake binary than the one provided in by system.
> >  : ${CMAKE_BINARY:=cmake}
> >  
> > +[[ ${EAPI} == 7 ]] && : ${CMAKE_BUILD_TYPE:=Gentoo}
> >  # @ECLASS-VARIABLE: CMAKE_BUILD_TYPE
> >  # @DESCRIPTION:
> >  # Set to override default CMAKE_BUILD_TYPE. Only useful for packages
> >  # known to make use of "if (CMAKE_BUILD_TYPE MATCHES xxx)".
> >  # If about to be set - needs to be set before invoking cmake_src_configure.
> > -# You usually do *NOT* want nor need to set it as it pulls CMake default
> > -# build-type specific compiler flags overriding make.conf.
> > -: ${CMAKE_BUILD_TYPE:=Gentoo}
> > +#
> > +# The default is RelWithDebInfo as that is least likely to append 
> > undesirable
> > +# flags. However, you may still need to sed CMake files or choose a 
> > different
> > +# build type to achieve desirable results.
> > +#
> > +# In EAPI 7, the default was non-standard build type of Gentoo.
> > +: ${CMAKE_BUILD_TYPE:=RelWithDebInfo}
> 
> Although I think this is better than the "Gentoo" build type we had, I
> think that even better is to just leave this blank and set a default on
> a per-ebuild basis, as I commented on bug 802786[1]. Repeating my
> comment from there, build type flags always come after CMAKE__FLAGS,
> which then override make.conf settings. Moreover, setting a build type
> can also have funny behavior with multi-config generators (possible with
> ninja on Linux too now) because it has no meaning in that context. For
> instance, this may override make.conf flags with "-O2 -g" in most cases,
> preventing people from changing the optimization level of any CMake-based
> package, or disabling compilation of debug info (which is then stripped
> anyway). This is probably why we had the "Gentoo" build in the first place.
> 
> For ebuilds that must have a CMAKE_BUILD_TYPE set, we should probably
> use Release and override CMAKE__FLAGS_RELEASE with settings from
> make.conf, or make CMAKE__FLAGS contain settings from make.conf
> and enforce CMAKE__FLAGS_ is empty for all build types.
> 

No, we shouldn't.  Release often has unexpected side effects. 
RelWithDebInfo is the moderate type that is least likely to have side
effects.

The eclasses are stripping default build type flags since 2016.  Please
do some research and/or testing before posting.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: Handle deselect/ignore in epytest

2021-08-15 Thread Michał Górny
On Thu, 2021-08-12 at 12:16 +0200, Michał Górny wrote:
> Support (potentially global-scope) EPYTEST_DESELECT and EPYTEST_IGNORE
> arrays to conveniently deselect/skip tests.  This effectively replaces
> local hacks such as:
> 
> epytest ${deselect[@]/#/--deselect }
> 

Merged.

-- 
Best regards,
Michał Górny





[gentoo-dev] [PATCH] metadata/qa-policy.conf: Remove obsolete deprecated-eclass section

2021-08-15 Thread Michał Górny
The eclass deprecations are now indicated via @DEPRECATED eclassdoc tag.
The qa-policy.conf list is not used by any tools right now, so just
remove it.

Signed-off-by: Michał Górny 
---
 metadata/qa-policy.conf | 13 -
 1 file changed, 13 deletions(-)

diff --git a/metadata/qa-policy.conf b/metadata/qa-policy.conf
index db9050f2ba7b..a93c62126247 100644
--- a/metadata/qa-policy.conf
+++ b/metadata/qa-policy.conf
@@ -61,16 +61,3 @@ PG0803 = warning
 PG0901 = warning
 # Deprecated EAPIs
 PG1001 = warning
-
-
-# The deprecated-eclass section lists deprecated eclasses along with
-# their suggested replacements (if any).  Most of the values are
-# replacement eclass names, though free-form text is permitted.
-[deprecated-eclass]
-cmake-utils = cmake
-epatch = (eapply since EAPI 6)
-eutils = (split into several eclasses)
-ltprune = (inline find ... -delete)
-mono = mono-env
-user = (GLEP 81 acct-* packages)
-versionator = eapi7-ver (built-in since EAPI 7)
-- 
2.32.0




Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

2021-08-13 Thread Michał Górny
On Fri, 2021-08-13 at 12:50 -0400, Aaron Bauman wrote:
> On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote:
> > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny  wrote:
> > > 
> 
> 
> 
> > To do that, I think we'd want to change what's required for the "clean
> > up" step. Since today the "clean up" step is dropping the vulnerable
> > package versions from the tree, it is dependent on
> > non-security-supported architectures completing the stabilization bug.
> > I think we'd like to break that dependence.
> > 
> 
> Yes, please. Thank you for bringing this up. This has been a hotly
> debated item in the past with former security leads dictating that
> "clean up" is not relevant to the security process, but it remained
> codified in documentation that it needs to occur.
> 
> It is indeed important, as leaving vulnerable versions is the tree is not
> good for anyone and impacts many other areas (e.g. promoting tree
> cleanliness).
> 
> Further, as mgorny mentioned in a follow-up email to this, we need to
> understand what is a "security supported" architecture. This has also
> been an issue in the past with council intervention needed to declare
> dropping specific arches to exp profiles and allowing security to drop
> support and subsequently move bugs forward.
> 
> And to continue on my soap box, we have a small blurb on the security
> page [1] which states what architectures are considered security supported.
> This is less than ideal. We also generally state that stable arches are
> supported and must be dealt with during the vulnerability process.
> 
> So, all in all, it is highly conflated IMHO and is *not* ideal for
> anyone to have to determine that a particular arch is stable but not
> security supported. 
> 
> As such, I advocate for any stable arch to be security supported by
> default. If the arch lags or is dropped then it goes to unstable
> (process TBD).
> 

Yes, this sounds like a good idea.  We should avoid having multiple
classifications for architectures.  If something's good enough to be
stable, it should be security supported.  If it's not, then it shouldn't
be stable.

In the end, I guess the primary problem is manpower.  Given that secbugs
are normally given priority, I don't really see a case for an arch that
would be not good enough to be security supported but at the same time
good enough to cope with the wider range of bugs.

-- 
Best regards,
Michał Górny





[gentoo-dev] Package up for grabs: dev-python/mpi4py

2021-08-13 Thread Michał Górny
Hi,

The following package is looking for a new maintainer:

  dev-python/mpi4py

The package is pretty specialistic, and would use a dedicated maintainer
who knows MPI.  Its only revdeps are sci-*/ packages.

It has two bugs open, one of them a test failure.  It is pending
a version bump.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

2021-08-12 Thread Michał Górny
On Thu, 2021-08-12 at 13:17 -0700, Matt Turner wrote:
> On Thu, Aug 12, 2021 at 5:53 AM Michał Górny  wrote:
> > 
> > Hello, everyone.
> > 
> > TL;DR: I'd like to propose that stabilizations are done via blockers of
> > security bugs instead of security bugs themselves, i.e. as any other
> > stabilizations.
> > 
> > 
> > Right now we're often performing security-related stabilizations via
> > security bugs. This has a few problems, that are:
> > 
> > 1. Stabilization-related activity causes unnecessary mail to the widely
> > subscribed security alias. That is, subscribed people get notified of
> > package list changes, NATTkA results, every arch doing its work.
> > However, in reality the security team only cares about stabilization
> > being started, stalled or finished -- and for that, getting the usual
> > 'dependent bug added/closed' mail should be sufficient.
> > 
> > 2. NATTkA has no good way of distinguishing irrelevant security bugs
> > from security bugs where something went wrong (and NATTkA doesn't use
> > persistent state by design). The most important problem is that --
> > unlike regular stablereqs -- security bugs aren't supposed to be closed
> > after stabilization. It can't really distinguish a security bug 'left
> > open' from a security bug with incorrect package list.
> > 
> > 3. Proxied maintainers without editbugs can't actually CC arches on
> > security bugs since the bugs are assigned to security@.
> > 
> > 
> > To resolve these problems going forward and establish consistent
> > behavior in the future, I'd like to propose to disable 'package list'
> > fields on security bugs and instead expect regular stabilization bugs to
> > be used (and made block the security bugs) for stabilizations. While I
> > understand that filing additional bugs might be cumbersome for some
> > people, I don't think it's such a herculean effort to outweigh
> > the problems solved.
> > 
> > In the end, consistency is a good thing and we've introduced a dedicated
> > stabilization category to reduce the spread of stabilization bugs all
> > around the place.
> 
> I love this.
> 
> It sounds (from IRC) like you're on board with the idea of having
> nattka add kw:security to appropriate stabilization bugs.
> 
> Could nattka also do something to the security@-assigned but itself to
> indicate that all security-supported architecture have been handled?
> Something like leaving a comment or fiddling with the security
> whiteboard.

Yeah, this shouldn't be a problem.  However, I would prefer if 'security
supported' architectures were defined somewhere reasonably standard,
rather than hardcoded in nattka.

> 
> It would be nice to be able to resolve the security@-assigned but
> before non-security-supported architectures are handled.
> 
> To do that, I think we'd want to change what's required for the "clean
> up" step. Since today the "clean up" step is dropping the vulnerable
> package versions from the tree, it is dependent on
> non-security-supported architectures completing the stabilization bug.
> I think we'd like to break that dependence.
> 
> I suggest that we redefine the "clean up" step to be: drop
> security-supported architectures' keywords from vulnerable versions.
> That would allow the security@-assigned bug to be resolved before
> non-security-supported architectures are finished with stabilization.
> 

To be honest, this sounds like doubling the effort for little benefit. 
After all, removing the old version of the package doesn't resolve any
problems on the end user systems -- upgrading does, and upgrading
usually happens entirely independently of whether we've cleaned up or
not.

Maybe it'd easier to release GLSAs before cleanup happens?  We can
always go the dekeywording way if arch teams are actually slacking.

-- 
Best regards,
Michał Górny





[gentoo-dev] [RFC] Decoupling stabilization from security bugs

2021-08-12 Thread Michał Górny
Hello, everyone.

TL;DR: I'd like to propose that stabilizations are done via blockers of
security bugs instead of security bugs themselves, i.e. as any other
stabilizations.


Right now we're often performing security-related stabilizations via
security bugs. This has a few problems, that are:

1. Stabilization-related activity causes unnecessary mail to the widely
subscribed security alias. That is, subscribed people get notified of
package list changes, NATTkA results, every arch doing its work.
However, in reality the security team only cares about stabilization
being started, stalled or finished -- and for that, getting the usual
'dependent bug added/closed' mail should be sufficient.

2. NATTkA has no good way of distinguishing irrelevant security bugs
from security bugs where something went wrong (and NATTkA doesn't use
persistent state by design). The most important problem is that --
unlike regular stablereqs -- security bugs aren't supposed to be closed
after stabilization. It can't really distinguish a security bug 'left
open' from a security bug with incorrect package list.

3. Proxied maintainers without editbugs can't actually CC arches on
security bugs since the bugs are assigned to security@.


To resolve these problems going forward and establish consistent
behavior in the future, I'd like to propose to disable 'package list'
fields on security bugs and instead expect regular stabilization bugs to
be used (and made block the security bugs) for stabilizations. While I
understand that filing additional bugs might be cumbersome for some
people, I don't think it's such a herculean effort to outweigh
the problems solved.

In the end, consistency is a good thing and we've introduced a dedicated
stabilization category to reduce the spread of stabilization bugs all
around the place.

WDYT?

-- 
Best regards,
Michał Górny






[gentoo-dev] [PATCH v2] python-utils-r1.eclass: Handle deselect/ignore in epytest

2021-08-12 Thread Michał Górny
Support (potentially global-scope) EPYTEST_DESELECT and EPYTEST_IGNORE
arrays to conveniently deselect/skip tests.  This effectively replaces
local hacks such as:

epytest ${deselect[@]/#/--deselect }

Signed-off-by: Michał Górny 
---
 eclass/python-utils-r1.eclass | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index b104b6694ac3..356ace6a6851 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1244,11 +1244,30 @@ build_sphinx() {
HTML_DOCS+=( "${dir}/_build/html/." )
 }
 
+# @VARIABLE: EPYTEST_DESELECT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specifies an array of tests to be deselected via pytest's --deselect
+# parameter, when calling epytest.  The list can include file paths,
+# specific test functions or parametrized test invocations.
+#
+# Note that the listed files will still be subject to collection,
+# i.e. modules imported in global scope will need to be available.
+# If this is undesirable, EPYTEST_IGNORE can be used instead.
+
+# @VARIABLE: EPYTEST_IGNORE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specifies an array of paths to be ignored via pytest's --ignore
+# parameter, when calling epytest.  The listed files will be entirely
+# skipped from test collection.
+
 # @FUNCTION: epytest
 # @USAGE: [...]
 # @DESCRIPTION:
-# Run pytest, passing the standard set of pytest options, followed
-# by user-specified options.
+# Run pytest, passing the standard set of pytest options, then
+# --deselect and --ignore options based on EPYTEST_DESELECT
+# and EPYTEST_IGNORE, then user-specified options.
 #
 # This command dies on failure and respects nonfatal.
 epytest() {
@@ -1268,6 +1287,13 @@ epytest() {
# for end users, as it tends to fail on new warnings from deps
-Wdefault
)
+   local x
+   for x in "${EPYTEST_DESELECT[@]}"; do
+   args+=( --deselect "${x}" )
+   done
+   for x in "${EPYTEST_IGNORE[@]}"; do
+   args+=( --ignore "${x}" )
+   done
set -- "${EPYTHON}" -m pytest "${args[@]}" "${@}"
 
echo "${@}" >&2
-- 
2.32.0




Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

2021-08-12 Thread Michał Górny
On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
> On 8/12/21 02:13, William Hubbs wrote:
> 
> > On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
> > > I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
> > > first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> > > priority.
> > > The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
> > > semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> > > suggestions.
> > FWIW, I like loong and ABI_LOONG better, or even better would be to use the
> > string `uname -m` returns for the hardware as ARCH and as the suffix for
> > ABI_.
> 
> Ahh I forgot to mention that...
> 
> $ uname -m
> loongarch64
> 
> And the triple is "loongarch64-unknown-linux-gnu"; kernel port sits at 
> arch/loongarch; almost everything except Go uses the "loongarch" 
> version. Go people didn't like duplicating "arch" for their GOARCH 
> value, so it's "GOARCH=loong64" there, otherwise the Loongson people 
> pushing their agenda would have used "loongarch64" too.
> 
> I would say this is mostly aesthetic matter, because we have equally 
> long ARCH names like "microblaze" or "openrisc" too. From a user's 
> perspective I'd personally prefer "loong" to save some typing, but 
> "loongarch" wouldn't hurt that much either.
> 

I think following upstream (i.e. "loongarch" convention) is better.
We have already caused some mess with custom names like "arm64".

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: Handle deselect/ignore in epytest

2021-08-11 Thread Michał Górny
On Wed, 2021-08-11 at 09:49 +0200, Michał Górny wrote:
> It is a de-facto standard to use deselect=() and/or ignore=() arrays
> to pass arguments to epytest.  Let's make the function take them
> automatically without requiring unsafe hacks such as:
> 
> epytest ${deselect[@]/#/--deselect }
> 
> Signed-off-by: Michał Górny 
> ---
>  eclass/python-utils-r1.eclass | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index b104b6694ac3..04b82d4f7a78 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -1250,6 +1250,10 @@ build_sphinx() {
>  # Run pytest, passing the standard set of pytest options, followed
>  # by user-specified options.
>  #
> +# If 'deselect' array is present in the calling scope, all its elements
> +# are added as --deselect arguments to pytest.  If 'ignore' array
> +# is present, its elements are added as --ignore arguments.
> +#
>  # This command dies on failure and respects nonfatal.
>  epytest() {
>   debug-print-function ${FUNCNAME} "${@}"
> @@ -1268,6 +1272,13 @@ epytest() {
>   # for end users, as it tends to fail on new warnings from deps
>   -Wdefault
>   )
> + local x
> + for x in "${deselect[@]}"; do
> + args+=( --deselect "${x}" )
> + done
> + for x in "${ignore[@]}"; do
> + args+=( --ignore "${x}" )
> + done
>   set -- "${EPYTHON}" -m pytest "${args[@]}" "${@}"
>  
>   echo "${@}" >&2

Arthur Zamarin did some grepping and found that there are ebuilds that
are actually broken by this change.  For example, in one ebuild some
mgorny did:

  deselect=( --ignore ... )

I suppose we have two main options right now:

1. Use more unique names for the new variables.  Possibly make them
uppercase and supported without redefining python_test(), e.g.:

  distutils_enable_tests pytest

  EPYTEST_DESELECT=(
tests/some_broken_stuff.py::test_fnord
  )

2. Pre-fix the ebuilds and go as-is.  I kinda dislike this because it
assumes custom repos could get hit by this, and requires us to find all
potentially broken occurences.

-- 
Best regards,
Michał Górny





[gentoo-dev] [PATCH] python-utils-r1.eclass: Handle deselect/ignore in epytest

2021-08-11 Thread Michał Górny
It is a de-facto standard to use deselect=() and/or ignore=() arrays
to pass arguments to epytest.  Let's make the function take them
automatically without requiring unsafe hacks such as:

epytest ${deselect[@]/#/--deselect }

Signed-off-by: Michał Górny 
---
 eclass/python-utils-r1.eclass | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index b104b6694ac3..04b82d4f7a78 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1250,6 +1250,10 @@ build_sphinx() {
 # Run pytest, passing the standard set of pytest options, followed
 # by user-specified options.
 #
+# If 'deselect' array is present in the calling scope, all its elements
+# are added as --deselect arguments to pytest.  If 'ignore' array
+# is present, its elements are added as --ignore arguments.
+#
 # This command dies on failure and respects nonfatal.
 epytest() {
debug-print-function ${FUNCNAME} "${@}"
@@ -1268,6 +1272,13 @@ epytest() {
# for end users, as it tends to fail on new warnings from deps
-Wdefault
)
+   local x
+   for x in "${deselect[@]}"; do
+   args+=( --deselect "${x}" )
+   done
+   for x in "${ignore[@]}"; do
+   args+=( --ignore "${x}" )
+   done
set -- "${EPYTHON}" -m pytest "${args[@]}" "${@}"
 
echo "${@}" >&2
-- 
2.32.0




Re: [gentoo-dev] Packages up for grabs per ikelos's retirement

2021-08-10 Thread Michał Górny
On Tue, 2021-08-10 at 08:57 +0300, Joonas Niilola wrote:
> dev-python/mypy_extensions

python@ will take this one.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Re: [RFC] News Item: OAuth2 Credentials Removed from Chromium

2021-08-08 Thread Michał Górny
On Sun, 2021-08-08 at 14:39 +0200, Jason A. Donenfeld wrote:
> v2 after brief IRC discussion
> ---
> 
> Title: OAuth2 Credentials Removed from Chromium
> Author: Jason A. Donenfeld
> Posted: 2021-08-08
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: www-client/chromium
> 
> In March of this year, Google announced that OAuth2 credentials would be 
> revoked
> for distros shipping Chromium. This was covered in multiple places at the 
> time,
> such as [1,2,3]. Around that time, with 89.0.4389.82, Gentoo removed OAuth2
> credentials from its packages. However, they slipped back in shortly after. As
> a result, some users [4] have found that recently Google's SSO does not 
> persist
> between browser sessions; e.g. you have to log back into GMail every time you
> open your browser. Today's changes [5] restore the old behavior we had in 
> March,
> of not shipping Gentoo OAuth2 credentials. If you find that certain Google
> services are no longer working, you may wish to set these flags, obtaining
> credentials by following the instructions at [6]. However, even without
> supplying such credentials, Google's SSO now should be working as expected.

Please split this into multiple shorter paragraphs.  It's very hard to
follow such a huge wall of text.

> 
> There are now two options for passing these tokens to Chromium via
> /etc/chromium/default:
> 
>   1. GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET environment
>  variables:
>export GOOGLE_DEFAULT_CLIENT_ID=""
>export GOOGLE_DEFAULT_CLIENT_SECRET=""
> 
>   2. --oauth2-client-id and --oauth2-client-secret= command line switches:
>CHROMIUM_FLAGS+=" --oauth2-client-id="
>CHROMIUM_FLAGS+=" --oauth2-client-secret="
> 
> Alternatively these environment variables and command line switches may be 
> given
> at the command line for ad-hoc testing.
> 
> [1] https://archlinux.org/news/chromium-losing-sync-support-in-early-march/
> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5
> [3] 
> https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/
> [4] https://bugs.gentoo.org/791871
> [5] 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fce48ef271bbcaee9afdf0481294da167e665a9b
> [6] http://www.chromium.org/developers/how-tos/api-keys
> 

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation

2021-08-07 Thread Michał Górny
On Thu, 2021-08-05 at 17:57 -0700, Alec Warner wrote:
> On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev  wrote:
> > 
> > Hi,
> > 
> > We've been collecting more and more container related packages in
> >  app-emulation/*
> > 
> > What do you think about finally moving those packages to separate category?
> 
> As always my opinion is that:
> 
> (a) Categories were a design mistake.
> (b) The mistake is hard to fix.
> (c) It's basically low-value to try to 'correctly' categorize packages
> because of A.
> (d) Recategorizing means a bunch of stuff has to be updated.
> 

Categories themselves were not a design mistake.  The design mistake is
using categories to permit conflicting package names.

Categories are convenient.  Sure, they're not perfect but they serve
their purpose to some degree and there's little harm in having them.
If you want to organize packages better, nobody's stopping you.  Until
you've got a better and widespread replacement, I don't see why people
shouldn't be using categories as they see fit.

The other part is something we could aim for fixing but so far most
developers seems to disagree with me, so there's no point in pursuing
that.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Packages up for grabs

2021-08-05 Thread Michał Górny
On Thu, 2021-08-05 at 19:00 -0400, Ionen Wolkens wrote:
> On Wed, Aug 04, 2021 at 10:08:41AM +0100, Sergei Trofimovich wrote:
> > Last batch of packages in search of a dedicated maintainer:
> > 
> > games-emulation/dolphin
> I'll add games@, but it could still use a more dedicated maintainer.
> So if anyone is interested feel free to add yourself as well.
> 

I'll add it to my collection, I've been using it recently.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Python 3.10.0rc1

2021-08-04 Thread Michał Górny
On Wed, 2021-08-04 at 20:27 +0100, Sergei Trofimovich wrote:
> On Tue, 03 Aug 2021 11:15:13 +0200
> Michał Górny  wrote:
> 
> > Hi, everyone.
> > 
> > Just a quick note: I've pushed Python 3.10.0rc1 today.  It has many last
> > minute changes that can break packages that were ported to previous
> > 3.10.0 betas before.
> > 
> > For practical reasons, we're going to support only >=3.10.0_rc1 going
> > forward.  If your package fails with >=3.10.0_rc1, feel free to apply
> > fixes without caring for backwards compatibility with betas.  If you see
> > failures with 3.10.0_beta4, please try upgrading to _rc1 first.
> > 
> > Notably, the newest releases of dev-python/django and dev-python/sphinx
> > that I've pushed today were updated for _rc1 and will have failures with
> > _beta4.
> 
> Should we drop PYTHON_COMPAT=python3_10 for known to break package versions?
> For example latest stable dev-python/sphinx-4.0.3 did not like today's ~arch
> python:

I suppose that's fine if it doesn't break depgraph.  For completeness,
the newer sphinx version is fixed for that.

-- 
Best regards,
Michał Górny





[gentoo-dev] Python 3.10.0rc1

2021-08-03 Thread Michał Górny
Hi, everyone.

Just a quick note: I've pushed Python 3.10.0rc1 today.  It has many last
minute changes that can break packages that were ported to previous
3.10.0 betas before.

For practical reasons, we're going to support only >=3.10.0_rc1 going
forward.  If your package fails with >=3.10.0_rc1, feel free to apply
fixes without caring for backwards compatibility with betas.  If you see
failures with 3.10.0_beta4, please try upgrading to _rc1 first.

Notably, the newest releases of dev-python/django and dev-python/sphinx
that I've pushed today were updated for _rc1 and will have failures with
_beta4.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-02 Thread Michał Górny
On Mon, 2021-08-02 at 01:28 -0700, Georgy Yakovlev wrote:
> it can actually check if ebuild calls tmpfiles_process, not only
> inherit.
> something like:
> 
>     local pkg_postinst_body="$(declare -fp pkg_postinst)"
>     if [[ ! ${pkg_postinst_body} == *tmpfiles_process* ]]; then
>     eqawarn "QA Notice: package is installing tmpfiles without
> calling
>     eqawarn "tmpfiles_process in pkg_postinst phase"
>     fi
>     
> ofc accounting for edge cases floppym mentioned.

This is going to cause false positives if tmpfiles_process is called via
another function.

-- 
Best regards,
Michał Górny





[gentoo-dev] [PATCH] glep-0082: Add profile-eapis-* keys

2021-08-01 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 glep-0082.rst | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/glep-0082.rst b/glep-0082.rst
index 6703313..841265c 100644
--- a/glep-0082.rst
+++ b/glep-0082.rst
@@ -4,10 +4,10 @@ Title: Repository configuration file (layout.conf)
 Author: Michał Górny 
 Type: Standards Track
 Status: Draft
-Version: 1.0
+Version: 1.1
 Created: 2021-05-19
-Last-Modified: 2021-05-31
-Post-History: 2021-05-19
+Last-Modified: 2021-08-01
+Post-History: 2021-05-19, 2021-08-01
 Content-Type: text/x-rst
 ---
 
@@ -159,6 +159,20 @@ eapis-banned = 
   be blocked.  If not specified, no EAPIs are banned.  This key
   does not apply to EAPI use in profiles.
 
+profile-eapis-deprecated = 
+  Specifies one or more EAPIs that are to be considered deprecated
+  by the development tools for use in profiles, i.e. their use
+  in any of the profiles listed in ``profiles/profiles.desc`` or their
+  parent profiles should trigger a warning.  If not specified, no EAPIs
+  are deprecated.
+
+profile-eapis-banned = 
+  Specifies one or more EAPIs that are to be considered banned
+  by the development tools for use in profiles, i.e. their use
+  in any of the profiles listed in ``profiles/profiles.desc`` or their
+  parent profiles should be blocked.  If not specified, no EAPIs
+  are banned.
+
 repo-name = 
   Specifies the repository name.  If specified, it must be equal
   to the contents of ``profiles/repo_name``.  If not specified,
-- 
2.32.0




Re: [gentoo-dev] [PATCH] wxwidgets.eclass: Support EAPI 8

2021-08-01 Thread Michał Górny
On Sun, 2021-08-01 at 16:40 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 01 Aug 2021, Michał Górny wrote:
> 
> > > + 3.0)  [[ ${EAPI} == 7 ]] \
> > > +   || die "GTK 2 no longer supported
> > > in EAPI ${EAPI}" ;;
> 
> > Let's make it:
> 
> >   [[ ${EAPI} != 7 ]] && die ...
> 
> > to keep the logic more straightforward (and consistent with 'if ...;
> > then').
> 
> Generally, I like the " || die" style more,
> because it is more common. It is also more consistent about the return
> status of the whole expression. With the && operator above, it would
> return shell false in case of success.

A user requested the other style in one of my earlier patches,
and I kinda agree that this reverse logic can easily get confusing.

> Of course, there's no functional difference here, but if you have it
> at
> the end of a function or before an explicit return statement it may
> play
> a role.

...only if it's nonfatal-friendly.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] wxwidgets.eclass: Support EAPI 8

2021-08-01 Thread Michał Górny
On Sun, 2021-08-01 at 14:36 +0200, Ulrich Müller wrote:
> Reviewed-by: Mart Raudsepp 
> Reviewed-by: David Seifert 
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/wxwidgets.eclass | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/eclass/wxwidgets.eclass b/eclass/wxwidgets.eclass
> index 4357e7367cc7..28735aaac6fd 100644
> --- a/eclass/wxwidgets.eclass
> +++ b/eclass/wxwidgets.eclass
> @@ -4,7 +4,7 @@
>  # @ECLASS: wxwidgets.eclass
>  # @MAINTAINER:
>  # wxwidg...@gentoo.org
> -# @SUPPORTED_EAPIS: 7
> +# @SUPPORTED_EAPIS: 7 8
>  # @BLURB: Manages build configuration for wxGTK-using packages.
>  # @DESCRIPTION:
>  # This eclass sets up the proper environment for ebuilds using the wxGTK
> @@ -21,10 +21,9 @@
>  # The configuration chosen is based on the version required and the flags
>  # wxGTK was built with.
>  
> -case ${EAPI:-0} in
> - [0-6]) die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" ;;
> - 7) ;;
> - *) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
> +case ${EAPI} in
> + 7|8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>  esac
>  
>  if [[ -z ${_WXWIDGETS_ECLASS} ]]; then
> @@ -37,7 +36,9 @@ _WXWIDGETS_ECLASS=1
>  # The SLOT of the x11-libs/wxGTK you're targeting.  Needs to be defined 
> before
>  # inheriting the eclass.  Can be either "3.0" or "3.0-gtk3".
>  case ${WX_GTK_VER} in
> - 3.0|3.0-gtk3) ;;
> + 3.0-gtk3) ;;
> + 3.0)  [[ ${EAPI} == 7 ]] \
> +   || die "GTK 2 no longer supported in EAPI 
> ${EAPI}" ;;

Let's make it:

  [[ ${EAPI} != 7 ]] && die ...

to keep the logic more straightforward (and consistent with 'if ...;
then').

>   "")   die "WX_GTK_VER not declared" ;;
>   *)die "Invalid WX_GTK_VER: must be set to a valid wxGTK 
> SLOT ('3.0' or '3.0-gtk3')" ;;
>  esac

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-01 Thread Michał Górny
On Sun, 2021-08-01 at 00:56 +0100, Sam James wrote:
> This adds two tmpfiles related QA checks:
> 1) Verify packages don't install tmpfiles to /etc/tmpfiles.d, which
> is a deprecated location;
> 
> 2) Check whether packages inherit tmpfiles.eclass if they're
> installing files to /usr/lib/tmpfiles.d.
> 
> (This helps to catch packages not calling tmpfiles_process
> in pkg_postinst).
> 
> Signed-off-by: Sam James 
> ---
>  metadata/install-qa-check.d/60tmpfiles-paths | 37 
>  1 file changed, 37 insertions(+)
>  create mode 100644 metadata/install-qa-check.d/60tmpfiles-paths
> 
> diff --git a/metadata/install-qa-check.d/60tmpfiles-paths 
> b/metadata/install-qa-check.d/60tmpfiles-paths
> new file mode 100644
> index 0..2c56c031bd1e3
> --- /dev/null
> +++ b/metadata/install-qa-check.d/60tmpfiles-paths
> @@ -0,0 +1,37 @@
> +# Copyright 2021 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# QA check: ensure that packages installing tmpfiles configuration inherit 
> the eclass
> +# Maintainer: Sam James 
> +
> +# Implements two checks:
> +# 1) Installation to /etc/tmpfiles.d (which is a deprecated location);
> +# 2) Installation of any tmpfiles to /usr/lib/tmpfiles.d without inheriting 
> the eclass
> +#(needed for tmpfiles_process in pkg_postinst)
> +tmpfiles_check() {
> + # Check 1
> + # Scan image for files in /etc/tmpfiles.d which is a deprecated location
> + if [[ -d "${ED}"/etc/tmpfiles.d/ ]] ; then

Nit: normally quoting is not necessary inside [[ ... ]].

> + eqawarn "QA Notice: files installed to the deprecated 
> /etc/tmpfiles.d location"
> + eqawarn "tmpfiles configuration files must be installed to 
> /usr/lib/tmpfiles.d!"
> + fi
> +
> + # Check 2
> + # We're now going to check for whether we install files to 
> /usr/lib/tmpfiles.d without
> + # inheriting the eclass (weak catch for ebuilds not calling 
> tmpfiles_process in pkg_postinst)
> +
> + # No need to carry on if we're inheriting the eclass
> + if has tmpfiles ${INHERITED} ; then
> + return
> + fi
> +
> + if [[ -d "${ED}"/usr/lib/tmpfiles.d/ ]] ; then
> + eqawarn "QA Notice: package is installing tmpfiles without 
> inheriting tmpfiles.eclass!"
> + eqawarn "Packages must inherit tmpfiles.eclass then call 
> tmpfiles_process in pkg_postinst."
> + fi
> +}
> +
> +tmpfiles_check
> +: # guarantee successful exit
> +
> +# vim:ft=sh

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Heads up: NATTkA will become more verbose when no action is needed

2021-07-29 Thread Michał Górny
On Thu, 2021-07-29 at 10:57 +0200, Michał Górny wrote:
> Hi, everyone.
> 
> Originally, I've tried to make NATTkA avoid leaving redundant comments
> on bugs where no action was due.  However, this often meant that if you
> did something wrong, NATTkA didn't complain and you ended up being
> confused why it's ignoring the bug.
> 
> Per recurring request, I'm working on making NATTkA more verbose.  This
> means some extra bug spam is to be expected, especially on security bugs
> since they don't get closed after stabilization.

I'm sorry, this was much worse than I have anticipated.  I have reverted
the change for now and will explore other options.

-- 
Best regards,
Michał Górny





[gentoo-dev] Heads up: NATTkA will become more verbose when no action is needed

2021-07-29 Thread Michał Górny
Hi, everyone.

Originally, I've tried to make NATTkA avoid leaving redundant comments
on bugs where no action was due.  However, this often meant that if you
did something wrong, NATTkA didn't complain and you ended up being
confused why it's ignoring the bug.

Per recurring request, I'm working on making NATTkA more verbose.  This
means some extra bug spam is to be expected, especially on security bugs
since they don't get closed after stabilization.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Guarantees of unstable architectures

2021-07-26 Thread Michał Górny
On Mon, 2021-07-26 at 17:23 +0100, Marek Szuba wrote:
> Dear everyone,
> 
> During the open-floor part of this month's Council meeting I asked 
> whether there is any official policy regarding what is or is not 
> guaranteed for hardware architectures we do not consider stable in 
> Gentoo. For reference, according to the current version of 
> profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, 
> dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390,
> and all Prefix arches.

For a start, your list includes architectures that have profiles with
various levels of stability.  Rules for stable/dev profiles are
different than rules for exp profiles, and therefore all architectures
that do not have stable/dev profiles give lower stability guarantees.

As for the remaining architectures, I don't think the rules for
architecture that doesn't have stable keywords should be different than
rules for ~arch packages on an architecture with stable keywords.

> As it turns out, we do not in fact have any such policy. On the other 
> hand, during my time as a Gentoo developer I have heard from other 
> developers a fairly wide range of opinions on the subject - from 
> insisting on clean QA results, passing tests etc. regardless of whether 
> an arch is stable or not to assuming we guarantee nothing for unstable 
> arches.
> 
> Anyway, it has been decided that it makes sense to discuss this on the 
> mailing list before making it a Council matter. Therefore - what do you 
> all think here?

I think the rough rule of thumb should be:

1. For stable keywords, we try really hard not to break anything.  When
doing somewhat risky stuff, we drop keywords to ~arch.  We generally try
to test stuff properly before things go stable.

2. For ~arch keywords, we don't guarantee things won't break but we also
don't break them deliberately.  When doing very risky stuff, we use
masks or drop keywords entirely.  Breakage can still sneak in.

3. For pure exp architectures, we don't guarantee any stability.  We can
drop keywords or break depgraph.

-- 
Best regards,
Michał Górny





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

2021-07-25 Thread Michał Górny
# Michał Górny  (2021-07-25)
# Conflicts with dev-python/pyxdg.  Upstream is unwilling to resolve
# this.  The only revdep has been patched to use pyxdg.
# Removal on 2021-08-24.  Bug #804127.
dev-python/xdg

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests

2021-07-25 Thread Michał Górny
On Sun, 2021-07-25 at 01:12 +0200, Thomas Deutschmann wrote:
> Hi,
> 
> I don't understand. Isn't it the same motion we put down just 2 months 
> ago [1]? Or is this something new?
> 
> If this isn't something new, what has changed since May [2]?

Apparently it has not been 'put down' because it came back via open
bugs.

> To remember: Currently we have two different hashes for every distfile. 
> If we are going to throw this data away, we should really have good 
> reasons to do that. Like said during that council meeting, BLAKE2B and 
> SHA512 are competing hashes. What's wrong with having a backup plan even 
> for a very unlikely scenario, that BLAKE2B will get broken?

Define 'broken'.

> It's not like SHA512 is requiring any additional deps which are 
> unmaintained or something like that. SHA has even hardware acceleration 
> support in modern systems.

...which is entirely irrelevant given that both hashes need to be
calculated.  (SHA512 + BLAKE2B) can be as fast as the slower of two
in the best scenario.

> In addition it is even more likely that you will find SHA checksum files 
> with upstream release tarballs than BLAKE2B files.

Again, I don't see how that's even remotely relevant.

> Remember that verify-sig.eclass I criticized last year? Of course some 
> scenarios I outlined were very unlikely and I never expected that I can 
> run around in near future saying "I told you". But in January 2021, 
> CVE-2021-3345 happened in libgcrypt...

I don't see how this is relevant either.  Are you admitting that you're
criticizing all my ideas because I just happen to propose them?


-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests

2021-07-25 Thread Michał Górny
On Sat, 2021-07-24 at 17:15 -0400, Joshua Kinard wrote:
> On 7/24/2021 11:16, Michał Górny wrote:
> > Hi, everyone.
> > 
> > I've been asked to repost the idea of removing SHA512 hash from
> > Manifests, effectively limiting them to BLAKE2B.
> > 
> > The 'old' set of Gentoo hashes including SHA512 went live in July 2012.
> > In November 2017, we have decided to remove the two other hashes and add
> > BLAKE2B in their stead.  Today, all Gentoo packages are using BLAKE2B
> > and SHA512 hashes.
> > 
> > To all extent, this is purely a cosmetic change.  The benefit from
> > removing the additional hash is negligible, both from space perspective
> > and hashing speed perspective.  The benefit from keeping two hashes is
> > also negligible.
> > 
> > Back during the 2017 discussion, Infra came to the conclusion that we're
> > going to keep SHA512 for a transition period, then remove it, and stay
> > with a single hash algorithm.  In my opinion, we have kept it long
> > enough.
> > 
> > WDYT?
> 
> Are there any security benefits/consequences of keeping two/one?  If no to
> consequences, then I don't see a problem dropping SHA512.

To the best of my knowledge, the consequences are negligible.

> And are we looking at BLAKE3 hash support at all for the future?  I know
> that algo is fairly new (Jan 2020).  A quick read indicates it merges a
> number of the BLAKE2 variants together and is faster in some areas of 
> execution.

Not at the moment.  I see they've eventually made a C implementation, so
maybe it's worth looking into.  OTOH we may want to wait till it's part
of CPython, or at least has C-based Python bindings.

-- 
Best regards,
Michał Górny





  1   2   3   4   5   6   7   8   9   10   >