Re: [gentoo-dev] RFC: Eclasses and EAPI

[Rich Freeman]

On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz  wrote:
> Kristian Fiskerstrand  writes:
>> inherited eclasses. having a whitelist in place and die if eclass is not
>> updated to handle it solves it.
>>
>> Thoughts? comments? cookies? threats?
>
> Wouldn't a blacklist be more practical than a whitelist?
>
>   root# cat /usr/portage/profiles/eclass.eapi.mask
>
>   fooutils.eclass >=6
>
> The problem seems infrequent enough that a blacklist is sufficient, like
> all the *.mask files in /usr/portage/profiles.
>
> The whitelist places a large testing burden on eclass authors on each
> EAPI bump, where 99% of the time there won't be any issue to fix.

A few things:

1.  Your syntax assumes that EAPIs are ordered (I'll let the
mathematicians go on about set theory).  Nothing about PMS requires
this, the next one could be "2B," or "Fred," or "."  (Apologies on
the last one if it doesn't come through, as I have no idea how UTF-8
safe email actually is.)  I don't think it is likely, but I know
somebody else will point it out if I don't.
2.  I think that requiring eclasses to be reviewed before use on a new
EAPI is a feature, and not a bug.  It is a trivial update if it is
fine, and depending on the nature of the eclass it might be trivial to
determine if there will be a problem.  If it isn't trivial to
determine if there is a problem, it is probably even more important
that it be reviewed.
3.  The whole problem driving this is people using EAPIs with eclasses
without realizing they fail in subtle ways.  If they're unmaintained,
this is even more likely to happen, and all the more reason to expose
the problem.  It is better to expose problems during design than at
runtime.
4.  EAPIs seem to come out about every other year right now.  Is it
really THAT hard to keep up with them?  And eclasses which fall behind
should probably be candidates for treecleaning anyway.

-- 
Rich

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Erik Mackdanz]

Kristian Fiskerstrand  writes:
> inherited eclasses. having a whitelist in place and die if eclass is not
> updated to handle it solves it.
>
> Thoughts? comments? cookies? threats?

Wouldn't a blacklist be more practical than a whitelist?

  root# cat /usr/portage/profiles/eclass.eapi.mask

  fooutils.eclass >=6

The problem seems infrequent enough that a blacklist is sufficient, like
all the *.mask files in /usr/portage/profiles.

The whitelist places a large testing burden on eclass authors on each
EAPI bump, where 99% of the time there won't be any issue to fix.

Erik

[gentoo-dev] Re: [gentoo-project] Call for agenda items - Council meeting 2016-09-11

[Kristian Fiskerstrand]

On 09/03/2016 05:17 PM, Rich Freeman wrote:
> Dear all,
> 
> the Gentoo Council will meet again on Sunday, September 11th at 19:00 UTC
> in #gentoo-council on FreeNode.
> 
> Please reply to this message on the gentoo-project list with any items
> the council should put on its agenda to discuss or vote on.
> 

Since we don't have any other non-standard agenda item I'd like to bring
up [RFC: Eclasses and EAPI] at this meeting already. If someone believe
it hasn't been sufficiently discussed on the dev ML we can postpone any
vote for next meeting, but we can at least talk about it and decide on
whether we're sufficiently informed for a vote at the meeting.


References:
[RFC: Eclasses and EAPI]
https://archives.gentoo.org/gentoo-dev/message/87e630b9da724c5c59060608aba596a9

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Eclasses and EAPI

[Michał Górny]

On Tue, 6 Sep 2016 09:19:42 -0400
Rich Freeman  wrote:

> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  wrote:
> >
> > I believe you're overthinking it, if we make it a guideline to include a
> > section of the eclass (as many already have) that does e.g (take this
> > for example purposes) there is no EAPI/PMS change needed
> > case "${EAPI:-0}" in
> > 4|5|6)
> > ;;
> >  *) die "EAPI=${EAPI} is not supported" ;;
> >  
> 
> I think the question becomes then what do we do about eclasses that
> don't follow the guideline?
> 
> With a PMS change we can in the future enforce that the eclass
> explicitly declare support by making it break by default if nothing is
> done.  With the approach above an eclass works with any EAPI by
> default as far as PMS is concerned, and we rely on eclasses to
> self-destruct when they're supposed to.

PMS is there to solve the technical problem of compatibility between
ebuilds and package managers, and you sound like you want to use it to
solve a social problem.

If we can agree on a policy adding a check like this, then enforcing it
should be a minor problem. Of course, it can become a problem with
the usual developers who know better and are going to refuse to comply
but again, this is a social problem.

Adding additional layer of complexity and enforcing the policy via PMS
sounds like you want to enforce the policy one level higher, so that
the developers would find it harder to reject it. Does that really
sound like the way to solve the problem?

-- 
Best regards,
Michał Górny



pgpiFCCwDk2_v.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 03:38 PM, M. J. Everitt wrote:
> On 06/09/16 14:35, Kristian Fiskerstrand wrote:
>> On 09/06/2016 03:19 PM, Rich Freeman wrote:
>>> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  
>>> wrote:
 I believe you're overthinking it, if we make it a guideline to include a
 section of the eclass (as many already have) that does e.g (take this
 for example purposes) there is no EAPI/PMS change needed
 case "${EAPI:-0}" in
 4|5|6)
 ;;
  *) die "EAPI=${EAPI} is not supported" ;;

>>> I think the question becomes then what do we do about eclasses that
>>> don't follow the guideline?
>> A natural step might be QA team involved in such cases?
>>
> Did you just volunteer to join QA there, Kristian ?! ;)
> 

hehe :) If they want me to contribute there they can ask. I'm certainly
not fundamentally opposed, but I believe they overall have a good
project going already so I'm allocating my (sadly resource constrained)
Gentoo-time elsewhere.

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 03:19 PM, Rich Freeman wrote:
> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand  wrote:
>>
>> I believe you're overthinking it, if we make it a guideline to include a
>> section of the eclass (as many already have) that does e.g (take this
>> for example purposes) there is no EAPI/PMS change needed
>> case "${EAPI:-0}" in
>> 4|5|6)
>> ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>>
> 
> I think the question becomes then what do we do about eclasses that
> don't follow the guideline?

A natural step might be QA team involved in such cases?

-- 
Kristian Fiskerstrand
OpenPGP certificate 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: Eclasses and EAPI

[Kristian Fiskerstrand]

On 09/06/2016 12:44 PM, Kent Fredric wrote:
> On Mon, 5 Sep 2016 15:03:36 +0200
> Michał Górny  wrote:
> 
>> On Fri, 2 Sep 2016 18:13:20 +0200
>> Kristian Fiskerstrand  wrote:
>>
>>> I'm wondering whether it wouldn't make sense to require eclasses (or
>>> strongly encourage) to include an explicit list of EAPIs it has been
>>> tested for in order to ease testing when introducing new EAPIs.
>>>
>>> We have seen some issues already with EAPI6 bump related to get_libdir
>>> and people updating EAPI in ebuild without properly testing the
>>> inherited eclasses. having a whitelist in place and die if eclass is not
>>> updated to handle it solves it.
>>>
>>> Thoughts? comments? cookies? threats?  
>>
>> +1. Because:
>>
>> 1. it makes it possible to change API safely with EAPI bump, including
>> major refactorings,
>>
>> 2. it makes it possible for the eclass maintainer to confirm that
>> the eclass is correctly ported to new EAPI, rather than some random
>> developer with poor knowledge of eclass assuming it works fine,
>>
>> 3. it makes it possible to ban the eclass in a new EAPI to more
>> effectively phase it out.
>>
>> This only reminds me of the cases when eclasses weren't calling
>> eapply_user in EAPI 6 and caused ebuilds to fail. Because someone
>> assumed that if his ebuild works in EAPI 6, then the eclass is
>> certainly correct.
>>
> 
> My only question is how we enforce it.
> 
> Given that eclasses are themselves without EAPI, and relying on this
> check existing in PMS would require such a feature defined in a future EAPI
> 
> I suspect for the forseeable future we're going to need to double our effort,
> having a whitelist that is only able to be interpreted by PMS clients that 
> implement
> EAPI7, and then the traditional logic for Pre-EAPI7.
> 

I believe you're overthinking it, if we make it a guideline to include a
section of the eclass (as many already have) that does e.g (take this
for example purposes) there is no EAPI/PMS change needed
case "${EAPI:-0}" in
4|5|6)
;;
 *) die "EAPI=${EAPI} is not supported" ;;



-- 
Kristian Fiskerstrand
OpenPGP certificate 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] recommended way to get gcc-6 for testing packages

[Paweł Hajdan , Jr .]

On 05/09/16 13:07, Joshua Kinard wrote:
> On 08/31/2016 17:28, Paweł Hajdan, Jr. wrote:
>> gcc-6 doesn't seem to be in portage.
> It's in the hardened-development overlay.  You can use layman to install the
> overlay, then test out gcc-6.2.x.  Already found a bug related to mips 
> myself, heh.

Okay. I'll probably take a look.

Why not add it to portage, unkeyworded or something?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Eclasses and EAPI

[Kent Fredric]

On Mon, 5 Sep 2016 15:03:36 +0200
Michał Górny  wrote:

> On Fri, 2 Sep 2016 18:13:20 +0200
> Kristian Fiskerstrand  wrote:
> 
> > I'm wondering whether it wouldn't make sense to require eclasses (or
> > strongly encourage) to include an explicit list of EAPIs it has been
> > tested for in order to ease testing when introducing new EAPIs.
> > 
> > We have seen some issues already with EAPI6 bump related to get_libdir
> > and people updating EAPI in ebuild without properly testing the
> > inherited eclasses. having a whitelist in place and die if eclass is not
> > updated to handle it solves it.
> > 
> > Thoughts? comments? cookies? threats?  
> 
> +1. Because:
> 
> 1. it makes it possible to change API safely with EAPI bump, including
> major refactorings,
> 
> 2. it makes it possible for the eclass maintainer to confirm that
> the eclass is correctly ported to new EAPI, rather than some random
> developer with poor knowledge of eclass assuming it works fine,
> 
> 3. it makes it possible to ban the eclass in a new EAPI to more
> effectively phase it out.
> 
> This only reminds me of the cases when eclasses weren't calling
> eapply_user in EAPI 6 and caused ebuilds to fail. Because someone
> assumed that if his ebuild works in EAPI 6, then the eclass is
> certainly correct.
> 

My only question is how we enforce it.

Given that eclasses are themselves without EAPI, and relying on this
check existing in PMS would require such a feature defined in a future EAPI

I suspect for the forseeable future we're going to need to double our effort,
having a whitelist that is only able to be interpreted by PMS clients that 
implement
EAPI7, and then the traditional logic for Pre-EAPI7.

And then when EAPI7 rolls around, all the eclasses without the EAPI7 magic hints
will be assumed "not to support EAPI7+"

And to support EAPI7, you must declare your support for the other EAPIs too.

Though I never figured it was a question of "should we", we rather should.

Only a question of "How do we do it"


pgpHuUuISyqg1.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: sys-block/eject

[Lars Wendler]

Dead upstream since 2013. Superseded by eject from sys-apps/util-linux.

Slated for removal in 30 days.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpacC2d8Ws1q.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs

[Alice Ferrazzi]

interested in euscan
I'm using it in one of my server.
but I'm away untill 14 of this month.

2016/08/07 18:27 "Patrick Lauer" :

> On 08/07/2016 10:12 AM, Dirkjan Ochtman wrote:
> > On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos  wrote:
> >> This packages are now up for grabs:
> >> app-portage/euscan
> >
> > Patrick,
> >
> > Are you still keeping euscan running?
> >
>
> Yes. It's not in the best shape, but for now it works well enough to
> keep it around.
>
>
>

Re: [gentoo-dev] Re: RFC: Eclasses and EAPI

[Alexis Ballier]

On Tue, 6 Sep 2016 02:50:51 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> PMFJI, but either I'm not understanding either, or mgorny did
> understand, but is looking at it from a different perspective, that
> being the eclass maintainer's perspective, and thus seeing an
> angle/problem you didn't cover in your example.
> 
> Here's the problem.  If an eclass hasn't been ported to a new EAPI,
> then it's reasonable for the eclass maintainer to assume that no
> ebuilds inheriting it should have been ported to that EAPI either.


These cases can, of course, be marked as suggested in the initial post.
The example I wrote even broke in most cases when using the new EAPI,
providing an even more objective case pro-dying.
All are perfectly valid cases, but nothing shows it has to be the norm.

[...]
> Did I get that correct, mgorny, or am I too not understanding,
> aballier?


There is a huge gap between what you wrote and 'let's commit crap and
hope it will work; worst case, things will go horribly kaboom on
users'.