"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.

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.

Second-to-last thing, I see you're running the gnome overlay.  As I said, 
I don't do GNOME (KDE's more my style, 3.5 as the 4.x series just isn't 
ready for me yet) so I haven't any idea of its status or what it might 
conflict with.  Pan doesn't require GNOME, only GTK+, but particularly if 
you are running overlay GTK+ builds as well it's quite possible there's 
some sort of conflict there.  Again, the emerge log may have provided 
some clue (or may not have), but you didn't post it so it's kind of hard 
to say.

Finally, come over and visit us (or better yet, become a regular) on the 
pan lists!  See the pan website ( 
http://pan.rebelbase.com ) for more info.  Once you get it installed and 
running there's some non-obvious "advanced" tweaks possible, some only by 
directly editing the config files.  I'm personally quite an enthusiastic 
pan booster myself, and of course am a Gentoo/~amd64 user too, but since 
I don't do GNOME, my knowledge is limited in that area.  But there are 
others who can help there, tho most aren't Gentoo users.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to