Mailing List Archive: Gentoo: AMD64

new testing 2004.3 stages

Index | Next | Previous | View Threaded

lv at gentoo

Sep 28, 2004, 10:33 PM

Post #1 of 12 (459 views)
Permalink

new testing 2004.3 stages

I've done a run of stage building using the new 2004.3 profile, and the
results are up: http://dev.gentoo.org/~lv/stages/2004.3/
If you use these stages, make sure you dont downgrade portage to 2.0.50!
2.0.50 will get confused and hang.

I probably wont be doing any new vanilla stages myself, I just wanted to
work through and fix any remaining issues with multilib-by-default stage
building and bootstrapping. there were a few silly bugs that needed
stomping... for example, the 32bit glibc wasnt being installed into the
stage1 stage tarball. *hangs head*

those of you bootstrapping multilib installs with these stages will no
longer get the dreaded "gcc fails to compile at libstdc++ because i have
sandbox enabled" bug, since the stages include a 32bit sandbox. you will
also not have to disable sandbox to install openoffice-bin anymore. the
decision to go multilib-by-default was to avoid these kinds of headaches. :)

also, with the new multilib stages i'm hoping to deprecate (but not get
rid of) grub-static, since grub compiles just fine with a multilib gcc.
grub-static will need to be kept around for non-multilib users, but it
probably wont be touched unless there are critical bugs that need fixing.

for those of you wondering, yes... the stages use gcc 3.4.

and now back to your regularly scheduled releases from jhuebel. :)

Travis Tilley
Gentoo/AMD64

--
gentoo-amd64 [at] gentoo mailing list

kd.drake at comcast

Sep 28, 2004, 10:58 PM

Post #2 of 12 (460 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

"If you use these stages, make sure you dont downgrade portage to 2.0.50!
2.0.50 will get confused and hang."

Huh?

-Kow

--
gentoo-amd64 [at] gentoo mailing list

1i5t5.duncan at cox

Sep 29, 2004, 1:01 AM

Post #3 of 12 (458 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Kow posted <000401c4a5e9$50f65360$538d0f81 [at] kenn>, excerpted below, on
Wed, 29 Sep 2004 06:58:17 +0100:

> "If you use these stages, make sure you dont downgrade portage to 2.0.50!
> 2.0.50 will get confused and hang."
>
> Huh?

Portage 2.0.51 is in rc stage, and is obviously what these are using.
I've been running it for several weeks. It's workable, and has some nice
new features including FEATURES=candy (try it after installation, then do
an emerge sync and watch the post-sync cache update), --newuse (a method
for remerging anything that has use flags that you've changed since the
original merge), and gpg signed ebuild handling (not well documented yet),
as well as new documentation, a good thing since a couple of the 2.0.50
man pages hadn't been updated since 2.0.48.

There's still a few rough edges (I'm about to go look for and potentially
file a bug re binary packages right now), but

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

--
gentoo-amd64 [at] gentoo mailing list

1i5t5.duncan at cox

Sep 29, 2004, 1:24 AM

Post #4 of 12 (454 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Travis Tilley posted <415A490D.5070906 [at] gentoo>, excerpted below, on
Wed, 29 Sep 2004 01:33:01 -0400:

> also, with the new multilib stages i'm hoping to deprecate (but not get
> rid of) grub-static, since grub compiles just fine with a multilib gcc.
> grub-static will need to be kept around for non-multilib users, but it
> probably wont be touched unless there are critical bugs that need fixing.

Any chance of getting LILO working? I know it works on AMD64 (altho it
must be 32-bit, like GRUB), as I kept the Mandrake AMD64 version (which
was the exact same binary RPM as on their i586 product) when I switched,
and recently updated to the 32-bit binary from the LILO home page, after I
tried and failed to get the Gentoo ebuild to compile here, with multi-lib
and -m32.

