Re: chown --no-dereference broken in coreutils 6.3 ?

Matthew Burgess <[EMAIL PROTECTED]> wrote: > Theodoros V. Kalamatianos wrote: >> So glibc-2.5 does not have this issue ? > > I've just run a build against glibc-2.5 (vanilla upstream sources) and > not seen any test failures. This is running under Ubuntu's > linux-2.6.15-27 kernel, in case it's a

[bug #11004] Results of "sort" fail "sort -c" check if LANG is set and memory is low

Follow-up Comment #5, bug #11004 (project coreutils): The bug still exists with glibc 2.3.6 and coreutils 5.97. ___ Reply to this item at: ___ Message

cp or join: how to join binary splits?

hi! I don't know if it's my lack of unix/linux console commands knowledge, but an equivalent from the msdos 'copy /b joined.bin + splited.025' is missing - i typed 'man cp' and 'info cp' and i got no suficient information about it. As well i thaugh the 'join' command as reverse of 'split' could

Re: cp or join: how to join binary splits?

[EMAIL PROTECTED] writes: > I don't know if it's my lack of unix/linux console commands knowledge, but an > equivalent from the msdos 'copy /b joined.bin + splited.025' is missing It's called cat. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße

Re: cp or join: how to join binary splits?

cat splited.* > joined.bin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize > 4MB

On Tue, Oct 03, 2006 at 03:42:30PM -0700, Paul Eggert wrote: > The GNU philosophy is to avoid arbitrary limits, so I installed the > following patch, in an attempt to do a minimal sort of sanity check > (catching the HP-UX bug, I hope) while not overly constraining > st_blksize. Thank you.

[bug #17908] 'configure' fails because it is unable to determine how to read the mount table.

Follow-up Comment #2, bug #17908 (project coreutils): Yes, that would be the ideal, but until someone (maybe me, maybe not me) figures that out, is it not better to at least build the rest of coreutils without having to hand-edit configure and Makefile's?

NSK(OSS) compilation problem

I have a problem building on Tandem/NSK OSS; specifically, uintmax_t (unsigned long long) is not a valid data type (don't ask me why!). I am thinking about changing this to 'long long', but before I do that can anyone comment on what potential problems that might cause? Would it be better to ch

coreutils-6.3 on MacOS X

On Darwin-7.9.0 with CPPFLAGS=-Wall: Builds fine. All tests pass. The "rm -rf" HFS+ bug workaround works fine. The "rm -rf" hardlinks / NFS bug is still open. The following warnings were seen: In file included from openat.c:285: at-func.c: In function `fchownat': at-func.c:39: warning: implicit d

coreutils-6.3 on Linux 2.4 kernel

Hi, Machine: Linux linuix 2.4.21-99-default #1 Wed Sep 24 13:30:51 UTC 2003 i686 GNU/Linux Results: Two tests fail 1) dd/misc fails: kernel does not support NOATIME (already reported). 2) ls/stat-dtype fails: out exp differ: char 2, line 1 1c1 < s --- > s@ out exp differ: char 6, line 1 1c1 <

[bug #11004] Results of "sort" fail "sort -c" check if LANG is set and memory is low

Update of bug #11004 (project coreutils): Open/Closed: Closed => Open ___ Follow-up Comment #6: I looked at the bug again, and now I think I understand it better. You're calling "sort" twi

Re: make check "failure" on Itanium HPUX

Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: Jim Meyering wrote: mwoehlke <[EMAIL PROTECTED]> wrote: mwoehlke wrote: This is a little odd... 'make' exits non-zero when doing 'make check' (help-version) on Itanium Linux, but the tests all seem to pass. Here is the relevant verbose o

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

mwoehlke <[EMAIL PROTECTED]> writes: > things went badly until I removed the #define for > intmax_t from config.h. That's not a good sign. In what way did they go badly, exactly? What diagnostics did you get? > shuf builds, but the linker complains about 'ftello unresolved', and > then *produc

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

mwoehlke <[EMAIL PROTECTED]> writes: > shuf builds, but the linker complains about 'ftello unresolved', and > then *produces a file* (but without +x), with the result that 'make' > then thinks it has nothing to do to for target 'shuf' and continues on > to "success" if re-run. I installed this pa

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

mwoehlke <[EMAIL PROTECTED]> writes: > ...is anyone else trying to build on Tru64? I'm using 4.0G to build, > and I have a LOT of problems. Yes, people build coreutils on Tru64, though 4.0G (released 2000-05) is getting a bit old. Have you applied all the relevant patches? See

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: shuf builds, but the linker complains about 'ftello unresolved', and then *produces a file* (but without +x), with the result that 'make' then thinks it has nothing to do to for target 'shuf' and continues on to "success" if re-run. I in

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: ...is anyone else trying to build on Tru64? I'm using 4.0G to build, and I have a LOT of problems. Yes, people build coreutils on Tru64, though 4.0G (released 2000-05) is getting a bit old. Have you applied all the relevant patches? See

Re: coreutils-6.3: spurious stat_dtype failure

On Tue, 3 Oct 2006, you wrote: > I'm not surprised. > I was counting on someone like you to tell me how to > perform the check reliably :-) I don't think it's possible. The best you could do is create a special shim C program just to check if those files return DT_UNKNOWN. > > Also, I understand

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

Paul Eggert wrote: mwoehlke <[EMAIL PROTECTED]> writes: things went badly until I removed the #define for intmax_t from config.h. That's not a good sign. In what way did they go badly, exactly? What diagnostics did you get? source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \