Hi all,
Here is the patch list to de-fuzz the patches in CentOS7.5 upgrade task.
https://review.openstack.org/#/q/topic:patch_fuzz+(status:open+OR+status:merged)
I notice there are some other src rpms also have the fuzzy issue. Will handle them later.
Also, I find some SRC RPM itself has the fuzzy issue, such as openldap/rsync/netpbm/openssh etc.
So we cannot eliminate all fuzzy issue just by rebase ourselves patches.
Best Regards
Shuicheng
From: Scott Little [mailto:scott.little@windriver.com]
Sent: Thursday, September 27, 2018 5:08 AM
To: starlingx-discuss@lists.starlingx.io
Subject: Re: [Starlingx-discuss] build-pkgs cannot complete std build
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.
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.
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.
2) Can we force rpmbuild within mock to use a consistent policy with respect to creation of orig files?
3) Can we pre-build rpm, such that all packages build against the same rpm version?
4) Are we patching any other low level build tools that have similar issues? Possibly explaining ceph? TBD
On 18-09-26 12:16 PM, Scott Little wrote: