28 Sep
2018
28 Sep
'18
10:39 p.m.
Ok, we've seen 3 ceph failures in our last 6 builds. The common factor: tpm2-tools builds on 'b0' before ceph builds. Our theory. The buildRequires of tpm2-tools causes autoconf-archive to be installed... which installs a bunch of .m4 files in /usr/share/aclocal ... which causes ceph grief when it calls aclocal. I don't really know automake or aclocal all that well. I'm assuming /usr/share/aclocal is acting something like a cache, but it's a cache whos contents are incompatible with ceph. Do we have any autotools / aclocal / m4 experts in the house? Possible fixes: - ceph: can we tell it to not use the aclocal cache... explicitly (a flag to aclocal?) ... or implicitly (update ceph's m4 files so they look 'newer' than the cache)? - tpm2-tools: Can we remove the dependence on autoconf-archive? No other package we build seems to need it. Scott On 18-09-27 04:45 PM, Saul Wold wrote: > > And of course it worked the third time! > > So, I lost the good logs. > > Sau! > > > On 09/27/2018 12:56 PM, Scott Little wrote: >> On 18-09-27 03:53 PM, Scott Little wrote: >>> Our latest build, based on code synced at 2018-09-27T15:28:00 UTC, >>> built successfully. >>> >>> It took three attempts to get ceph built. The first two passes >>> aborted quickly due to missing packages. The final pass did not >>> exhibit the 'aclocal: too many loops'**issue. >>> >>> The only build I have that exhibited the too many loops error was a >>> snapshot on 2018-09-20T15:50:40 UTC >>> >>> I do have a designer with an older snapshot that seems to hit it >>> regularly, so I'll work with him and see if we can learn more. >>> >>> I think we need more data from the community >>> - Who's build is failing on ceph with *aclocal: too many loops?* >>> - Who is building successfully ? >>> - Who can build only intermittently? >>> >>> >>> >>> Info to collect for failed builds: >> - repo sync timestamp >>> - build command used? >>> - Was it a new workspace, a cleaned workspace, or a previously used >>> workspace? >> - $MY_WORKSPACE/CONTEXT >>> - $MY_WORKSPACE/build-std.log >>> - $MY_WORKSPACE/std/results/*/ceph-*/*.log >>> >>> For successful builds, same info. Rather than full build logs, I can >>> settle for: >>> - grep '\(Success building\|iteration\|building ceph\)' >>> $MY_WORKSPACE/build-std.log >>> - grep compute_resources: build-std.log >>> >>> >>> >>> >>> >>> On 18-09-27 02:21 PM, Saul Wold wrote: >>>> On 09/26/2018 09:16 AM, Scott Little wrote: >>>>> aclocal 'too many loops' has been popping up sporadically for a >>>>> week or two now. Possibly 7.5 related. >>>>> >>>>> I suspect that there is a build order and/or race condition >>>>> element to this. It often goes away if you just run build-pkgs a >>>>> second time. >>>>> >>>> I am seeing this failure also, but it does not go away after a >>>> second rebuild. I have the lastest stx-root (build-tools) with the >>>> recent patches. >>>> >>>> Is this directly related to the fuzz issue or is there something >>>> else we need to address in CEPH itself. >>>> >>>> This is blocking my local build. >>>> >>>> Sau! >>> >>> >>> >>> >>> _______________________________________________ >>> Starlingx-discuss mailing list >>> Starlingx-discuss@lists.starlingx.io >>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >> >> >> >> >> _______________________________________________ >> Starlingx-discuss mailing list >> Starlingx-discuss@lists.starlingx.io >> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss >>