On Thu, Nov 7, 2013 at 6:37 AM, Pádraig Brady wrote:
> Since the previous patch renabled direct I/O that was disabled on most
> (file) systems in coreutils 6.0, it reactivates a bug that was present
> since 5.3.0 when direct I/O was added.
>
> I.E. there can now be an odd sized direct I/O write at
On Fri, Nov 1, 2013 at 9:29 AM, Pádraig Brady wrote:
> This should be fully backwards and forwards compatible with previous
> escaping, since we'll never have a file name at the start of a line,
> thus '\' at the start of a line always means the file name is escaped.
>
> * src/md5sum.c (main): Onl
On Wed, Oct 30, 2013 at 3:53 AM, Pádraig Brady wrote:
> Though I don't think the complication/clarification
> is warranted in this case.
Glad we agree. THanks for replying.
Good idea. Thanks!
On Wed, Oct 9, 2013 at 4:07 PM, Bob Proulx wrote:
> Summary: The old coreutils CVS is now marked read-only.
>
> Details: Recently one of the other projects on Savannah moved from CVS
> to GIT. They wanted to mark the old CVS source repository as
> read-only to ensure that no developers accidental
d, 9 insertions(+), 1 deletion(-)
>>
>> Coreutils includes a rather extensive list of file systems (alas, it's
>> GPLv3+ code, so we can't use it verbatim without asking Jim Meyering and
>> other coreutils folks to relax the license):
>> http://git.sv.gnu.o
On Wed, Sep 11, 2013 at 11:06 PM, Bernhard Voelker
wrote:
...
> Thanks, pushed:
> http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=321933e1
Thanks!
On Thu, Sep 5, 2013 at 9:22 AM, Pádraig Brady wrote:
> On 09/05/2013 04:58 PM, Chris Dew wrote:
>> Thanks Pádraig,
>>
>> I had avoided fiemap, due to the issue discussed at
>> http://smackerelofopinion.blogspot.co.uk/2010/01/using-fiemap-ioctl-to-get-file-extents.html
>> - I use fibmap instead,
Reduced scope and cleaner static analysis runs are always welcome. Thanks.
On Sat, Jul 27, 2013 at 6:33 PM, Pádraig Brady wrote:
> * src/csplit.c (find_lines): Assert that load_buffer() updates the
> global buffers, thus "b" will be non NULL, thus suppressing subsequent
> NULL pointer derefence w
Pádraig Brady wrote:
> On 06/02/2013 04:46 AM, Jim Meyering wrote:
>> diff --git a/tests/misc/head-c.sh b/tests/misc/head-c.sh
>> index 37a86ce..a5b6c6a 100755
>> --- a/tests/misc/head-c.sh
>> +++ b/tests/misc/head-c.sh
>> @@ -19,6 +19,7 @@
>> . "${s
rlying patch, because on a 32-bit system,
it's not uncommon to have 2^31 bytes of RAM, so the allocation
could succeed.
However, that's so much simpler that I now think it's the way to go.
Thanks!
>From aeaeb87c134ce748527ba99e749b7369fcba2438 Mon Sep 17 00:00:00 2001
From: Jim
Paul Eggert wrote:
> On 05/27/2013 06:04 PM, Jim Meyering wrote:
>> +lim=$(echo $SIZE_MAX | subtract_one_)
>> +lim=$(expr $lim - $max_BUFSIZ)
>
> Sorry, I don't see how this will work either.
> It's common for a GMP-less expr to handle values
> only up to
Paul Eggert wrote:
> On 05/27/2013 05:07 PM, Jim Meyering wrote:
>
>> +max_BUFSIZ=$(expr 256 '*' 1024)
>> +lim=$(expr $SIZE_MAX - $max_BUFSIZ)
>
> Can't this code fail, due to overflow, on non-GMP hosts? See:
>
> http://lists.gnu.org/archive/html/cor
Paul Eggert wrote:
> On 05/27/2013 05:07 PM, Jim Meyering wrote:
>
>> +max_BUFSIZ=$(expr 256 '*' 1024)
>> +lim=$(expr $SIZE_MAX - $max_BUFSIZ)
>
> Can't this code fail, due to overflow, on non-GMP hosts? See:
>
> http://lists.gnu.org/archive/html/cor
nt.
This works for me:
>From 6b20bb5c9c464277f843a1d3f418824275f25f6b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 27 May 2013 17:01:14 -0700
Subject: [PATCH] tests: head-c: avoid spurious failure with a 32-bit SIZE_MAX
* tests/misc/head-c.sh: When eliding N bytes from a non-see
Pádraig Brady wrote:
> On 05/27/2013 03:04 AM, Jim Meyering wrote:
>> FYI, this avoids another 32-bit (small SIZE_MAX, actually) test failure:
>
> +1 thanks
Thanks. Pushed.
Pádraig Brady wrote:
> On 05/27/2013 03:10 AM, Jim Meyering wrote:
>> This avoids a test failure when the current user or group name
>> contains a space. To demonstrate, you can probably just edit
>> /etc/group and make your primary group name two words with a
>>
This avoids a test failure when the current user or group name
contains a space. To demonstrate, you can probably just edit
/etc/group and make your primary group name two words with a
space between them.
>From 909a0561de27e516f3dff8e4a79ce0add5ca148b Mon Sep 17 00:00:00 2001
From: Jim Meyer
FYI, this avoids another 32-bit (small SIZE_MAX, actually) test failure:
>From 2b4c6ebeaafbdf48df4162c1991452bcb5d7b5cf Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 26 May 2013 18:56:50 -0700
Subject: [PATCH] tests: avoid spurious failure when SIZE_MAX is 2^32-1
* tests/split/l
Jim Meyering wrote:
> Pádraig Brady wrote:
>
>> unarchive 13530
>> stop
>
> Thanks.
>
> ...
>>> @@ -358,6 +356,14 @@ elide_tail_bytes_pipe (const char *filename, int fd,
>>> uintmax_t n_elide_0)
>>>
>>>if (bu
Pádraig Brady wrote:
> unarchive 13530
> stop
Thanks.
...
>> @@ -358,6 +356,14 @@ elide_tail_bytes_pipe (const char *filename, int fd,
>> uintmax_t n_elide_0)
>>
>>if (buffered_enough)
>> {
>> + if (n_elide_0 != n_elide)
>> +{
>> +
Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 05/26/2013 06:07 PM, Jim Meyering wrote:
>>> Pádraig Brady wrote:
>>> ...
>>>> I expect to push soon, the attached more complete fix to realloc the array.
>>>
>>> That new test would still fa
Pádraig Brady wrote:
> On 05/26/2013 06:07 PM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>> ...
>>> I expect to push soon, the attached more complete fix to realloc the array.
>>
>> That new test would still fail on 32-bit systems, and on any system
>>
ter than to suggest
testing in a 32-bit virtual machine.
>From 8c647adfcd7d9ae66f7759f1bbf9ac3f78c23503 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 26 May 2013 09:49:22 -0700
Subject: [PATCH] head: with --bytes=-N don't fail early for large N on 32-bit
systems
* src/head.c (elide_ta
Jim Meyering wrote:
> Paul Eggert wrote:
>> On 05/12/2013 10:14 PM, Jim Meyering wrote:
>>> I ran gcc's -fsanitize=address against coreutils, and two
>>> sort tests failed due to buffer overruns. Both arose via
>>> a bug in quotearg.c. Patch below. Tw
Paul Eggert wrote:
> On 05/12/2013 10:14 PM, Jim Meyering wrote:
>> I ran gcc's -fsanitize=address against coreutils, and two
>> sort tests failed due to buffer overruns. Both arose via
>> a bug in quotearg.c. Patch below. Two things remain to do:
>> 1)
sure I'll do #1, but I will get to #2.
>From 5f14f49f770258fd81cea53602a94be0c0c4dffd Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 11 May 2013 18:43:50 -0700
Subject: [PATCH] quotearg: do not read beyond end of buffer
* lib/quotearg.c (quotearg_buffer_restyled): Do not read beyo
Bob Proulx wrote:
> Jim Meyering wrote:
>> Bob Proulx wrote:
>> > Not so much to the coreutils mailing lists but to the other mailing
>> > lists there have been quite a few large files attempted to be posted.
>> > And when I say large I mean 10M files po
Bob Proulx wrote:
> Not so much to the coreutils mailing lists but to the other mailing
> lists there have been quite a few large files attempted to be posted.
> And when I say large I mean 10M files posted to mailing lists with
> 1200+ subscribers in the worst cases! Usually somewhat less large.
I found this small languishing patch, refreshed it and will push later today.
>From 090294b0e4b496137fcb3a672c979c679d0e47f8 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 5 Dec 2012 11:11:59 -0800
Subject: [PATCH] scripts: tweak URLs in autotools-install
* scripts/autotools-inst
Ole Tange wrote:
> I was astonished to learn that:
>
> perl -MMIME::Base64 -e 'while(read(STDIN,$buf,770*50)){print
> decode_base64($buf)}'
>
> is faster than:
>
> base64 -d
>
> I found this which might be faster:
> http://www.experts-exchange.com/Programming/System/Windows__Programming/A_3216
Pádraig Brady wrote:
> * src/tail.c (main): If -n0 or -c0 were specified without -f,
> then no data would ever be output, so exit without reading input.
> * tests/tail-2/tail-n0f.sh: Augment the related test with this case.
Nice. Thanks!
Pádraig Brady wrote:
> * doc/coreutils.texi (sort invocation): Mention that numfmt
> can achieve the same results with a possibly more accurate sort.
> ---
> doc/coreutils.texi |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
Assaf Gordon wrote:
> Hello,
>
> Trying to use 'scripts/autotools-install' on a problematic system (Mac
> OS X 10.6.8, already has few other related bugs), building
> "pkg-config" fails.
>
> Two patches attached:
>
> 1. When "./configure" or "make" fail, use "die()" to print an error,
> pointing t
Assaf Gordon wrote:
> Hello Stefano,
>
> Stefano Lattarini wrote, On 02/22/2013 02:30 AM:
>> On 02/22/2013 12:08 AM, Assaf Gordon wrote:
>>>
>> I think this explanation should go in the commit message of the second patch,
>> as it makes clear why such patch is needed.
>>
>
> Good idea, attached an
Stefano Lattarini wrote:
> Hi Pádraig, thanks for the quick feedback.
>
> On 02/15/2013 03:56 PM, Pádraig Brady wrote:
>> On 02/15/2013 01:39 PM, Stefano Lattarini wrote:
>>> I have a custom 'editor' script in ~/bin, and a system-provided
>>> 'editor' program in /usr/bin (on Debian, this is a link
Pádraig Brady wrote:
> On 02/11/2013 11:55 AM, Pádraig Brady wrote:
>> This is another snapshot mainly to roll up translations.
>> We plan to release coreutils 8.21 this Thursday.
...
> Date: Thu, 14 Feb 2013 02:32:22 +
> Subject: [PATCH] build: avoid link failure in devmsg() on older linkers
>
Assaf Gordon wrote:
> Assaf Gordon wrote, On 02/13/2013 11:45 AM:
...
>> One more update with two changes:
...
> From: Assaf Gordon
> Date: Mon, 11 Feb 2013 20:19:31 -0500
> Subject: [PATCH 01/12] uniq: support sort-like '--key' specification
>
> ---
> src/uniq.c | 338 --
Liu Haifeng wrote:
> I got this resolved, it's a bug in my java code. I didn't close the error
> stream, which means tail's stderr was piped to the java program too. I did not
> consume any error output, and after a month the stderr buffer got full, that
> caused tail to block.
Thanks for the foll
Pádraig Brady wrote:
> On 02/08/2013 05:09 PM, Bernhard Voelker wrote:
>> On February 8, 2013 at 5:30 PM "Pádraig Brady" wrote:
>>> On 02/08/2013 02:53 PM, Bernhard Voelker wrote:
On February 7, 2013 at 8:57 PM "Pádraig Brady" wrote:
* SLES-10.3 (i586):
gcc (GCC) 4.1.2 20070115
Jim Meyering wrote:
> I noticed two new test failures, both minor. Here are fixes:
...
> Subject: [PATCH] tests: avoid actual/expected mismatch due to changed
> diagnostic
>
> * tests/cp/fail-perm.sh: Adjust expected diagnostic to match
> just-changed cp diagnostic.
> * te
I noticed two new test failures, both minor. Here are fixes:
>From f3569a9b3f18a0f22ce137c90826c0553b6da9ae Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 7 Feb 2013 09:43:41 -0800
Subject: [PATCH] tests: avoid actual/expected mismatch due to changed
diagnostic
* tests/cp/fail-perm
Makefile.am (TESTS): Add slink.
* tests/du/slink: New test for system.h change of 2002-08-31.
Which refers to this commit:
commit 62808a7fb5cbb2d321719c0cba558f2ce8c90d24
Author: Jim Meyering
Date: Sat Aug 31 16:04:57 2002 +
Symlinks were always reported as using 0 blocks.
(ST_NBLOCKS): Don't depend on file type.
This reverts the change of 2000-01-30.
Based on a report and patch from Neil Brown via Michael Stone.
Pádraig Brady wrote:
> On 01/09/2013 05:15 PM, Daniel J Walsh wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 01/09/2013 11:02 AM, Pádraig Brady wrote:
>>> On 01/09/2013 03:50 PM, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Any word on this
Ondrej Oprala wrote:
> On 01/03/2013 02:12 PM, Jim Meyering wrote:
>>> bool all_errors = !x->data_copy_required ||
>>> x->require_preserve_context;
>>> bool some_errors = !all_errors && !x->reduce_diagnostics;
>> However, both
Ondrej Oprala wrote:
> I'd like to propose a patch based on this bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=806055 .
> Since it doesn't add any new functionality or fix incorrect behaviour,
> I assume there's no need for another test or a NEWS entry.
>
> From e95a3ce63cfee94bcf8099da3a0
We don't like "make syntax-check" failures :-)
I've updated to the latest in gnulib, and updated copyright years
in coreutils. All tests still pass, at least on Fedora 17, 18,
and rawhide (all x86_64).
>From a4838da139dde3739d9046153809939b8ccfe72d Mon Sep 17 00:00:00
Bernhard Voelker wrote:
> On 12/29/2012 03:34 PM, Jim Meyering wrote:
>> I've made a few changes as I read through the recent NEWS entries:
>
> Thanks.
> +1
Thanks for the review. Pushed.
I've made a few changes as I read through the recent NEWS entries:
>From cebf94eeb1dd07dbc1afff73acf2b586f63367d5 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 29 Dec 2012 15:30:48 +0100
Subject: [PATCH] maint: adjust NEWS entry wording
* NEWS: Adjust wording in a few
Pádraig Brady wrote:
...
> I'll push the attached (complete with new test and doc adjustments) soon.
...
Nice. I was going to say it looked impeccable,
but then noticed a nit at the end of the test.
Thanks!
> diff --git a/tests/readlink/multi.sh b/tests/readlink/multi.sh
...
> +readlink link1 li
Jim Meyering wrote:
...
>> The awkward/somewhat redundant -n, --no-newline option
>> is handled in the same way as on BSD and the help text adjusted like:
>>
>> - -n, --no-newline do not output the trailing newline\n\
>> + -n, --no-newline
Pádraig Brady wrote:
> On 12/12/2012 08:19 PM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> On 12/12/2012 07:05 PM, Aaron Davies wrote:
>>>> Is there a reason the interface for readlink(1) is “FILE” instead of
>>>> “FILE...”? I’ve often wanted to do
Pádraig Brady wrote:
> On 12/12/2012 07:05 PM, Aaron Davies wrote:
>> Is there a reason the interface for readlink(1) is “FILE” instead of
>> “FILE...”? I’ve often wanted to do e.g. “find -type l|xargs
>> readlink” or (in zsh) “readlink **/*(@)”, and having to do a shell
>> loop or use “xargs -n1”
Assaf Gordon wrote:
> Assaf Gordon wrote, On 12/05/2012 06:13 PM:
>> Attached is a working version of numfmt.
>
> Somewhat related:
> How do I add a rule to build the man page (I'm working on passing 'make
> syntax-check').
>
> I've added the following line to 'man/local.mk':
> man/numfmt.1:
Pádraig Brady wrote:
> On 12/04/2012 11:35 PM, Assaf Gordon wrote:
>> Pádraig Brady wrote, On 12/04/2012 06:11 PM:
>>> On 12/04/2012 10:55 PM, Assaf Gordon wrote:
Hello,
> Pádraig Brady wrote, On 12/04/2012 11:30 AM:
>> Nothing yet. The plan is to make a numfmt command available
Bernhard Voelker wrote:
> Hi Ondrej,
>
> On 12/03/2012 07:09 PM, Ondrej Oprala wrote:
>> thanks for the rebase :) .
>
> no worries, you're welcome. ;-)
>
>> I've modified the patch a bit, so I dont interfere with output if df -a
>> is specified.
>
> Thanks.
>
> I just had a quick look on the patch
Pádraig Brady wrote:
> * src/factor.c (mp_factor_init): Init the pointers with NULL,
> which xrealloc (or realloc) handles fine.
> ---
> src/factor.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/factor.c b/src/factor.c
> index 6d1d17a..90af1c4 100644
> --- a
Pádraig Brady wrote:
> Sorry for the slowness of my review of this.
> I had a spare hour there, and added these plumbing
> patches to better integrate your patch into coreutils.
> I'll squash these into your patch when finished.
>
> Still todo is:
> actually analyze/test the meat of the patch
>
I've pushed these three maint patches:
>From d35a931d2daf0b8e8ad79940b99c40dc8ef75317 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 18 Nov 2012 09:16:17 -0800
Subject: [PATCH 1/3] maint: avoid i686-specific syntax-check failure
* cfg.mk (_gl_TS_unmarked_extern_vars)
Michael Stone wrote:
> FYI
>
> From: Daniel Schepler
> Subject: Bug#693337: coreutils: src/factor.c should use HAVE_LONG_LONG_INT
> instead of undefined HAVE_LONG_LONG
> To: sub...@bugs.debian.org
> Date: Thu, 15 Nov 2012 08:02:02 -0800 (3 days, 1 hour, 53 minutes ago)
>
> Source: coreutils
FYI,
>From 7b4df77dbebe6d11710a81c9e06a60e8086b9146 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 13 Nov 2012 07:03:01 +0100
Subject: [PATCH] maint: avoid unnecessary #include to fix syntax-check
failure
* src/factor.c: Remove unneeded #inclusion of"verify.h".
It'
I was going to write this:
FYI, I've just updated coreutils to use
the latest from gnulib, after fixing a couple of
minor problems in gnulib. Now, at least for me,
"make check" and "make syntax-check" pass with this
latest version of gnulib (on x86_64/F17 and i686/F18)
But then I saw a
> run.sh to make clear that the test scripts are generated.
> * cfg.mk (sc_tests_list_consistency): Exempt the new test.
> (exclude_file_name_regexp--sc_prohibit_test_backticks):
> Likewise.
>
> Improved-by: Stefano Lattarini
> Improved by: Jim Meyering
> ---
> cfg.mk
Bernhard Voelker wrote:
> Subject: [PATCH] maint: refactor new tests for refactored factor
Oh, and the subject of that patch, while cute, could be more accurate,
e.g.,
tests: shorten factor's inordinately-long test file names
Stefano Lattarini wrote:
> Hi Jim.
>
> On 10/27/2012 11:14 AM, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>>>> You can save a fork by avoiding a call to basename:
>>>>>
>>>>> t=${testname##*/}
>>>>
>>>>
Stefano Lattarini wrote:
>>> You can save a fork by avoiding a call to basename:
>>>
>>> t=${testname##*/}
>>
>> Good point. I wasn't sure if that syntax is portable.
>> I know it from old dtksh days.
>>
> It is portable to any decent POSIX shell. And I think Coreutils assumes
> that one is av
Pádraig Brady wrote:
> On 10/26/2012 10:34 AM, Jim Meyering wrote:
>> +** Build-related
>> +
>> + The generated man/*.1 man pages are no longer distributed. Building
>> + without perl, you would create stub man pages, and besides would be
>> + unable to ru
Stefano Lattarini wrote:
> On 10/25/2012 04:25 PM, Bernhard Voelker wrote:
>> On 10/25/2012 04:08 PM, Jim Meyering wrote:
>>> Bernhard Voelker wrote:
>>>> Isn't it "Due to lack on the build system, ..."?
>>>>
>>>> I.e. coreutil
Bernhard Voelker wrote:
> I was just wondering if we shouldn't refactor the new factor tests.
>
> They have ugly and long file names (the test data), and have identical content
> (which is redundancy which in turn should be avoided IMO):
>
> $ md5sum *.sh
> 31c3a9e8b5dad969dafd07c348c48233
> 0-1000
Bernhard Voelker wrote:
> On 10/25/2012 03:37 PM, Jim Meyering wrote:
>> -Due to lack of perl on your system, the GNU coreutils build system
>> -hasn't been able to create the manual page for
>> +Due to lack of perl on your system, the $source build system
>> +fail
Stefano Lattarini wrote:
...
> Here is the updated patch. Sorry for the noise,
> Stefano
>
> 8<8<8<8<8<8<8<8<8<8<8<
>
>>From f61dcb763975c1aab299fa9678ea180d70db6acf Mon Sep 17 00:00:00 2001
> Message-Id:
>
> From: Stefano Lattarini
> Date: Tue,
Pádraig Brady wrote:
> * tests/misc/pr.pl: Refactor this test into ...
> * tests/pr/pr-tests.pl: ... here.
> * tests/local.mk: Remove the reference to the removed test
> * tests/pr/m-w-t-1: Input file for the refactored test.
> * tests/pr/m-w-t-2: Likewise.
> * tests/pr/m-w-t-3: Likewise.
> ---
>
g@free.fr wrote:
> - Mail original -
>> De: "Jim Meyering"
>> À: "Stefano Lattarini"
>> Cc: "Pádraig Brady" , "Mike Frysinger"
>> , coreutils@gnu.org,
>> 12...@debbugs.gnu.org
>> Envoyé: Mercredi 24 Octob
Stefano Lattarini wrote:
> Here is the updated patch. Sorry for the noise,
...
> Subject: [PATCH] build: graceful degradation in man pages generation if perl
> is lacking
Thank you for the updated patch.
> Fixes coreutils bug#12715.
>
> Since commit v8.19-118-g57da212, our 'dist-hook' rule twea
Pádraig Brady wrote:
> On 10/24/2012 09:54 AM, Jim Meyering wrote:
>> Sounds good. I.e., it sounds like we want Stefano's patch, after all.
>>
>> As you recall, a nice side effect is that we will
>> no longer distribute the generated man/*.1 files.
>
> We
Pádraig Brady wrote:
> On 10/24/2012 08:56 AM, Jim Meyering wrote:
>> Would anyone object to making perl a build-time prerequisite?
>> I.e., would this cause serious inconvenience?
>
> Probably less inconvenience than a broken make -j ;)
Note that it is broken only when bu
Jim Meyering wrote:
> Mike Frysinger wrote:
> ...
>>> I have mixed feelings. If someone is modifying sources and expecting
>>> to be able to rebuild, they'd better have developer tools like perl.
>>>
>>> On the other hand, I dislike distributing
Pádraig Brady wrote:
> On 10/23/2012 01:13 PM, Jim Meyering wrote:
>> Thanks.
>> I confirmed that this addresses the problem.
>>
>> Did you consider other ways of addressing it,
>> say without adding that cast? Imagine that
>> someone adds another addmod2 u
Pádraig Brady wrote:
> Yes these comments are appreciated,
> as I needed to dig into the code a bit
> mode that I would like to figure out things.
>
> Please push.
Done.
Pádraig Brady wrote:
> * src/longlong.h: Restrict some sparc assembly variants
> to sparc V9. This was seen to be an issue with newer
> sparc systems with default gcc CPU options.
> ---
> src/longlong.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/longlong.h b
Pádraig Brady wrote:
> * src/factor.c (factor_using_pollard_rho2): On some systems
> (like sparc) we need to promote all addmod2() parameters
> to uintmax_t to avoid warnings.
> ---
> src/factor.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/factor.c b/src
Pádraig Brady wrote:
> src/factor.c (__GMP_DECLSPEC): Move back from longlong.h
> to treat consistently with other stub macros.
> (__GMP_GNUC_PREREQ): Reference to avoid -Wunused-macros warning.
> (__GMP_DECLSPEC): Likewise.
> (ASSERT): Likewise.
> (__clz_tab): Likewise.
> (factor_using_division):
Pádraig Brady wrote:
> On 10/23/2012 08:46 AM, Jim Meyering wrote:
>> Torbjorn Granlund wrote:
>>> Pádraig Brady writes:
...
>>> Aren't this Draconian options ("ask the compiler to nag about everything
>>> it can, then treat nagging as errors in the
Pádraig Brady wrote:
> On 10/23/2012 08:46 AM, Jim Meyering wrote:
...
>> When configured with gcc and --enable-gcc-warnings we enable -Werror,
>> to ensure that no warnings slip by unnoticed.
>> That is not the default, though I'm tempted to make it
>> th
Torbjorn Granlund wrote:
> Pádraig Brady writes:
>
> If I manually undef HAVE_GMP at the top of factor.c, then...
>
> $ make src/factor.o
> src/factor.c:154:0: error: macro "__GMP_GNUC_PREREQ" is not used
> [-Werror=unused-macros]
>
> It is used by some configs in longlong.h. It cannot be r
Pádraig Brady wrote:
> On 10/19/2012 12:36 PM, Jim Meyering wrote:
>> We plan to release coreutils-8.20 early next week, so any testing
>> you can do between now and Monday would be most welcome.
>
> Fedora 15 - x86_64
...
> RHEL 6.1
...
> solaris - sparc
...
> Debian
Pádraig Brady wrote:
> * tests/misc/factor.pl: Correct the precedence and
> regular expression in the command to check for GMP.
> ---
> tests/misc/factor.pl |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tests/misc/factor.pl b/tests/misc/factor.pl
> index 8f6edaa..5
Daniel J Walsh wrote:
> On 10/16/2012 09:32 AM, Jim Meyering wrote:
>> Daniel J Walsh wrote:
>>> On 10/09/2012 08:54 AM, Jim Meyering wrote:
>>>> Pádraig Brady wrote:
>>>>> On 10/08/2012 09:24 PM, Daniel J Walsh wrote:
>> ...
>>>>
-install --help
Jim Meyering (58):
maint: post-release administrivia
tests: don't require @acronym{...} around POSIX
maint: stop using @acronym{...} in texinfo sources
build: update gnulib submodule to latest
tail,stat: improve support for ZFS
scripts: git
Pádraig Brady wrote:
> On 10/17/2012 03:07 AM, Jim Meyering wrote:
>> Hi Pádraig,
>>
>> Would you please review this?
>>
>> [ cp: avoid data-corrupting free-memory-read ]
>> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/25139/focus=25151
Hi Pádraig,
Would you please review this?
[ cp: avoid data-corrupting free-memory-read ]
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/25139/focus=25151
That bug is obviously serious and the fix merits a prompt release.
What would you or anyone else like to see committed before
Daniel J Walsh wrote:
> On 10/09/2012 08:54 AM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>> On 10/08/2012 09:24 PM, Daniel J Walsh wrote:
...
>> [in a follow-up]
>>> Thinking further, --context without an option, is not too clear to the
>>> user. They
Nikolas Kallis wrote:
> There is a problem with the Coreutils Contribution Guidelines:
>
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>
> I got up to 'Your first commit: the quick and dirty way' and executed
> the command 'git format-patch --stdout -1 > DIFF', and got the error
> m
Pádraig Brady wrote:
> On 10/08/2012 09:24 PM, Daniel J Walsh wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> One of if not the most common problem people hit with SELinux is the mv
>> command, which maintains the file context of the source destination.
>>
>> mv /home/dwalsh/index
Jeff liu wrote:
> Hi Philipp,
>
> Thanks for taking a look at this feature, and sorry for my late response!
>
> Hi Jim,
>
> Recently, I have discussed with a colleague(Bo Liu CC-ed) who is focus
> on Btrfs development, and we
> decided to teach Btrfs aware of reflinked extents per file for du(1) pu
Philipp Thomas wrote:
> * Jim Meyering (j...@meyering.net) [20121003 20:09]:
>
>> I can reproduce that by specifying an older version of POSIX:
>>
>> $ : | _POSIX2_VERSION=0 tail -c 10
>> tail: cannot open '10' for reading: No such file or direc
Jim Meyering wrote:
> Pádraig Brady wrote:
>> In the recent factor rewrite, the GMP code
>> wasn't actually used; just an error was printed
>> on integer overflow. While fixing that it was noticed
>> that correct input validation wasn't done in all cases
Pádraig Brady wrote:
> In the recent factor rewrite, the GMP code
> wasn't actually used; just an error was printed
> on integer overflow. While fixing that it was noticed
> that correct input validation wasn't done in all cases
> when falling back to the GMP code.
>
> * src/factor.c (print_factor
d as errors
make[2]: *** [src/factor.o] Error 1
I'm sure there's a cleaner way to fix it, but this is
good enough for now.
>From 231e40a6ba29b892daca1e4a2e464c315874e155 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 7 Oct 2012 10:37:25 +0200
Subject: [PATCH] maint: avoid warni
FYI,
>From f947735d3c4036703e03bf6970784430db1355f7 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 5 Oct 2012 22:35:27 +0200
Subject: [PATCH] build: avoid link failure when strerror is replaced
When building the new make-prime-list program on a system for which
strerror is defined
301 - 400 of 1572 matches
Mail list logo
