[gentoo-catalyst] specifying global USE

[gentoo-catalyst] specifying global USE

[Jeff Davidson]

I'm working on my own set of stage tarballs since I want a few USE flags 
that differ from the default, namely:

nptl nptlonly userlocales -ipv6 -fortran -nls

However, it looks like glibc wasn't compiling with my flags, since it 
was working in a -linuxthreads directory instead of an -nptl 
directory.   So, two questions:

1) Why isn't the USE setting from my envscript not going through?

bash-2.05b# cat /etc/catalyst/catalyst.conf | grep envscript=
envscript="/root/livecd/catalyst-env.sh"

bash-2.05b# cat /root/livecd/catalyst-env.sh
export GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo"
export USE="nptl nptlonly userlocales -fortran -ipv6 -nls"

2) Just out of curiousity, does the portage_confdir setting work in the 
stage builds?  I understand I could do this, but for things like nptl, 
ipv6, and nls, there are so many packages with these USE flags that to 
go through and add a listing for each one manually seems like overkill 
to me.

Thanks,
-Monkey
--
gentoo-catalyst@gentoo.org mailing list

[gentoo-catalyst] python-fchksum error - looking for wrong gcc? (was: specifying global USE)

[Jeff Davidson]

To answer my own question, the stage1 build seems to disable USE, but
it seems to work (somewhat) in the stage2 build.  Nothing I do can get
glibc not to build every locale, but I'll assume its supposed to be
like that.

And now for a more annoying problem:  My stage3 fails on
python-fchksum, which for some odd reason was trying to use
i386-pc-linux-gnu-gcc instead of the i686 gcc I have installed.  In
the catalyst-generated tarball, there were two i386-pc gcc files that
I thought were generating this error, but when I removed them and
retarred the file I still got it (although it changed from gcc-config
complaining to a simple file not found):

>>> Source unpacked.
['setup.py', 'build']
running build
running build_ext
building 'fchksum' extension
creating build
creating build/temp.linux-i686-2.3
i386-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -O2
-march=i686 -fomit-frame-pointer -fPIC -I/usr/include/python2.3 -c
md5.c -o build/temp.linux-i686-2.3/md5.o
unable to execute i386-pc-linux-gnu-gcc: No such file or directory
error: command 'i386-pc-linux-gnu-gcc' failed with exit status 1

!!! ERROR: dev-python/python-fchksum-1.7.1 failed.
!!! Function src_compile, Line 22, Exitcode 1
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Why the heck is it doing this? Thanks in advance for the help.

On Apr 2, 2005 10:39 AM, Jeff Davidson <supermonkey@gmail.com> wrote:
> I'm working on my own set of stage tarballs since I want a few USE flags
> that differ from the default, namely:
> 
> nptl nptlonly userlocales -ipv6 -fortran -nls
> 
> However, it looks like glibc wasn't compiling with my flags, since it
> was working in a -linuxthreads directory instead of an -nptl
> directory.   So, two questions:
> 
> 1) Why isn't the USE setting from my envscript not going through?
> 
> bash-2.05b# cat /etc/catalyst/catalyst.conf | grep envscript=
> envscript="/root/livecd/catalyst-env.sh"
> 
> bash-2.05b# cat /root/livecd/catalyst-env.sh
> export GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo"
> export USE="nptl nptlonly userlocales -fortran -ipv6 -nls"
> 
> 2) Just out of curiousity, does the portage_confdir setting work in the
> stage builds?  I understand I could do this, but for things like nptl,
> ipv6, and nls, there are so many packages with these USE flags that to
> go through and add a listing for each one manually seems like overkill
> to me.
> 
> Thanks,
> -Monkey
>
--
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] python-fchksum error - looking for wrong gcc? (was: specifying global USE)

[bob p]

On Apr 3, 2005 6:34 AM, Jeff Davidson <supermonkey@gmail.com> wrote:

> And now for a more annoying problem:  My stage3 fails on
> python-fchksum, which for some odd reason was trying to use
> i386-pc-linux-gnu-gcc instead of the i686 gcc I have installed.  In
> the catalyst-generated tarball, there were two i386-pc gcc files that
> I thought were generating this error, but when I removed them and
> retarred the file I still got it (although it changed from gcc-config
> complaining to a simple file not found):

Hi.  I'm new to the list.

Jeff, I've seen this problem before.  Ryan (Sith) had commented that
he had also seen the problem with python-fchksum occurring when he was
rebuilding a GCC 343 toolkit on a 2005.0 installation.  He said that,
"the ebuild compiles using python, and if python has been compiled
using an older gcc compiler, then it uses that compiler to build
python-fchsum, which causes cflag problems (with -mtune)."
Interestingly, he only noticed this problem occurring with the x86
stageball and not any of the stageballs based on i686.

I'm thinking that this problem could be caused by the retention of
static libraries from the previous version of GCC.  I would try
"emerge -e system && emerge -e system" and see if that makes the
problem go away.

Just an idea.  I hope it works.

bob
--
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] python-fchksum error - looking for wrong gcc?

[Jeff Davidson]

Hey Bob, It's monkey89 from the forum post. :)

Yeah, I noticed you had an error with python-fchksum, and I was hoping 
that this was it, but it's a different error - I'm sticking with gcc 
3.3.4 and there's no mtune used - this is all default catalyst stuff.

