Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 23:41 -0500, Andrew Muraco wrote: Out of curiosity, if this goes into effect before 2006.0 is released, then ALL the stages for x86 and the livecd would be built with gcc34? If so then I think this may benefit alot of users, especially ones that do a stage1/2 just so they can shove gcc34 into there system at an early stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see as a bigger problem for those of us that are already running gcc34. But I'm sure many ~x86 users would welcome that, after all what fun is ~x86 without some breakage every now and then ;-) 2006.0 is still a ways off, but yes, all of the stages would be built with gcc 3.4 exclusively. Of course, this would happen whether we made the change globally (for x86) or if we only did it via profile. The problem with doing it via profile is we *already have* people on 2005.0 and 2005.1 profiles running gcc 3.4, so it means causing a much more disruptive upgrade for all ~x86 users, or anyone who has merged gcc 3.4 explicitly already. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Addition of DVB_CARDS to USE_EXPAND
On Wed, 2005-11-30 at 07:01 +0100, Matthias Schwarzott wrote: On Monday 28 November 2005 22:37, Chris Gianelloni wrote: On Mon, 2005-11-28 at 21:53 +0100, Matthias Schwarzott wrote: Hi! If nobody objects I will add DVB_CARDS to USE_EXAPAND on next saturday (2005/12/03). This will be used to decide which firmware-file to download and install within the to be created media-tv/linuxtv-dvb-firmware ebuild. What will the ebuild do if DVB_CARDS is not set? Please make it download/install them all. No problem making the default installing all. (That means around ~60Mb download for the whole packet which makes it a bit uncomfortable for users. Installed are just the ~2Mb of firmware files. Most firmware files are contained in driver-files which are around 10mb per driver/firmware file (extracted firmware file is only some kb) but must not be extracted and mirrored cause of license. Before being sure I have to check the licenses inside these driver archives. Up to now I have not found a license file inside every archive.) The main thing is if it is ever included into a release or binary package, it should work on all systems. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 23:41 -0500, Andrew Muraco wrote: Out of curiosity, if this goes into effect before 2006.0 is released, then ALL the stages for x86 and the livecd would be built with gcc34? If so then I think this may benefit alot of users, especially ones that do a stage1/2 just so they can shove gcc34 into there system at an early stage. Also, if gcc34 gets moved to x86, would gcc40 be ~x86? This I see as a bigger problem for those of us that are already running gcc34. But I'm sure many ~x86 users would welcome that, after all what fun is ~x86 without some breakage every now and then ;-) 2006.0 is still a ways off, but yes, all of the stages would be built with gcc 3.4 exclusively. Of course, this would happen whether we made the change globally (for x86) or if we only did it via profile. The problem with doing it via profile is we *already have* people on 2005.0 and 2005.1 profiles running gcc 3.4, so it means causing a much more disruptive upgrade for all ~x86 users, or anyone who has merged gcc 3.4 explicitly already. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux Again, would anyone know what will happen to ~x86 gcc?, Will it become gcc40 or just use the stable x86 gcc for everyone? (except those who are already playing with gcc40 at their own risk) Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] apache2 default for 2006.0
Chris Gianelloni wrote: Here's the deal. We have a new user that installs Gentoo. After installing Gentoo, he tries to emerge nagios and it dies on building apache over a bug that has been known for some time and still isn't resolved. How exactly does that make us look? How exactly does that make Release Engineering look when a default install cannot even install apache properly? APACHE!!! Whether we are responsible for apache or not, we *are* responsible for the release. Having things completely broken in the default install is *not* acceptable. The bug was reported in June and while there has been some action in the bug, no fix has been issued. Again, this is *not* acceptable. Now, because of this, it is my determination that we have a serious problem that *will* affect the 2006.0 release, and I am trying to do something proactive to prevent it. Case in point: I built a fresh, iso downloaded this weekend from w.g.o, and i failed to bring portage up to date before installing the stable apache2 - and what i got was broken because it was lacking the enewuser for apache (it built, installed, etc. - just couldn't run without either manually adding the user or syncing the dead-end box). And this was on a 100% stable box using the iso at http://bouncer.gentoo.org/?product=gentoo-2005.1-install-minimumos=x86 (link off the where page). OK, so I'm not bright for not syncing before starting emerging - but i can't imagine a new to gentoo user, not quite up with the portage changes by the nanosecond would think to sync after building from a livecd. just my two insert monatary system here worth :) ~mcummings -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
[EMAIL PROTECTED] writes: Again, would anyone know what will happen to ~x86 gcc?, Will it become gcc40 or just use the stable x86 gcc for everyone? (except those who are already playing with gcc40 at their own risk) Even if ~x86 does change to gcc40 then gcc is slotted so we can continue to use gcc3.4.4. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] apache2 default for 2006.0
On Wed, 2005-11-30 at 09:22 -0500, Michael Cummings wrote: Chris Gianelloni wrote: Here's the deal. We have a new user that installs Gentoo. After installing Gentoo, he tries to emerge nagios and it dies on building apache over a bug that has been known for some time and still isn't resolved. How exactly does that make us look? How exactly does that make Release Engineering look when a default install cannot even install apache properly? APACHE!!! Whether we are responsible for apache or not, we *are* responsible for the release. Having things completely broken in the default install is *not* acceptable. The bug was reported in June and while there has been some action in the bug, no fix has been issued. Again, this is *not* acceptable. Now, because of this, it is my determination that we have a serious problem that *will* affect the 2006.0 release, and I am trying to do something proactive to prevent it. Case in point: I built a fresh, iso downloaded this weekend from w.g.o, and i failed to bring portage up to date before installing the stable apache2 - and what i got was broken because it was lacking the enewuser for apache (it built, installed, etc. - just couldn't run without either manually adding the user or syncing the dead-end box). And this was on a 100% stable box using the iso at http://bouncer.gentoo.org/?product=gentoo-2005.1-install-minimumos=x86 (link off the where page). Thanks for the reminder... bug #114020... :P Anyway, what I am suggesting would not have resolved this issue for you. OK, so I'm not bright for not syncing before starting emerging - but i can't imagine a new to gentoo user, not quite up with the portage changes by the nanosecond would think to sync after building from a livecd. A new user would likely be reading the Handbook, which has the user perform an emerge --sync (except for GRP). -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
On Fri, 2005-11-25 at 19:24 +, Mike Frysinger wrote: I'm looking to minimize what is in a stage1 tarball, not increase it. I would much prefer that we instead had a proper dependency tree, than hacking around it. Applications that need to add users on Linux *should* DEPEND on shadow. They should not rely on it being already present. and when we move the user management hacks out of eclasses and into portage itself, where do you think shadow will end up ? in stage1 is my guess Well, apparently with shadow in packages.build we can no longer build a stage1 tarball from a stage3. We also cannot bootstrap, as both of these tasks strip a large number of USE flags. As soon as I removed shadow from packages.build, my builds resumed working. i wouldnt qualify shadow as a part of a proper dependency tree since it's the ebuild itself that requires it, not the package It is required by our ebuild to build the package. I'd call that a dependency. If you want to call it a dependency of the eclass or portage or whatever, I don't care. It is still a dependency in the dependency tree. Plus, your solution does not work retroactively to repair issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does. tell users to stop using stage[12], you're already going that route :p That still will not fix the issue. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mark Loeser [EMAIL PROTECTED] said: Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. I'm not sure how other archs handled the migration, but I haven't been able to find any docs online. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpq7g9SRNKO0.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Mark Loeser wrote: So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. gentoo-announce at least. I wish emerge --news was already here. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, Nov 30, 2005 at 01:56:40PM -0500, Mark Loeser wrote: Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I don't think a whole doc is necessary, but instructions for a safe upgrade would be fine. A think a one-liner like emerge -u gcc emerge -e system emerge -e world emerge -P gcc emerge whateverneedstobedoneafterwards should suffice as documentation. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. Maybe people look closer if they upgrade gcc, but einfo still gets overlooked easily. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. Assuming a clear upgrade path is provided i think it would be fine. We'll make some sticky thread on the forum mentioning that instructions, i bet it couldn't hurt to put them on the gentoo mainpage, as topic in #gentoo etc. I'm also pretty sure next GWN is likely to report about the update. Just because we haven't got emerge --news it doesn't mean we haven't got lots of ways to reach our users. Every user that gets to read them in time is a potential bug report less. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Wernfried Haas wrote: On Wed, Nov 30, 2005 at 01:56:40PM -0500, Mark Loeser wrote: Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I don't think a whole doc is necessary, but instructions for a safe upgrade would be fine. A think a one-liner like emerge -u gcc emerge -e system emerge -e world emerge -P gcc emerge whateverneedstobedoneafterwards should suffice as documentation. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. Maybe people look closer if they upgrade gcc, but einfo still gets overlooked easily. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. Assuming a clear upgrade path is provided i think it would be fine. We'll make some sticky thread on the forum mentioning that instructions, i bet it couldn't hurt to put them on the gentoo mainpage, as topic in #gentoo etc. I'm also pretty sure next GWN is likely to report about the update. Just because we haven't got emerge --news it doesn't mean we haven't got lots of ways to reach our users. Every user that gets to read them in time is a potential bug report less. cheers, Wernfried Personally, I would set a date next week, so that way GWN and other places can be prepare for this, a definate date for users to know that it IS going to happen, and I personally think that a sticky on the forum (i would even be willing to write a little something, but i'm no expert) is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. just my $.02 Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Andrew Muraco [EMAIL PROTECTED] said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpUWJPetVoI1.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Georgi Georgiev wrote: maillog: 30/11/2005-15:16:35(-0500): Andrew Muraco types Mark Loeser wrote: Andrew Muraco [EMAIL PROTECTED] said: is a minimum. A full out doc with all the FAQ and important notes about what needs to be recompiled (in my opinion) would be a much more through upgrade path, ofcourse still include the einfo quick instructions. But I think the masses of users will not be happy when they realize that emerge -e world emerge -e world means that they will be compiling for the next day (or 2 or 3), so a way to block the upgrade from messing up people that wish to keep 3.3.x as default would be a good idea. gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. That makes me feel a bit more comfortable. I still think that something more then an einfo warning should be provided, as its easy to overlook those. So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. I like that idea alot actually. Perhaps also include in that warning message that switching back is OKAY aslong as nothing has been compiled with the new minor version. :-P I vote for this choice. Greetings, Tux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Georgi Georgiev [EMAIL PROTECTED] said: So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. That's going to be really really annoying for someone like me that flips between gcc versions all the time to test things. How to inform users of updates is not really the scope here though (go argue this on the news GLEP). Making sure the information for how to properly upgrade is available is what we are looking at. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpzZTFpcaErN.pgp Description: PGP signature
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
30.11.2005, 22:19:27, Peter Ruskin wrote: On Wednesday 30 November 2005 20:12, Mark Loeser wrote: gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. But we should not yet be encouraged to switch to 3.4. I upgraded to i686-pc-linux-gnu-3.4.4 a long time ago but my gcc profile is still firmly fixed at 3.3.5-20050130 because of bug #101471. This bug was opened 2005-08-05 and it's still not fixed. Whenever I try 3.4.4 I can't rebuild glibc because of this bug. Sure. So remove USE=vanilla from your use flags and it will work. That bug won't be fixed, because it's not a bug. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpkKIpnkGEFu.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 13:56 -0500, Mark Loeser wrote: Mark Loeser [EMAIL PROTECTED] said: Only thing I see as lacking is we might want to get a doc together on how to properly upgrade your toolchain so we don't get an influx of bugs from users that have a system half compiled with 3.3 and the other half with 3.4 so they get linking errors. Seems people read this to mean that I was going to write a doc, which I have no intentions on doing. I believe adding It is recommended that you `emerge -e system emerge -e world` after merging gcc-3.4 to the einfo at the end of the gcc-3.4.4 install should be good enough. I'm not sure how other archs handled the migration, but I haven't been able to find any docs online. So, let me know if marking it stable in the next day or two is completely stupid and I should wait to announce this via the GWN or something, or if its an alright move and people aren't going to stab me for marking it stable. einfo $stuff and mark it stable later today wins my vote. -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
051130 Andrew Muraco wrote: I think the masses of users will not be happy when they realize that 'emerge -e world emerge -e world' ... Should that be 'emerge -e system emerge -e world' ? ... means that they will be compiling for the next day or 2 or 3 , /spectate As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 30 Nov 2005 17:34:56 -0500 Philip Webb [EMAIL PROTECTED] wrote: | As one of the masses, I am certainly disturbed at that implication. | I don't remember any such need when I upgraded 2.9.5 - 3.x (now | 3.3.6). The 2.x - 3.x upgrade was far worse. Maybe you're just repressing the memory of it... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Philip Webb wrote: [Wed Nov 30 2005, 04:34:56PM CST] As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). http://www.gentoo.org/doc/en/new-upgrade-to-gentoo-1.4.xml -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgptsXmrzu1x2.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Philip Webb [EMAIL PROTECTED] said: I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. C++ compat was broken between 3.3 and 3.4, so C++ libs compiled against 3.3 and 3.4 aren't going to play nice with each other. KDE is the common example of breakage here. If I'm wrong, then someone will hopefully correct me here, but this is the only way to keep everything sane as far as I know. As for a doc, look at: https://bugs.gentoo.org/show_bug.cgi?id=102876 I'm hoping we can get something thrown together relatively quickly so I can mark it stable. Nothing is going to be required immediately from the user though, since their compiler won't be changed to 3.4 until they do so. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpn8ucW9Srof.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Lots of things broke way back then, too. Also, there wasn't even slotted gcc ebuilds back then, so it really is hard to compare. There were a lot of things done in the past that were really broken that we have since learned from... Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. I would very much appreciate a doc somewhere which explains the advantages of moving to 3.4 why a wholesale ground-up rebuild is necessary, if indeed it is. As always, my thanks to those who do the volunteer work. Well, the advantages are simple. Upstream no longer supports 3.3 anymore. They barely support 3.4, but having some support from upstream is better than none. This means 3.3 will be relegated to a legacy version and likely won't be updated except for security bugs. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
1.12.2005, 0:29:48, Chris Gianelloni wrote: On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. -- jakub pgpgEl2aFDbjP.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. -- Mark Loeser - Gentoo Developer (cpp gcc-porting toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpMsWalxXe7V.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. -- Marien. -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
1.12.2005, 1:30:41, Marien Zwart wrote: Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. Which returns us to the question why don't we build python with nocxx so that we could avoid this major PITA. -- jakub pgpQpg8uVxpUk.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Thu, 1 Dec 2005 01:53:25 +0100 Jakub Moc [EMAIL PROTECTED] wrote: 1.12.2005, 1:30:41, Marien Zwart wrote: Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. Which returns us to the question why don't we build python with nocxx so that we could avoid this major PITA. Actually I'm looking into that. According to the information I have found on the python-dev list and in python's documentation the libstdc++ link is not needed, but a dev asked a python herd member for it, and therefore the link was added. Haven't caught that dev yet, so at the moment I don't know why that link is there. If someone on this list knows the reason it was added, please enlighten me. -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
051130 Chris Gianelloni wrote: On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: As one of the masses, I am certainly disturbed at that implication. I don't remember any such need when I upgraded 2.9.5 - 3.x (now 3.3.6). This is the kind of issue on which I trust the devs to do sensible things, but do we really need to rebuild our whole systems from the ground up ? Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. That's what I wanted to know. From this other responses, it looks as if it would be a bad idea eg to upgrade to KDE 3.5 just before adopting GCC 3.4 (smile), but that 'revdep-rebuild' will reveal the (lengthy) list of needed remerges. I would urge whoever is documenting this to avoid a blanket recommendation to 'emerge -e system emerge -e world' or be prepared for a lot of negative reaction from the masses. spectate -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 22, 2005, at 4:13 AM, Grobian wrote: On 21-11-2005 19:15:58 -0800, Donnie Berkholz wrote: | virtual/x11 isn't xorg for all profiles. Perhaps the relevant people (macos?) could get in touch with me, and we can figure out what needs to happen. It may be that we'll need to add x11-base/apple-xfree into the || list as well. Using the virtual is not an option right now, because of the previously mentioned bug. OSX doesn't have Xorg (yet?), so it would indeed cause some trouble for us right now. Since we're outnumbered here, I'd vote to make the change that is compatible with the majority of users right now. I'm affraid it would just boil down to dropping the ppc-macos keyword on those packages that get xorg dependency. The mentioned || list is an issue for more than xorg, so it should be considered some more IMHO. Kito, can you agree with this, or do you have another 'solution'? I would want to know exactly how many keywords would be dropped with this solution. I would hate to see something that is working perfectly fine having support dropped due to syntax troubles in an ebuild... - --Lina Pezzella Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDjmXGNJ9STR9DbYERAtx6AJ4qQG3fr80C5IAf9rxsMfSYFvuc0wCdEe5w ca4WsabWZGsVEjmBrh2EcPE= =wyJn -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glibc binutils -aware hackers wanted for questions ;)
On Tue, 2005-11-29 at 02:29 +0100, Spider (D.m.D. Lj.) wrote: Hello, I've been looking some at Michael Meeks -Bdirect patches, and the possible performance boost they could give. The good parts here is that it seems to be far less intrusive for the running system than prelink is, on the other hand, it does require a more intrusive surgery into the core systems. So, now I'm just asking for comments and/or discussion here.. would it be worth the time spent on this? http://sourceware.org/ml/binutils/2005-10/msg00436.html For the interested : http://bugs.gentoo.org/show_bug.cgi?id=114008 -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 2005-11-30 at 16:19 -0500, Mark Loeser wrote: Georgi Georgiev [EMAIL PROTECTED] said: So make gcc-config produce warnings when changing the compiler. Switching to gcc-MAJOR.MINOR may break your system. Upgrade instructions can be found at http://thedoc; Trigger the message only when switching minor versions. That's going to be really really annoying for someone like me that flips between gcc versions all the time to test things. New flag? # gcc-config -q foo -q == quiet just a thought -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] PATCH: parallel-fetch
On Wed, Nov 30, 2005 at 12:51:58PM -0800, Zac Medico wrote: Brian Harring wrote: Note that due to how it's implemented, this does two rounds of verification- it'll actually do *two* rounds of fetching too, if things go awry in the backgrounded thread. Two possible improvements to help prevent user confusion: 1) Display a warning message when waiting for distlocks and parallel-fetching is enabled, in order to alert the user that background fetching is likely in progress. portage_locks does so already. 2) Display a warning message via an atexit hook when parallel-fetching is enabled, in order to alert the user that background fetching may _still_ be in progress if emerge appears to hang after an ebuild dies (this happened to me while kde-3.5 was fetching in the background). Details please... atexit portage_exec hooks should kill off the fetcher. ~harring pgpNX9tteH9Ck.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: parallel-fetch
Brian Harring wrote: 2) Display a warning message via an atexit hook when parallel-fetching is enabled, in order to alert the user that background fetching may _still_ be in progress if emerge appears to hang after an ebuild dies (this happened to me while kde-3.5 was fetching in the background). Details please... atexit portage_exec hooks should kill off the fetcher. Well, I'm running the latest svn so there could be a regression in the recent changes to portage_exec.cleanup(). Zac -- gentoo-portage-dev@gentoo.org mailing list
