Re: [gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86
maillog: 02/12/2005-16:55:23(-0500): Mark Loeser types > > [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml Re: the guide above. It says to run # revdep-rebuild --library libstdc++.so.5 -- -pv # revdep-rebuild --library libstdc++.so.5 However, revdep-rebuild only recognizes "-p" when rebuilding (it does not recognize -pv for pretend) and it will delete the /root/.revdep* files upon completion of the "-pv" command. The downside is that revdep-rebuild will need to search for the matching binaries *twice* if a user follows the above guide. Compare the output of: # revdep-rebuild --library libstdc++.so.5 -- -pv ... ... Total size of downloads: 0 kB Build finished correctly. Removing temporary files... .. You can re-run revdep-rebuild to verify that all libraries and binaries are fixed. If some inconsistency remains, it can be orphaned file, deep dependency, binary package or specially evaluated library. And... # revdep-rebuild --library libstdc++.so.5 -- -p -v ... ... Total size of downloads: 0 kB Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. -- /\ Georgi Georgiev /\ Your boss is a few sandwiches short of a /\ \/[EMAIL PROTECTED]\/ picnic.\/ /\ http://www.gg3.net/ /\/\ pgpaRDUhk5QGu.pgp Description: PGP signature
Re: [gentoo-dev] eclass mozconfig-2 restrictions
On Sunday 04 December 2005 20:47, Ned Ludd wrote: > that sounds like it would solve the problems ferringb has > pointed out in the past. That works fine, a part an "Eclass blabla inherited illegally" errors on unmerge of older ebuilds. The main problem is that what was proposed for shadow deps requires adding a dep to an eclass, so it would add _again_ the dep on shadow on eutils (it was removed because the shadow dep was creating a circular dep with pam-login and pam). -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpqgnSVzTFdH.pgp Description: PGP signature
Re: [gentoo-dev] eclass mozconfig-2 restrictions
On Sun, 2005-12-04 at 20:14 +0100, Luca Barbato wrote: > Ned Ludd wrote: > > > > You should talk to ferringb about why it's evil to remove functions from > > an eclass ever. > > > > eclasses can't inherit from other eclasses? > > Just splitting functionality on another eclass and keep the former > eclass providing everything by inheriting the new one doesn't work? that sounds like it would solve the problems ferringb has pointed out in the past. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclass mozconfig-2 restrictions
Ned Ludd wrote: You should talk to ferringb about why it's evil to remove functions from an eclass ever. eclasses can't inherit from other eclasses? Just splitting functionality on another eclass and keep the former eclass providing everything by inheriting the new one doesn't work? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: gcc-3.4 migration guide
Jan Kundr?t <[EMAIL PROTECTED]> wrote: > [-- text/plain, encoding quoted-printable, charset: utf-8, 14 lines --] > > On Saturday 03 of December 2005 21:26 Matthias Langer wrote: >> 1.) If you remove gcc-3.3* before emerge -e system you will be left >> behind with a broken python and therefore emerge. Thus i think there >> should be a big red box telling users about this. > > Our guide says that you have to either run `revdep-rebuild` or `emerge -1 > libstdc++-v3` and `emerge -e system` before unmerging old version of GCC. When I read the migration document, it looks like a lowercase "L" instead of a number "1". That is why the emerge did not work for me. Jeff -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclass mozconfig-2 restrictions
On Sun, 2005-12-04 at 08:26 -0600, Jory A. Pratt wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I have found a restrictions in out mozconfig-2 eclass. Splitting the > eclass core configuration out to a seprate eclass will fix the > restrictions. I have placed the eclasses at > http://dev.gentoo.org/~anarchy/eclass for view. With the new mozcoreconf > we will be able to add the extentions for mozilla/thunderbird/firefox of > major use to the tree. Enigmail is the perfect example as to an ebuild > that is wanted in the tree by 90% of thunderbird user. You should talk to ferringb about why it's evil to remove functions from an eclass ever. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] eclass mozconfig-2 restrictions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have found a restrictions in out mozconfig-2 eclass. Splitting the eclass core configuration out to a seprate eclass will fix the restrictions. I have placed the eclasses at http://dev.gentoo.org/~anarchy/eclass for view. With the new mozcoreconf we will be able to add the extentions for mozilla/thunderbird/firefox of major use to the tree. Enigmail is the perfect example as to an ebuild that is wanted in the tree by 90% of thunderbird user. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDkvyOGDfjNg8unQIRAtKGAJkBXuyDUDdd01DJMd/mSLgbq6UElgCfZ7E4 ifHE/Ls/2comIDOwG3Xwj8k= =BGKV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86
Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 04 Dec 2005 11:13:54 +0900: >> Reading this reminds me of a question I've had since I tried emerge -eav >> world last time: >> >> When portage merges, it stops the emerge process, updates its metadata or >> whatever, then restarts the process. With the -e in there, at least here, >> it reissued the same command over again, thereby restarting the process >> from the beginning and of course, upon getting to portage, looping yet >> again! > > This is incorrect. Portage should only restart if the version that was merged > does not match the internally recorded version. There was one or two releases > that had an incorrect internal version but not for at least a year. However, > if the version has changed and portage does restart itself then any packages > listed before portage will be merged again. > >> Maybe it was because I was using -KuD also, to remerge/upgrade from binary >> packages? (Hard disk trouble, I was remerging the binary packages to >> bring up2date an old installation snapshot.) > > Perhaps you were using one of the broken versions? Most likely so. At the time, the portage database was out of sync with what was actually merged, because the database was new (on /var, which wasn't affected) but I was working from an old root and /usr set. Since I had all the binary packages, I figured the easiest way to get everything back upto-date and lined up again, was to do an emerge --emptytree --packageonly, and I was rather frustrated to find it kept looping, when I'd never seen anything in the documentation saying to watch out for portage or the easiest way to avoid the loop. =8^\ Honestly, I didn't expect it to be absolutely smooth, because that's not "functioning within design specifications", and I knew it. It's just that was the only experience with emerge --emptytree I'd had, and I didn't expect /that/ problem, because it was just too obvious not to be mentioned if it was happening to everyone, or whatever. Anyway, I have an explanation for what had been an unexplained anomaly, now, and my level of peace with the world just went up accordingly, so very much thanks! -- 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
