Re: [gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

[Alexis Ballier]

On Sat, 11 Mar 2017 22:25:45 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted:
> 
> > On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel"
> >  wrote:  
> >> This keywording bug 597822 is now open since 2016-10-22.  
> > 
> > 
> > Man, it's been only 5 months :)  
> 
> ... which will make it six months after the announced 30-day clock 
> expires.  (Make it 45-days and it'll be a full calendar six months,
> half a year.)
> 

Note: this was meant as a joke / sarcasm :)

I'm still waiting for texlive 2013 keywords on 2 of these arches. And
yes, 2013 is the year of the release :)

jer is usually dilligent for hppa, when he's not it usually means he
found an issue that he'll report when he'll have time to investigate it
properly

As for the 2 others, I think it would make more sense to demote their
profiles to dev these days.

Re: [gentoo-dev] How to deal with package forks?

[Michał Górny]

W dniu 11.03.2017, sob o godzinie 21∶49 -0500, użytkownik Rich Freeman
napisał:
> On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric  wrote:
> > On Thu, 09 Mar 2017 16:34:20 +0100
> > Michał Górny  wrote:
> > 
> > > 1. classic forks -- package B is forked out of A, and the development of
> > > both continue independently (eudev/systemd, ffmpeg/libav);
> > > 
> > > 2. large patch sets / continuously rebased forks -- where the particular
> > > set of changes is usually applied to mainline or regularly rebased
> > > against mainline but without full separation (kernel patchsets, bitcoin
> > > patches);
> > > 
> > > 3. abandoned package forks -- package A stops being maintained upstream,
> > > someone forks it and starts working on top of that (xarchiver).
> > 
> > I think any formal guideline needs to be clear that these statements are 
> > with regards
> > to *mutually exclusive* forks, where dual-installation is not viable and/or 
> > auto-linking
> > magic would do bad things if they were co-installed.
> > 
> > Partly because not all forks are done by 3rd parties. Some projects "Self 
> > fork".
> > 
> > But here, the distinction between "fork" and "major version" blurs, because 
> > often
> > the reason for a "self fork" is to explicitly allow cohabitation with the 
> > "old fork",
> > in a manner very akin to "new major version in new slot".
> > 
> > So with that said, in all of those cases, if the "new" fork and the "old" 
> > fork don't
> > directly compete at a physical level, even though they share logical 
> > ancestry, they can be considered
> > new independent software.
> 
> So, I have to ask.  All this theorizing is interesting and I think it
> can make for guidelines, but do we really have any cases where it
> isn't working out under maintainer discretion, other than the one case
> that started this discussion?
> 
> My sense is that everybody has already figured out the best way to
> handle these kinds of patches and is already using discretion to sort
> out these cases.  I don't think we need a generic policy over a
> dispute about how bitcoin is packaged.

Actually, what started this is me wondering whether I did the right
thing by switching app-arch/xarchiver to the fork.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Walter Dnes]

- Typo...
Additional Security Project bugzilla notes
* The Security Project is except (should that read "exempt"?)



- An intermediate level before masking might be issuing a warning if
  some simple, specific remediation measure can protect against a
  vulnerability.  E.g. forcing cups to only listen to 127.0.0.1 or :1

- If you want to absolutely ensure that people are warned of a severe,
  but remediable vulnerability, is it acceptable to "break the build"
  by requiring a new local USE flag for the ebuild?  I'm thinking of
  something like "glep_0001234", "glep_0001235", "glep_0001236", etc,
  and have the ebuild die if the flag is not set, and print out a URL
  for a security problem.  This could be abstracted to make.conf with
  a new variable...

  GLEP="0001234 0001235 0001236 etc etc"

  This would probably be the last stage before masking.  It would
deliberately break the build, and require the user/admin to take manual
action (add the flag for the GLEP) before proceeding further.  This is
a heavy-handed method, but masking is more final.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Rich Freeman]

On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand  wrote:
> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>>
>> My point is that users must be informed about security problem, but
>> they still should have a choice. So it should be either a rule
>> "mask without removal" or clear guidelines when to remove a
>> package and when to not.
>
> At some point, of a package does not belong in the main tree due to
> security vulnerabilities, they can still be kept in an overlay by a
> respective project without it impacting other users. I'm not convinced
> that impacts the overall user experience of other Gentoo users.
>

Is there any reason that this can't be left to maintainer discretion?
The package is masked and clearly advertises its security issue.  The
user can make an informed choice.  Do we really need to force the
issue further?  What is the benefit to Gentoo in doing so?

-- 
Rich

Re: [gentoo-dev] How to deal with package forks?

[Rich Freeman]

