Re: [gentoo-dev] Mailing list moderation and community openness

[kuzetsa]

On 03/26/2018 09:26 PM, Rich Freeman wrote:
> On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa  wrote:
>> On 03/20/2018 08:08 PM, Rich Freeman wrote:
>>
>>>
>>> Actually, I think it is more of a technical constraint.  It is
>>> basically impossible to blacklist somebody on a mailing list, since
>>> all they need to do is roll up a new email address.
>>>
>>> I can think of various arguments for whitelisting or not whitelisting,
>>> but it seems silly to blacklist.
>>>
>>
>> require active stewardship (moderation, blacklisting, etc.)
>>
>> entry barriers to participation (default deny / require whitelist)
>>
>> if there are limitations on free speech, someone has to bear the burden.
>> for gentoo to have list moderation (blacklist approach) which isn't
>> dysfunctional, the main barrier to resources will be the human resources
>> end of things, not technical constraints. The tools themselves are easy
>> enough to use, but people who are willing and able to use them, and with
>> a clear guideline for how it needs done is a comrel issue which the
>> foundation needs to sort out.
>>
> 
> List moderation isn't the same as blacklisting.  With moderation
> you're effectively whitelisting because the first post anybody makes
> would be held for moderation, and depending on the approach you could
> moderate everything.
> 
> If you allowed new subscribers to post without being held for
> moderation, then the issues I spoke of would still apply, no matter
> how much manpower you threw at it.
> 

I think this may be a misunderstanding? no? there might be some mailing
list jargon term: "moderation" which I was unaware of:

I was more referring to how IRC chatrooms have an op, forums have
moderators which DO NOT screen individual posts, etc. I think I know of
the other version, and it might be analogous to the mechanism you meant?

for example: websites which hold back all comments which are posted
anonymously (non-trusted users) until a moderator can approve it.

I've never used mailing list software which has that feature (I think
that may be what you're referring to) - I mostly meant someone (or a
team) with the specific duty to hold people accountable for their posts
(since the list is public-facing, this should include @gentoo.org devs
too because it sets a weird precedent to have disparate enforcement)

specifically - I was referring to persons (staff) who are moderators.

(active stewardship to check for problems which need addressed)

I think the mechanism you describes sounds like some sort of greylist /
tiered version of default deny or something like that. Interesting.

the "require whitelist / default deny" version of having a closed list
seems the same - expecting users to contact a dev to relay messages, or
go through the dubiously [un]documented process of getting whitelisted.

unless that process has a standardized format, it seems worse than the
greylist because individual developers have the autonomy to [not]
sponsor people for whitelist, or approve posting on a user's behalf. the
lack of transparency for the process is a concern, I mean.

[gentoo-portage-dev] [PATCH] emerge: add --changed-slot [ y | n ] option (bug 631358)

[Zac Medico]

This is similar to --changed-deps, but for SLOT metadata.

Bug: https://bugs.gentoo.org/631358
---
 man/emerge.1  |  7 +++
 pym/_emerge/create_depgraph_params.py |  6 ++
 pym/_emerge/depgraph.py   | 11 +++
 pym/_emerge/main.py   | 13 +
 .../resolver/test_slot_change_without_revbump.py  | 19 +++
 5 files changed, 56 insertions(+)

diff --git a/man/emerge.1 b/man/emerge.1
index 27a1193fe..a3c8dd7cd 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -471,6 +471,13 @@ changed since the installed instance was built. Behavior 
with respect to
 changed build\-time dependencies is controlled by the
 \fB\-\-with\-bdeps\fR option.
 .TP
+.BR "\-\-changed\-slot [ y | n ]"
+Tells emerge to replace installed packages for which the corresponding
+ebuild SLOT metadata has changed since the packages were built. This
+option also implies the \fB\-\-selective\fR option. This may also result
+in rebuilds for any installed packages that have slot/sub\-slot :=
+operator dependencies that are sensitive to the relevant SLOT metadata.
+.TP
 .BR \-\-changed\-use ", " \-U
 Tells emerge to include installed packages where USE flags have
 changed since installation. This option also implies the
diff --git a/pym/_emerge/create_depgraph_params.py 
b/pym/_emerge/create_depgraph_params.py
index ff18f3acc..1fd1f5e36 100644
--- a/pym/_emerge/create_depgraph_params.py
+++ b/pym/_emerge/create_depgraph_params.py
@@ -30,6 +30,7 @@ def create_depgraph_params(myopts, myaction):
# with_test_deps: pull in test deps for packages matched by arguments
# changed_deps: rebuild installed packages with outdated deps
# changed_deps_report: report installed packages with outdated deps
+   # changed_slot: rebuild installed packages with outdated SLOT metadata
# binpkg_changed_deps: reject binary packages with outdated deps
myparams = {"recurse" : True}
 
@@ -64,12 +65,17 @@ def create_depgraph_params(myopts, myaction):
if rebuild_if_new_slot is not None:
myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
 
+   changed_slot = myopts.get('--changed-slot') is True
+   if changed_slot:
+   myparams["changed_slot"] = True
+
if "--update" in myopts or \
"--newrepo" in myopts or \
"--newuse" in myopts or \
"--reinstall" in myopts or \
"--noreplace" in myopts or \
myopts.get("--changed-deps", "n") != "n" or \
+   changed_slot or \
myopts.get("--selective", "n") != "n":
myparams["selective"] = True
 
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index f7ea27c37..dcf3938d8 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -2660,6 +2660,10 @@ class depgraph(object):
 
return changed
 
+   def _changed_slot(self, pkg):
+   ebuild = self._equiv_ebuild(pkg)
+   return ebuild is not None and (ebuild.slot, ebuild.sub_slot) != 
(pkg.slot, pkg.sub_slot)
+
def _create_graph(self, allow_unsatisfied=False):
dep_stack = self._dynamic_config._dep_stack
dep_disjunctive_stack = 
self._dynamic_config._dep_disjunctive_stack
@@ -6464,6 +6468,13 @@ class depgraph(object):

modified_use=self._pkg_use_enabled(pkg))):
if myeb and "--newrepo" in 
self._frozen_config.myopts and myeb.repo != pkg.repo:
break
+   elif 
self._dynamic_config.myparams.get("changed_slot") and self._changed_slot(pkg):
+   if installed:
+   break
+   else:
+   # Continue 
searching for a binary package
+   # with the 
desired SLOT metadata.
+   continue
elif reinstall_use or (not 
installed and respect_use):
iuses = pkg.iuse.all
old_use = 
self._pkg_use_enabled(pkg)
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index 147472cbd..4aa9585fa 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -136,6 +136,7 @@ def insert_optional_args(args):
'--binpkg-changed-deps'  : y_or_n,
'--buildpkg' : y_or_n,
'--changed-deps' : y_or_n,
+   

Re: [gentoo-dev] Mailing list moderation and community openness

[Rich Freeman]

On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa  wrote:
> On 03/20/2018 08:08 PM, Rich Freeman wrote:
>
>>
>> Actually, I think it is more of a technical constraint.  It is
>> basically impossible to blacklist somebody on a mailing list, since
>> all they need to do is roll up a new email address.
>>
>> I can think of various arguments for whitelisting or not whitelisting,
>> but it seems silly to blacklist.
>>
>
> require active stewardship (moderation, blacklisting, etc.)
>
> entry barriers to participation (default deny / require whitelist)
>
> if there are limitations on free speech, someone has to bear the burden.
> for gentoo to have list moderation (blacklist approach) which isn't
> dysfunctional, the main barrier to resources will be the human resources
> end of things, not technical constraints. The tools themselves are easy
> enough to use, but people who are willing and able to use them, and with
> a clear guideline for how it needs done is a comrel issue which the
> foundation needs to sort out.
>

List moderation isn't the same as blacklisting.  With moderation
you're effectively whitelisting because the first post anybody makes
would be held for moderation, and depending on the approach you could
moderate everything.

If you allowed new subscribers to post without being held for
moderation, then the issues I spoke of would still apply, no matter
how much manpower you threw at it.

-- 
Rich

Re: [gentoo-dev] Mailing list moderation and community openness

[kuzetsa]

On 03/20/2018 08:08 PM, Rich Freeman wrote:
> On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu  wrote:
>> William Hubbs  writes:
>>
>>> I do feel that this decision reflects badly on us as a community and
>>> should be reversed immediately. The proper way to deal with people who
>>> have bad behavior is to deal with them individually and not put a
>>> restriction on the community that is not necessary.
>>
>> I agree with William.  Dealing with individuals makes more sense.
>>
>> It boils down to an attitude of assuming outsiders are good (blacklist
>> to ML) or bad (whitelist to ML) by default.
> 
> Actually, I think it is more of a technical constraint.  It is
> basically impossible to blacklist somebody on a mailing list, since
> all they need to do is roll up a new email address.
> 
> I can think of various arguments for whitelisting or not whitelisting,
> but it seems silly to blacklist.
> 

require active stewardship (moderation, blacklisting, etc.)

entry barriers to participation (default deny / require whitelist)

if there are limitations on free speech, someone has to bear the burden.
for gentoo to have list moderation (blacklist approach) which isn't
dysfunctional, the main barrier to resources will be the human resources
end of things, not technical constraints. The tools themselves are easy
enough to use, but people who are willing and able to use them, and with
a clear guideline for how it needs done is a comrel issue which the
foundation needs to sort out.

Re: [gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

[Marty E. Plummer]

On Mon, Mar 26, 2018 at 11:58:00PM +0200, Michał Górny wrote:
> W dniu pon, 26.03.2018 o godzinie 16∶33 -0500, użytkownik Marty E.
> Plummer napisał:
> > As a pretty simple eclass, which only inherited multilib in
> > order to get $(get_libdir) and eutils for who knows why, and
> > all its consumers bumped to EAPI=6, it makes sense to require
> > EAPI 6 for this eclass
> > 
> 
> It's trivial, used by 6 ebuilds... why do we even have this eclass?
> 
> If I wrote mgorny.eclass it would have more consumers ;-P.
>
Possibly, but it does allow for pretty quick additions of freedict
packages, but since everything that uses it is EAPI 6 now it makes
sense to go ahead and ban lesser EAPIs in order to prevent their
reintroduction in that category. Honestly if you could set EAPI in
an eclass I'd set it there, then every ebuild using it would be at
EAPI 6 to begin with :)

Re: [gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

[Michał Górny]

W dniu pon, 26.03.2018 o godzinie 16∶33 -0500, użytkownik Marty E.
Plummer napisał:
> As a pretty simple eclass, which only inherited multilib in
> order to get $(get_libdir) and eutils for who knows why, and
> all its consumers bumped to EAPI=6, it makes sense to require
> EAPI 6 for this eclass
> 

It's trivial, used by 6 ebuilds... why do we even have this eclass?

If I wrote mgorny.eclass it would have more consumers ;-P.

-- 
Best regards,
Michał Górny

[gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

[Marty E. Plummer]

As a pretty simple eclass, which only inherited multilib in
order to get $(get_libdir) and eutils for who knows why, and
all its consumers bumped to EAPI=6, it makes sense to require
EAPI 6 for this eclass

Package-Manager: Portage-2.3.24, Repoman-2.3.6
---
 eclass/freedict.eclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/eclass/freedict.eclass b/eclass/freedict.eclass
index 06419626d34..f2518f3cdcd 100644
--- a/eclass/freedict.eclass
+++ b/eclass/freedict.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: freedict.eclass
@@ -21,7 +21,10 @@
 # @DESCRIPTION:
 # Please see above for a description.
 
-inherit eutils multilib
+case ${EAPI:-0} in
+   6) ;;
+   *) die "${ECLASS}.eclass is banned in EAPI=${EAPI}" ;;
+esac
 
 IUSE=""
 
