[Starlingx-discuss] de-fuzz centos7.5 upgraded src rpm
Saul Wold
sgw at linux.intel.com
Fri Sep 28 14:08:33 UTC 2018
On 09/28/2018 06:54 AM, Scott Little wrote:
> Certainly that will prevent creation of .orig files, so the risk of
> build failures in the packaging phase will be eliminated.
> However I have strong distrust of fuzzy patches. It suggests to me that
> folks are upgrading packages without doing the
> due diligence to make sure the patches are still needed, and are being
> applied correctly.
>
> Also I have seen twice in my career, a fuzzy patch get improperly
> applied to a neighboring bit of code that happened to
> look similar to the proper target. It's rare, but it can occur.
>
I agree with this, I have also been "bitten" by a mis-applied fuzz patch.
> On the plus side, moving to 4.14 would give us a consistent version of
> rpm throughout the build. That I like.
>
> I'm thinking we should do it, but we need a no fuzzy patches policy, and
> perhaps we create an audit that looks for fuzzy patches.
>
This sounds like a good plan for post-October release
Sau!
> Scott
>
>
>
> On 18-09-28 02:27 AM, Lin, Shuicheng wrote:
>>
>> Hi Scott,
>>
>> What do you think about upgrade rpm in mirror lst to 4.14 version? So
>> we could get rid of the fuzz issue.
>>
>> To do this upgrade, rpm will be moved from centos repo lst to tarball lst.
>>
>> Here is the release notes of rpm-4.13 to fix this fuzz issue:
>>
>> Enable –no-backup-if-mismatch by default in %patch macro (RhBug:884755
>> <https://bugzilla.redhat.com/show_bug.cgi?id=884755>)
>>
>> Best Regards
>>
>> Shuicheng
>>
>> *From:*Scott Little [mailto:scott.little at windriver.com]
>> *Sent:* Thursday, September 27, 2018 11:24 PM
>> *To:* Lin, Shuicheng <shuicheng.lin at intel.com>;
>> starlingx-discuss at lists.starlingx.io
>> *Subject:* Re: [Starlingx-discuss] de-fuzz centos7.5 upgraded src rpm
>>
>> Yes, I've seen some upstream packages that ship from CentOS or EL7
>> with fuzzy patches. Can't do much about that.
>>
>> My list might include packages where the only fuzzy patches are those
>> coming from CentOS. We'll have to sort through them by hand I think.
>>
>> Scott
>>
>>
>>
>> On 18-09-27 10:24 AM, Lin, Shuicheng wrote:
>>
>> 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)
>> <https://review.openstack.org/#/q/topic:patch_fuzz+%28status:open+OR+status:merged%29>
>>
>> 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 at windriver.com]
>> *Sent:* Thursday, September 27, 2018 5:08 AM
>> *To:* starlingx-discuss at lists.starlingx.io
>> <mailto:starlingx-discuss at 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:
>>
>> 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> <mailto: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
>> <mailto: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