Re: [PATCH 1/2] gitlog-to-changelog: support multi-author commits.

Hi Jim, Thanks for the reviews. On 17 Nov 2011, at 03:01, Jim Meyering wrote: > Gary V. Vaughan wrote: > ... >> the parts that didn't work OOTB on my Mac to be portable. Feel free to crib >> those portable parts of this one into coreutils, or reformat this one to >> coreutils style as you prefer

Re: FYI, new, rare failure on rawhide

The data that you gave are consistent with my guess, namely, that utimens is marking st_ctime for update, but that the update doesn't actually occur until after stat is called (a violation of POSIX). If my wild guess is right, increasing the nap time could mask the bug, as the update could occur d

Re: FYI, new, rare failure on rawhide

Paul Eggert wrote: > Possibly a bug in the file system or kernel? > An earlier part of the code does this: > > /* lines 57 and 58 of test-utimens.h */ > ASSERT (func (BASE "file", ts) == 0); > ASSERT (stat (BASE "file", &st1) == 0); > > and this relies on st_ctime being marked for updat

Re: gnulib integration how to

Excerpts from Paul Eggert's message of Wed Nov 16 03:10:40 -0500 2011: > I agree with your comment about it needing a date and version info. Added. I'll maintain this going forward. > Also, it'd be nice for it to have a "References" or "See also" > section at the bottom, that points to the gnul

Re: gnulib integration how to

Excerpts from Bruno Haible's message of Tue Nov 15 21:48:30 -0500 2011: Hi Bruno, > Two things: > > 1) From the perspective of a distributor of packages for a specific >platform, the libposix subproject of gnulib (see > >

Re: [PATCH 1/2] gitlog-to-changelog: support multi-author commits.

Gary V. Vaughan wrote: ... > the parts that didn't work OOTB on my Mac to be portable. Feel free to crib > those portable parts of this one into coreutils, or reformat this one to > coreutils style as you prefer. > >> An alternative is to accept anything after the ":" and then, to use >> "s/\s*> >

Re: FYI, new, rare failure on rawhide

Possibly a bug in the file system or kernel? An earlier part of the code does this: /* lines 57 and 58 of test-utimens.h */ ASSERT (func (BASE "file", ts) == 0); ASSERT (stat (BASE "file", &st1) == 0); and this relies on st_ctime being marked for update in the first line, and being ac

FYI, new, rare failure on rawhide

FYI, I'm seeing this in a rawhide VM using ext4, but only twice, and since then 20 trials with no failure. FAIL: test-fdutimensat (exit: 134) == test-utimens.h:109: assertion failed It never fails when run by itself. I.e., the failure happens only when

Re: openat requires lstat.m4

Excerpts from Bruno Haible's message of Tue Nov 15 21:12:06 -0500 2011: > I'm applying this. The "tiny change" is not meant to be a derogatory > designation; it merely documents that your contribution to gnulib so > far did not require the exchange of copyright assignment paperwork. Perfect. Tha

Re: signbit #define'd causes compilation error in octave

* Eric Blake (ebl...@redhat.com) [20111018 23:07]: > But since octave is written in C++, we could avoid the macros and > instead have three overloaded functions named signbit which operate > on the correct types, so as not to pollute the namespace with a > macro. That's why the C++ standard has

Re: gnulib integration how to

On 11/15/11 18:48, Bruno Haible wrote: > I'm running out of time on this now; someone else can comment, please? I agree with your comment about it needing a date and version info. Also, it'd be nice for it to have a "References" or "See also" section at the bottom, that points to the gnulib manua