Hi, I did this experiment: I cherry pick all the defuzzed patches and try to build. The result was that the build failing packages now are: libvirt-python-4.7.0-1.tis.1.src.rpm vm-topology-1.0- 1.tis.src.rpm libvirt-4.7.0-1.tis.22.src.rpm which basically is just libvirt, the other ones are just depending on libvirt. Checking the build.log for libvirt: Making all in src make[2]: Entering directory `/builddir/build/BUILD/libvirt-4.7.0/src' BUILDSTDERR: make[2]: *** No rule to make target `keycodemapdb/data/keymaps.csv', needed by `util/virkeycodetable_linux.h'. Stop. make[2]: Leaving directory `/builddir/build/BUILD/libvirt-4.7.0/src' BUILDSTDERR: make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/libvirt-4.7.0' BUILDSTDERR: make: *** [all] Error 2 RPM build errors: BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.Chutrp (%build) BUILDSTDERR: Macro expanded in comment on line 2067: %{_datadir}/systemtap/tapset/libvirt_probes*.stp BUILDSTDERR: Macro expanded in comment on line 2068: %{_datadir}/systemtap/tapset/libvirt_qemu_probes*.stp BUILDSTDERR: Macro expanded in comment on line 2069: %{_datadir}/systemtap/tapset/libvirt_functions.stp BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.Chutrp (%build) Child return code was: 1 So, this is a new failure, but the problem stuck in ceph wasn't present in this execution. Should be noticed that only one attempt of build- pkgs was needed to get here. -Erich On Thu, 2018-09-27 at 11:21 -0700, 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!
The second possible element is that build-pkgs is using flags that preserve the mock environment between packages. The goal was to avoid reinstalling required packages that are often common across the packages we build. It was a build time speedup that has been in use for 2- 3 years now without incident.
Google shows that other folks have hit 'aclocal too many loops' as well, and there are suggestions that it might be fixed in a recent update to automake. Scanning the changelog for the latest and greatest from gnu.org doesn't show any obvious fixes addressing this issue.
Scott
On 18-09-26 11:32 AM, Cordoba Malibran, Erich wrote:
BUILDSTDERR: aclocal: error: too many loops BUILDSTDERR: aclocal: Please contact<bug-automake@gnu.org>. BUILDSTDERR: at /usr/share/automake-1.13/Automake/Channels.pm line 662. BUILDSTDERR: Automake::Channels::msg('automake', '', 'too many loops') called at /usr/share/automake- 1.13/Automake/ChannelDefs.pm line 212 BUILDSTDERR: Automake::ChannelDefs::prog_error('too many loops') called at /usr/bin/aclocal line 1187 BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.Sj0E7c (%build) BUILDSTDERR: Macro expanded in comment on line 214: %global _libexecdir %{_exec_prefix}/lib BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.Sj0E7c (%build)
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus s
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss