Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Peter Humphrey wrote:
> On Thursday 22 October 2015 17:11:42 Dale wrote:
>> Alan McKinnon wrote:
>>> On 22/10/2015 23:51, Dale wrote:
 Neil Bothwick wrote:
> On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:
>> Of course, there is better ways of finding this info but I never can
>> remember the command and it takes me a bit to figure out what options
>> do what so I finally said "screw it" and work without it unless I just
>> must have it.  If I only need one, I use the date command.  It
>> works.  ;-)
> genlop -l --date yesterday
>
> Not too hard to remember :)
 It is when you only use it once every year or two.  Generally, it is
 rare that I have to even go look at the emerge log file.  This is likely
 the first time I have looked in there in a good long while. Maybe over a
 year.  Sometimes, I wonder if I even need the thing.
>>> Of course you need it - genlop won't work without it
>> That's the point.  I rarely use it.  The only genlop command I may use
>> every once in a while is genlop -c.  I use that to see how long
>> something has been compiling or if it is a major upgrade, what is
>> actually being compiled at the time.  Generally, the estimated time
>> remaining is worthless.  Most of the time, it isn't even in the ballpark.
> Genlop is just a simple tool. I know of two cases it doesn't cope with well: 
> first, simultaneous emerges of the same package in the main system and in a 
> chroot; second, emerge -k.
>
> I sometimes do a batch of emerge -B followed with emerge -k. The time taken 
> from emerge.log is tiny in that case, but genlop still includes it in its 
> calculation of average emerge time.
>
> Any time I want to emerge -e world I do it that way. Also any KDE upgrade 
> gets 
> the same treatment: first compile the packages, then shut down KDE and 
> install 
> them. That way I don't get problems in trying to restart KDE when half its 
> code has changed.
>


What I have noticed about the time estimation is this.  When emerge is
working on several packages compiled in parallel, that slows each
package down.  Instead of using all four cores to work on one package,
those four cores may be working on half a dozen packages.  That alone
makes the time estimator wrong, sometimes by a lot.  If I set portage to
compile only one package at a time, then it would be more accurate. 
Thing is, it also makes it take longer. 

I sometimes use -k but not to often.  It can be handy tho.  The times I
have used it is when I update Firefox/seamonkey and some plugin doesn't
work.  I just go back to a earlier version until it gets fixed/updated. 
Usually tho, Firefox/Seamonkey catches it and just disables the thing
instead of not coming up at all. 

I do upgrades to KDE and just let it update while I am doing something
else, usually sleeping.  When it gets done, I log out and back in and
the new stuff loads up.  So far, I've never had any trouble with it. 
The stuff it is using is usually already loaded anyway.  Luck maybe.

Either way, I just don't use genlop much.  I rarely use the q* commands
either.  I use qlop -s on occasion to see when my last sync was but even
that is not to often.  I generally do mine on Sundays, Tuesdays and
either Thursday or Friday.  Sometimes if a check of the packages Gentoo
page shows little changes, I may skip a update or two. 

Dale

:-)  :-) 

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Peter Humphrey]

On Thursday 22 October 2015 17:11:42 Dale wrote:
> Alan McKinnon wrote:
> > On 22/10/2015 23:51, Dale wrote:
> >> Neil Bothwick wrote:
> >>> On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:
>  Of course, there is better ways of finding this info but I never can
>  remember the command and it takes me a bit to figure out what options
>  do what so I finally said "screw it" and work without it unless I just
>  must have it.  If I only need one, I use the date command.  It
>  works.  ;-)
> >>> 
> >>> genlop -l --date yesterday
> >>> 
> >>> Not too hard to remember :)
> >> 
> >> It is when you only use it once every year or two.  Generally, it is
> >> rare that I have to even go look at the emerge log file.  This is likely
> >> the first time I have looked in there in a good long while. Maybe over a
> >> year.  Sometimes, I wonder if I even need the thing.
> > 
> > Of course you need it - genlop won't work without it
> 
> That's the point.  I rarely use it.  The only genlop command I may use
> every once in a while is genlop -c.  I use that to see how long
> something has been compiling or if it is a major upgrade, what is
> actually being compiled at the time.  Generally, the estimated time
> remaining is worthless.  Most of the time, it isn't even in the ballpark.

Genlop is just a simple tool. I know of two cases it doesn't cope with well: 
first, simultaneous emerges of the same package in the main system and in a 
chroot; second, emerge -k.

I sometimes do a batch of emerge -B followed with emerge -k. The time taken 
from emerge.log is tiny in that case, but genlop still includes it in its 
calculation of average emerge time.

Any time I want to emerge -e world I do it that way. Also any KDE upgrade gets 
the same treatment: first compile the packages, then shut down KDE and install 
them. That way I don't get problems in trying to restart KDE when half its 
code has changed.

-- 
Rgds
Peter

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Neil Bothwick wrote:

On Thu, 22 Oct 2015 09:53:57 +, Alan Mackenzie wrote:


1445464761:  >>> unmerge success: sys-libs/glibc-2.20-r2
1445464768:  === (1 of 13) Post-Build Cleaning
(sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
1445464768:  ::: completed emerge (1 of 13) sys-libs/glibc-2.21-r1
to /

This is nothing to do with your problem, but it might be useful
nonetheless.

I finally got fed up with these "seconds since the epoch" time stamps a
couple of days ago, and wrote a little filter to turn them into readable
time stamps.  Probably there is software around already which does this,
but the effort to write the script was less than that to search for the
existing software.

Either genlop or qlop (from portage-utils) will do this and much more.
You probably already have at least one of them installed.





It can be done with the date command if you only need one done. Thing 
is, I already knew when this was done so the time stamps didn't matter 
to me.  I went to the bottom of the file, the last emerges I did, then 
looked at the update section of the log.  I didn't need timestamps to 
know where it was or anything.  Go to bottom, scroll up a bit and look 
for the world update part.


Of course, there is better ways of finding this info but I never can 
remember the command and it takes me a bit to figure out what options do 
what so I finally said "screw it" and work without it unless I just must 
have it.  If I only need one, I use the date command.  It works.  ;-)


I'm getting to old for this stuff.  :/

Dale

:-)  :-)

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Neil Bothwick]

On Thu, 22 Oct 2015 09:53:57 +, Alan Mackenzie wrote:

> > 1445464761:  >>> unmerge success: sys-libs/glibc-2.20-r2
> > 1445464768:  === (1 of 13) Post-Build Cleaning
> > (sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
> > 1445464768:  ::: completed emerge (1 of 13) sys-libs/glibc-2.21-r1
> > to /  
> 
> This is nothing to do with your problem, but it might be useful
> nonetheless.
> 
> I finally got fed up with these "seconds since the epoch" time stamps a
> couple of days ago, and wrote a little filter to turn them into readable
> time stamps.  Probably there is software around already which does this,
> but the effort to write the script was less than that to search for the
> existing software.

Either genlop or qlop (from portage-utils) will do this and much more.
You probably already have at least one of them installed.


-- 
Neil Bothwick

There is absolutely no substitute for a genuine lack of preparation.


pgpd6zRDHFp0F.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Dale wrote:

Howdy,

I recently did a upgrade which included glibc.  Now both Firefox and 
Seamonkey has problems starting.  I have several profiles and some 
work and some don't.  Using safe-mode works which makes me think the 
browsers themselves are OK but something else got messed up.  The only 
package I see that I just updated is glibc that might could cause this 
issue.  This is the recent emerge list from emerge.log:


 SNIP 

I see a couple python packages but not sure that they would affect 
anything.  Is anyone else having this issue?  Anyone have a clue what 
could cause it?


Right now, I'm testing to see if it is a add-on that is causing it. 
I'm cutting them on one at a time but since sometimes it works and 
sometimes it don't, makes it hard to know if it is even a add-on or 
not much less which one.


I thought about going back to the old version of glibc but we know 
that is not a good idea.  That one is sort of a one way street. If no 
one has any ideas, I may try a emerge -e world and see if that helps any.


Thanks much.

Dale

:-)  :-)




OK.  My emerge -e world finished, with a couple that failed such as 
libreoffice, kscreen and such, but the problem remains.  Since no one 
else is having this problem, based on no one posting about it, then I 
have to assume it is a add-on I use.  Also, safe-mode works too.  Odd 
thing is, when I start it on the command line to see if it reports any 
errors, I get the same output whether it works or not. This is what I 
get either way.




dale@fireball / $ seamonkey -p -new-instance

(process:11385): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed


(process:11385): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed

dale@fireball / $


No clue what that Glib error is about but either way, it works even when 
it spits out that error.  So, now to play with these add-ons and see 
which one is the offender.  One of them is about to be on my bad list.  
So far, adblock works.  Whew!!!


Dale

:-)  :-)

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Neil Bothwick]

On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:

> Of course, there is better ways of finding this info but I never can 
> remember the command and it takes me a bit to figure out what options
> do what so I finally said "screw it" and work without it unless I just
> must have it.  If I only need one, I use the date command.  It
> works.  ;-)

genlop -l --date yesterday

Not too hard to remember :)


-- 
Neil Bothwick

The sooner you fall behind the more time you'll have to catch up.


pgpu7iHDWQ_Xb.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Neil Bothwick wrote:

On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:


Of course, there is better ways of finding this info but I never can
remember the command and it takes me a bit to figure out what options
do what so I finally said "screw it" and work without it unless I just
must have it.  If I only need one, I use the date command.  It
works.  ;-)

genlop -l --date yesterday

Not too hard to remember :)





It is when you only use it once every year or two.  Generally, it is 
rare that I have to even go look at the emerge log file.  This is likely 
the first time I have looked in there in a good long while. Maybe over a 
year.  Sometimes, I wonder if I even need the thing.


Dale

:-)  :-)

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Alan McKinnon wrote:

On 22/10/2015 23:51, Dale wrote:

Neil Bothwick wrote:

On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:


Of course, there is better ways of finding this info but I never can
remember the command and it takes me a bit to figure out what options
do what so I finally said "screw it" and work without it unless I just
must have it.  If I only need one, I use the date command.  It
works.  ;-)

genlop -l --date yesterday

Not too hard to remember :)




It is when you only use it once every year or two.  Generally, it is
rare that I have to even go look at the emerge log file.  This is likely
the first time I have looked in there in a good long while. Maybe over a
year.  Sometimes, I wonder if I even need the thing.

Of course you need it - genlop won't work without it




That's the point.  I rarely use it.  The only genlop command I may use 
every once in a while is genlop -c.  I use that to see how long 
something has been compiling or if it is a major upgrade, what is 
actually being compiled at the time.  Generally, the estimated time 
remaining is worthless.  Most of the time, it isn't even in the ballpark.


So, unless there is a problem with a recent emerge, I don't really have 
a need for it.


Dale

:-)  :-)

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Alan McKinnon]

On 22/10/2015 23:51, Dale wrote:
> Neil Bothwick wrote:
>> On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:
>>
>>> Of course, there is better ways of finding this info but I never can
>>> remember the command and it takes me a bit to figure out what options
>>> do what so I finally said "screw it" and work without it unless I just
>>> must have it.  If I only need one, I use the date command.  It
>>> works.  ;-)
>> genlop -l --date yesterday
>>
>> Not too hard to remember :)
>>
>>
> 
> 
> It is when you only use it once every year or two.  Generally, it is
> rare that I have to even go look at the emerge log file.  This is likely
> the first time I have looked in there in a good long while. Maybe over a
> year.  Sometimes, I wonder if I even need the thing.

Of course you need it - genlop won't work without it


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Dale wrote:
>
>
> OK.  My emerge -e world finished, with a couple that failed such as
> libreoffice, kscreen and such, but the problem remains.  Since no one
> else is having this problem, based on no one posting about it, then I
> have to assume it is a add-on I use.  Also, safe-mode works too.  Odd
> thing is, when I start it on the command line to see if it reports any
> errors, I get the same output whether it works or not. This is what I
> get either way.
>
>
>
> dale@fireball / $ seamonkey -p -new-instance
>
> (process:11385): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
>
> (process:11385): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed
> dale@fireball / $
>
>
> No clue what that Glib error is about but either way, it works even
> when it spits out that error.  So, now to play with these add-ons and
> see which one is the offender.  One of them is about to be on my bad
> list.  So far, adblock works.  Whew!!!
>
> Dale
>
> :-)  :-)
>


