User-Agent: Mozilla/5.0 (U; en-US) Gecko Firefox if I use "bzip2 -dc patch.bz2 | patch -p1" or any other way I use patch it always uses the -b option and creates *.orig files. This breaks for example the build process with rpmbuild as diff's from a dir where I have used the command above to patch something include the *.orig files. Applying the first part of a given .patch file by rpmbuild also creates a *.orig file and as the diff also included a new *.orig file an error is displayed and rpmbuild fails. Reproducible: Always Steps to Reproduce: 1. patch some file in some dir (not using the -b option from patch) 2. list dir, observe if "file.orig"-file is present Actual Results: "file.orig"-file is present Expected Results: "file.orig"-file is not present
packet version is: patch-2.5.4-35.fc10 (i386)
I can't reproduce this. Here's the test I tried: echo b > a echo a > a.orig diff -u a.orig a > a.patch rm -f a.orig echo a > a patch a -i a.patch ls
inside kernel-source (from current kernel-package) ls arch/x86/kernel/cpu/cpufreq/ | grep acpi Output: acpi-cpufreq.c bzip2 -dc ../../patches/linux-phc-0.3.2-kernel-vanilla-2.6.26.patch.bz2 | patch -p1 Output: patching file arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c Output: Hunk #4 succeeded at 751 (offset 1 line). ls arch/x86/kernel/cpu/cpufreq/ | grep acpi Output: acpi-cpufreq.c Output: acpi-cpufreq.c.orig You are right, 'always' in an overstatement, but maybe some patches with offsets? There seems no way of disabling the .orig-file creation (which I am aware of), so I manually have to remove it. Worked with Fedora 10 without any updates. kernel-2.6.27.21-170.2.56.fc10.src.rpm Patch from http://www.linux-phc.org/
Even a new patch with no offset creates the same thing. ls arch/x86/kernel/cpu/cpufreq/ | grep acpi Output: acpi-cpufreq.c cat ../../patches/linux-2.6-phc.patch | patch -p1 Output: patching file arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c ls arch/x86/kernel/cpu/cpufreq/ | grep acpi Output: acpi-cpufreq.c Output: acpi-cpufreq.c.orig using patch -p1 <../../patches/linux-2.6-phc.patch works as expected. Maybe my syntax is wrong...
Rather than using one of the largest RPM packages in the distribution, please try to construct a small test case that demonstrates the problem you are seeing.
I am sorry. The described way is the one where I noticed it at first. It must be some problem only invoked by all patches I tried and derivatives of them, as I can't create any test case which is 'small' from scratch. What ever is causing this drives me crazy. I'am going to create a script which removes all the *.orig files and don't bother you anymore until I can come up with a simple test case.
(In reply to comment #6) > I am sorry. The described way is the one where I noticed it at first. > > It must be some problem only invoked by all patches I tried and derivatives of > them, as I can't create any test case which is 'small' from scratch. Incomplete Lines? (http://www.network-theory.co.uk/docs/diff/Incomplete_Lines.html) I can reproduce this: $ echo -e "firstline\nsecondline" > a $ echo -e "firstline\nsecondline\nthirdline" > b $ diff -u a b > ab.patch $ ls a ab.patch b $ echo -en "firstline\nsecondline" > a1 $ patch a1 -i ab.patch $ ls a a1 a1.orig ab.patch b
That is correct and I am now able to fix the affected patches. Thank you. In my opinion patch shouldn't leave the *.orig file, even if the patch doesn't end with a new line, as long as it applies without errors.
This is a case of the context not matching. Use the --no-backup-if-mismatch option if you don't want this POSIX behaviour.