[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Donnie Berkholz]

On 18:20 Mon 18 Feb     , Sven Wegener (swegener) wrote:
> swegener    08/02/18 18:20:47
> 
>   Modified:             flag-o-matic.eclass
>   Log:
>   redirect the ewarn message to stderr
> 
> Revision  Changes    Path
> 1.122                eclass/flag-o-matic.eclass
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.122&content-type=text/plain
> diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.121&r2=1.122

> @@ -614,7 +614,7 @@
>  # @DESCRIPTION:
>  # DEPRECATED - Gets the flags needed for "NOW" binding
>  bindnow-flags() {
> -	ewarn "QA: stop using the bindnow-flags function ... simply drop it from your ebuild"
> +	ewarn "QA: stop using the bindnow-flags function ... simply drop it from your ebuild" >&2

This seems like something ewarn should do on its own.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Roy Marples]

On Monday 18 February 2008 21:20:52 Donnie Berkholz wrote:
> > @@ -614,7 +614,7 @@
> >  # @DESCRIPTION:
> >  # DEPRECATED - Gets the flags needed for "NOW" binding
> >  bindnow-flags() {
> > -	ewarn "QA: stop using the bindnow-flags function ... simply drop it
> > from your ebuild" +	ewarn "QA: stop using the bindnow-flags function ...
> > simply drop it from your ebuild" >&2
>
> This seems like something ewarn should do on its own.

baselayout and portage have always echoed ewarn to stdout and not stderr.

Warnings are NOT errors, so why use stderr? If it's an error, use eerror which 
DOES goto stderr.

Thanks

Roy
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Mon, 18 Feb 2008 13:20:52 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> This seems like something ewarn should do on its own.

http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140

http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121&view=markup

http://thread.gmane.org/gmane.linux.gentoo.user/194929

hth,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Donnie Berkholz]

On 21:37 Mon 18 Feb     , Ciaran McCreesh wrote:
> On Mon, 18 Feb 2008 13:20:52 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > This seems like something ewarn should do on its own.
> 
> http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140

Alright, so portage has put this stuff to stderr since January 4. Then 
why are we also adding workarounds to individual eclasses?

> http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.121&view=markup

I'm not sure what I'm supposed to get out of this, besides seeing that a 
lot of stuff is sent to stderr.

> http://thread.gmane.org/gmane.linux.gentoo.user/194929

Right, I figured the reason was something along the lines of info going 
to stdout when only flags should.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Mon, 18 Feb 2008 13:54:34 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140
> 
> Alright, so portage has put this stuff to stderr since January 4.
> Then why are we also adding workarounds to individual eclasses?

How many people are running a Portage version released after January 4?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ryan Hill]

Ciaran McCreesh wrote:
> On Mon, 18 Feb 2008 13:54:34 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>> http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140
>> Alright, so portage has put this stuff to stderr since January 4.
>> Then why are we also adding workarounds to individual eclasses?
> 
> How many people are running a Portage version released after January 4?

Eventually, all of them.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Mon, 18 Feb 2008 16:26:11 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 18 Feb 2008 13:54:34 -0800
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> >>> http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140
> >> Alright, so portage has put this stuff to stderr since January 4.
> >> Then why are we also adding workarounds to individual eclasses?
> > 
> > How many people are running a Portage version released after
> > January 4?
> 
> Eventually, all of them.

And until then, how many users are going to get things going weirdly
wrong if workarounds aren't added to everything using the code?

I'd mutter something about EAPIs here, but really if people are having
difficulty understanding the necessity of the original commit, I
suspect it's a lost cause...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Doug Klima]

