Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Ryan Tandy wrote: Dale wrote: Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Well, the /etc thing is generally more due to CONFIG_PROTECT - it won't delete files from /etc regardless of whether or not you've modified them, because they're under CONFIG_PROTECTion. Yea, but now I know that. Sometimes it takes my light bulb a while to get brightened up good. :-( LOL Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. -- Neil Bothwick A computer scientist is someone who, when told to Go to Hell, sees the go to, rather than the destination, as harmful. signature.asc Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Neil Bothwick wrote: On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Who knows, maybe in 20 years I'll be a dev. O_O I'll be too old then though. I'm working on a fresh install on another hard drive now. That will clear out some cruft. I copied my make.conf file and one other config file and that is it. Oh, the kernel's .config. I knew it was something outside of /etc. Thanks for clearing up my muddy water. Care to help with the rest now? LOL Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Monday 11 September 2006 23:32, Neil Bothwick wrote: On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote: So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? Yes, because the file is no longer the file portage installed, so it has no right to remove it. [SNIP] This generally isn't a problem, because you normally only edit files in /etc, which are config protected anyway. It arises here because fix_libtool_files.sh modifies the .la files. I still would prefer if it was stored in a log file somewhere so that if I ever stumple upon it I can see where it came from... Haven't gotten around to filing any bug about that though. One could argue that it is the responsibility of that script to check the md5/mtime information and update it. http://bugs.gentoo.org/show_bug.cgi?id=71265 -- Bo Andresen pgpgShGE4HY4O.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Dale wrote: Cheese, I'm learning something. I already knew that it would not delete files in /etc/ and now I know why. LOL I never put the two together before you said that. Well, the /etc thing is generally more due to CONFIG_PROTECT - it won't delete files from /etc regardless of whether or not you've modified them, because they're under CONFIG_PROTECTion. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
[EMAIL PROTECTED] schrieb: I'm upgrading my gcc from 3.x to 4.x. I've done the gcc switching, and now I'm updating my system. The recommended steps are: # emerge -eav system # emerge -eav world While emerging my system I received a message suggesting I run revdep-rebuild: warning - be sure to run revdep-rebuild now My question is, should I run revdep-rebuild right after emerging the system, or should I wait until after I emerge world? My concern was that in between, my system is in an unstable intermediate state, and it might be damaged by a revdep-rebuild in between. Well, you rebuild world, which includes all packages you would rebuild with revdep-rebuild. I would run revdep-rebuild after the rebuild of world, just to be sure. I also recommend to look through the info outputs of every emerge, if you missed something, e.g. I had messages like rebuild against the new library, than it is save to delete the old one. If you miss this, then you have cruft libs on your system. Cheers Marc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Marc Blumentritt wrote: snip I would run revdep-rebuild after the rebuild of world, just to be sure. snip Cheers Marc I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Dale schrieb: Marc Blumentritt wrote: I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Did you remove the temporary files of revdep-rebuild from /root? I had no problems with the upgrade and running revdep-rebuild afterward. In fact, revdep-rebuild showed me no package at all to rebuild, which was what I expected. Cheers Marc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Friday 08 September 2006 15:00, Dale wrote: I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. It is bug #125728 [1]? Otherwise if it continues consider posting the output of: # revdep-rebuild -i -- -vp [1] http://bugs.gentoo.org/show_bug.cgi?id=125728 -- Bo Andresen pgp80mi9wtzxM.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Marc Blumentritt wrote: Dale schrieb: Marc Blumentritt wrote: I did that too. I'm not sure if it is just me or what but every time I run revdep-rebuild it wants to emerge gcc again. It did the same thing before the gcc upgrade. If you run it, you may want to post to make sure it is making sense. After three runs, I said forget it. It'll just have to keep. I read somewhere it was a bug. I dunno. Did you remove the temporary files of revdep-rebuild from /root? I had no problems with the upgrade and running revdep-rebuild afterward. In fact, revdep-rebuild showed me no package at all to rebuild, which was what I expected. Cheers Marc I remove those each time. It is sort of a habit now. I run it on occasion especially if I remove something. Just to make sure. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On 9/8/06, Dale [EMAIL PROTECTED] wrote: Checking dynamic linking consistency... broken /usr/lib/aqbanking/plugins/0/bankinfo/de.la (requires /usr/lib/libaqbanking.la) Since you don't have aqbanking installed anymore, just delete these files, and probably the entire /usr/lib/qabanking directory. Might want to run an equery belongs /usr/lib/aqbanking first just to make sure nothing claims ownership of those files first... broken /usr/lib/avifile-0.7/ac3pass.la (requires /usr/lib/libaviplayavformat.la) broken /usr/lib/avifile-0.7/ac3pass.la (requires ... I suspect this is the same as aqbanking..no longer installed, so same solution. Equery belongs to be sure... broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.la (requires /usr/lib/lib-gnu-java-awt-peer-gtk.la) broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires /usr/lib/libgcj.la) Definitely bug #125728. I believe comment #29 contains the best workarounds until a fix is actually applied. broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires /usr/kde/3.4/lib/libkio.la) ... Here again, equery belongs /usr/lib/kde3/libk3blibsndfiledecoder.la. If nothing owns it, just remove it. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Fri, 08 Sep 2006 16:14:53 -0500, Dale wrote: broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavformat.la) broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavcodec.la) broken /usr/lib/libqbanking.la (requires /usr/lib/libaqbanking.la) broken /usr/lib/libqbanking.la (requires /usr/lib/libgwenhywfar.la) [repeated] I unmerged aqbanking. It wouldn't compile and I was not using it anyway. What you think? Bug or me having a setting wrong?? Did you run fix_libtool_files.sh between merging and unmerging aqbanking? This changes .la files, which means that their checksums no longer match the installed versions so portage doesn't remove them. Whether this is a bug in fix_libtool_files.sh or portage is open for discussion. -- Neil Bothwick When companies ship Styrofoam, what do they pack it in? signature.asc Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On 9/8/06, Dale [EMAIL PROTECTED] wrote: So basically if these files don't belong to anything, I can safely delete them? Yep. On the roach report, me sort of chicken to edit those files. Will it be OK to let it stay like this and let the bug get fixed? It's been doing this a while and I don't !see! any problems. Yes, as long as you don't mind the revdep-rebuild borkage. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Bo Ørsted Andresen wrote: I'm working on the list above. So far nothing belongs to anything. Maybe I need a depclean on this thing. It is a 3 year old install if I recall correctly. This has nothing to do with depclean. Neils suggesting that the md5sums were altered by fix_libtool_files.sh and hence not removed seems much more likely. Portage doesn't removed files with altered md5sums.. What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Gosh I wish someone could just pour all the Gentoo stuff in my head. Dale :-) :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
On Saturday 09 September 2006 05:33, Dale wrote: What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Depclean is to remove packages that are no longer in or a dependency of something in your world file. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Yep. So just to illustrate: # touch /usr/share/vim/vimfiles/plugin/bugsummary.vim # emerge --unmerge -va gentoo-syntax These are the packages that would be unmerged: [SNIP] Unmerging app-vim/gentoo-syntax-20051221-r1... No package files given... Grabbing a set. [SNIP] obj /usr/share/vim/vimfiles/plugin/newinitd.vim obj /usr/share/vim/vimfiles/plugin/neweselect.vim obj /usr/share/vim/vimfiles/plugin/newebuild.vim obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim --- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim [SNIP] --- !empty dir /usr/share/vim dir /usr/share/doc/gentoo-syntax-20051221-r1 All the things that has a are actually removed. The things with --- are not removed for the reason given in the following column. Since I touch'ed /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed with the reason: !mtime which means the last modified time has been altered after it was installed. The reason !empty is the reason for dirs which aren't empty (others packages have installed files in the same dirs...). After the unmerge is complete the only way to know is that the files no longer belong to any package. Of course when I remerge this package in a few minutes the files will be overwritten and the mtime will be correct again... Hope that makes it clear. -- Bo Andresen pgpO8wwWjx1D1.pgp Description: PGP signature
Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?
Bo Ørsted Andresen wrote: On Saturday 09 September 2006 05:33, Dale wrote: What would be a good way of finding files that were not deleted when something was upgraded/unmerged? I thought depclean was different from what I wanted to say but it got the ball rolling. Depclean is to remove packages that are no longer in or a dependency of something in your world file. Last part, zm, right over my head I think. Let's see if I get this right. emerge put a file in there, something, me maybe, changed something so it leaves it alone. That right?? Yep. So just to illustrate: # touch /usr/share/vim/vimfiles/plugin/bugsummary.vim # emerge --unmerge -va gentoo-syntax These are the packages that would be unmerged: [SNIP] Unmerging app-vim/gentoo-syntax-20051221-r1... No package files given... Grabbing a set. [SNIP] obj /usr/share/vim/vimfiles/plugin/newinitd.vim obj /usr/share/vim/vimfiles/plugin/neweselect.vim obj /usr/share/vim/vimfiles/plugin/newebuild.vim obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim --- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim [SNIP] --- !empty dir /usr/share/vim dir /usr/share/doc/gentoo-syntax-20051221-r1 All the things that has a are actually removed. The things with --- are not removed for the reason given in the following column. Since I touch'ed /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed with the reason: !mtime which means the last modified time has been altered after it was installed. The reason !empty is the reason for dirs which aren't empty (others packages have installed files in the same dirs...). After the unmerge is complete the only way to know is that the files no longer belong to any package. Of course when I remerge this package in a few minutes the files will be overwritten and the mtime will be correct again... Hope that makes it clear. So basically if I mess with a file and then unmerge the program it belongs to, I have to remember which ones I messed with and delete them myself? If I unmerge this in a console and can't read all the -- !mtime as they roll by, I'm stuck with orphan files on my rig? This needs a fix but I wouldn't want to be the dev to figure this one out. ;-) Dale :-) :-) -- gentoo-user@gentoo.org mailing list
