On 2016-05-31 17:21, Aurelien Jarno wrote: > On 2016-05-31 16:23, John Paul Adrian Glaubitz wrote: > > (Sorry for the confusion, I accidentally used my company email. Please > > answer to this address). > > > > Hi Aurelien! > > > > On 05/31/2016 04:13 PM, Aurelien Jarno wrote: > > >> ---------- > > >> XFAIL: wcsmbs/test-wcsncmp > > >> original exit status 1 > > >> wcsncmp simple_wcsncmp stupid_wcsncmp > > >> Didn't expect signal from child: got `Bus error' > > >> ---------- > > > > > > While the issue is real, this is not the reason while the package fails > > > to build from source. The test is marked as XFAIL as shown above. > > > > Ok, I see. I thought the problem would still trigger due to the unusual > > failure. > > > > > Thanks for submitting the patch upstream. Given the above, I think it is > > > better to wait for an answer from upstream before applying it. > > > > The test comes from Jose Marchesi who I know is gcc upstream, but I'm > > not sure about glibc. Jose, could you please comment on this? > > > > >> Please note: I was still getting some spurious test failures in > > >> rt/tst-mqueue5 > > >> due to timeouts. But those could also be a local issue which needs some > > >> further > > >> investiogation (might be related to TIMEOUTFACTOR in debian/build.mk). > > > > > > TIMEOUTFACTOR just increases the timeout, if you don't specify it, the > > > test will just fail faster. > > > > Hmm, then I'm a bit out of ideas. The idea came from Nick Alcock, so maybe > > he can comment on this as well. > > > > What's more strange is that glibc_2.22-7 actually happened to build fine, > > with the tests enabled [1]. All later builds failed again. > > This logs show that a build can be successful with the test-wcsncmp test > failing (look for "XFAIL: wcsmbs/test-wcsncmp" in the build log). > > The other builds fails on andi due to the following issue: > > | FAIL: math/test-idouble > | original exit status 1 > | testing double (inline functions) > | Failure: Test: Real part of: clog10_upward (-0x9.93d17p-4 + 0x7.c5c8d8p-4 i) > | Result: > | is: -1.12998325949956790470e-01 -0x1.ced75527533340000000p-4 > | should be: -1.12998111847613019742e-01 -0x1.ced71bae52efa0000000p-4 > | difference: 2.14102343770727898687e-07 0x1.cbc8021d000000000000p-23 > | ulp : 15427699770.0000 > | max.ulp : 8.0000 > | > | Test suite completed: > | 58870 test cases plus 56646 tests for exception flags and > | 56646 tests for errno executed. > | 1 errors occurred. > > And on u164 due to the rt/tst-mqueue5. > > So it just look like rt/tst-mqueue5 is racy and sometimes work. You got > more chance on the 2.22-7 build.
glibc 2.22-10 has been tried on landau, and the error is different: FAIL: rt/tst-shm original exit status 1 It's very likely that /dev/shm (or /run/shm) is not mounted correctly in the chroot. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
