Re: [gentoo-dev] Addressing GLEP-62 itself

[Zac Medico]

On 09/27/2012 01:30 PM, Ian Stakenvicius wrote:
> On 27/09/12 04:13 PM, Zac Medico wrote:
>> On 09/27/2012 12:53 PM, Brian Harring wrote:
>>> Bullshit.  This is optional in the sense of embrace/extend
>>> 'optional'; if one PM takes up the new functionality, all have to
>>> switch to writing unfinalized deps to the VDB, and all have to
>>> switch to transfering that IUSE_RUNTIME crap to the VDB.
> 
>> I think the proposal suddenly becomes a lot saner if it's done as
>> an EAPI extension, the optional runtime deps and IUSE_RUNTIME
>> conditionals are isolated in a new separate variable (perhaps
>> SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE.
>> Using a separate SRDEPEND variable means that the package manager
>> only has to preserve USE conditionals in the vdb for that one
>> variable.
> 
> 
> Saner, perhaps, but that would also mean the feature would be more or
> less independent of the current USE handling within the PM.

Well, the package manager could still treat IUSE_RUNTIME flags as valid
flags for things like USE deps in _other_ packages. So, they don't have
to be entirely independent. The idea is just to limit the scope where
those flags are allowed the package that declares the flags as runtime
flags, so that those runtime flags are only allowed in SRDEPEND.

> Mind you if it's easier to deal with in the PM then I guess
> piggy-backing on the current USE implementation isn't an advantage.

Part of my concern is not just the implementation details, but also
being able to explain/document for communication purposes. If it's such
a mess that it's difficult to communicate, then it sucks for everyone
involved.
-- 
Thanks,
Zac

Re: [gentoo-dev] Addressing GLEP-62 itself

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/09/12 04:13 PM, Zac Medico wrote:
> On 09/27/2012 12:53 PM, Brian Harring wrote:
>> Bullshit.  This is optional in the sense of embrace/extend
>> 'optional'; if one PM takes up the new functionality, all have to
>> switch to writing unfinalized deps to the VDB, and all have to
>> switch to transfering that IUSE_RUNTIME crap to the VDB.
> 
> I think the proposal suddenly becomes a lot saner if it's done as
> an EAPI extension, the optional runtime deps and IUSE_RUNTIME
> conditionals are isolated in a new separate variable (perhaps
> SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE.
> Using a separate SRDEPEND variable means that the package manager
> only has to preserve USE conditionals in the vdb for that one
> variable.


Saner, perhaps, but that would also mean the feature would be more or
less independent of the current USE handling within the PM.

Mind you if it's easier to deal with in the PM then I guess
piggy-backing on the current USE implementation isn't an advantage.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkt0oACgkQ2ugaI38ACPAKtQEAgkIJJfyBV20VsKVL8/dPlKF9
B4+SnJGlA+daYTCjXvgA/jq7aNzN8Cuj/sE+S+VWCK5U50vtHX3CqhoeOitgf9Zl
=G5Tc
-END PGP SIGNATURE-

Re: [gentoo-dev] Addressing GLEP-62 itself

[Zac Medico]

On 09/27/2012 12:53 PM, Brian Harring wrote:
> Bullshit.  This is optional in the sense of embrace/extend 'optional'; 
> if one PM takes up the new functionality, all have to switch to 
> writing unfinalized deps to the VDB, and all have to switch to 
> transfering that IUSE_RUNTIME crap to the VDB.

I think the proposal suddenly becomes a lot saner if it's done as an
EAPI extension, the optional runtime deps and IUSE_RUNTIME conditionals
are isolated in a new separate variable (perhaps SRDEPEND), and
IUSE_RUNTIME is not allowed to intersect with IUSE. Using a separate
SRDEPEND variable means that the package manager only has to preserve
USE conditionals in the vdb for that one variable.
-- 
Thanks,
Zac

Re: [gentoo-dev] Addressing GLEP-62 itself

[Brian Harring]

On Wed, Sep 26, 2012 at 07:25:11PM -0300, Alexis Ballier wrote:
> On Wed, 26 Sep 2012 14:02:57 -0700
> Brian Harring  wrote:
> > On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote:
> > > IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
> > > Also, the proposal doesn't assume flags are toggable at will, it
> > > assumes they are useflags and obey the same rules.
> > 
> > I truly hate claims like this; "it's optional, so who cares if it's 
> > whacky".  Think through the proposal; for it to work reliably, it's 
> > not optional.  Same issue I've been y'all over the head with, 
> > rendered/finalized vs raw/unfinalized deps being stored in the VDB.  
> > 
> > All managers have to write unfinalized if that proposal goes through, 
> > even if they don't support the optional toggling after the fact.
> 
> Why? _Current_ PMs will rebuild the package. The point of this is just
> to give them a hint that they do not need to rebuild it. We already
> have an implementation actually: one that ignores the hint :)

Bullshit.  This is optional in the sense of embrace/extend 'optional'; 
if one PM takes up the new functionality, all have to switch to 
writing unfinalized deps to the VDB, and all have to switch to 
transfering that IUSE_RUNTIME crap to the VDB.

If they don't, whatever sole/crappy PM that runs w/ this proposal will 
wind up forcing rebuilds on any packages merged by the PM's that don't 
do this "optional" glep.

Thus rendering it nonoptional since it implicitly is reliant on all 
switching to the degrade *DEPEND writing that this proposal is reliant 
on.  The blame game becomes "well, you shouldn't use the PMs that 
don't do this *optional* thing".  There in is the implicit lie of that 
'optional' crap.

Claiming other wise is ignoring reality; I called it embrace/extend 
because this is exactly how that shit goes- sure it's optional, 'cept 
you're forced to support it (even partially) else the whole degrades 
and that PM winds up getting blackballed or fragmentation occuring.  
As far as I'm concerned, any PMS intended proposal must not pull the 
'should' or 'optional' crap; it has no place in a spec (spec's are 
supposed to be assertions after all).


> > As for the UI... arguing "but it's optional!" doesn't give a blank 
> > check for the UI angle.  What the plan, more colorization and a new 
> > char for emerge -vp?  Because we're kind of running out of chars 
> > there...
> 
> How is this relevant ?

Um... dude... This proposal is about adding suggested/optional deps so 
people can inspect/select/enable them per package.

You're asking "how is the UI relevant" in light of that.

Just saying; it's kind of core to this whole damn thing, else we're 
just trying to add an optimization hack; either one runs a strong risk 
of my next response including a joke about elderberries and hamsters. 
;)


