[Starlingx-discuss] build-pkgs cannot complete std build

[Cordoba Malibran, Erich]

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 at 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 at lists.starlingx.io
> > http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discus
> > s
> > 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss