Re: Building coreutils in Linux From Scratch

[Matthew Burgess]

Paul Eggert wrote:
> Matthew Burgess <address@hidden> writes:
>
> > http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-uname-1.patch
> > What would be the preferred method of seeing the -i and -p flags of
> > uname produce correct output on x86-linux machines?  I'm assuming it
> > needs either kernel or glibc cooperation?
>
> Yes, that's the idea.  Partly because we don't want to have to
> maintain the "major hack", but more because this info really
> belongs in the kernel or C library, not in application code.  We
> don't much care which syscall does the job (as you can see from
> the existing uname.c), so long as some syscall does it.

OK, I guessed as much.  Unfortunately I'm not a kernel or libc hacker, 
nor do I play one on TV  :-)   I've taken a look at the patch Mike 
Frysinger pointed me to, and it looks at least a little more sane, so 
I'll propose to the LFS community that we use that one instead, for the 
time being anyway.

> > http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-suppress_uptime_kill_su-1.patch
> > prevents `uptime', `kill' and `su' from being installed as we use
> > binaries from the procps and shadow packages instead.  As this is
> > specific to LFS, I won't propose that GNU Coreutils apply it upstream
>
> OK.  For 'su' I understand -- we've been toying with the idea of
> removing it from coreutils -- but why is this the case for uptime
> and kill?  What features are in procps uptime and kill that are
> not in coreutils?

Both versions of kill and uptime offer the same features.  There is a 
minor incompatibility in that `kill -t` in coreutils maps to `kill -L` 
in procps.  The main reason we suppress their installation is so that if 
folks decide to upgrade either procps or coreutils, they're guaranteed 
to run the binaries from the package we expect them to be provided by. 
This obviously makes resolving problem reports easier as we won't go 
around chasing our tails looking for a bug in procps' `kill' when it's 
actually in coreutils implementation (or vice versa, of course).

We could just as easily patch procps to prevent it from installing its 
versions of those two programs, but as we're preventing installation of 
`su' as it is, it made sense to suppress coreutils kill and uptime in 
the same patch.

> > http://www.linuxfromscratch.org/patches/lfs/development/coreutils-5.97-i18n-1.patch
> > fixes a number of issues related to using the Coreutils binaries in
> > multibyte locales.  Although the patch header states that this patch
> > has been rejected by yourselves before, it also states that the fixes
> > it provides are planned for 6.0.  As the patch largely applied as-is
> > to 6.1, and I couldn't see anything relevant in NEWS, I'm assuming
> > those fixes haven't made it in yet?
>
> That's right.  The intent is to support it eventually, but those
> patches head in the wrong direction.  They're incomplete, and
> don't fix many commonly-used programs like 'ls'.  And they make
> the code significantly harder to maintain.

Is there anything I can do to help out with regard to this?  Would you 
accept patches that add i18n related testcases, which XFAIL for the time 
being?

> > We also perform `sed -i 's/_LEN 6/_LEN 20/' src/who.c` with the
> > following explanation:
> >
> > "It has been found that translated messages sometimes overflow a
> > buffer in the who -Hu  command."
> >
> > If I've understood the source correctly, the buffer overflow can occur
> > in several locales because of the translation of " old ".
>
> That's an old bug, and was fixed a while back, by this:
>
>     sprintf (idlestr, "%.*s", IDLESTR_LEN, idle_string (last_change, boottime));
>
> So no matter how long " old " is translated to, the sprintf
> truncates it after IDLESTR_LEN bytes.

Fantastic, thanks for that (and also to Mike for pointing the same thing 
out).  I'll remove that sed from the book.

Thanks,

Matt.

PS: Apologies to Paul, who received a private reply earlier today!