This makes the release process more efficient on a multi-core system:
>From 948828b208e4cd59ceb903afbb46f55c09d51e18 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 4 Jan 2011 12:47:24 +0100
Subject: [PATCH] maint: use slightly more efficient process in README-release
* README-release: Ru
crocket wrote:
> The below message didn't go to my "coreutils mailing list" folder in
> my mailbox.
> It was because the mssage didn't have "coreutils@gnu.org" as one of
> recipients.
In general the mailing list address should always be in the recipient
list in either the To: or Cc: fields. It is
==
1 of 382 tests failed
(60 tests were not run)
See tests/test-suite.log
Please report to bug-coreut...@gnu.org
==
This is, I believe the relevant section:
FAIL: cp/cp-parents (exit: 1)
=
++ init
I noticed that the new du test would occasionally fail
because du would complete too quickly.
Making the tree about ten times larger solved the problem:
(5x was not enough; see comments below)
>From 7e72d4fe9da159d42efe0845b0f36e2ea9d7c3b1 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 18
The below message didn't go to my "coreutils mailing list" folder in my mailbox.
It was because the mssage didn't have "coreutils@gnu.org" as one of recipients.
Is there a way to put such messages in the correct folder?
- Original Message
From: Andreas Schwab
To: Jim Meyering
Cc: public
Jim Meyering wrote:
> Pádraig Brady wrote:
>
>> On 16/01/11 23:53, Sami Kerola wrote:
>>> Hi,
>>>
>>> I notice uniq -f 'insane_large_number' will make process to be busy
>>> long time without good reason. Attached patch should fix this symptom.
>>
>> I'd slightly amend that to the following,
>> to
Jim Meyering wrote:
...
> Odd... no difference in CPU time or syscall counts.
>
> I wonder if the SSD is doing something special with blocks of all zeros,
> which is reminiscent of The Reg's article:
> http://www.theregister.co.uk/2011/01/14/ocz_and_ddrdrive_performance_row/
I've redone the doc ch