Update.  I booted into safe-mode.  I removed ALL add-ons, not disable
but removed them.  I then added them back one at a time until it
wouldn't come up.  It seems Lastpass has a problem.  When I add it back,
it goes belly up with all feet/hands in the air, some swelling starting
too.  Think road kill.  Basically, it's bad.  All the other add-ons seem
to work fine and let Firefox load up fine.  So, I'm off to dig into the
Lastpass world.  Some initial digging is turning up something about
changes to Firefox and how add-ons work, or don't it would seem. 

So, if your Firefox doesn't load up, disable Lastpass first and give it
a test run.  It just may help things.

Don't ask me what my passwords are right now.  o_O  At least Seamonkey
is working. 

Dale

:-)  :-)

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Alan Mackenzie]

Hello, Dale.

On Wed, Oct 21, 2015 at 07:57:32PM -0500, Dale wrote:
> Howdy,

> I recently did a upgrade which included glibc.  Now both Firefox and 
> Seamonkey has problems starting.  I have several profiles and some work 
> and some don't.  Using safe-mode works which makes me think the browsers 
> themselves are OK but something else got messed up.  The only package I 
> see that I just updated is glibc that might could cause this issue.  
> This is the recent emerge list from emerge.log:

> 1445463962:  >>> emerge (1 of 13) sys-libs/glibc-2.21-r1 to /
> 1445464046:  === (1 of 13) Cleaning 
> (sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
> 1445464046:  === (1 of 13) Compiling/Packaging 
> (sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
> 1445464751:  === (1 of 13) Merging 
> (sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
> 1445464759:  >>> AUTOCLEAN: sys-libs/glibc:2.2
> 1445464759:  === Unmerging... (sys-libs/glibc-2.20-r2)
> 1445464761:  >>> unmerge success: sys-libs/glibc-2.20-r2
> 1445464768:  === (1 of 13) Post-Build Cleaning 
> (sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
> 1445464768:  ::: completed emerge (1 of 13) sys-libs/glibc-2.21-r1 to /

This is nothing to do with your problem, but it might be useful
nonetheless.

I finally got fed up with these "seconds since the epoch" time stamps a
couple of days ago, and wrote a little filter to turn them into readable
time stamps.  Probably there is software around already which does this,
but the effort to write the script was less than that to search for the
existing software.

Here is that script:


#!/usr/bin/awk -f
#
# log-emerge:
#
# A filter which converts the time stamp on emerge log files to a human
# readable form.
#
# Written by Alan Mackenzie , 2015-10-20.
# This script is in the public domain.
#
# To use, pipe all or part of a log file through this filter.
#
{
sec = strtonum(substr($1, 1, 11))
$1 = strftime("%Y-%m-%d %H:%M:%S %z", sec, 0) ":"
print
}


Don't forget to make it exectuable!  It turns the first of these log
file lines into this:

2015-10-21 21:46:02 +: >>> emerge (1 of 13) sys-libs/glibc-2.21-r1 to /

If the timezone field is unwanted, just remove the " %z" from the middle
line of the script.

> Thanks much.

> Dale

> :-)  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Dale wrote:

Walter Dnes wrote:

On Wed, Oct 21, 2015 at 07:57:32PM -0500, Dale wrote

Howdy,

I recently did a upgrade which included glibc.  Now both Firefox and
Seamonkey has problems starting.  I have several profiles and some work
and some don't.  Using safe-mode works which makes me think the 
browsers

themselves are OK but something else got messed up.  The only package I
see that I just updated is glibc that might could cause this issue.
This is the recent emerge list from emerge.log:

[...deletia...]


I thought about going back to the old version of glibc but we know that
is not a good idea.  That one is sort of a one way street.  If no one
has any ideas, I may try a emerge -e world and see if that helps any.

   Try revdep-rebuild first.




Thanks Walter.  I haven't ran that in so long I forgot it was even 
there.  Giving that a try.


I still can't make much sense out of the add-on thing.  It's just so 
random.  It dies, then it works, then it dies again.  Weird.


Thanks again.

Dale

:-)  :-)




Well revdep-rebuild came back clean.  I'm doing a emerge -e world at the 
moment.  I'm hoping it is just something out of sync here.


Oh, I also synced the tree again to just in case.  Nothing changed. Of 
course, it had only been one day but still.


Dale

:-)  :-)

[gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Howdy,

I recently did a upgrade which included glibc.  Now both Firefox and 
Seamonkey has problems starting.  I have several profiles and some work 
and some don't.  Using safe-mode works which makes me think the browsers 
themselves are OK but something else got messed up.  The only package I 
see that I just updated is glibc that might could cause this issue.  
This is the recent emerge list from emerge.log:




1445463962:  >>> emerge (1 of 13) sys-libs/glibc-2.21-r1 to /
1445464046:  === (1 of 13) Cleaning 
(sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
1445464046:  === (1 of 13) Compiling/Packaging 
(sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)
1445464751:  === (1 of 13) Merging 
(sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)

1445464759:  >>> AUTOCLEAN: sys-libs/glibc:2.2
1445464759:  === Unmerging... (sys-libs/glibc-2.20-r2)
1445464761:  >>> unmerge success: sys-libs/glibc-2.20-r2
1445464768:  === (1 of 13) Post-Build Cleaning 
(sys-libs/glibc-2.21-r1::/var/cache/portage/tree/sys-libs/glibc/glibc-2.21-r1.ebuild)

1445464768:  ::: completed emerge (1 of 13) sys-libs/glibc-2.21-r1 to /
1445464768:  >>> emerge (2 of 13) 
sci-electronics/electronics-menu-1.0-r1 to /
1445464768:  === (2 of 13) Cleaning 
(sci-electronics/electronics-menu-1.0-r1::/var/cache/portage/tree/sci-electronics/electronics-menu/electronics-menu-1.0-r1.ebuild)

1445464768:  >>> emerge (3 of 13) dev-libs/elfutils-0.163 to /
1445464768:  === (3 of 13) Cleaning 
(dev-libs/elfutils-0.163::/var/cache/portage/tree/dev-libs/elfutils/elfutils-0.163.ebuild)
1445464768:  === (2 of 13) Compiling/Packaging 
(sci-electronics/electronics-menu-1.0-r1::/var/cache/portage/tree/sci-electronics/electronics-menu/electronics-menu-1.0-r1.ebuild)
1445464768:  === (3 of 13) Compiling/Packaging 
(dev-libs/elfutils-0.163::/var/cache/portage/tree/dev-libs/elfutils/elfutils-0.163.ebuild)
1445464771:  === (2 of 13) Merging 
(sci-electronics/electronics-menu-1.0-r1::/var/cache/portage/tree/sci-electronics/electronics-menu/electronics-menu-1.0-r1.ebuild)

1445464774:  >>> AUTOCLEAN: sci-electronics/electronics-menu:0
1445464774:  === Unmerging... (sci-electronics/electronics-menu-1.0)
1445464779:  >>> unmerge success: sci-electronics/electronics-menu-1.0
1445464785:  === (2 of 13) Post-Build Cleaning 
(sci-electronics/electronics-menu-1.0-r1::/var/cache/portage/tree/sci-electronics/electronics-menu/electronics-menu-1.0-r1.ebuild)
1445464785:  ::: completed emerge (2 of 13) 
sci-electronics/electronics-menu-1.0-r1 to /
1445464803:  === (3 of 13) Merging 
(dev-libs/elfutils-0.163::/var/cache/portage/tree/dev-libs/elfutils/elfutils-0.163.ebuild)

1445464806:  >>> AUTOCLEAN: dev-libs/elfutils:0
1445464806:  === Unmerging... (dev-libs/elfutils-0.158)
1445464808:  >>> unmerge success: dev-libs/elfutils-0.158
1445464811:  === (3 of 13) Post-Build Cleaning 
(dev-libs/elfutils-0.163::/var/cache/portage/tree/dev-libs/elfutils/elfutils-0.163.ebuild)

1445464811:  ::: completed emerge (3 of 13) dev-libs/elfutils-0.163 to /
1445464811:  >>> emerge (4 of 13) app-portage/eix-0.31.0 to /
1445464811:  === (4 of 13) Cleaning 
(app-portage/eix-0.31.0::/var/cache/portage/tree/app-portage/eix/eix-0.31.0.ebuild)

1445464811:  >>> emerge (5 of 13) media-libs/libsdl-1.2.15-r9 to /
1445464811:  === (5 of 13) Cleaning 
(media-libs/libsdl-1.2.15-r9::/var/cache/portage/tree/media-libs/libsdl/libsdl-1.2.15-r9.ebuild)
1445464811:  === (4 of 13) Compiling/Packaging 
(app-portage/eix-0.31.0::/var/cache/portage/tree/app-portage/eix/eix-0.31.0.ebuild)
1445464811:  === (5 of 13) Compiling/Packaging 
(media-libs/libsdl-1.2.15-r9::/var/cache/portage/tree/media-libs/libsdl/libsdl-1.2.15-r9.ebuild)
1445464883:  === (4 of 13) Merging 
(app-portage/eix-0.31.0::/var/cache/portage/tree/app-portage/eix/eix-0.31.0.ebuild)

1445464890:  >>> AUTOCLEAN: app-portage/eix:0
1445464890:  === Unmerging... (app-portage/eix-0.30.11)
1445464892:  >>> unmerge success: app-portage/eix-0.30.11
1445464895:  === (4 of 13) Post-Build Cleaning 
(app-portage/eix-0.31.0::/var/cache/portage/tree/app-portage/eix/eix-0.31.0.ebuild)

1445464895:  ::: completed emerge (4 of 13) app-portage/eix-0.31.0 to /
1445464895:  === (5 of 13) Merging 
(media-libs/libsdl-1.2.15-r9::/var/cache/portage/tree/media-libs/libsdl/libsdl-1.2.15-r9.ebuild)

1445464898:  >>> AUTOCLEAN: media-libs/libsdl:0
1445464898:  === Unmerging... (media-libs/libsdl-1.2.15-r8)
1445464900:  >>> unmerge success: media-libs/libsdl-1.2.15-r8
1445464904:  === (5 of 13) Post-Build Cleaning 
(media-libs/libsdl-1.2.15-r9::/var/cache/portage/tree/media-libs/libsdl/libsdl-1.2.15-r9.ebuild)

1445464904:  ::: completed emerge (5 of 13) media-libs/libsdl-1.2.15-r9 to /
1445464904:  >>> emerge (6 of 13) dev-python/sip-4.16.9 to /
1445464904:  === (6 of 13) Cleaning 
(dev-python/sip-4.16.9::/var/cache/portage/tree/dev-python/sip/sip-4.16.9.ebuild)

1445464904:  

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Walter Dnes]

On Wed, Oct 21, 2015 at 07:57:32PM -0500, Dale wrote
> Howdy,
> 
> I recently did a upgrade which included glibc.  Now both Firefox and 
> Seamonkey has problems starting.  I have several profiles and some work 
> and some don't.  Using safe-mode works which makes me think the browsers 
> themselves are OK but something else got messed up.  The only package I 
> see that I just updated is glibc that might could cause this issue.  
> This is the recent emerge list from emerge.log:

[...deletia...]

> I thought about going back to the old version of glibc but we know that 
> is not a good idea.  That one is sort of a one way street.  If no one 
> has any ideas, I may try a emerge -e world and see if that helps any.

  Try revdep-rebuild first.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Dale]

Walter Dnes wrote:

On Wed, Oct 21, 2015 at 07:57:32PM -0500, Dale wrote

Howdy,

I recently did a upgrade which included glibc.  Now both Firefox and
Seamonkey has problems starting.  I have several profiles and some work
and some don't.  Using safe-mode works which makes me think the browsers
themselves are OK but something else got messed up.  The only package I
see that I just updated is glibc that might could cause this issue.
This is the recent emerge list from emerge.log:

[...deletia...]


I thought about going back to the old version of glibc but we know that
is not a good idea.  That one is sort of a one way street.  If no one
has any ideas, I may try a emerge -e world and see if that helps any.

   Try revdep-rebuild first.




Thanks Walter.  I haven't ran that in so long I forgot it was even 
there.  Giving that a try.


I still can't make much sense out of the add-on thing.  It's just so 
random.  It dies, then it works, then it dies again.  Weird.


Thanks again.

Dale

:-)  :-)