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

Saul Wold sgw at linux.intel.com
Wed Sep 26 23:44:50 UTC 2018



On 09/26/2018 02:08 PM, Scott Little wrote:
> I have also been investigating another intermittent build error 
> affecting initscripts.
> 
> https://bugs.launchpad.net/starlingx/+bug/1794611
> 
> So any given package might be built by rpm-4.11.3, or by rpm-4.14.0.  
> It's a race with many inputs.  Ideally it shouldn't matter, but it 
> does.  build-pkgs --serial might reduce the odds, but likely won't solve 
> it entirely.
> 
Why is this the case in the first place, can't we ensure we only build 
rpm-4.14.0?

> In this case it is a new option that rpm passes to the patch command, 
> --no-backup-if-mismatch, first introduced by rpm-4.13.
> This option has the effect of suppressing the creation of '.orig' files.
> 
> Creation of .orig files are a consequence of applying patches that are 
> not clean. Unclean patches are ones that require 'fuzzing', i.e. treat 
> the patch line numbers as approximate, rather than a strict requirement, 
> just so long as the before/after context seems to be correct.
> 
> Prior to StarlingX, my policy for rebasing patches was that no fuzz is 
> tolerated in our patches.
> 
> All the work to upgrade to 7.5 has created a lot of fuzzy patches.
> 
Wow, sorry I was not aware that they were all fuzzy patches.

> audit-2.8.1-3.el7.tis.2
> bash-4.2.46-30.el7.tis.3
> dhcp-4.2.5-68.el7.centos.1.tis.8
> dnsmasq-2.76-5.el7.tis.6
> drbd-8.4.3-0.tis.6
> facter-2.4.4-4.el7.tis.4
> haproxy-1.5.18-7.el7.tis.7
> initscripts-9.49.41-1.el7.tis.16
> iptables-1.4.21-24.1.el7_5.tis.3
> kubernetes-1.10.0-1.tis.1
> libevent-2.0.21-4.el7.tis.2
> lighttpd-1.4.50-1.el7.tis.6
> logrotate-3.8.6-15.el7.tis.3
> netpbm-10.79.00-7.el7.tis.2
> net-snmp-5.7.2-33.el7_5.2.tis.10
> net-tools-2.0-0.22.20131004git.el7.tis.2
> nfs-utils-1.3.0-0.54.el7.tis.4
> nss-pam-ldapd-0.8.13-16.el7.tis.4
> ntp-4.2.6p5-28.el7.centos.tis.3
> openldap-2.4.44-15.el7_5.tis.8
> openssh-7.4p1-16.el7_4.tis.9
> pam-1.1.8-22.el7.tis.4
> puppet-4.8.2-1.el7.tis.2
> puppet-ceph-2.4.1-1.el7.tis.4
> puppet-horizon-11.5.0-1.el7.tis.1
> python-2.7.5-69.el7_5.tis.3
> python-keyring-5.7.1-1.tis.2
> python-wsme-0.9.2-1.el7.tis.3
> resource-agents-3.9.5-124.el7.tis.12
> rsync-3.1.2-4.el7.tis.2
> shadow-utils-4.1.5.1-24.el7.tis.4
> sudo-1.8.19p2-14.el7_5.tis.3
> watchdog-5.13-11.el7.tis.2
> 
> So any of these packages might or might not produce unwanted .orig files.
> The .orig files might or might not be packaged, or break packaging.
> 
> So there are a number of threads to pull at here.
> 1) Are fuzzy patches tolerated.   I vote no.  Sooner or later a fuzzy 
> patch will be mis-applied and cause us problems.

Agreed, when updating patches should be rebased and de-fuzzed.

> 2) Can we force rpmbuild within mock to use a consistent policy with 
> respect to creation of orig files?

It would be good to investigate that.

> 3) Can we pre-build rpm, such that all packages build against the same 
> rpm version?

Yes, as mentioned above we should use a consistent version.

> 4) Are we patching any other low level build tools that have similar 
> issues?  Possibly explaining ceph?  TBD
>

Yup more info is needed

Sau!


> 
> 
> On 18-09-26 12:16 PM, 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.
>>
>> 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-discuss
> 
> 
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 



More information about the Starlingx-discuss mailing list