On Fri, Dec 19, 2003 at 03:35:15PM +0700, John Francis Lee wrote:
> Hello,
>
> I had the 2.4.22 kernel source so I just downloaded the patch to 2.4.23.
>
> I applied the patch-2.4.23 to the linux-2.4.22 source tree, renamed it
> to linux-2.4.23 and made a symbolic link to linux, then applied the
> 2.4.23 owl patch, which went ok, followed by patch-2.2.23-vs1.22 .diff,
> with results below.
>
> [EMAIL PROTECTED] src]# patch -p0 < patch-2.4.23-vs1.22.diff
> patching file linux-2.4.23/Makefile
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file
> linux-2.4.23/Makefile.rej
> patching file linux-2.4.23/fs/exec.c
> Hunk #1 succeeded at 737 (offset 8 lines).
> patching file linux-2.4.23/fs/namei.c
> Hunk #1 succeeded at 23 (offset 1 line).
> Hunk #3 succeeded at 174 (offset 1 line).
> Hunk #4 succeeded at 955 (offset 41 lines).
> Hunk #5 succeeded at 1685 (offset 58 lines).
> patching file linux-2.4.23/fs/proc/base.c
> Hunk #1 succeeded at 1083 (offset 5 lines).
> Hunk #2 succeeded at 1096 (offset 4 lines).
> Hunk #3 succeeded at 1132 (offset 5 lines).
> patching file linux-2.4.23/include/linux/sched.h
> Hunk #5 succeeded at 521 (offset 2 lines).
> patching file linux-2.4.23/kernel/exit.c
> Hunk #2 succeeded at 70 (offset 3 lines).
> Hunk #4 succeeded at 185 (offset 3 lines).
> patching file linux-2.4.23/kernel/sysctl.c
> Hunk #4 succeeded at 421 (offset 3 lines).
>
> The rejected hunk seems just to have been versioning information which
> failed because the version was already extended by "-owl". I extended it
> by hand to "-owl-vs1.22".
>
> I'm pretty sure that's ok.
me too ... unless the owl patch interferes with
vserver business in some nasty way, compiling it
is the first step into finding out ;)
> What about those offsets?
it just means, that the owl patch inserted (or
removed) some lines before the lines patched by
the vs patch, so the 'location' of the 'hunk'
was moved a little (or somewhat, as in namei)
'down' in the 'original' file ...
with patching, there are different 'levels' ...
1) no message
hunk applied exactly as expected
2) Hunk #<m> succeeded at <l> (offset <o> lines).
the hunk <m> applied without issues, but
at line <l> which was <o> lines 'below'
the expected location
3) Hunk #<m> succeeded at <l> with fuzz <f> (offset <o> lines).
the hunk <m> applied at line <l>, <o> lines
below the expected location, but only after
removing <f> lines of 'context'
4) Hunk #<m> FAILED at <l>.
the hunk <m> expected to apply at line <l>
just didn't apply
5) Reversed (or previously applied) patch detected!
it seems like this hunk has already been
applied to the 'original'
1) is perfect, usually you don't have to think
twice about 2), 3) depends on the value of <f>
(unified diffs usually have 3 lines of context,
so <f>=1 means only 2 lines, <f>=2 means just
one line of context), 4) means it wasn't applied
and 5) means it looks like it's already there
HTH,
Herbert
> Thanks for your help.
>
> --
> John Francis Lee <[EMAIL PROTECTED]>
>
> _______________________________________________
> Vserver mailing list
> [EMAIL PROTECTED]
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
