autotools.eclass no longer inherits eutils; check your ebuilds!
 

On May 20, autools.eclass was changed to no longer inherit eutils, see
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134

Relying on autotools.eclass for your eutils needs was always a terrible
idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
since they can no longer use epatch. See bug #416847 for an example.

Check your ebuilds to make sure you inherit eutils in anything that uses
epatch!

-Alexandre Rostovtsev.

autotools.eclass no longer inherits eutils; check your ebuilds!
 

El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
> On May 20, autools.eclass was changed to no longer inherit eutils, see
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>
> Relying on autotools.eclass for your eutils needs was always a terrible
> idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
> since they can no longer use epatch. See bug #416847 for an example.
>
> Check your ebuilds to make sure you inherit eutils in anything that uses
> epatch!
>
> -Alexandre Rostovtsev.
>
>
>

Looks like ebuilds not inheriting eutils directly even using epatch are
a lot as I have seen running:
grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
eutils

Maybe they should be checked and a repoman warning should be added when
an ebuild is using epatch without inheriting eutils directly, otherwise
this problem could reappear if some other eclass no longer inherit it in
the future :-/

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On 05/21/2012 12:04 PM, Pacho Ramos wrote:
> El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
>> On May 20, autools.eclass was changed to no longer inherit eutils, see
>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>>
>> Relying on autotools.eclass for your eutils needs was always a terrible
>> idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
>> since they can no longer use epatch. See bug #416847 for an example.
>>
>> Check your ebuilds to make sure you inherit eutils in anything that uses
>> epatch!
>>
>> -Alexandre Rostovtsev.
>>
>>
>>
>
> Looks like ebuilds not inheriting eutils directly even using epatch are
> a lot as I have seen running:
> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> eutils
>
> Maybe they should be checked and a repoman warning should be added when
> an ebuild is using epatch without inheriting eutils directly, otherwise
> this problem could reappear if some other eclass no longer inherit it in
> the future :-/

Yeah, we have a similar check for inherit of prefix.eclass:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b583812101f1156c553385effcd 9dbee0b751087
--
Thanks,
Zac

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On Monday 21 May 2012 15:04:44 Pacho Ramos wrote:
> El lun, 21-05-2012 a las 13:46 -0400, Alexandre Rostovtsev escribió:
> > On May 20, autools.eclass was changed to no longer inherit eutils, see
> > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.
> > eclass?r1=1.133&r2=1.134
> >
> > Relying on autotools.eclass for your eutils needs was always a terrible
> > idea, but a few ebuilds did it anyway. Those ebuilds are now *broken*
> > since they can no longer use epatch. See bug #416847 for an example.
> >
> > Check your ebuilds to make sure you inherit eutils in anything that uses
> > epatch!
>
> Looks like ebuilds not inheriting eutils directly even using epatch are
> a lot as I have seen running:
> grep inherit $(grep -r epatch */*/*.ebuild| cut -d: -f1) | grep -v
> eutils

this is what i was using:
find /usr/portage/*-* -name '*.ebuild' -exec grep -l '<epatch>' {} + |
xargs grep -L inherit.*eutils

there's quite a number there :(

> Maybe they should be checked and a repoman warning should be added when
> an ebuild is using epatch without inheriting eutils directly, otherwise
> this problem could reappear if some other eclass no longer inherit it in
> the future :-/

yeah, a repoman check would be a really good idea
-mike

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On 05/21/2012 06:46 PM, Alexandre Rostovtsev wrote:
> On May 20, autools.eclass was changed to no longer inherit eutils,
> see
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/autotools.eclass?r1=1.133&r2=1.134
>
>
>
Relying on autotools.eclass for your eutils needs was always a
> terrible idea, but a few ebuilds did it anyway. Those ebuilds are
> now *broken* since they can no longer use epatch. See bug #416847
> for an example.
>
> Check your ebuilds to make sure you inherit eutils in anything
> that uses epatch!
>
> -Alexandre Rostovtsev.
>
>
Excuse me but the way this change was handled is a bit depressing.
First, the ebuilds should have been fixed to inherit eutils and then
remove eutils from autotools. Now, a bunch of ebuilds are broken out
of nowhere. I don't believe this issue was that urgent in order to
justify the significant breakage of portage tree.

--
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
> Excuse me but the way this change was handled is a bit depressing.
> First, the ebuilds should have been fixed to inherit eutils and then
> remove eutils from autotools. Now, a bunch of ebuilds are broken out
> of nowhere. I don't believe this issue was that urgent in order to
> justify the significant breakage of portage tree.

you're assuming the breakage was intentional. i also wouldn't really describe
it as "significant", but that's just quibbling over an insignificant aspect.

but what's done is done. fix the ebuilds and move on.
-mike

autotools.eclass no longer inherits eutils; check your ebuilds!
 

2012/5/22 Mike Frysinger <vapier@gentoo.org>:
> On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
>> Excuse me but the way this change was handled is a bit depressing.
>> First, the ebuilds should have been fixed to inherit eutils and then
>> remove eutils from autotools. Now, a bunch of ebuilds are broken out
>> of nowhere. I don't believe this issue was that urgent in order to
>> justify the significant breakage of portage tree.
>
> you're assuming the breakage was intentional. *i also wouldn't really describe
> it as "significant", but that's just quibbling over an insignificant aspect.

It's intentional not to revert the change, it's significant because it
involve a number of significant packages like icu, vim and boost, some
of them already marked stable (from a fast grep from the one mentioned
in the previous posts).

> but what's done is done. *fix the ebuilds and move on.
> -mike

revert - fix the ebuilds - re-apply could work too, or since you're an
old and respected developer fix them yourself, the change is easy and
probably mantainers will understand.

Francesco R.

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
> 2012/5/22 Mike Frysinger:
> > On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
> >> Excuse me but the way this change was handled is a bit depressing.
> >> First, the ebuilds should have been fixed to inherit eutils and then
> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out
> >> of nowhere. I don't believe this issue was that urgent in order to
> >> justify the significant breakage of portage tree.
> >
> > you're assuming the breakage was intentional. i also wouldn't really
> > describe it as "significant", but that's just quibbling over an
> > insignificant aspect.
>
> It's intentional not to revert the change, it's significant because it
> involve a number of significant packages like icu, vim and boost, some
> of them already marked stable (from a fast grep from the one mentioned
> in the previous posts).

you've identified the broke things. so fix them.
-mike

autotools.eclass no longer inherits eutils; check your ebuilds!
 

2012/5/22 Mike Frysinger <vapier@gentoo.org>:
> On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
>> 2012/5/22 Mike Frysinger:
>> > On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
>> >> Excuse me but the way this change was handled is a bit depressing.
>> >> First, the ebuilds should have been fixed to inherit eutils and then
>> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out
>> >> of nowhere. I don't believe this issue was that urgent in order to
>> >> justify the significant breakage of portage tree.
>> >
>> > you're assuming the breakage was intentional. *i also wouldn't really
>> > describe it as "significant", but that's just quibbling over an
>> > insignificant aspect.
>>
>> It's intentional not to revert the change, it's significant because it
>> involve a number of significant packages like icu, vim and boost, some
>> of them already marked stable (from a fast grep from the one mentioned
>> in the previous posts).
>
> you've identified the broke things. *so fix them.
> -mike

wanna give me commit access for few hours?
I've already done mass changes to the tree when introducing
virtual/mysql seem something doable the same way.

autotools.eclass no longer inherits eutils; check your ebuilds!
 

On Monday 21 May 2012 19:24:27 Francesco Riosa wrote:
> 2012/5/22 Mike Frysinger:
> > On Monday 21 May 2012 19:01:04 Francesco Riosa wrote:
> >> 2012/5/22 Mike Frysinger:
> >> > On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
> >> >> Excuse me but the way this change was handled is a bit depressing.
> >> >> First, the ebuilds should have been fixed to inherit eutils and then
> >> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out
> >> >> of nowhere. I don't believe this issue was that urgent in order to
> >> >> justify the significant breakage of portage tree.
> >> >
> >> > you're assuming the breakage was intentional. i also wouldn't really
> >> > describe it as "significant", but that's just quibbling over an
> >> > insignificant aspect.
> >>
> >> It's intentional not to revert the change, it's significant because it
> >> involve a number of significant packages like icu, vim and boost, some
> >> of them already marked stable (from a fast grep from the one mentioned
> >> in the previous posts).
> >
> > you've identified the broke things. so fix them.
>
> wanna give me commit access for few hours?

just join as a dev and get it over with ;P

> I've already done mass changes to the tree when introducing
> virtual/mysql seem something doable the same way.

seems people have already fixed most (if not all) errors related to
autotools.eclass
-mike