Re: FYI: updated to latest gnulib --- almost, but not quite

[Paul Eggert]

On 11/08/2012 11:36 PM, Jim Meyering wrote:
> I saw failures on 2 of 3 "make -j5 check" runs on
> an old 2-core F18/i686+SSD/ext4.  But when I revert the last
> two changes to gnulib's tests/nap.h, I saw 10 successes in a row,
> so I'd revert those if I had more time now.

Feel free to revert them; they're just performance improvements
for the tests, and aren't crucial.  That being said,
I'm not observing problems on my old 2-core host
(Ubuntu 12.04/x86/ext4) nor on my newer 4-core host
(Fedora 17/x86-64/ext4).  I'm not using SSDs.

I have the sneaking suspicion that this whole area is pretty
buggy, and that the updated test (which runs faster) is more
likely to expose race-condition bugs in the underlying system.
Whether this is a win for coreutils is another matter....

BTW I did run into trouble when I tried to reproduce the problem.
I followed the instructions in README-hacking:

        $ ./bootstrap
        $ git submodule foreach git pull origin master
        $ git commit -m 'build: update gnulib submodule to latest' gnulib

but the "make check" immediately failed because of the
public-submodule-commit rule.  I worked around this by
commenting out that rule's body.  Is there some better way
to try out the latest gnulib these days?

Also, I ran into a problem with the gnulib getlogin test
(I fixed by gnulib checkin
<http://lists.gnu.org/archive/html/bug-gnulib/2012-11/msg00049.html>)
and found a couple of problems in the recently added df test
(I fixed with coreutils git commit
a395b637a62a380f2d11e12f8c9e0eceb9e86a8f).