Re: make-kpkg and kernel patches
After reading the fine source I can now answer some, but not all, of my
questions. I understand more about why it's failing, but don't know how
to make it work right or diagnose the failures (well, I probably could
diagnose them by untarring the patch file and comparing it to the
target, though that seems awkward).
make-kpkg provides some pre-processing around the standard invocation of
debian/rules. That file does the patching during its macro scan. It
looks in several places, with a representative one like this:
if [ -n "$(ALL_PATCH_DIR)" -a \
-d $(ALL_PATCH_APPLY) ]; then \
run-parts --exit-on-error $(ALL_PATCH_APPLY); \
(cd $(ALL_PATCH_APPLY); ls -1) >> applied_patches;\
echo done > stamp-patch; \
On Fri, 2003-12-12 at 12:45, Ross Boylan wrote:
> I am trying to apply kernel patches with make-kpkg, but am running into
> difficulties, particularly on repeated runs.
>
> First, I am not able to find the .rej files when patches fail to apply.
> I thought this might have been from a subsequent make-kpkg clean, but
> even without that, they're not there. Are these automatically cleaned
> out? If so, how can I diagnose problems applying patches?
The invoked patch file says
patch --force --dry-run $PATCH_OPTIONS -p$STRIPLEVEL
--dry-run doesn't touch any files. Presumably this includes not
generating the .rej files.
>
> Second, the patches that apply on later runs differ from those on
> earlier runs, as well as the success of the patches. My preliminary
> theory is that as soon as make-kpkg has an error while applying a patch,
> it abandons attempting to apply all subsequent patches. Is that
> correct?
Yes. The makefile snippet at the top says --exit-on-error, so it gives
up on the first failure.
Why it's not the same on the later runs is less clear. There appear to
be mechanisms for removing patches and tracking which patches have been
applied; none of them seem to help.
>
> Here's an example, starting in new, just untarred directory (2.4.21):
> export PATCH_THE_KERNEL=YES
> make-kpkg --rootcmd fakeroot --revision rb.1 --append-to-version advncd
> configure
> results include
> ------------------------------------
> START applying patch "Debian Logo"
> Testing whether "Debian Logo" patch for 2.4.21 applies (dry run):
> "Debian Logo" patch for 2.4.21 succeeded
> Removing empty files after patching:
> Done.
> END applying patch "Debian Logo"
> START applying patch "Linux device-mapper"
> Testing whether "Linux device-mapper" patch for 2.4.21 applies (dry
> run):
> 1 out of 2 hunks FAILED -- saving rejects to file mm/filemap.c.rej
> "Linux device-mapper" patch for 2.4.21 does not apply cleanly
> run-parts: /usr/src/kernel-patches/all//apply/device-mapper exited with
> return code 1
> ---------------------------------
> make-kpkg --rootcmd fakeroot --revision rb.1 --append-to-version
> advncd clean
> make-kpkg --rootcmd fakeroot --revision rb.1 --append-to-version advncd
> configure
> output is now
> ----------------------------------------------
> START applying patch "Debian Logo"
> Testing whether "Debian Logo" patch for 2.4.21 applies (dry run):
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/video/fbcon.c.rej
> 1 out of 1 hunk FAILED -- saving rejects to file
> include/linux/linux_logo.h.rej
> "Debian Logo" patch for 2.4.21 does not apply cleanly
> run-parts: /usr/src/kernel-patches/all//apply/debianlogo exited with
> return code 1
> ------------------------------------------
> This time I looked for the .rej file before cleaning, but it still
> wasn't there.
>
> My guess is that the previous application of the patch is still in
> place, causing the 2nd patch attempt to fail.
>
> So what's going on? And what's the right way to do repeated make-kpkg
> runs in the presence of kernel patches?
>
> Thanks.
--
Ross Boylan wk: (415) 502-4031
530 Parnassus Avenue (Library) rm 115-4 ross@biostat.ucsf.edu
Dept of Epidemiology and Biostatistics fax: (415) 476-9856
University of California, San Francisco
San Francisco, CA 94143-0840 hm: (415) 550-1062
Reply to: