Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Krzysztof Pawlik]

On 22/05/12 07:58, Hans de Graaff wrote:
> On Mon, 2012-05-21 at 21:50 -0500, Donnie Berkholz wrote:
>> On 16:27 Sun 13 May , Mike Gilbert wrote:
>>> To make ebuilds utilizing python-distutils-ng.eclass usable
>>
>> I didn't read any farther because I couldn't stop laughing. What will 
>> the next version of this eclass be called, -ng-ng? -really-ng? =)
> 
> Given that Diego named the original ruby-ng eclass I would assume it
> would be ruby-voyager, or python-distutils-voyager.

ruby-enterprise and python-distutils-enterprise ;)

We can also go the Borland way and have ruby-turbo & python-disutils-turbo.

-- 
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Adding PYTHON_TARGETS=python2_7 to base profile

[Ryan Hill]

On Mon, 21 May 2012 21:50:33 -0500
Donnie Berkholz  wrote:

> On 16:27 Sun 13 May , Mike Gilbert wrote:
> > To make ebuilds utilizing python-distutils-ng.eclass usable
> 
> I didn't read any farther because I couldn't stop laughing. What will 
> the next version of this eclass be called, -ng-ng? -really-ng? =)

-ds9


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Hans de Graaff]

On Mon, 2012-05-21 at 21:50 -0500, Donnie Berkholz wrote:
> On 16:27 Sun 13 May , Mike Gilbert wrote:
> > To make ebuilds utilizing python-distutils-ng.eclass usable
> 
> I didn't read any farther because I couldn't stop laughing. What will 
> the next version of this eclass be called, -ng-ng? -really-ng? =)

Given that Diego named the original ruby-ng eclass I would assume it
would be ruby-voyager, or python-distutils-voyager.

Kind regards,

Hans


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Michał Górny]

On Mon, 21 May 2012 23:16:25 +0100
Markos Chandras  wrote:

> 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.

First of all, to quote devmanual:

| Before updating eutils or a similar widely used eclass, it is best to
| email the gentoo-dev list. It may be that your proposed change is
| broken in a way you had not anticipated> [...]. If you don't email
| gentoo-dev first, and end up breaking something, expect to be in a
| lot of trouble.

Not that this disrespect for this rule is something new...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] GCC 4.6.* unmasked, 4.7.0 added to tree

[Ryan Hill]

I've added 4.7.0 to the tree tonight (unkeyworded and masked as usual).

I've also keyworded the 4.6 series on all arches except amd64 (due to the
grub bug).  This is a temporary measure until we figure out the best course of
action (at least we have some people looking at the problem now).

I personally apologize for the extremely long delay in getting these releases
out in a timely manner.  As such, I'm stepping down as GCC maintainer.
Someone with as limited free time and programming experience as myself has
no business maintaining a such core piece of a source-based distro.

Sorry to dump even more on your shoulders Mike, but really I haven't been
helping out much this past year anyways.  I'll still be doing gcc-porting and
hunting down patches like I used to.

Thanks guys.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile

[Donnie Berkholz]

On 16:27 Sun 13 May , Mike Gilbert wrote:
> To make ebuilds utilizing python-distutils-ng.eclass usable

I didn't read any farther because I couldn't stop laughing. What will 
the next version of this eclass be called, -ng-ng? -really-ng? =)

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgpIBXHy7OxqK.pgp
Description: PGP signature

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

[Mike Frysinger]

On Sunday 20 May 2012 19:24:13 hasufell wrote:
>   case ${2} in

please use $1/$2/etc... with positional variables when possible

>   16|22|24|32|36|48|64|72|96|128|192|256)
>   size=${2}x${2};;
>   
> 16x16|22x22|24x24|32x32|36x36|48x48|64x64|72x72|96x96|128x128|
192x192|256x256)
>   size=${2};;
>   scalable)
>   size=scalable;;
>   *)
>   eqawarn "${2} is an unsupported icon size!"
>   ((++ret));;
>   esac

you can write this w/out having to duplicate two lists:
size=
if [[ $2 == "scalable" ]] ; then
size=$2
elif [[ ${2:0:2}x${2:0:2} == "$2" ]] ; then
size=${2:0:2}
case ${size} in
16|22|24|32|36|48|64|72|96|128|192|256) ;;
*) size= ;;
esac
fi
if [[ -z ${size} ]] ; then
eqawarn "${2} is an unsupported icon size!"
((++ret))
fi
shift 2

