It is the official portage tree, it's just git based ;) On Thu, Nov 20, 2008 at 10:24 AM, Beso <[EMAIL PROTECTED]> wrote: > 2008/11/20 Tonko Mulder <[EMAIL PROTECTED]>: >> On Wed, Nov 19, 2008 at 7:40 PM, Duncan <[EMAIL PROTECTED]> wrote: >>> "Tonko Mulder" <[EMAIL PROTECTED]> posted >>> [EMAIL PROTECTED], excerpted >>> below, on Wed, 19 Nov 2008 10:50:59 +0100: >>> >>>> I have a weird problem with portage. >>>> I tried to install pan and I got the following error >>>> >>>> [EMAIL PROTECTED] ~/dev/repo/portage $ sudo emerge pan -avq [ebuild NS ] >>>> dev-libs/gmime-2.2.23 [2.4.2] USE="mono -debug -doc" [ebuild N ] >>>> net-nntp/pan-0.133 USE="spell" >>>> >>>> Would you like to merge these packages? [Yes/No] y >>>>>>> Verifying ebuild manifests >>>>>>> Starting parallel fetch >>>>>>> Emerging (1 of 2) dev-libs/gmime-2.2.23 Installing >>>>>>> dev-libs/gmime-2.2.23 >>>>>>> Jobs: 0 of 2 complete Load avg: 3.67, 2.22, >>>>>>> 1.64/sbin/ldconfig: File /usr/lib/libemeraldengine.so.0 is empty, not >>>>>>> checked. >>>> /sbin/ldconfig: File /usr/lib/libemeraldengine.so is empty, not checked. >>>> /sbin/ldconfig: File /usr/lib/libemeraldengine.so.0.0.0 is empty, not >>>> checked. >>> >>> This looks very strange to me. Empty shared-object libs? >>> >>> FWIW, I have gmime-2.2.23 (only, no 2.4.x) merged here, with USE=-mono, >>> and equery b libemeraldengine.so returns nothing, so those >>> libemeraldengine.so* files must be mono related. >>> >> It's not just pan/gmime, it's for every ebuild. >> I now also get 'compiler cannot create executable' and I forgot what >> the solution for that was. >>> I don't know why you have the mono USE flag on for gmime, presumably >>> something you have merged needs it for the gmime 2.4 slot, since I don't >>> see it turned on in your USE flags, and you have it in package.use for >>> gmime (or maybe it's on for your profile). Regardless, the gmime-2.2.23 >>> package (slot 0) is being merged new-slot for pan specifically, and I >>> know for a fact that it doesn't use it (I'm a long-time regular over on >>> the pan lists), so you could turn it off for slot-0. If you already have >>> an entry in package.use for it, try limiting it to dev-libs/gmime:2.4 . >>> >>> dev-libs/gmime:2.4 mono >>> >>> If you don't, either turn it off globally (but that may not work well if >>> you need it for other packages, I don't run GNOME but I believe it's >>> needed for parts of it), or add a package.use entry turning it off for >>> dev-libs/gmime:0 . >>> >>> dev-libs/gmime:0 -mono >>> >>> Meanwhile, I don't know if that's the problem or not, only that empty >>> *.so* files look rather suspicious, and that I have gmime-2.2.23 build >>> -mono here and it works fine for pan. >>> >>>>>>> Emerging (2 of 2) net-nntp/pan-0.133 >>>>>>> Installing net-nntp/pan-0.133 >>>>>>> Jobs: 1 of 2 complete Load avg: 4.05, 3.16, >>>>>>> 2.11 >>>> Traceback (most recent call last): >>>> File "/usr/bin/emerge", line 18, in <module> [snip] >>>> My knowledge of python isn't that great, so any help is appreciated. >>> >>> I don't know python well, but I do know that emerge should not be >>> aborting with a traceback. The portage guys put a lot of effort into >>> catching any problems they know about and making them spit out errors in >>> "English", so any time a traceback occurs in portage/emerge, it indicates >>> a serious problem with it that they didn't foresee, and it's bug time! >>> Of course, you (like me) are running a ~arch version of portage (2.2 is >>> still in -rcs and hasn't hit stable yet), so there /are/ going to be bugs >>> of this sort they haven't caught just yet. I'd file a portage bug on it >>> and let the portage guys sort it out. You'll want to attach the log file >>> (if it hadn't done the traceback and it errored out, it would have told >>> you where, you probably know tho) as well. >>> >>> Also, it looks like gmime merged fine (if those libemeraldengine warnings >>> don't indicate it's broken, but it still merged), did you try running the >>> merge again? It should now be just pan. Maybe it'll merge. Anyway, try >>> it, possibly without the parallel-merge options (--jobs --load-average) >>> so you can see the output and where it fails. Or... that'll be in the >>> log mentioned above. >>> >>> There may or may not also be a pan bug. It's a bit difficult to tell >>> without the log, which doesn't show up on screen when you're parallel >>> merging because several would be jumbled together. Portage would >>> normally spit it out at the end if there was a problem, but not when >>> emerge itself crashes as it did here. >>> >>>> emerge --info www.xs4all.nl/~mtonko/emerge.info >>> >>> BTW, far be it from me to tell you not to do it as I've rather customized >>> my system layout as well, but I gotta ask, if only to satisfy my own >>> curiosity... /dev is normally for devices and will in most cases be udev/ >>> tmpfs based. /dev/repo/portage? I'd love to know the story behind that. >>> >> I don't see that path in my emerge --info, but FYI the full path is >> ~/dev/repo/portage and it's my git based portage tree (testing) by >> Daniel Robbins. > > well, so this isn't the official portage tree. i think you'd better go > with official portage and see what happens. in my opinion the issue > you're having is because of some weird stuff in funtoo overlay. you > might need to reinstall portage manually (download portage from gentoo > or funtoo and untar it in /usr/portage) and then retry. > > -- > dott. ing. beso > >
-- Tonko
