Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Aaron W. Swenson]

On 2016-01-25 10:31, Ian Stakenvicius wrote:
> On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> >> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
> >>  wrote:
> >> 
> >> I would like some feedback on the documentation/comments in
> >> the eclass. I'm certain it could be improved. Though, if you
> >> were able to follow them (not a slight, just you were the first
> >> to follow them), I might have done good enough.
> >> 
> > 
> > I'll have another look; i don't think I read any of the docs,
> > just looked to see that PG_CONFIG was set for me and confirmed
> > things looked to work the same as multilib-minimal.
> 
> OK here's my full review (with docs and all):
> 
> postgres.eclass:
> 
> postgres_check_slot() <-- #1, not seeing a need for this as
> dependencies should be forced now due to USE flag provisions.  #2,
> though, the documentation says it should be used in pkg_pretend but
> then in the code there's an exclusion to make it a no-op when it's
> run in pkg_pretend.  Perhaps it's supposed to be run in pkg_setup??

I'm a bit uncertain what to do with this. There are a few ebuilds that
check that the slot is set properly, and they do so as early as possible
so the user doesn't start the emerge and walk away thinking everything
will be okay. So, it tries to run the check, but won't die if the
PostgreSQL eselect module hasn't been emerged yet.

I could probably replace it with a pkg_setup that sets the PG_CONFIG
variable globally.

But, this would probably require another USE_EXPAND to do a single
target. I'm not against this, I just don't want to go use flag crazy.

> postgres_new_user() <-- the documentation seems a little bit unclear
> on this one..  It looks like it creates the 'postgres' user/group
> and optionally it also creates an additional specified user/group..
>  But i'm not sure how creating new users/groups here instead of with
> calling enewuser/enewgroup directly in the ebuild is helpful per
> se...?  It also seems a bit redundant if you wanted to create say, 2
> or 3 extra users/groups, to repeatedly call enewuser postgres 

You're right about how it works. I could scratch the rest of the
function and have it just create the postgres system group and
user. It's intended to make it so that a developer doesn't have to look
up the postgres system user and group parameters in another ebuild, or
dig around for nonexistent documentation, which will be rectified but
that'll still be difficult to search.

> postgres-multi.eclass:
> 
> #1 - main description could perhaps be changed from:
> 
> # build against any and all compatible PostgreSQL slots that are also
> # enabled by the user.
> 
> to:
> 
> # build and install for one or more PostgreSQL slots as specified by
> # POSTGRES_TARGETS use flags.

Done.

> #2 - POSTGRES_COMPAT , needs an example and/or text to describe the
> syntax of the slot specification.

Done.

> #3 - _POSTGRES_UNION_SLOTS -- you actually mean here the
> intersection between the two sets, rather than the union, right?
> Var can likely stay as-is but the description should probably be
> updated.

Well, that's a bit embarrassing. You'd think I'd know the difference by
now. Renamed it _POSTGRES_INTERSECT_SLOTS and corrected other
appearances of union.

> #4 - postgres-multi_foreach() -- this actually runs in the builddir,
> not the source dir as mentioned in the text.

Done.

> #5 - postgres-multi_forbest() -- maybe expand on what the "best"
> slot is here, ie that it's the lexicographically biggest slot rather
> than something else (like, say, the slot that's currently eselected)

Done.

> #6 - need docs for postgres-multi_src_prepare() and so forth -- just
> simple stuff will suffice I think:  postgres-multi_src_prepare()
> copies ${S} into a build directory for each target PG_SLOT and
> should be specified; the others are default functions that are
> provided for convenience, but postgres-multi_foreach should be used
> instead of these when customization is necessary.

Done.

> ...and I think that's it..

Thanks!


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: New Eclasses: postgres and postgres-multi

[Aaron W. Swenson]

On 2016-01-25 22:34, Jonathan Callen wrote:
> On 01/25/2016 07:29 AM, Aaron W. Swenson wrote:
> > On 2016-01-24 18:44, Michael Orlitzky wrote:
> >> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> >>> Okay, provided that the new USE_EXPAND is okay for
> >>> POSTGRES_TARGETS, attached are the eclasses that I'll commit to
> >>> the tree.
> >>> 
> >> 
> >>> case ${EAPI:-0} in 0|1|2|3|4) die "postgres-multi.eclass
> >>> requires EAPI 5 or higher" ;; *) ;; esac
> >> 
> >> Does this really work with EAPI=6? I didn't try, but it looks
> >> like it would need an eapply_user somewhere in src_prepare. And,
> >> pedantry warning, there's no such thing as "EAPI 5 or higher."
> >> The lawyers will tell you to do something like this instead
> >> (stolen from git-r3):
> >> 
> >> case "${EAPI:-0}" in 5|6) ;; *) die "Unsupported EAPI=${EAPI}
> >> (unknown) for ${ECLASS}" ;; esac
> >> 
> >> That will require an edit for every new EAPI, but prevents weird
> >> crashes from things like a missing eapply_user.
> >> 
> >> 
> > 
> > Thank you.
> > 
> > I've added the eapply_user to postgres-multi and modified the case 
> > condition to match the hot goods you're selling on the sly.
> > 
> 
> You missed the fix for EAPI in postgres-multi.eclass (it looks okay in
> the other eclass, though).

