6.8 patch tweaks.

Rob Landley rob at landley.net
Fri Jul 8 20:54:22 PDT 2011

On 07/08/2011 11:00 AM, Bruce Dubbs wrote:
>> 2) rm "$SRCDIR"/procps-3.2.8-fix_HZ_errors-1.patch || exit 1
>> The path has a "//" which means -p1 winds up with an absolute path after
>> discarding one "/".
> I'm not sure what you mean here with the 'rm ... |exit 1', but the patch 
> applies cleanly for me:

Sorry, a cut and paste from my build script which I forgot to clean up.

I mean that the patch contains this:

diff -Naurp procps-3.2.8-orig//proc/sysinfo.c procps-3.2.8//proc/sysinfo.c
--- procps-3.2.8-orig//proc/sysinfo.c   2008-03-23 23:33:43.000000000 -0500
+++ procps-3.2.8//proc/sysinfo.c        2010-09-20 01:13:36.000000000 -0500

Note the double slash.  Busybox patch when told to "-p1" that path
removes the first slash, and then tries to patch /proc/sysinfo.c at an
absolute path.

Gnu patch (being larger and more complicated) has an extra check for
multiple consecutive slashes.

What the standard requires depends on what "path component" means...
(Rummage, rummage...)


Ok, bug in busybox I should fix.  Still, the patch doesn't need two
consecutive slashes in it triggering this bug in the current busybox
release version.

> $ patch -Np1 -i ../procps-3.2.8-fix_HZ_errors-1.patch
> patching file proc/sysinfo.c
> $
> I can fix that, but since you are deviating from the book (vii. Host 
> System Requirements),

I keep meaning to write an "Embedded Linux From Scratch".  The smallest
system capable of rebuilding itself under itself is 7 packages (busybox,
uClibc, binutils, gcc, bash, make, and linux).  I had to extend busybox
significantly to make that work, but it does now.  (Admittedly that's
using the last GPLv2 releases of binutils and gcc, 2.17 and 4.2.1.  The
current versions are written in C++ and spilled some of their internal
components into three or four more packages.  GNU code has always been
subject to Gates' law...)

> it is not a high priority.  You could edit the 
> patch file manually or use a sed on it.

Right now I'm just deleting it (hence the "rm" above).  It isn't fixing
a bug I've actually hit, and if it was important it would presumably be
fixed in procps upstream.



More information about the lfs-dev mailing list