<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I have also been investigating another
intermittent build error affecting initscripts.<br>
<br>
<span style="color: rgb(0, 0, 0); font-family: "SF
Regular", "Segoe UI Regular", sans-serif;
font-size: 16px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; orphans: 2; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration-style: initial; text-decoration-color: initial;
display: inline !important; float: none;"><a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/starlingx/+bug/1794611">https://bugs.launchpad.net/starlingx/+bug/1794611</a></span><br>
<br>
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.<br>
<br>
In this case it is a new option that rpm passes to the patch
command, --no-backup-<wbr>if-mismatch, first introduced by
rpm-4.13.<br>
This option has the effect of suppressing the creation of '.orig'
files.<br>
<br>
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.<br>
<br>
Prior to StarlingX, my policy for rebasing patches was that no
fuzz is tolerated in our patches.<br>
<br>
All the work to upgrade to 7.5 has created a lot of fuzzy patches.<br>
<br>
audit-2.8.1-3.el7.tis.2<br>
bash-4.2.46-30.el7.tis.3<br>
dhcp-4.2.5-68.el7.centos.1.tis.8<br>
dnsmasq-2.76-5.el7.tis.6<br>
drbd-8.4.3-0.tis.6<br>
facter-2.4.4-4.el7.tis.4<br>
haproxy-1.5.18-7.el7.tis.7<br>
initscripts-9.49.41-1.el7.tis.16<br>
iptables-1.4.21-24.1.el7_5.tis.3<br>
kubernetes-1.10.0-1.tis.1<br>
libevent-2.0.21-4.el7.tis.2<br>
lighttpd-1.4.50-1.el7.tis.6<br>
logrotate-3.8.6-15.el7.tis.3<br>
netpbm-10.79.00-7.el7.tis.2<br>
net-snmp-5.7.2-33.el7_5.2.tis.10<br>
net-tools-2.0-0.22.20131004git.el7.tis.2<br>
nfs-utils-1.3.0-0.54.el7.tis.4<br>
nss-pam-ldapd-0.8.13-16.el7.tis.4<br>
ntp-4.2.6p5-28.el7.centos.tis.3<br>
openldap-2.4.44-15.el7_5.tis.8<br>
openssh-7.4p1-16.el7_4.tis.9<br>
pam-1.1.8-22.el7.tis.4<br>
puppet-4.8.2-1.el7.tis.2<br>
puppet-ceph-2.4.1-1.el7.tis.4<br>
puppet-horizon-11.5.0-1.el7.tis.1<br>
python-2.7.5-69.el7_5.tis.3<br>
python-keyring-5.7.1-1.tis.2<br>
python-wsme-0.9.2-1.el7.tis.3<br>
resource-agents-3.9.5-124.el7.tis.12<br>
rsync-3.1.2-4.el7.tis.2<br>
shadow-utils-4.1.5.1-24.el7.tis.4<br>
sudo-1.8.19p2-14.el7_5.tis.3<br>
watchdog-5.13-11.el7.tis.2<br>
<br>
So any of these packages might or might not produce unwanted .orig
files.<br>
The .orig files might or might not be packaged, or break
packaging.<br>
<br>
So there are a number of threads to pull at here.<br>
1) Are fuzzy patches tolerated. I vote no. Sooner or later a
fuzzy patch will be mis-applied and cause us problems.<br>
2) Can we force rpmbuild within mock to use a consistent policy
with respect to creation of orig files?<br>
3) Can we pre-build rpm, such that all packages build against the
same rpm version?<br>
4) Are we patching any other low level build tools that have
similar issues? Possibly explaining ceph? TBD<br>
<br>
<br>
<br>
On 18-09-26 12:16 PM, Scott Little wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2ca0a806-58fa-34c7-0176-ac2d74a83e2d@windriver.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">aclocal 'too many loops' has been
popping up sporadically for a week or two now. Possibly 7.5
related.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
Scott<br>
<br>
<br>
On 18-09-26 11:32 AM, Cordoba Malibran, Erich wrote:<br>
</div>
<blockquote type="cite"
cite="mid:668d78e1a36768a23f247a0a4f92b79920db33a6.camel@intel.com">
<pre wrap="">BUILDSTDERR: aclocal: error: too many loops
BUILDSTDERR: aclocal: Please contact <a class="moz-txt-link-rfc2396E" href="mailto:bug-automake@gnu.org" moz-do-not-send="true"><bug-automake@gnu.org></a>.
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)</pre>
</blockquote>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Starlingx-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>