Fixed. Thanks!


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314

[Ulrich Mueller]

> On Tue, 26 Jan 2016, Göktürk Yüksek wrote:

> Ulrich Mueller:
>> The devmanual is the one central place where our development
>> workflow should be documented, not some random wiki page.
>> 
> If the most up-to-date information is on the wiki, constantly
> updating devmanual to match the wiki creates unnecessary maintenance
> burden.

The point is that any information that constitutes policy should be
traceable, e.g. there should be a bug or a patch should be posted to
the mailing lists.

> Related to my point above, looks like the git workflow is still in
> the process of making. I expect that some discussion will continue
> to take place in the future. We can always fix the other parts of
> the devmanual and come back to this.

I beg to differ. Apart from some small details, things have settled.
Looking at the history of the wiki page, there was quite some activity
in the two months following the switch to git, but very little after.

> Is it possible to merge this changeset as is while the workflow
> matures, or should I go for a round 3?

I'd prefer a round 3, including Michael's suggestions at least. That
is, include the "Commit message format" subsection from the wiki page
(or even the "Commit policy" section; it is not much longer).

Ulrich


pgp0RVkHvkWFb.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314

[Göktürk Yüksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ulrich Mueller:
>> On Sun, 24 Jan 2016, Michael Orlitzky wrote:
> 
>> The ChangeLog page is nonsense as-is, and removing it makes the 
>> devmanual better. Afterwards, if someone wants to take the commit
>> message guidelines from the wiki and merge them with the old
>> ChangeLog tips, great. There's only two things worth salvaging
>> from the ChangeLog page. Here's the combined list:
> 
>> 1. Everything from the Git workflow wiki page "Commit message 
>> format" section.
> 
> I would say not only that section, but most of the page. The 
> devmanual is the one central place where our development workflow 
> should be documented, not some random wiki page.
> 
If the most up-to-date information is on the wiki, constantly updating
devmanual to match the wiki creates unnecessary maintenance burden.

>> 2. Mention the "Gentoo-Bug:" identifier.
> 
> Right. (But had we settled for "Gentoo-Bug:"? IIRC, last time this 
> was discussed there was no consensus.)
> 
Related to my point above, looks like the git workflow is still in the
process of making. I expect that some discussion will continue to take
place in the future. We can always fix the other parts of the
devmanual and come back to this.

Is it possible to merge this changeset as is while the workflow
matures, or should I go for a round 3?

>> Using "bug #12345" in the commit message itself causes trouble. 
>> If you word-wrap on the "#12345", it will silently clobber the 
>> message.
> 
> That's one of the reasons why I have 'commentchar = ";"' in my 
> .gitconfig file. (Not sure if that option would be worth mentioning
> in our documentation, though.)
> 
>> [...]
> 
> Ulrich
> 

- --
gokturk

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWqEU2AAoJEIT4AuXAiM4zwCAH/3q8FQB+zX0q1kuXjJfYnF3j
IvJ2uKjuHMfbSAoGy2bUGEEhsvXGpNTmLv7vDIiHILCeLR0mD1eAmWHuJjjUSmJx
PyK6kAPaXX++E5aZ9gRuXqNFSGqiNx3oPvzQs0SH6vXgVec8fpmRk6y/Dg2r20Am
hfJLPIeD8Z9Vf/0wM7EcjiS3eVYrTnYCX+aGAKpgk74zKHcnHTL9S77no0Lemby1
vlCK9ceouVd6OYdDcvjNg73umlci7JIenCZCU3nagloGwvH6XDFWdGkWSRLQ0G7T
DoZlysM2Litafjr7NgyQ7R8xp1HnR+tmWfY26urIPd4rKU+aA05kPnQiTjgKTHo=
=UDYD
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH] emerge-webrsync: suppress tar future timestamp warning (bug 572578)