I guess it might be possible to work around this by chrooting into the 
stage tarball and messing with it there, but I'd like to use pure 
catalyst without having to do anything extra, and it has definitely 
worked in the past.

-Monkey

bob p wrote:

>On Apr 3, 2005 6:34 AM, Jeff Davidson <supermonkey@gmail.com> wrote:
>
>  
>
>>And now for a more annoying problem:  My stage3 fails on
>>python-fchksum, which for some odd reason was trying to use
>>i386-pc-linux-gnu-gcc instead of the i686 gcc I have installed.  In
>>the catalyst-generated tarball, there were two i386-pc gcc files that
>>I thought were generating this error, but when I removed them and
>>retarred the file I still got it (although it changed from gcc-config
>>complaining to a simple file not found):
>>    
>>
>
>Hi.  I'm new to the list.
>
>Jeff, I've seen this problem before.  Ryan (Sith) had commented that
>he had also seen the problem with python-fchksum occurring when he was
>rebuilding a GCC 343 toolkit on a 2005.0 installation.  He said that,
>"the ebuild compiles using python, and if python has been compiled
>using an older gcc compiler, then it uses that compiler to build
>python-fchsum, which causes cflag problems (with -mtune)."
>Interestingly, he only noticed this problem occurring with the x86
>stageball and not any of the stageballs based on i686.
>
>I'm thinking that this problem could be caused by the retention of
>static libraries from the previous version of GCC.  I would try
>"emerge -e system && emerge -e system" and see if that makes the
>problem go away.
>
>Just an idea.  I hope it works.
>
>bob
>--
>gentoo-catalyst@gentoo.org mailing list
>
>
>  
>

--
gentoo-catalyst@gentoo.org mailing list

Re: [gentoo-catalyst] python-fchksum error - looking for wrong gcc?

[Jeff Davidson]

I'm still getting this problem.  I even did a fresh gentoo install on
vmware and tried there with spec files copied exactly from
livecd-specs-2005.0, the only changes being a newer snapshot and the
use of the 2005.0 stage to build instead of 2004.3-r1 (which I can't
find anywhere).

The build is for i686 - why is python-fchksum trying to use i386?

>>> emerge (10 of 88) dev-python/python-fchksum-1.7.1 to /
>>> md5 src_uri ;-) python-fchksum-1.7.1.tar.gz
>>> Unpacking source...
>>> Unpacking python-fchksum-1.7.1.tar.gz to
/var/tmp/portage/python-fchksum-1.7.1/work
>>> Source unpacked.
['setup.py', 'build']
running build
running build_ext
building 'fchksum' extension
creating build
creating build/temp.linux-i686-2.3
i386-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -O2
-march=i686 -fomit-frame-pointer -fPIC -I/usr/include/python2.3 -c
md5.c -o build/temp.linux-i686-2.3/md5.o
gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"
error: command 'i386-pc-linux-gnu-gcc' failed with exit status 1

!!! ERROR: dev-python/python-fchksum-1.7.1 failed.
!!! Function src_compile, Line 22, Exitcode 1
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

Might be slight typos, had to type that from scratch, but you get the
idea.  I can't imagine that I'm the only one coming across this bug -
I'm using generic spec files, and a completely fresh install w/
catalyst 1.1.8 in vmware.

-Jeff

On Apr 3, 2005 9:02 PM, Jeff Davidson <supermonkey@gmail.com> wrote:
> Hey Bob, It's monkey89 from the forum post. :)
> 
> Yeah, I noticed you had an error with python-fchksum, and I was hoping
> that this was it, but it's a different error - I'm sticking with gcc
> 3.3.4 and there's no mtune used - this is all default catalyst stuff.
> 
> I guess it might be possible to work around this by chrooting into the
> stage tarball and messing with it there, but I'd like to use pure
> catalyst without having to do anything extra, and it has definitely
> worked in the past.
> 
> -Monkey
> 
> bob p wrote:
> 
> >On Apr 3, 2005 6:34 AM, Jeff Davidson <supermonkey@gmail.com> wrote:
> >
> >
> >
> >>And now for a more annoying problem:  My stage3 fails on
> >>python-fchksum, which for some odd reason was trying to use
> >>i386-pc-linux-gnu-gcc instead of the i686 gcc I have installed.  In
> >>the catalyst-generated tarball, there were two i386-pc gcc files that
> >>I thought were generating this error, but when I removed them and
> >>retarred the file I still got it (although it changed from gcc-config
> >>complaining to a simple file not found):
> >>
> >>
> >
> >Hi.  I'm new to the list.
> >
> >Jeff, I've seen this problem before.  Ryan (Sith) had commented that
> >he had also seen the problem with python-fchksum occurring when he was
> >rebuilding a GCC 343 toolkit on a 2005.0 installation.  He said that,
> >"the ebuild compiles using python, and if python has been compiled
> >using an older gcc compiler, then it uses that compiler to build
> >python-fchsum, which causes cflag problems (with -mtune)."
> >Interestingly, he only noticed this problem occurring with the x86
> >stageball and not any of the stageballs based on i686.
> >
> >I'm thinking that this problem could be caused by the retention of
> >static libraries from the previous version of GCC.  I would try
> >"emerge -e system && emerge -e system" and see if that makes the
> >problem go away.
> >
> >Just an idea.  I hope it works.
> >
> >bob
> >--
> >gentoo-catalyst@gentoo.org mailing list
> >
> >
> >
> >
> 
>
--
gentoo-catalyst@gentoo.org mailing list