| Summary: | QA shebang complaints on Cygwin or "//home/..." is an invalid path | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Al <oss.elmar> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Other | ||
| URL: | http://portage.prefix.freens.org/prefix/rev/49d9ba612812 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Ok, I see, ${ROOT%/} is probably the right thing to use here. Same for ${D}, should be ${D%/}. (We know that ${line[0]} starts with a forward slash here due to the test before.)
committed the fix, can't release at the moment due to the very broken state of prefix portage in git. released in portage-2.2.01.16270 |
While bootstrapping on Cygwin emerge dies due to QA concerns in from portage/bin/misc-function.sh Reproducible: Always Steps to Reproduce: Bootstrap on Cygwin. Run emerge something. Actual Results: "*** has explicit EPREFIX in shebang but target not found ***" "QA Notice: the following files use invalid (possible non-prefixed) shebangs:" "Aborting due to QA concerns: invalid shebangs found" For Cygwin a path that starts with a double slash differs from one that starts with a single slash. "//home/user/gentoo/bin/bash" is not found. Reason is line 645 of the Prefix patched misc-functions.sh: ------------------------------------------------------------------- # does the shebang start with ${EPREFIX}, and does it exist? if [[ ${line[0]} == ${EPREFIX}/* ]] ; then if [[ ! -e ${ROOT}${line[0]} && ! -e ${D}${line[0]} ]] ; then # hmm, refers explicitly to $EPREFIX, but doesn't exist, # if it's in PATH that's wrong in any case ------------------------------------------------------------------- where ${ROOT} is "/" and ${line[0]} "/home/user/gentoo/bin/bash". Workaround: Strip ${ROOT} from that line temporarly. Remark: It has been reported that the blocker for bootstrapping on Cygwin is the .exe postfix on executables. I can't confirm that. This is rather one of the problems if tools can't be addressed.