Dale schreef: > Holly Bostick wrote: > > >> Did you re-emerge gentoo-sources after removing the "doc" USE flag? >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > Yup, I sure did. > >> What is the format of the relevant entry in >> /etc/portage/package.use? >> >> If it does not look like this >> >> sys-kernel/gentoo-sources -doc >> > > Mine looks like this: O_O > > >> sys-kernel/gentoo-sources -doc
OK, that eliminates that possibility; it must be something else, then. > >> Also, try >> >> emerge -uDNptv world >> >> emerge --update --deep --newuse --pretend --tree --verbose >> >> (with --tree being the important change) >> >> to see what packages are requiring xmlto. We're just guessing that >> it's gentoo-sources, really; maybe it's not. >> > > >> [EMAIL PROTECTED] / # emerge -uDNptv world >> >> These are the packages that I would merge, in reverse order: >> >> Calculating world dependencies ...done! [nomerge ] >> sys-kernel/vanilla-sources-2.6.12.5 -build +doc -symlink [ebuild N >> ] app-text/xmlto-0.0.18 0 kB >> >> Total size of downloads: 0 kB [EMAIL PROTECTED] / # > And so, in fact, it is something else. Or something more, that we didn't know about. Do you use/need vanilla-sources? If not, then you might consider unmerging it, so it does not appear in your world file and attempt to update every time you do an emerge -whatever world. And you might also consider adding -doc to /etc/make.conf, as noted previously. > > Something new that didn't show up last time. My new package.use: > > >> sys-kernel/gentoo-sources -doc sys-kernel/vanilla-sources -doc >> That should solve that, then. >> Great. No more need to deal with that atm, then. > > What about the broke stuff? According to your last output: >> [EMAIL PROTECTED] / # revdep-rebuild >> >> Checking reverse dependencies... Packages containing binaries and >> libraries broken by any package update, will be recompiled. >> >> Collecting system binaries and libraries... done. >> (/root/.revdep-rebuild.1_files) >> >> Collecting complete LD_LIBRARY_PATH... done. >> (/root/.revdep-rebuild.2_ldpath) >> >> Checking dynamic linking consistency... broken /usr/lib/gaim/tcl.so >> (requires libtcl8.3.so libtk8.3.so) broken >> /usr/lib/libgtkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken >> /usr/lib/libgdkmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken >> /usr/lib/libpangomm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken >> /usr/lib/libglibmm-2.0.so.1.5.9 (requires libsigc-1.2.so.5) broken >> /usr/lib/libatkmm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) broken >> /usr/lib/python2.2/lib-dynload/_tkinter.so (requires libtk8.3.so >> libtcl8.3.so) broken >> /usr/lib/libgtkmm_generate_extra_defs-2.0.so.1.5.9 (requires >> libsigc-1.2.so.5) broken /usr/bin/icewm-session (requires >> libungif.so.4) broken /usr/bin/icewm (requires libungif.so.4) >> broken /usr/bin/gnome-panel-properties-capplet (requires >> libcapplet.so.0) broken /usr/bin/icewmtray (requires libungif.so.4) >> broken /usr/bin/icehelp (requires libungif.so.4) broken >> /usr/bin/icewmbg (requires libungif.so.4) broken >> /usr/X11R6/lib/gaim/tcl.so (requires libtcl8.3.so libtk8.3.so) >> broken /usr/X11R6/lib/libgtkmm-2.0.so.1.5.9 (requires >> libsigc-1.2.so.5) broken /usr/X11R6/lib/libgdkmm-2.0.so.1.5.9 >> (requires libsigc-1.2.so.5) broken >> /usr/X11R6/lib/libpangomm-1.0.so.1.5.9 (requires libsigc-1.2.so.5) >> broken /usr/X11R6/lib/libglibmm-2.0.so.1.5.9 (requires >> libsigc-1.2.so.5) broken /usr/X11R6/lib/libatkmm-1.0.so.1.5.9 >> (requires libsigc-1.2.so.5) broken >> /usr/X11R6/lib/python2.2/lib-dynload/_tkinter.so (requires >> libtk8.3.so libtcl8.3.so) broken >> /usr/X11R6/lib/libgtkmm_generate_extra_defs-2.0.so.1.5.9 (requires >> libsigc-1.2.so.5) broken /usr/X11R6/bin/icewm-session (requires >> libungif.so.4) broken /usr/X11R6/bin/icewm (requires libungif.so.4) >> broken /usr/X11R6/bin/gnome-panel-properties-capplet (requires >> libcapplet.so.0) broken /usr/X11R6/bin/icewmtray (requires >> libungif.so.4) broken /usr/X11R6/bin/icehelp (requires >> libungif.so.4) broken /usr/X11R6/bin/icewmbg (requires >> libungif.so.4) done. (/root/.revdep-rebuild.3_rebuild) >> >> Assigning files to ebuilds... done. >> (/root/.revdep-rebuild.4_ebuilds) >> >> Evaluating package order... done. (/root/.revdep-rebuild.5_order) >> >> Dynamic linking on your system is consistent... All done. "Dynamic linking on your system is consistent... All done." means that nothing needs rebuilding, in the opinion of revdep-rebuild (meaning no libraries are disconnected from the programs that depend on them). By the way, what version of gentoolkit do you have installed? If the last stable (0.2.0-r2), you might very well want to consider unmasking the unstable version for this package only -- add "app-portage/gentoolkit ~x86" to /etc/portage/package.keywords-- as revdep-rebuild is vastly improved (though still not perfect) in the most recent unstable version. It is within the realm of possiblility that your version of revdep-rebuild is less trustworthy than mine (I use the unstable version), so the reason why you're receiving untrustworthy reports, and I'm saying the application is trustworthy despite this is because my version *is* reasonably trustworthy and yours is not (which would make all of the following completely incorrect). I understand that all those "brokens" seem like they should be of concern, but the important thing is that *revdep-rebuild is not offering to rebuild anything*. What I suspect has happened is that you have changed your USE flags and possibly run revdep-rebuild based on a revdep-rebuild -p that you had done prior to changing your USE flags. I say this because I notice that gaim and python both have the tcltk USE flag available; they must have been compiled at least once with this flag active for them to require libtk8.3.so and libtcl8.3.so, but now, even though these libraries are broken, gaim and python are not offered to be rebuilt-- therefore the optional dependency on these libraries must have been removed in the meantime. This could occur if you had run revdep-rebuild -p (which makes a list of the proposed rebuilds based on the system at that moment), changed your USE flages, removing "tcltk", then re-emerged gaim and python during the course of a emerge --newuse world, and then run revdep-rebuild without the -p (which reads the list created from the previous --pretend run rather than re-evaluating the system). All the broken gnome libs depending on libsigc++ (which is where libsigc-1.2.so.5 comes from) seem to be deep dependencies (no packages are offered to be fixed related to them); since you appear to be a KDE user, the only way I see for these libraries to be on your system is that they were optional dependencies emerged via the +gnome USE flag (since the direct dependencies for these libraries are not being mentioned as broken, or offered to rebuild). Perhaps this USE flag has also been disabled and the applications previously using it rebuilt. The icewm applications depending on libungif are also not offered to rebuild, although they are broken w.r.t the libraries, which suggests that icewm is not in your world file, but is a dependency or deep dependency of something that is. But what's interesting is that icewm does not depend on libungif, but giflib, which is apparently not broken, and certainly not broken w.r.t icewm. So what it looks like to me is that your system is very sloppy at the moment, but nothing in fact is broken by some miracle of fate, which is why revdep-rebuild put out all this output, but offered to fix nothing. Or it's a gigantic bug. but if that was the case, you would likely have noticed; you would have rather a wide range of programs and DE/WMs that would not start, such as GNOME, IceWM, and Gaim, which I think you would have reported if it had happened. So I think that revdep-rebuild is telling the truth, and although many things are bent, nothing is broken and nothing in fact needs rebuilding. I would consider an emerge depclean -p (do *not* forget the "-p"!!!) to begin the process of getting rid of some of these apparently no-longer needed packages and libraries. *Absolutely* look at the list and make sure nothing essential is suggested to unmerge before attempting an emerge depclean without --pretend!!!! > > >> *Will* you stop trying to get authorization for emerge -e at every >> opportunity!!!??? :-) >> > > Well, that was the command I was given and copy and paste works. I'm > a bad typer remember. I copy and paste all I can. It's safer. That's the command you were given *when*? About the only time you are "given" that command is when you first install the system. Emerge --emptytree rebuilds every package in the system, as if nothing was installed at all (as if the "tree" was "empty"). Now I don't know how long it took you to emerge your system, but personally, I have no particular desire to emerge gcc and glibc and X and KDE and Mozilla and every single other package on my system all over again, since each one of those named packages takes at least two hours (some significantly more, like glibc and X, not to mention something like KDE) to emerge by itself, so emerging everything would probably take closer to 24 to 36 hours than like....10 to 18 (which is still a da*m long time, btw) . And that's assuming everything went perfectly, which it often doesn't. The point is, emerge -e "should" only be used in the very most extreme of emergencies; it's a pretty desperate measure, not to be taken lightly, and very very rarely necessary. > >> It's really not necessary. And you're getting yourself all worked >> up over a relatively minor issue (or in fact a couple of them). >> > > I'm not all worked up here. I'm ROTFLMAO though. LOL I'm OK as > long as I can figure it out OR get help fixing it. I'm not clear what, at this point, you're trying to fix. The original issue, revdep-rebuild, is solved, insofar as revdep-rebuild has completed with no re-emerges necessary, and the xmlto thing should now be solved as well. If something of substance remains, perhaps you should start another thread. If you're just upset about the revdep-rebuild output with no offers to re-emerge, I wouldn't worry about that (in the sense of thinking there's a 'problem' as opposed to an annoyance). Revdep-rebuild may not be perfect, but if something was actively broken, it would catch that. I would trust that if it says nothing needs to be re-emerged, then nothing needs to be re-emerged. > > >> Basically, you seem to be upset because Portage is having a fit >> when you try to update world. Not because a program is broken, or >> because you can't do some specific task (because a program is >> broken). If that is a correct assessment of the situation, then >> have some perspective. > > > I'm not mad at portage. I love portage. I still remember Mandrake. > I'll never forget that mess. At least with this, it can be fixed > without a re-install. No, I think you're missing my point. My point was that if the only problem with your system is that you have some anomalies when you do an emerge -whatever world or revdep-rebuild, but all the applications you use work, and you can in fact use your system for what you use it for, you don't have a problem, /per se/, you have a minor annoyance. If you didn't update world (which is not necessary), you would never notice a thing (presumably, correct me if I'm wrong). I'm certainly not saying that we don't fix minor annoyances here (we most assuredly do), but there's no need to treat it like The End of The World (which is about the only case in which you might care to reinstall/emerge -e world). Portage constantly up/downgrading giflib/libungif, or even refusing to install one of them, is far from such a state, unless the issue breaks.... (I dunno) Evolution, which you need to communicate with your clients at work, for example. Being unable to use Evolution if you need it is a problem. Portage being annoying is... just annoying. > > >> You don't have to update world every day, or even every month. So >> don't. If things work OK for what you need them to do, then the >> fact that you can't update easily right now is *not a problem*. >> Certainly not one needing a reinstall of the entire system. >> >> > > > I do mine each night because I'm on dial-up and it is easier to get > little tidbits than to wait until there is a new KDE and Open Office > at the same time. o_O It takes me about three days to get just Open > Office so I like to nibble on it a bit. Again, do you really *need* to be on the cutting edge every minute of the day? Especially when on dial-up? What good does the new version of KDE and Oo.o do for you that you have to upgrade every day? And you might also consider alternatives-- smaller alternatives-- like abiword or kwrite. Heck, you might consider using icewm or xfce (or openbox or Windowmaker or fvwm) instead of KDE. It's not that I'm telling you what to do, but you seem to be living outside your means, practically speaking. If you're on dial-up and you really can't afford (either in terms of time or money) the cost of the huge downloads that KDE and Oo.o entail, then you don't *have* to use them, you know. KDE is modular; you can use xfce and a selection of KDE programs-- just the ones you need. You don't really *need* konqueror, for example, since you use Mozilla for web browsing, and there are tons of other file managers for the file management part (xfce itself has one, but I like Krusader, despite it being a KDE program when I don't use KDE). Heck, you can use mc in a terminal (midnight commander is quite good, actually). And then you wouldn't have to download or compile konqueror anymore. If your means are limited (in terms of bandwidth), then it is well worth your time to consider how to maximize the effectiveness of what you spend that bandwidth on. Gentoo is about choice, but choice requires flexibility, and if you *can't* do everything you want (because you flatly don't have the bandwidth), then flexibility is a key skill to develop (how to get the most of what you want with the minimum of outlay). > >> If something specific is broken due to the gif/libungif issue, then >> tell us what that is. It may be that gif/libungif needs to be >> sorted out to fix whatever is broken, but we can cross that bridge >> when we come to it. >> > > I'm not sure if anything is broke or not. It was a block thing that > I thought may be messing up revdep-rebuild since it was complaining > about it. Everything seems to be working OK. Revdep-rebuild wasn't able to perform its suggested actions because of the block, but there are no more suggested actions, so everything is fine as far as that goes-- nothing is broke. > >> It's really not a big deal. Relax. >> > > I re-emerged vanilla-sources, it had the -doc on it too. Now I get > this: > > >> [EMAIL PROTECTED] / # emerge -uDNptv world >> >> These are the packages that I would merge, in reverse order: >> >> Calculating world dependencies ...done! >> >> Total size of downloads: 0 kB [EMAIL PROTECTED] / # > Fine, problem solved. :-D > > > Just for the heck of it, I'm doing a emerge -ev world. Just to be > sure. I'll skip Open Office though. It won't take to long. Famous last words. Good luck. > > My only question is about those broken things in revdep-rebuild. I > guess the emerge -ev world will deal with that though, right? *THERE ARE NO BROKEN THINGS IN REVDEP-REBUILD.* Dynamic linking on your system is consistent... All done. means that nothing is broken! It's just bent, and that could be due to user inexperience; if you ran revdep-rebuild -p after a depclean and/or after an emerge -uaDNv world, you might find even those 'bent' reports disappeared. And even if something did come up as needing re-emerging, it would *only* mean that one or more individual programs were linked against a missing or updated library, so those individual programs would not work until the linkage was fixed. Just because you put a single book away out of alphabetical order when at the public library, and the next person wanting it couldn't find it (because it's in the wrong place) wouldn't mean that the entire library building needed to be demolished and rebuilt! That's essentially what you're doing, with your emerge -e world. As I said, good luck. Holly -- gentoo-user@gentoo.org mailing list
