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:

- build command used?
- Was it a new workspace, a cleaned workspace, or a previously used workspace?

- $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