shift 2;;
-t|--theme)
theme=${2}
shift 2;;
-c|--context)
context=${2}
shift 2;;
*)
>   if [[ -z ${size} ]] ; then
>   dir=/usr/share/pixmaps
>   else
>   dir=/usr/share/icons/${theme}/${size}/${context}
>   fi
>   
>   insinto "${dir}"

considering you only use $dir once, you could just call `insinto` directly on 
the path rather than using the dir variable at all

>   elif [[ -d ${1} ]] ; then
>   for i in "${1}"/*.{png,svg} ; do
>   doins "${i}"
>   ((ret+=$?))
>   done

why loop ?  `doins "${1}"/*.{png,svg}` works just as well

you probably want to enable nullglobbing here, otherwise this will cause 
problems if you try to doicon on a dir that contains just svg.

also, what about other file types ?  people install xpm, svgz, gif, and other 
file types ...

>   exit ${ret}

bash masks error codes to [0..255], so all the ret updates should probably be 
changed to just: ret=1

after all, i doubt anyone cares how many errors there were, just that one 
occurred.  and while you're here, might want to make it auto die on failure 
like we've done with all our other helpers.
-mike


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

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

[Mike Frysinger]

On Monday 21 May 2012 15:58:24 hasufell wrote:
> On 05/21/2012 07:14 PM, Michał Górny wrote:
> > On Mon, 21 May 2012 01:24:13 +0200 hasufell wrote:
> >> I want support for installing icons into the appropriate
> >> directories which are under /usr/share/icons/... and not just
> >> pixmaps.
> >> 
> >> proposal attached + diff
> >> 
> >> This should not break existing ebuilds. Tested a bit and open
> >> for review now.
> > 
> > I'd rather see a new function for that rather than making doicon()
> > overcomplex.
> 
> The new features are totally optional, so there is nothing complex. If
> someone is looking for support for /usr/share/icons/... directories
> without setting insinto he can have it.
> 
> doicon/newicon without options (should) behave exactly the same way.

i think he's talking about the actual implementation details (and yes, the 
duplication of content should be solved rather than copying & pasting the guts 
-- someone suggested a good fix for that) and the extended option set (which i 
think we can live with).
-mike


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Arfrever Frehtes Taifersar Arahesis]

2012-05-22 01:01:04 Francesco Riosa napisał(a):
> 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

These packages are not involved:

dev-libs/icu ebuilds do not inherit autotools.eclass.
An older ebuild (icu-4.8.1.1-r1.ebuild) inherits eutils.eclass only through 
versionator.eclass.

app-editors/vim ebuilds do not inherit autotools.eclass, and inherit vim.eclass,
which inherits eutils.eclass.

dev-libs/boost ebuilds do not inherit autotools.eclass, and inherit 
check-reqs.eclass,
flag-o-matic.eclass and versionator.eclass, which inherit eutils.eclass.

-- 
Arfrever Frehtes Taifersar Arahesis


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Francesco Riosa]

2012/5/21 Mike Frysinger :
> 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

maybe gentoo will live better w/o my fat typeing hands :-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

Seem to be the better outcome.  If someone could fix the remaining
unfixed after x days that would be perfect, it's always unpleasant to
touch other devs ebuilds but sometimes is just the only thing to do
(replace with some philosophy mumble at pleasure;-)

good night and thanks for answering

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Mike Frysinger]

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


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Francesco Riosa]

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.
> -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.

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[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.
-mike


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Francesco Riosa]

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).

> 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.

Re: [gentoo-dev] Do we need games group and all that game prefixes?

[Walter Dnes]

On Mon, May 21, 2012 at 10:26:14AM +0300, Samuli Suominen wrote

> I suppose you mean the "XFree86-DGA extension", USE="dga"?
> 
> $ cd $(portageq envvar PORTDIR)
> $ grep -r IUSE.*dga */*/*.ebuild
> 
> http://qa-reports.gentoo.org/output/genrdeps/rindex/x11-libs/libXxf86dga
> 
> But I fail to see how that is relavent with this thread at all, using 
> the extension is controlled by the xorg-server (Xorg) which is suid root 
> and unrelated to 'games' (despite being used by some).

  It was more along the lines of svgalib.  See...
http://linux.die.net/man/7/svgalib  Is that even in the tree anymore?
If not, that's one less reason to keep games special.

-- 
Walter Dnes 

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[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.

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


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Markos Chandras]

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

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

[hasufell]

On 05/21/2012 07:14 PM, Michał Górny wrote:
> On Mon, 21 May 2012 01:24:13 +0200 hasufell 
> wrote:
> 
>> I want support for installing icons into the appropriate
>> directories which are under /usr/share/icons/... and not just
>> pixmaps.
>> 
>> proposal attached + diff
>> 
>> This should not break existing ebuilds. Tested a bit and open
>> for review now.
> 
> I'd rather see a new function for that rather than making doicon() 
> overcomplex.
> 

The new features are totally optional, so there is nothing complex. If
someone is looking for support for /usr/share/icons/... directories
without setting insinto he can have it.

doicon/newicon without options (should) behave exactly the same way.

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Mike Frysinger]

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 '\' {} + | \
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


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

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Zac Medico]

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=b583812101f1156c553385effcd9dbee0b751087
-- 
Thanks,
Zac

Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Pacho Ramos]

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 :-/


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

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Alexandre Rostovtsev]

On Mon, 2012-05-21 at 13:29 -0400, Mike Frysinger wrote:
> On Monday 21 May 2012 12:08:21 Alexandre Rostovtsev wrote:
> > Realistically, every Gentoo machine, with the exception of pure deployment
> > installations that don't build any packages (and therefore don't care about
> > autotools.eclass anyway), already has intltool installed.
> 
> extending the set of machines that you care about to include all setups is 
> obviously wrong (i certainly have machines that "build packages" that don't 
> have intltool installed).  and even if that wasn't true, it'd be entirely 
> irrelevant.  spurious dependencies are not acceptable.
> -mike

I apologize; I must have run "equery d intltool" while experimenting
with a patched autotools.eclass, and that led me to grossly overestimate
the number of packages depending on intltool.

So you are correct, many Gentoo machines do not have any reason to have
intltool installed.

-Alexandre.

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Mike Frysinger]

On Monday 21 May 2012 02:41:18 Alexandre Rostovtsev wrote:
> On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote:
> > i've extended eautoreconf to automatically call autopoint when the
> > package uses gettext.  the configure check might seem naïve, but this is
> > how autoreconf itself does it.  this hopefully shouldn't break any
> > packages (at least, none that weren't already broken), but if you guys
> > start seeing eautoreconf failures where there were none before, feel
> > free to cc base-system. -mike
> > 
> > --- autotools.eclass
> > +++ autotools.eclass
> > @@ -162,6 +162,9 @@ eautoreconf() {
> > 
> > einfo "Running eautoreconf in '${PWD}' ..."
> > [[ -n ${auxdir}${macdir} ]] && mkdir -p ${auxdir} ${macdir}
> > eaclocal
> > 
> > +   if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
> > +   eautopoint --force
> > +   fi
> > 
> > [[ ${CHOST} == *-darwin* ]] && g=g
> > if ${LIBTOOLIZE:-${g}libtoolize} -n --install >& /dev/null ; then
> > 
> > _elibtoolize --copy --force --install
> 
> This change broke many gnome-related packages, see bug #416789

should be fixed:
http://sources.gentoo.org/eclass/autotools.eclass?r1=1.139&r2=1.140

end packages that use intltoolize must depend on it themselves
-mike


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

[gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

[Alexandre Rostovtsev]

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.

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

[Samuli Suominen]

On 05/21/2012 08:14 PM, Michał Górny wrote:

On Mon, 21 May 2012 01:24:13 +0200
hasufell  wrote:


I want support for installing icons into the appropriate directories
which are under /usr/share/icons/... and not just pixmaps.

proposal attached + diff

This should not break existing ebuilds. Tested a bit and open for
review now.


I'd rather see a new function for that rather than making doicon()
overcomplex.



Uh, please no. Doing something simple as installing icons shouldn't have 
multiple commands.


Should be easy enough to retain the old behavior, and add on top of that.

- Samuli

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Mike Frysinger]

On Monday 21 May 2012 12:08:21 Alexandre Rostovtsev wrote:
> On Mon, 2012-05-21 at 11:36 -0400, Mike Frysinger wrote:
> > On Monday 21 May 2012 02:41:18 Alexandre Rostovtsev wrote:
> > > On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote:
> > > > i've extended eautoreconf to automatically call autopoint when the
> > > > package uses gettext.  the configure check might seem naïve, but this
> > > > is how autoreconf itself does it.  this hopefully shouldn't break
> > > > any packages (at least, none that weren't already broken), but if
> > > > you guys start seeing eautoreconf failures where there were none
> > > > before, feel free to cc base-system. -mike
> > > > 
> > > > --- autotools.eclass
> > > > +++ autotools.eclass
> > > > @@ -162,6 +162,9 @@ eautoreconf() {
> > > > 
> > > > einfo "Running eautoreconf in '${PWD}' ..."
> > > > [[ -n ${auxdir}${macdir} ]] && mkdir -p ${auxdir} ${macdir}
> > > > eaclocal
> > > > 
> > > > +   if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
> > > > +   eautopoint --force
> > > > +   fi
> > > > 
> > > > [[ ${CHOST} == *-darwin* ]] && g=g
> > > > if ${LIBTOOLIZE:-${g}libtoolize} -n --install >& /dev/null ;then
> > > > 
> > > > _elibtoolize --copy --force --install
> > > 
> > > This change broke many gnome-related packages, see bug #416789. You
> > > cannot assume that every package that uses AM_GNU_GETTEXT_VERSION wants
> > > (just) autopoint;
> > 
> > two things:
> >  - eautoreconf acts like autoreconf which means it can assume that use of
> > AM_GNU_GETTEXT_VERSION implies use of `autopoint`
> >  - it doesn't assume *just* autopoint -- nothing is stopping you from
> >  running any other random tools you like (such as intltool)
> 
> Changing eautoreconf's behavior to exactly match vanilla autoconf may
> make sense from your point of view as an autotools maintainer, but it
> breaks ebuilds that do not want vanilla autoconf semantics and that are
> relying on eautoreconf's old, intltool-friendly behavior.

it still makes sense.  i don't have a problem integrating a call to intltool, 
but your proposed code isn't the way to go.

> > > there are also packages that use intltool (to be run
> > > after autopoint) or glib-gettext (in which case autopoint should not be
> > > used at all).
> > 
> > so attempting to run `autoreconf` in those packages fails ?
> 
> It results in configure failure. E.g.

so the answer is "yes, these packages fail to work with `autoreconf`"

> > > +# @ECLASS-VARIABLE: WANT_INTLTOOL
> > > +# @DESCRIPTION:
> > > +# Do you want intltool?  Valid values here are "latest" and "none".
> > > +: ${WANT_INTLTOOL:=latest}
> > > ...
> > > +_intltool_atom="dev-util/intltool"
> > > +if [[ -n ${WANT_INTLTOOL} ]] ; then
> > > + case ${WANT_INTLTOOL} in
> > > + none)   _intltool_atom="" ;;
> > > + latest) ;;
> > > + *)  die "Invalid WANT_INTLTOOL value '${WANT_INTLTOOL}'" ;;
> > > + esac
> > > + export WANT_LIBTOOL
> > > +fi
> > > ...
> > > -AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_libtool_atom}"
> > > +AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_intltool_atom}
> > 
> > no.  this adds intltool as a dependency to every package inherting this
> > eclass.
> 
> Why is that unacceptable?

fairly obvious why

> Realistically, every Gentoo machine, with the exception of pure deployment
> installations that don't build any packages (and therefore don't care about
> autotools.eclass anyway), already has intltool installed.

extending the set of machines that you care about to include all setups is 
obviously wrong (i certainly have machines that "build packages" that don't 
have intltool installed).  and even if that wasn't true, it'd be entirely 
irrelevant.  spurious dependencies are not acceptable.
-mike


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

Re: [gentoo-dev] enhancement for doicon/newicon in eutils.eclass

[Michał Górny]

On Mon, 21 May 2012 01:24:13 +0200
hasufell  wrote:

> I want support for installing icons into the appropriate directories
> which are under /usr/share/icons/... and not just pixmaps.
> 
> proposal attached + diff
> 
> This should not break existing ebuilds. Tested a bit and open for
> review now.

I'd rather see a new function for that rather than making doicon()
overcomplex.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Alexandre Rostovtsev]

On Mon, 2012-05-21 at 11:36 -0400, Mike Frysinger wrote:
> On Monday 21 May 2012 02:41:18 Alexandre Rostovtsev wrote:
> > On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote:
> > > i've extended eautoreconf to automatically call autopoint when the
> > > package uses gettext.  the configure check might seem naïve, but this is
> > > how autoreconf itself does it.  this hopefully shouldn't break any
> > > packages (at least, none that weren't already broken), but if you guys
> > > start seeing eautoreconf failures where there were none before, feel
> > > free to cc base-system. -mike
> > > 
> > > --- autotools.eclass
> > > +++ autotools.eclass
> > > @@ -162,6 +162,9 @@ eautoreconf() {
> > > 
> > >   einfo "Running eautoreconf in '${PWD}' ..."
> > >   [[ -n ${auxdir}${macdir} ]] && mkdir -p ${auxdir} ${macdir}
> > >   eaclocal
> > > 
> > > + if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
> > > + eautopoint --force
> > > + fi
> > > 
> > >   [[ ${CHOST} == *-darwin* ]] && g=g
> > >   if ${LIBTOOLIZE:-${g}libtoolize} -n --install >& /dev/null ; then
> > >   
> > >   _elibtoolize --copy --force --install
> > 
> > This change broke many gnome-related packages, see bug #416789. You
> > cannot assume that every package that uses AM_GNU_GETTEXT_VERSION wants
> > (just) autopoint;
> 
> two things:
>  - eautoreconf acts like autoreconf which means it can assume that use of 
> AM_GNU_GETTEXT_VERSION implies use of `autopoint`
>  - it doesn't assume *just* autopoint -- nothing is stopping you from running 
> any other random tools you like (such as intltool)

Changing eautoreconf's behavior to exactly match vanilla autoconf may
make sense from your point of view as an autotools maintainer, but it
breaks ebuilds that do not want vanilla autoconf semantics and that are
relying on eautoreconf's old, intltool-friendly behavior.

> > there are also packages that use intltool (to be run
> > after autopoint) or glib-gettext (in which case autopoint should not be
> > used at all).
> 
> so attempting to run `autoreconf` in those packages fails ?

It results in configure failure. E.g.

>>> Emerging (1 of 1) gnome-extra/evolution-data-server-3.2.3-r2
[...]
 * Running eautoreconf in 
'/var/tmp/portage/gnome-extra/evolution-data-server-3.2.3-r2/work/evolution-data-server-3.2.3'
 ...
 * Running aclocal -I m4 ...[ ok ]
 * Running autopoint --force ...[ ok ]
 * Running libtoolize --install --copy --force --automake ...   [ ok ]
 * Running aclocal -I m4 ...[ ok ]
 * Running autoconf ... [ ok ]
 * Running autoheader ...   [ ok ]
 * Running automake --add-missing --copy --foreign ...  [ ok ]
 * Running elibtoolize in: evolution-data-server-3.2.3/
 *   Applying portage/1.2.0 patch ...
 *   Applying sed/1.5.6 patch ...
 * Fixing OMF Makefiles ... [ ok ]
>>> Source prepared.
>>> Configuring source in 
>>> /var/tmp/portage/gnome-extra/evolution-data-server-3.2.3-r2/work/evolution-data-server-3.2.3
>>>  ...
[...]
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing libtool commands
config.status: executing po/stamp-it commands
config.status: error: po/Makefile.in.in was not created by intltoolize.

!!! Please attach the following file when seeking support:
!!! 
/var/tmp/portage/gnome-extra/evolution-data-server-3.2.3-r2/work/evolution-data-server-3.2.3/config.log
 * ERROR: gnome-extra/evolution-data-server-3.2.3-r2 failed (configure phase):
 *   econf failed

> > +# @ECLASS-VARIABLE: WANT_INTLTOOL
> > +# @DESCRIPTION:
> > +# Do you want intltool?  Valid values here are "latest" and "none".
> > +: ${WANT_INTLTOOL:=latest}
> > ...
> > +_intltool_atom="dev-util/intltool"
> > +if [[ -n ${WANT_INTLTOOL} ]] ; then
> > +   case ${WANT_INTLTOOL} in
> > +   none)   _intltool_atom="" ;;
> > +   latest) ;;
> > +   *)  die "Invalid WANT_INTLTOOL value '${WANT_INTLTOOL}'" ;;
> > +   esac
> > +   export WANT_LIBTOOL
> > +fi
> > ...
> > -AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_libtool_atom}"
> > +AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_intltool_atom}
> 
> no.  this adds intltool as a dependency to every package inherting this 
> eclass.

Why is that unacceptable? Realistically, every Gentoo machine, with the
exception of pure deployment installations that don't build any packages
(and therefore don't care about autotools.eclass anyway), already has
intltool installed.

-Alexandre.

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Mike Frysinger]

On Monday 21 May 2012 02:41:18 Alexandre Rostovtsev wrote:
> On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote:
> > i've extended eautoreconf to automatically call autopoint when the
> > package uses gettext.  the configure check might seem naïve, but this is
> > how autoreconf itself does it.  this hopefully shouldn't break any
> > packages (at least, none that weren't already broken), but if you guys
> > start seeing eautoreconf failures where there were none before, feel
> > free to cc base-system. -mike
> > 
> > --- autotools.eclass
> > +++ autotools.eclass
> > @@ -162,6 +162,9 @@ eautoreconf() {
> > 
> > einfo "Running eautoreconf in '${PWD}' ..."
> > [[ -n ${auxdir}${macdir} ]] && mkdir -p ${auxdir} ${macdir}
> > eaclocal
> > 
> > +   if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
> > +   eautopoint --force
> > +   fi
> > 
> > [[ ${CHOST} == *-darwin* ]] && g=g
> > if ${LIBTOOLIZE:-${g}libtoolize} -n --install >& /dev/null ; then
> > 
> > _elibtoolize --copy --force --install
> 
> This change broke many gnome-related packages, see bug #416789. You
> cannot assume that every package that uses AM_GNU_GETTEXT_VERSION wants
> (just) autopoint;

two things:
 - eautoreconf acts like autoreconf which means it can assume that use of 
AM_GNU_GETTEXT_VERSION implies use of `autopoint`
 - it doesn't assume *just* autopoint -- nothing is stopping you from running 
any other random tools you like (such as intltool)

> there are also packages that use intltool (to be run
> after autopoint) or glib-gettext (in which case autopoint should not be
> used at all).

so attempting to run `autoreconf` in those packages fails ?

> +# @ECLASS-VARIABLE: WANT_INTLTOOL
> +# @DESCRIPTION:
> +# Do you want intltool?  Valid values here are "latest" and "none".
> +: ${WANT_INTLTOOL:=latest}
> ...
> +_intltool_atom="dev-util/intltool"
> +if [[ -n ${WANT_INTLTOOL} ]] ; then
> + case ${WANT_INTLTOOL} in
> + none)   _intltool_atom="" ;;
> + latest) ;;
> + *)  die "Invalid WANT_INTLTOOL value '${WANT_INTLTOOL}'" ;;
> + esac
> + export WANT_LIBTOOL
> +fi
> ...
> -AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_libtool_atom}"
> +AUTOTOOLS_DEPEND="${_automake_atom} ${_autoconf_atom} ${_intltool_atom}

no.  this adds intltool as a dependency to every package inherting this 
eclass.
-mike


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

Re: [gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass

[Mike Gilbert]

On Mon, May 21, 2012 at 1:30 AM, hasufell  wrote:
> On 05/21/2012 02:01 AM, Jonathan Callen wrote:
>> On 05/20/2012 07:49 PM, hasufell wrote:
>>> On 05/21/2012 01:36 AM, Alexis Ballier wrote:
 On Mon, 21 May 2012 01:24:13 +0200 hasufell
  wrote:

> I want support for installing icons into the appropriate
> directories which are under /usr/share/icons/... and not
> just pixmaps.
>
> proposal attached + diff
>
> This should not break existing ebuilds. Tested a bit and
> open for review now.

 maybe i missed something but cant you just make doicon a
 newicon wrapper and remove all that code duplication ?

>>
>>> I don't see how. "doicon" supports installing multiple icons
>>> with one command, as well as directories. That does not work for
>>> "newicon".
>>
>>
>>
>> Normally, new* is a wrapper for do* that does something like:
>>
>> newfoo() { # argument checking omitted... cp -P "${1}" "${T}/${2}"
>> dofoo "${T}/${2}" }
>>
>>
>
> That does not use "newins" like the old function. Why would I want to
> change that?
>

An alternative would be to factor the common code into a third
function, and call that from doicon and newicon.

Re: [gentoo-dev] Do we need games group and all that game prefixes?

[Maxim Kammerer]

On Mon, May 21, 2012 at 10:17 AM, Walter Dnes  wrote:
> I don't know the current situation, but I recall that in the past,
> some games pounded away directly on the VGA hardware for speed, or
> called libraries that did so.

I think that the main sentiment in this thread is that, while
/usr/games have found some uses in Gentoo “because it's there”, it is
pure legacy. However, /usr/games and associated directories *are* part
of the FHS [1], and are older than X [2].

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html
[2] http://unix-tree.huihoo.org/V7/

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you

[Pacho Ramos]

El lun, 21-05-2012 a las 02:41 -0400, Alexandre Rostovtsev escribió:
> On Sun, 2012-05-20 at 06:32 -0400, Mike Frysinger wrote:
> > i've extended eautoreconf to automatically call autopoint when the package 
> > uses gettext.  the configure check might seem naïve, but this is how 
> > autoreconf 
> > itself does it.  this hopefully shouldn't break any packages (at least, 
> > none 
> > that weren't already broken), but if you guys start seeing eautoreconf 
> > failures where there were none before, feel free to cc base-system.
> > -mike
> > 
[...]
>   eaclocal
> - if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? ; then
> + # Follow gnome2-live.eclass and gnome-autogen.sh logic; bug #416789
> + if grep -q '^AM_GNU_GETTEXT_VERSION' configure.?? && ! grep -q 
> '^AM_GLIB_GNU_GETTEXT' configure.?? ; then
>   eautopoint --force
>   fi
> + if grep -q "^AC_PROG_INTLTOOL\|^IT_PROG_INTLTOOL" configure.?? ; then
> + autotools_run_tool intltoolize --force --copy --automake
> + fi
>   _elibtoolize --install --copy --force
>   eautoconf
>   eautoheader
> 
> 
> 

With this change, we can start to no longer call "intltoolize --force
--copy --automake" directly in ebuilds I guess, no?


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

Re: [gentoo-dev] Do we need games group and all that game prefixes?

[Samuli Suominen]

On 05/21/2012 10:17 AM, Walter Dnes wrote:

On Sun, May 20, 2012 at 08:16:44PM +0300, Maxim Kammerer wrote

On Sun, May 20, 2012 at 7:26 PM, Micha?? G??rny  wrote:

- changing ownership and permissions of all the files.


As a side note: why is /usr/games owned by uid "games"? Does
games_pkg_setup() in games.eclass do that? What's the point of user
"games" (as opposed to group with same name)?


   I don't know the current situation, but I recall that in the past,
some games pounded away directly on the VGA hardware for speed, or
called libraries that did so.  This, of course might be dangerous to
allow regular-user programs to do.


I suppose you mean the "XFree86-DGA extension", USE="dga"?

$ cd $(portageq envvar PORTDIR)
$ grep -r IUSE.*dga */*/*.ebuild

http://qa-reports.gentoo.org/output/genrdeps/rindex/x11-libs/libXxf86dga

But I fail to see how that is relavent with this thread at all, using 
the extension is controlled by the xorg-server (Xorg) which is suid root 
and unrelated to 'games' (despite being used by some).


- Samuli

Re: [gentoo-dev] Do we need games group and all that game prefixes?

[Walter Dnes]

On Sun, May 20, 2012 at 08:16:44PM +0300, Maxim Kammerer wrote
> On Sun, May 20, 2012 at 7:26 PM, Micha?? G??rny  wrote:
> > - changing ownership and permissions of all the files.
> 
> As a side note: why is /usr/games owned by uid "games"? Does
> games_pkg_setup() in games.eclass do that? What's the point of user
> "games" (as opposed to group with same name)?

  I don't know the current situation, but I recall that in the past,
some games pounded away directly on the VGA hardware for speed, or
called libraries that did so.  This, of course might be dangerous to
allow regular-user programs to do.

-- 
Walter Dnes