When updating across the libcrypt replacement (admittedly this system was a bit out of date), the emerge world fails on gpgme due to a missing header file. The file, crypt.h, is provided by libcrypt, which has been removed earlier in the update and gets reinstated later on. Since gpgme uses libcrypt, needs its headers, and can't be built without it, there is clearly a real an present dependency on it. However, this dependency is missing from the ebuild. I added a dependency locally and it fixed the problem. Reproducible: Always Steps to Reproduce: 1. Start with an older baseline, before libxcrypt 2. Do an "emerge -uaND world" 3. gpgme fails to build
Could you include the build.log?
(In reply to Sam James from comment #1) > Could you include the build.log? I don't see any reference to crypt.h in the source..
(In reply to Sam James from comment #2) > (In reply to Sam James from comment #1) > > Could you include the build.log? > > I don't see any reference to crypt.h in the source.. Thinking about it, you probably have USE=python on, and hit bug 802210. The news item covers how to fix this (upgrade Python first).
(In reply to Sam James from comment #3) > > Thinking about it, you probably have USE=python on, and hit bug 802210. The > news item covers how to fix this (upgrade Python first). Yes, I probably do have USE=python enabled. I hadn't seen any mention of Python in the news item when I read about libcrypt earlier - perhaps that was added after I'd updated other systems? Anyway, if the dependency is actually a complete fake then I suppose user intervention is the only option (generally I'd consider "you need to know this and have read that and understood the other" to be not an acceptable response to a relatively common emerge failure)
Thank you for the report. We need to have all information at hand before ticket assignment. Please provide * the complete build.log as attachment and * paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket Please reopen this ticket (Status:UNCONFIRMED) afterwards.
(In reply to Robert Pearce from comment #4) > (In reply to Sam James from comment #3) > > > > Thinking about it, you probably have USE=python on, and hit bug 802210. The > > news item covers how to fix this (upgrade Python first). > > Yes, I probably do have USE=python enabled. I hadn't seen any mention of > Python in the news item when I read about libcrypt earlier - perhaps that > was added after I'd updated other systems? Anyway, if the dependency is > actually a complete fake then I suppose user intervention is the only option > (generally I'd consider "you need to know this and have read that and > understood the other" to be not an acceptable response to a relatively > common emerge failure) I'm sorry you don't consider it to be acceptable. I've spent a lot of time trying to make the news item as clear as possible and changed it based on user feedback. If you have any concrete changes you would like me to make, please suggest them. This was a change which was completely unavoidable and we spent a huge amount of time planning and testing for. The issue in this bug is that there was a problem within Python (unnecessary include and linkage in libpython) that _sometimes_ causes build failures. The news item explicitly mentions that spurious build failures can be fixed by following listed commands...
(In reply to Sam James from comment #6) > > I'm sorry you don't consider it to be acceptable. I've spent a lot of time > trying to make the news item as clear as possible and changed it based on > user feedback. Well, "not acceptable" is possibly a bit strong. In general, I would consider "you need to follow these instructions" more of a last fall-back option, but from what you've said it does sound like the only realistic one given the cause. Your instructions in the news item are fine, it's just that when I first hit this problem (on a different and even more out-of-date machine) the news item didn't mention any possible problems, and when updating this latest box I'd skim-read and not noticed the additions. I do wonder whether some sort of news item hierarchy would be beneficial? The list I got this time contained two "this package (that you're not using) is disappearing and won't trouble anyone" type items, one "we're moving from RedHat's to Debian's interpretation of something minor" item, and two "big changes that might cause problems that you need to fix manually". They all get presented the same way in a long on-demand list. It seems to me there should be more focus on gotchas - perhaps a warning issued if an emerge is started when a known problem situation can be detected (so in this case, scheduling an update across the libxcrypt change when USE=python is found would prompt the user to read your news item first). But that's getting off-topic for a bug report!