Bastian Balthazar Bux wrote: > Jesse Guardiani ha scritto: > >>Bastian Balthazar Bux wrote: >> >> >> >>>Jesse Guardiani ha scritto: >>> >>> >>> >>>>Hello, >>>> >>>>I'm trying to set up a binary portage server for use >>>>with `emerge -g`. It's set up, but I think there is >>>>either a problem with my binary packages (created using >>>>`qpkg -I -nc | & xargs -n 1 -r quickpkg` on the binary >>>>server machine), or with my portage trees. I keep >>>>getting this: >>>> >>>>[11:[EMAIL PROTECTED]:[/home/jesse]# emerge -g --update --deep world >>>>Fetching binary packages info... >>>>Loaded metadata pickle. >>>>cache miss: 'x' --- cache hit: 'o' >>>>ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo >>>> -- DONE! >>>> >>>>Calculating world dependencies - >>>>emerge: there are no ebuilds to satisfy ">=dev-libs/fftw-3.0.1". >>>> >>>> >>>>!!! Problem with ebuild media-sound/audacity-1.2.1 >>>>!!! Possibly a DEPEND/*DEPEND problem. >>>> >>>>!!! Depgraph creation failed. >>>>Exit 1 >>>>[11:[EMAIL PROTECTED]:[/home/jesse]# >>>> >>>> >>>> >>>> >>>the problem is that dev-libs/fftw now is sci-libs/fftw , probably some >>>packages still point to dev-libs/fftw and so it can't find it, blockink >>>the whole emerge. >>>Try to emerge first fftv on the client machine and then "emerge -g >>>--update --deep world" (I think it not solve your problem) >>> >>> >> >>I'm not sure if you meant that you think it will or won't solve the >>problem, but fftv is already emerged on the client: >> >>* sci-libs/fftw >> Latest version available: 3.0.1 >> Latest version installed: 3.0.1 >> Size of downloaded files: 1,900 kB >> Homepage: http://www.fftw.org >> Description: C subroutine library for computing the Discrete Fourier >> Transform (DFT) >> License: GPL-2 >> >>I think I rebuilt it by hand when I first encountered the problem. >> >> >> >> >>>or find the wrong ebuild and file a bug for it (with many tanks from all >>>we) >>> >>> >> >>Since I ONLY encounter this problem when using binary packages and since >>I built my packages using `quickpkg`, I assume that the problem is in one >>or more of those binary packages. Is there a way to extract dependency >>info from binary packages so I can figure out which packages are looking >>for dev-libs instead of sci-libs? >> >> > To find dependancies: > > quoting Alec > > The easiest way I can think of is using AUX_GET.py. I can't remember > if it came with portage, or if genone gave it to me. Anyway, here it > is. Now if you want something out of ebuilds just do aux_get.py DEPEND > PACKAGE and it will go into the Database and fetch it. > The down side is it used the portage database instead of the ebuilds > themselves, so it's kinda slow ;) > >> >> >> >>>alternatively you can emerge it and then make emerge think it's >>>provided via /etc/portage/profile/package.provided >>> >>> >> >>I'd prefer to rebuild the package(s) exhibiting incorrect deps. >> >> > So I think you should rebuild fftw, then the depending packages on the > server, repackage them and move them to the client. > Pleas don't kill me if it's wrong
Ugh, that didn't work. I ended up placing fftw in package.provided, then I tried again, then I waited for another 15 minutes while portage crunched dependencies on my 500mhz, then I added the next bad package, and so on... Eventually, I ended up with this in package.provided: dev-libs/fftw-3.0.1 gnome-base/ORBit-2.12 app-text/docbook-sgml-dtd-3.0-r1 app-text/docbook-sgml-dtd-3.1-r1 app-text/docbook-sgml-dtd-4.1-r1 app-text/docbook-sgml-dtd-4.0-r1 And as of a few minutes ago I finally completed my binary upgrade. This wouldn't be such a bad procedure if it didn't take 15 minutes to find the next bad package. If I could see all bad packages up front then this would be pretty easy. Oh well, I ain't gonna code it, so I guess I should stop complaining. :) -- 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 -- [email protected] mailing list
