Dave disabled utrace because sched-cfs has a line that conflicts. It only
conflicts under -F1, and with default patching (-F2) utrace applies fine
after sched-cfs. This tweak to the spec file''s ApplyPatch makes it
easy to
make one patch use -F2 when you need it, instead of disabling a patch
because of a conflict that patch resolves just fine.
Thanks,
Roland
--- kernel-2.6.spec 21 Jun 2007 23:20:46 -0700 1.3233
+++ kernel-2.6.spec 21 Jun 2007 23:49:07 -0700
@@ -889,13 +890,15 @@ cd linux-%{kversion}.%{_target_cpu}
patch_command=''patch -p1 -F1 -s''
ApplyPatch()
{
- if [ ! -f $RPM_SOURCE_DIR/$1 ]; then
+ local patch=$1
+ shift
+ if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
exit 1;
fi
- case "$1" in
- *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$1" | $patch_command ;;
- *.gz) gunzip < "$RPM_SOURCE_DIR/$1" | $patch_command ;;
- *) $patch_command < "$RPM_SOURCE_DIR/$1" ;;
+ case "$patch" in
+ *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command
${1+"$@"} ;;
+ *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command
${1+"$@"} ;;
+ *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch"
;;
esac
}
@@ -914,9 +917,9 @@ ApplyPatch patch-2.6.22-rc5-git4.bz2
ApplyPatch linux-2.6-sched-cfs.patch
# Roland''s utrace ptrace replacement.
-#ApplyPatch linux-2.6-utrace.patch
-# setuid /proc/self/maps fix. (dependant on utrace)
-#ApplyPatch linux-2.6-proc-self-maps-fix.patch
+ApplyPatch linux-2.6-utrace.patch -F2
+# setuid /proc/self/maps fix. (dependent on utrace)
+ApplyPatch linux-2.6-proc-self-maps-fix.patch
# Nouveau DRM
#ApplyPatch nouveau-drm.patch
On Thu, Jun 21, 2007 at 11:56:26PM -0700, Roland McGrath wrote: > Dave disabled utrace because sched-cfs has a line that conflicts. It only > conflicts under -F1, and with default patching (-F2) utrace applies fine > after sched-cfs. This tweak to the spec file''s ApplyPatch makes it easy to > make one patch use -F2 when you need it, instead of disabling a patch > because of a conflict that patch resolves just fine. I''ll give this a begruding ''ok''. With luck cfs will be going upstream soon anyway, so we can then rediff utrace against it. (And if it isn''t upstream by 2.6.23, we''ll need to drop it, or at least neuter it''s addition of a syscall) Dave -- http://www.codemonkey.org.uk