Again, working LILO binaries work, so it should be /just/ a matter of
invoking the proper patch magic to get it compiling with multi-lib.
Unfortunately, that may be easier said than done. The errors when
attempting the compile here were definitely beyond my very limited
trouble-shooting abilities. (I don't claim to know C, tho I can and do
muddle thru enough of it to fix an occasional problem here or there, if
it's trivial enough.)

If I could get that working, my entire system, save for a single rather
old DOS game (Master of Orion original, (c) 1993, which I still play,
now using dosbox-cvs, which actually works in 64-bit mode, altho the
dosbox regular ebuild won't, tho it compiles.), would be Gentoo
from-source. I don't really want to build and keep updated an entire
32-bit chroot just so I can build LILO from time to time! Using the binary
from the LILO site works, but it's not quite the same as compiling it
myself, so I'd be a happy camper if Gentoo LILO could be made to emerge w/
multi-lib.

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

--
gentoo-amd64 [at] gentoo mailing list

lv at gentoo

Sep 29, 2004, 1:30 AM

Post #5 of 12 (458 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Kow wrote:
> "If you use these stages, make sure you dont downgrade portage to
> 2.0.50! 2.0.50 will get confused and hang."
>
>
> Huh?
>
> -Kow

the stages use portage 2.0.51_rc6, which currently isnt in stable. a
version of .51 should be in stable within a week or two, as it'll be
required for the next release. cascading profiles are somewhat broken
without it... indeed, if you use portage 2.0.50 with our 2004.3 profile
it will simply hang instead of doing anything that you tell it to.

the only other ~amd64 package used in these stages is gcc 3.4.2-r2,
which should also be in stable before release. it's not essential that
you dont downgrade gcc, i used it in these stages simply because it's
what i'm hoping will be used for the final release.

hey... now's as good a time as any to detail a neat little feature with
the new profile. when also using gcc 3.4.2-r2, you can merge something with:

USE_SPECS=hardened emerge <daemon/app/whatever>

and it will be built using the hardened specs, without having to install
hardened gcc as your default system compiler. this allows you to enable
stack smashing protection and address space layout randomisation for the
specific binaries that need it most.

also... if you use hardened gcc as your default compiler, you can merge
something with:

USE_SPECS=vanilla emerge <blah>

and install something that would otherwise be a pain with the hardened
toolchain (like mozilla, which seems to dislike stack smashing
protection, or xorg-x11, which seems to dislike being built as a
position independant executable so far).

ayanami root # USE_SPECS=hardened emerge bash
(compile messages)
ayanami root # file `which bash`
/bin/bash: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV),
not stripped

ayanami root # USE_SPECS=vanilla emerge bash
(compile messages)
ayanami root # file `which bash`
/bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped

...i know bash is a bad example but it compiles quickly. note that
position independant executables show up as "shared object". also note
that the logic for handling USE_SPECS is only in -our- cascading profile
and you need to be using portage 2.0.51 for that logic to work.

Travis Tilley
Gentoo/AMD64

--
gentoo-amd64 [at] gentoo mailing list

1i5t5.duncan at cox

Sep 29, 2004, 3:34 AM

Post #6 of 12 (468 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Travis Tilley posted <415A72BC.1090306 [at] gentoo>, excerpted below, on
Wed, 29 Sep 2004 04:30:52 -0400:

> hey... now's as good a time as any to detail a neat little feature with
> the new profile. when also using gcc 3.4.2-r2, you can merge something with:
>
> USE_SPECS=hardened emerge <daemon/app/whatever>

"I was wondeling" how the spec files I saw mentioned in the changelog
worked. Thanks!

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

--
gentoo-amd64 [at] gentoo mailing list

1i5t5.duncan at cox

Sep 29, 2004, 3:44 AM

Post #7 of 12 (452 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Duncan posted <pan.2004.09.29.10.34.36.139819 [at] cox>, excerpted below,
on Wed, 29 Sep 2004 03:34:36 -0700:

> Travis Tilley posted <415A72BC.1090306 [at] gentoo>, excerpted below, on
> Wed, 29 Sep 2004 04:30:52 -0400:
>
>> hey... now's as good a time as any to detail a neat little feature with
>> the new profile. when also using gcc 3.4.2-r2, you can merge something with:
>>
>> USE_SPECS=hardened emerge <daemon/app/whatever>
>
> "I was wondeling" how the spec files I saw mentioned in the changelog
> worked. Thanks!

BTW, Travis, will setting USE_SPECS in make.conf work as well? I ask
because I usually keep commented out versions of this sort of thing in
there, so I know where to look next time I need it. Thus, quickly
removing a # and saving the file, for a single emerge, then adding the #
back, is actually easier since I'm looking at the file already when I go
to use the feature, than actually typing it out onto the command line.
However, I've had mixed luck with that, I'm guessing because Portage gets
picky about what it adds to the environment, from there. Thus, knowing in
advance whether it works from make.conf is helpful.

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

--
gentoo-amd64 [at] gentoo mailing list

kd.drake at comcast

Sep 29, 2004, 7:29 AM

Post #8 of 12 (454 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

I was more looking at the typo.. he wants you to downgrade to 2.0.50 while
"2.0.50 will get confused and hang."...

-Kow
----- Original Message -----
From: "Travis Tilley" <lv [at] gentoo>
To: <gentoo-amd64 [at] lists>
Sent: Wednesday, September 29, 2004 9:30
Subject: Re: [gentoo-amd64] new testing 2004.3 stages

> Kow wrote:
>> "If you use these stages, make sure you dont downgrade portage to 2.0.50!
>> 2.0.50 will get confused and hang."
>>
>>
>> Huh?
>>
>> -Kow
>
> the stages use portage 2.0.51_rc6, which currently isnt in stable. a
> version of .51 should be in stable within a week or two, as it'll be
> required for the next release. cascading profiles are somewhat broken
> without it... indeed, if you use portage 2.0.50 with our 2004.3 profile it
> will simply hang instead of doing anything that you tell it to.
>
> the only other ~amd64 package used in these stages is gcc 3.4.2-r2, which
> should also be in stable before release. it's not essential that you dont
> downgrade gcc, i used it in these stages simply because it's what i'm
> hoping will be used for the final release.
>
>
> hey... now's as good a time as any to detail a neat little feature with
> the new profile. when also using gcc 3.4.2-r2, you can merge something
> with:
>
> USE_SPECS=hardened emerge <daemon/app/whatever>
>
> and it will be built using the hardened specs, without having to install
> hardened gcc as your default system compiler. this allows you to enable
> stack smashing protection and address space layout randomisation for the
> specific binaries that need it most.
>
> also... if you use hardened gcc as your default compiler, you can merge
> something with:
>
> USE_SPECS=vanilla emerge <blah>
>
> and install something that would otherwise be a pain with the hardened
> toolchain (like mozilla, which seems to dislike stack smashing protection,
> or xorg-x11, which seems to dislike being built as a position independant
> executable so far).
>
>
> ayanami root # USE_SPECS=hardened emerge bash
> (compile messages)
> ayanami root # file `which bash`
> /bin/bash: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not
> stripped
>
> ayanami root # USE_SPECS=vanilla emerge bash
> (compile messages)
> ayanami root # file `which bash`
> /bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
> GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
>
>
> ...i know bash is a bad example but it compiles quickly. note that
> position independant executables show up as "shared object". also note
> that the logic for handling USE_SPECS is only in -our- cascading profile
> and you need to be using portage 2.0.51 for that logic to work.
>
>
> Travis Tilley
> Gentoo/AMD64
>
> --
> gentoo-amd64 [at] gentoo mailing list
>

--
gentoo-amd64 [at] gentoo mailing list

lv at gentoo

Sep 29, 2004, 11:47 AM

Post #9 of 12 (457 views)
Permalink

Re: new testing 2004.3 stages [In reply to]

Kow wrote:
> I was more looking at the typo.. he wants you to downgrade to 2.0.50
> while "2.0.50 will get confused and hang."...
>
> -Kow

re-read my message a few times... make sure you DO NOT downgrade to
2.0.50. 2.0.50 WILL HANG. that's what i said, no typo.

--
gentoo-amd64 [at] gentoo mailing list

lv at gentoo

Sep 29, 2004, 11:49 AM

Post #10 of 12 (458 views)
Permalink

Re: Re: new testing 2004.3 stages [In reply to]

Duncan wrote:
> BTW, Travis, will setting USE_SPECS in make.conf work as well? I ask
> because I usually keep commented out versions of this sort of thing in
> there, so I know where to look next time I need it. Thus, quickly
> removing a # and saving the file, for a single emerge, then adding the #
> back, is actually easier since I'm looking at the file already when I go
> to use the feature, than actually typing it out onto the command line.
> However, I've had mixed luck with that, I'm guessing because Portage gets
> picky about what it adds to the environment, from there. Thus, knowing in
> advance whether it works from make.conf is helpful.

any variable you can set on the commandline -should- also work from
make.conf.

--
gentoo-amd64 [at] gentoo mailing list

beolach at comcast

Sep 29, 2004, 1:19 PM

Post #11 of 12 (460 views)
Permalink

Re: Re: new testing 2004.3 stages [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Kow posted <000401c4a5e9$50f65360$538d0f81 [at] kenn>, excerpted below, on
> Wed, 29 Sep 2004 06:58:17 +0100:
>
>
>>"If you use these stages, make sure you dont downgrade portage to 2.0.50!
>>2.0.50 will get confused and hang."
>>
>>Huh?
>
>
> Portage 2.0.51 is in rc stage, and is obviously what these are using.
> I've been running it for several weeks. It's workable, and has some nice
> new features including FEATURES=candy (try it after installation, then do
> an emerge sync and watch the post-sync cache update), --newuse (a method
> for remerging anything that has use flags that you've changed since the
> original merge), and gpg signed ebuild handling (not well documented yet),
> as well as new documentation, a good thing since a couple of the 2.0.50
> man pages hadn't been updated since 2.0.48.
>
> There's still a few rough edges (I'm about to go look for and potentially
> file a bug re binary packages right now), but
>

- --newuse Yippee! No more
# emerge --verbose --pretend --emptytree world | grep <USEFLAG>

I play around w/ USE flags too much...

Conway S. Smith
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBWxjOGL3AU+cCPDERAhcYAJ91jpl7oJBsis5mV2rqQUlSo5YNIgCbB6q8
FBqhtj4IRZG7MQLd+90wZMQ=
=A77C
-----END PGP SIGNATURE-----

--
gentoo-amd64 [at] gentoo mailing list

1i5t5.duncan at cox

Sep 30, 2004, 2:53 AM

Post #12 of 12 (459 views)
Permalink

Re: Re: new testing 2004.3 stages [In reply to]

Travis Tilley posted <415B03AB.8020303 [at] gentoo>, excerpted below, on
Wed, 29 Sep 2004 14:49:15 -0400:

> any variable you can set on the commandline -should- also work from
> make.conf.

Cool! That's what I first assumed, but then read an offhand statement (on
devel, I think) to the effect that portage parses it and only puts what it
knows about in the environment for use by make and the like. That sounded
a bit strange to me but possible, and I thought it might explain why a
couple things that should have worked from whatever (either upstream or
specific ebuild) documentation didn't appear to get noticed, from
make.conf. Before I read that, I had decided the documentation was likely
outdated or didn't apply to amd64, which seems more likely, and if Portage
simply puts everything it doesn't specifically know to deal with in other
ways, that makes sense.

--
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

--
gentoo-amd64 [at] gentoo mailing list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads