Simon Stelling posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 03 Jan 2006 20:14:38 +0100:
> This is just a quick reminder: The 2004.3 profile (and all the subprofiles > of course) will be removed on February 1, 2006. If you're still running > 2004.3, this is your last chance to upgrade. > > Information on how to upgrade can be found here: > > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=1 Interesting followup, here: Some of you may recall that I had posted a question a few weeks ago about possibly switching to the 64-bit-only sub-profiles, and was wondering about grub. The reason I was considering it was that 32-bit compiles, sandbox updates and the like, weren't working properly, and I was thinking that simply switching to 64-bit-only, since I don't use 32-bit but for grub and the multilib toolchain stuff (sandbox, gcc, glibc...), would be easier than tracing the problem and fixing it. Turns out the problem was pretty simple. I've mentioned before that I had problems with an overheating hard drive this past summer, when my AC was out, and ended up recovering from an old system image. As it happens, that old image was 2004.x profile, when /emul/linux/x86 was used for a bunch of stuff, and after the recovery, I had duplicates of various libraries, including an old emul-linux-x86-glibc and friends. I had weeded out lib64 some time ago, but hadn't worried about lib32 as I don't really use it anyway. It's those duplicate 32-bit libs that were causing my problems. After verifying that no existing packages used the old /emul dir (using equery b), and (recursively) deleting it, the problems disappeared! I now have a working 32-bit sandbox and etc, once again! I figure someone else might find the info useful, during/after this upgrade. If you find 32-bit stuff isn't working, see if you have stale 32-bit versions of glibc and friends in /emul/*. equery b, particularly with the -f (full regexp) switch, can be very helpful in seeing just what current packages /do/ use a directory, so one can remove (or rename if you are cautious, for later removal if nothing breaks) the remaining files, which are likely to be stale and causing breakage. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
