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

Lin, Shuicheng shuicheng.lin at intel.com
Thu Sep 27 01:23:44 UTC 2018


Hi all,
I will try to finish the fuzzy correction today.

Best Regards
Shuicheng


-----Original Message-----
From: Jones, Bruce E 
Sent: Thursday, September 27, 2018 9:20 AM
To: Rowsell, Brent <Brent.Rowsell at windriver.com>; Khalil, Ghada <Ghada.Khalil at windriver.com>; Saul Wold <sgw at linux.intel.com>; starlingx-discuss at lists.starlingx.io; Xie, Cindy <cindy.xie at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>
Subject: RE: [Starlingx-discuss] build-pkgs cannot complete std build

Cindy, do you agree?  How long will it take for the patches to be corrected?

Team - assuming her answer is "more than a day or two", do we want to hold the release branch creation that long?  We're moving the release into day-for-day slip mode...

      brucej

-----Original Message-----
From: Rowsell, Brent [mailto:Brent.Rowsell at windriver.com] 
Sent: Wednesday, September 26, 2018 6:12 PM
To: Khalil, Ghada <Ghada.Khalil at windriver.com>; Saul Wold <sgw at linux.intel.com>; starlingx-discuss at lists.starlingx.io; Xie, Cindy <cindy.xie at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>
Subject: Re: [Starlingx-discuss] build-pkgs cannot complete std build

I agree.

Brent 

-----Original Message-----
From: Khalil, Ghada [mailto:Ghada.Khalil at windriver.com] 
Sent: Wednesday, September 26, 2018 9:10 PM
To: Saul Wold <sgw at linux.intel.com>; starlingx-discuss at lists.starlingx.io; Xie, Cindy <cindy.xie at intel.com>; Lin, Shuicheng <shuicheng.lin at intel.com>
Subject: Re: [Starlingx-discuss] build-pkgs cannot complete std build

Hi Saul,
It looks like the first step is for all the 7.5 patches to be re-generated and de-fuzzed. I consider this to be gating the October release. Do you agree?

I suggest that this gets addressed in master before the release branch creation. I will add a new task to the CentOS 7.5 rebase story for Cindy's team to work on.

I would also like to propose that we continue to place master under code freeze/limited merge and only allow the items we consider gating for October. This would allow us to limit the churn to the next few days. Is this ok with everyone?

Thanks,
Ghada


-----Original Message-----
From: Saul Wold [mailto:sgw at linux.intel.com] 
Sent: Wednesday, September 26, 2018 7:45 PM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] build-pkgs cannot complete std build



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
> 

_______________________________________________
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
_______________________________________________
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