[gentoo-amd64] Some weird issues with portage

[gentoo-amd64] Some weird issues with portage

[Tonko Mulder]

Hello list,

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.
>>> 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>
    retval = _emerge.emerge_main()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 14212, in emerge_main
    myopts, myaction, myfiles, spinner)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 13256, in
action_build
    retval = mergetask.merge()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 9642, in merge
    rval = self._merge()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 9884, in _merge
    self._main_loop()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 10019, in _main_loop
    self._poll_loop()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 8590, in _poll_loop
    handler(f, event)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 2212, in
_output_handler
    self.wait()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1666, in wait
    self._wait_hook()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1739, in _wait_hook
    self._exit_listener_stack.pop()(self)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 2644, in
_buildpkg_exit
    self.wait()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1666, in wait
    self._wait_hook()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1739, in _wait_hook
    self._exit_listener_stack.pop()(self)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1922, in
_default_final_exit
    return self.wait()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1666, in wait
    self._wait_hook()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1739, in _wait_hook
    self._exit_listener_stack.pop()(self)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 9864, in _build_exit
    self._schedule()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 8503, in _schedule
    return self._schedule_tasks()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 10031, in
_schedule_tasks
    if q.schedule():
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 8395, in schedule
    task.start()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 1647, in start
    self._start()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 3684, in _start
    self.returncode = self.merge.merge()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 3651, in merge
    retval = self._install_task.install()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 2683, in install
    rval = merge.execute()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 3021, in execute
    blockers=self.find_blockers)
  File "//usr/lib64/portage/pym/portage/__init__.py", line 6077, in merge
    mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "//usr/lib64/portage/pym/portage/dbapi/vartree.py", line 3811, in merge
    mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "//usr/lib64/portage/pym/portage/dbapi/vartree.py", line 3821, in _merge
    cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "//usr/lib64/portage/pym/portage/dbapi/vartree.py", line 3137,
in treewalk
    blockers = self._blockers()
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 9341, in get_blockers
    return self._find_blockers_with_lock(new_pkg, acquire_lock=0)
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 9358, in
_find_blockers_with_lock
    new_pkg, acquire_lock=acquire_lock):
  File "//usr/lib64/portage/pym/_emerge/__init__.py", line 3924, in
findInstalledBlockers
    cached_blockers.counter != long(inst_pkg.metadata["COUNTER"]):
ValueError: invalid literal for long() with base 10: ''

My knowledge of python isn't that great, so any help is appreciated.

emerge --info www.xs4all.nl/~mtonko/emerge.info

-- 
Tonko

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

[Duncan]

"Tonko Mulder" <tonko.mulder@gmail.com> posted
43ba12950811190150s1a8ea692ld30246ed60c07999@mail.gmail.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.

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

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

[Tonko Mulder]

On Wed, Nov 19, 2008 at 7:40 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Tonko Mulder" <tonko.mulder@gmail.com> posted
> 43ba12950811190150s1a8ea692ld30246ed60c07999@mail.gmail.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.
> 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.
>
I'll try to remove the overlay and see how it goes :)
> 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.
>
I'm subscribed to the list as of today :)
> --
> 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
>
>
>



-- 
Tonko

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

[Beso]

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

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

[Tonko Mulder]

It is the official portage tree, it's just git based ;)

On Thu, Nov 20, 2008 at 10:24 AM, Beso <givemesugarr@gmail.com> wrote:
> 2008/11/20 Tonko Mulder <tonko.mulder@gmail.com>:
>> On Wed, Nov 19, 2008 at 7:40 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>> "Tonko Mulder" <tonko.mulder@gmail.com> posted
>>> 43ba12950811190150s1a8ea692ld30246ed60c07999@mail.gmail.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
>
>



-- 
Tonko

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

[Beso]

2008/11/20 Tonko Mulder <tonko.mulder@gmail.com>:
> It is the official portage tree, it's just git based ;)
>

so it's not the devel tree. well, still, try manually downloading
portage and see if untaring it would work. also you could run
python-updater and see if you have something that depends on it. also
install another package manager, like paludis or pkgcore, so that if
portage has problem you still have a backup.

-- 
dott. ing. beso

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

[Duncan]

"Tonko Mulder" <tonko.mulder@gmail.com> posted
43ba12950811200057t7d6ad5fehbe03184c6f56b006@mail.gmail.com, excerpted
below, on  Thu, 20 Nov 2008 08:57:17 +0000:

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

Now /that/ might explain the empty *.so* libs as well.  If it can't 
create executables, it likely can't properly create libraries either.  
That might have been when it started, right there.

If you're getting compiler can't create executables on top of the other 
thing, it could mean whatever was the problem has caused other problems 
and your systems getting more and more screwed up.  Tread carefully, or 
you may end up having to reinstall from a stage tarball and effectively 
start over (but without having to repartition and all that, starting from 
the stage tarball).

If you've been using FEATURES=buildpkg, you probably have a working gcc 
package you and remerge over top of the old one, to fix gcc if it becomes 
necessary.  If not, you can unpack a stage tarball into a testing area, 
chroot into it, quickpkg up the gcc version that's there thus creating a 
binary package, then back outside the chroot again, emerge -K the binary 
package you created.  That's the usual emergency procedure to restore a 
working gcc.  Of course, that gcc will be the one from the stage tarball, 
and you'll have to use it to remerge a normal system gcc with your own 
USE flags, etc.