> > It's a simple enough request; one that wouldn't even need to be made 
> > if there was code backing this proposal; on a related note, hell yes 
> > I'm wary of having this dumped on manager authors heads and having to 
> > be told "sort out the mess/make it so".  So I'm asking y'all to at 
> > least put in an equivalent time investment doing a quick prototype.
> > 
> > This isn't an unreasonable request, and has been the norm for most 
> > gleps for a long while.
> 
> I guess people do not want to invest time in writing code for something
> doomed.

This is one of the cases where "tough fucking luck" really/truly fits.

If it's doomed, consider why it's doomed.  I'm not requiring a 
prototype just because I'm a dick; I'm requiring a prototype because 
I fully expect since y'all won't listen to what people are telling 
you, trying to write the code will educate y'all to what we've been 
saying.   This is ignoring that prototypes are bsaically the norm for 
proposals of this sort (both PMS and gleps)... meaning it's the 
standard, and y'all are trying to get this proposal special cased.

Does it suck you can't just get what you want via writing a quick doc 
and arguing on an ml?  At times, yes.  If you believe it's worth it, 
you do the legwork.

If the folks backing this can't be bothered to write a freaking patch, 
well, I think that's a pretty strong vote of no-confidence on the 
backers part.


> The original request was just to have it 'accepted' so that an
> implementation can start. If the implementation is good then make it
> final, otherwise amend or reject the glep. This isn't unreasonable
> either.

Also known as rubber stamp it.  And if it sucks, of course it's easy 
to roll that bad idea back?  Right?

If the idea was universally accepted and lacked issues, that may fly; 
that's not been the case.


> > It cannot be stacked because y'all are trying to shove this in as an 
> > optional; unlike it's brother IUSE, which stacks.
> > 
> > As for "ons of others that don't stack"; very few actually influence 
> > the package manager; ~14 roughly, minimally 5 of those stack (thos

Re: [gentoo-dev] RFC: toolchain-funcs.eclass patch to fix bug 432390

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Patch committed ; timing worked out that vapier and I were on irc at
the same time, and toolchain approval was granted.

Vapier did mention (on the bug as well as in-channel) that perhaps
'tc-arch-kernel' should move to linux-info.eclass ...  If anyone has
any thoughts on that please comment on bug 432390

Thanks!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF0EAREIAAYFAlBkrdAACgkQ2ugaI38ACPAwPAD8Cr4O5U+h6TvcBSp0EXkTUdMU
bYaBwseo7P4Z097kBPEA9RriAoJk/lWRHxnZI3gw2ghj0gfjMikH80xzIBUOrnQ=
=f249
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: toolchain-funcs.eclass patch to fix bug 432390

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/09/12 01:55 PM, Ian Stakenvicius wrote:
> Hey all -- it's been a month since 432390 was filed; and this bug
> is keeping lirc-0.9.0-r2 from going stable.  If nobody objects
> within the next 24h or so, I'm going to apply the following patch
> to toolchain-funcs.eclass to fix the bug.
> 
> The patch does not revert existing behaviour and only allows the 
> function to work properly (or fail gracefully) when used outside
> of kernel-2.eclass.
> 
> The patch changes tc-ninja_magic_to_arch() as follows:
> 
> 1 - changes the use of $KV to the local $kv in all checks
> 
> 2 - assigns kv=${KV:-$KV_FULL} (so that if called from
> kernel-2.eclass it will work as-is, but if not then it will use the
> value of KV_FULL from linux-info, the way its supposed to)
> 
> 3 - dies, instead of returning an invalid value, when no kernel 
> version is available.
> 

The bug mentions it'd not be a problem to use a 'local
KV=${KV:-$KV_FULL}' , so that would reduce the size of the patch
significantly and I have no issues doing that instead.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBknVsACgkQ2ugaI38ACPAQeQEAu/PZ4Qk22XHXgc9ahai8I/3Y
kqrewQtYmSYc+ixVoBoA/Agy7u+gRUGBlNoVlGr8A6FEOwrhRe0A61y9sX/KLLv/
=LJpg
-END PGP SIGNATURE-

Re: [gentoo-dev] How to raise money for Gentoo

[Dale]

Alec Warner wrote:
> On Thu, Sep 27, 2012 at 4:11 PM, Dale  wrote:
>> wbrana wrote:
>>> Page www.gentoo.org asks for donations
>>> "Donate to support our development efforts."
>>> Gentoo could get more money if all *.gentoo.org would contain 
>>> advertisements.
>>>
>>>
>>
>> My questions are this:  Does Gentoo need more money?  Is it in need of
>> more funds to support itself?
> On a yearly basis, we take in more money than we spend. We primarily
> spend money on fees (legal, accountant, etc) and funding requests
> (infra hardware, requests from foundation members.)
>
> Its all on http://foundation.gentoo.org if you are curious. The 2011
> report notes that we have approximately $70,000 USD in funds. Some
> Gentoo developers want to do more conference-type events. However
> those typically come with much higher budgets than our funds and
> require sponsors to make happen. Without clearer goals on what to
> spend the money on, I can't really see the need to increase our
> advertising.
>
> We primarily get money from Paypal and Google Summer of Code.
>
> -A
>
>> Dale
>>
>> :-)  :-)
>>
>> --
>> I am only responsible for what I said ... Not for what you understood or how 
>> you interpreted my words!
>>
>>
>