[Zac Medico]

As reported in bug 572578, the gentoo rsync repository contains a file
which intentionally has a future timestamp. Since tar future timestamp
warnings are irrelevant, suppress them if tar supports the option.

X-Gentoo-Bug: 572578
X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=572578
---
 bin/emerge-webrsync | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/bin/emerge-webrsync b/bin/emerge-webrsync
index 9961ad8..ee0d980 100755
--- a/bin/emerge-webrsync
+++ b/bin/emerge-webrsync
@@ -66,6 +66,9 @@ fi
 do_verbose=0
 do_debug=0
 keep=false
+tar_opts=()
+
+[[ $(tar --help) == *--warning* ]] && tar_opts+=(--warning=no-timestamp)
 
 if has webrsync-gpg ${FEATURES} ; then
WEBSYNC_VERIFY_SIGNATURE=1
@@ -86,7 +89,7 @@ do_tar() {
*.gz)   decompressor="zcat"  ;;
*)  decompressor="cat"   ;;
esac
-   ${decompressor} "${file}" | tar "$@"
+   ${decompressor} "${file}" | tar "${tar_opts[@]}" "$@"
_pipestatus=${PIPESTATUS[*]}
[[ ${_pipestatus// /} -eq 0 ]]
 }
@@ -225,7 +228,7 @@ sync_local() {
return 1
fi
else
-   if ! do_tar "${file}" xf -; then
+   if ! do_tar "${file}" -xf -; then
eecho "tar failed to extract the image. tarball is 
corrupt? (${file})"
rm -fr portage
return 1
-- 
2.4.10

Re: [gentoo-dev] New packages up for grabs

[Jason Zaman]

On Mon, Jan 25, 2016 at 12:32:06AM +0100, Michał Górny wrote:
> net-libs/libtorrent
> net-p2p/rtorrent

I'll take these

-- Jason

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Davide Pesavento]

On Tue, Jan 26, 2016 at 1:50 PM, Michał Górny  wrote:
> Dnia 26 stycznia 2016 13:36:00 CET, Davide Pesavento  
> napisał(a):
>>On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher  wrote:
>>> Signed-off-by: Justin Lecher 
>>> ---
>>>  eclass/cmake-utils.eclass | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>>> index 01de9a5..23339ab 100644
>>> --- a/eclass/cmake-utils.eclass
>>> +++ b/eclass/cmake-utils.eclass
>>> @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
>>>  # for econf and is needed to pass TRY_RUN results when
>>cross-compiling.
>>>  # Should be set by user in a per-package basis in
>>/etc/portage/package.env.
>>>
>>> -case ${EAPI} in
>>> +case ${EAPI:-0} in
>>> 2|3|4|5|6) : ;;
>>> *) die "EAPI=${EAPI:-0} is not supported" ;;
>>>  esac
>>> --
>>> 2.7.0
>>>
>>
>>Why?
>
> Indeed, why? I think it would be cleaner to simply quote the parameter to 
> case.
>

AFAIK even quoting would be unnecessary in this context (assuming bash).

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Justin Lecher (jlec)]

On 26/01/16 15:10, Davide Pesavento wrote:
> On Tue, Jan 26, 2016 at 1:50 PM, Michał Górny  wrote:
>> Dnia 26 stycznia 2016 13:36:00 CET, Davide Pesavento  
>> napisał(a):
>>> On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher  wrote:
 Signed-off-by: Justin Lecher 
 ---
  eclass/cmake-utils.eclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
 index 01de9a5..23339ab 100644
 --- a/eclass/cmake-utils.eclass
 +++ b/eclass/cmake-utils.eclass
 @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
  # for econf and is needed to pass TRY_RUN results when
>>> cross-compiling.
  # Should be set by user in a per-package basis in
>>> /etc/portage/package.env.

 -case ${EAPI} in
 +case ${EAPI:-0} in
 2|3|4|5|6) : ;;
 *) die "EAPI=${EAPI:-0} is not supported" ;;
  esac
 --
 2.7.0

>>>
>>> Why?
>>
>> Indeed, why? I think it would be cleaner to simply quote the parameter to 
>> case.
>>
> 
> AFAIK even quoting would be unnecessary in this context (assuming bash).
> 

Guys, if you are sure, that it is enough, then I will drop it. I just
thought there has to be something. But I tested it and it's unnecessary.
At least with latest bash.

