Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
Alan McKinnon skrev: On Saturday 14 November 2009 01:13:06 Neil Bothwick wrote: However, it did get to the point where it was complaining about two packages and the number of files to be rebuilt went (IIRC) 52, 50, 50, so I decide since it was rebuilding 50 packages the 2nd 3rd times it wasn't going to improve. Might not be true though. seems related to https://bugs.gentoo.org/show_bug.cgi?id=292622
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, 13 Nov 2009 17:06:02 -0800, Mark Knecht wrote: I think it is being over-cautious, which results in packages being rebuilt multiple time unnecessarily, but I's rather give it the chance to fix itself. That said, I've never had a list anything like 50 packages long, but I do update frequently. It wasn't that I had 50 packages in the emerge -DuN @world. That was something like 10. It was after that finished and I ran @preserved-rebuild that it said 50 packages were effected by something it found, but those 50 were all dependent on just one or two packages that Alan was suggesting to me are held in the preserved database file, or so I think. I realised it was 50-odd in the rebuild list, but in my experience multiple runs gradually reduces that number. Maybe portage could be more intelligent about the order in which it re-emerges these packages, but running it enough times always works for me. Removing the registry is potentially risky because you could still have packages linked to a library that is not managed by portage, and that will never update. If someone finds a security hole in that library, you could be in trouble. Fixing the problem by deleting the registry is akin to fixing low oil pressure in your car by disconnecting the warning light. -- Neil Bothwick We are THOR of Borg... your RFC compliant mailbox has been assimilated signature.asc Description: PGP signature
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Saturday 14 November 2009 01:13:06 Neil Bothwick wrote: However, it did get to the point where it was complaining about two packages and the number of files to be rebuilt went (IIRC) 52, 50, 50, so I decide since it was rebuilding 50 packages the 2nd 3rd times it wasn't going to improve. Might not be true though. I think it is being over-cautious, which results in packages being rebuilt multiple time unnecessarily, but I's rather give it the chance to fix itself. That said, I've never had a list anything like 50 packages long, but I do update frequently. The only relevant facts I have ever seen myself are that ldd was telling me a lib was required and portage had already told me via depclean that it wasn't... It's totally possible that what the OP is running into is something I've never had to track down -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Saturday 14 November 2009 03:06:02 Mark Knecht wrote: It wasn't that I had 50 packages in the emerge -DuN @world. That was something like 10. It was after that finished and I ran @preserved-rebuild that it said 50 packages were effected by something it found, but those 50 were all dependent on just one or two packages that Alan was suggesting to me are held in the preserved database file, or so I think. Yes, that's pretty much the scenario I was describing. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. Won't that leave orphaned libraries hanging around since they aren't removed until emerges complete successfully? I've seen this behaviour before, where the list gets shorter each time and let it run its course. It may take longer, but you know it's safe. -- Neil Bothwick It compiled? The first screen came up? Ship it! -- Bill Gates signature.asc Description: PGP signature
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Friday 13 November 2009 14:39:52 Neil Bothwick wrote: On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. Won't that leave orphaned libraries hanging around since they aren't removed until emerges complete successfully? I've seen this behaviour before, where the list gets shorter each time and let it run its course. It may take longer, but you know it's safe. Interesting point. My tests before indicated that a full --depclean sorted everything out, but I can't be certain. @preserved-rebuild deletes orphans once it's complete, but it would be nice to verify what happens otherwise. Unfortunately, it's been a long time since any of my machines got stuck in this loop. I must have earned some good joss in recent months... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Friday 13 November 2009 14:39:52 Neil Bothwick wrote: On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. Won't that leave orphaned libraries hanging around since they aren't removed until emerges complete successfully? I've seen this behaviour before, where the list gets shorter each time and let it run its course. It may take longer, but you know it's safe. Interesting point. My tests before indicated that a full --depclean sorted everything out, but I can't be certain. @preserved-rebuild deletes orphans once it's complete, but it would be nice to verify what happens otherwise. Unfortunately, it's been a long time since any of my machines got stuck in this loop. I must have earned some good joss in recent months... -- alan dot mckinnon at gmail dot com If this problem is fundamentally due to dependencies not in DEPEND then is there any evidence that it's big a problem? I.e. - there aren't many packages that create the loop from what I've seen so far. I've had this issue show up on all the machines I've updated this week, but it was always (I think) the same packages that caused the problems. As Neil suggested, at least on one machine the number of offending packages did seem to go down, but it would never go to zero as far as I can tell. (I did it 3 times on one box just to convince myself but emerging 50 packages gets boring.) While I haven't bug reported it I suspect someone will jump on this and a few days or weeks from now it won't exist, at least for these packages. Other than disk space what's the technical downside of some libraries being stranded. Will this somehow leave applications pointing at old library binaries? - Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Friday 13 November 2009 21:46:04 Mark Knecht wrote: On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Friday 13 November 2009 14:39:52 Neil Bothwick wrote: On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. Won't that leave orphaned libraries hanging around since they aren't removed until emerges complete successfully? I've seen this behaviour before, where the list gets shorter each time and let it run its course. It may take longer, but you know it's safe. Interesting point. My tests before indicated that a full --depclean sorted everything out, but I can't be certain. @preserved-rebuild deletes orphans once it's complete, but it would be nice to verify what happens otherwise. Unfortunately, it's been a long time since any of my machines got stuck in this loop. I must have earned some good joss in recent months... -- alan dot mckinnon at gmail dot com If this problem is fundamentally due to dependencies not in DEPEND then is there any evidence that it's big a problem? I.e. - there aren't many packages that create the loop from what I've seen so far. I've had this issue show up on all the machines I've updated this week, but it was always (I think) the same packages that caused the problems. As Neil suggested, at least on one machine the number of offending packages did seem to go down, but it would never go to zero as far as I can tell. (I did it 3 times on one box just to convince myself but emerging 50 packages gets boring.) While I haven't bug reported it I suspect someone will jump on this and a few days or weeks from now it won't exist, at least for these packages. Other than disk space what's the technical downside of some libraries being stranded. Will this somehow leave applications pointing at old library binaries? The basic problem is that portage's idea of the state of the machine differs from reality. For a package manager, that's not a good thing as sooner or later it will do the wrong thing. Detecting orphans is also an expensive process later so it's best to avoid it happening if possible -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, Nov 13, 2009 at 12:57 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Friday 13 November 2009 21:46:04 Mark Knecht wrote: On Fri, Nov 13, 2009 at 10:42 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Friday 13 November 2009 14:39:52 Neil Bothwick wrote: On Thu, 12 Nov 2009 16:58:15 +0200, Alan McKinnon wrote: Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. Won't that leave orphaned libraries hanging around since they aren't removed until emerges complete successfully? I've seen this behaviour before, where the list gets shorter each time and let it run its course. It may take longer, but you know it's safe. Interesting point. My tests before indicated that a full --depclean sorted everything out, but I can't be certain. @preserved-rebuild deletes orphans once it's complete, but it would be nice to verify what happens otherwise. Unfortunately, it's been a long time since any of my machines got stuck in this loop. I must have earned some good joss in recent months... -- alan dot mckinnon at gmail dot com If this problem is fundamentally due to dependencies not in DEPEND then is there any evidence that it's big a problem? I.e. - there aren't many packages that create the loop from what I've seen so far. I've had this issue show up on all the machines I've updated this week, but it was always (I think) the same packages that caused the problems. As Neil suggested, at least on one machine the number of offending packages did seem to go down, but it would never go to zero as far as I can tell. (I did it 3 times on one box just to convince myself but emerging 50 packages gets boring.) While I haven't bug reported it I suspect someone will jump on this and a few days or weeks from now it won't exist, at least for these packages. Other than disk space what's the technical downside of some libraries being stranded. Will this somehow leave applications pointing at old library binaries? The basic problem is that portage's idea of the state of the machine differs from reality. For a package manager, that's not a good thing as sooner or later it will do the wrong thing. Detecting orphans is also an expensive process later so it's best to avoid it happening if possible -- alan dot mckinnon at gmail dot com I agree that we want to be in agreement but then what are our options if emerge @preserved-rebuild goes into an endless loop as it seems it was doing yesterday? Do we just stop looping, wait until someone may one day fix the ebuild, and then try again never knowing when things will be correct again? I had a problem show up last evening after I thought everything was done. I went back for one last revdep-rebuild and then it decided to tell me that there were wine libraries on the machine unowned by any installed package. Now this machine hasn't had Wine on it in over a year so I cannot understand why it would start telling me that today but it did. It seems to me that expensive or not it would be great to have a tool that completely checked every single library on the machine if that's what it takes. I thought revdep-rebuild was doing that but now I'm not so sure. Cheers, Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, 13 Nov 2009 14:19:26 -0800, Mark Knecht wrote: I agree that we want to be in agreement but then what are our options if emerge @preserved-rebuild goes into an endless loop as it seems it was doing yesterday? Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild count decreased. In my experience, it can occasionally take a few runs to clear the list, sometimes subsequent runs add packages that were not there previously, but it all clears in the end, I have NEVER had to resort to deleting the registry file manually. -- Neil Bothwick I'm not being rude. You're just insignificant. signature.asc Description: PGP signature
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, Nov 13, 2009 at 2:38 PM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 13 Nov 2009 14:19:26 -0800, Mark Knecht wrote: I agree that we want to be in agreement but then what are our options if emerge @preserved-rebuild goes into an endless loop as it seems it was doing yesterday? Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild count decreased. In my experience, it can occasionally take a few runs to clear the list, sometimes subsequent runs add packages that were not there previously, but it all clears in the end, I have NEVER had to resort to deleting the registry file manually. -- Neil Bothwick If I don't run it forever then I don't think I can say it would never clear up. Can't prove a negative, etc. However, it did get to the point where it was complaining about two packages and the number of files to be rebuilt went (IIRC) 52, 50, 50, so I decide since it was rebuilding 50 packages the 2nd 3rd times it wasn't going to improve. Might not be true though. - Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote: Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild count decreased. In my experience, it can occasionally take a few runs to clear the list, sometimes subsequent runs add packages that were not there previously, but it all clears in the end, I have NEVER had to resort to deleting the registry file manually. If I don't run it forever then I don't think I can say it would never clear up. Can't prove a negative, etc. When you get identical package lists on subsequent runs, I think it's fair to say it won't fix itself. This has never happened to me. However, it did get to the point where it was complaining about two packages and the number of files to be rebuilt went (IIRC) 52, 50, 50, so I decide since it was rebuilding 50 packages the 2nd 3rd times it wasn't going to improve. Might not be true though. I think it is being over-cautious, which results in packages being rebuilt multiple time unnecessarily, but I's rather give it the chance to fix itself. That said, I've never had a list anything like 50 packages long, but I do update frequently. -- Neil Bothwick Why are love and relationships so confusing? signature.asc Description: PGP signature
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
Neil Bothwick wrote: On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote: Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild count decreased. In my experience, it can occasionally take a few runs to clear the list, sometimes subsequent runs add packages that were not there previously, but it all clears in the end, I have NEVER had to resort to deleting the registry file manually. If I don't run it forever then I don't think I can say it would never clear up. Can't prove a negative, etc. When you get identical package lists on subsequent runs, I think it's fair to say it won't fix itself. This has never happened to me. I had this happen to me the other day. I ran preserved-rebuild 3 or 4 times with the last two or three being the same. I can't recall if I posted it here or not, I think I did tho, but I did eventually get it sorted by emerging packages in a certain order. After that, it came back clean with nothing needing to be rebuilt. I update about twice a week as a general rule. Sort of depends. Dale :-) :-)
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Fri, Nov 13, 2009 at 3:13 PM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 13 Nov 2009 15:00:33 -0800, Mark Knecht wrote: Was it an endless loop? AIUI you emerged twice and the @preserved-rebuild count decreased. In my experience, it can occasionally take a few runs to clear the list, sometimes subsequent runs add packages that were not there previously, but it all clears in the end, I have NEVER had to resort to deleting the registry file manually. If I don't run it forever then I don't think I can say it would never clear up. Can't prove a negative, etc. When you get identical package lists on subsequent runs, I think it's fair to say it won't fix itself. This has never happened to me. However, it did get to the point where it was complaining about two packages and the number of files to be rebuilt went (IIRC) 52, 50, 50, so I decide since it was rebuilding 50 packages the 2nd 3rd times it wasn't going to improve. Might not be true though. I think it is being over-cautious, which results in packages being rebuilt multiple time unnecessarily, but I's rather give it the chance to fix itself. That said, I've never had a list anything like 50 packages long, but I do update frequently. It wasn't that I had 50 packages in the emerge -DuN @world. That was something like 10. It was after that finished and I ran @preserved-rebuild that it said 50 packages were effected by something it found, but those 50 were all dependent on just one or two packages that Alan was suggesting to me are held in the preserved database file, or so I think. Again, you know me...basically a flunky just trying to use my tool box to play music even if I don't know how the tool box works... - Mark
[gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
So on one machine yesterday I did emerge -DuN @world which then suggested the need for emerge @preserved-rebuild which I did over night. This morning it was finished but suggested the need for a second emerge @preserved-rebuild. As I don't need the machine right now I kicked it off and will check it again later but I'm wondering why in the world it needs to do this twice, compiling 52 packages the first time and 50 packages the second time where most of the packages in the first list were in the second list? Is this setting up for an endless loop? Most of the packages were part of Gnome or XFCE4. Cheers, Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thursday 12 November 2009 16:43:15 Mark Knecht wrote: So on one machine yesterday I did emerge -DuN @world which then suggested the need for emerge @preserved-rebuild which I did over night. This morning it was finished but suggested the need for a second emerge @preserved-rebuild. As I don't need the machine right now I kicked it off and will check it again later but I'm wondering why in the world it needs to do this twice, compiling 52 packages the first time and 50 packages the second time where most of the packages in the first list were in the second list? Is this setting up for an endless loop? Most of the packages were part of Gnome or XFCE4. I've been answering this question a lot lately :-) Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. A later revdep-rebuild will sort out any (highly unlikely) remaining issues -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thu, Nov 12, 2009 at 6:58 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Thursday 12 November 2009 16:43:15 Mark Knecht wrote: So on one machine yesterday I did emerge -DuN @world which then suggested the need for emerge @preserved-rebuild which I did over night. This morning it was finished but suggested the need for a second emerge @preserved-rebuild. As I don't need the machine right now I kicked it off and will check it again later but I'm wondering why in the world it needs to do this twice, compiling 52 packages the first time and 50 packages the second time where most of the packages in the first list were in the second list? Is this setting up for an endless loop? Most of the packages were part of Gnome or XFCE4. I've been answering this question a lot lately :-) Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. A later revdep-rebuild will sort out any (highly unlikely) remaining issues -- alan dot mckinnon at gmail dot com Thanks Alan. I always tend to do a revdep-rebuild -i anyway. Not sure if it's required but old habits die hard. Cheers, Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thu, Nov 12, 2009 at 7:14 AM, Mark Knecht markkne...@gmail.com wrote: On Thu, Nov 12, 2009 at 6:58 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Thursday 12 November 2009 16:43:15 Mark Knecht wrote: So on one machine yesterday I did emerge -DuN @world which then suggested the need for emerge @preserved-rebuild which I did over night. This morning it was finished but suggested the need for a second emerge @preserved-rebuild. As I don't need the machine right now I kicked it off and will check it again later but I'm wondering why in the world it needs to do this twice, compiling 52 packages the first time and 50 packages the second time where most of the packages in the first list were in the second list? Is this setting up for an endless loop? Most of the packages were part of Gnome or XFCE4. I've been answering this question a lot lately :-) Almost invariably it's an automagic dependency where the offending package is not in DEPEND. If you have been through the cycle at least once, it is safe to delete /var/lib/portage/preserved_libs_registry and continue on your way. A later revdep-rebuild will sort out any (highly unlikely) remaining issues -- alan dot mckinnon at gmail dot com Thanks Alan. I always tend to do a revdep-rebuild -i anyway. Not sure if it's required but old habits die hard. Cheers, Mark Again, thanks Alan. The second pass through finished up and the same offending package (apparently e2fsprogs-libs ?) was still listed so erasing the preserved_libs_registry file and using revdep-rebuild -i suggests that the machine is clean again. Cheers, Mark Auto-cleaning packages... No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 122 info files. !!! existing preserved libs: package: sys-libs/e2fsprogs-libs-1.41.9 * - /lib/libblkid.so * used by /bin/mount (sys-apps/util-linux-2.16.1) * used by /bin/umount (sys-apps/util-linux-2.16.1) * used by /sbin/blkid (sys-apps/util-linux-2.16.1) * used by 10 other files * - /lib/libuuid.so * used by /bin/mount (sys-apps/util-linux-2.16.1) * used by /bin/umount (sys-apps/util-linux-2.16.1) * used by /sbin/blkid (sys-apps/util-linux-2.16.1) * used by 362 other files Use emerge @preserved-rebuild to rebuild packages using these libraries gandalf ~ # rm /var/lib/portage/preserved_libs_registry gandalf ~ # revdep-rebuild -ip * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done. gandalf ~ # equery belongs /lib/libblkid.so [ Searching for file(s) /lib/libblkid.so in *... ] sys-libs/e2fsprogs-libs-1.41.9 (/lib/libblkid.so - libblkid.so.1) gandalf ~ # equery belongs /lib/libuuid.so [ Searching for file(s) /lib/libuuid.so in *... ] sys-libs/e2fsprogs-libs-1.41.9 (/lib/libuuid.so - libuuid.so.1) gandalf ~ #
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thu, Nov 12, 2009 at 8:28 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Thursday 12 November 2009 18:19:02 Mark Knecht wrote: Again, thanks Alan. The second pass through finished up and the same offending package (apparently e2fsprogs-libs ?) was still listed so erasing the preserved_libs_registry file and using revdep-rebuild -i suggests that the machine is clean again. Cheers, Mark Auto-cleaning packages... No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 122 info files. !!! existing preserved libs: package: sys-libs/e2fsprogs-libs-1.41.9 * - /lib/libblkid.so * used by /bin/mount (sys-apps/util-linux-2.16.1) * used by /bin/umount (sys-apps/util-linux-2.16.1) * used by /sbin/blkid (sys-apps/util-linux-2.16.1) An easy way to check if things are OK is to run ldd on each of the used by files. None of them should list Not found. If they do, portage has gotten itself confused and it's records are out of sync with reality. There's not much portage can do about this as the problem is really with the ebuilds -- alan dot mckinnon at gmail dot com Thanks. I'll star this conversation and try to remember that advice in the future. Problem was the first time around it listed 3 or 4 and then stated and 362 others... but didn't give the names. Clearly something was confused! Cheers, Mark
Re: [gentoo-user] emerge @ world - @preserved-rebuild - @preserved-rebuild - what next?
On Thursday 12 November 2009 18:19:02 Mark Knecht wrote: Again, thanks Alan. The second pass through finished up and the same offending package (apparently e2fsprogs-libs ?) was still listed so erasing the preserved_libs_registry file and using revdep-rebuild -i suggests that the machine is clean again. Cheers, Mark Auto-cleaning packages... No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 122 info files. !!! existing preserved libs: package: sys-libs/e2fsprogs-libs-1.41.9 * - /lib/libblkid.so * used by /bin/mount (sys-apps/util-linux-2.16.1) * used by /bin/umount (sys-apps/util-linux-2.16.1) * used by /sbin/blkid (sys-apps/util-linux-2.16.1) An easy way to check if things are OK is to run ldd on each of the used by files. None of them should list Not found. If they do, portage has gotten itself confused and it's records are out of sync with reality. There's not much portage can do about this as the problem is really with the ebuilds -- alan dot mckinnon at gmail dot com
