Duncan posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 23 Apr 2005 08:57:31 -0700:
> At least... 20-r1 really borked me over, here, and I had to use the > emergency portage recovery procedure with a copy of the previous binary > package as above, to get a working portage again. > > http://bugs.gentoo.org/show_bug.cgi?id=90135 > > Note that ppc/osx opened a bug on it just before mine, 90133, tho with a > bit different errors, as well, so it doesn't look to be amd64 only, but > perhaps many of the non-x86_32 archs, having issues. I found one of the problems. The now separate sandbox package isn't building the 32-bit libsandbox.so that it should be building, only the 64-bit version. So, the 32-bit lib is the old portage-2.0.51.19 (sandbox 1.1) version, while the 64-bit lib is the new separate sandbox-1.2 version, and portage is understandably /very/ confused! =8^P According to the bug, jstubbs keyword masked the new portage on all but x86 until things are worked out. Hopefully, with this new info, a sandbox package building both libs will quickly be made available, and /then/ we'll see what issues remain. Meanwhile, anyone running the 64-bit only sub-profile shouldn't have /that/ issue, but I'd still ensure I had a binpkg of my current portage available, before I tried merging the new one, because there's enough new in this version to potentially break things, as I've already found out, and having a known working binpkg ready to extract over the bad one if things break, /sure/ makes recovery easier. -- 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