On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric  wrote:
> On Thu, 09 Mar 2017 16:34:20 +0100
> Michał Górny  wrote:
>
>> 1. classic forks -- package B is forked out of A, and the development of
>> both continue independently (eudev/systemd, ffmpeg/libav);
>>
>> 2. large patch sets / continuously rebased forks -- where the particular
>> set of changes is usually applied to mainline or regularly rebased
>> against mainline but without full separation (kernel patchsets, bitcoin
>> patches);
>>
>> 3. abandoned package forks -- package A stops being maintained upstream,
>> someone forks it and starts working on top of that (xarchiver).
>
> I think any formal guideline needs to be clear that these statements are with 
> regards
> to *mutually exclusive* forks, where dual-installation is not viable and/or 
> auto-linking
> magic would do bad things if they were co-installed.
>
> Partly because not all forks are done by 3rd parties. Some projects "Self 
> fork".
>
> But here, the distinction between "fork" and "major version" blurs, because 
> often
> the reason for a "self fork" is to explicitly allow cohabitation with the 
> "old fork",
> in a manner very akin to "new major version in new slot".
>
> So with that said, in all of those cases, if the "new" fork and the "old" 
> fork don't
> directly compete at a physical level, even though they share logical 
> ancestry, they can be considered
> new independent software.
>

So, I have to ask.  All this theorizing is interesting and I think it
can make for guidelines, but do we really have any cases where it
isn't working out under maintainer discretion, other than the one case
that started this discussion?

My sense is that everybody has already figured out the best way to
handle these kinds of patches and is already using discretion to sort
out these cases.  I don't think we need a generic policy over a
dispute about how bitcoin is packaged.

-- 
Rich

Re: [gentoo-dev] [patch] golang-vcs-snapshot.eclass: add vendoring of external dependencies

[Kent Fredric]

On Thu, 09 Mar 2017 18:16:51 -0500
"William L. Thomson Jr."  wrote:

> That would likely be an incorrect ebuild and should not have been committed 
> to 
> tree.

If people didn't accidentally overlook problems where variables contained the 
wrong
contents and tried to access files they shouldn't, we wouldn't have a need for 
Gentoo Maintainers.

More over, we wouldn't need a lot of security we have these days, and PHP 
features like register_globals
would have never been considered a bad thing.

But the reality is, sometimes you write bugs in your code where you're not 
looking at it carefully enough.

Sometimes said bugs sneak through code review, tests, and about 100 people 
installing it without issue.

Hence a defensive approach of "Look, I don't think I've done anything really 
bad here, but just in case
reality starts bending in on itself, lets put in some sensible BANG points to 
catch that".

You're not going to remember every time you aught to put such BANG points in 
place, but the hope is
that having *2* mental toolkits: "Don't make mistakes"  and "Put things in 
place to go bang when I make mistakes",

With a bit of luck, both won't fail a the same time.

But that's just me I guess. || die "Error sending clear message by email" 


pgpTDurvdTHEu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] How to deal with package forks?

[Kent Fredric]

On Thu, 09 Mar 2017 16:34:20 +0100
Michał Górny  wrote:

> 1. classic forks -- package B is forked out of A, and the development of
> both continue independently (eudev/systemd, ffmpeg/libav);
> 
> 2. large patch sets / continuously rebased forks -- where the particular
> set of changes is usually applied to mainline or regularly rebased
> against mainline but without full separation (kernel patchsets, bitcoin
> patches);
> 
> 3. abandoned package forks -- package A stops being maintained upstream,
> someone forks it and starts working on top of that (xarchiver).

I think any formal guideline needs to be clear that these statements are with 
regards
to *mutually exclusive* forks, where dual-installation is not viable and/or 
auto-linking
magic would do bad things if they were co-installed.

Partly because not all forks are done by 3rd parties. Some projects "Self fork".

But here, the distinction between "fork" and "major version" blurs, because 
often
the reason for a "self fork" is to explicitly allow cohabitation with the "old 
fork",
in a manner very akin to "new major version in new slot".

So with that said, in all of those cases, if the "new" fork and the "old" fork 
don't
directly compete at a physical level, even though they share logical ancestry, 
they can be considered
new independent software.



pgpfAAErH4s1P.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
> Hi Kristian,
> 
> On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
>> A draft of a Pre-GLEP for the Security project is available for reading
>> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
>>
>> The GLEP follows a line of GLEPs for special projects that have
>> tree-wide access in order to ensure proper accountability (c.f GLEP 48
>> for QA and still non-produced GLEP for ComRel (I've started working on
>> this and will be presenting this one later as current ComRel Lead))
>>
>> Comments, patches, threats, etc welcome
> 
> First of all, thank you for this Pre-GLEP, since we really need some
> public and established policy for the Security project.
> 
> 1. From this proposal it looks like the Security Project Lead
> obtains a lot of power and a lot of responsibility, maybe too much
> for a single person to handle.
> 
> While the Deputy may be assigned, this still gives all power to
> single hands. Maybe it will be better to establish something like
> the Security Project Council (SPC)? E.g. three project members may
> be elected to this SPC, so that all serious decisions will require
> some team agreement from at least 2 SPC members. This way the
> Deputy will not be needed as well.
> 

The thinking here is that the project lead is the responsible party. Any
ambiguity can still be escalated to the Gentoo Council, but someone
needs to be responsible from the side of the Gentoo Security Project.

> 2. "If a vulnerability is unlikely to be fixed by upstream or the
> package's maintainer it might require a package mask." — I'd like
> to see this expanded to more detail, because it is possible to mask
> for removal and to simply mask without scheduled removal.
> 
> Sometimes an application is desirable even if it is vulnerable,
> e.g. if there are no alternatives. Sometimes a vulnerability is
> minor or affect a very rare use case. Sometimes users need a
> specific software version for their workflow and they don't really
> care about security — this affects many scientific packages being
> used at isolated HPC setups.
> 
> My point is that users must be informed about security problem, but
> they still should have a choice. So it should be either a rule
> "mask without removal" or clear guidelines when to remove a
> package and when to not.

