When an ebuild exists both in $PORTDIR_OVERLAY and in the standard Portage tree, dependancy resolution fails if the ebuild in the standard Portage tree is older than that of the local tree. Example: me@machine % ls -l /usr/portage/app-crypt/newpg/ total 9 -rw-r--r-- 1 root root 627 2003-03-05 05:50 ChangeLog drwxr-xr-x 2 root root 88 2003-02-06 11:50 files/ -rw-r--r-- 1 root root 1172 2003-03-11 22:20 newpg-0.9.4.ebuild me@machine % ls -l /usr/local/portage/app-crypt/newpg/ total 5 drwxr-xr-x 2 root root 88 2002-12-16 20:56 files/ -rw-r--r-- 1 root root 824 2003-04-20 18:04 newpg-0.9.4.ebuild me@machine % emerge rsync [goes fine] me@machine % emerge -uUDp world These are the packages that I would merge, in order: Calculating world dependencies \ !!! all ebuilds that could satisfy ">=app-crypt/newpg-0.9.4" have been masked. !!! (dependency required by "app-crypt/aegypten-1.0" [ebuild]) !!! Problem with ebuild app-crypt/aegypten-1.0 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Note that app-crypt/aegypten-1.0 is itself in $PORTDIR_OVERLAY, not in the standard Portage tree. The problem can be worked around by doing this: sudo find /usr/local/portage -name "*.ebuild" -exec touch "{}" \; right after the emerge rsync. Portage doesn't seem to 'see' the ebuilds in the overlay tree if they're less current than that of the standard tree. I think the bug is blatant in my case only because the standard newpg-0.9.4.ebuild is masked while my own isn't; if it was unmasked, then it would be selected instead of my own ebuild and I probably wouldn't notice the bug. Reproducible: Always Steps to Reproduce: 1. Install Paul de Vrieze's ebuilds for Aegypten (http://www.niii.kun.nl/~pauldv/kmailgentoo.php) in the local Portage tree, since they're good for triggering the bug. Note that the ebuilds are unmasked (they're under arch x86 rather than ~x86). 2. emerge rsync to update the standard Portage tree. 3. emerge -Dup aegypten triggers the bug. Actual Results: These are the packages that I would merge, in order: Calculating dependencies | !!! all ebuilds that could satisfy ">=app-crypt/newpg-0.9.4" have been masked. !!! (dependency required by "app-crypt/aegypten-1.0" [ebuild]) !!! Error calculating dependancies. Please correct. Expected Results: Correct emerge -p output. emerge info: Portage 2.0.47-r10 (default-1.0, gcc-2.95.3, glibc-2.2.5-r8) ================================================================= System uname: 2.4.20-gentoo-r2 i686 AMD Athlon(tm) XP 1600+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://mirrors.sunsite.dk/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo/ ftp://ftp.rez-gif.supelec.fr/pub/Linux/distrib/gentoo/ " CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 3dnow libg++ xml2 esd ggi gnome-libs gtk libwww motif perl svga tcltk tetex aalib acl acpi alsa apm arts avi berkdb cdr crypt cups dga doc dvd encode ethereal flash gdbm gif gphoto2 gpm imap imlib innodb java jikes jpeg kde maildir mbox mikmod mmx mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib png python qt qtmt quicktime readline samba sasl scanner sdl slang spell sse ssl tcpd tiff truetype usb wmf X xmms xv zlib" COMPILER="" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
the ebuids are all ~x86 masked could you attach your ebuilds please
Created attachment 10922 [details] Local ebuilds for aegypten, newpg, pinentry and cryptplug Darn, you're right, the ebuilds are no longer on Paul's page. Here are those from my own local tree; they ought to trigger the bug correctly. So to speak.
are they from portage tree or portage_overlay please attache the others too
Created attachment 11018 [details] Portage ebuilds for newpg, pinentry and cryptplug The previous tgz was from my local tree; this one is from the standard Portage tree. Sorry for not making this clearer! Note that there is no 'aegypten' ebuild in the standard Portage tree. I don't know if that relates to the problem being reported here (I would suspect not, otherwise why would the 'find -exec touch' trick fix the problem until the next emerge sync...?). Also note that app-crypt/aegypten is in my world file, hence the bug being triggered on a world update. Is there any other info you'd need me to provide? Additional tests I could make to help identifying the bug?
please attach the builds
Dang, I'm a little confused... Do you mean you want the ebuilds attached 'as is', as opposed to in a TGZ archive like I did before, Martin? Thanks.
this is what i got Calculating dependencies / !!! all ebuilds that could satisfy ">=dev-libs/libgcrypt-1.1.8" have been masked. !!! (dependency required by "app-crypt/newpg-0.9.4" [ebuild]) !!! Error calculating dependancies. Please correct.
watch package.mask + use ~x86 or change to stable in ebuilds
Once more, the ebuilds in my $PORTDIR_OVERLAY *are* marked stable, ie, they contain the line KEYWORDS="x86", *not* "~x86", and they're not in package.mask, either. If it was a problem of stable vs. unstable, then 'touch'ing the ebuilds wouldn't fix it, would it? Tell you what, leave this bug closed, I'll try to come up with a clearer instance of the problem, if possible. Thanks for your help!
last time
I think that what he is reporting as a bug is that portage ignores ebuilds in $PORTDIR_OVERLAY if identically named ones exist in $PORTDIR with a newer time-stamp. This is shown by the following behaviour that I experence: # emerge sync [Snip...] # emerge world -DUp >>> --upgradeonly implies --update... adding --update to options. These are the packages that I would merge, in order: Calculating world dependencies | !!! all ebuilds that could satisfy ">=dev-libs/libmrproject-0.9.1" have been masked. !!! (dependency required by "app-office/mrproject-0.9.1" [ebuild]) !!! Problem with ebuild app-office/mrproject-0.9.1 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. # touch /usr/local/portage/dev-libs/libmrproject/libmrproject-0.9.1.ebuild # emerge world -DUp >>> --upgradeonly implies --update... adding --update to options. These are the packages that I would merge, in order: Calculating world dependencies \ !!! all ebuilds that could satisfy ">=app-text/docbook-dsssl-stylesheets-1.77-r2" have been masked. !!! (dependency required by "dev-libs/libgcrypt-1.1.12" [ebuild]) !!! Problem with ebuild dev-libs/libgcrypt-1.1.12 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. # touch /usr/local/portage/app-text/docbook-dsssl-stylesheets/docbook-dsssl-stylesheets-1.77-r2.ebuild # emerge world -DUp >>> --upgradeonly implies --update... adding --update to options. These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] media-libs/libart_lgpl-2.3.11 [2.3.10] The two ebuilds shown above in /usr/local/portage are identical to those in /usr/portage except that their keywords have been changed from "~x86" to "x86". I have several unstable (~x86) packages merged with my mostly stable (x86) system, but these are the only two ebuilds that produce this behaviour. I have to touch the ebuilds after every emerge sync if I want to run emerge world -DU. Running emerge world with -Du or -U do not reproduce this behaviour. Hope this helps.
> I think that what he is reporting as a bug is that portage ignores > ebuilds in $PORTDIR_OVERLAY if identically named ones exist > in $PORTDIR with a newer time-stamp. Woohoo! This is indeed exactly the problem that hit me. Thank you so much, Eric! I didn't know this was actually a feature. I guess that in my case, Portage would try to update the aegypten ebuild (marked x86, in PORTAGE_OVERLAY), look for its dependancies, find them in both the normal Portage dir and the overlay one, and dismiss the latter. Even though the latter was stable (x86) while the former is unstable (~x86)! Maybe an unmasked ebuild SHOULD have precedence over a masked one regardless of timestamps? What do you think? At any rate, this makes this bug report 'INVALID', I guess, so you can close it and leave it closed (yay!). If you think it's worth it, though, I'll submit a feature request suggesting that unmasked ebuilds in PORTAGE_OVERLAY should have precedence over similar, but masked ebuilds in /usr/portage regardless of timestamps, since that's more logical. Not sure it's -really- worth the trouble though.
This should be fixed in 48_pre6, which will be unmasked ~arch very shortly.
This totally rocks! One thousand thanks, Nicholas. :)
Have you tested this yet? I'd like to know if I actually fixed it.
Tested now and works for me. Thanks. Now I notice that running an emerge world causes my Konsole titlebar to be renamed from "Shell - Konsole" to "xterm - Shell - Konsole" after an emerge world invocation finishes. Setting FEATURES="notitles" in make.conf doesn't make any difference. Not that it's making the system unuseable or anything.
closing for the new bug, please open a new bug
