Eric Blake wrote:
> Subject: [PATCH] build: fix build failure of bogus USE_XATTR
...
> diff --git a/m4/xattr.m4 b/m4/xattr.m4
...
> use_xattr=yes
>fi
> fi
> -AC_DEFINE_UNQUOTED([USE_XATTR], [$use_xattr],
> - [Define if you want extended attribute supp
Michael Stone writes:
> It seems that touch -a does update ctime on btrfs, invalidating one of the
> assumptions behind this test and causing it to fail.
Did you mean "does not update ctime"?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01
On 16/01/10 18:08, Leszek Dubiel wrote:
I have found that Judy arrays are faster than standard "sort" program
about 10 times. This is a little bit strange, because I expected sort to
be fastest tool ever.
Heres is my session:
les...@jowisz$ wc input
100 100 5659335 input
les...@jowisz
Michael Stone wrote:
> It seems that touch -a does update ctime on btrfs, invalidating one of
> the assumptions behind this test and causing it to fail.
s/does/does not/
Thanks for the report.
I've just confirmed this test failure by building and running coreutils'
"make check" on a btrfs file s
On Sun, Jan 17, 2010 at 09:59:46AM +0100, Andreas Schwab wrote:
Michael Stone writes:
It seems that touch -a does update ctime on btrfs, invalidating one of the
assumptions behind this test and causing it to fail.
Did you mean "does not update ctime"?
Yes. My eyes are starting to cross. I
On Sun, Jan 17, 2010 at 10:08:23AM -0500, Michael Stone wrote:
But then I also have a build log
(https://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=8.1-1&arch=amd64&stamp=1261006367&file=log)
with a different failure, which is what I thought I'd duplicated last
night, but can't for the li
According to Michael Stone on 1/17/2010 8:11 AM:
> On Sun, Jan 17, 2010 at 10:08:23AM -0500, Michael Stone wrote:
>> But then I also have a build log
>> (https://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=8.1-1&arch=amd64&stamp=1261006367&file=log)
>> with a different failure, which is what I
Each of these variables is declared as an "int *".
>From bbf85cc44fc18ec8f085edf1dcf73fc1247648a0 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 18 Jan 2010 07:53:44 +0100
Subject: [PATCH] pr: avoid two over-allocations
* src/pr.c (init_store_cols): Allocate N*sizeof(*VAR) bytes,
not N*s
Hi Pádraig,
Is this ok with you?
>From 175c6320d2934a48e7bd31b2a778758a8c1c1ae4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 18 Jan 2010 08:02:05 +0100
Subject: [PATCH] libstdbuf: plug a leak
* src/libstdbuf.c (apply_mode): Don't leak "buf" upon setvbuf failure.
---
src/libstdbuf.c |