-- 
2.16.2

[gentoo-portage-dev] [PATCH] Disallow package.provided in EAPI 7

[Zac Medico]

This is also implemented in portage-mgorny by the following commit:

https://github.com/mgorny/portage/commit/386cdb131c99b01541d53c8c894b2ec6534b6dea

Bug: https://bugs.gentoo.org/568884
---
 pym/portage/eapi.py  | 5 +
 pym/portage/package/ebuild/config.py | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py
index 5f0017b65..49c0e0ecd 100644
--- a/pym/portage/eapi.py
+++ b/pym/portage/eapi.py
@@ -104,6 +104,10 @@ def eapi_has_automatic_unpack_dependencies(eapi):
 def eapi_has_hdepend(eapi):
return eapi in ("5-hdepend",)
 
+def eapi_allows_package_provided(eapi):
+   return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi",
+   "5", "5-progress", "6")
+
 def eapi_has_bdepend(eapi):
return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi",
"5", "5-progress", "6")
@@ -148,6 +152,7 @@ def _get_eapi_attrs(eapi):
eapi = None
 
eapi_attrs = _eapi_attrs(
+   allows_package_provided=(eapi is None or 
eapi_allows_package_provided(eapi)),
bdepend = (eapi is not None and eapi_has_bdepend(eapi)),
dots_in_PN = (eapi is None or eapi_allows_dots_in_PN(eapi)),
dots_in_use_flags = (eapi is None or 
eapi_allows_dots_in_use_flags(eapi)),
diff --git a/pym/portage/package/ebuild/config.py 
b/pym/portage/package/ebuild/config.py
index 9d2b34a53..ea49839d8 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -803,7 +803,8 @@ class config(object):
pkgprovidedlines = [grabfile(
os.path.join(x.location, "package.provided"),
recursive=x.portage1_directories)
-   for x in profiles_complex]
+   for x in profiles_complex if 
_get_eapi_attrs(x.eapi).allows_package_provided]
+
pkgprovidedlines = stack_lists(pkgprovidedlines, 
incremental=1)
has_invalid_data = False
for x in range(len(pkgprovidedlines)-1, -1, -1):
-- 
2.13.6

[gentoo-portage-dev] Re: [PATCH 0/7] Add dostrip for EAPI 7

[Zac Medico]

On 03/25/2018 01:28 PM, Zac Medico wrote:
> The series contains dostrip patches cherry picked from portage-mgorny:
> 
> commit 38273616460fef9b36d3862f366f49f8ba5e7911
> Author: Michał Górny 
> Date:   2018-03-25 14:37:44 +0200
> 
> Add dostrip for EAPI 7
> 
> Bug: https://bugs.gentoo.org/203891
> Closes: https://github.com/mgorny/portage/issues/8
> 
> commit ddb250cf5291a83cd5d44910428f666445147448
> Author: Michał Górny 
> Date:   2018-03-25 14:32:40 +0200
> 
> Allow individually allowing strip w/ RESTRICT=strip
> 
> Update RESTRICT=strip to control the default strip inclusion list
> as specified in EAPI 7 rather than disabling stripping entirely.
> This makes it possible to strip individual files.
> 
> commit ef5f2d3574d4f73d6e5fce7e3e798e2a05cc1893
> Author: Michał Górny 
> Date:   2018-03-25 14:31:36 +0200
> 
> estrip: Report pre-stripped files even with RESTRICT=strip
> 
> The purpose of RESTRICT=strip is to prevent files from being stripped,
> not to silence QA checks about pre-stripped files.
> 
> commit 46f0f9cf8d02ab498ab7b4fec4419e507433839b
> Author: Michał Górny 
> Date:   2018-03-25 14:11:20 +0200
> 
> Introduce control variables for estrip
> 
> commit 5ccafc3662ada431e5c75ec35aeb06cc86ee53ba
> Author: Michał Górny 
> Date:   2018-03-25 14:05:19 +0200
> 
> estrip: Use queue/dequeue logic
> 
> commit ee10e26763051396eea077a640c47796674403cc
> Author: Michał Górny 
> Date:   2018-03-25 13:16:24 +0200
> 
> Disarm prepstrip & prepallstrip
> 
> Move stripping logic to a new estrip helper (that is not exposed
> to ebuilds) and make prepstrip & prepallstrip do nothing.
> 
> 
> commit ae52aceeb86253a8b5742b287229614340017e55
> Author: Michał Górny 
> Date:   2018-03-24 14:03:02 +0100
> 
> prepstrip: Disable parallel work
> 
> 
> Michał Górny (7):
>   prepstrip: Disable parallel work
>   Disarm prepstrip & prepallstrip
>   estrip: Use queue/dequeue logic
>   Introduce control variables for estrip
>   estrip: Report pre-stripped files even with RESTRICT=strip
>   Allow individually allowing strip w/ RESTRICT=strip
>   Add dostrip for EAPI 7
> 
>  bin/eapi.sh |   4 +
>  bin/ebuild-helpers/prepallstrip |  11 +-
>  bin/ebuild-helpers/prepstrip| 401 +---
>  bin/ebuild.sh   |   2 +-
>  bin/estrip  | 438 
> 
>  bin/misc-functions.sh   |   6 +-
>  bin/phase-helpers.sh|  29 +++
>  bin/save-ebuild-env.sh  |   4 +-
>  8 files changed, 486 insertions(+), 409 deletions(-)
>  create mode 100755 bin/estrip
> 

I've now separated the essential parts into a single patch:

https://archives.gentoo.org/gentoo-portage-dev/message/59a58e7c2ea1267a53ef87f34c26f63f
https://github.com/gentoo/portage/pull/281
-- 
Thanks,
Zac

[gentoo-portage-dev] [PATCH] Add dostrip for EAPI 7

[Zac Medico]