At some point, of a package does not belong in the main tree due to
security vulnerabilities, they can still be kept in an overlay by a
respective project without it impacting other users. I'm not convinced
that impacts the overall user experience of other Gentoo users.


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-scheme/schoca

[Michael Palimaka]

# Michael Palimaka  (11 Mar 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #592184.
dev-scheme/schoca

[gentoo-dev] Re: Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

[Duncan]

Alexis Ballier posted on Sat, 11 Mar 2017 20:59:56 +0100 as excerpted:

> On Sat, 11 Mar 2017 20:45:07 +0100 "Andreas K. Huettel"
>  wrote:
>> This keywording bug 597822 is now open since 2016-10-22.
> 
> 
> Man, it's been only 5 months :)

... which will make it six months after the announced 30-day clock 
expires.  (Make it 45-days and it'll be a full calendar six months, half 
a year.)

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

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Andrew Savchenko]

Hi Kristian,

On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
> A draft of a Pre-GLEP for the Security project is available for reading
> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
> 
> The GLEP follows a line of GLEPs for special projects that have
> tree-wide access in order to ensure proper accountability (c.f GLEP 48
> for QA and still non-produced GLEP for ComRel (I've started working on
> this and will be presenting this one later as current ComRel Lead))
> 
> Comments, patches, threats, etc welcome

First of all, thank you for this Pre-GLEP, since we really need some
public and established policy for the Security project.

1. From this proposal it looks like the Security Project Lead
obtains a lot of power and a lot of responsibility, maybe too much
for a single person to handle.

While the Deputy may be assigned, this still gives all power to
single hands. Maybe it will be better to establish something like
the Security Project Council (SPC)? E.g. three project members may
be elected to this SPC, so that all serious decisions will require
some team agreement from at least 2 SPC members. This way the
Deputy will not be needed as well.

2. "If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer it might require a package mask." — I'd like
to see this expanded to more detail, because it is possible to mask
for removal and to simply mask without scheduled removal.

Sometimes an application is desirable even if it is vulnerable,
e.g. if there are no alternatives. Sometimes a vulnerability is
minor or affect a very rare use case. Sometimes users need a
specific software version for their workflow and they don't really
care about security — this affects many scientific packages being
used at isolated HPC setups.

My point is that users must be informed about security problem, but
they still should have a choice. So it should be either a rule
"mask without removal" or clear guidelines when to remove a
package and when to not.

Best regards,
Andrew Savchenko


pgpg_bm2zlxSw.pgp
Description: PGP signature

[gentoo-dev] last rites: dev-perl/Net-Google-SafeBrowsing-UpdateRequest dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing

[Andreas K. Huettel]

# Andreas K. Hüttel  (11 Mar 2017)
# Fails since upgrade to dev-lang/perl-5.12 (!).
# Removal in 30 days. Bug 336898.
dev-perl/Net-Google-SafeBrowsing-UpdateRequest
dev-perl/Mail-SpamAssassin-Plugin-GoogleSafeBrowsing

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

[gentoo-dev] last rites: dev-libs/btparse

[Andreas K. Huettel]

(side notes, 
* the original dev-libs/btparse library has not seen any updates since 2007
* the Perl version removed the separate (autoconf) build system, so only 
Makefile.PL really works now...)

# Andreas K. Hüttel  (11 Mar 2017)
# Dead upstream; the library has been picked up by
# dev-perl/Text-BibTeX and is further developed there.
# Please uninstall dev-libs/btparse and re-build your
# application against >=dev-perl/Text-BibTeX-0.780.0-r1
# (this should happen automatically with tellico, the
# only reverse dependency in the main tree).
# Removal in 30 days.
dev-libs/btparse


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

[gentoo-dev] Last rites: dev-java/jusb

[Patrice Clement]

# Patrice Clement  (11 Mar 2017)
# Upstream dead: no update since 2003. Ebuild is outdated and buggy.
# Removal in 30 days. Bug #279088
dev-java/jusb

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

A draft of a Pre-GLEP for the Security project is available for reading
at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security

The GLEP follows a line of GLEPs for special projects that have
tree-wide access in order to ensure proper accountability (c.f GLEP 48
for QA and still non-produced GLEP for ComRel (I've started working on
this and will be presenting this one later as current ComRel Lead))

Comments, patches, threats, etc welcome

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Anthony G. Basile]

On 3/11/17 3:13 PM, Peter Stuge wrote:
> 
> All lines containing +knots should say knots instead.
> 

Done.


I'm getting increasingly unsatisfied with where bitcoins* is going.  I
think I'd like to take full ownership of it and remove all unnecessary
patches.  If there's anyone that wants to co-maintain it with me, I'd
welcome the help.  I'm busy until summer at which time I revisit the
issue and try to clean up the eclass and ebuilds.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

[Alexis Ballier]

On Sat, 11 Mar 2017 20:45:07 +0100
"Andreas K. Huettel"  wrote:
> This keywording bug 597822 is now open since
> 2016-10-22.


