Putting --fuzz=0 into rpmbuild on older versions?

[Tom Lane]

So, sure enough, I got blindsided by the fact that rawhide's RPM now
applies patches with --fuzz=0.  I don't object to tightening the policy
like that, but it's pretty unhappy-making that having tested an SRPM on
my Fedora 9 system offers no protection against the koji build failing.

I looked around for a place to inject --fuzz=0 into the patch arguments
on F-9, and couldn't find one.  Is the definition of %patch really
hardwired into rpmbuild?  It's not supposed to be according to the
documentation, but I can't find the macro definition anyplace ...

			regards, tom lane

[Kevin Kofler]

Tom Lane <tgl <at> redhat.com> writes:
>  So, sure enough, I got blindsided by the fact that rawhide's RPM
> now
>  applies patches with --fuzz=0.  I don't object to tightening the policy
>  like that, but it's pretty unhappy-making that having tested an SRPM on
>  my Fedora 9 system offers no protection against the koji build failing. 
For the KDE packages, we're simply adding %define _default_patch_fuzz 2 to our 
specfiles whenever a patch doesn't apply due to fuzz.

        Kevin Kofler

[Arjan van de Ven]

On Sun, 27 Jul 2008 18:53:33 +0000 (UTC)
Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Tom Lane <tgl <at> redhat.com> writes:
>  > So, sure enough, I got blindsided by the fact that rawhide's RPM now
>  > applies patches with --fuzz=0.  I don't object to tightening the
>  > policy like that, but it's pretty unhappy-making that having tested
>  > an SRPM on my Fedora 9 system offers no protection against the koji
>  > build failing.
>  
>  For the KDE packages, we're simply adding %define _default_patch_fuzz
>  2 to our specfiles whenever a patch doesn't apply due to fuzz. 
eww... why not rebase the patch instead?
(while making sure it's still a valid result)



-- 
If you want to reach me at my work email, use arjan(a)linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

[Dave Jones]

On Sun, Jul 27, 2008 at 02:31:45PM -0400, Tom Lane wrote:
>  So, sure enough, I got blindsided by the fact that rawhide's RPM
> now
>  applies patches with --fuzz=0.  I don't object to tightening the policy
>  like that, but it's pretty unhappy-making that having tested an SRPM on
>  my Fedora 9 system offers no protection against the koji build failing.
>  
>  I looked around for a place to inject --fuzz=0 into the patch arguments
>  on F-9, and couldn't find one.  Is the definition of %patch really
>  hardwired into rpmbuild?  
Yes.
See the ApplyPatch macro in the kernel specfile for a way to work
around it.  We've been doing fuzz=0 patches since circa fc7 after
a fuzzy patch caused a "can't boot" regression that was a nightmare
to track down.

	Dave

-- 
http://www.codemonkey.org.uk

[Tom Lane]

Dave Jones <davej(a)redhat.com&gt; writes:
>  On Sun, Jul 27, 2008 at 02:31:45PM -0400, Tom Lane wrote:
> >> I looked around for a place to inject --fuzz=0 into the patch arguments
> >> on F-9, and couldn't find one.  Is the definition of %patch really
> >> hardwired into rpmbuild?  
>  Yes. 
Ick.

>  See the ApplyPatch macro in the kernel specfile for a way to work
>  around it. 
Double ick.

After some poking at rpm I found that making F-9 support fuzz
specification decently is really a very small patch (attached).
With this, I can put "%_default_patch_fuzz 0" into ~/.rpmmacros
and get rawhide-equivalent behavior.  I think I'll be using a
locally patched rpm if I can't get the maintainer to apply this...

			regards, tom lane


diff -Naur rpm-4.4.2.3.orig/build/parsePrep.c rpm-4.4.2.3/build/parsePrep.c
--- rpm-4.4.2.3.orig/build/parsePrep.c	2008-04-01 03:28:21.000000000 -0400
+++ rpm-4.4.2.3/build/parsePrep.c	2008-07-28 16:20:03.000000000 -0400
@@ -61,7 +61,7 @@
  * @param strip		patch level (i.e. patch -p argument)
  * @param db		saved file suffix (i.e. patch --suffix argument)
  * @param reverse	include -R?
- * @param fuzz		include -F?
+ * @param fuzz		fuzz factor, fuzz<0 means no fuzz set
  * @param removeEmpties	include -E?
  * @return		expanded %patch macro (NULL on error)
  */
@@ -98,7 +98,7 @@
 #endif
 	t = stpcpy( stpcpy(t, "--suffix "), db);
     }
-    if (fuzz) {
+    if (fuzz>=0) {
 	t = stpcpy(t, " -F");
 	sprintf(t, "%d", fuzz);
 	t += strlen(t);
@@ -463,7 +463,8 @@
     int patch_index, x;
 
     memset(patch_nums, 0, sizeof(patch_nums));
-    opt_P = opt_p = opt_R = opt_E = opt_F = 0;
+    opt_P = opt_p = opt_R = opt_E = 0;
+    opt_F = rpmExpandNumeric("%{_default_patch_fuzz}");		/* get default fuzz
factor for %patch */
     opt_b = NULL;
     patch_index = 0;
 
@@ -515,7 +516,7 @@
 		fnum = strtok(NULL, " \t\n");
 	    }
 	    opt_F = (fnum ? strtol(fnum, &end, 10) : 0);
-	    if (! opt_F || *end) {
+	    if (opt_F < 0 || *end) {
 		rpmError(RPMERR_BADSPEC,
 			_("line %d: Bad arg to %%patch -F: %s\n"),
 			spec->lineNum, spec->line);
diff -Naur rpm-4.4.2.3.orig/macros.in rpm-4.4.2.3/macros.in
--- rpm-4.4.2.3.orig/macros.in	2008-04-01 03:28:22.000000000 -0400
+++ rpm-4.4.2.3/macros.in	2008-07-28 16:21:42.000000000 -0400
@@ -340,6 +340,9 @@
 #
 #%vendor
 
+#	Default fuzz level for %patch in spec file (-1 means don't set it).
+%_default_patch_fuzz	-1
+
 #==============================================================================
 # ---- Build configuration macros.
 #

[Seth Vidal]

Tom,
 Please send this patch up to rpm-maint(a)rpm.org - I think that's a
better place for patches to rpm.

thanks,
-sv

[Tom Lane]

seth vidal <skvidal(a)fedoraproject.org&gt; writes:
>  Tom,
>   Please send this patch up to rpm-maint(a)rpm.org - I think that's a
>  better place for patches to rpm. 
I filed it here:
https://bugzilla.redhat.com/show_bug.cgi?id=456636
Do you think additional nagging is required?

The only reason I sent it to fedora-devel-list was I thought some other
people might want the patch right away.  I've just been going through my
own packages using a locally patched rpm ...

			regards, tom lane