Re: new module 'strerror_r-posix'

2010-11-30 Thread Bruno Haible
There was a small mistake in this new module. Fixed like this: 2010-11-30 Bruno Haible strerror_r-posix: Fix autoconf test. * m4/strerror_r.m4 (gl_FUNC_STRERROR_R): Fix typo. --- m4/strerror_r.m4.orig Tue Nov 30 21:41:37 2010 +++ m4/strerror_r.m4Tue Nov 30 21:41:36

Re: how to update the git repo?

2010-11-30 Thread Ben Pfaff
Bruno Haible writes: > When savannah is back online: Can we make this recommit of past changes in > such a way that existing checkouts continue to work? > - Is it possible if one person who has a clean checkout does a "git push"? > Or will the server reject that push because it contains com

Re: return values of test programs in *.m4 macros

2010-11-30 Thread Eric Blake
On 11/29/2010 08:07 PM, Bruno Haible wrote: > Hi, > > For a long time, we've written our test programs in *.m4 macros in such a way > that when they fail, the return code is 1. > > But often we have several tests, combined in a single program. > Example: m4/utimes.m4. > > Eric's new style is to

Add summary of what posix-modules does

2010-11-30 Thread Reuben Thomas
This patch seems to have been overlooked again. Is there some problem with it? It just adds text to posix-modules --help... -- http://rrt.sc3d.org 0001-Rebase.patch Description: Binary data

Re: how to update the git repo?

2010-11-30 Thread Eric Blake
On 11/29/2010 07:53 PM, Bruno Haible wrote: > Hi Jim, Eric, Ralf, > > Sylvain Beucler writes in : > We're reinstalling the system and restoring the data from a safe backup, > November 24th. > Please prepare to recommit your changes since that date. > > When savannah

how to update the git repo?

2010-11-30 Thread Bruno Haible
Hi Jim, Eric, Ralf, Sylvain Beucler writes in : We're reinstalling the system and restoring the data from a safe backup, November 24th. Please prepare to recommit your changes since that date. When savannah is back online: Can we make this recommit of past changes i

return values of test programs in *.m4 macros

2010-11-30 Thread Bruno Haible
Hi, For a long time, we've written our test programs in *.m4 macros in such a way that when they fail, the return code is 1. But often we have several tests, combined in a single program. Example: m4/utimes.m4. Eric's new style is to use a different return code (1, 2, 3, ...) at every possible f