Matthew Burgess <[EMAIL PROTECTED]> 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. > 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? > 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. > 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
