Re: [coreutils] Re: [PATCH 2/2] stat: print timestamps to full resolution

Jim Meyering wrote: > Eric Blake wrote: > >> On 10/21/2010 08:09 AM, Andreas Schwab wrote: >>> Eric Blake writes: >>> >>>> On 10/21/2010 03:22 AM, Andreas Schwab wrote: >>>>> >>>>> >>>>> Jim Meyering

Re: [coreutils] Re: [PATCH 2/2] stat: print timestamps to full resolution

Eric Blake wrote: > On 10/21/2010 09:33 AM, Jim Meyering wrote: >>> Then, to get full seconds.nanoseconds, you'd use a format like %X.%:X >>> and if you want only milliseconds, you'd use %X.%3.3:X >> >> Oops. >> I forgot to zero-pad. Otherwise, w

Re: [coreutils] Re: [PATCH 2/2] stat: print timestamps to full resolution

Jim Meyering wrote: > Jim Meyering wrote: > >> Eric Blake wrote: >> >>> On 10/21/2010 08:09 AM, Andreas Schwab wrote: >>>> Eric Blake writes: >>>> >>>>> On 10/21/2010 03:22 AM, Andreas Schwab wrote: >>>>>>

[coreutils] Re: crtime on ext4 or ntfs

Vincent GACOUGNOLLE wrote: > Sorry if I am wrong, I am a new-by. > > I am looking for core utils manipulating crtime on ext4 and ntfs. > > In a large vision, I would like get from coreutils the ability to use new > file attributes we can found on modern FS like ext4 and ntfs. > > After seen sources

[coreutils] stat: reverting recent %X %Y %Z change

Part of reverting this change: stat now outputs the full sub-second resolution for the atime, mtime, and ctime values since the Epoch, when using the %X, %Y, and %Z directives of the --format option. This matches the fact that %x, %y, and %z were already doing so for the human-rea

[coreutils] Re: [PATCH] du: don't print junk when diagnosing out-of-range time stamps

Paul Eggert wrote: > While looking into the inttostr issues circulated recently on > bug-gnulib, I was experimenting with an inttostr variant that I hope > will be nicer. In the process, I discovered a bug in du, where du > uses uninitialized storage. Here's a patch. Good catch! > The tabs in t

Re: [coreutils] stat: reverting recent %X %Y %Z change

Pádraig Brady wrote: > On 22/10/10 18:43, Jim Meyering wrote: >> Part of reverting this change: >> >> stat now outputs the full sub-second resolution for the atime, >> mtime, and ctime values since the Epoch, when using the %X, %Y, and >> %Z directi

Re: [coreutils] stat: reverting recent %X %Y %Z change

Jim Meyering wrote: > Pádraig Brady wrote: >> On 22/10/10 18:43, Jim Meyering wrote: >>> Part of reverting this change: >>> >>> stat now outputs the full sub-second resolution for the atime, >>> mtime, and ctime values since the Epoch, when u

Re: [coreutils] [PATCH] truncate: fix a very unlikely case for undiagnosed errors

Pádraig Brady wrote: > The attached is more to suppress any errors from > possible future static analysis, than for any > practical reason. Thanks. That looks fine, but please defer it until after the upcoming release. > Subject: [PATCH] truncate: fix a very unlikely case for undiagnosed errors

[coreutils] cp/reflink-perm fails on btrfs (and probably on ocfs2, too)

_copy" does have nonzero size. Here's the patch I'll probably use to solve that: >From 4df6a5f89cb5abd3f48ba3fa1653a0b732165a76 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 26 Oct 2010 11:36:08 +0200 Subject: [PATCH] tests: avoid false-positive failure on btrfs * tests/cp/

Re: [coreutils] cp/reflink-perm fails on btrfs (and probably on ocfs2, too)

Erik Auerswald wrote: > Hi, > > On Tue, Oct 26, 2010 at 11:39:58AM +0200, Jim Meyering wrote: >> The cp/reflink-perm test fails on a btrfs file system: >> >> echo > file2 # file with data >> cp --reflink=auto --preserve --attributes-only file2

Re: [coreutils] cp/reflink-perm fails on btrfs (and probably on ocfs2, too)

Pádraig Brady wrote: > On 26/10/10 12:48, Pádraig Brady wrote: >> So in summary error if any of --link, --symbolic-link, >> --reflink or --attributes-only are combined. > > I.E. leave the docs alone and do: Thanks. That sounds good. Do you feel like writing the NEWS entry, too? > diff --git a/sr

