Re: [gentoo-dev] Addition of DVB_CARDS to USE_EXPAND
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.) Zzam -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Chris Gianelloni wrote:
On Tue, 2005-11-29 at 15:01 +, Mike Williams wrote:
On Monday 28 November 2005 14:22, Mark Loeser wrote:
This is basically a heads-up email to everyone to say that we are probably
going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
archs that have already done the move from having 3.3 stable to 3.4 could
give us a heads up on what to expect, that would be great. 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.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X-> go
to 3.4.X
Nope.
While it would be possible to limit it to a specific profile, it really
makes it a pain in the ass, especially for two versions that are almost
compatible, as opposed to the profiles that we have done in the past
where we were going from things like gcc2 to gcc3, that were not very
compatible, at all.
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 ;-)
Greetings,
Tuxp3
Andrew Muraco
www.leetworks.com
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] apache2 default for 2006.0
On Tue, 2005-11-29 at 16:34 -0800, Michael Stewart (vericgar) wrote: > Chris Gianelloni wrote: > > I'd like to add the apache2 USE flag to 2006.0's profile. This would > > not resolve bug #95140, but would keep users from hitting it by default. > > With apache being such a popular package, having it fail from a default > > stage3 installation reflects poorly on us all. If I haven't heard any > > good objections by November 30th, I'll make the change. This will *not* > > be retroactive to any previous release profiles. > > > > Sorry about the late reply. > > I've been working on setting up a UML today so I could better test and > fix that bug (honestly, apache-1.3 is a mess). Now that I have the UML > set up, it shouldn't take me too long to get that bug fixed. > > As fas as adding apache2 to the 2006.0 profile - no objections here, and > in fact I'd prefer it that way. Cool. I was really hoping for a positive nod from the apache team. =] I've been testing it in my tinderbox runs, and it really does keep the bug from showing itself. It doesn't resolve the issue, but it does keep people from hitting it by default. -- 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] apache2 default for 2006.0
Chris Gianelloni wrote: > I'd like to add the apache2 USE flag to 2006.0's profile. This would > not resolve bug #95140, but would keep users from hitting it by default. > With apache being such a popular package, having it fail from a default > stage3 installation reflects poorly on us all. If I haven't heard any > good objections by November 30th, I'll make the change. This will *not* > be retroactive to any previous release profiles. > Sorry about the late reply. I've been working on setting up a UML today so I could better test and fix that bug (honestly, apache-1.3 is a mess). Now that I have the UML set up, it shouldn't take me too long to get that bug fixed. As fas as adding apache2 to the 2006.0 profile - no objections here, and in fact I'd prefer it that way. -- Michael Stewart [EMAIL PROTECTED] Gentoo Developerhttp://dev.gentoo.org/~vericgar GnuPG Key ID 0x08614788 available on http://pgp.mit.edu -- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] apache2 default for 2006.0
On Tue, 2005-11-29 at 23:19 +, Stuart Herbert wrote: > Hi, > > On Thu, 2005-11-24 at 09:16 -0500, Chris Gianelloni wrote: > > I'd like to add the apache2 USE flag to 2006.0's profile. This would > > not resolve bug #95140, but would keep users from hitting it by default. > > With apache being such a popular package, having it fail from a default > > stage3 installation reflects poorly on us all. If I haven't heard any > > good objections by November 30th, I'll make the change. This will *not* > > be retroactive to any previous release profiles. > > I must be missing something. How is adding the apache2 USE flag the > right solution to this problem with users trying to install apache v1? *sigh* "This would not resolve bug #95140, but would keep users from hitting it by default." Did I ever even imply that this would resolve problems with users trying to install apache v1? Di I ever say that this was a solution for them in any way? Did I not also mention that this would *not* be retroactive? 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. -- 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] New developer: Alexandre Buisse (Nattfodd)
On Mon, Nov 28, 2005 at 23:39:17 +0100, Michael Cummings wrote: > "Tom Martin"<[EMAIL PROTECTED]> said: > ... and he > participated in the Google Summer of Code in writing a generational > garbage collector, GMC, for the Perl 6 VM (http://www.parrotcode.org). > > > > Sweet! Does this mean he can help us get parrot/pugs functional again in > portage? :) hem... What I did was mostly spend a month trying to understand the internals of parrot. I never used it other than for 'make test' (and admiring nice memory corruption), so I don't think I can be of any special help... Regards, Alexandre -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] apache2 default for 2006.0
Hi, On Thu, 2005-11-24 at 09:16 -0500, Chris Gianelloni wrote: > I'd like to add the apache2 USE flag to 2006.0's profile. This would > not resolve bug #95140, but would keep users from hitting it by default. > With apache being such a popular package, having it fail from a default > stage3 installation reflects poorly on us all. If I haven't heard any > good objections by November 30th, I'll make the change. This will *not* > be retroactive to any previous release profiles. I must be missing something. How is adding the apache2 USE flag the right solution to this problem with users trying to install apache v1? Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- 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 18:37 +0100, Andreas Proschofsky wrote: > On Tue, 2005-11-29 at 16:04 +, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: > > > broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires > > > libORBit-2.so.0 libgconf-2.so.4) > > > > binary packages should never be in /usr/ > > > > > Is /opt ignored? > > > > yes, because our policy specifically says binary packages in /opt > > It's not that easy for every package. For instance openoffice and > openoffice-bin need to got to the same location, cause OOo does a user > install and this will break when changing between them (and all the > settings / paths and so on). > > So either we would have both in /opt which then means that the source > based OOo is ignored too, or we have them in /usr/lib which results in > the ooo-bin annoyance. I would say the second one is less harmful. > > Btw, there is a long running bug about the revdep-rebuild, which also > has a solution for this: > > https://bugs.gentoo.org/show_bug.cgi?id=32276 Great! So it is being fixed. -- 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] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 29 Nov 2005 15:23:54 +0100 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | little question (that could start up a flame): what's the official | status of /usr/libexec directory? libexec for stuff that's run is far tidier than weird subdirectories in /usr/lib*. Those old people with beards got it right. -- 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
On Tue, 2005-11-29 at 16:04 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: > > broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires > > libORBit-2.so.0 libgconf-2.so.4) > > binary packages should never be in /usr/ > > > Is /opt ignored? > > yes, because our policy specifically says binary packages in /opt It's not that easy for every package. For instance openoffice and openoffice-bin need to got to the same location, cause OOo does a user install and this will break when changing between them (and all the settings / paths and so on). So either we would have both in /opt which then means that the source based OOo is ignored too, or we have them in /usr/lib which results in the ooo-bin annoyance. I would say the second one is less harmful. Btw, there is a long running bug about the revdep-rebuild, which also has a solution for this: https://bugs.gentoo.org/show_bug.cgi?id=32276 bye Andreas -- Andreas Proschofsky Gentoo Developer / OpenOffice.org 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 08:50 -0500, Curtis Napier wrote: > Doing it from the outset will save the forums and bugs a lot of stress > and heartache that could have been easily avoided. Don't forget the #gentoo channel. I meant to comment on this about the stage 1/2 thing but never did. I'm not picking sides but if the forum mods and the channel ops were both notified explicitly of changes that *are* coming then we could help head off a bunch of bugs and user aggravation. I'm pretty active in most places Gentoo but the first I heard about the stage 1/2 removal was GWN. If you could drop an email to the forum-mods address (??) and [EMAIL PROTECTED] a few days or so before something gets to the users that would be great. > Just my 2 $DENOMINATION's My 2/100 $DENOMINATION's :) -- Tres Melton IRC & Gentoo: RiverRat signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 10:48:10AM -0500, Olivier Cr?te wrote: > On Tue, 2005-29-11 at 15:27 +, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > > > On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > > > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? > > > > wrote: > > > > > what's the official status of /usr/libexec directory? > > > > > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > > > > > Why move the libexec content to libdir? They are all executables, not > > > libraries. Its in the same category as /usr/bin. > > > > libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, > > this are internal binaries that end user should never run themselves > > I was going to quote the FHS to prove you were wrong but it turns > out that libexec/ has been pull out of it. And they seem to recommend a > libdir subdirectory... i know it, but i wasnt about to start quoting FHS on you :P i was hoping we could scrounge up better reasons before resorting to throwing spec files at each other > In the end it doesn't really matter, but if we > change from libexec to lib/misc.. which is why i havent really started a thread on the topic already > will need to modify a lot of gnome package at least. yeah, a bunch of packages will need to be tweaked slightly, but i dont think it should be a big deal to do ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 04:41:20PM +0100, Thomas de Grenier de Latour wrote: > On Tue, 29 Nov 2005 15:27:10 + > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > i know they are executables, that's why we're talking about a > > specific subdir of lib > > > > libexec clutters /usr while /usr/lib/misc hides it nicely ... > > afterall, this are internal binaries that end user should never > > run themselves > > Random thought of the day: why not /usr/bin/misc? subdirs are not allowed in /usr/bin or /usr/sbin or any other bin dir -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 10:52:11AM -0500, Chris Gianelloni wrote: > broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires > libORBit-2.so.0 libgconf-2.so.4) binary packages should never be in /usr/ > Is /opt ignored? yes, because our policy specifically says binary packages in /opt -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 10:42 -0500, Chris Gianelloni wrote: > On Tue, 2005-11-29 at 15:03 +, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: > > > On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: > > > > Every user _must_ be instructed to run > > > > 'revdep-rebuild --soname libstdc++.so.5', > > > > if a system contains things linking to libstdc++.so.5 and things > > > > linking to > > > > libstdc++.so.6 I consider it horribly broken. > > > > > > ...and when it tries to "recompile" openoffice-bin? doom3? > > > > revdep-rebuild should ignore those packages > > Just curious, but how? How does it know that doom3 isn't compiled from > source and should be ignored? broken /usr/lib32/openoffice/program/gconfbe1.uno.so (requires libORBit-2.so.0 libgconf-2.so.4) broken /usr/lib32/openoffice/program/gnome-set-default-application (requires libORBit-2.so.0 libORBitCosNaming-2.so.0 libbonobo-2.so.0 libbonobo-activation.so.4 libgconf-2.so.4 libgnomevfs-2.so.0) broken /usr/lib32/openoffice/program/libofficebean.so.1.1 (requires libjawt.so) broken /usr/lib32/openoffice/program/libvclplug_kde680li.so.1.1 (requires libkdecore.so.4 libkdeui.so.4 libqt-mt.so.3) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/_bsddb.so (requires libdb-3.1.so) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/_tkinter.so (requires libBLT24.so libtcl8.3.so libtk8.3.so) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/bz2.so (requires libbz2.so.0) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/dbm.so (requires libgdbm.so.2) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/gdbm.so (requires libgdbm.so.2) broken /usr/lib32/openoffice/program/python-core-2.3.4/lib/lib-dynload/mpz.so (requires libgmp.so.3) broken /usr/lib32/openoffice/program/ucpgvfs1.uno.so (requires libgnomevfs-2.so.0) These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-office/openoffice-bin-2.0.0 It most definitely does not recognize binary packages of any kind. Just to let you know, every successful revdep-rebuild followed by another also wants openoffice-bin again. Interestingly enough, it did *not* list any of the games I have installed on that machine that are in /opt. Is /opt ignored? -- 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, Nov 29, 2005 at 08:21:51AM -0500, Mark Loeser wrote: > This assumes that they do an `emerge -e world'. Well, the same problem will arise should they upgrade their gcc and install a new external kernel module (with or without `emerge -e world`). Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpsDnLzB7Lu1.pgp Description: PGP signature
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 2005-29-11 at 15:27 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > > On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > > > what's the official status of /usr/libexec directory? > > > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > > > Why move the libexec content to libdir? They are all executables, not > > libraries. Its in the same category as /usr/bin. > > libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, > this are internal binaries that end user should never run themselves I was going to quote the FHS to prove you were wrong but it turns out that libexec/ has been pull out of it. And they seem to recommend a libdir subdirectory... In the end it doesn't really matter, but if we change from libexec to lib/misc.. will need to modify a lot of gnome package at least. https://www.redhat.com/archives/fedora-devel-list/2005-May/msg00240.html http://lists.debian.org/debian-devel/2005/05/msg00401.html -- Olivier Crête [EMAIL PROTECTED] 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 15:03 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: > > On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: > > > Every user _must_ be instructed to run > > > 'revdep-rebuild --soname libstdc++.so.5', > > > if a system contains things linking to libstdc++.so.5 and things linking > > > to > > > libstdc++.so.6 I consider it horribly broken. > > > > ...and when it tries to "recompile" openoffice-bin? doom3? > > revdep-rebuild should ignore those packages Just curious, but how? How does it know that doom3 isn't compiled from source and should be ignored? -- 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 15:01 +, Mike Williams wrote:
> On Monday 28 November 2005 14:22, Mark Loeser wrote:
> > This is basically a heads-up email to everyone to say that we are probably
> > going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
> > archs that have already done the move from having 3.3 stable to 3.4 could
> > give us a heads up on what to expect, that would be great. 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.
>
> Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X->
> go
> to 3.4.X
Nope.
While it would be possible to limit it to a specific profile, it really
makes it a pain in the ass, especially for two versions that are almost
compatible, as opposed to the profiles that we have done in the past
where we were going from things like gcc2 to gcc3, that were not very
compatible, at all.
--
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] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 29 Nov 2005 15:27:10 + Mike Frysinger <[EMAIL PROTECTED]> wrote: > i know they are executables, that's why we're talking about a > specific subdir of lib > > libexec clutters /usr while /usr/lib/misc hides it nicely ... > afterall, this are internal binaries that end user should never > run themselves Random thought of the day: why not /usr/bin/misc? -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 10:18:05AM -0500, Olivier Cr?te wrote: > On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > > what's the official status of /usr/libexec directory? > > > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc > > Why move the libexec content to libdir? They are all executables, not > libraries. Its in the same category as /usr/bin. i know they are executables, that's why we're talking about a specific subdir of lib libexec clutters /usr while /usr/lib/misc hides it nicely ... afterall, this are internal binaries that end user should never run themselves -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, 2005-29-11 at 14:53 +, Mike Frysinger wrote: > On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > > what's the official status of /usr/libexec directory? > > personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc Why move the libexec content to libdir? They are all executables, not libraries. Its in the same category as /usr/bin. -- Olivier Crête [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, Nov 29, 2005 at 09:50:34AM -0500, Chris Gianelloni wrote: > On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: > > Every user _must_ be instructed to run > > 'revdep-rebuild --soname libstdc++.so.5', > > if a system contains things linking to libstdc++.so.5 and things linking to > > libstdc++.so.6 I consider it horribly broken. > > ...and when it tries to "recompile" openoffice-bin? doom3? revdep-rebuild should ignore those packages -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Monday 28 November 2005 14:22, Mark Loeser wrote:
> This is basically a heads-up email to everyone to say that we are probably
> going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the
> archs that have already done the move from having 3.3 stable to 3.4 could
> give us a heads up on what to expect, that would be great. 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.
Shouldn't this be a profile thing? i.e. 200{4,5}.X stays at 3.3.X, 2006.X-> go
to 3.4.X
--
Mike Williams
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
On Tue, Nov 29, 2005 at 03:23:54PM +0100, Diego 'Flameeyes' Petten? wrote: > what's the official status of /usr/libexec directory? there is none afaik ... it's something we've been leaving alone for the time being because it hasnt been that critical of an issue personally, i'd prefer if we moved all of /usr/libexec to /usr/lib/misc -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 09:51 +0100, Gregorio Guidi wrote: > On Tuesday 29 November 2005 03:40, Mark Loeser wrote: > > Mike Frysinger <[EMAIL PROTECTED]> said: > > > that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their > > > system until they remove it > > > > > > so if user fails to rebuild all their packages before unmerging gcc-3.3 > > > they will be screwed, but OH WELL > > > > Yea. Even after they remove it though, libstdc++-v3 should be pulled in > > after that. Only issue I really see is people that have libraries compiled > > with 3.3 and 3.4 and don't know why stuff is broken. I don't know how > > large of a problem that will be though. > > It will be huge, see > https://bugs.gentoo.org/show_bug.cgi?id=64615 > https://bugs.gentoo.org/show_bug.cgi?id=61146 > > Every user _must_ be instructed to run > 'revdep-rebuild --soname libstdc++.so.5', > if a system contains things linking to libstdc++.so.5 and things linking to > libstdc++.so.6 I consider it horribly broken. *sigh* ...and when it tries to "recompile" openoffice-bin? doom3? A system linked against both libraries is definitely *not* broken, as there are plenty of cases where this is necessary. > Thus having libstdc++-v3 installed apparently solves a problem but in fact > does not solve anything, the only solution is to recompile everything c++ > related on the system. Except the binary apps that you don't have the source to be able to recompile. So now we're right back where we were, aren't we? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Misquoted in the GWN
Henrik Brix Andersen posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 28 Nov 2005 10:48:01 +0100: > So I fired up a web browser and there it was - first section in the GWN > [1]. Seems the GWN authors have read my blog entry [2] and decided to > bring their own version of it to the public. > > * The GWN talks about WiFi Protected Access (WPA). My Blog talks about > IEEE 802.11/wired authentication in general. Prefacing my comments with a big **IN** **MY** **OPINION** as a Gentoo user and (now) reader of that blog entry and this thread, for whatever you take such reader/user opinion to be worth (or not worth). Your blog does indeed mention IEE 802.11/wired authentication. However, it parallels xsupplicant and wpa_supplicant, saying they do the same thing, without making clear that (implied) wpa_supplicant does more than wpa. Thus, a reader not familiar with the technical details (such as myself, and apparently the GWN folks) could very easily fail to account as important the "general" reference, and equate WPA to the general case, where you (above, but not in the blog) make clear there's some difference. This certainly doesn't excuse their not running it by you, as they should have done, to clear up exactly this sort of error, if any, but it's a very reasonable error to make. Reading the blog, I made exactly the same error, and Grobian says he came to more or less the same conclusion. Not running it by you is a serious mistake, but given you asked for comments in the blog entry, you are now getting them, even if part of them have to do with a misunderstanding /of/ that blog entry. > * The GWN talks about "my plans" for deprecating xsupplicant. My blog > doesn't say anything about this. Not in so many words, no, but the meaning is clear, To justify having to maintain two packages (along with rcscripts) with the exact same purpose, . Reading between the lines, as one in a newsweekly may legitimately need to do in ordered to summarize a statement, what /other/ meaning could be taken from that, than that should such justification not be forthcoming from the feedback/discussion, deprecation of the now unjustified package would be the result? Again, no excuse for not running it by you, certainly no excuse for not linking the blog entry directly (that one I can't see at all, as sourcing is /always/ a mark of reputable journalism, and it would have been /so/ easy, in this case), but it's certainly what your blog implies the ultimate result will be, barring something legit coming up in the feedback you are now requesting. > * The GWN talks about removing xsupplicant from Gentoo Portage. My > blog certainly doesn't say anything about this. Same as above, the ultimate result of deprecation would be removal, altho with open source, where one never knows what else is out there depending on something, ultimate removal of deprecated items is normally something done on a timeline of years, not months, so this could reasonably be assumed to be well in the future. > * The GWN doesn't even link to my blog entry, from which they must > have gotten the initial idea for this article, thus not allowing their > readers to see that the information provided is incorrect. This, IMO, was the gravest error. I believe they reproduced the gist of the blog entry entirely faithfully (note that said gist of what's actually there may differ DRASTICALLY from what was intended, the reason running any official commentary by the original author is a VERY GOOD idea), but there remains /no/ excuse for not linking it, however faithful their summary may have been and regardless of whether it was run by you or not. Again, quoting source is one of the marks of reputable journalism, so failing to do so /also/ has strong implications on the reliability of the journalism. Failure to link the source is IMO inexcusable. The take appears to be entirely logical and reasonable, and what I got from reading it as well. However, that doesn't change a journalist's responsibility to at least link the source, where possible (as it was here), and to run the article by the subject in question where time and opportunity permits. I'd say chalk it up to a learning experience. GWN, as is customary with such things, should print a correction and apology next issue, and one would hope such a mistake isn't made again. Again, the above is simply IN MY OPINION as a reader of all three locations (this thread, the GWN entry, and the blog entry, in that order), and a Gentoo user, simply trying to "read the tea leaves" well enough to get some sense of what's ahead for him on this journey that is Gentoo. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] /usr/libexec vs /usr/lib(32|64)/misc
Hi all, little question (that could start up a flame): what's the official status of /usr/libexec directory? I was told on IRC time ago to prefer /usr/$(get_libdir)/misc to libexec because that's already ABI-specified... but I'm not really sure. /usr/libexec is already used by many upstream packages, starting from FreeBSD itself, and while it's true that /usr/$(get_libdir)/misc is ABI safe, I don't really like thinking of moving executables in a subdirectory of lib for ABI's sake.. or we'll end up having /usr/$(get_libdir)/binaries instead of /usr/bin ... So, as the documentation about that seems not to be clear, what's its status? -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdsyCVsmXbj.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
As a user who has done this on a number of systems - its no sweat. Also, check some of the older guides for upgrading from gcc-2.95 to 3, and 3.0 to 3.1 - should still be around somewhere. Its been done before, more than once - ask some of the older devs whove been around since the early days(!). Traps this time were uninstalling 3.3.6 without installing the sys-libs/libstdc++-v3 first. Ive put off removing 3.3.6 from the other systems until I get the nerve up again. So as well as instructions to do the task, some rescue for common mistakes like this would be nice. BillK On Tue, 2005-11-29 at 08:50 -0500, Curtis Napier wrote: > Speaking as a user who upgraded from 3.3.x to 3.4.x a loong lng > time ago and also as a forum mod who sees questins about this on a daily > basis: > > Users are more or less aware that they will have to rebuild the entire > world including the kernel when they upgrade gcc. If they aren't already > aware of it they soon learn that it is necessary and they aren't averse > to it. This is a from source distro afterall, so TELLING them in an > upgrade guide that they *HAVE* to do this wouldn't be such a bad thing. > It solves 99% of all the problems reported in a gcc upgrade for people > who *didn't* do an "emerge -e world". > > Doing it from the outset will save the forums and bugs a lot of stress > and heartache that could have been easily avoided. > > Just my 2 $DENOMINATION's -- William Kenworthy <[EMAIL PROTECTED]> Home! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Speaking as a user who upgraded from 3.3.x to 3.4.x a loong lng time ago and also as a forum mod who sees questins about this on a daily basis: Users are more or less aware that they will have to rebuild the entire world including the kernel when they upgrade gcc. If they aren't already aware of it they soon learn that it is necessary and they aren't averse to it. This is a from source distro afterall, so TELLING them in an upgrade guide that they *HAVE* to do this wouldn't be such a bad thing. It solves 99% of all the problems reported in a gcc upgrade for people who *didn't* do an "emerge -e world". Doing it from the outset will save the forums and bugs a lot of stress and heartache that could have been easily avoided. Just my 2 $DENOMINATION's -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Henrik Brix Andersen <[EMAIL PROTECTED]> said: > We will also need to instruct users to recompile their kernel with > gcc-3.4 otherwise the external modules (which will be recompiled with > gcc-3.4 during `emerge -e world`) will fail to load because of > vermagic mismatch. This assumes that they do an `emerge -e world'. We aren't going to be able to protect users from all of the stupid mistakes they can make, but the upgrade path is sane and very doable. Perhaps the docs team could come up with a generic toolchain guide that will possibly help stop any of the stupid mistakes users could make. -- 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 pgpgktGju3Vxt.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 12:18, Henrik Brix Andersen wrote: > gcc-3.4 during `emerge -e world`) will fail to load because of Why should one do that? It's not needed. But of course recompiling the kernel and external modules at some point makes sense. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWPQFAN8xtW.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Mon, Nov 28, 2005 at 09:22:33AM -0500, Mark Loeser wrote: > This is basically a heads-up email to everyone to say that we are probably > going to be moving gcc-3.4.4-r1 to stable on x86 very soon. If any of the > archs that have already done the move from having 3.3 stable to 3.4 could > give us a heads up on what to expect, that would be great. 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. We will also need to instruct users to recompile their kernel with gcc-3.4 otherwise the external modules (which will be recompiled with gcc-3.4 during `emerge -e world`) will fail to load because of vermagic mismatch. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpkQs96Fa7ch.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 10:53, Graham Murray wrote: > Paul de Vrieze <[EMAIL PROTECTED]> writes: > > It is also needed for third party apps that were linked against > > libstdc++.so.5. As long as those applications do not depend on other > > libraries that are linked against a newer c++ lib things are totally > > ok. > > But unfortunately is does happen. For example on my system (~x86 built > with gcc 3.4.4) opera is linked against libstdc++.so.5 and > libqt-mt.so.3 which in turn is linked against libstdc++.so.6 Opera is indeed an example of an application where it doesn't work. Mozilla, the jdk's and many games are however "good" examples. The general rule is that using libraries written in c++ doesn't work for transitioning. This is partly caused by the fact that the linker makes all symbols global, and as such doesn't look at (or record) the soname of the library where the symbol is supposed to come from. Please be aware though that doing so would still not fix c++ issues as extending objects with one symbol table (and library of origin) with objects (children) with another symbol table (and library of origin) is bound to break. If for example a library function returns a c++ string object. Which methods should then be used on this object? Paul ps. The sandbox we use in portage actually also relies on this behaviour of the linker, as we replace glibc symbols by our own versions of them that check permissions. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpssmaZzoOLH.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
Paul de Vrieze <[EMAIL PROTECTED]> writes: > It is also needed for third party apps that were linked against > libstdc++.so.5. As long as those applications do not depend on other > libraries that are linked against a newer c++ lib things are totally ok. But unfortunately is does happen. For example on my system (~x86 built with gcc 3.4.4) opera is linked against libstdc++.so.5 and libqt-mt.so.3 which in turn is linked against libstdc++.so.6 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 09:51, Gregorio Guidi wrote: > Every user _must_ be instructed to run > 'revdep-rebuild --soname libstdc++.so.5', > if a system contains things linking to libstdc++.so.5 and things > linking to libstdc++.so.6 I consider it horribly broken. > A system is only horribly broken if it contains binaries or libraries that link to both libstdc++.so.5 *and* libstdc++.so.6. This creates instabilities. The situation you describe is only that of a system in transition. > Thus having libstdc++-v3 installed apparently solves a problem but in > fact does not solve anything, the only solution is to recompile > everything c++ related on the system. It is also needed for third party apps that were linked against libstdc++.so.5. As long as those applications do not depend on other libraries that are linked against a newer c++ lib things are totally ok. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpF7GpJX0UML.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 03:40, Mark Loeser wrote: > Mike Frysinger <[EMAIL PROTECTED]> said: > > that means when people upgrade to gcc-3.4, gcc-3.3 will remain on > > their system until they remove it > > > > so if user fails to rebuild all their packages before unmerging > > gcc-3.3 they will be screwed, but OH WELL > > Yea. Even after they remove it though, libstdc++-v3 should be pulled > in after that. Only issue I really see is people that have libraries > compiled with 3.3 and 3.4 and don't know why stuff is broken. I don't > know how large of a problem that will be though. From my own experience of updating quite some while ago, I remember that the libraries are sufficiently compatible such that not so many bugs occur. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgPDQYl0K6g.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tuesday 29 November 2005 03:40, Mark Loeser wrote: > Mike Frysinger <[EMAIL PROTECTED]> said: > > that means when people upgrade to gcc-3.4, gcc-3.3 will remain on their > > system until they remove it > > > > so if user fails to rebuild all their packages before unmerging gcc-3.3 > > they will be screwed, but OH WELL > > Yea. Even after they remove it though, libstdc++-v3 should be pulled in > after that. Only issue I really see is people that have libraries compiled > with 3.3 and 3.4 and don't know why stuff is broken. I don't know how > large of a problem that will be though. It will be huge, see https://bugs.gentoo.org/show_bug.cgi?id=64615 https://bugs.gentoo.org/show_bug.cgi?id=61146 Every user _must_ be instructed to run 'revdep-rebuild --soname libstdc++.so.5', if a system contains things linking to libstdc++.so.5 and things linking to libstdc++.so.6 I consider it horribly broken. Thus having libstdc++-v3 installed apparently solves a problem but in fact does not solve anything, the only solution is to recompile everything c++ related on the system. -- gentoo-dev@gentoo.org mailing list