This patch includes the essential parts of the dostrip implementation
from portage-mgorny. It also bans the non-standard prepstrip and
prepallstrip helpers in EAPI 7, with a die message suggesting to
use 'dostrip' instead. All of the prepstrip code has moved to
bin/estrip, without any changes except the addition of argument
parsing for estrip --ignore, --queue, and --deque modes which are
equivalent to the corresponding ecompressdir modes.

Bug: https://bugs.gentoo.org/203891
---
 bin/eapi.sh |   4 +
 bin/ebuild-helpers/prepall  |   2 +-
 bin/ebuild-helpers/prepallstrip |   4 +
 bin/ebuild-helpers/prepstrip| 400 +--
 bin/ebuild.sh   |   2 +-
 bin/estrip  | 458 
 bin/misc-functions.sh   |   6 +
 bin/phase-helpers.sh|  29 +++
 bin/save-ebuild-env.sh  |   4 +-
 9 files changed, 509 insertions(+), 400 deletions(-)
 create mode 100755 bin/estrip

diff --git a/bin/eapi.sh b/bin/eapi.sh
index 326eb387e..f9a4744e9 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -76,6 +76,10 @@ ___eapi_has_docompress() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3)$ ]]
 }
 
+___eapi_has_dostrip() {
+   [[ ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress|6)$ ]]
+}
+
 ___eapi_has_nonfatal() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3)$ ]]
 }
diff --git a/bin/ebuild-helpers/prepall b/bin/ebuild-helpers/prepall
index 44643bb58..bc77af4a1 100755
--- a/bin/ebuild-helpers/prepall
+++ b/bin/ebuild-helpers/prepall
@@ -19,7 +19,7 @@ fi
 prepallman
 prepallinfo
 
-prepallstrip
+___eapi_has_dostrip || prepallstrip
 
 if has chflags $FEATURES ; then
# Restore all the file flags that were saved at the beginning of 
prepall.
diff --git a/bin/ebuild-helpers/prepallstrip b/bin/ebuild-helpers/prepallstrip
index 59fa7cc61..4bde1f4b2 100755
--- a/bin/ebuild-helpers/prepallstrip
+++ b/bin/ebuild-helpers/prepallstrip
@@ -4,6 +4,10 @@
 
 source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
 
+if ___eapi_has_dostrip; then
+   die "${0##*/}: ${0##*/} has been banned for EAPI '$EAPI'; use 'dostrip' 
instead"
+fi
+
 if ! ___eapi_has_prefix_variables; then
ED=${D}
 fi
diff --git a/bin/ebuild-helpers/prepstrip b/bin/ebuild-helpers/prepstrip
index 2136e0d4d..9db06284d 100755
--- a/bin/ebuild-helpers/prepstrip
+++ b/bin/ebuild-helpers/prepstrip
@@ -2,402 +2,10 @@
 # Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
-source "${PORTAGE_BIN_PATH}"/helper-functions.sh || exit 1
+source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
 
-# avoid multiple calls to `has`.  this creates things like:
-#   FEATURES_foo=false
-# if "foo" is not in $FEATURES
-tf() { "$@" && echo true || echo false ; }
-exp_tf() {
-   local flag var=$1
-   shift
-   for flag in "$@" ; do
-   eval ${var}_${flag}=$(tf has ${flag} ${!var})
-   done
-}
-exp_tf FEATURES compressdebug installsources nostrip splitdebug xattr
-exp_tf RESTRICT binchecks installsources splitdebug strip
-
-if ! ___eapi_has_prefix_variables; then
-   EPREFIX= ED=${D}
-fi
-
-banner=false
-SKIP_STRIP=false
-if ${RESTRICT_strip} || ${FEATURES_nostrip} ; then
-   SKIP_STRIP=true
-   banner=true
-   ${FEATURES_installsources} || exit 0
-fi
-
-PRESERVE_XATTR=false
-if [[ ${KERNEL} == linux ]] && ${FEATURES_xattr} ; then
-   PRESERVE_XATTR=true
-   if type -P getfattr >/dev/null && type -P setfattr >/dev/null ; then
-   dump_xattrs() {
-   getfattr -d -m - --absolute-names "$1"
-   }
-   restore_xattrs() {
-   setfattr --restore=-
-   }
-   else
-   dump_xattrs() {
-   PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
-   "${PORTAGE_PYTHON:-/usr/bin/python}" \
-   "${PORTAGE_BIN_PATH}/xattr-helper.py" --dump < <(echo 
-n "$1")
-   }
-   restore_xattrs() {
-   PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
-   "${PORTAGE_PYTHON:-/usr/bin/python}" \
-   "${PORTAGE_BIN_PATH}/xattr-helper.py" --restore
-   }
-   fi
-fi
-
-# look up the tools we might be using
-for t in STRIP:strip OBJCOPY:objcopy READELF:readelf ; do
-   v=${t%:*} # STRIP
-   t=${t#*:} # strip
-   eval ${v}=\"${!v:-${CHOST}-${t}}\"
-   type -P -- ${!v} >/dev/null || eval ${v}=${t}
-done
-
-# Figure out what tool set we're using to strip stuff
-unset SAFE_STRIP_FLAGS DEF_STRIP_FLAGS SPLIT_STRIP_FLAGS
-case $(${STRIP} --version 2>/dev/null) in
-*elfutils*) # dev-libs/elfutils
-   # elfutils default behavior is always safe, so don't need to specify
-   # any flags at all
-   SAFE_STRIP_FLAGS=""
-   DEF_STRIP_FLAGS="--remove-comment"
-

Re: [gentoo-dev] Lastrites: net-dns/hesiod, games-arcade/monkey-bubble, app-shells/scsh-install-lib, dev-db/mysql-udf-infusion...

[Alec Warner]

On Sun, Mar 18, 2018 at 9:39 AM, Alec Warner  wrote:

