"emerge -Duvp world" fails with the error below. Reproducible: Always Steps to Reproduce: 1. emerge sync 2. emerge -Duvp world Actual Results: Calculating world dependencies - emerge: there are no ebuilds to satisfy "=app-text/docbook-sgml-dtd-3.0-r1". !!! Problem with ebuild media-video/totem-0.99.15.1 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Portage 2.0.51_rc9 (default-linux/x86/2004.2/gcc34/2.6, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.8-gentoo-r10 i686) ================================================================= System uname: 2.6.8-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1500MHz Gentoo Base System version 1.5.3 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /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/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-m -mno-sse2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks fixpackages sandbox sfperms" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" 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="X acpi alsa avi berkdb bitmap-fonts cdr crypt cscope cups dvd dvdr eds encode esd evo f77 fam flac foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 hal howl imagemagick imlib java jpeg libg++ libwww mad mikmod mmx mono motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png ppds python quicktime readline samba sdl slang spell sse ssl svg svga tcltk tcpd theora tiff truetype x86 xml2 xmms xprint xv zlib"
I am getting this too with a different require-er : # emerge -pDu world These are the packages that I would merge, in order: Calculating world dependencies - emerge: there are no masked or unmasked ebuilds to satisfy "=app-text/docbook-sgml-dtd-3.0-r1". !!! Problem with ebuild gnome-base/gdm-2.4.4.7-r1 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed.
*** Bug 68022 has been marked as a duplicate of this bug. ***
Ho hum. app-text/docbook-sgml-utils-0.6.14 is (r)dependent on =app-text/docbook-sgml-dtd-3.0-r1 which has just been deleted from the tree.
I'm having the same problem with x11-plugins/gaim-encryption-2.31 and net-www/epiphany-1.2.9-r1 when running "emerge -UDvp world".
Unfortunately, it looks like there are dozens of others ebuilds depending on =app-text/docbook-sgml-dtd-3.0-r1 (and 3.1-r1, &c.). Here is a partial list: /app-text/docbook-sgml/docbook-sgml-1.0.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12-r2.ebuild~: =app-text/docbook-sgml-dtd-3.1-r1 ./app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12.ebuild~: =app-text/docbook-sgml-dtd-3.1-r1 ./app-text/sgmltools-lite/sgmltools-lite-3.0.3-r6.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./app-text/sgmltools-lite/sgmltools-lite-3.0.3-r7.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/haddock/haddock-0.4.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/haddock/haddock-0.6-r1.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/haddock/haddock-0.5.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/haddock/haddock-0.6.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/haddock/haddock-0.6-r2.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-haskell/alex/alex-2.0.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.2-r1.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.2.1-r1.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.2.1.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.0.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.0.1.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-lang/ghc/ghc-6.2.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 ./dev-libs/libusb/libusb-0.1.8.ebuild: =app-text/docbook-sgml-dtd-3.1-r1 )" ./dev-libs/libusb/libusb-0.1.7-r1.ebuild: doc? ( app-text/openjade =app-text/docbook-sgml-dtd-3.1-r1 )" ./dev-libs/libusb/libusb-0.1.7.ebuild: doc? ( app-text/openjade =app-text/docbook-sgml-dtd-3.1-r1 )" I can't change it, but this should be marked as Critical as it prevents updating the system.
All the GNOME-dependant ebuilds (like gdm, gaim-encryption and epiphany) would trigger the bug, because scrollkeeper depends on docbook-sgml-utils, one of the affected ebuilds above.
I didn't notice that so many ebuilds depend on specific revision of docbook-sgml-dtd... I'm just grepping ebuilds to see what packages need to be updated. Sorry for any inconvenience.
The problem occurs with all the docbook-sgml-dtd's! In addition to a large number of ebuild depending specifically on docbook-sgml-dtd-3.0-r1 there are a large number that depend specifically on release 'r1' of the other versions - docbook-sgml-dtd-3.1-r1, docbook-sgml-dtd-4.0-r1 and docbook-sgml-dtd-4.1-r1. Incidently, I was able to update my system by copying all the *-r2 ebuilds to their respective *-r1 ebuilds - ugly I am sure but at least my system can update while I wait for the next emerge sync.
All should be fixed now... hope this change will be available by next sync. My apologies for all of you.
there needs to be a seporation between the software version and the package release in portage. when specifying dependancies. I'm sick of this type of bug. Aditionally, Portage could use another "shim" type file that makes everything fit. We just need to be able to quickly say blah_ebuild-r2 replaces blah_ebuild-r1 ... well that's a bad example because no ebuild should care about the -r number... but in practice they do... This kind of bug strands many people for many days. because 1/2 hour can be more valuable at certain times of the day. (trying not to pick on this bug, but trying to rally people to find a solution) My system is out of date because of these problems.
Here is the hack I did to fix it: find /usr/portage -name '*.ebuild' -exec grep -E -l 'app-text/docbook-sgml-dtd-(3\.0|3\.1|4\.0|4\.1)-r1' {} \; | xargs perl -p -i.bak -e 's%app-text/docbook-sgml-dtd-(3\.0|3\.1|4\.0|4\.1)-r1%app-text/docbook-sgml-dtd-$1-r2%g' Here are the effected ebuilds: /usr/portage/app-text/docbook-sgml/docbook-sgml-1.0.ebuild.bak /usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12-r2.ebuild.bak/usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.12.ebuild.bak /usr/portage/app-text/docbook-sgml-utils/docbook-sgml-utils-0.6.14.ebuild.bak /usr/portage/app-text/sgmltools-lite/sgmltools-lite-3.0.3-r6.ebuild.bak /usr/portage/app-text/sgmltools-lite/sgmltools-lite-3.0.3-r7.ebuild.bak /usr/portage/dev-haskell/alex/alex-2.0.ebuild.bak /usr/portage/dev-haskell/haddock/haddock-0.4.ebuild.bak /usr/portage/dev-haskell/haddock/haddock-0.6-r1.ebuild.bak /usr/portage/dev-haskell/haddock/haddock-0.5.ebuild.bak /usr/portage/dev-haskell/haddock/haddock-0.6-r2.ebuild.bak /usr/portage/dev-haskell/haddock/haddock-0.6.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.0.1.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.2-r1.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.0.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.2.1-r1.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.2.1.ebuild.bak /usr/portage/dev-lang/ghc/ghc-6.2.ebuild.bak /usr/portage/dev-libs/libusb/libusb-0.1.7.ebuild.bak /usr/portage/dev-libs/libusb/libusb-0.1.7-r1.ebuild.bak /usr/portage/dev-libs/libusb/libusb-0.1.8.ebuild.bak
I've had this problem for days, and after syncing this morning, it *still* isn't fixed. Is it supposed to be? I also agree with above comments about this type of bug re-occurring. Perhaps there should be a database of dependancies that is *checked* before anything is deleted from the portage tree so that packages aren't left stranded? I haven't investigated how portage works, but if this is currently impossible, then I may be interested in building you a MySQL-based dependancy database that will provide this functionality, and maybe even a Perl-Gtk2 front-end to it that handles updates. Like I said, I have no idea how portage works, but it seems like this would be a nice feature that would save headaches for many.
*** Bug 68188 has been marked as a duplicate of this bug. ***
repoman is what we use for checking Portage tree dependencies before committing but it only checks dependencies of a package. It doesn't check reverse dependencies of a packge (packages which depend on the package being checked). Even worse we don't have any tool to do the check at the moment (ferringb posted a python script http://dev.gentoo.org/~ferringb/find-deps.py yesterday to gentoo-dev list). Surely we can check the entire tree by repoman to avoid this situation, but running repoman on entire tree is so slow that nobody wants to run it except one call it from cron job.
I am getting this after emerge sync: emerge -puvD world These are the packages that I would merge, in order: Calculating world dependencies / emerge: there are no ebuilds to satisfy "=sys-devel/automake-1.8.5-r2". !!! Problem with ebuild sys-apps/man-pages-2.01 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed.
Same problem as the previous post: Calculating world dependencies / emerge: there are no ebuilds to satisfy "=sys-devel/automake-1.8.5-r2". !!! Problem with ebuild media-gfx/gqview-1.5.6 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. What happened to automake-1.8.5-r2?
Yep, same here. Having the same problem. Why do =somecat/somedep dependencies keep appearing in ebuilds? Wouldn't >= or =< be more logical. Some ebuilds tend to be removed from the tree unknowingly breaking other ebuilds.
Sometimes we need specific version(revision) of a package, and we cannot help using the syntax if it is the only way to deal with it....
