Re: [gentoo-amd64] Re: Some weird issues with portage

[Beso]

2008/11/20 Tonko Mulder <tonko.mulder@×××××.com>:
> On Wed, Nov 19, 2008 at 7:40 PM, Duncan <1i5t5.duncan@×××.net> wrote:
>> "Tonko Mulder" <tonko.mulder@×××××.com> posted
>> 43ba12950811190150s1a8ea692ld30246ed60c07999@××××××××××.com, 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
>>>
>>> tonko@Gaius ~/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