Bug 677685 - .orig file appears in the directory while it shouldn't
Summary: .orig file appears in the directory while it shouldn't
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: patch
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 678000 678016
TreeView+ depends on / blocked
 
Reported: 2011-02-15 15:32 UTC by Vít Ondruch
Modified: 2011-02-16 14:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 678016 (view as bug list)
Environment:
Last Closed: 2011-02-16 13:00:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Reproducer (2.06 KB, application/octet-stream)
2011-02-15 15:33 UTC, Vít Ondruch
no flags Details
patch-reproducer.tar.gz (but works for me) (2.41 KB, application/x-gzip)
2011-02-15 16:05 UTC, Tim Waugh
no flags Details
script executed by rpmbuild (3.44 KB, application/octet-stream)
2011-02-15 18:08 UTC, Vít Ondruch
no flags Details
Valid reproducer (2.43 KB, application/x-gzip)
2011-02-16 12:22 UTC, Vít Ondruch
no flags Details

Description Vít Ondruch 2011-02-15 15:32:21 UTC
Description of problem:
Koji build of rubygem-actionpack fails while it worked week ago:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2841403
http://koji.fedoraproject.org/koji/buildinfo?buildID=225223

Version-Release number of selected component (if applicable):
mock-chroot> cat /etc/redhat-release 
Fedora release 15 (Rawhide)
mock-chroot> rpm -q patch
patch-2.6.1-8.fc15.x86_64



How reproducible:
mock -r fedora-x86_64 ../SRPMS/rubygem-actionpack-3.0.3-3.fc14.src.rpm


mock-chroot> ls specifications/
actionpack-3.0.3.gemspec
mock-chroot> /usr/bin/patch -s -p0 --fuzz=0 < /builddir/build/SOURCES/actionpack-downgrade-dependencies.patch
mock-chroot> ls specifications/
actionpack-3.0.3.gemspec  actionpack-3.0.3.gemspec.orig

Comment 1 Vít Ondruch 2011-02-15 15:33:26 UTC
Created attachment 478893 [details]
Reproducer

Comment 2 Tim Waugh 2011-02-15 16:05:42 UTC
Created attachment 478903 [details]
patch-reproducer.tar.gz (but works for me)

I can't reproduce this.

patch-2.6.1-8.fc15.x86_64

Attached is the complete reproducer I tried (not just the patch: the patch, the file, and the invocation).

I obtained the file to patch by adding "exit 1" before "%patch3 -p0" in the spec file before running 'fedpkg prep'.

Backup files are written when the patch did not match the file exactly (see the --backup-if-mismatch option).

Comment 3 Tim Waugh 2011-02-15 16:06:10 UTC
Does the reproducer fail for you?

Comment 4 Vít Ondruch 2011-02-15 18:06:26 UTC
Unfortunately I cannot reproduce it using your reproducer. While I can reproduce it always using "mock -r fedora-rawhide-x86_64 rubygem-actionpack-3.0.3-3.fc15.src.rpm". 

Not sure where is the problem :( I have tried to export the environment right after the failure if it helps:

+ test -f specifications/actionpack-3.0.3.gemspec.orig
+ echo PASS: no .orig file
PASS: no .orig file
+ echo 'Patch #3 (actionpack-downgrade-dependencies.patch):'
Patch #3 (actionpack-downgrade-dependencies.patch):
+ /bin/cat /builddir/build/SOURCES/actionpack-downgrade-dependencies.patch
+ /usr/bin/patch -s -p0 --fuzz=0
+ test -f specifications/actionpack-3.0.3.gemspec.orig
+ echo FAIL: .orig file present
FAIL: .orig file present
+ ls -lZ specifications/
-rw-r--r--. root root unconfined_u:object_r:mock_var_lib_t:s0 actionpack-3.0.3.gemspec
-rw-r--r--. root root unconfined_u:object_r:mock_var_lib_t:s0 actionpack-3.0.3.gemspec.orig
+ export
export HOME="/builddir"
export LANG="C"
export LOGNAME="root"
export OLDPWD="/builddir/build/BUILD/rubygem-actionpack-3.0.3"
export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/root/bin"
export PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/share/pkgconfig"
export PWD="/builddir/build/BUILD/rubygem-actionpack-3.0.3/usr/lib/ruby/gems/1.8"
export RPM_ARCH="x86_64"
export RPM_BUILD_DIR="/builddir/build/BUILD"
export RPM_BUILD_ROOT="/builddir/build/BUILDROOT/rubygem-actionpack-3.0.3-3.fc16.x86_64"
export RPM_DOC_DIR="/usr/share/doc"
export RPM_OPT_FLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic"
export RPM_OS="linux"
export RPM_PACKAGE_NAME="rubygem-actionpack"
export RPM_PACKAGE_RELEASE="3.fc16"
export RPM_PACKAGE_VERSION="3.0.3"
export RPM_SOURCE_DIR="/builddir/build/SOURCES"
export SHELL="/bin/sh"
export SHLVL="3"
export TERM="xterm"
export USER="root"
export USERHELPER_UID="501"
+ exit 1

Comment 5 Vít Ondruch 2011-02-15 18:08:10 UTC
Created attachment 478942 [details]
script executed by rpmbuild

The attached script is the script which is executing the rpmbuild to build the package if it may help.

Comment 6 Vít Ondruch 2011-02-16 12:22:12 UTC
Created attachment 479092 [details]
Valid reproducer

I found the difference. There was introduced RubyGems 1.5 into F15/Rawhide which produced a little bit different .gemspec file. There is missing "current_version = Gem::Specification::CURRENT_SPECIFICATION_VERSION" line. So the truth is that the patch doesn't apply cleanly. 

However, there is not error message nor anything else (except the .orig file) which would point that out. Is that intentional? Shouldn't be there some warning at least? It would make life easier IMO.

Comment 7 Tim Waugh 2011-02-16 13:00:12 UTC
rpmbuild deliberately stops patch from telling us this by passing the '-s' flag...

Taking out the '-s' from runme.sh gives this output:

$ ./runme.sh 
patching file specifications/actionpack-3.0.3.gemspec
Hunk #1 succeeded at 26 (offset -1 lines).
FAIL: .orig file present

That "(offset ... lines)" message is the clue that the patch doesn't match the file exactly.

So yes, this is all intentional, but obviously can lead to a confusing situation if the presence of a backup file causes a problem.

One solution might be for rpmbuild to tell patch not to create backup files in this situation by using the --no-backup-if-mismatch option; another might be for it to omit the -s option.

Comment 8 Vít Ondruch 2011-02-16 13:27:43 UTC
Tim, thank you for your help. I have created #678000 for rpmdevtools to fix
this issue.


Note You need to log in before you can comment on or make changes to this bug.