Thanks for the answer.  If Gentoo ever gets to a point where it needs
funds to maintain itself, I would like a dev to post to the user mailing
list.  I'm certain we could donate if we know there is a need.  I
certainly would and I'm sure others would too.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

[Zac Medico]

On 09/27/2012 10:45 AM, Ian Stakenvicius wrote:
> On 27/09/12 12:02 PM, Ian Stakenvicius wrote:
>> On 27/09/12 11:57 AM, Mike Gilbert wrote:
>>> On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico  
>>> wrote:
 Hi,

 The council has approved [1] "Profile IUSE injection" [2] for 
 inclusion in EAPI 5, and in latest Portage we have
 experimental EAPI 5_pre2 [3] which implements all of the
 approved features. So, now would be a good time to start
 populating IUSE_IMPLICIT with whatever values may be
 appropriate.

 What values belong there? Some of the flags that appear in 
 profiles/base/use.mask might make good candidates, such as
 prefix and selinux. How about other special flags like
 bootstrap, build, and test?

> 
>>> prefix and test make sense to me. I'm not so familiar with the 
>>> others.
> 
> 
>> build is specifically for catalyst and/or for building the stages, 
>> right?  If so, this one makes sense to me to add.
> 
>> bootstrap I would guess is similar?  Unsure how that one is used
>> at present.  If IUSE_IMPLICIT would still allow the boostrapping
>> tool to set the use flag, i see no issues having it in the list.
> 
> 
> For the purposes of EAPI5 testing (overlays etc), would it make sense
> to start with this list of flags within IUSE_IMPLICIT on
> base/make.defaults now, and then based on consensus that list can be
> trimmed or appended?

I would recommend to stay on the conservative side and only add ones
that we're sure we need for specific ebuilds. We can remove flags later,
but it's better if can avoid adding unneeded ones in the first place.

> floppym's already requested 'prefix' so that his chromium tests with
> EAPI5 don't fail or need an explicit 'prefix' in IUSE, for instance

I think it's pretty clear that the 'prefix' flag is special, so I would
go ahead and add it.
-- 
Thanks,
Zac

[gentoo-dev] RFC: toolchain-funcs.eclass patch to fix bug 432390

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all -- it's been a month since 432390 was filed; and this bug is
keeping lirc-0.9.0-r2 from going stable.  If nobody objects within the
next 24h or so, I'm going to apply the following patch to
toolchain-funcs.eclass to fix the bug.

The patch does not revert existing behaviour and only allows the
function to work properly (or fail gracefully) when used outside of
kernel-2.eclass.

The patch changes tc-ninja_magic_to_arch() as follows:

1 - changes the use of $KV to the local $kv in all checks

2 - assigns kv=${KV:-$KV_FULL}
 (so that if called from kernel-2.eclass it will work as-is, but if
not then it will use the value of KV_FULL from linux-info, the way its
supposed to)

3 - dies, instead of returning an invalid value, when no kernel
version is available.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkkxcACgkQ2ugaI38ACPDAzwD+KJCvblZlCjw3ELum8JK1zg0c
ZDCGuRb7bbpFuCjfKK8BALMBDyDamB7zvrgu1vOi3LuEPHLTY2yB8YColruW9Q4v
=Husj
-END PGP SIGNATURE-
--- toolchain-funcs.eclass	2012-09-15 12:16:53.0 -0400
+++ toolchain-funcs.eclass	2012-09-14 12:33:55.0 -0400
@@ -357,6 +359,9 @@
 	local host=$2
 	[[ -z ${host} ]] && host=${CTARGET:-${CHOST}}
 
+	local kv=${KV:-$KV_FULL}
+	[[ -z ${kv} ]] && die "toolchain-funcs.eclass: Kernel version could not be determined, please inherit kernel-2 or linux-info"
+
 	case ${host} in
 		aarch64*)	ninj aarch64 arm;;
 		alpha*)		echo alpha;;
@@ -369,7 +374,7 @@
 			# Starting with linux-2.6.24, the 'x86_64' and 'i386'
 			# trees have been unified into 'x86'.
 			# FreeBSD still uses i386
-			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -lt $(KV_to_int 2.6.24) || ${host} == *freebsd* ]] ; then
+			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${kv}) -lt $(KV_to_int 2.6.24) || ${host} == *freebsd* ]] ; then
 echo i386
 			else
 echo x86
@@ -384,9 +389,9 @@
 			# Starting with linux-2.6.15, the 'ppc' and 'ppc64' trees
 			# have been unified into simply 'powerpc', but until 2.6.16,
 			# ppc32 is still using ARCH="ppc" as default
-			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.16) ]] ; then
+			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${kv}) -ge $(KV_to_int 2.6.16) ]] ; then
 echo powerpc
-			elif [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -eq $(KV_to_int 2.6.15) ]] ; then
+			elif [[ ${type} == "kern" ]] && [[ $(KV_to_int ${kv}) -eq $(KV_to_int 2.6.15) ]] ; then
 if [[ ${host} == powerpc64* ]] || [[ ${PROFILE_ARCH} == "ppc64" ]] ; then
 	echo powerpc
 else
@@ -413,7 +418,7 @@
 		x86_64*)
 			# Starting with linux-2.6.24, the 'x86_64' and 'i386'
 			# trees have been unified into 'x86'.
-			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${KV}) -ge $(KV_to_int 2.6.24) ]] ; then
+			if [[ ${type} == "kern" ]] && [[ $(KV_to_int ${kv}) -ge $(KV_to_int 2.6.24) ]] ; then
 echo x86
 			else
 ninj x86_64 amd64


toolchain-funcs-fix.patch.sig
Description: PGP signature

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

[Brian Harring]

On Thu, Sep 27, 2012 at 10:30:21AM -0700, Zac Medico wrote:
> On 09/27/2012 10:16 AM, Ian Stakenvicius wrote:
> > On 27/09/12 01:07 PM, Zac Medico wrote:
> >> On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
> >>> As far as I can see, only the definition of the usex function
> >>> must be disabled. Please review the patch included below.
> >>>
> >>> Ulrich
> >>>
> >>> --- eutils.eclass 15 Sep 2012 16:16:53 -  1.403 +++
> >>> eutils.eclass 27 Sep 2012 16:45:14 - @@ -1373,7 +1373,9 @@ #
> >>> @DESCRIPTION: # If USE flag is set, echo [true output][true
> >>> suffix] (defaults to "yes"), # otherwise echo [false
> >>> output][false suffix] (defaults to "no"). +if has "${EAPI:-0}" 0
> >>> 1 2 3 4; then usex() { use "$1" && echo "${2-yes}$4" || echo
> >>> "${3-no}$5" ; } #382963 +fi
> >>>
> >>> # @FUNCTION: prune_libtool_files # @USAGE: [--all]
> >>>
> > 
> >> Looks good to me.
> > 
> >> It may not work for unofficial EAPIs that don't include usex, but
> >> I guess there's nothing we can do for those, and they can just be
> >> replaced with newer EAPIs that include usex.
> > 
> > i actually just committed the fix discussed in #gentoo-dev , using
> > 'declare -F' instead (similar to the eqawarn conditional declaration
> > already in eutils.eclass)
> > 
> > 
> > Sorry..
> 
> It's fine with me, but some of the other package manager devs might
> object, since it makes assumptions about implementation details.

PMS isn't particular clear on the metadata sourcing env for EAPIs- 
especially after the requirement that we pull the EAPI out of the file 
on the fly was aded.

Point is, if it's EAPI5 the env should already export usex- even if 
it's disabled- so case/esac is better imo.
~harring

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/09/12 12:02 PM, Ian Stakenvicius wrote:
> On 27/09/12 11:57 AM, Mike Gilbert wrote:
>> On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico  
>> wrote:
>>> Hi,
>>> 
>>> The council has approved [1] "Profile IUSE injection" [2] for 
>>> inclusion in EAPI 5, and in latest Portage we have
>>> experimental EAPI 5_pre2 [3] which implements all of the
>>> approved features. So, now would be a good time to start
>>> populating IUSE_IMPLICIT with whatever values may be
>>> appropriate.
>>> 
>>> What values belong there? Some of the flags that appear in 
>>> profiles/base/use.mask might make good candidates, such as
>>> prefix and selinux. How about other special flags like
>>> bootstrap, build, and test?
>>> 
> 
>> prefix and test make sense to me. I'm not so familiar with the 
>> others.
> 
> 
> build is specifically for catalyst and/or for building the stages, 
> right?  If so, this one makes sense to me to add.
> 
> bootstrap I would guess is similar?  Unsure how that one is used
> at present.  If IUSE_IMPLICIT would still allow the boostrapping
> tool to set the use flag, i see no issues having it in the list.
> 

For the purposes of EAPI5 testing (overlays etc), would it make sense
to start with this list of flags within IUSE_IMPLICIT on
base/make.defaults now, and then based on consensus that list can be
trimmed or appended?

floppym's already requested 'prefix' so that his chromium tests with
EAPI5 don't fail or need an explicit 'prefix' in IUSE, for instance
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkkNAACgkQ2ugaI38ACPBy4wD/VvIH8xliB9j+bfUD35wZSeK+
CuBMh6wuy3hKQkufCM0A/iZFp+g7/tcXtRdQBxahojwhtaN7SnFpQkVJNzBdstUI
=BhP1
-END PGP SIGNATURE-

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

[Zac Medico]

On 09/27/2012 10:16 AM, Ian Stakenvicius wrote:
> On 27/09/12 01:07 PM, Zac Medico wrote:
>> On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
>>> As far as I can see, only the definition of the usex function
>>> must be disabled. Please review the patch included below.
>>>
>>> Ulrich
>>>
>>> --- eutils.eclass   15 Sep 2012 16:16:53 -  1.403 +++
>>> eutils.eclass   27 Sep 2012 16:45:14 - @@ -1373,7 +1373,9 @@ #
>>> @DESCRIPTION: # If USE flag is set, echo [true output][true
>>> suffix] (defaults to "yes"), # otherwise echo [false
>>> output][false suffix] (defaults to "no"). +if has "${EAPI:-0}" 0
>>> 1 2 3 4; then usex() { use "$1" && echo "${2-yes}$4" || echo
>>> "${3-no}$5" ; } #382963 +fi
>>>
>>> # @FUNCTION: prune_libtool_files # @USAGE: [--all]
>>>
> 
>> Looks good to me.
> 
>> It may not work for unofficial EAPIs that don't include usex, but
>> I guess there's nothing we can do for those, and they can just be
>> replaced with newer EAPIs that include usex.
> 
> i actually just committed the fix discussed in #gentoo-dev , using
> 'declare -F' instead (similar to the eqawarn conditional declaration
> already in eutils.eclass)
> 
> 
> Sorry..

It's fine with me, but some of the other package manager devs might
object, since it makes assumptions about implementation details.
-- 
Thanks,
Zac

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

[Zac Medico]

On 09/27/2012 10:07 AM, Zac Medico wrote:
> On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
>> As far as I can see, only the definition of the usex function must be
>> disabled. Please review the patch included below.
>>
>> Ulrich
>>
>> --- eutils.eclass15 Sep 2012 16:16:53 -  1.403
>> +++ eutils.eclass27 Sep 2012 16:45:14 -
>> @@ -1373,7 +1373,9 @@
>>  # @DESCRIPTION:
>>  # If USE flag is set, echo [true output][true suffix] (defaults to "yes"),
>>  # otherwise echo [false output][false suffix] (defaults to "no").
>> +if has "${EAPI:-0}" 0 1 2 3 4; then
>>  usex() { use "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; } #382963
>> +fi
>>  
>>  # @FUNCTION: prune_libtool_files
>>  # @USAGE: [--all]
>>
> 
> Looks good to me.
> 
> It may not work for unofficial EAPIs that don't include usex, but I
> guess there's nothing we can do for those, and they can just be replaced
> with newer EAPIs that include usex.

Something like this would work with current versions of portage:

if ! declare -F usex >/dev/null ; then
usex() { use "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; }
fi

However, it's probably not a good idea to assume that the package
manager defines usex prior to sourcing the eclass.
-- 
Thanks,
Zac

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/09/12 01:07 PM, Zac Medico wrote:
> On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
>> As far as I can see, only the definition of the usex function
>> must be disabled. Please review the patch included below.
>> 
>> Ulrich
>> 
>> --- eutils.eclass15 Sep 2012 16:16:53 -  1.403 +++
>> eutils.eclass27 Sep 2012 16:45:14 - @@ -1373,7 +1373,9 @@ #
>> @DESCRIPTION: # If USE flag is set, echo [true output][true
>> suffix] (defaults to "yes"), # otherwise echo [false
>> output][false suffix] (defaults to "no"). +if has "${EAPI:-0}" 0
>> 1 2 3 4; then usex() { use "$1" && echo "${2-yes}$4" || echo
>> "${3-no}$5" ; } #382963 +fi
>> 
>> # @FUNCTION: prune_libtool_files # @USAGE: [--all]
>> 
> 
> Looks good to me.
> 
> It may not work for unofficial EAPIs that don't include usex, but
> I guess there's nothing we can do for those, and they can just be
> replaced with newer EAPIs that include usex.

i actually just committed the fix discussed in #gentoo-dev , using
'declare -F' instead (similar to the eqawarn conditional declaration
already in eutils.eclass)


Sorry..

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkif0ACgkQ2ugaI38ACPDcvgEAudN0ErAB8aZkjtdiTK309NV0
01UWERp6vSQsvTmaVUwA/1LBd9ddbgGUpiqwvDCYzYR1rbgiA+7a6vzU9mmzZpil
=RdnN
-END PGP SIGNATURE-

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

[Zac Medico]

On 09/27/2012 09:49 AM, Ulrich Mueller wrote:
> As far as I can see, only the definition of the usex function must be
> disabled. Please review the patch included below.
> 
> Ulrich
> 
> --- eutils.eclass 15 Sep 2012 16:16:53 -  1.403
> +++ eutils.eclass 27 Sep 2012 16:45:14 -
> @@ -1373,7 +1373,9 @@
>  # @DESCRIPTION:
>  # If USE flag is set, echo [true output][true suffix] (defaults to "yes"),
>  # otherwise echo [false output][false suffix] (defaults to "no").
> +if has "${EAPI:-0}" 0 1 2 3 4; then
>  usex() { use "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; } #382963
> +fi
>  
>  # @FUNCTION: prune_libtool_files
>  # @USAGE: [--all]
> 

Looks good to me.

It may not work for unofficial EAPIs that don't include usex, but I
guess there's nothing we can do for those, and they can just be replaced
with newer EAPIs that include usex.
-- 
Thanks,
Zac

[gentoo-dev] patch eutils.eclass for EAPI 5

[Ulrich Mueller]

As far as I can see, only the definition of the usex function must be
disabled. Please review the patch included below.

Ulrich

--- eutils.eclass   15 Sep 2012 16:16:53 -  1.403
+++ eutils.eclass   27 Sep 2012 16:45:14 -
@@ -1373,7 +1373,9 @@
 # @DESCRIPTION:
 # If USE flag is set, echo [true output][true suffix] (defaults to "yes"),
 # otherwise echo [false output][false suffix] (defaults to "no").
+if has "${EAPI:-0}" 0 1 2 3 4; then
 usex() { use "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; } #382963
+fi
 
 # @FUNCTION: prune_libtool_files
 # @USAGE: [--all]

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/09/12 11:57 AM, Mike Gilbert wrote:
> On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico 
> wrote:
>> Hi,
>> 
>> The council has approved [1] "Profile IUSE injection" [2] for
>> inclusion in EAPI 5, and in latest Portage we have experimental
>> EAPI 5_pre2 [3] which implements all of the approved features.
>> So, now would be a good time to start populating IUSE_IMPLICIT
>> with whatever values may be appropriate.
>> 
>> What values belong there? Some of the flags that appear in 
>> profiles/base/use.mask might make good candidates, such as prefix
>> and selinux. How about other special flags like bootstrap, build,
>> and test?
>> 
> 
> prefix and test make sense to me. I'm not so familiar with the
> others.
> 

build is specifically for catalyst and/or for building the stages,
right?  If so, this one makes sense to me to add.

bootstrap I would guess is similar?  Unsure how that one is used at
present.  If IUSE_IMPLICIT would still allow the boostrapping tool to
set the use flag, i see no issues having it in the list.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkeLIACgkQ2ugaI38ACPAh/QEAvfgmEDRGykF+3OvSRJVD684J
z60BrRXTWBYwi0ngmkABAIrolomS0leqwqpt7iX9RhYvctwId1CClZZ7P88+Ms6L
=R1e4
-END PGP SIGNATURE-

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

[Mike Gilbert]

On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico  wrote:
> Hi,
>
> The council has approved [1] "Profile IUSE injection" [2] for inclusion
> in EAPI 5, and in latest Portage we have experimental EAPI 5_pre2 [3]
> which implements all of the approved features. So, now would be a good
> time to start populating IUSE_IMPLICIT with whatever values may be
> appropriate.
>
> What values belong there? Some of the flags that appear in
> profiles/base/use.mask might make good candidates, such as prefix and
> selinux. How about other special flags like bootstrap, build, and test?
>

prefix and test make sense to me. I'm not so familiar with the others.

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Florian Philipp]

Am 27.09.2012 09:22, schrieb Florian Philipp:
> Am 26.09.2012 23:53, schrieb Michael Mol:
>> On Wed, Sep 26, 2012 at 5:27 PM, Florian Philipp  
>> wrote:
>>> Am 26.09.2012 22:43, schrieb Matt Turner:
 On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol  wrote:
> A few months ago, I filed bug 423651 to ask that bzip2 on the install
> media be replaced with
>  pbzip2. It was closed a short while later, telling me that it'd
> involve changing what's kept in @system, and that had to be discussed
> here, rather than in a bug report.

 If we're going to ship a parallel bzip2 implementation, it should be
 lbzip2 and not pbzip2.

 lbzip2 can decompress bz2 archives with multiple threads that haven't
 been compressed with lbzip2/pbzip2.

>>>
>>> This seems relevant, especially comment 12ff:
>>> https://bugs.gentoo.org/show_bug.cgi?id=309683
>>>
>>> For further anecdotal evidence: I've used pbzip2 with USE="symlink" for
>>> several months now and never had trouble with it. Checking out lbzip2
>>> now. I noticed it doesn't install a bunzip2 symlink.
>>
>> Piotr Szymaniak asked me about lbzip2, and I bounced the question over
>> to my friend. He didn't investigate it deeply; it crashed (OOM or
>> something else, I don't know) when he tried it on a large file. Could
>> have been from 2GB to 2TB, from what he has laying around. I don't
>> know; I didn't get that one in writing. :)
>>
>> But if it proves to be stable for small and very large files, I'd have
>> no complaint. :)
>>
> 
> I just encountered this:
> 
> bzip2 -c /dev/null
> bzip2:
> /var/tmp/portage/app-arch/lbzip2-2.2/work/lbzip2-2.2/src/encode.c:794:
> generate_initial_trees: Assertion `a < b' failed.
> 
> Something in that file is upsetting lbzip2. I'm investigating.

Okay, reported and (hopefully) fixed in
https://bugs.gentoo.org/show_bug.cgi?id=436382

In my infinite confidence in my own coding and testing skills I suggest
copying the proposed patch to /etc/portage/patches/app-arch/lbzip2-2.2
before trying out lbzip2. ;-)

Regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 10:42 AM, Alec Warner  wrote:
> On Thu, Sep 27, 2012 at 4:35 PM, Michael Mol  wrote:
>> On Thu, Sep 27, 2012 at 10:29 AM, Alec Warner  wrote:
>>> On Thu, Sep 27, 2012 at 4:11 PM, Dale  wrote:
 wbrana wrote:
> Page www.gentoo.org asks for donations
> "Donate to support our development efforts."
> Gentoo could get more money if all *.gentoo.org would contain 
> advertisements.
>
>


 My questions are this:  Does Gentoo need more money?  Is it in need of
 more funds to support itself?
>>>
>>> On a yearly basis, we take in more money than we spend. We primarily
>>> spend money on fees (legal, accountant, etc) and funding requests
>>> (infra hardware, requests from foundation members.)
>>>
>>> Its all on http://foundation.gentoo.org if you are curious. The 2011
>>> report notes that we have approximately $70,000 USD in funds. Some
>>> Gentoo developers want to do more conference-type events. However
>>> those typically come with much higher budgets than our funds and
>>> require sponsors to make happen. Without clearer goals on what to
>>> spend the money on, I can't really see the need to increase our
>>> advertising.
>>
>> Could some of the money be spent on bug bounties?
>
> You want gentoo-nfp@, not this list. I'm trying to move the discussion
> there. Go visit the foundation webpages I linked to earlier. Funding
> requests are pretty easy to write...

kk. I'll stop adding noise to this list on this topic. :)

-- 
:wq

Re: [gentoo-dev] How to raise money for Gentoo

[Alec Warner]

On Thu, Sep 27, 2012 at 4:35 PM, Michael Mol  wrote:
> On Thu, Sep 27, 2012 at 10:29 AM, Alec Warner  wrote:
>> On Thu, Sep 27, 2012 at 4:11 PM, Dale  wrote:
>>> wbrana wrote:
 Page www.gentoo.org asks for donations
 "Donate to support our development efforts."
 Gentoo could get more money if all *.gentoo.org would contain 
 advertisements.


>>>
>>>
>>> My questions are this:  Does Gentoo need more money?  Is it in need of
>>> more funds to support itself?
>>
>> On a yearly basis, we take in more money than we spend. We primarily
>> spend money on fees (legal, accountant, etc) and funding requests
>> (infra hardware, requests from foundation members.)
>>
>> Its all on http://foundation.gentoo.org if you are curious. The 2011
>> report notes that we have approximately $70,000 USD in funds. Some
>> Gentoo developers want to do more conference-type events. However
>> those typically come with much higher budgets than our funds and
>> require sponsors to make happen. Without clearer goals on what to
>> spend the money on, I can't really see the need to increase our
>> advertising.
>
> Could some of the money be spent on bug bounties?

You want gentoo-nfp@, not this list. I'm trying to move the discussion
there. Go visit the foundation webpages I linked to earlier. Funding
requests are pretty easy to write...

-A

>
> [snip]
>
> --
> :wq
>

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 10:29 AM, Alec Warner  wrote:
> On Thu, Sep 27, 2012 at 4:11 PM, Dale  wrote:
>> wbrana wrote:
>>> Page www.gentoo.org asks for donations
>>> "Donate to support our development efforts."
>>> Gentoo could get more money if all *.gentoo.org would contain 
>>> advertisements.
>>>
>>>
>>
>>
>> My questions are this:  Does Gentoo need more money?  Is it in need of
>> more funds to support itself?
>
> On a yearly basis, we take in more money than we spend. We primarily
> spend money on fees (legal, accountant, etc) and funding requests
> (infra hardware, requests from foundation members.)
>
> Its all on http://foundation.gentoo.org if you are curious. The 2011
> report notes that we have approximately $70,000 USD in funds. Some
> Gentoo developers want to do more conference-type events. However
> those typically come with much higher budgets than our funds and
> require sponsors to make happen. Without clearer goals on what to
> spend the money on, I can't really see the need to increase our
> advertising.

Could some of the money be spent on bug bounties?

[snip]

-- 
:wq

Re: [gentoo-dev] How to raise money for Gentoo

[Alec Warner]

On Thu, Sep 27, 2012 at 4:11 PM, Dale  wrote:
> wbrana wrote:
>> Page www.gentoo.org asks for donations
>> "Donate to support our development efforts."
>> Gentoo could get more money if all *.gentoo.org would contain advertisements.
>>
>>
>
>
> My questions are this:  Does Gentoo need more money?  Is it in need of
> more funds to support itself?

On a yearly basis, we take in more money than we spend. We primarily
spend money on fees (legal, accountant, etc) and funding requests
(infra hardware, requests from foundation members.)

Its all on http://foundation.gentoo.org if you are curious. The 2011
report notes that we have approximately $70,000 USD in funds. Some
Gentoo developers want to do more conference-type events. However
those typically come with much higher budgets than our funds and
require sponsors to make happen. Without clearer goals on what to
spend the money on, I can't really see the need to increase our
advertising.

We primarily get money from Paypal and Google Summer of Code.

-A

>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how 
> you interpreted my words!
>
>

Re: [gentoo-dev] How to raise money for Gentoo

[Dale]

wbrana wrote:
> Page www.gentoo.org asks for donations
> "Donate to support our development efforts."
> Gentoo could get more money if all *.gentoo.org would contain advertisements.
>
>


My questions are this:  Does Gentoo need more money?  Is it in need of
more funds to support itself? 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Re: [gentoo-dev] How to raise money for Gentoo

[Alec Warner]

On Thu, Sep 27, 2012 at 3:23 PM, wbrana  wrote:
> Page www.gentoo.org asks for donations
> "Donate to support our development efforts."
> Gentoo could get more money if all *.gentoo.org would contain advertisements.
>

You already filed a bug against infra / www asking for this, and we
told you that we would not do that.

http://www.gentoo.org/foundation/en/cash-sponsors-policy.xml covers
the ad policy. It is not clear to me if adding more paypal links would
actually help us. Paypal revenue seems based more on our popularity
and activity as a whole. Feel free to discuss revenue ideas on
gentoo-...@lists.gentoo.org

-A

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 9:23 AM, wbrana  wrote:
> Page www.gentoo.org asks for donations
> "Donate to support our development efforts."
> Gentoo could get more money if all *.gentoo.org would contain advertisements.

I run a technical website with around 6k visits per day, and my
experience is that ads which aren't irritating and annoying don't pay
much. I had an almost-nice experience with Text-Link-Ads, but they
have a manual URL submission and approval process, and they turned
down my most-trafficked pages.

The other recurring difficulty I've had is finding an ad network which
comprehends technical markets. Since I can't find an ad network which
runs ads relevant to my users, I don't show ads.

-- 
:wq

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Ulrich Mueller]

> On Wed, 26 Sep 2012, Michael Mol wrote:

> A few months ago, I filed bug 423651 to ask that bzip2 on the
> install media be replaced with pbzip2. It was closed a short while
> later, telling me that it'd involve changing what's kept in @system,
> and that had to be discussed here, rather than in a bug report.

We need to be careful when we replace such standard tools. Often the
replacement isn't completely compatible. For example, pbzip2 suffers
from the same bug as pigz [1] when it encounters a zero-padded tarball:

   $ echo foo | bzip2 | dd conv=sync 2>/dev/null | pbzip2 -d
   foo
   pbzip2: *ERROR during BZ2_bzDecompress - trailing garbage: ret=4; block=0; 
seq=0; isLastInSeq=1; avail_in=472
   Terminator thread: premature exit requested - quitting...
   $ echo $?
   1

The same command line as above but with bzip2 -d will return a good
exit status.

Ulrich

[1] 

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Piotr Szymaniak]

On Wed, Sep 26, 2012 at 01:43:27PM -0700, Matt Turner wrote:
> On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol  wrote:
> > A few months ago, I filed bug 423651 to ask that bzip2 on the install
> > media be replaced with
> >  pbzip2. It was closed a short while later, telling me that it'd
> > involve changing what's kept in @system, and that had to be discussed
> > here, rather than in a bug report.
> 
> If we're going to ship a parallel bzip2 implementation, it should be
> lbzip2 and not pbzip2.
> 
> lbzip2 can decompress bz2 archives with multiple threads that haven't
> been compressed with lbzip2/pbzip2.

Afair I'm using PORTAGE_BZIP2_COMMAND with lbzip2 and it works fine.
Also some time ago I've changed a bit the (famous?) stage4 backup
script from g-wiki to support parallel gz/bz2 implementations (simple
check if there pbzip2/lbzip2/foobar installed and if yes, use it instead
of normal gzip/bzip2).

Maybe portage should be like my stage4 mod? If it finds some parallel
(de)compressor it should use it, if not fallback to standard gzip/bzip2?


Piotr Szymaniak.
-- 
 - Jeden hamburger na dziesiec ci zaszkodzi. Jeden moj stary przyjaciel
to sprawdzil.  Zjadal dziewiec hamburgerow i byl idealnie zdrowy, a gdy
probowal zjesc dziesiatego, z miejsca dostawal torsji.
  -- Graham Masterton, "Night Warriors"


signature.asc
Description: Digital signature

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Tobias Klausmann]

Hi! 

On Wed, 26 Sep 2012, Chí-Thanh Christopher Nguyễn wrote:
> A different question is whether in the cases where parallel bzip2 makes
> sense, is it really the best solution? xz is outperforming bzip2's
> compression ratio for large files (for an informal comparison, see bug
> 434350). And xz is faster at decompression, which offsets the parallel
> advantage to some degree.

As for the performance side of things: 
http://blog.i-no.de/archives/2008/05/08/index.html#e2008-05-08T16_35_13.txt

Yes, that's four years old and needs to be redone with modern
implementations (and machines). Will do so this weekend (I hope).

Regards,
Tobias

-- 
printk (KERN_ALERT "You are screwed! " ...);
linux-2.6.6/arch/i386/kernel/efi.c

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Florian Philipp]

Am 26.09.2012 23:53, schrieb Michael Mol:
> On Wed, Sep 26, 2012 at 5:27 PM, Florian Philipp  
> wrote:
>> Am 26.09.2012 22:43, schrieb Matt Turner:
>>> On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol  wrote:
 A few months ago, I filed bug 423651 to ask that bzip2 on the install
 media be replaced with
  pbzip2. It was closed a short while later, telling me that it'd
 involve changing what's kept in @system, and that had to be discussed
 here, rather than in a bug report.
>>>
>>> If we're going to ship a parallel bzip2 implementation, it should be
>>> lbzip2 and not pbzip2.
>>>
>>> lbzip2 can decompress bz2 archives with multiple threads that haven't
>>> been compressed with lbzip2/pbzip2.
>>>
>>
>> This seems relevant, especially comment 12ff:
>> https://bugs.gentoo.org/show_bug.cgi?id=309683
>>
>> For further anecdotal evidence: I've used pbzip2 with USE="symlink" for
>> several months now and never had trouble with it. Checking out lbzip2
>> now. I noticed it doesn't install a bunzip2 symlink.
> 
> Piotr Szymaniak asked me about lbzip2, and I bounced the question over
> to my friend. He didn't investigate it deeply; it crashed (OOM or
> something else, I don't know) when he tried it on a large file. Could
> have been from 2GB to 2TB, from what he has laying around. I don't
> know; I didn't get that one in writing. :)
> 
> But if it proves to be stable for small and very large files, I'd have
> no complaint. :)
> 

I just encountered this:

bzip2 -c /dev/null
bzip2:
/var/tmp/portage/app-arch/lbzip2-2.2/work/lbzip2-2.2/src/encode.c:794:
generate_initial_trees: Assertion `a < b' failed.

Something in that file is upsetting lbzip2. I'm investigating.



signature.asc
Description: OpenPGP digital signature