On Thu, 22 Dec 2011, Michal Suchanek wrote:
> Building a quilt (3.0) package with fuzzy patch fails although quilt
> aplies and unapplies the patch just fine.

This is normal and not really a bug. We really want patches that apply
without fuzz. Otherwise there are too many risks of misapplied patches.

> Worse, the package source may be broken by dpkg-buildpackage. It looks
> like the patch is applied but not recorded as applied by quilt in the
> end.

This is worthy of investigation. But I don't really

[ All patches applied ]
> $ dpkg-buildpackage -j6
[...]
>  dpkg-source -b qemu-kvm-0.15.1+dfsg
> dpkg-source: info: using source format `3.0 (quilt)'
> dpkg-source: info: building qemu-kvm using existing 
> ./qemu-kvm_0.15.1+dfsg.orig.tar.gz
> patching file hw/isa.h
> Hunk #1 succeeded at 36 (offset 1 line).
> patching file hw/pckbd.c
> patching file vl.c
> Hunk #1 FAILED at 2179.
> 1 out of 1 hunk FAILED -- saving rejects to file vl.c.rej
> patching file qemu-options.hx
> Hunk #1 succeeded at 2451 (offset 85 lines).
> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B 
> .pc/nops2.patch/ < 
> qemu-kvm-0.15.1+dfsg.orig.2OmAtg/debian/patches/nops2.patch gav
> e error exit status 1
> dpkg-buildpackage: error: dpkg-source -b qemu-kvm-0.15.1+dfsg gave error exit 
> status 2

Since all patches were already applied, the failure happens when
dpkg-source tries to apply patches to the pristine copy unpacked in a
temporary directory. So it can't really mess up with your source package.

So it's to be expected that "quilt pop -a" works as usual:
> $ quilt pop -a
> Removing patch debian/patches/nops2.patch
[...]
> No patches applied

But now if you run it with patches unapplied, dpkg-source --before-build
will try to apply them:
> $ dpkg-buildpackage -j6
[...]
>  dpkg-source --before-build qemu-kvm-0.15.1+dfsg
> dpkg-source: info: patches are not applied, applying them now
> dpkg-source: info: applying 02_use_usr_share_kvm_fixed.patch
> dpkg-source: info: applying 03_use_etc_kvm_not_etc_qemu.patch
> dpkg-source: info: applying 04_use_etc_kvm_kvm-ifup.patch
> dpkg-source: info: applying 05_report_debian_package_version.patch
> dpkg-source: info: applying 
> build-move-QEMU_INCLUDES-before-QEMU_CFLAGS-76dc3cf82c.diff
> dpkg-source: info: applying 
> scsi-disk-commonize-iovec-creation-between-reads-and-writes-103b40f51e-CVE-2011-3346.diff
> dpkg-source: info: applying 
> scsi-disk-lazily-allocate-bounce-buffer-7285477ab1-CVE-2011-3346.diff
> dpkg-source: info: applying nops2.patch
> patching file hw/isa.h
> Hunk #1 succeeded at 36 (offset 1 line).
> patching file hw/pckbd.c
> patching file vl.c
> Hunk #1 FAILED at 2179.
> 1 out of 1 hunk FAILED -- saving rejects to file vl.c.rej
> patching file qemu-options.hx
> Hunk #1 succeeded at 2451 (offset 85 lines).
> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B 
> .pc/nops2.patch/ < qemu-kvm-0.15.1+dfsg/debian/patches/nops2.patch gave error 
> exit
>  status 1
> dpkg-buildpackage: error: dpkg-source --before-build qemu-kvm-0.15.1+dfsg 
> gave error exit status 1

So apparently at this point, despite the failure, patch modified several
files and will not undo those changes. The correct thing to do would then
be to restore the files from .pc/nops2.patch/ so that we're back to the
initial state before we tried to apply this patch (and then clean up that
directory too).

FWIW that's what quilt is doing (with the help of its backup-files
script).

Another approach could be to --dry-run the patch first but that would be
too expensive and would impact everybody.

Yet another idea would be to re-apply the patch with the -R option. It
would drop the changes already applied (and fail again due to the changes
that failed to apply). This is probably easier to implement than the
restore from .pc/nops2.patch/ but not very clean.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to