[coreutils] [PATCH] tests: mention that btrfs also causes failure of misc/ls-time

FYI, I considered skipping this as a known bug, but hear that it should be fixed "soon", so prefer to continue to see the failure until it's resolved. >From 0960e0c83d2a79d260f2b83bb273ed13ef5bbea1 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 26 Oct 2010 16:34:51 +02

Re: [coreutils] cp/reflink-perm fails on btrfs (and probably on ocfs2, too)

Pádraig Brady wrote: > On 26/10/10 14:54, Jim Meyering wrote: >> Pádraig Brady wrote: >>> On 26/10/10 12:48, Pádraig Brady wrote: >>>> So in summary error if any of --link, --symbolic-link, >>>> --reflink or --attributes-only are combined. >>>

Re: [coreutils] cp/reflink-perm fails on btrfs (and probably on ocfs2, too)

Pádraig Brady wrote: > Actually I remember now why we didn't want --reflink > mutually exclusive with other options. > It's so it can be used as configuration to change > the data copy method employed. I.E. it operates > on much the same level as --sparse in that the > results are mostly transparen

Re: [coreutils] stat: reverting recent %X %Y %Z change

Jim Meyering wrote: > Jim Meyering wrote: > >> Pádraig Brady wrote: >>> On 22/10/10 18:43, Jim Meyering wrote: >>>> Part of reverting this change: >>>> >>>> stat now outputs the full sub-second resolution for the atime, >>>&g

Re: [coreutils] stat: reverting recent %X %Y %Z change

Pádraig Brady wrote: > On 26/10/10 18:59, Jim Meyering wrote: >> Jim Meyering wrote: >>> Jim Meyering wrote: >>> >>>> Pádraig Brady wrote: >>>>> On 22/10/10 18:43, Jim Meyering wrote: >>>>>> Part of reverting this change: &

Re: [coreutils][patch] seq: User specified terminator

Pádraig Brady wrote: > On 27/10/10 18:27, William Plusnick wrote: >> I added a way to specify the string printed after the last number in the >> seq command, as suggested by a comment. I am not sure how helpful this >> option is, because I personally don't use the seq command much. I also >> added

Re: [coreutils] stat: reverting recent %X %Y %Z change

Jim Meyering wrote: ... > I think I have fixed things, finally. > Here's how my latest works: > > $ touch -d '2010-10-21 18:43:33.012345678' k > $ src/stat -c %3:X k > 12345678 > $ src/stat -c %3.3:X k >12 > $ src/stat -c %03.3:X k >

Re: [coreutils][patch] seq: User specified terminator

William Plusnick wrote: > On Wed, Oct 27, 2010 at 2:40 PM, Jim Meyering wrote: > > I wrote that comment simply because I thought that > hard-coding "\n" might not always be desirable. > Given that no one has ever complained, so > simply removi

Re: [coreutils] seq: Add the ability to process escape characters

William Plusnick wrote: > When I was looking at seq I noticed it did not process escape character in the > separator string. This renders it nearly impossible to separate the numbers by > tabs in Bash because when you hit the tab key it tries to autofill and doesn't > add the tab in directly. A mor

[coreutils] new snapshot available: coreutils-8.6.19-1369f

-- Here's git shortlog info: Changes in coreutils since v8.6: Andreas Schwab (1): fold: fix fadvise hint Benno Schulenberg (1): md5sum: print a summary warning for improperly formatted lines Eric Blake (1): maint: update THANKS Jim Meyering (9): post-release administriv

bug#7317: Bug in SLEEP command

Pádraig Brady wrote: > On 02/11/10 16:41, Eric Blake wrote: >> On 11/02/2010 09:46 AM, Андрей Передрий wrote: >>> >>> Hello guys! >>> >>> I found a bug in 'sleep' command. >> >>> As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, >>> 26 minutes and 33 seconds. >>> 24*24*36

[coreutils] Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

Gilles Espinasse wrote: > backref-multibyte-slow test fail on my imac 400 > Fail with timeout 5s, pass when timeout is changed to 10s > I have no faster machine to test on ppc. Thanks for the report. What is the ratio of the two times when running the latest with LC_ALL=en_US.UTF-8 / LC_ALL=C ? Fo

[coreutils] Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

