Bug 677685 - .orig file appears in the directory while it shouldn't
.orig file appears in the directory while it shouldn't
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: patch (Show other bugs)
rawhide
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 678000 678016
  Show dependency treegraph
 
Reported: 2011-02-15 10:32 EST by Vít Ondruch
Modified: 2011-02-16 09:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 678016 (view as bug list)
Environment:
Last Closed: 2011-02-16 08:00:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Vít Ondruch 2011-02-15 10:32:21 EST
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 10:33:26 EST
Created attachment 478893 [details]
Reproducer
Comment 2 Tim Waugh 2011-02-15 11:05:42 EST
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 11:06:10 EST
Does the reproducer fail for you?
Comment 4 Vít Ondruch 2011-02-15 13:06:26 EST
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 13:08:10 EST
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 07:22:12 EST
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 08:00:12 EST
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 08:27:43 EST
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.