Jesse Guardiani wrote: > Jesse Guardiani wrote: > >> Hello, >> >> I'm getting caught by all kinds of weirdness. It's probably >> just user error, but it feels like a bug. Can someone take >> a look at my output? Here it is: >> >> [19:[EMAIL PROTECTED]:[/usr/portage/packages/All]# emerge -gK --deep world >> Fetching binary packages info... >> Loaded metadata pickle. >> Location has moved: http://office.wingnet.net/gentoo-packages/ >> cache miss: 'x' --- cache hit: 'o' >> ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo >> -- DONE! >> >> Calculating world dependencies >> *** Package in world file is not installed: sys-apps/sh-utils >> >> *** Package in world file is not installed: sys-apps/fileutils >> >> *** Package in world file is not installed: sys-apps/textutils >> ...done! >> sys-process/procps-3.2.4-r3 >> sys-process/daemontools-0.76-r4 >> sys-process/at-3.1.8-r11 >> sys-process/vixie-cron-4.1-r4 >> >> These are required by '--usepkgonly' -- Terminating. >> >> Exit 1 >> >> But all of those software packages exist on the binary server: >> >> # ls -al /usr/portage/packages/All/procps-3.2.4-r3.tbz2 >> -rw-r--r-- 1 root root 227892 Mar 25 14:34 >> /usr/portage/packages/All/procps-3.2.4-r3.tbz2 >> # ls -al /usr/portage/packages/All/daemontools-0.76-r4.tbz2 >> -rw-r--r-- 1 root root 73023 Mar 25 14:34 >> /usr/portage/packages/All/daemontools-0.76-r4.tbz2 >> # ls -al /usr/portage/packages/All/at-3.1.8-r10.tbz2 >> -rw-r--r-- 1 root root 71593 Mar 23 19:27 >> /usr/portage/packages/All/at-3.1.8-r10.tbz2 >> # ls -al /usr/portage/packages/All/vixie-cron-4.1-r4.tbz2 >> -rw-r--r-- 1 root root 94559 Mar 25 14:34 >> /usr/portage/packages/All/vixie-cron-4.1-r4.tbz2 >> >> However, these files were probably built on a different server and >> transfered to the binary server's package dir later. Does anything >> else have to be done before they're usable by clients? >> >> NOTE: fixpackages has been run both on the binary server and on the >> client. > > This doesn't look right either, does it? > > # emerge -g --update --deep world > Fetching binary packages info... > Loaded metadata pickle. > Location has moved: http://office.wingnet.net/gentoo-packages/ > cache miss: 'x' --- cache hit: 'o' > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > -- DONE! > > Calculating world dependencies / > emerge: there are no ebuilds to satisfy "virtual/snmp". > > > !!! Problem with binary net-firewall/fwbuilder-2.0.0 > !!! Possibly a DEPEND/*DEPEND problem. > > !!! Depgraph creation failed. > Exit 1
FYI to anyone who has problems with `emerge -gD world`, `emerge -GD world`, `emerge -gDK world`, `emerge -GDK world`, `emerge -gDk world`, emerge -GDk world`, or `emerge -kD world` complaining inexplicably about DEPEND problems (particularly about virtual/snmp): I think it's a bug, and I got tired of trying to fix it without knowing what caused it, so I worked around this issue locally by sharing my /usr/portage/packages and /usr/portage/distfiles directories via NFS on the local LAN and using a slightly modified "pye" (Pick Your Emerge) script. First, download pye: http://tinyurl.com/6td25 Then modify it like so (causes it to try a binary package emerge for each ebuild it attempts to emerge): # diff -u pye~ pye --- pye~ 2005-03-26 14:58:56.000000000 -0500 +++ pye 2005-03-26 15:06:14.000000000 -0500 @@ -66,7 +66,7 @@ def mergethis(package): """Merge given package and return True if successful.""" - os.system("emerge %s" % package) + os.system("emerge -k %s" % package) global pkgdict package = package.split("/")[1] vartree = portage.vartree() Exit 1 Then run this command: ./pye -e uD world If your packages and distfiles directories are properly mounted over NFS then this should work just as well as an `emerge -gKD world` - better actually, because it won't complain about virtual/snmp. The only downside is that NFS is slow, so it won't work well over a T1 or DSL. For that, I suggest replicating your package and distfile repositories via the unison file synchronizer as it handles updates at either end and will let you feed any updated packages back into your binary server's main repository. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net -- gentoo-user@gentoo.org mailing list