Justin

[gentoo-dev] New schema language for metadata validation?

[Dirkjan Ochtman]

All,

TL;DR: I think we should switch from DTD to RELAX NG (compact syntax,
ideally) for our XML validation needs. It is more expressive and more
readable.

Most people who know anything about XML stuff know that DTDs are not
that great a solution for validation. Their expression power is very
limited; there are a few examples of this is in our metadata.dtd [1].
For a few years now, I've wanted to see if we could replace
metadata.dtd with something in RELAX NG, which is a more modern XML
schema language; it's an ISO standard with an emphasis on readability
both for humans and for tools (by using a rigorous formalism). Some
arguments in favor of RELAX NG (and some counter-arguments) are
enumerated on Tim Bray's weblog [2]. I've created a compact syntax
schema for metadata that can validate all metadata.xml files currently
in the tree, as an example [3].

Some arguments against:

- Not enough tool support for RELAX NG: I'd be curious to hear what
tools you want to use. At least libxml2 supports RELAX NG natively.
The Python lxml library uses that support to provide pretty simple
RELAX NG validation. libxml2 does not have native compact syntax
support, but I maintain a simple library called rnc2rng [4] that is
used transparently by lxml if installed. rnc2rng also comes with a
rnc2rng command-line script to do the conversion.

- Performance: in a quick test with lxml (backed by libxml2), RELAX NG
validation takes very similar time compared to DTD. Testing with
~19000 metadata.xml files in the tree, with DTD (best of 3):

real0m2.861s
user0m2.560s
sys0m0.296s

With RNC (best of 3):

real0m3.058s
user0m2.688s
sys0m0.364s

We could probably easily maintain an XML Schema shadow schema if
that's really desired, but I would be in favor of making RELAX NG our
main schema language. I can easily do the work to update repoman for
this (I've already refactored the metadata code in repoman). What
other stuff would need to be updated?

Comments?

Cheers,

Dirkjan

[1] https://github.com/djc/gentoo-data-dtd/blob/metadata-rnc/metadata.dtd
[2] https://www.tbray.org/ongoing/When/200x/2006/11/27/Choose-Relax
[3] https://github.com/djc/gentoo-data-dtd/blob/metadata-rnc/metadata.rnc
[4] https://github.com/djc/rnc2rng

[gentoo-dev] Last rites: app-eselect/eselect-maven

[James Le Cuirot]

# James Le Cuirot  (26 Jan 2016)
# Now part of eselect-java. Removal in 30 days.
app-eselect/eselect-maven

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp61k0Nno5iP.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-cdr/webcdwriter

[James Le Cuirot]

# James Le Cuirot  (26 Jan 2016)
# No new release since 2008. Removal in 30 days.
app-cdr/webcdwriter

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpk42l6SqYNs.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] New schema language for metadata validation?

[Michael Orlitzky]

On 01/26/2016 02:52 PM, Dirkjan Ochtman wrote:
> All,
> 
> TL;DR: I think we should switch from DTD to RELAX NG (compact syntax,
> ideally) for our XML validation needs. It is more expressive and more
> readable.
> 

A great idea.


> What other stuff would need to be updated?
> 

I would appreciate examples of some common tasks like validating
projects.xml, but since we don't have those now, it's not critical.
This used to be kinda straightforward with xmllint,

  $ xmllint --valid --noout projects.xml && echo "OK"

but now that www.gentoo.org is on HTTPS, even that doesn't work. There's
an example in the devmanual that needs updating along those lines (at
the bottom of the page). In fact, all of the herds junk needs to be updated:

  https://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/

Our DTDs are available under https://www.gentoo.org/dtd/ -- do we need
to put the rnc files somewhere accessible? Or do we only need the DTDs
public for the DOCTYPE declarations?

Thanks for preemptively hacking repoman.

Re: [gentoo-dev] Last rites: app-cdr/webcdwriter

[Peter Stuge]

James Le Cuirot wrote:
> # James Le Cuirot  (26 Jan 2016)
> # No new release since 2008. Removal in 30 days.
> app-cdr/webcdwriter

Is there a problem with it? I don't use it and have no interest in
this particular package but merely lack of release is not a valid
reason to remove the ebuild if everything else is all right. If it
isn't, then maybe that needs to be added to the lastrite comment?


Thanks

//Peter


pgprQTyDGc8bT.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-dev-announce] GLEP 67 is in, please update your metadata.dtd!

