49/237 test-resolved-packet OK 0.79 s 50/237 test-dnssec OK 0.03 s 51/237 test-timesync FAIL 0.09 s 52/237 test-device-nodes OK 0.08 s 53/237 test-engine SKIP 0.10 s 54/237 test-job-type OK 0.04 s ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-systemd_20170903-225953 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) emerge -qpv sys-apps/systemd [ebuild U ] sys-apps/systemd-234-r3 [233-r4] USE="acl gcrypt kmod lz4 pam seccomp ssl -apparmor -audit -build -cryptsetup -curl -elfutils -gnuefi -http -idn -importd -libidn2% -lzma -nat -policykit -qrcode (-selinux) -sysv-utils {-test} -vanilla -xkb (-doc%)" ABI_X86="(64) -32 (-x32)"
Created attachment 492282 [details] emerge-info.txt
Created attachment 492284 [details] emerge-history.txt
Created attachment 492286 [details] environment
Created attachment 492288 [details] etc.portage.tbz2
Created attachment 492290 [details] sys-apps:systemd-234-r3:20170904-083938.log.bz2
Created attachment 492292 [details] temp.tbz2
Created attachment 492434 [details] failed tests
I am not able to reproduce any of the failures you did. However, I did have one failure of my own: 61/221 test-condition FAIL 2.67 s ... Assertion 'r == 0' failed at ../systemd-234/src/test/test-condition.c:396, function test_condition_test_user(). Aborting.
These test failures seem to be caused by missing /etc/machine-id in your chroot image.
(In reply to Mike Gilbert from comment #8) > 61/221 test-condition FAIL 2.67 s > ... > Assertion 'r == 0' failed at ../systemd-234/src/test/test-condition.c:396, > function test_condition_test_user(). Aborting. This one was fixed upstream after v234. https://github.com/systemd/systemd/pull/6409
(In reply to Mike Gilbert from comment #10) Yes, the file is (in the meanwhile) there I ran "emerge -1 systemd" again at that machine and now I just get this issue : runtime error: file file:///usr/share/sgml/docbook/xsl-stylesheets/lib/lib.xsl line 60 element variable xsltApplySequenceConstructor: A potential infinite template recursion was detected. You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000). Templates: #0 name string.subst #1 name string.subst #2 name string.subst #3 name string.subst #4 name string.subst #5 name string.subst #6 name string.subst #7 name string.subst #8 name string.subst #9 name string.subst #10 name string.subst #11 name string.subst #12 name string.subst #13 name string.subst #14 name string.subst Variables: #0 replacement target string #1 target string #2 string #3 replacement target string #4 target string #5 string #6 replacement target string #7 target string #8 string #9 replacement target string #10 target string #11 string #12 replacement target string #13 target string #14 string error: file man/systemd.index.xml xsltRunStylesheet : run failed ninja: build stopped: subcommand failed.
(In reply to Toralf Förster from comment #11) That's bug 630022.
(In reply to Mike Gilbert from comment #12) > That's bug 630022. Indeed. sys-apps/systemd-234-r3 should depend on app-text/docbook-xsl-stylesheets-1.79.1-r2, which contains the fix.
(In reply to Magnus Kessler from comment #13) for USE=test or unconditionally ?
(In reply to Toralf Förster from comment #14) > (In reply to Magnus Kessler from comment #13) > for USE=test or unconditionally ? For me it was unconditionally. However, this was on a system that had a multilib profile installed with x86 and amd64 variants being built.
Upstream is probably not going to entertain running tests without /etc/machine-id.
