Eric Blake wrote:
> On 01/23/2012 05:22 AM, Krzysztof Goj wrote:
>> It was raised in the Google+ discussion that -d flag has been added to
>> BSD code base in 1990.
>> I checked the man pages of FreeBSD, NetBSD, OpenBSD and Mac OS X and
>> the -d option is there.
>
> That's the most convincing arg
Krzysztof Goj wrote:
> I created a patch adding new option to rm (-d/--dir) which allows to
> remove empty directories.
> You may have seen this issue being discussed in comments on Rob Pike's Google+
> (https://plus.google.com/101960720994009339267/posts/3WDmR2RTTrv).
>
> Removing empty directorie
Some old tests in tests/rm/* still had remnants showing that
they pre-dated our use of init.sh and similar frameworks.
Here's a clean-up patch:
>From dec02bb98ec59fc1a5a0ed6ae1dda2bda69af111 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 23 Jan 2012 14:42:10 +0100
Subject: [PATC
Erwin Poeze wrote:
> 8.15 is added now to the TP. I wrongly thought to have seen that there
> where no changes compared to 8.14.
Thanks, Erwin!
Philipp Thomas wrote:
> * Jim Meyering (j...@meyering.net) [20120106 19:39]:
>
>> This is to announce coreutils-8.15, yet another stable release.
>
> Could it be that you forgot to send the message template for 8.15 to the
> translation robot? I tried to submit the updated g
Pádraig Brady wrote:
> On 01/10/2012 06:00 PM, Jim Meyering wrote:
>> - format = xasprintf ("%s%s", format, _("\
>> -Access: %x\n\
>> -Modify: %y\n\
>> -Change: %z\n\
>> - Birth: %w\n\
>> -"));
>> + format = xaspr
Pádraig Brady wrote:
> On 01/05/2012 04:05 AM, Bruno Haible wrote:
>> Pádraig Brady wrote:
No, time_t is typedefed to 'long int' (32-bit but signed) on this
>> platform.
>>>
>>> Right, so if time_t is changed to 64 bit there in future,
>>> the test would be too restrictive?
>>
>> time_t cannot
itive.
>From f2ee48d9cb4406ba6b03e780032d3f308d6c6ffa Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 9 Jan 2012 22:56:54 +0100
Subject: [PATCH] maint: adjust formatting of certain continued strings
Add a rule to ding any source file that has a continued string
with a word in the
FYI,
>From bfe711db1c07e73a5806647a637f609eb8c1773d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 9 Jan 2012 22:38:24 +0100
Subject: [PATCH] maint: straggler *.[ch] files: convert more `...' to '...'
The preceding commands ignored .[ch] files in lib/ and gl/.
This is
Jim Meyering wrote:
> Here are some change-sets to convert most `...' quoting to '...'.
>
> I tried to automate as much as possible.
> The commits labeled "maint:..." will be merged into the preceding
> ones since they usually just denote "run the sa
gfpmtipb GFP IP App ID wrote:
> coreutils-8.11
>
...
> FAIL: misc/env-null (exit: 1)
> =
...
> + fail=1
> + env -i
> PATH=/appl/archives/build_tools/tools/build/coreutils-8.11/src:/appl/archives/build_tools/tools/build/coreutils-8.11/src:/usr/xpg4/bin:/appl/gfpip/local/
est.
Besides, it's only the test of the testing framework, and the penalty
for failure is a mere "diff not found" diagnostic on some old system.
I confirmed that at least on Solaris 10, it works as desired,
even when (somehow) you don't have diff in your shell's search path.
Pádraig Brady wrote:
> On 01/07/2012 04:20 PM, Jim Meyering wrote:
>> - fprintf (stderr, _("Try `%s --help' for more information.\n"),
>> program_name);
>> + fprintf (stderr, _("Try '%s --help' for more information.\n"),
>>
Jim Meyering wrote:
> Now that gnulib's quote/quotearg use 'quotes', not `quotes'
> begin the process of updating coreutils and its tests
> to match that new behavior.
>
> Blindly updating to latest from gnulib would have ind
Jim Meyering wrote:
> Now that gnulib's quote/quotearg use 'quotes', not `quotes'
> begin the process of updating coreutils and its tests
> to match that new behavior.
>
> Blindly updating to latest from gnulib would have induced 87 test failures.
...
>
p 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 7 Jan 2012 16:42:41 +0100
Subject: [PATCH 1/3] maint: factor out all `Try --help'-emitting statements
* src/system.h (emit_try_help): New function.
---
src/system.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a
This is to announce coreutils-8.15, yet another stable release.
There have been over 120 commits by 12 people in the 12 weeks since 8.14.
This adds a new program, realpath, and several bug fixes.
Reassuringly, the trend continues: most fixes are for bugs off in the dusty
corners of the code, and f
d messed up the part that accepted that.
Here's the fix:
>From ce0e4459c40fceb367d9383f2c078ac8a2a0ea60 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 6 Jan 2012 17:51:52 +0100
Subject: [PATCH] scripts: allow one-line summary to start with "[Vv]ersion
\d"
* scripts/gi
I'm building/testing now, using the latest from gnulib and automake master.
If all goes well, I'll tag and upload within the next few hours.
FYI,
>From 847446ac841857e532b208cad21957e706a7c989 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 6 Jan 2012 08:53:04 +0100
Subject: [PATCH] maint: adjust ChangeLog to reflect earlier df request
* build-aux/git-log-fix: Credit early reporter.
* THANKS.in: Add a name.
---
THANKS
s surprised to see that change introduce
new failures, where quote-emitted `...' failed to match my expectation
of '...'-everywhere.
For now, I've adapted coreutils' tests so that that they expect the
new, inconsistent output.
>From e8fb9b01699ee235fd4d3c6d0d413d4000
Bruno Haible wrote:
> Jim Meyering wrote:
...
> Thanks, this fixed the failures of this test on several platforms.
>
> But it introduced a minor problem: spurious output of the test.
>
> On AIX 6.1:
>
> ./test-init.sh[42]: There: not found.
> PASS: test-init.sh
>
&
Pádraig Brady wrote:
> This patch looks good.
> I've no pending commits for 8.15.
Thanks. None here, either.
I expect to update to the latest gnulib and automake tomorrow morning,
do some testing, and if all goes well, release.
* empty
> ! --- in
> ! ***
> ! *** 0
> ! --- 1
> ! + xyz
Thanks!
My test expected diff -u output.
compare may generate diff -c output or even cmp output.
This should fix it:
>From 68571c92aeffdded292b047f1ea3c25bd5f73b49 Mon Sep 17 00:00:00 2001
From: Jim Meye
Bruno Haible wrote:
> Jim Meyering wrote:
>> > ERROR: misc/printenv
>> >
>> >
>> > grep: Maximum line length of 2048 exceeded.
>> > grep: Maximum line length of 2048 exceeded.
>> > printenv: set-up failure:
>>
>
Bruno Haible wrote:
> Jim Meyering wrote in
> <https://lists.gnu.org/archive/html/coreutils/2012-01/msg00059.html>:
>> > FAIL: rm/unread3
>> >
>> > rm: unable to record current working directory: Too many open files
>> > rm: unab
Bruno Haible wrote:
>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
> On AIX 5.1, there are 1 framework failure and 5 test failures.
Thanks for the report!
> ERROR: misc/printenv
>
>
> grep: Maximum line length of 2048 exceeded.
> grep: Maximum line length of 20
Jim Meyering wrote:
> Bruno Haible wrote:
>>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>>
>> On NetBSD 5.1/x86, I get this test failure in particular:
>>
>>
>> FAIL: split/l-chunk
>> ===
>> split: /dev/zero: N
o be a 3-letter sequence:
> $ setfacl -m user::r k
> Unrecognized character found in mode field
> $ setfacl -m user::r-- k
> $ setfacl -m user::-w- k
> $ setfacl -m user::--x k
Thanks for the report and analysis!
This should fix it and prevent recurrence.
>From cf318308a5dd0c1bc3f1
avoid failure due to leftover 'errno' value
* src/split.c (lines_chunk_split): Fix logic bug that led to
unwarranted failure of "split -n l/2 /dev/zero" on NetBSD 5.1.
The same would happen when splitting a growing file, where
open/lseek-end gives one size, but by the time we
k-TESTS
> bash: -c: line 4: syntax error: unexpected end of file
> *** Error code 2
> make: Fatal error: Command failed for target `misc/help-version.log'
>
>
> Could this be documented in the README as well?
Sure. Thanks for the report.
>From 4d3e398a74cf9546642c77be89e3bd811150faa4 Mon Se
FYI,
>From d01550552843baf365ed9ff039426dfdd0fcb986 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 4 Jan 2012 18:13:19 +0100
Subject: [PATCH] maint: ignore *.trs files, lib/getopt.h and
build-aux/test-driver
* .gitignore: Also ignore automake's new .trs files and its
build-
Eric Blake wrote:
> On 06/11/2011 05:02 AM, James Youngman wrote:
>> * src/system.h: Definitions of ST_* macros have moved into the
>> gnulib module stat-size (specifically, the header file
>> stat-size.h), so remove them from here.
>> * src/truncate.c: Include stat-size.h.
>> * src/stat.c: Likewis
Bernhard Voelker wrote:
> I stumbled over this readme sentence:
>
>> tail -f now uses polling (not inotify) when any of its file arguments
>> resides on a file system of unknown type.
>
> So I asked myself what happens if all file system types of all arguments
> are known but one is "remote"? strac
Pádraig Brady wrote:
> On 01/03/2012 04:29 PM, Jim Meyering wrote:
>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>> expected on Thursday or Friday.
>>
>> coreutils snapshot:
>> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
Pádraig Brady wrote:
> On 01/03/2012 04:29 PM, Jim Meyering wrote:
>> FYI, here's a snapshot of what will soon be coreutils-8.15,
>> expected on Thursday or Friday.
>>
>> coreutils snapshot:
>> http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB
>
Pádraig Brady wrote:
> On 01/03/2012 03:58 PM, Jim Meyering wrote:
>> diff --git a/NEWS b/NEWS
>
>> + df, with no non-option argument and recent enough kernel/tools, would
>> + print a long UUID-including file system name, pushing second and
>> subsequent
>&g
-check improvement
build: simplify warnings based on last gnulib update
doc: fix list of GNU extension date formats
Erik Auerswald (1):
ln: fix position of --backup values description
Jim Meyering (80):
maint: post-release administrivia
maint: tac: remove sol
Pádraig Brady wrote:
> On 01/03/2012 03:58 PM, Jim Meyering wrote:
>> diff --git a/NEWS b/NEWS
>
>> + df, with no non-option argument and recent enough kernel/tools, would
>> + print a long UUID-including file system name, pushing second and
>> subsequent
>&g
Jim Meyering wrote:
> Pádraig Brady wrote:
> ...
>>> Now, I'm thinking about making this a little more future-proof by
>>> matching the UUID part /[0-9a-fA-F-]{36}$/ instead.
>>> I.e., testing something like this:
>>>
>>> i
Pádraig Brady wrote:
> On 01/03/2012 10:29 AM, Jim Meyering wrote:
>
>>> On 01/03/2012 12:30 AM, Bruno Haible wrote:
>
>>>> How about '--no-symlinks'?
>
>> Please add a comment something like this near the --strip option:
>> /* FIXME: d
Pádraig Brady wrote:
> On 01/03/2012 12:30 AM, Bruno Haible wrote:
>> Pádraig Brady wrote:
>>> To me realpath is conceptually (cd; pwd), so I used
>>> the -L and -P options as defined by POSIX for cd.
>>
>> Makes good sense, yes.
>>
>>> I considered using --no-dereference, but while the symlinks
>
> presented in /proc/mounts that one doesn't want displayed.
> I can't think of anything else worth avoiding at the moment.
Thanks for the review.
Here's an updated patch.
Changes:
- added comment for new function
- added _GL_ATTRIBUTE_PURE, too
- updated commit log and
'int' [-Werror=format]
>From 658a91d573f148dd0db51eaaa4d7c337d0035031 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 2 Jan 2012 21:28:15 +0100
Subject: [PATCH] build: tail: avoid type/format mismatch warning from gcc
Without this change, gcc's -Werror=format would complain that
the '%lx' format requ
Jim Meyering wrote:
...
> + char *dev_name = xstrdup (disk);
> + char *resolved_dev;
> +
> + /* On some systems, dev_name is a long-named symlink like
> + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing
> + to a much shorter and more useful n
Pádraig Brady wrote:
> On 12/31/2011 11:27 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
>>>> Reading only the documentation for --relative-base=FILE,
>>>> I am not sure how it works:
>>>>
>>>> `--relative-base=FILE
Barely worth a commit...
>From 794e52b7bd84a860d5606b70265cefdde839b7c3 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 1 Jan 2012 18:40:54 +0100
Subject: [PATCH] tests: also print chmod's --version
* tests/rm/many-dir-entries-vs-OOM: This test also exercises chmod.
---
tests
First I updated tests/sample-test with a simple s/2011/2012/
From 75a21e62486521ba3d8ef518dc4740dc1adeb7f4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 1 Jan 2012 09:52:49 +0100
Subject: [PATCH 1/2] tests: change copyright year from 2011 to 2012 in
sample-test
Pádraig Brady wrote:
> On 12/12/2011 12:24 AM, Pádraig Brady wrote:
>> FYI I'm not forgetting about this.
>> This week I'll be travelling with work,
>> but I intend to tackle this early the following week.
>
> Sorry for the delay.
> Attached is the realpath implementation, which I think
> turned in
Pádraig Brady wrote:
...
>> Reading only the documentation for --relative-base=FILE,
>> I am not sure how it works:
>>
>> `--relative-base=FILE'
>> Ensure both the `--relative-to' and processed files are
>> subdirectories of FILE, or otherwise output the absolute file name.
>> Note t
ed unconditionally?
> Anyway I now see the failure after first doing a `make clean`.
Actually it's a missing dependency.
This should fix it.
>From 325f98e3746e8677de7f0b5e742b8b11eb5a92b4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 31 Dec 2011 11:56:40 +0100
Subject: [PATCH] t
Pádraig Brady wrote:
> On 12/12/2011 12:24 AM, Pádraig Brady wrote:
>> FYI I'm not forgetting about this.
>> This week I'll be travelling with work,
>> but I intend to tackle this early the following week.
>
> Sorry for the delay.
> Attached is the realpath implementation, which I think
> turned in
Pádraig Brady wrote:
> On 12/12/2011 12:24 AM, Pádraig Brady wrote:
>> FYI I'm not forgetting about this.
>> This week I'll be travelling with work,
>> but I intend to tackle this early the following week.
>
> Sorry for the delay.
> Attached is the realpath implementation, which I think
> turned in
Without this, building on rawhide has been failing for some time
when configured with --enable-gcc-warnings. The warning/error is
unwarranted, since the function may exit.
>From 9be9d120f01fa65be33ab98d0c728a7e849c5d4b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 30 Dec 2011 22:48
Pádraig Brady wrote:
> On 12/29/2011 02:09 PM, Jim Meyering wrote:
>> On systems with recent kernel/tools, a symlink from /etc/mtab to
>> /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone),
>> you will see something like the following when running "df -hT
Paul Eggert wrote:
> On 12/29/11 06:09, Jim Meyering wrote:
>> + /* If dev_name is a long-named symlink like
>> + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 and its
>> + canonical name is shorter, use the shorter name. But don't bother
>> +
o defer or drop the patch.
>From a59338b9ca2ed8cbc82bdf3a299c4a664ad113c9 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 29 Dec 2011 14:49:00 +0100
Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks
On systems with recent kernel/tools, a symlink from /etc/m
FYI, I noticed the getenv calls in libstdbuf.c and realized
that these three new variables could perturb tests, so have
added them to the list in tests/envvar-check:
>From 3e7a1473ae41440bd5e8b62f0532ac99a112f7bd Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 28 Dec 2011 18:01:01 +0
Pádraig Brady wrote:
> On 12/28/2011 06:18 PM, Jim Meyering wrote:
>> It's been over two months and pretty many bug fixes since 8.14.
>> Does anyone have pending bug fixes or requests that should be considered?
>
> I was hoping to get `realpath` finished tonight.
>
Pádraig Brady wrote:
> On 12/28/2011 05:56 PM, Jim Meyering wrote:
>> Can anyone name a real system on which forming a pointer like this,
>> "buffer + (size_t)(-1)" actually provokes a trap or some other real problem?
>
> I don't know of particular hardware w
It's been over two months and pretty many bug fixes since 8.14.
Does anyone have pending bug fixes or requests that should be considered?
There are enough bug fixes that I'd like to defer feature
additions (i.e., new du option) and new programs until after 8.15.
Here's the NEWS delta for upcoming
Can anyone name a real system on which forming a pointer like this,
"buffer + (size_t)(-1)" actually provokes a trap or some other real problem?
>From 6e00315bf290310895036fce979a7e0210871b63 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 28 Dec 2011 18:30:50 +0100
Subject:
Pádraig Brady wrote:
> On 12/26/2011 03:50 PM, Jim Meyering wrote:
>> --- a/src/stat.c
>> +++ b/src/stat.c
>
>> +case S_MAGIC_PIPEFS: /* 0x50495045 remote */
>> + /* FIXME: change syntax or add an optional attribute like
>> "inotify:no".
&g
e it so tail uses polling, not
inotify with it. If anyone happens to know that inotify does work
with that type of file system, please let us know.
>From b1230020dc5c5acc9f9ab16c3c397c0aecb5977b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 26 Dec 2011 16:09:48 +0100
Subject: [PATCH]
nsistent with --help from all other programs.
I've adjusted all of stat --help's lines on that front.
>From b2a6fb0ac925831f8b96f54e10633f24b7b33f12 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 24 Dec 2011 12:03:18 +0100
Subject: [PATCH] doc: stat: clarify that %t and %T
I've been running this rule sporadically, but it should be part of the
pre-release process, so ...
If anyone knows of a more up-to-date list of file system
magic numbers, please let us know.
>From 6e3299fcdb783b19552dbb2ceb0d012ce51a3501 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date:
FYI, I read part the "info factor" documentation today
and spotted/fixed a couple of nits in an example:
>From ed71262bc258311690e7761154f8413465d9c78e Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 20 Dec 2011 14:39:57 +0100
Subject: [PATCH] doc: improve factor e
Just noticed that with the new bootstrap script, this
slightly kludgy fix-up code is no longer needed:
>From f797c04415d348ae15a0c0aa8a19cfe8d22569bd Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 17 Dec 2011 17:26:00 +0100
Subject: [PATCH] build: remove now-useless code f
FYI,
>From e71f0d9df3c782386b364b6a53dcdaadaaef81b5 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 17 Dec 2011 16:38:23 +0100
Subject: [PATCH] build: merge in bootstrap changes from gnulib
* bootstrap: Pull in the combination of gnulib's "bootstrap: detect
tools required b
jida...@jidanni.org wrote:
> $ ls -t1 --time-style=%c -og
> ls: invalid argument `%c' for `time style'
> Valid arguments are:
> - `full-iso'
> - `long-iso'
> - `iso'
> - `locale' <-you forgot to also mention "+FORMAT"
> Try `ls --help' for more information.
> $ ls -t1 --time
r/--recursive
>> as
>> a TODO.
>
> Hmm, we probably ought to nuke that comment instead, unless there are
> other implementations of shred that already provide -r.
Thanks for mentioning it.
That comment is no longer useful, so I'll remove it with this:
>From da4793e94
Jim Meyering wrote:
...
> Subject: [PATCH] ls: be responsive to interrupts when color-listing large
> directories
>
> Starting with commit adc30a83, when using --color, ls inhibited
> interrupts to avoid corrupting the state of an output terminal.
> However, for very large
More gcc warnings fallout:
>From fd75178fa8f1deeef72b375a19870e7464f5f393 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 4 Dec 2011 14:08:54 +0100
Subject: [PATCH] maint: sort, stat: remove unused parameters
* src/sort.c (struct thread_args) [is_lo_child]: Remove member.
(sortli
Pádraig Brady wrote:
> On 12/04/2011 09:37 AM, Jim Meyering wrote:
>> I've been using gcc-4.7.0 and experimenting with an even
>> longer list of warnings. Here's some fallout:
>
>> Subject: [PATCH 2/2] od,test: address warnings from gcc's -Wjump-misses-
I've been using gcc-4.7.0 and experimenting with an even
longer list of warnings. Here's some fallout:
>From bea7b10489afcc845db00b03da6ccea71de6cb1d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 3 Dec 2011 16:42:19 +0100
Subject: [PATCH 1/2] maint: remove redundant usage
Peng Yu wrote:
> Hi Jim,
>
>> realpath --relative-start=DIR FILE ...
>
> I had some private email conversation with Eric. Per Eric's
> suggestion, it is better to document it to the mailing list for future
> reference and to make my point clearer.
Keeping discussion on the mailing list is almos
aught how to use the new program.
There's no point in doing that now for relpath when it will be different
for realpath.
------
>From 824756b16c7a0fecde2ea15eb5b7901dae302cfa Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: T
Bernhard Voelker wrote:
> On 12/01/2011 09:07 AM, Jim Meyering wrote:
>
>> Your patch was fine, but your mail client mangled the sole TAB, rendering
>> it inapplicable via "git am FILE". The very last line of diff context in
>> the init.cfg diff should have had
Bernhard Voelker wrote:
> As a replacement for my previously proposed patch:
> "[PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests"
> (see http://lists.gnu.org/archive/html/coreutils/2011-11/msg00086.html),
> and after some confusion in the discussion, the following patch adds
Bernhard Voelker wrote:
> As a replacement for my previously proposed patch:
> "[PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests"
> (see http://lists.gnu.org/archive/html/coreutils/2011-11/msg00086.html),
> and after some confusion in the discussion, the following patch adds
Bernhard Voelker wrote:
> On 12/01/2011 01:40 AM, Pádraig Brady wrote:
>> On 12/01/2011 12:17 AM, Bernhard Voelker wrote:
>>> As a replacement for my previously proposed patch:
>>> "[PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests"
>>> (see http://lists.gnu.org/archive/html/
Bernhard Voelker wrote:
> Since gnulib commit 69f517e5975418e7b2c5033f8f60191919f44b9d,
> a coreutils build fails when --enable-gcc-warnings is enabled:
>
> CC propername.o
> cc1: warnings being treated as errors
> propername.c:21:10: error: unknown option after '#pragma GCC
> diagnostic' ki
oelker.
---
ChangeLog|6 ++
lib/propername.c |2 +-
lib/quotearg.c |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 28fbe90..333 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-11-29 Jim Meyering
+
+ quote
Eric Blake wrote:
> [adding bug-gnulib]
>
> On 11/27/2011 01:17 PM, Jim Meyering wrote:
>> Someone should have dinged me ;-)
>> Last week I made a global change but forgot to add a matching
>> syntax-check rule.
>>
>>>From 5b3e538b7fc193f8e54b16aeb99b48f
Now that gnulib's lib/ (at least the part coreutils uses)
is ready for -Wsuggest-attribute=pure|const, I've changed
coreutils to enable those options for lib/ -- but still not
for gnulib-tests/:
>From 1e676ec8443f096f7e46aeef781301e38ef30f1d Mon Sep 17 00:00:00 2001
From: Jim Meyeri
Someone should have dinged me ;-)
Last week I made a global change but forgot to add a matching
syntax-check rule.
>From 5b3e538b7fc193f8e54b16aeb99b48f28744c1db Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 27 Nov 2011 15:36:06 +0100
Subject: [PATCH] tests: add a syntax check for l
:00 2001
From: Jim Meyering
Date: Sun, 27 Nov 2011 13:51:40 +0100
Subject: [PATCH] maint: update comment gcc-4.6.2 still botches
-Wsuggest-attribute=pure
* configure.ac: Update the comment on which gcc versions still must
not use -Wsuggest-attribute=pure option: still required on post-
F
From: Jim Meyering
* bootstrap (AUTOPOINT, AUTORECONF): Factor out definitions.
Run autopoint and libtoolize *before* gnulib-tool.
After it, run an abbreviated autoreconf, rather than a loop around
all tools.
* bootstrap.conf (gnulib_tool_option_extras): Add both --symlink
and --makefile-name
From: Jim Meyering
---
.gitignore | 77
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index cc17996..fabab51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,11 +18,13 @@
/build-aux
From: Jim Meyering
This bootstrap script arose back when gnulib-tool was young.
Since then, it has seen improvements that render much of this
script unnecessary. In particular, it can now make symlinks
to the files it uses. Also, I no longer see as much value in
marking files as read-only via
From: Jim Meyering
* bootstrap.conf (gnulib_modules): Use gnulib's gettext-h, not the
gettext module. Not only is gettext-h far smaller (it has far fewer
dependencies than the gnulib module), but it does not suffer from
the problem with the gettext module whereby it adds a -I.../intl
opti
With these changes, I've removed a lot of old code from coreutils'
bootstrap script. I expect to commit the latter two changes to gnulib
soon, too, and from there the updated bootstrap script will propagate
to grep, gzip, diffutils, parted, etc.
I verified that bootstrapping from a 'make maintain
Erik Auerswald wrote:
...
>> Therefore I don't think it's a problem of the system, but
>> more the behavior of coreutils tests to use administrative
>> tools (those usually used by root and therefore in [/usr]/sbin).
>> As a result, I think the test should either be run as root
>> only (which is of
Bernhard Voelker wrote:
> Although my OpenSuSE system has e2fsprogs installed, the test
> fiemap-perf cannot use it, because /usr/sbin is missing in
> my (non-root) user's PATH:
>
> fiemap-perf: skipped test: the `filefrag` utility is missing
> SKIP: cp/fiemap-perf
>
> This is similar to the ma
Bernhard Voelker wrote:
> Hi Jim,
>
> I wanted to do a commit in git-gui using a message with
> 74 characters in a line. The commit-msg hook catched that,
> and opened $EDITOR.
>
> However, as I committed from git-gui, there was no
> terminal, and git-gui hang.
>
> berny@blackice:~/git/coreutils> p
Jim Meyering wrote:
> I have just had this commit hook mistakenly reject a commit log
> due to a git-generated comment line that was longer than 72.
> Obviously, those should be exempted:
>
...
> - 72 < length $line
> + 72 < length $line && $line =~ /^#/
I have just had this commit hook mistakenly reject a commit log
due to a git-generated comment line that was longer than 72.
Obviously, those should be exempted:
>From b29658ee8456c209aef5d7b9534b9e2d575fc29d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 23 Nov 2011 09:02:51 +0
provoked only one warning.
>From da38f12d6f0cfcf0c990c2b8ca7e982f655540d8 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 22 Nov 2011 21:45:24 +0100
Subject: [PATCH 1/2] build: --enable-gcc-warnings: disable some new warnings
* configure.ac: Disable some new warning options pulled in
c7367 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 20 Nov 2011 21:33:48 +0100
Subject: [PATCH 1/3] maint: make generated THANKS file read-only
* Makefile.am (THANKS): Make generated file read-only.
---
Makefile.am |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
I noticed diagnostics from gitlog-to-changelog about two unused entries.
This suppresses them:
>From 8ffc159611db3443282aee42465afc8a1597519c Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 20 Nov 2011 15:34:59 +0100
Subject: [PATCH] maint: avoid gitlog-to-changelog diagnostic ab
801 - 900 of 1572 matches
Mail list logo