[Michał Górny]

Hello again,

On Mon, 25 Jan 2016 10:37:15 +0100
Michał Górny  wrote:

> Please note that the metadata.dtd is unable to correctly enforce
> obligatory type="" attribute on maintainers. Please make sure to add
> it. I will be adding pkgcheck/repoman checks for that soon.

As requested by a number of developers, I have reverted the DTD change
blocking  elements in order to provide additional transition
period.

The support for , as well as herds.xml and herds.dtd, will be
removed no earlier than 2 weeks from now. Please use that time to
update metadata.xml in your repositories.

While at it, I've added three GLEP 67-related checks to gentoo-ci.
Therefore, the metadata.xml files in Gentoo repository and pull
requests will be periodically checked for the following problems:

1.  elements,

2.  elements with no type="" (invalid is already covered
by the DTD),

3.  referencing projects not
in projects.xml.

-- 
Best regards,
Michał Górny



pgpve67Pq3v1k.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: app-cdr/webcdwriter

[James Le Cuirot]

On Tue, 26 Jan 2016 21:55:15 +0100
Peter Stuge  wrote:

> James Le Cuirot wrote:
> > # James Le Cuirot  (26 Jan 2016)
> > # No new release since 2008. Removal in 30 days.
> > app-cdr/webcdwriter  
> 
> Is there a problem with it? I don't use it and have no interest in
> this particular package but merely lack of release is not a valid
> reason to remove the ebuild if everything else is all right. If it
> isn't, then maybe that needs to be added to the lastrite comment?

I must admit that I had to think twice about this one given its unusual
nature. The overriding factor is that there is tons of dead Java
software in the tree and we're struggling to even keep up with the live
stuff. We're therefore trimming the fat down to a more manageable size.
This package was brought to my attention because bugs had been assigned
to the optical media herd, which has now been disbanded. There are only
3 open bugs, none of them serious, but apart from the lack of releases,
I considered several points:

 * It's presented as a Java web applet or web start application.
   Applets are all but outlawed these days. Web start isn't dead and
   you don't strictly need a browser to use it but this isn't exactly a
   popular way to launch applications.

 * I'd be very dubious of the security around something like this. Even
   actively maintained software has seen tons of security
   vulnerabilities lately, not least in the Java space.

 * Optical media is on the decline. My main development machine doesn't
   even have a burner any more so I can't easily test it.

 * It was designed around cdrecord, which has seen many new releases
   since then and may not be entirely compatible any more. The cdrkit
   fork (which I use) may also have similar issues. I'll admit this is
   purely speculation on my part.

 * It's fugly. ;) Seriously, no one like Java's Swing and even Oracle
   and co have put it on life support, fixing critical bugs only.

 * The ebuild doesn't look like much fun. The project uses autotools,
   which is rarely a good thing in Java land.

 * There may be cleaner ways to achieve the same goal. If it were me,
   I'd try ATA over Ethernet with regular burning software, though I'm
   not entirely sure it would work.

Am I off the hook now? ;)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpMBPMkA3sJZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Michał Górny]

Dnia 26 stycznia 2016 13:36:00 CET, Davide Pesavento  
napisał(a):
>On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher  wrote:
>> Signed-off-by: Justin Lecher 
>> ---
>>  eclass/cmake-utils.eclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> index 01de9a5..23339ab 100644
>> --- a/eclass/cmake-utils.eclass
>> +++ b/eclass/cmake-utils.eclass
>> @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
>>  # for econf and is needed to pass TRY_RUN results when
>cross-compiling.
>>  # Should be set by user in a per-package basis in
>/etc/portage/package.env.
>>
>> -case ${EAPI} in
>> +case ${EAPI:-0} in
>> 2|3|4|5|6) : ;;
>> *) die "EAPI=${EAPI:-0} is not supported" ;;
>>  esac
>> --
>> 2.7.0
>>
>
>Why?

Indeed, why? I think it would be cleaner to simply quote the parameter to case.


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

Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0

[Davide Pesavento]

On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher  wrote:
> Signed-off-by: Justin Lecher 
> ---
>  eclass/cmake-utils.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 01de9a5..23339ab 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
>  # for econf and is needed to pass TRY_RUN results when cross-compiling.
>  # Should be set by user in a per-package basis in /etc/portage/package.env.
>
> -case ${EAPI} in
> +case ${EAPI:-0} in
> 2|3|4|5|6) : ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> --
> 2.7.0
>

Why?