Man, it's been only 5 months :)

[gentoo-dev] Fwd: [Bug 597822] www-apache/mod_perl-2.0.10 dev-perl/Chatbot-Eliza-1.60.0 keyword request

[Andreas K. Huettel]

Forwarded message: https://bugs.gentoo.org/show_bug.cgi?id=597822

--- Comment #5 from Andreas K. Hüttel  ---
@@@ IMPORTANT MESSAGE TO ARCH TEAMS @@

I'll drop keywords for mod_perl and all of its reverse dependencies for any
arch that has not even restored the KEYWORD yet in this bug, 30 days from 
today. This keywording bug 597822 is now open since 2016-10-22.

This means in particular, if you're still interested in running mod_perl on
hppa, ia64 or sparc, get your backside moving now!

@@@ IMPORTANT MESSAGE TO ARCH TEAMS @@

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

[Peter Stuge]

Anthony G. Basile wrote:
> >> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> >> against the bitcoin eclass.  The following is his proposed change.
> >> I'll commit it after review.
> > 
> > Please do not do that, Anthony.
> 
> I don't have time nor the familiarity to properly maintain bitcoins
> myself.

Understood, and no problem. I think it's especially important to be a
bit conservative under those circumstances.


> I will ignore all negative advice regarding this package unless it is
> balanced with positive advice.

That's cool. I tried to also be constructive in my mail - sorry if
that didn't get through. I was saying that the patched version should
probably be a separate ebuild.

But Mathy's (sorry for the mistype in my last mail Mathy) suggestion
to go ahead with renaming the USE flag but *not* flipping it to
default on is also a good step.


> Please point out what lines of the patch should be changed and what
> they should be changed to, else I will commit the patch as
> provided.

All lines containing +knots should say knots instead.


Thanks!

//Peter

[gentoo-dev] [PATCH] eutils.eclass: Kill multilib inherit for EAPI 7

[Michał Górny]

The multilib.eclass seems not to be used by any eutils function.
Therefore, disable the inherit for EAPI 7. It is being preserved for
older EAPIs not to break ebuilds inheriting this eclass and using
multilib.eclass functions implicitly.
---
 eclass/eutils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 724a310b3000..e036001dc5e1 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -17,12 +17,12 @@
 if [[ -z ${_EUTILS_ECLASS} ]]; then
 _EUTILS_ECLASS=1
 
-inherit multilib toolchain-funcs
+inherit toolchain-funcs
 
 # implicitly inherited (now split) eclasses
 case ${EAPI:-0} in
 0|1|2|3|4|5|6)
-   inherit epatch estack
+   inherit epatch estack multilib
;;
 esac
 
-- 
2.12.0

[gentoo-dev] [PATCH v2] epatch.eclass: Split epatch* logic from eutils

[Michał Górny]

Move epatch and epatch_user (along with the descriptions for all their
variables) into a dedicated epatch.eclass. This function is very
complex, therefore it benefits from separate eclass and a dedicated
maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6.

The new eclass is implicitly inherited by eutils to preserve
compatibility. However, the inherit will be removed in EAPI 7,
and the ebuilds should switch to inheriting epatch directly or using
eapply*.

Thanks to Ulrich Müller for doing the necessary research.
---
 eclass/epatch.eclass | 458 +++
 eclass/eutils.eclass | 440 +
 2 files changed, 459 insertions(+), 439 deletions(-)
 create mode 100644 eclass/epatch.eclass

diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
new file mode 100644
index ..fb0a10b53583
--- /dev/null
+++ b/eclass/epatch.eclass
@@ -0,0 +1,458 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: epatch.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: easy patch application functions
+# @DESCRIPTION:
+# An eclass providing epatch and epatch_user functions to easily apply
+# patches to ebuilds. Mostly superseded by eapply* in EAPI 6.
+
+if [[ -z ${_EPATCH_ECLASS} ]]; then
+
+# @VARIABLE: EPATCH_SOURCE
+# @DESCRIPTION:
+# Default directory to search for patches.
+EPATCH_SOURCE="${WORKDIR}/patch"
+# @VARIABLE: EPATCH_SUFFIX
+# @DESCRIPTION:
+# Default extension for patches (do not prefix the period yourself).
+EPATCH_SUFFIX="patch.bz2"
+# @VARIABLE: EPATCH_OPTS
+# @DESCRIPTION:
+# Options to pass to patch.  Meant for ebuild/package-specific tweaking
+# such as forcing the patch level (-p#) or fuzz (-F#) factor.  Note that
+# for single patch tweaking, you can also pass flags directly to epatch.
+EPATCH_OPTS=""
+# @VARIABLE: EPATCH_COMMON_OPTS
+# @DESCRIPTION:
+# Common options to pass to `patch`.  You probably should never need to
+# change these.  If you do, please discuss it with base-system first to
+# be sure.
+# @CODE
+#  -g0 - keep RCS, ClearCase, Perforce and SCCS happy #24571
+#  --no-backup-if-mismatch - do not leave .orig files behind
+#  -E - automatically remove empty files
+# @CODE
+EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch"
+# @VARIABLE: EPATCH_EXCLUDE
+# @DESCRIPTION:
+# List of patches not to apply. Note this is only file names,
+# and not the full path.  Globs accepted.
+EPATCH_EXCLUDE=""
+# @VARIABLE: EPATCH_SINGLE_MSG
+# @DESCRIPTION:
+# Change the printed message for a single patch.
+EPATCH_SINGLE_MSG=""
+# @VARIABLE: EPATCH_MULTI_MSG
+# @DESCRIPTION:
+# Change the printed message for multiple patches.
+EPATCH_MULTI_MSG="Applying various patches (bugfixes/updates) ..."
+# @VARIABLE: EPATCH_FORCE
+# @DESCRIPTION:
+# Only require patches to match EPATCH_SUFFIX rather than the extended
+# arch naming style.
+EPATCH_FORCE="no"
+# @VARIABLE: EPATCH_USER_EXCLUDE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of patches not to apply. Note this is only file names,
+# and not the full path.  Globs accepted.
+
+# @FUNCTION: epatch
+# @USAGE: [options] [patches] [dirs of patches]
+# @DESCRIPTION:
+# epatch is designed to greatly simplify the application of patches.  It can
+# process patch files directly, or directories of patches.  The patches may be
+# compressed (bzip/gzip/etc...) or plain text.  You generally need not specify
+# the -p option as epatch will automatically attempt -p0 to -p4 until things
+# apply successfully.
+#
+# If you do not specify any patches/dirs, then epatch will default to the
+# directory specified by EPATCH_SOURCE.
+#
+# Any options specified that start with a dash will be passed down to patch
+# for this specific invocation.  As soon as an arg w/out a dash is found, then
+# arg processing stops.
+#
+# When processing directories, epatch will apply all patches that match:
+# @CODE
+#  if ${EPATCH_FORCE} != "yes"
+#  ??_${ARCH}_foo.${EPATCH_SUFFIX}
+#  else
+#  *.${EPATCH_SUFFIX}
+# @CODE
+# The leading ?? are typically numbers used to force consistent patch ordering.
+# The arch field is used to apply patches only for the host architecture with
+# the special value of "all" means apply for everyone.  Note that using values
+# other than "all" is highly discouraged -- you should apply patches all the
+# time and let architecture details be detected at configure/compile time.
+#
+# If EPATCH_SUFFIX is empty, then no period before it is implied when searching
+# for patches to apply.
+#
+# Refer to the other EPATCH_xxx variables for more customization of behavior.
+epatch() {
+   _epatch_draw_line() {
+   # create a line of same length as input string
+   [[ -z $1 ]] && set "$(printf "%65s" '')"
+   echo "${1//?/=}"
+   }
+
+   unset P4CONFIG P4PORT P4USER # keep perforce at 

[gentoo-dev] [PATCH v2] estack.eclass: Split estack* logic from eutils

[Michał Górny]

Split the estack_* and related functions from eutils into a dedicated
estack.eclass. Those functions have significant complexity and are not
used frequently, therefore they benefit from having a separate file
and an explicit dedicated maintainer.

The new eclass is implicitly inherited by eutils to preserve
compatibility. However, the inherit will be removed in EAPI 7,
and the ebuilds should switch to using estack directly.

Thanks to Ulrich Müller for doing the research on this.
---
 eclass/estack.eclass | 217 +++
 eclass/eutils.eclass | 210 ++---
 2 files changed, 224 insertions(+), 203 deletions(-)
 create mode 100644 eclass/estack.eclass

diff --git a/eclass/estack.eclass b/eclass/estack.eclass
new file mode 100644
index ..19c388f3d8d2
--- /dev/null
+++ b/eclass/estack.eclass
@@ -0,0 +1,217 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: estack.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: stack-like value storage support
+# @DESCRIPTION:
+# Support for storing values on stack-like variables.
+
+if [[ -z ${_ESTACK_ECLASS} ]]; then
+
+# @FUNCTION: estack_push
+# @USAGE:  [items to push]
+# @DESCRIPTION:
+# Push any number of items onto the specified stack.  Pick a name that
+# is a valid variable (i.e. stick to alphanumerics), and push as many
+# items as you like onto the stack at once.
+#
+# The following code snippet will echo 5, then 4, then 3, then ...
+# @CODE
+#  estack_push mystack 1 2 3 4 5
+#  while estack_pop mystack i ; do
+#  echo "${i}"
+#  done
+# @CODE
+estack_push() {
+   [[ $# -eq 0 ]] && die "estack_push: incorrect # of arguments"
+   local stack_name="_ESTACK_$1_" ; shift
+   eval ${stack_name}+=\( \"\$@\" \)
+}
+
+# @FUNCTION: estack_pop
+# @USAGE:  [variable]
+# @DESCRIPTION:
+# Pop a single item off the specified stack.  If a variable is specified,
+# the popped item is stored there.  If no more items are available, return
+# 1, else return 0.  See estack_push for more info.
+estack_pop() {
+   [[ $# -eq 0 || $# -gt 2 ]] && die "estack_pop: incorrect # of arguments"
+
+   # We use the fugly _estack_xxx var names to avoid collision with
+   # passing back the return value.  If we used "local i" and the
+   # caller ran `estack_pop ... i`, we'd end up setting the local
+   # copy of "i" rather than the caller's copy.  The _estack_xxx
+   # garbage is preferable to using $1/$2 everywhere as that is a
+   # bit harder to read.
+   local _estack_name="_ESTACK_$1_" ; shift
+   local _estack_retvar=$1 ; shift
+   eval local _estack_i=\${#${_estack_name}\[@\]}
+   # Don't warn -- let the caller interpret this as a failure
+   # or as normal behavior (akin to `shift`)
+   [[ $(( --_estack_i )) -eq -1 ]] && return 1
+
+   if [[ -n ${_estack_retvar} ]] ; then
+   eval ${_estack_retvar}=\"\${${_estack_name}\[${_estack_i}\]}\"
+   fi
+   eval unset \"${_estack_name}\[${_estack_i}\]\"
+}
+
+# @FUNCTION: evar_push
+# @USAGE:  [more vars to save]
+# @DESCRIPTION:
+# This let's you temporarily modify a variable and then restore it (including
+# set vs unset semantics).  Arrays are not supported at this time.
+#
+# This is meant for variables where using `local` does not work (such as
+# exported variables, or only temporarily changing things in a func).
+#
+# For example:
+# @CODE
+#  evar_push LC_ALL
+#  export LC_ALL=C
+#  ... do some stuff that needs LC_ALL=C set ...
+#  evar_pop
+#
+#  # You can also save/restore more than one var at a time
+#  evar_push BUTTERFLY IN THE SKY
+#  ... do stuff with the vars ...
+#  evar_pop # This restores just one var, SKY
+#  ... do more stuff ...
+#  evar_pop 3   # This pops the remaining 3 vars
+# @CODE
+evar_push() {
+   local var val
+   for var ; do
+   [[ ${!var+set} == "set" ]] \
+   && val=${!var} \
+   || val="unset_76fc3c462065bb4ca959f939e6793f94"
+   estack_push evar "${var}" "${val}"
+   done
+}
+
+# @FUNCTION: evar_push_set
+# @USAGE:  [new value to store]
+# @DESCRIPTION:
+# This is a handy shortcut to save and temporarily set a variable.  If a value
+# is not specified, the var will be unset.
+evar_push_set() {
+   local var=$1
+   evar_push ${var}
+   case $# in
+   1) unset ${var} ;;
+   2) printf -v "${var}" '%s' "$2" ;;
+   *) die "${FUNCNAME}: incorrect # of args: $*" ;;
+   esac
+}
+
+# @FUNCTION: evar_pop
+# @USAGE: [number of vars to restore]
+# @DESCRIPTION:
+# Restore the variables to the state saved with the corresponding
+# evar_push call.  See that function for more 

Re: [gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils

[Ulrich Mueller]

> On Sat, 11 Mar 2017, Michał Górny wrote:

> Split the estack_* and related functions from eutils into a
> dedicated estack.eclass. Those functions have significant complexity
> and are not used frequently, therefore they benefit from having a
> separate file and an explicit dedicated maintainer.

This (and the other new eclass as well) might benefit from protection
against inheriting it multiple times:

if [[ -z ${_ESTACK_ECLASS} ]]; then
_ESTACK_ECLASS=1
# main eclass code here
fi


pgpH1YJ1N99P6.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

[Michał Górny]

W dniu 11.03.2017, sob o godzinie 09∶04 -0500, użytkownik Michael
Orlitzky napisał:
> On 03/11/2017 08:51 AM, Michał Górny wrote:
> > 
> > However, the inherit will be removed in EAPI 7
> > 
> > ...
> >  
> > -inherit estack multilib toolchain-funcs
> > +inherit epatch estack multilib toolchain-funcs
> >  
> 
> Would it hurt to do that now, so that we don't forget when EAPI 7 comes?
> For EAPI=0 to 6, inherit them all; otherwise, inherit the old set of
> eclasses (without estack or epatch).

Sure, I think we can do that. However, I'd also like to check whether
multilib is currently used at all as that is also a candidate for
removal. So maybe I'll do that in a single followup commit?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

[Michael Orlitzky]

On 03/11/2017 08:51 AM, Michał Górny wrote:
> 
> However, the inherit will be removed in EAPI 7
> 
> ...
>  
> -inherit estack multilib toolchain-funcs
> +inherit epatch estack multilib toolchain-funcs
>  

Would it hurt to do that now, so that we don't forget when EAPI 7 comes?
For EAPI=0 to 6, inherit them all; otherwise, inherit the old set of
eclasses (without estack or epatch).

[gentoo-dev] [PATCH] epatch.eclass: Split epatch* logic from eutils

[Michał Górny]

Move epatch and epatch_user (along with the descriptions for all their
variables) into a dedicated epatch.eclass. This function is very
complex, therefore it benefits from separate eclass and a dedicated
maintainer. Furthermore, it is mostly obsoleted by eapply* in EAPI 6.

The new eclass is implicitly inherited by eutils to preserve
compatibility. However, the inherit will be removed in EAPI 7,
and the ebuilds should switch to inheriting epatch directly or using
eapply*.
-
[Review note: this is 1:1 code move, no changes between the code]
--
 eclass/epatch.eclass | 453 +++
 eclass/eutils.eclass | 440 +
 2 files changed, 454 insertions(+), 439 deletions(-)
 create mode 100644 eclass/epatch.eclass

diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
new file mode 100644
index ..9727dae6bee7
--- /dev/null
+++ b/eclass/epatch.eclass
@@ -0,0 +1,453 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: epatch.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: easy patch application functions
+# @DESCRIPTION:
+# An eclass providing epatch and epatch_user functions to easily apply
+# patches to ebuilds. Mostly superseded by eapply* in EAPI 6.
+
+# @VARIABLE: EPATCH_SOURCE
+# @DESCRIPTION:
+# Default directory to search for patches.
+EPATCH_SOURCE="${WORKDIR}/patch"
+# @VARIABLE: EPATCH_SUFFIX
+# @DESCRIPTION:
+# Default extension for patches (do not prefix the period yourself).
+EPATCH_SUFFIX="patch.bz2"
+# @VARIABLE: EPATCH_OPTS
+# @DESCRIPTION:
+# Options to pass to patch.  Meant for ebuild/package-specific tweaking
+# such as forcing the patch level (-p#) or fuzz (-F#) factor.  Note that
+# for single patch tweaking, you can also pass flags directly to epatch.
+EPATCH_OPTS=""
+# @VARIABLE: EPATCH_COMMON_OPTS
+# @DESCRIPTION:
+# Common options to pass to `patch`.  You probably should never need to
+# change these.  If you do, please discuss it with base-system first to
+# be sure.
+# @CODE
+#  -g0 - keep RCS, ClearCase, Perforce and SCCS happy #24571
+#  --no-backup-if-mismatch - do not leave .orig files behind
+#  -E - automatically remove empty files
+# @CODE
+EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch"
+# @VARIABLE: EPATCH_EXCLUDE
+# @DESCRIPTION:
+# List of patches not to apply. Note this is only file names,
+# and not the full path.  Globs accepted.
+EPATCH_EXCLUDE=""
+# @VARIABLE: EPATCH_SINGLE_MSG
+# @DESCRIPTION:
+# Change the printed message for a single patch.
+EPATCH_SINGLE_MSG=""
+# @VARIABLE: EPATCH_MULTI_MSG
+# @DESCRIPTION:
+# Change the printed message for multiple patches.
+EPATCH_MULTI_MSG="Applying various patches (bugfixes/updates) ..."
+# @VARIABLE: EPATCH_FORCE
+# @DESCRIPTION:
+# Only require patches to match EPATCH_SUFFIX rather than the extended
+# arch naming style.
+EPATCH_FORCE="no"
+# @VARIABLE: EPATCH_USER_EXCLUDE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# List of patches not to apply. Note this is only file names,
+# and not the full path.  Globs accepted.
+
+# @FUNCTION: epatch
+# @USAGE: [options] [patches] [dirs of patches]
+# @DESCRIPTION:
+# epatch is designed to greatly simplify the application of patches.  It can
+# process patch files directly, or directories of patches.  The patches may be
+# compressed (bzip/gzip/etc...) or plain text.  You generally need not specify
+# the -p option as epatch will automatically attempt -p0 to -p4 until things
+# apply successfully.
+#
+# If you do not specify any patches/dirs, then epatch will default to the
+# directory specified by EPATCH_SOURCE.
+#
+# Any options specified that start with a dash will be passed down to patch
+# for this specific invocation.  As soon as an arg w/out a dash is found, then
+# arg processing stops.
+#
+# When processing directories, epatch will apply all patches that match:
+# @CODE
+#  if ${EPATCH_FORCE} != "yes"
+#  ??_${ARCH}_foo.${EPATCH_SUFFIX}
+#  else
+#  *.${EPATCH_SUFFIX}
+# @CODE
+# The leading ?? are typically numbers used to force consistent patch ordering.
+# The arch field is used to apply patches only for the host architecture with
+# the special value of "all" means apply for everyone.  Note that using values
+# other than "all" is highly discouraged -- you should apply patches all the
+# time and let architecture details be detected at configure/compile time.
+#
+# If EPATCH_SUFFIX is empty, then no period before it is implied when searching
+# for patches to apply.
+#
+# Refer to the other EPATCH_xxx variables for more customization of behavior.
+epatch() {
+   _epatch_draw_line() {
+   # create a line of same length as input string
+   [[ -z $1 ]] && set "$(printf "%65s" '')"
+   echo "${1//?/=}"
+   }
+
+   unset P4CONFIG P4PORT P4USER # keep perforce at bay #56402
+
+   # First 

[gentoo-dev] [PATCH] estack.eclass: Split estack* logic from eutils

[Michał Górny]

Split the estack_* and related functions from eutils into a dedicated
estack.eclass. Those functions have significant complexity and are not
used frequently, therefore they benefit from having a separate file
and an explicit dedicated maintainer.

The new eclass is implicitly inherited by eutils to preserve
compatibility. However, the inherit will be removed in EAPI 7,
and the ebuilds should switch to using estack directly.

[Review note: this is 1:1 code move, no changes between the code]
---
 eclass/estack.eclass | 212 +++
 eclass/eutils.eclass | 205 +
 2 files changed, 213 insertions(+), 204 deletions(-)
 create mode 100644 eclass/estack.eclass

diff --git a/eclass/estack.eclass b/eclass/estack.eclass
new file mode 100644
index ..f07f8e5882dc
--- /dev/null
+++ b/eclass/estack.eclass
@@ -0,0 +1,212 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: estack.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: stack-like value storage support
+# @DESCRIPTION:
+# Support for storing values on stack-like variables.
+
+# @FUNCTION: estack_push
+# @USAGE:  [items to push]
+# @DESCRIPTION:
+# Push any number of items onto the specified stack.  Pick a name that
+# is a valid variable (i.e. stick to alphanumerics), and push as many
+# items as you like onto the stack at once.
+#
+# The following code snippet will echo 5, then 4, then 3, then ...
+# @CODE
+#  estack_push mystack 1 2 3 4 5
+#  while estack_pop mystack i ; do
+#  echo "${i}"
+#  done
+# @CODE
+estack_push() {
+   [[ $# -eq 0 ]] && die "estack_push: incorrect # of arguments"
+   local stack_name="_ESTACK_$1_" ; shift
+   eval ${stack_name}+=\( \"\$@\" \)
+}
+
+# @FUNCTION: estack_pop
+# @USAGE:  [variable]
+# @DESCRIPTION:
+# Pop a single item off the specified stack.  If a variable is specified,
+# the popped item is stored there.  If no more items are available, return
+# 1, else return 0.  See estack_push for more info.
+estack_pop() {
+   [[ $# -eq 0 || $# -gt 2 ]] && die "estack_pop: incorrect # of arguments"
+
+   # We use the fugly _estack_xxx var names to avoid collision with
+   # passing back the return value.  If we used "local i" and the
+   # caller ran `estack_pop ... i`, we'd end up setting the local
+   # copy of "i" rather than the caller's copy.  The _estack_xxx
+   # garbage is preferable to using $1/$2 everywhere as that is a
+   # bit harder to read.
+   local _estack_name="_ESTACK_$1_" ; shift
+   local _estack_retvar=$1 ; shift
+   eval local _estack_i=\${#${_estack_name}\[@\]}
+   # Don't warn -- let the caller interpret this as a failure
+   # or as normal behavior (akin to `shift`)
+   [[ $(( --_estack_i )) -eq -1 ]] && return 1
+
+   if [[ -n ${_estack_retvar} ]] ; then
+   eval ${_estack_retvar}=\"\${${_estack_name}\[${_estack_i}\]}\"
+   fi
+   eval unset \"${_estack_name}\[${_estack_i}\]\"
+}
+
+# @FUNCTION: evar_push
+# @USAGE:  [more vars to save]
+# @DESCRIPTION:
+# This let's you temporarily modify a variable and then restore it (including
+# set vs unset semantics).  Arrays are not supported at this time.
+#
+# This is meant for variables where using `local` does not work (such as
+# exported variables, or only temporarily changing things in a func).
+#
+# For example:
+# @CODE
+#  evar_push LC_ALL
+#  export LC_ALL=C
+#  ... do some stuff that needs LC_ALL=C set ...
+#  evar_pop
+#
+#  # You can also save/restore more than one var at a time
+#  evar_push BUTTERFLY IN THE SKY
+#  ... do stuff with the vars ...
+#  evar_pop # This restores just one var, SKY
+#  ... do more stuff ...
+#  evar_pop 3   # This pops the remaining 3 vars
+# @CODE
+evar_push() {
+   local var val
+   for var ; do
+   [[ ${!var+set} == "set" ]] \
+   && val=${!var} \
+   || val="unset_76fc3c462065bb4ca959f939e6793f94"
+   estack_push evar "${var}" "${val}"
+   done
+}
+
+# @FUNCTION: evar_push_set
+# @USAGE:  [new value to store]
+# @DESCRIPTION:
+# This is a handy shortcut to save and temporarily set a variable.  If a value
+# is not specified, the var will be unset.
+evar_push_set() {
+   local var=$1
+   evar_push ${var}
+   case $# in
+   1) unset ${var} ;;
+   2) printf -v "${var}" '%s' "$2" ;;
+   *) die "${FUNCNAME}: incorrect # of args: $*" ;;
+   esac
+}
+
+# @FUNCTION: evar_pop
+# @USAGE: [number of vars to restore]
+# @DESCRIPTION:
+# Restore the variables to the state saved with the corresponding
+# evar_push call.  See that function for more details.
+evar_pop() {
+   local 

[gentoo-dev] [PATCH] eutils.eclass: Deprecate validate_desktop_entries

[Michał Górny]

The validate_desktop_entries function is redundant to the built-in
.desktop file checks done by Portage directly. It is used in total by
two packages for both of which bugs have been filed.
---
 eclass/eutils.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index e398aafc464a..d91245495caa 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -883,6 +883,9 @@ _eutils_eprefix_init() {
 # @DESCRIPTION:
 # Validate desktop entries using desktop-file-utils
 validate_desktop_entries() {
+   eqawarn "validate_desktop_entries is deprecated and should be not be 
used."
+   eqawarn ".desktop file validation is done implicitly by Portage now."
+
_eutils_eprefix_init
if [[ -x "${EPREFIX}"/usr/bin/desktop-file-validate ]] ; then
einfo "Checking desktop entry validity"
-- 
2.12.0