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).