make[2]: Entering directory '/var/tmp/portage/x11-apps/xauth-1.0.10/work/xauth-1.0.10_build/tests' make[3]: Entering directory '/var/tmp/portage/x11-apps/xauth-1.0.10/work/xauth-1.0.10_build/tests' FAIL: test_xauth ============================================================================ Testsuite summary for xauth 1.0.10 ============================================================================ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-plasma-systemd_libressl-test_20190408-173502 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-8.3.0 * Available Python interpreters, in order of preference: [1] python3.6 [2] python2.7 (fallback) emerge -qpvO x11-apps/xauth [ebuild N ] x11-apps/xauth-1.0.10 USE="ipv6 test"
Created attachment 572514 [details] emerge-info.txt
Created attachment 572516 [details] emerge-history.txt
Created attachment 572518 [details] environment
Created attachment 572520 [details] etc.portage.tbz2
Created attachment 572522 [details] logs.tbz2
Created attachment 572524 [details] temp.tbz2
Created attachment 572526 [details] tests.tbz2
Created attachment 572528 [details] x11-apps:xauth-1.0.10:20190410-210046.log
This failure occurs for me when dev-util/cmdtest is not installed. However, dev-util/cmdtest is listed as a test dep: DEPEND="${RDEPEND} test? ( dev-util/cmdtest )" Can you confirm that cmdtest is installed? Try running the test manually? p50-ethernet /var/tmp/portage/x11-apps/xauth-1.0.10/work/xauth-1.0.10_build/tests # ./test_xauth Unable to execute 'cmdtest'. Make sure, that it is installed: No such file or directory
Well, the image is gone, so no further tests possible, "cmdtest" was installed (see attached emerge history): Tue Apr 9 00:12:11 2019 >>> dev-util/cmdtest-0.30 FWIW that package is installed fine at 5 different images having "test" in FEATURES in May and June
Okay. If you happen to encounter the failure again, please reopen.
it is still an issue at unstable amd64 tinderbox image 17.1-desktop-gnome_libressl-abi32+64-test_20190621-191902
Created attachment 580390 [details] emerge-info.txt
Created attachment 580392 [details] emerge-history.txt
Created attachment 580394 [details] environment
Created attachment 580396 [details] etc.portage.tbz2
Created attachment 580398 [details] logs.tbz2
Created attachment 580400 [details] temp.tbz2
Created attachment 580402 [details] tests.tbz2
Created attachment 580404 [details] x11-apps:xauth-1.0.10:20190622-074015.log
Sorry I haven't rechecked this bug. test_xauth.log inside logs.tbz2 contains this: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/cliapp/app.py", line 193, in _run self.process_args(args) File "/usr/lib/python-exec/python2.7/cmdtest", line 64, in process_args self.setup_ttystatus(td) File "/usr/lib/python-exec/python2.7/cmdtest", line 105, in setup_ttystatus self.ts = ttystatus.TerminalStatus(period=0.001) File "/usr/lib64/python2.7/site-packages/ttystatus/status.py", line 37, in __init__ period=period, _terminal=_terminal) File "/usr/lib64/python2.7/site-packages/ttystatus/messager.py", line 45, in __init__ self._terminal.open_tty() File "/usr/lib64/python2.7/site-packages/ttystatus/tty.py", line 36, in open_tty curses.setupterm(None, self._terminal.fileno()) error: setupterm: could not find terminal FAIL test_xauth (exit status: 1) I think this might be the result of the way your tinderbox works? https://stackoverflow.com/questions/9485699/setupterm-could-not-find-terminal-in-python-program-using-curses That answer suggests setting export TERM=linux export TERMINFO=/etc/terminfo Does that work? Is your tinderbox not setting TERM? (My shell doesn't set TERMINFO, but does set TERM, FWIW). I see just a couple of instances of ebuilds setting TERM. Maybe we need to do that here?
I do have mr-fox ~ # echo $TERM $TERMINFO xterm-256color mr-fox ~ # echo $TERMINFO I'll try your suggestions.
(In reply to Toralf Förster from comment #22) > I do have > mr-fox ~ # echo $TERM $TERMINFO > xterm-256color > mr-fox ~ # echo $TERMINFO > > > I'll try your suggestions. OTOH it emerged now fine at a test image (img2/17.1_desktop_plasma_systemd-test-20191114-081627) even with "xterm-256color" so I do tend to think, that the failure was caused by a different root cause.
Weird. I hate to keep doing this, but I don't know how to proceed since I've never been able to reproduce the issue -- so I guess I'll mark as NEEDINFO again :|
