Some scripts munge/detect shebang paths. If /usr is detected, a build fails and the bootstrap process can not continue. If prefix can not support /usr/* then an error should be thrown earlier in the bootstrap process. Reproducible: Always Steps to Reproduce: 1. Follow the bootstrap guide and use EPREFIX=/usr/prefix 2. Wait for gzip-1.4 to break the bootstrap Actual Results: * QA Notice: the following files use invalid (possible non-prefixed) shebangs: * usr/prefix/bin/gunzip:/prefix/bin/bash * ERROR: app-arch/gzip-1.4 failed: * Aborting due to QA concerns: invalid shebangs found * * Call stack: * misc-functions.sh, line 1432: Called install_qa_check * misc-functions.sh, line 94: Called install_qa_check_prefix * misc-functions.sh, line 649: Called die * The specific snippet of code: * die "Aborting due to QA concerns: invalid shebangs found" Expected Results: success or a failure much earlier Portage 2.2.00.15444-prefix (prefix/darwin/macos/10.5/x64, gcc-4.2.1, unavailable, 9.8.0 i386) ================================================================= System Settings ================================================================= System uname: Darwin-9.8.0-i386-64bit Timestamp of tree: Tue, 02 Mar 2010 03:07:18 +0000 distcc 2.18.5-Apple.1 i386-apple-darwin9.0 (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 4.0_p35 dev-lang/python: 2.6.4 sys-devel/autoconf: 2.63-r01.1 sys-devel/automake: 1.10.2-r00.1, 1.11.1 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.2.6b ACCEPT_KEYWORDS="~x64-macos" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-apple-darwin9" CFLAGS="-march=nocona" CHOST="x86_64-apple-darwin9" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="" DISTDIR="/usr/prefix/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages news nostrip parallel-fetch preserve-libs protect-owned sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="" LDFLAGS="" PKGDIR="/usr/prefix/usr/portage/packages" PORTAGE_CONFIGROOT="/usr/prefix/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/usr/prefix/var/tmp" PORTDIR="/usr/prefix/usr/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="aqua coreaudio cracklib cxx mmx mmxext modules ncurses objc objc++ prefix readline sse sse2 ssl x64-macos zlib" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="Darwin" INPUT_DEVICES="keyboard mouse" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I asked Tim to file this bug, seems like the we should set a policy that /usr cannot be the start of your EPREFIX (and how to properly document it?) or this should be fixed.
questions here are along the lines of why. - does the script indeed have #!/prefix/... - if not, does the shebang check in portage do something wrong
(In reply to comment #2) > questions here are along the lines of why. > > - does the script indeed have #!/prefix/... > - if not, does the shebang check in portage do something wrong > If your EPREFIX is "/usr/foo" then the shebang would be /usr/foo/bin/bash. I speculate (I haven't stepped through the code yet) that the shebang check in portage matches on "^/usr" which is why we either need: 1) a fixed shebang check 2) a statement that says your EPREFIX cannot be "^/usr/..." I won't exactly agree that #2 is a good thing, but we have a precedence for it in bug 300138 =/
The shebang check doesn't do anything like ^/usr. # does the shebang start with ${EPREFIX}? [[ ${line[0]} == ${EPREFIX}* ]] && continue # can we just fix it(tm)? if [[ -e ${EPREFIX}${line[0]} || -e ${ED}${line[0]} ]] ; then eqawarn "prefixing shebang of ${fn#${D}}" sed -i -e '1s:^#! \?:#!'"${EPREFIX}"':' "${fn}" continue fi # all else is an error if the found script is in $PATH
oh, sorry. Then again, I don't know why /usr gets stripped off the shebang
So, in reality, the only way that this will die is because it is hitting this code block: # all else is an error if the found script is in $PATH local fp=${fn#${D}} ; fp=/${fp%/*} if [[ ":${PATH}:" == *":${fp}:"* ]] || hasq stricter ${FEATURES} ; then echo "${fn#${D}}:${line[0]}" \ >> "${T}"/non-prefix-shebangs-errs else eqawarn "invalid shebang in ${fn#${D}}: ${line[0]}" fi done if [[ -e "${T}"/non-prefix-shebangs-errs ]] ; then eqawarn "QA Notice: the following files use invalid (possible non-prefixed) shebangs:" eqawarn "$(<"${T}"/non-prefix-shebangs-errs)" die "Aborting due to QA concerns: invalid shebangs found" rm -f "${T}"/non-prefix-shebangs-errs fi It is hard for me to debug due to the bash expansion, but someone else hit it in IRC today...We need to do something about it.
(In reply to comment #6) > So, in reality, the only way that this will die is because it is hitting this > code block: And the only way it will get there is if the "automatic prefixing" doesn't get ran, particular: "if [[ -e ${EPREFIX}${line[0]} || -e ${ED}${line[0]} ]] ; then" which means that the old behavior: " if [[ -x ${EPREFIX}${line[0]} || -x ${ED}${line[0]} ]] ; then" worked better in this regard and it is a regression since r15435
how can something be executable but not exist?
Hi, I am the guy who hit the bug and reported on IRC. I commented the following lines : eqawarn "QA Notice: the following files use invalid (possible non-prefixed) shebangs:" eqawarn "$(<"${T}"/non-prefix-shebangs-errs)" die "Aborting due to QA concerns: invalid shebangs found" rm -f "${T}"/non-prefix-shebangs-errs replacing them with echo "blahblah". I had to do it twice, as the procedure implies to reinstall portage at some point, which erases the modifications. I just finished the bootstraping procedure, and as far as I can see, everything is working fine (I installed fortume-$ Thanks to Jeremy Olexa (darkside) for helping me out on IRC.
I looked at this problem in detail, and I couldn't reproduce this with recent Portage. I'm currently testing 2.2.00.15838 which has different code compared to 15444.
*** Bug 322005 has been marked as a duplicate of this bug. ***
seems it still happens
ok, why did noone ever looked into the ebuild? (Includes me) # keep most things in /usr, just the fun stuff in / dodir /bin mv "${ED}"/usr/bin/{gunzip,gzip,uncompress,zcat} "${ED}"/bin/ || die sed -e 's:/usr::' -i "${ED}"/bin/gunzip || die that is clearly going to cause trouble IMO. I think this should do: - sed -e 's:/usr::' -i "${ED}"/bin/gunzip || die + sed -e "s:${EPREFIX}/usr:${EPREFIX}:" -i "${ED}"/bin/gunzip || die Can someone try if that really fixes it? In the meanwhile I committed the fix to the ebuild.
fix committed and bootstraps work for me
