If built with FEATURES="test": >>> Source compiled. /usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10385/temp/environment: ./pym/portage/tests/runTests: /usr/bin/python: bad interpreter: No such file or directory * ERROR: sys-apps/portage-2.2.00.10385 failed: * test(s) failed * * Call stack: * ebuild.sh: 49: <call src_test> * environment:2757: ./pym/portage/tests/runTests || die "test(s) failed" ... sed-magic needed to correct these lines to include $EPREFIX, or simply alter them to '#!/bin/env python'?
Additionally, when trying to merge eselect-ctags-1.5 I get: >>> Install eselect-ctags-1.5 into /usr/opt/portage/var/tmp/portage/app-admin/eselect-ctags-1.5/image/opt/portage/ category app-admin /opt/portage/usr/lib/portage/bin/doman: line 35: unexpected argument `(' to conditional binary operator /opt/portage/usr/lib/portage/bin/doman: line 35: syntax error near `(.' /opt/portage/usr/lib/portage/bin/doman: line 35: ` [[ $x =~ (.*)\.([a-z][a-z](_[A-Z][A-Z])?)\.(.*) ]] ; then' * ERROR: app-admin/eselect-ctags-1.5 failed: * doman failed * * Call stack: * ebuild.sh: 49: <call src_install> * environment:2115: doman ctags.eselect.5 || die "doman failed" ... where 'doman' is a portage binary. The problematic segment is: if ! hasq "${EAPI:-0}" 0 1 && \ [[ $x =~ (.*)\.([a-z][a-z](_[A-Z][A-Z])?)\.(.*) ]] ; then name=${BASH_REMATCH[1]##*/}.${BASH_REMATCH[4]} mandir=${BASH_REMATCH[2]}/man${suffix:0:1} else name=${x##*/} mandir=${i18n}man${suffix:0:1} fi Both regular-expressions (lines 35 and 43) cause problems in 'doman' - I'm assuming this is a portage problem rather than an eselect-ctags problem...
merged fine here. What bash are you using?
Just to check I re-merged the latest bash and latest portage from prefix before trying again, but get the same problem :( bash passes it's entire test-suite (except for the unicode sections, where there is a notice that they may fail if the environment isn't entirely unicode-compliant), and I can use the '=~' operator myself as a test... so I'm really not sure what's going wrong here. The only thing I can think - when 'emerge' invokes 'doman' does it specify the interpreter (rather than directly invoking the script and allowing the shebang line the specify how it should be run)? The only possible cause I can imagine is that emerge manually invokes *a* bash to run the 'doman' script, and isn't using the prefix one. e.g. whilst the prefix bash does work, is another bash on the system (which might be pre bash-3.2, and so not supporting '=~' syntax) being invoked instead? It's a long-shot, I know...
A quick way to figure that out is by echoing $BASH in doman. Nasty bug if it found another bash than prefixed bash :(
Going back to the original problem (perhaps we should split this...), the portage tests now fail with: >>> Source compiled. Traceback (most recent call last): File "./pym/portage/tests/runTests", line 15, in <module> import portage.tests as tests File "/usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10625/work/prefix-portage-2.2.00.10625/pym/portage/__init__.py", line 77, in <module> import portage.getbinpkg File "/usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10625/work/prefix-portage-2.2.00.10625/pym/portage/getbinpkg.py", line 6, in <module> from portage.output import red, yellow, green File "/usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10625/work/prefix-portage-2.2.00.10625/pym/portage/output.py", line 14, in <module> from portage.const import COLOR_MAP_FILE File "/usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10625/work/prefix-portage-2.2.00.10625/pym/portage/const.py", line 10, in <module> from portage.const_autotool import * File "/usr/opt/portage/var/tmp/portage/sys-apps/portage-2.2.00.10625/work/prefix-portage-2.2.00.10625/pym/portage/const_autotool.py", line 12 EAPIPREFIX = @EAPIPREFIX@ ^ SyntaxError: invalid syntax * ERROR: sys-apps/portage-2.2.00.10625 failed: * test(s) failed * * Call stack: * ebuild.sh: 49: <call src_test> * environment:2793: ./pym/portage/tests/runTests || die "test(s) failed" ... which looks to me as if a substitution hasn't been applied?
I admit that I never run the tests, as they are quite useless to me. Maybe I should restrict it in the ebuild, the tests aren't "ported" to Prefix either, if necessary at all.
I've sorted out the doman problem: I had bash-3.2.0 in usr/bin/bash and bash-3.2.39 in bin/bash, and the former was being used.
ah, so we can consider that to be a local problem?
Yeah - the 'doman' problem is now solved (I don't quite know how bash managed to get into usr/bin rather than bin, but it could well have been my doing back in the mists of time...) The issue with the portage test-suite is still valid, though - and I really think that it would be useful to try and allow the test-suite to at least run, given how key an system portage is. (I build everything with FEATURES="test", and there are surprisingly few problems, all things considered...)
yes and no, there are a few tests that do some unit-testing approach
Can't run the tests, because for that the portage sources need to be installed first. Fixing that is a whole lot more complicated than it's worth IMO.
(In reply to comment #11) > Can't run the tests, because for that the portage sources need to be installed > first. Fixing that is a whole lot more complicated than it's worth IMO. > How about throwing a RESTRICT=test in the ebuild then?
I thought I added that one already?
(In reply to comment #13) > I thought I added that one already? > You did, my mistake.