Pádraig Brady wrote: > On 04/11/10 09:40, Jim Meyering wrote: ... >> Using Perl would work... >> I've wanted this sort of ability for other tests (e.g., coreutils' >> tests/rm/ext3-perf), so maybe it's worth adding an option to GNU timeout: >> run a refe

[coreutils] Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

Gilles Espinasse wrote: > Selon Jim Meyering : ... >> Gilles, does that work for you? >> > Will test tonight. > At least perl is always available on LFS build style. > > If perl is not available, probably test should be skipped. Actually, giving a warning and using t

Re: [coreutils] [patch] Re: Install enhancement request: capabilities

Yaron Sheffer wrote: > it's somewhat cleaner to have all the security-critical settings in > one place: owner, group, permissions, capabilities (and grep for "-P" > or "--capabilities"...). Plus you can rely on "install" to always be > there, which I don't think is true for "setcap". Thanks for th

[coreutils] Re: tests/backref-multibyte-slow timeout 5s is too short for my imac 400

Gilles Espinasse wrote: ... > Patch work with the zerl/perl typo fixed > PASS: backref-multibyte-slow Thanks. Oh, zerl was for testing, to make sure the case of missing perl was handled properly.

[coreutils] Re: Builds of coreutils-8.6.19-1369f

Nelson H. F. Beebe wrote: [...there appears to be a hang in "make check" on FreeBSD...] > > PASS: misc/id-groups > SKIP: misc/md5sum > SKIP: misc/md5sum-newline > PASS: misc/md5sum-parallel > PASS: misc/mknod Hi Nelson, [Cc'ing the list] Thanks for the heads up and for all the testing. The test

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Andreas Schwab wrote: > Jim Meyering writes: > >> For the record, I reduced it to this, >> where /bin/sh is /usr/local/bin/bash, which is 4.1.7: Actually, /bin/sh is *not* bash on that particular system. Rather, it's simply FreeBSD 8.1's /bin/sh. That require

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Jim Meyering wrote: > Andreas Schwab wrote: >> Jim Meyering writes: >> >>> For the record, I reduced it to this, >>> where /bin/sh is /usr/local/bin/bash, which is 4.1.7: > > Actually, /bin/sh is *not* bash on that particular system. > Rather, it's

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Andreas Schwab wrote: > Jim Meyering writes: > >> Here's a better test case: >> >> $ /bin/sh -c 'f(){ local s=$IFS; test -n "$s"; }; f' >> [Exit 1] >> >> And based on that, here's a patch to gnulib's tests/init

[coreutils] new snapshot available: coreutils-8.6.24-6c058

ng/cu/coreutils-ss.tar.xz http://people.redhat.com/meyering/cu/coreutils-8.6.24-6c058.tar.xz Changes in coreutils since 8.6.19-1369f: Eric Blake (2): cp, mv, touch: fix file time manipulation on Solaris 10 cp: NEWS entry for previous fix Jim Meyering (2): build: update gnuli

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Eric Blake wrote: > On 11/06/2010 08:19 AM, Jim Meyering wrote: >> Andreas Schwab wrote: >> >>> Jim Meyering writes: >>> >>>> Here's a better test case: >>>> >>>> $ /bin/sh -c 'f(){ local s=$IFS; test -n "

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Andreas Schwab wrote: > Jim Meyering writes: > >> IMHO, the fact that VAR=$OTHER_VAL never needs quotes >> should imply that `local VAR=$OTHER_VAL' also requires no quotes. > > I wonder where POSIX requires or even allows that export VAR=$foo does > not perform wor

[coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

Hi Pádraig, When running make check SHELL=dash, I got one failure. It was in misc/stat-birthtime, due to its use retry_delay_: + num_sleeps=16 + test 5 -le 5 + gawk -v n=16 -v s=.07 BEGIN { for (i=0;iFrom bda912213e8605121226ce2e07951f1b682ef595 Mon Sep 17 00:00:00 2001 From: Jim Meyering

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Ralf Wildenhues wrote: > Hello, > > * Jim Meyering wrote on Sat, Nov 06, 2010 at 02:55:47PM CET: >> Jim Meyering wrote: >> > Andreas Schwab wrote: >> >> Jim Meyering writes: >> >>> cat <<\EOF > init.cfg >> >>>

Re: [coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

Pádraig Brady wrote: > On 06/11/10 17:08, Jim Meyering wrote: >> Hi Pádraig, >> >> When running make check SHELL=dash, I got one failure. >> It was in misc/stat-birthtime, due to its use retry_delay_: >> >> + num_sleeps=16 >> + test 5 -le 5 &g

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: >> Ralf Wildenhues wrote: >> > - Posix does not require IFS to be set upon script startup. It only >> > requires >> > that, if IFS is unset, word splitting ought to behave

[coreutils] [PATCH] tests: don't disqualify FreeBSD 8.1's /bin/sh just yet,

I'll push this tomorrow: >From dd45755406861fc192284d7e2b28f3c33e0433d3 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 7 Nov 2010 14:23:32 +0100 Subject: [PATCH] tests: don't disqualify FreeBSD 8.1's /bin/sh just yet, because dash-0.5.6-2.fc14.x86_64 would also be

Re: [coreutils] [PATCH] split: fail immediately if impossible to create a large file

Pádraig Brady wrote: > For example, if splitting to 4G files (max on VFAT for example), > and `split` is built without large file support, then we would > have only failed after about 2G was written. If the input is > currently less than that, we won't know about the issue until later. > > I'm not

Re: [coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

Pádraig Brady wrote: > On 06/11/10 17:08, Jim Meyering wrote: >> Hi Pádraig, >> >> When running make check SHELL=dash, I got one failure. >> It was in misc/stat-birthtime, due to its use retry_delay_: >> >> + num_sleeps=16 >> + test 5 -le 5 &g

Re: [coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

Pádraig Brady wrote: ... >>> diff --git a/tests/init.cfg b/tests/init.cfg >>> index 1048cf3..d704f34 100644 >>> --- a/tests/init.cfg >>> +++ b/tests/init.cfg >>> @@ -388,8 +388,8 @@ retry_delay_() >>>local num_sleeps=$attempt >>>local time_fail >>>while test $attempt -le $max_n_tries; d

Re: [coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

#x27;m debating how much internal arg checking is warranted for test-only code like this. >From 21ff95d56601735e6db0c1235dee627f15e5eb1a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Nov 2010 13:11:05 +0100 Subject: [PATCH] tests: diagnose potential internal error * tests/init.cfg (ret

Re: [coreutils] [PATCH] tests: avoid portability problem with dash vs. local v=$splittable_val

Pádraig Brady wrote: > On 08/11/10 12:20, Jim Meyering wrote: > >> + case $init_delay in >> + ''|[^+.0-9]) fail_ "invalid delay: $init_delay; internal error" > > You need ** around the above I think like: > + ''|*[^+.0-9]*) fail_ "i

bug#7325: new test failure due to non-portability of printf formats like %05.3s

Pádraig Brady wrote: > On 08/11/10 14:33, Jim Meyering wrote: >> Looks like I got very lucky here and hit a number of nanoseconds >> that happened to be a multiple of 100,000: >> >> $ for i in $(seq 1000); do touch -d '1970-01-01 18:43:33.50' 2

Re: [coreutils] test: fix a dash portability problem with redirected symlinked ttys

Pádraig Brady wrote: > Another bug I noticed with dash-0.5.6-2.fc11.i586 > is that it doesn't redirect from symlinks correctly > for background processes. > > $ dash -c "tty < /dev/stdin&" > $ dash -c "tty < /dev/stdin" > /dev/pts/3 > $ bash -c "tty < /dev/stdin&" > /dev/pts/3 > $ dash -c "tty < $(

Re: [coreutils] [patch] Re: Install enhancement request: capabilities

Pádraig Brady wrote: > On 09/11/10 14:56, Mike Frysinger wrote: >> On Sunday, November 07, 2010 08:57:22 Yaron Sheffer wrote: >>> I still don't see the logic of not including capabilities in the >>> "install" feature set. We could use chmod and chown separately, too. But >>> still, setting owner/g

bug#7325: new test failure due to non-portability of printf formats like %05.3s

Jim Meyering wrote: > Paul Eggert wrote: > >> On 11/08/10 08:02, Eric Blake wrote: >>> In fact, since Paul originally wrote utimecmp.c, I'm surprised that you >>> rewrote the coreutils hash table from scratch rather than trying to >>> reuse the code. &

bug#7357: csplit: memory exhausted when using stdout / pipe instead of a file

looks fine and certainly belongs in the upcoming release. Looking at that, I found yet another problem. Here's all but the test, which will be done momentarily: >From b6ab1ac32080060667dea3b864462b5535e2779d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 10 Nov 2010 13:53:38 +0100 Sub

[coreutils] [PATCH] csplit: avoid buffer overrun when writing more than 999 files

#x27;s installed and usable. >From 8a5043963e1412014403150e53d850e0242f14e7 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 10 Nov 2010 13:53:38 +0100 Subject: [PATCH] csplit: avoid buffer overrun when writing more than 999 files Without this fix, seq 1000 | csplit - /./ '{*}' would write the NUL-termi

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Nov 07, 2010 at 12:22:13PM CET: >> Ralf Wildenhues wrote: >> > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: >> >> Ralf Wildenhues wrote: >> >> > - Posix does not require IFS to

[coreutils] coreutils-8.7 released [stable]

This is to announce coreutils-8.7, a stable, bug-fix-only release. It's been a month since coreutils-8.6 with 37 change-sets in coreutils proper and 59 in gnulib. This was supposed to have been a snap release solely to revert the stat %[XYZ] time stamp handling change introduced in 8.6, but that

[coreutils] [PATCH] maint: add a NEWS-checking syntax-check rule

Here's a trivial syntax check rule that I'll be using in a few projects. Without this, it's too easy to forget the guideline that says we prefer to use two empty lines to separate per-version sections. >From 23dbe438fd4c6a15281a1dc938a6b2682c48f677 Mon Sep 17 00:00:00 2001

Re: [coreutils] [PATCH] maint: add a missed fadvise-tests module

Pádraig Brady wrote: > > maint: add a missed fadvise-tests module > > * gl/modules/fadvise-tests: Add the module previously missed > in commit 63b5e816, 2010-07-14, "fadvise: new module ...". > * gl/tests/test-fadvise.c: Add a comment as to why we don't > check return values. L

Re: [coreutils] [PATCH] build: add `patch` as a bootstrap dependency

Pádraig Brady wrote: > FYI. > > commit 79adacc43178916392af3dd581ded87f3aea1655 > Author: Pádraig Brady > Date: Tue Nov 16 07:32:32 2010 + > > build: add `patch` as a bootstrap dependency > > * bootstrap.conf (buildreq): require `patch` as it's used > by gnulib-tool to apply loca

Re: [coreutils] [PATCH 1/5] tests: factor out VERBOSE-only --version-printing code

Pádraig Brady wrote: > On 17/11/10 21:31, Jim Meyering wrote: >> FYI, here are 5 change-sets to make a few hundred (mostly automated) >> changes like these: >> >> -test "$VERBOSE" = yes && chown --version >> +print_ver_ chown >> >

[coreutils] [PATCH] maint: syntax-check: prevent new $VERBOSE/--version tests

FYI, >From c1b41c5c3bd9f603ac09a8cbf16a69ffc9129e4f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 18 Nov 2010 06:29:54 +0100 Subject: [PATCH] maint: syntax-check: prevent new $VERBOSE/--version tests * cfg.mk (sc_prohibit_verbose_version): New rule. --- cfg.mk |6 ++ 1 fi

[coreutils] [PATCH] maint: avoid NEWS-related syntax-check failure

FYI, >From c2bdd178567cc1ba97995f3d086e5811d15aa84c Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 18 Nov 2010 21:16:27 +0100 Subject: [PATCH] maint: avoid NEWS-related syntax-check failure * NEWS: Add 2nd blank line to separate latest changes from those of 8.7, to avoid syntax-ch

Re: [coreutils] over aggressive threads in sort

Pádraig Brady wrote: > FYI https://bugzilla.redhat.com/show_bug.cgi?id=655096 Ouch! Thanks for forwarding that. Here's one way to test for the bug: seq 10 > in mkfifo fifo (for i in $(seq 12); do read line; echo $i; sleep .1; done cat > /dev/null) < fifo & (ulimit -t 1; ./sort i

Re: [coreutils] [PATCH] head: optionally indicate underrun of set limit

Pádraig Brady wrote: > On 23/11/10 16:24, Stefan Tomanek wrote: >> Dies schrieb Stefan Tomanek (stefan.toma...@wertarbyte.de): >> >>> It is often convinient to detect whether head has in fact printed the >>> requested number of lines or if EOF was reached before reaching that >>> point. This patch

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Hi Eric, > > I installed > coreutils-8.7-sol10-sparc-local > and the following dependencies are described as being required on the > sun freeware web site http://www.sunfreeware.com/indexsparc10.html > libintl-3.4.0-sol10-sparc-local > libiconv-1.13.1-sol10-sparc-local > libg

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Thanks for your reply. Please find attached the output of the commands > you asked for. Thanks. > /tmp/solpkgs# df -F /tmp/solpkgs > df: unknown option: T You can avoid that problem by running the just-built src/df, e.g., cd coreutils-8.7 && src/df -F /tmp/solpkgs >

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Thank you for your continued assistance. > > I don't have a config.status file. Perhaps I should explain that I > didn't compile the coreutils package I downloaded a pre configured > coreutils 8.7 package from sunfreeware along with some of the > dependancies that were mentio

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Hi Jim, > > Thanks for the info. I did the following and am still requiring some support > > I downloaded > > ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.7.tar.gz > ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.7.tar.gz.sig > > gpg --verify coreutils-8.7.tar.gz.sig && > I don't

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Hi Jim, > > Sorry about this hand holding but I have no experience with this. > > I ran > (cd coreutils-8.7 && ./configure && make && make -k check ) >& log > > In the zsh shell and it was much more successful this time. > > But what do I do know? If "make -k check" succeede

Re: [coreutils] coredump segmentation fault using coreutils 6.4 sparc solaris using mv or touch

Howell Hughes wrote: > Installing under /usr/local is fine. I don't have to use pkgadd it's > just what I was used to, so we can ignore that bit. > > I don't know if make -k check worked ok or not. I attached the > config.status file written during (cd coreutils-8.7 && ./configure && > make && mak

Re: [coreutils] [PATCH] tsort: suppress a valgrind memory leak warning

Pádraig Brady wrote: > This is the only "definitely lost" warning left > from valgrind --tool=memcheck. Good. Thanks! > commit c8b88772b61ffb3d9f73fc6b9985ec7b35495f87 > Author: Pádraig Brady > Date: Thu Nov 25 19:16:00 2010 + > > tsort: suppress a valgrind memory leak warning > >

Re: [coreutils] over aggressive threads in sort

Jim Meyering wrote: > Pádraig Brady wrote: >> FYI https://bugzilla.redhat.com/show_bug.cgi?id=655096 > > Ouch! Thanks for forwarding that. > > Here's one way to test for the bug: > > seq 10 > in > mkfifo fifo > (for i in $(seq 12); do read line;

Re: bug#7489: [coreutils] over aggressive threads in sort

erenced by the other thread. The patch below adds a small test case to exercise it. It demonstrates the failure in all but ~20 trials out of 1000 for me. So far, I've reproduced this only on multi-core systems, with --parallel=2. >From 3b8f453a325fbd094e2605347b1d8a05efab9b0d Mon Sep 17 00:

Re: bug#7489: [coreutils] over aggressive threads in sort

Paul Eggert wrote: > Could you please try this little patch? It should fix your > problem. I came up with this fix in my sleep (literally! > I woke up this morning and the patch was in my head), but > haven't had time to look at the code in this area to see > if it's the best fix. > > Clearly the

[coreutils] FYI, savannah is back; pushed up to Nov 27

I've just (re)pushed the few commits from Nov 24 to Nov 27.

[coreutils] [PATCH] tests: add test for parallel sort -u segfault bug

062 >From a5207bb1391cb8e169bc6036eb036bb1a89cde89 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 28 Nov 2010 12:59:38 +0100 Subject: [PATCH 2/2] tests: add test for parallel sort -u segfault bug * tests/misc/sort-unique-segv: New file. * tests/Makefile.am (TESTS): Add it. --- tests/

Re: bug#7489: [coreutils] over aggressive threads in sort

Jim Meyering wrote: > Paul Eggert wrote: >> Could you please try this little patch? It should fix your >> problem. I came up with this fix in my sleep (literally! >> I woke up this morning and the patch was in my head), but >> haven't had time to look at the cod

Re: bug#7489: [coreutils] over aggressive threads in sort

Paul Eggert wrote: > On 11/29/2010 08:32 PM, Chen Guo wrote: >> Hi guys, >> Is something up with Savannah? I just tried a git clone and got >> connection time out; I cant even reach git.sv.gnu.org via ping. > > There was a breakin, which led to leaking of encrypted account > passwords, some of

[coreutils] FYI, the repo is once again read-only

The first SQL injection abuse was actually two days earlier, so we're reverting to Nov 22 backups instead. There's a brief note on http://savannah.gnu.org/: # 2010/11/30 22:45 GMT: stopped write access and preparing new backup from the 22th # 2010/11/30 23:45 GMT: found trace of ear

Re: bug#7489: [coreutils] over aggressive threads in sort

Chen Guo wrote: > Hi Professor Eggert, > On Mon, Nov 29, 2010 at 11:16 AM, Paul Eggert wrote: >>  (for i in $(seq 12); do read line; echo $i; sleep .1; done >>  cat > /dev/null) < fifo & >>  (ulimit -t 1; ./sort in > fifo \ >>  || echo killed via $(env kill -l $(expr $? - 128))) > > I ran this 10

Re: [coreutils] [PATCH] tests: cleanup rm -rf fails under NFS

Paul Eggert wrote: > (I pushed this.) > > This problem was observed on RHEL 5.5 x86-64 when running as a > client of a NetApp FAS2050. > * tests/cp/cp-mv-backup: Don't leave a file descriptor open to > a file in a directory that will be cleaned up with "rm -rf". > Under NFS, when the rm unlinks tha

[coreutils] [PATCH] tests: make it harder to lose a race in spinlock-abuse

on. >From 231d8719f1b6d8324882cde0eb136c045b7c8338 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 4 Dec 2010 11:52:21 +0100 Subject: [PATCH] tests: make it harder to lose a race in spinlock-abuse * tests/misc/sort-spinlock-abuse: On a busy system, with only 12 pauses of length 0.1 seconds, the buggy (busy-spi

Re: bug#7489: [coreutils] over aggressive threads in sort

Paul Eggert wrote: > On 11/29/2010 02:46 PM, Paul Eggert wrote: >> My current guess, by the way, >> is that it's not a bug that can be triggered: it's merely >> useless code that is harmless and can safely be removed. > > I removed it as part of the following series of cleanup > patches. These are

Re: bug#7489: [coreutils] over aggressive threads in sort

Chen Guo wrote: ... > I've attached the patch (inlined at the bottom). Here's the GDB > crash, with backtrace. I also printed node->queued in GDB, so it's > evident that its accessible. > > (gdb) run --parallel 2 rec_1M > /dev/null > Starting program: /data/chen/Coding/Coreutils/test/sort-mutex

Re: bug#7489: [coreutils] over aggressive threads in sort

Chen Guo wrote: > Hi Professor Eggert, > On Sun, Dec 5, 2010 at 11:01 PM, Paul Eggert wrote: >> On 12/05/2010 09:16 PM, Chen Guo wrote: >>> Before saying anything else, I should note that for mutexes, on 4 >>> threads 20% of the time there's a segfault on a seemingly innocuous >>> line in queue_in

Re: [coreutils] [PATCH] split: fix a case where --elide-empty-files causes invalid chunking

Pádraig Brady wrote: > This is a fairly esoteric issue I noticed in passing. > No need for a NEWS entry I think. > I was wondering about adding ---io-blksize when writing > the test originally, and now that it can be used to > trigger this bug I think it's warranted? ... > Subject: [PATCH] split: f

[coreutils] multi-threaded sort can segfault (unrelated to the sort -u segfault)

[I've retitled and Cc'd bug-coreutils so this gets its own bug number] Chen Guo wrote: > On Tue, Dec 7, 2010 at 3:24 AM, Jim Meyering wrote: >> Thanks.  What does your input file look like? >> I've been unable to reproduce the failure using the output of >

Re: [coreutils] multi-threaded sort can segfault (unrelated to the sort -u segfault)

Jim Meyering wrote: ... > With that, I've solved at least part of the problem. > The segfault (and other strangeness we've witnessed) > arises because each "node" struct is stored on the stack, > and its address ends up being used by another thread after >

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

ed Thursday. I've also fixed a few syntax nits separately: >From 9a9d69e9e463ebfa67e90ecc061305532a91543e Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 11 Dec 2010 11:29:38 +0100 Subject: [PATCH 1/2] sort: syntax cleanup * src/sort.c (xfopen, debug_key, sortlines, sort, main): A

[coreutils] it's time for coreutils-8.8

Given the three sort bugs present in 8.6 and 8.7 that are now fixed for the upcoming release, I am motivated to make that release very soon. Does anyone have changes or additional bug reports that we should know about?

Re: [coreutils] draft [PATCH] sort: explicit --parallel=N now overrides environment

Pádraig Brady wrote: > On 11/12/10 09:05, Paul Eggert wrote: >> It seems to me that this code in sort.c: >> >> unsigned long int np2 = num_processors (NPROC_CURRENT_OVERRIDABLE); >> if (!nthreads || nthreads > np2) >> nthreads = np2; >> >> is now obsolete. It was written assumi

[coreutils] [PATCH] tests: avoid FP failure when run under valgrind

I noticed a false-positive failure when testing valgrind-wrapped tools: >From 45ff91af24f84eff331cbbc5c1a3f4a84248 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 11 Dec 2010 18:44:57 +0100 Subject: [PATCH] tests: avoid FP failure when run under valgrind * tests/misc/printenv: Fil

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Paul Eggert wrote: > Sorry for botching the NEWS and the change log. To help > make amends, how about if I add a test case for that? That would be welcome. Thanks. > I'm thinking of the 2nd test case in > , > namely this one

[coreutils] Re: bug#7597: multi-threaded sort can segfault (unrelated to the sort -u segfault)

Paul Eggert wrote: > On 12/12/2010 07:41 AM, Jim Meyering wrote: >> That sounds good, assuming it triggers the bug reliably for you. >> I was hoping to find a way to reproduce it without relying on gensort, >> but won't object if you want to do that. > > In my a

[coreutils] [PATCH] doc: tail: semi-deprecate --sleep-interval and --max-unchanged-stats

FYI, >From 2f2ef7369e326d7d43a91e1bef502d764517efd7 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 14 Dec 2010 09:08:37 +0100 Subject: [PATCH] doc: tail: semi-deprecate --sleep-interval and --max-unchanged-stats Those options are useful only on systems that lack inotify support and

Re: [coreutils] [PATCH] sort: fix some --compress reaper bugs

Paul Eggert wrote: > I found and fixed some bugs and simplified some code > while trying (and so far, failing) to fix the hang reported at the end of > . > I installed the following, and plan to look into that hang some more. >

Re: [coreutils] [PATCH] sort: fix some --compress reaper bugs

Paul Eggert wrote: > On 14/12/10 09:55, Jim Meyering wrote: >> It'd be a shame to make everyone sleep even one second for NFS. > > Well, it is marked as an _expensive_ test. :-) > > On 12/14/10 02:07, Pádraig Brady wrote: >> If the subprocesses were reparented to t

[coreutils] new snapshot available: coreutils-8.7.66-561f8

New features split accepts the --number option to generate a specific number of files. Here is "git shortlog" output: = Changes in coreutils since v8.7: Chen Guo (3): split: add --number to generate a particular number of files

[coreutils] Re: du/bigtime fail (

Assaf Gordon wrote: > Jim Meyering wrote, On 12/17/2010 05:07 AM: >> Here's a preview of what should soon appear as coreutils-8.8. [...] >> Any testing you can perform over the weekend would be most welcome. >> > On CentOS 5.4, du/bigtime fails (in a reproducible ma

[coreutils] [PATCH] doc: split: add examples showing how to use the new option

Here's a proposed addition to the texinfo manual: >From a83f05b6e91bb248ed0efc6585854f9785ccbda1 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 17 Dec 2010 21:58:33 +0100 Subject: [PATCH] doc: split: add examples showing how to use the new option * doc/coreutils.texi (split in

Re: [coreutils] clang-analyzer

Pádraig Brady wrote: > On 17/12/10 16:11, Pádraig Brady wrote: >> I also notice more warnings and a possible >> uninitialized stat buf in cp.c. >> I'll have a look at these later... > > That was another buglet fixed with: > > commit b0cce8793c0b7a305f0f336e2f563ea941c44a92 > Author: Pádraig Brady

Re: [coreutils] [PATCH] tests: set fail=0 by default

Paul Eggert wrote: > I found this one by tracking down a bug with the latest snapshot > on Solaris. Still haven't got to the real bug yet, but this bug > was getting in the way. > > Subject: [PATCH] tests: set fail=0 by default > > * tests/init.sh (setup_): Set fail=0. This was the intent as per

Re: [coreutils] Memory usage of parallel sort

Pádraig Brady wrote: > On 17/12/10 19:29, Assaf Gordon wrote: ... > Thanks for looking at this! > > I've not looked into the memory details, > but this is another reason to restrict > the default number of threads to 8, > which we talked about previously... > > commit 69ef9deef087b0447c05d9a298

<    1   2   3   4   5   6   7   8   9   10   >