If portage or python (which portage needs to work) is screwed, the 
emergency procedure for replacing it starts the same way (unpack a stage 
tarball, chroot into it, use quickpkg to create a binpkg of whatever you 
need), but once out of the chroot, you have to do something different as 
the portage you'd merge the binpkg with is broken.  In that case, first 
backup config files such as make.conf that the package will include and 
thus will overwrite if you use this procedure, then untar the binary 
package (which is a tar.bz2 with some extra data glued on the end) to /, 
directly over top of your working system.  That should get you a working 
portage or python or whatever again, but as I said, any config files that 
the package would have normally updated will be directly overwritten with 
the default versions.  Thus the backups, which you can now restore over 
the default versions.  Of course, if the brokenness was in your config 
files, that will break it again, but you'll already have the package 
available to untar over / again, and you'll /know/ it's in the config the 
second time around and can be more careful restoring your backup config.  
At this point you should be working again, but since you bypassed 
portage, its idea of what's installed will be out of sync with what's 
really installed.  Thus, you'll need to remerge a working package once 
again to get portage back in sync, and you may have a few stale files to 
cleanup by hand as well, if the filenames changed or the packages 
otherwise didn't install exactly the same files.  Still, that's better 
than having to start from the stage tarball and reinstall 
/everything/.

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

"Oh, well, carry on then." =;^)

FWIW I saw it in your login prompt, but missed the ~ at the beginning, 
which makes /all/ the difference.  Now that you've explained it, pointing 
out my /small/ oversight which wasn't so small after all =:^(, it makes 
perfect sense.  So, um... yeah... carry on!  Don't mind me!  Nothing to 
see here!  =;^)

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

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

[Tonko Mulder]

Op donderdag 20-11-2008 om 13:08 uur [tijdzone +0000], schreef Duncan:
> "Tonko Mulder" <tonko.mulder@gmail.com> posted
> 43ba12950811200057t7d6ad5fehbe03184c6f56b006@mail.gmail.com, excerpted
> below, on  Thu, 20 Nov 2008 08:57:17 +0000:
> 
> >> 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.
> 
> Now /that/ might explain the empty *.so* libs as well.  If it can't 
> create executables, it likely can't properly create libraries either.  
> That might have been when it started, right there.
> 
> If you're getting compiler can't create executables on top of the other 
> thing, it could mean whatever was the problem has caused other problems 
> and your systems getting more and more screwed up.  Tread carefully, or 
> you may end up having to reinstall from a stage tarball and effectively 
> start over (but without having to repartition and all that, starting from 
> the stage tarball).
> 
> If you've been using FEATURES=buildpkg, you probably have a working gcc 
> package you and remerge over top of the old one, to fix gcc if it becomes 
> necessary.  If not, you can unpack a stage tarball into a testing area, 
> chroot into it, quickpkg up the gcc version that's there thus creating a 
> binary package, then back outside the chroot again, emerge -K the binary 
> package you created.  That's the usual emergency procedure to restore a 
> working gcc.  Of course, that gcc will be the one from the stage tarball, 
> and you'll have to use it to remerge a normal system gcc with your own 
> USE flags, etc.
> 
I emerged gcc with the -k option and all seems to be well. 
My world file was also empty, but using regenworld that's kinda back to
it's old self.
Portage seems to install everything fine, there some quircks from trying
to install compix-fusion. But I'll try that later.

> If portage or python (which portage needs to work) is screwed, the 
> emergency procedure for replacing it starts the same way (unpack a stage 
> tarball, chroot into it, use quickpkg to create a binpkg of whatever you 
> need), but once out of the chroot, you have to do something different as 
> the portage you'd merge the binpkg with is broken.  In that case, first 
> backup config files such as make.conf that the package will include and 
> thus will overwrite if you use this procedure, then untar the binary 
> package (which is a tar.bz2 with some extra data glued on the end) to /, 
> directly over top of your working system.  That should get you a working 
> portage or python or whatever again, but as I said, any config files that 
> the package would have normally updated will be directly overwritten with 
> the default versions.  Thus the backups, which you can now restore over 
> the default versions.  Of course, if the brokenness was in your config 
> files, that will break it again, but you'll already have the package 
> available to untar over / again, and you'll /know/ it's in the config the 
> second time around and can be more careful restoring your backup config.  
> At this point you should be working again, but since you bypassed 
> portage, its idea of what's installed will be out of sync with what's 
> really installed.  Thus, you'll need to remerge a working package once 
> again to get portage back in sync, and you may have a few stale files to 
> cleanup by hand as well, if the filenames changed or the packages 
> otherwise didn't install exactly the same files.  Still, that's better 
> than having to start from the stage tarball and reinstall 
> /everything/.
> 
> > 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.
> 
> "Oh, well, carry on then." =;^)
> 
> FWIW I saw it in your login prompt, but missed the ~ at the beginning, 
> which makes /all/ the difference.  Now that you've explained it, pointing 
> out my /small/ oversight which wasn't so small after all =:^(, it makes 
> perfect sense.  So, um... yeah... carry on!  Don't mind me!  Nothing to 
> see here!  =;^)
> 

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

[Duncan]

Tonko Mulder <tonko.mulder@gmail.com> posted
1227215380.6329.4.camel@Gaius, excerpted below, on  Thu, 20 Nov 2008
22:09:40 +0100:

> I emerged gcc with the -k option and all seems to be well. My world file
> was also empty, but using regenworld that's kinda back to it's old self.
> Portage seems to install everything fine, there some quircks from trying
> to install compix-fusion. But I'll try that later.

Cool! =:^)

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