Hi, I'm getting following output when I "emerge -upv --deep world": sol radek # expemerge -upv --deep world These are the packages that I would merge, in order: Calculating world dependencies - emerge: there are no masked or unmasked ebuilds to satisfy "docs". !!! Problem with ebuild media-video/ffmpeg-0.4.8 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. sol radek # etcat -d docs [ Results for search key : docs ] * app-doc/kdelibs-apidocs-3.1.2 app-doc/qt-docs * app-doc/kdelibs-apidocs-3.1.4 app-doc/qt-docs * app-editors/quanta-3.2.0_beta1 docs * app-editors/quanta-3.2.0_beta2 app-doc/quanta-docs * app-misc/evidence-0.9.7.20031225 docs * app-misc/examine-0.0.1.20031129 docs * app-sci/equate-0.0.4.20031225 docs * dev-db/edb-1.0.4.20031225 docs * dev-db/myodbc-3.51.06 docs? ...output continues... Taking a closer look at the ebuilds, they all (the ones with strange "docs" dependancy) seem to have strange "DEPEND=${DEPEND}" inside... I don't know if this is the problem but I hope it helps. Ask me further if necessary, I'll help since right now, I cannot update my system which is really bad! ------------------ sol radek # emerge info Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0) ================================================================= System uname: 2.6.0 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.3.12 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo" MAKEOPTS="-j6" 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 apache2 apm avi bonobo cdr cups dvd encode flash foomaticdb gif gnome gphoto2 gtk gtk2 gtkhtml imap imlib ipv6 java jpeg kde libg++ libwww lirc mad maildir matroska mbox mmx mozilla mpeg mysql ncurses oggvorbis opengl perl png python qt readline samba scanner sdl sse ssl tcltk tetex tiff truetype unicode usb x86 xml xml2 xmms xv zlib" After a minute of investigation a got this:
I pasted it wrong... The last line should be before the "etcat"... Radek
Hi, Could you show us 'emerge -upv --deep --debug world'? And what is 'expemerge'? it seems an alias. right?
Created attachment 23077 [details] Output from emerge -upv --deep --debug world Attention! The file is rather long...
Added the output as attachment... Sorry, I forgot to mention "expemerge" is just an alias for "ACCEPT_KEYWORDS="~x86" emerge"... Radek
It was enlightenment.eclass bug and already fixed. I think it works file if you do 'emerge sync' Thanks,
what bug in enlightenment.eclass ?
I think DEPEND was 'doc ( app-doc/doxygen )' in the eclass. hmm, but I can't find such as a thing in CVS now. There may be other reason..
newdepend "doc? ( app-doc/doxygen )" that's in the enlightenment.eclass ...
'doc? ( app-doc/doxygen )' is correct. 'doc ( app-doc/doxygen )' is incorrect. doc is considered as package in the case.
Just synced. The enlightenment.eclass has the doc? thingy but still no-go... :-(
I just noticed you set PORTDIR_OVERLAY. Can you unset it and retry?
I'm sorry, no change... :-(
ah, well while i may have missed the missing ? here, there was never a version of enlightenment.eclass in portage that was missing a ? :)
*** Bug 37187 has been marked as a duplicate of this bug. ***
If this issue is still persisting after another emerge sync, please check your world file (/var/cache/edb/world) and make sure that 'doc' doesn't appear by itself in that file. Post your world file if you can't find the problem and fix it.
The world file seems to be fine... :-( radek@sol df $ cat /var/cache/edb/world | grep doc x11-misc/docker app-doc/linux-gazette-all app-doc/howto-html app-text/docbook-xml-dtd app-text/docbook-xsl-stylesheets dev-util/gtk-doc app-doc/phrack-all app-text/docbook-dsssl-stylesheets app-text/docbook-sgml-utils dev-python/python-docs app-doc/php-docs ...will attach the entire world file...
Created attachment 23243 [details] world
resynced, updated to portage-2.0.49-r21: it works well now. i cross my fingers :)
Can you, please, tell me what bug was? Thanks... Radek
...what the bug was? :-)
#37187
This may sound strange but it's true: I've resynced and emerge portage -r21. The "docs" problem remained. Then, I've resynced againg (with just a few files being really updated) but now using my alias which does "emerge sync; eupdate". Voila, it started to work... The eupdate command comes from the esearch package... I don't know whether the problem was solved by the second resync or the eupdate... :-( Radek
docs problem came again this weekend, on giblib-1.2.2. eupdate didn't solve the problem, as i expected.
giblib depends on imlib2 and imlib2's ebuilds contain the strange DEPEND=${DEPEND} thing I've mentioned before. Can someone please take a look a it and experiment a bit? For me, the "docs" problem is gone and I don't want to mess up my system with giblib which I don't know what it's for... Radek
since portage is supposed to handle depend in eclasses correctly now ive fixed the imlib2 package
i'm still having the problem on giblib-1.2.2.
Looks like enlightenment.eclass's row 22 newdepend "doc? ( app-doc/doxygen )" gets completed to "docs ( app-doc/doxygen )" at some point. This can be confirmed by grepping /var/cache/edb/dep/: grep -r "docs " /var/cache/edb/dep /var/cache/edb/dep/media-libs/imlib2-1.1.0:=media-libs/freetype-2* gif? ( media-libs/libungif >=media-libs/giflib-4.1.0 ) png? ( >=media-libs/libpng-1.2.1 ) jpeg? ( media-libs/jpeg ) tiff? ( >=media-libs/tiff-3.5.5 ) virtual/x11 docs ( app-doc/doxygen ) sys-devel/gcc /var/cache/edb/dep/media-libs/imlib2-1.1.0.20040103:=media-libs/freetype-2* gif? ( media-libs/libungif >=media-libs/giflib-4.1.0 ) png? ( >=media-libs/libpng-1.2.1 ) jpeg? ( media-libs/jpeg ) tiff? ( >=media-libs/tiff-3.5.5 ) X? ( virtual/x11 ) docs ( app-doc/doxygen ) sys-devel/gcc Now the question is where does this so called completion happen and why. Maybe somewhere in newdepend script?
I think I solved this :) It's quite funny actually... I have "docs" subdir in my home directory. Now, when there is some ebuild that uses "doc? ( something )" syntax and is _not_ in portage cache, that "doc?" gets completed to "docs". This happens if there is a file or a directory with that name in the current working directory (actually it might happen when there's for example a variable, alias or function called "docs"). This kind of strange thing might happen with other use flag queries also, which is kind of nasty. Removing eg. imlib2 from portage cache, mkdir or touch docs and emerge -pv imlib2 should confirm this bug. I believe this is a bug in newdepend function, and happens when there is newdepend "foo? ( xyz/bar )" and a "fooX" directory or file in the current working directory.
And here's a short three command script for confirming this bug: # rm /var/cache/edb/dep/media-libs/imlib2-* # mkdir docX # emerge -pv imlib2 emerge: there are no masked or unmasked ebuilds to satisfy "docX".
Created attachment 23895 [details, diff] Patch to fix the weird use-flag completion in newdepend/do_newdepend Ok, this patch fixes the ebuild.sh newdepend " foo? ( bar )" completion issue. The problem was some missing quotations, both in newdepend() and in do_newdepend(). This patch only changes a few of them, so there might be other similar bugs in ebuild.sh (and other scripts too!). So I suggest some of you real developers go through the whole portage and check out for similar bugs. The very reason for this bug is the usage of those dirty "eval echo" and "eval export" hacks. Like the comment in ebuild.sh says... Cool, huh? :)
Wow! I admire you! If I tried to solve this problem, it would take a thousand years without any clue it could be caused by of this... Of course I also have the "docs" subdir in my home dir... :-) Great work! Radek
hehe, guess what? i've also a docs/ dir in my homedir :) thanks jyrki!
There's a patch, it works, the bug is annoying. Should it be fixed any time soon? I have docs/ dir too ;)
Fixed in CVS. Thanks for reporting.
Shouldn't this be closed by now? :-)
This bug has been inactive for more than 90 days. Can it be closed now?
Bug has been fixed and released in stable portages on or before 2.0.51-r2
