I did revdep-rebuild and things went fine. When I did --depclean, It
removed many necessary packages. And I can not even complete
running "emerge system", it fails on one of the packages due to missing alocal !

I can not even run mutt, as lynx is not there and can not install it as well.

I run this type of things before going to bed, as it takes time. I
should change this habit, and spend time on it when I am not tired. :)
I will look into this tonight, or maybe on the weekend. I may have to
spend many hours to fix this.

Normally I run "emerge --update --deep --newuse world" every two
weeks, but I haven't done this for more than 2 months. I don't this
should be an issue.


On Tue, Oct 13, 2009 at 11:39 AM, Duncan <1i5t5.duncan@...> wrote:
> Mansour Al Akeel posted on Tue, 13 Oct 2009 10:25:15 -0300 as excerpted:
>
>> I lost the output from the previos build, and unable to regenerate the
>> issue after fooliwnf libxcb update guilde. But now I am stuck with
>> another error, when bulllding gcc.
>>
>>
>> /var/tmp/portage/sys-devel/gcc-4.1.2/
>
> gcc-4.1.2 ?  gcc 4.1 is a bit outdated.  You /may/ be able to simply
> unmerge it.  What versions of gcc do you have installed, anyway?  It's
> likely you have a 4.3 version, as gcc-4.3.2-r3 is the latest keyworded
> stable for amd64.
>
> A caution, however.  Until your whole system is rebuilt with the newer
> gccs, some C++ packages in particular may still link to the old
> versions.  But it should at least be possible to ignore the old gccs for
> the moment (emerge --resume --skipfirst if necessary) and build
> everything else.  If you're using FEATURES=buildpkg, it's easy enough to
> unmerge a package, see if anything breaks (run revdep-rebuild and see if
> there's anything that needs rebuilt, and hope it rebuilds fine), and
> remerge the binpkg if necessary.  That's what I'd do.
>
> If you're not running FEATURES=buildpkg, I'd suggest you consider it.
> Right before a system-wide rebuild is a great time to turn it on. =:^)
> But if you're not, you can use quickpkg to create a binpkg of a
> particular package before removing it for testing.  That way you still
> get the binpkg, and can remerge it if necessary, if you find you still
> need it.
>
> Anyway... after updating gcc to 4.3.2-r3 if you don't have it, and gcc-
> config-ing to it, you could emerge --emptytree @system @world so
> everything is built with it, and then unmerge older gcc versions,
> including the 4.1.2 that's giving you issues ATM.
>
> FWIW, on ~amd64, the only gcc I have currently installed is 4.4.1, as I
> unmerged earlier versions after I had rebuilt the entire system with it.
> I do remember having some issues rebuilding earlier gccs at one point,
> but with the entire system (other than those gccs) building with 4.4.1, I
> was able to unmerge them instead of rebuild them.
>
> Of course, I always do --update --deep --newuse, generally a couple times
> a week, and revdep-rebuild and --depclean afterward, to make sure the
> system stays consistent and keep the cruft to a minimum.  If you've let
> it build up by not regularly using --update --deep and not regularly
> doing --depcleans and revdep-rebuilds, you are likely to have quite some
> problems getting the system back in shape, as there will be quite some
> cruft buildup to clean out, and doing it incrementally as the updates
> show up is MUCH easier than letting it buildup and trying to do it all at
> once.
>
> --
> 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
>
>
>