Duncan posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 23 Apr 2005 13:09:38 -0700:
> 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 >> > 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 The bug is closed. the .51.20-r3 version of portage, with sandbox 1.2.1-r2, works just fine, here. ~amd64 users should have no problems with it. (For anyone using /etc/portage/profile/package.provided, note that the new version of portage, according to the portage manpage, expects versions on all package strings therein. I didn't have versions on some of mine and the new portage was protesting. If you don't want to be bothered with newer versions, try putting in a real high version number. For instance, I install kernels from kernel.org, so don't use portage for that, and therefore put sys-kernel/gentoo-sources-2.6.999 in my package.provided. That should keep it from asking for awhile, even if some package thinks it needs gentoo-sources-2.6.37 or some such thing. <g>) -- 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
