I did an emerge world (including baselayout), and afterwards when I try to run xpdf I get this error: xpdf: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory I don't think it has anything to do with revdep-rebuild; I believe I ran emerge depclean followed by revdep-rebuild, the latter of which never works but only because I have binary packages installed. The only command it wanted to run was: emerge --oneshot --nodeps =app-office/openoffice-bin-1.1.4 =www-client/mozilla-bin-1.7.6-r1 =www-client/netscape-7.2 which is usual, so that's why I don't think that's the problem. Reproducible: Always Steps to Reproduce: 1. 2. 3. root>emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 21 2005, 20:42:41)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nostrip sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://194.117.143.70" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X alsa arts avi bash-completion bitmap-fonts cdr crypt cscope cups curl dvd emboss encode fam flac foomaticdb gd gdbm gif gpm gtk2 imagemagick imlib jpeg kde kdeenablefinal libg++ libwww mmx mp3 mpeg ncurses ogg oggvorbis opengl pdflib perl png ppds qt quicktime readline scanner sdl sqlite ssl tcpd tetex tiff truetype truetype-fonts trusted type1-fonts usb v4l vorbis xml2 xmms xprint xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Do you have x11-libs/openmotif installed? Is /usr/lib/libXm.so.3 present on your system?
No to both questions.
Solution #1: add "motif" to your USE flags, re-emerge xpdf Solution #2: just re-emerge xpdf (if you don't need motif)
I see what happened now. I didn't notice the message that configure gave that openmotif is needed for the xpdf command. Probably openmotif used to be a dependency of xpdf, then it stopped being a dependency so it got removed when I ran emerge depclean, hence the error. Now I emerged openmotif and xpdf and it works. Sorry about that. Ultimately I'd say this is the result of a twofold bad design. First, when I unmerged openmotif, it should have figured out that xpdf needs to be reemerged, since it used to depend on it and now doesn't. Second, each package should only install a single user-visible program (this is bad design on the part of the xpdf developers), and certainly a package called "xpdf" should always install the xpdf program. A separate ebuild like "xpdf-utils" could be used for people who only want those command line utilities, to work around the problem of not having separate packages for each one.
(In reply to comment #4) > First, when I > unmerged openmotif, it should have figured out that xpdf needs to be reemerged It's not done automatically, revdep-rebuild should handle such situation. As you've wrote revdep-rebuild doesn't work right for you, you can file another bug for revdep-rebuild. Anyway, I think this bug can be closed with resolution invalid.
Are you sure it's invalid and a new bug report should be opened? The bug here, if I understand you, is caused because revdep-rebuild should have realized that xpdf needs to be re-emerged. When I said revdep-rebuild doesn't work for me, I didn't mean it totally doesn't work - it's just that it always tries to run a command which fails, because I'm told it doesn't work with binary packages, which is another story. That doesn't belong in another bug report because it's a known problem. But revdep-rebuild should also have displayed a command to re-emerge xpdf, if I understand it correctly, which it didn't do.
it would be a feature request for revdep-rebuild then, but very hard to realize
A feature request? Not a bug fix? My system was left in an unstable state, even after running revdep-rebuild (or it would have been had I run it). My understanding of the program requirements of revdep-rebuild is it fixes systems that are in an unstable state. Since it didn't do that, I'd call it a bug (which is by definition a difference between the program requirements and the actual program). That the bug is very hard to fix doesn't make it a feature request, though if you want to lower the priority of fixing it I couldn't say that I'd blame you.
where does revdep-rebuild state that it fixes unstable system? In the end it's not on my end to decide that since i don't maintain revdep-rebuild so please fill a bug against it and not against xpdf.
Is it possible to just change the category of this bug report?
reopen to reassign
Changed title from "revdep rebuild detects the wrong ebuild to rebuild" to "revdep rebuild failed to detect an ebuild to rebuild". The bug doesn't involve something it did that it shouldn't have done, only something it didn't do that it should have (namely, emerge xpdf).
Which version of gentoolkit do you have installed?
adam>emerge -pv gentoolkit These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-portage/gentoolkit-0.2.0 0 kB Total size of downloads: 0 kB And according to /var/log/portage, that's the same version I had installed when I noticed the bug too.
I have duplicated the bug. In order to ensure that you are hitting the same bug. 1. Do you have a java package installed? 2. What are the contents of /etc/ld.so.conf? As far as I can tell, the bug occurs because when revdep-rebuild uses all of the paths in /etc/ld.so.conf, it is finding a libXm.so.3 in the java install. Because of this, it thinks that the dependency is satisfied and doesn't flag the executible as having a broken dependency.
> 1. Do you have a java package installed? Yes: adam>emerge -pv black blackbox blackdown-java3d-bin blackdown-jdk blackdown-jre blackshades-cvs adam>emerge -pv blackdown-jdk These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-java/blackdown-jdk-1.4.2.02 -doc -mozilla 0 kB Total size of downloads: 0 kB > 2. What are the contents of /etc/ld.so.conf? adam>cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/local/lib /usr/lib/opengl/nvidia/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130 /usr/lib/MozillaFirefox /usr/lib /opt/blackdown-jdk-1.4.2.02/jre/lib/i386/ /opt/blackdown-jdk-1.4.2.02/jre/lib/i386/native_threads/ /opt/blackdown-jdk-1.4.2.02/jre/lib/i386/classic/ /opt/blackdown-jdk-1.4.2.02/jre/lib/i386/server/ /usr/qt/3/lib /usr/kde/3.3/lib
*** Bug 107196 has been marked as a duplicate of this bug. ***
Here is my comment from the other bug just marked as a duplicate of this one. I'm going to increase the severity since it left my system in an unbootable state, and I've heard of this happening to others. revdep-rebuild appears to: 1) create a list of libraries 2) build list COMPLETE_LD_LIBRARY_PATH by putting together the paths leading to these libraries, plus the contents of ld.so 3) check dynamic linking using this massive list COMPLETE_LD_LIBRARY_PATH The problem is that the list COMPLETE_LD_LIBRARY_PATH contains stuff that can't possibly be linked in for a particular executable, as it isn't in ld.so.conf, or that executables dynamic path. A good example of this problem is upgrading gcc (say 3.3 -> 3.4). A new libstdc++ is built. revdep-rebuild should cause everything that depended on the old libstdc++ to get rebuilt. Instead, if you have openoffice installed, it finds /opt/OpenOffice.org/program/libstdc++.so. This is clearly wrong - the openoffice libstdc++ (or any of the other libraries in openoffice) will never be used to dynamically link any other application. And yet revdep-rebuild considers the mere presence of these files enough to satisfy the dependency for every other application. So revdep-rebuild appears to work, yet every c++ application is still broken.
There is also a symlink following bug, eg. when /usr/X11R6 points to /usr: *** /usr/X11R6/lib/kde3/kcm_kbluetoothd.so not owned by any package is broken! *** /usr/X11R6/lib/kde3/kcm_kbluetoothd.so -> (none) *** /usr/X11R6/lib/kde3/kcm_obex.so not owned by any package is broken! *** /usr/X11R6/lib/kde3/kcm_obex.so -> (none)
Another problem.. on line 270 there's a call to emerge --pretend. There is no error checking so it will return no packages if there is a problem: emerge --nospinner --pretend --oneshot --emptytree app-arch/unrar ... Calculating dependencies .. !!! All ebuilds that could satisfy ">=dev-cpp/gtkmm-2.6" have been masked. !!! One of the following masked packages is required to complete your request: - dev-cpp/gtkmm-2.6.4 (masked by: ~x86 keyword) Dynamic linking on your system is consistent... All done. And hence again revdep-rebuild is reporting that everything is fine, when there are still loads of broken packages.
What version of gentoolkit do you have installed?
0.2.0.
If you are willing, I would highly recommend installing gentoolkit-0.2.1_pre8 and helping to get a significantly improved revdep-rebuild tested and stable. That version of revdep-rebuild is significantly improved, although this bug is still present. The issue with fixing this bug is that not building the complete path also causes packages to be missed.
Ok, I've installed it. The code for evaluating the package order looks identical to 0.2.0. The return value of emerge is never checked (lines 516,531) - if emerge --pretend fails you get an empty list as explained above.
Using gentoolkit-0.2.1, It does check the status of emerge and returns a value of 1 if it failed. If it isn't doing that for you, please attach all of the outout and the .revdep-rebuild* files from the following command: revdep-rebuild --keep-temp --ignore --pretend --verbose
(In reply to comment #18) > A good example of this problem is upgrading gcc (say 3.3 -> 3.4). A new > libstdc++ is built. revdep-rebuild should cause everything that depended on > the old libstdc++ to get rebuilt. In my case, revdep-rebuild is not working as expected as well, although it somehow does what you say it doesn't. Having in the past upgraded GCC to 3.4, I assumme libstdc++.so.5 was taken off the system for one reason or the other at some point, maybe through emerge depclean. The problem came not long ago when I tried to run the ut2004-demo binary, and it complained of not having that library file to run. No other programs including mozilla-firefox-bin, opeoffice, etc, complained about this. I ran revdep-rebuild, which as usual rebuilded the ut2004-demo and mozilla-firefox-bin binaries. After doing so, ut2004-demo was still broken. I did some questioning in #gentoo and realized there was a package, libstdc++-v3, that included this library and which should have been installed when I ran revdep-rebuild. This package however, and according to www.gentoo-portage.com, doesn't have any reverse dependencies, which means that not even ut2004-demo have it as its dependencies (I also checked this by emerge ut2004-demo -ep). How would any person that wants to play ut2004-demo realize that they need libstdc++-v3 so as to make it run. I realize this seems to be a bug related exclusively to ut2004, but finding the present bug being so near to this issue and since revdep-rebuild should have solved it, I thought I'd rather post the problem here before opening a new bug.
(In reply to comment #26) > I ran revdep-rebuild, which as usual rebuilded the ut2004-demo and > mozilla-firefox-bin binaries. After doing so, ut2004-demo was still broken. I > did some questioning in #gentoo and realized there was a package, libstdc++-v3, > that included this library and which should have been installed when I ran > revdep-rebuild. This package however, and according to www.gentoo-portage.com, > doesn't have any reverse dependencies, which means that not even ut2004-demo > have it as its dependencies (I also checked this by emerge ut2004-demo -ep). That is not a bug with revdep-rebuild. It rebuilt the package as it was supposed to, the bug is with the package that doesn't have the required dependencies set.
From 0.2.1-pre8: echo -n -e "${GR}Evaluating package order...${NO}" if [ -f $LLIST.5_order ] ; then echo " using existing $LLIST.5_order." else RAW_REBUILD_LIST="$(cat $LLIST.4_ebuilds | sed s/^/=/ | tr '\n' ' ')" if [ ! -z "$RAW_REBUILD_LIST" ] ; then REBUILD_GREP="^\\($( (emerge --nospinner --pretend --oneshot --nodeps $RAW_REBUILD_LIST ; echo $? >$LLIST.5_status ) | sed -n 's/\./\\&/g\ ;s/ //g;s/$/\\/;s/\[[^]]*\]//gp' | tr '\n' '|' | sed 's/|$//'))\$" if [ $(cat $LLIST.5_status) -gt 0 ] ; then echo "" echo -e "${RD}Warning: Failed to resolve package order." echo -e "Will merge in \"random\" order!${NO}" echo "Possible reasons:" echo "- An ebuild is no longer in the portage tree." echo "- An ebuild is masked, use /etc/portage/packages.keyword" echo " and/or /etc/portage/package.unmask to unmask it" for i in . . . . . ; do echo -n -e '\a.' sleep 1 done ln -f $LLIST.4_ebuilds $LLIST.5_order else emerge --nospinner --pretend --oneshot --emptytree $RAW_REBUILD_LIST | sed -n 's/ //g;s/^.*\]//p' | grep "$REBUILD_GREP" >$LLIST.\ 5_order fi else echo -n "" >$LLIST.5_order fi echo -e " done.\n ($LLIST.5_order)" fi The return value of emerge isn't checked.
Created attachment 69648 [details] log.bz2 I can no longer reproduce the problem as I fixed my system.. that piece of code hasn't been changed between 0.2.0 and 0.2.1 (the check of the return status of the first emerge is in 0.2.0), and it was definately responsible for revdep-rebuild not working correctly in my case. I have attached a debug log of revdep-rebuild running. You can clearly see at the end it has a huge list of ebuilds to emerge, but it puts it through emerge --nospinner --pretend --oneshot --emptytree which fails (with the message "!!! All ebuilds that could satisfy ">=dev-cpp/gtkmm-2.6" have been masked." but you can't see that in the log), and then it reports linking consistent, everything is done.
I should make it clearer - I took the log when I actually had the problem and was trying to debug it, it does show the problem. I can't reproduce now because I fixed the consistency of my system.
I have had this problem with an upgrade to dbus. So far revdep-rebuild has failed to realize that: gaim,epiphany,gfloppy,sound-juicer,nautilus-cd-burner,gtkpod,gnome-volume-manager,gnome-cd were all linked to the old library.
*** Bug 122518 has been marked as a duplicate of this bug. ***
Bug from comment #20 is fixed in gentoolkit-0.2.0, Leaving open as the original issue has not been fixed.
Sorry for the spam, previous comment should have read gentoolkit-0.2.2
This is fixed with the --no-path option in svn r302. However, when this option is used you will most likely get false positives for software that doesn't keep its libraries in standard locations
I think this bug should be marked dup of bug 80455 ; should'nt it ?
(In reply to comment #35) > This is fixed with the --no-path option in svn r302. > > However, when this option is used you will most likely get false positives for > software that doesn't keep its libraries in standard locations > Isn't it better to enable this behaviour by default and provide an option to revert to the old behaviour? I think the possibility for a broken system is worse than a few extra emerges due to false positives. Maybe in the long run those "broken" packages can be fixed so there will be less/none false positives.
Released in gentoolkit-0.2.3_pre1.
(In reply to comment #37) > Isn't it better to enable this behaviour by default and provide an option to > revert to the old behaviour? I've decided in my testing to not make this the default due to the number of packages that are affected that are designed that way. Fixed in gentoolkit-0.2.3
*** Bug 80455 has been marked as a duplicate of this bug. ***
