Summary: | sys-apps/portage-2.1.2.7 - features="keepwork" leads to wrong compile error message | ||
---|---|---|---|
Product: | Portage Development | Reporter: | DocReedSolomon <sprockhoevel> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | Keywords: | InVCS |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 181949 |
Description
DocReedSolomon
2007-05-09 10:16:38 UTC
You didn't say in which phase the sandbox problem appeared (compile? install? test?). At a guess that phase was marked as completed incorrectly, so the code that triggered the sandbox problem was skipped on the attempted rebuild and also leads to the file-not-found error later on. to me it happen on install, the actual rrdtool bugreport is found here: http://bugs.gentoo.org/show_bug.cgi?id=177256 hmm, i will keep an eye on this one with the next ebuild that fails to compile. "unfortunately" <g> i have no other ebuild that fails to test with yet ;) (In reply to comment #0) > so far so good. now, if you have FEATURES="keepwork" in yours make.conf: When you use FEATURES="keepwork", and fallout is your responsibility. > as you can see, the error output of the failed compile process is completly > misleading. not a word about the real problem (sandbox violation) anymore. Like I said, it's your responsibility if you have FEATURES="keepwork" enabled. You saw the access violation once and it's your responsibility to connect the dots. Portage has no way of knowing that the two events are related. It's more complex than that. > i think this is a bug? This bug looks invalid to me. FEATURES="keepwork" is intended for ebuild development. It's not a general-use feature and users shouldn't use it unless they're prepared to do some debugging. I think we need to split the features listed the make.conf manpage into sections so that it's clear which ones are acceptable for general use and which ones aren't. well, maybe keepwork could just be documented a little better, thats all thats needed i guess. currently the manpage doesnt even mention it resumes the compile process. In svn r6512 I've updated the keepwork docs as follows: .B keepwork Do not delete the ${WORKDIR} directory after the merge process. This also disables most of the clean phase that is run prior to each build. This causes it to interfere with normal emerge operation and therefore it should not be left enabled for more than a short period of time. "Do not delete the ${WORKDIR} directory after the merge process and resume aborted compile operation" or something like that would make it clear what this option is supposed to be for, IMHO. In svn r6519 I've updated it clarify about how ${WORKDIR} can be reused: .B keepwork Do not delete the ${WORKDIR} directory after the merge process. ${WORKDIR} can then be reused since this feature disables most of the clean phase that runs prior to each build. Due to lack of proper cleanup, this feature can interfere with normal emerge operation and therefore it should not be left enabled for more than a short period of time. sounds perfect to me, thx a bunch! and, of course, keep up your good work! This has been released in 2.1.2.8. |