[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