Ciaran McCreesh wrote:
> On Mon, 18 Feb 2008 16:26:11 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Mon, 18 Feb 2008 13:54:34 -0800
>>> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>>>> http://sources.gentoo.org/viewcvs.py/portage/main/trunk/bin/isolated-functions.sh?r1=9118&r2=9140
>>>> Alright, so portage has put this stuff to stderr since January 4.
>>>> Then why are we also adding workarounds to individual eclasses?
>>> How many people are running a Portage version released after
>>> January 4?
>> Eventually, all of them.
> 
> And until then, how many users are going to get things going weirdly
> wrong if workarounds aren't added to everything using the code?
> 
> I'd mutter something about EAPIs here, but really if people are having
> difficulty understanding the necessity of the original commit, I
> suspect it's a lost cause...
> 

6

-- 
Doug Klima <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Mon, 18 Feb 2008 18:15:18 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> >>> How many people are running a Portage version released after
> >>> January 4?
> >> Eventually, all of them.
> > 
> > And until then, how many users are going to get things going weirdly
> > wrong if workarounds aren't added to everything using the code?
>
> 6

You think there are 6 people running stable Portage? Either you think
all the users (including those installing off old stages) are running
~arch, or you think Gentoo has died, or you think everyone's moved to
Paludis...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Doug Klima]

Ciaran McCreesh wrote:
> On Mon, 18 Feb 2008 18:15:18 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
>>>>> How many people are running a Portage version released after
>>>>> January 4?
>>>> Eventually, all of them.
>>> And until then, how many users are going to get things going weirdly
>>> wrong if workarounds aren't added to everything using the code?
>> 6
> 
> You think there are 6 people running stable Portage? Either you think
> all the users (including those installing off old stages) are running
> ~arch, or you think Gentoo has died, or you think everyone's moved to
> Paludis...
> 

Stupid questions deserve stupid answers. So I arbitrarily picked a 
number and gave it to you.

A better statement on your part would have been "We need to ensure 
compatibility for the greatest amount of users and requiring users to 
have a version of Portage released after January 4th when it's only the 
middle of February is not going to ensure the greatest compatibility. 
The previous policy was always 6 months between breaks like this." 
You're free to reword the above to however you see fit.

-- 
Doug Klima <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Tue, 19 Feb 2008 08:44:43 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> A better statement on your part would have been "We need to ensure 
> compatibility for the greatest amount of users and requiring users to 
> have a version of Portage released after January 4th when it's only
> the middle of February is not going to ensure the greatest
> compatibility. The previous policy was always 6 months between breaks
> like this." You're free to reword the above to however you see fit.

You mean "the change should of course have been an EAPI bump".

hth,
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Doug Klima]

Ciaran McCreesh wrote:
> On Tue, 19 Feb 2008 08:44:43 -0500
> Doug Klima <cardoe@gentoo.org> wrote:
>   
>> A better statement on your part would have been "We need to ensure 
>> compatibility for the greatest amount of users and requiring users to 
>> have a version of Portage released after January 4th when it's only
>> the middle of February is not going to ensure the greatest
>> compatibility. The previous policy was always 6 months between breaks
>> like this." You're free to reword the above to however you see fit.
>>     
>
> You mean "the change should of course have been an EAPI bump".
>
> hth,
>   
As it's been explained to me by one of your fellow PMS developers, since 
EAPI=0 is not complete yet, there will be no work on further EAPIs until 
EAPI=0 is complete. Since this is the case and we still need to make 
changes, we must revert back to the previous policy with regard to changes.

I personally would love to see EAPI=0 published as a draft for users and 
developers to see. I feel that it's going to be one of those things 
that's going to be difficult to nail down do the the nature of a whole 
package manager being developed without any specifications . Writing a 
concrete set of specifications after the fact, which encompass every 
little nook and cranny, is a difficult and tedious process that requires 
testing every single code path.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Doug Klima <cardoe@gentoo.org> said:
> As it's been explained to me by one of your fellow PMS developers, since 
> EAPI=0 is not complete yet, there will be no work on further EAPIs until 
> EAPI=0 is complete. Since this is the case and we still need to make 
> changes, we must revert back to the previous policy with regard to changes.

Just to clarify slightly:

I won't be working on anything other than EAPI=0.  Other people may be,
but the council said in the latest meeting that they feel we should get
EAPI=0 done before adding any new EAPIs to the tree.

-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Tue, 19 Feb 2008 09:42:43 -0500
Doug Klima <cardoe@gentoo.org> wrote:
> As it's been explained to me by one of your fellow PMS developers,
> since EAPI=0 is not complete yet, there will be no work on further
> EAPIs until EAPI=0 is complete.

No-one who has worked upon PMS has said that.

> I personally would love to see EAPI=0 published as a draft for users
> and developers to see.

PMS drafts have been available for ages.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

On Sat, 04 Apr 2009 17:57:54 +0000
"Fabian Groffen (grobian)" <grobian@gentoo.org> wrote:

> grobian     09/04/04 17:57:54
> 
>   Modified:             flag-o-matic.eclass
>   Log:
>   backport fix for x86-macos in filter-flags from Prefix
> 
> Revision  Changes    Path
> 1.133                eclass/flag-o-matic.eclass
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?rev=1.133&content-type=text/plain
> diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.132&r2=1.133
> 
> Index: flag-o-matic.eclass
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v
> retrieving revision 1.132
> retrieving revision 1.133
> diff -u -r1.132 -r1.133
> --- flag-o-matic.eclass	21 Jan 2009 00:42:20 -0000	1.132
> +++ flag-o-matic.eclass	4 Apr 2009 17:57:54 -0000	1.133
> @@ -1,6 +1,6 @@
>  # Copyright 1999-2009 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.132 2009/01/21 00:42:20 gengor Exp $
> +# $Header: /var/cvsroot/gentoo-x86/eclass/flag-o-matic.eclass,v 1.133 2009/04/04 17:57:54 grobian Exp $
>  
>  # @ECLASS: flag-o-matic.eclass
>  # @MAINTAINER:
> @@ -52,6 +52,12 @@
>  		-m32 -m64 -mabi -mlittle-endian -mbig-endian -EL -EB -fPIC \
>  		-mlive-g0 -mcmodel -mstack-bias -mno-stack-bias \
>  		-msecure-plt -m*-toc -D* -U*"
> +	
> +	# killing these two on OSX/Intel will disable SSE, resulting in failing
> +	# compilations, as the headers expect SSE to be enabled (Apple knows what
> +	# hardware they run on afterall, don't they?)
> +	[[ ${CHOST} == i?86-apple-darwin* ]] \
> +		&& ALLOWED_FLAGS="${ALLOWED_FLAGS} -march=prescott -march=nocona"
>  

Why do these have to be specifically included?  Aren't they handed by 

  34         export ALLOWED_FLAGS="${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu -march -mtune"



-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass

[Fabian Groffen]

On 04-04-2009 18:49:50 -0600, Ryan Hill wrote:
> > +	# killing these two on OSX/Intel will disable SSE, resulting in failing
> > +	# compilations, as the headers expect SSE to be enabled (Apple knows what
> > +	# hardware they run on afterall, don't they?)
> > +	[[ ${CHOST} == i?86-apple-darwin* ]] \
> > +		&& ALLOWED_FLAGS="${ALLOWED_FLAGS} -march=prescott -march=nocona"
> >  
> 
> Why do these have to be specifically included?  Aren't they handed by 
> 
>   34         export ALLOWED_FLAGS="${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu -march -mtune"

Looking at the current code, it can't even work properly.  Even in the
case when ALLOWED_FLAGS is already set.

	if [[ -z ${ALLOWED_FLAGS} ]] ; then
			export ALLOWED_FLAGS="-pipe"
			export ALLOWED_FLAGS="${ALLOWED_FLAGS} -O -O0 -O1 -O2 -mcpu -march"

Weird enough, it /did/ enable compilations to succeed in the past, but
it just can't in the current eclass, so it's bogus, and I will remove it
again.

Thanks for the check, much appreciated!


-- 
Fabian Groffen
Gentoo on a different level