>
>
> On Sun, Mar 18, 2018 at 8:49 AM, Pacho Ramos  wrote:
>
>> # Pacho Ramos  (18 Mar 2018)
>> # Unresolved security issues (#606652), tests fail (#628622, #337249).
>> # Removal in a month.
>> net-dns/hesiod
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Depends on gstreamer:0.10 and many more dead libs (#629174), upstream
>> dead
>> # for ages (#634490). Removal in a month.
>> games-arcade/monkey-bubble
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Fails to build (#629622, #614576, #627408). Removal in a month.
>> app-shells/scsh-install-lib
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Upstream dead, not compatible with MariaDB (#629902). Removal in a
>> month.
>> dev-db/mysql-udf-infusion
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Doesn't build (#630252). Removal in a month.
>> dev-python/visual
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Version bump pending for a long time, depends in QT4 (#630476). Removal
>> in
>> # a month.
>> x11-misc/treeline
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Security vulnerable (#630954, #635548). Removal in a month.
>> media-sound/mp3gain
>> media-sound/aacgain
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Security vulnerable (#631602). Removal in a month.
>> net-proxy/httpush
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Security vulnerable (#631720), dead since 2008, uses doman with
>> compressed
>> # man pages (#619952). Removal in a month.
>> mail-filter/p3scan
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Doesn't build (#634116), use games-action/dxx-rebirth instead. Removal
>> in
>> # a month.
>> games-action/d2x-rebirth
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Fails at runtime (#634258). Removal in a month.
>> net-irc/savirc
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Fails to build (#634662), version bump long time pending (#596162).
>> # Removal in a month.
>> games-emulation/sdlmame
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Multiple vulnerabilities (#635598). Removal in a month.
>> www-apps/b2evolution
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Superseeded by adwaita-icon-theme for years, also having both installed
>> at
>> # the same time causes some apps to use old icons over new ones (#638142).
>> # Removal in a month.
>> x11-themes/gnome-icon-theme
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Completely dead and unmaintained for years, multiple alternatives in the
>> # tree (#638812). Removal in a month.
>> media-gfx/pornview
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Not installable (#639130), version bump long time pending (#489156),
>> # restricts userpriv (#516578). Removal in a month.
>> mail-filter/qmail-scanner
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Fail to fetch (#640544, #640596, #640602). Removal in a month.
>> media-video/vcdgear
>> net-misc/yangcli-pro
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Outdated and useless (#642158). Removal in a month.
>> app-i18n/man-pages-ro
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Forces the usage of obsolete dev-python/mysql-python (#643502). Dead
>> since
>> # 2013. Removal in a month.
>> app-backup/holland-lib-mysql
>> app-backup/holland-backup-mysqldump
>> app-backup/holland-backup-mysql-meta
>> app-backup/holland-backup-mysql-lvm
>> app-backup/holland-backup-mysqlhotcopy
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Forces downgrade of mock (#643506). Removal in a month.
>> dev-python/django-social-auth
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Requires old dev-python/oauth2client (#643534), tests fail (#527608).
>> # Removal in a month.
>> net-misc/gsutil
>>
>
> I'll poke upstream about bug 643543; either a new oauth2client should be
> out or they will just tell us to use pip, in which case I'm good w/that.
>
>
Poked them today, this is on the roadmap but its not likely to be fixed
soon (other stuff is higher priority) so lets drop it.

-A


> -A
>
>
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Requires old psycopg (#643614). Removal in a month.
>> dev-python/adodb-py
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Requires old whoosh (#643690). Removal in a month.
>> dev-python/flask-whooshalchemy
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Requires old redis-py and gevent (#643692). Removal in a month.
>> dev-python/pyzor
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Requires old leveldb, live ebuild, dead since 2013 (#644310). Removal
>> in a
>> # month.
>> net-p2p/datacoin-hp
>>
>> # Pacho Ramos  (18 Mar 2018)
>> # Dead since 2011, relies on dead libraries (#644322, #644326, #644330,
>> #644332
>> # #644340, #647600, #647608, #647698, #647700, 

Re: [gentoo-dev] How to provide a recent TeXLive for Gentoo for our users?

[Alexis Ballier]

On Mon, 26 Mar 2018 20:07:07 +0200
Jonas Stein  wrote:

> > [...]  
> >> This is not a very nice solution, but it works so far. One
> >> difficulty is, that there is no 1:1 relation between the texlive
> >> distribution and dev-texlive/* at the moment.  
> > There is a 1:1 relation.  
> 
> A full installation of TeXLive installs packages, which are in
> dev-tex/* and dev-texlive/* on gentoo.
> On the other hand single packages are bundled some times.
> Some programs/packages can be found in dev-tex/* and dev-texlive/*
> 
> I remember, that I last we had for example dev-tex/notoccite in the
> tree and dev-texlive/texlive-latexextra including shipped the same,
> but newer files.
> This is what I meant with "no 1:1 relation"

The idea with dev-tex/* packages is that they can be split out of
texlive and installed/updated independently as long as they are
actively maintained. While you might have a need for specific updates
on some packages, I seriously doubt you need (and can find the manpower
to maintain) a live ebuild for the whole CTAN and can live with yearly
texlive updates.

The notoccite example is what happens over the years: package is left
unmaintained, texlive catches up and the package becomes useless.
Worse: if done properly it will overlay the more recent version from
texlive! Those packages should be reported and removed (or updated).


> >> How can we enable our users to run a recent TeXLive in a clean
> >> way?  
> > /usr/local/share/texmf has been supported by texlive on Gentoo from
> > day one. You can use that. It's an overlay that takes precedence on
> > anything else, so per the above, you lose all the QA & testing done
> > behind the scenes if you use this.  
> 
> And packages which depend on a specific LaTeX package will not
> install. So the user has to provide a package.provided list, which is
> not so nice to maintain for so many packages.

They will install, only they will pull older unused files from
texlive. As said above, the proper way to avoid this is to step up as
maintainer of some dev-tex/* packages, fix the deps to add a || or
(probably after convincing me it's worth it because the package is
updated very frequently) remove it entirely from texlive and switch the
deps.


Alexis.

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Zac Medico]

On 03/26/2018 09:48 AM, Thomas Deutschmann wrote:
> On 2018-03-23 18:44, Patrick McLean wrote:
>> At my (and zmedico's) employer we use Gentoo heavily (all of our servers
>> run it), and have a few large internal overlays and hundreds of internal
>> profiles. There are packages in upstream Gentoo that we maintain an
>> internal fork of, and it would be extremely useful if we could mask the
>> ::gentoo version of something so a version bump does not cause it to be
>> installed instead of our forked version.
> 
> I have the same need, but it works for me: I have several packages in
> /etc/portage/package.mask directory with content like
> 
>   /::gentoo
> 
> to make sure the package from Gentoo repository isn't used.
> 
> But I guess you are talking about a different thing?

The issue is that people are using profiles hosted in repositories other
than gentoo, complete with profiles.desc entries (eselect profile
supports this), and they would like to have the ability to use ::repo
atoms in these profiles.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] How to provide a recent TeXLive for Gentoo for our users?

[Jonas Stein]

Hi Alexis,

> The real reason is that we need to go through ~arch testing, fixing rev
> deps that might need update to their .tex files because the underlying
> packages they use has changed, adapt the deps for some potential
> changes, and then a stablereq round. 

I agree. This makes the situation not easier.

> [...]
>> This is not a very nice solution, but it works so far. One difficulty
>> is, that there is no 1:1 relation between the texlive distribution and
>> dev-texlive/* at the moment.
> There is a 1:1 relation.

A full installation of TeXLive installs packages, which are in
dev-tex/* and dev-texlive/* on gentoo.
On the other hand single packages are bundled some times.
Some programs/packages can be found in dev-tex/* and dev-texlive/*

I remember, that I last we had for example dev-tex/notoccite in the tree
and dev-texlive/texlive-latexextra including shipped the same, but newer
files.
This is what I meant with "no 1:1 relation"

>> How can we enable our users to run a recent TeXLive in a clean way?
> /usr/local/share/texmf has been supported by texlive on Gentoo from day
> one. You can use that. It's an overlay that takes precedence on
> anything else, so per the above, you lose all the QA & testing done
> behind the scenes if you use this.

And packages which depend on a specific LaTeX package will not install.
So the user has to provide a package.provided list, which is not so nice
to maintain for so many packages.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New category: app-metrics

[Thomas Deutschmann]

On 2018-03-22 09:57, Dirkjan Ochtman wrote:
> On the face of it, I wouldn't drop the "prometheus-" prefix if
> app-metrics is to be the home to other tools. Otherwise, other tools
> like graphite or collectd might want very similar names for the same
> tools out  there.

I second this. Please keep "prometheus-" prefix.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Thomas Deutschmann]

On 2018-03-23 18:44, Patrick McLean wrote:
> At my (and zmedico's) employer we use Gentoo heavily (all of our servers
> run it), and have a few large internal overlays and hundreds of internal
> profiles. There are packages in upstream Gentoo that we maintain an
> internal fork of, and it would be extremely useful if we could mask the
> ::gentoo version of something so a version bump does not cause it to be
> installed instead of our forked version.

I have the same need, but it works for me: I have several packages in
/etc/portage/package.mask directory with content like

  /::gentoo

to make sure the package from Gentoo repository isn't used.

But I guess you are talking about a different thing?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proper dependencies for TeX related ebuilds

[Alexis Ballier]

On Mon, 26 Mar 2018 11:40:12 +0200
Jonas Stein  wrote:

> Hi,
> 
> I just read
> https://bugs.gentoo.org/625908#c5
> and saw that we do not have a good documentation on this and  many
> packages in the tree ship with strange tex dependencies.
> 
> I started a documentation on our wiki
> https://wiki.gentoo.org/wiki/Notes_on_TeX_related_ebuilds

Well, your example (inkscape) is wrong: dep on tl-core is *never*
sufficient and certainly does not provide a working latex command. First
step to get it right is to use the already existing virtuals
(virtual/{la,}tex-base).

Re: [gentoo-dev] How to provide a recent TeXLive for Gentoo for our users?

[Alexis Ballier]

On Mon, 26 Mar 2018 11:57:49 +0200
Jonas Stein  wrote:
> An installation via tlmgr provides many updates per day, but
> our distributed TeXLive is unfortunately always behind.
> Typically TeXLive on gentoo is 6-12 months behind upstream, because we
> have to bump a lot manually.

That is not the real reason. Most of it has been scripted for 10+ years.
The real reason is that we need to go through ~arch testing, fixing rev
deps that might need update to their .tex files because the underlying
packages they use has changed, adapt the deps for some potential
changes, and then a stablereq round. Following the yearly release cycle
leaves time for it to happen. It could move faster, but I don't see any
need for it as this would mean shortening stabilization cycles
potentially allowing for more bugs to enter stable and increasing the
load on arch teams.


[...]
> This is not a very nice solution, but it works so far. One difficulty
> is, that there is no 1:1 relation between the texlive distribution and
> dev-texlive/* at the moment.

There is a 1:1 relation.


> How can we enable our users to run a recent TeXLive in a clean way?

/usr/local/share/texmf has been supported by texlive on Gentoo from day
one. You can use that. It's an overlay that takes precedence on
anything else, so per the above, you lose all the QA & testing done
behind the scenes if you use this.


Alexis.

Re: [gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag

[Gilles Dartiguelongue]

Le lundi 26 mars 2018 à 13:55 +0200, Michał Górny a écrit :
> Dnia 26 marca 2018 10:47:04 CEST, Gilles Dartiguelongue  rg> napisał(a):
> > Le lundi 26 février 2018 à 23:24 +0100, Michał Górny a écrit :
> > > 'luajit' is used consistently in 25+ packages. Make it a global
> > > flag.
> > 
> > Not that I have a strong opinion about it, but wouldn't it be
> > better to
> > have USE="lua jit" like libpeas does ? Use flags aren't supposed to
> > match library names but features so this would seem more correct.
> 
> LuaJIT is a completely separate implementation of Lua, not a feature.
> And it's certainly not a feature of libpeas.

My bad, I had memories that recent (masked) lua had jit USE flag but it
seems I'm mistaken. Feel free to push these changes then.

-- 
Gilles Dartiguelongue 

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

Re: [gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag

[Michał Górny]

Dnia 26 marca 2018 10:47:04 CEST, Gilles Dartiguelongue  
napisał(a):
>Le lundi 26 février 2018 à 23:24 +0100, Michał Górny a écrit :
>> 'luajit' is used consistently in 25+ packages. Make it a global flag.
>
>Not that I have a strong opinion about it, but wouldn't it be better to
>have USE="lua jit" like libpeas does ? Use flags aren't supposed to
>match library names but features so this would seem more correct.

LuaJIT is a completely separate implementation of Lua, not a feature. And it's 
certainly not a feature of libpeas.


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

[gentoo-dev] How to provide a recent TeXLive for Gentoo for our users?

[Jonas Stein]

Dear all,

there was a question on the tex@gentoo ml from a user, who needs a very
recent TeXLive in order to be compatible with other setups.
This is also very important, for users of the more recent programs like
lualatex. Many packages do not work properly in the unfixed old version.

An installation via tlmgr provides many updates per day, but
our distributed TeXLive is unfortunately always behind.
Typically TeXLive on gentoo is 6-12 months behind upstream, because we
have to bump a lot manually.

One solution would be more powerful scripts, which update the TeX
ebuilds, but the ticket is open since 2005.
https://bugs.gentoo.org/85411

On one Gentoo system I installed therefor TeXLive via tlmgr and added
all provided packages in package.provided like this:

/etc/portage/profile/package.provided/texlive.provided
[..]
dev-tex/xcolor-
dev-tex/latexdiff-
dev-tex/glossaries-
dev-tex/biblatex-
dev-tex/biber-
dev-tex/bibtexu-
app-text/texlive-core-

This is not a very nice solution, but it works so far. One difficulty
is, that there is no 1:1 relation between the texlive distribution and
dev-texlive/* at the moment.

How can we enable our users to run a recent TeXLive in a clean way?

Ideas are welcome.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Proper dependencies for TeX related ebuilds

[Jonas Stein]

Hi,

I just read
https://bugs.gentoo.org/625908#c5
and saw that we do not have a good documentation on this and  many
packages in the tree ship with strange tex dependencies.

I started a documentation on our wiki
https://wiki.gentoo.org/wiki/Notes_on_TeX_related_ebuilds

Please help to complete it.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Repoman to warn about suspicious =-dependencies

[Dirkjan Ochtman]

On Sun, Mar 4, 2018 at 12:37 PM, Michał Górny  wrote:

> I think this cause the trouble of specifying '-r0' rather rarely, and it
> will decrease the number of mistakes, also effectively making Gentoo
> development easier. It is somewhat inspired by the handling of slot
> operators (where repoman explicitly asks you to use ':*' instead
> of no operator when the latter would be ambiguous).
>
> What do you think?
>

Sounds good!

Regards,

Dirkjan

Re: [gentoo-dev] RFC: Repoman to warn about suspicious =-dependencies

[Gilles Dartiguelongue]

Le dimanche 04 mars 2018 à 12:37 +0100, Michał Górny a écrit :
> Hi, everyone.
> 
> I have proposed a new check for repoman [1] (with a patch at [2])
> that
> would warn developers about suspicious '=' deps.
> 
> By suspicious, I mean dependencies '=foo-1.2.3' which are sometimes
> mistakenly used instead of '~foo-1.2.3', and cause some degree of
> mayhem
> when someone revbumps the package (either by preventing people from
> upgrading or causing depgraph breakage).
> 
> The check would trigger whenever '='-class dependency is used without
> a revision specified and without the '*' suffix. It would suggest to
> either use '~' operator when any revision is acceptable, or
> explicitly
> specify '-r0' (which is equivalent to no revision specified).
> 
> In other words, repoman would complain at:
> 
>   =dev-foo/bar-1.2.3
> 
> but it will be happy if you used:
> 
>   ~dev-foo/bar-1-2.3
>   =dev-foo/bar-1.2.3-r0
> 
> I think this cause the trouble of specifying '-r0' rather rarely, and
> it
> will decrease the number of mistakes, also effectively making Gentoo
> development easier. It is somewhat inspired by the handling of slot
> operators (where repoman explicitly asks you to use ':*' instead
> of no operator when the latter would be ambiguous).
> 
> What do you think?

Sounds good. The attached script hopefully gives a good indication of
how much packages would be affected. A local run raises about 92
ebuilds.
#!/usr/bin/env python

from portage import isvalidatom, portdb

for cpv in portdb.cpv_all():
deps = portdb.aux_get(cpv, ['DEPEND', 'RDEPEND', 'PDEPEND'])
atoms = set(' '.join(deps).split(' '))

suspicious = []
for atom in atoms:
if not isvalidatom(atom):
continue

# Drop USE-dependencies and slots
atom_simple = atom.split(':')[0].split('[')[0]
if atom[0] == '=' and atom_simple[-1] != '*' and not atom_simple.endswith(''):
suspicious.append(atom)

if suspicious:
print('%s: %s' % (cpv, suspicious))


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

Re: [gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag

[Gilles Dartiguelongue]

Le lundi 26 février 2018 à 23:24 +0100, Michał Górny a écrit :
> 'luajit' is used consistently in 25+ packages. Make it a global flag.

Not that I have a strong opinion about it, but wouldn't it be better to
have USE="lua jit" like libpeas does ? Use flags aren't supposed to
match library names but features so this would seem more correct.

-- 
Gilles Dartiguelongue 

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Zac Medico]

On 03/25/2018 02:02 AM, Kent Fredric wrote:
> On Sat, 24 Mar 2018 21:43:41 -0700
> Zac Medico  wrote:
> 
>> But if the majority demographic is as you describe, then they shouldn't
>> be using anything having dependencies that require package.unmask or **
>> keywords changes.
> 
> Again, they *dont*, the problem is portage makes the mistake of
> thinking they do.
> 
> This happens especially around virtuals where there is an existing
> problem of portage not doing the right thing when perl-core/* exists in
> some definition.
> 
> I don't have details on hand to give you as to how this happens,
> but I've seen this happen often enough around packages *I maintain* and
> *I* can't explain why portage is trying to install it, only that
> --auto-unmask-keep-masks=y makes the problem mysteriously go away.

An issue like that involving REQUIRED_USE has been reported, and today
I've created a patch that corrects the problem:

https://bugs.gentoo.org/622462

> The question for me is not "auto unmask is good" vs "autounmask is
> bad", autounmask is fine on its own and is very useful.
> 
> Its the default of --autounmask-keep-masks=n that I find short on value.
> 
> If anything, I suggest there needs to be an
> --autounmask-keep-masks=conditional, or something, that narrows the
> range of solutions portage will try and only attempt to unmask ** or
> package.mask in the following conditions:
> 
> - An explicitly masked package/version is explicitly requested on the command 
> line.
> - A package is a direct dependency of of the above
> - As above, but for the world file
> 
> That is, assume the only reason for masked packages to be considered is:
> - The user in some way directly requested them
> - A logical consequence of the user directly requesting a masked package

It's possible that bug 622462 is not the only way to trigger this
problem. If anyone experiences a problem like this, then a bug report
would be appreciated.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] emerge --autounmask: prevent unmask due to unsatisfied REQUIRED_USE (bug 622462)

[Zac Medico]

Fix autounmask to generate USE changes that violate REQUIRED_USE, in
order to prevent it from trying to create inappropriate keywords or
package.unmask. This solves the problem reported in bug 622462, where
it inappropriately unmasked a newer version of qscintilla. With this
fix, it will generate USE changes that violate REQUIRED_USE, and then
report the issue as follows:

emerge: there are no ebuilds built with USE flags to satisfy 
">=x11-libs/qscintilla-2.9.3-r2:=[qt5(+)]".
!!! One of the following packages is required to complete your request:
- x11-libs/qscintilla-2.9.4::test_repo (Change USE: +qt5, this change violates 
use flag constraints defined by x11-libs/qscintilla-2.9.4: 'exactly-one-of ( 
qt4 qt5 )')

Note that it may be possible for autounmask to try harder to solve
REQUIRED_USE in cases like this, but that it beyond the scope of this
bug fix. The only goal of this patch is to correctly handle the case
where satisfaction of REQUIRED_USE has failed.

Bug: https://bugs.gentoo.org/622462
---
 pym/_emerge/depgraph.py   | 20 +---
 pym/portage/tests/resolver/test_autounmask.py | 27 +++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 6c728684f..7ec3f09a7 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -355,6 +355,13 @@ class _rebuild_config(object):
return need_restart
 
 
+class _use_changes(tuple):
+   def __new__(cls, new_use, new_changes, required_use_satisfied=True):
+   obj = tuple.__new__(cls, [new_use, new_changes])
+   obj.required_use_satisfied = required_use_satisfied
+   return obj
+
+
 class _dynamic_depgraph_config(object):
 
"""
@@ -6130,22 +6137,25 @@ class depgraph(object):
 
if new_changes != old_changes:
#Don't do the change if it violates REQUIRED_USE.
+   required_use_satisfied = True
required_use = pkg._metadata.get("REQUIRED_USE")
if required_use and check_required_use(required_use, 
old_use,
pkg.iuse.is_valid_flag, eapi=pkg.eapi) and \
not check_required_use(required_use, new_use,
pkg.iuse.is_valid_flag, eapi=pkg.eapi):
-   return old_use
+   required_use_satisfied = False
 
if any(x in pkg.use.mask for x in new_changes) or \
any(x in pkg.use.force for x in new_changes):
return old_use
 
-   self._dynamic_config._needed_use_config_changes[pkg] = 
(new_use, new_changes)
+   changes = _use_changes(new_use, new_changes,
+   required_use_satisfied=required_use_satisfied)
+   self._dynamic_config._needed_use_config_changes[pkg] = 
changes
backtrack_infos = self._dynamic_config._backtrack_infos
backtrack_infos.setdefault("config", {})

backtrack_infos["config"].setdefault("needed_use_config_changes", [])
-   
backtrack_infos["config"]["needed_use_config_changes"].append((pkg, (new_use, 
new_changes)))
+   
backtrack_infos["config"]["needed_use_config_changes"].append((pkg, changes))
if want_restart_for_use_change(pkg, new_use):
self._dynamic_config._need_restart = True
return new_use
@@ -9384,6 +9394,10 @@ class depgraph(object):
return self._dynamic_config._need_config_reload
 
def autounmask_breakage_detected(self):
+   # Check for REQUIRED_USE violations.
+   for changes in 
self._dynamic_config._needed_use_config_changes.values():
+   if getattr(changes, 'required_use_satisfied', None) is 
False:
+   return True
try:
for pargs, kwargs in 
self._dynamic_config._unsatisfied_deps_for_display:
self._show_unsatisfied_dep(
diff --git a/pym/portage/tests/resolver/test_autounmask.py 
b/pym/portage/tests/resolver/test_autounmask.py
index e2a7de028..c9db6141b 100644
--- a/pym/portage/tests/resolver/test_autounmask.py
+++ b/pym/portage/tests/resolver/test_autounmask.py
@@ -61,6 +61,25 @@ class AutounmaskTestCase(TestCase):
 
"app-portage/B-1": { "IUSE": "foo +bar", 
"REQUIRED_USE": "^^ ( foo bar )", "EAPI": "4" },
"app-portage/C-1": { "IUSE": "+foo +bar", 
"REQUIRED_USE": "^^ ( foo bar )", "EAPI": "4" },
+
+   "sci-mathematics/octave-4.2.2": {
+   "EAPI": 6,
+   "RDEPEND":