gnulib-tool and --with-tests

Bruno Haible writes: > $ ./gnulib-tool --test --with-tests parse-duration Using '--test --with-tests' or '--create-testdir --with-tests' is quite common. Is there any reason why --with-tests isn't the default? It seems rare to want to test a module without also wanting to include its self-test

Re: gnumakefile: usable on its own without maintainer-makefile?

Jim Meyering writes: > Simon Josefsson wrote: >> Building the 'gnumakefile' module fails: >> >> http://autobuild.josefsson.org/gnulib-mega/log-201206201113065857000.txt >> >> Looking at that module, I wonder if that module is useful at all without >> maintainer-makefile? It seems GNUmakefile is

Re: [PATCH] gnumakefile: work without maintainer-makefile

Eric Blake writes: > With gnumakefile being an independent module from maintainer-makefile, > we shouldn't have a hard requirement on maint.mk. ... > This is an alternative to merging the 'gnumakefile' and > 'maintainer-makefile' modules. I'm posting it more as a > demonstration that it is possi

Re: posixtm: doesn't like -1 for 32-bit time_t's?

Paul Eggert writes: > On 06/20/2012 10:43 AM, Simon Josefsson wrote: > >> Has this test worked on any 32-bit time_t machines? > > Sure, lots. > >> 190112132045.51 return value mismatch: got 0, expected 1 >> >> and that time corresponds to (time_t) -1. Any ideas? > > That time is corresponds to

Re: [musl] Re: musl bugs found through gnulib

On Wed, Jun 20, 2012 at 03:28:02PM -0400, Rich Felker wrote: > > Replacement of getcwd, because of > > checking whether getcwd handles long file names properly... no, but it is > > partly working This test is failing because musl uses the kernel to resolve the current directory name, and the ke

[PATCH] Do use readlink if available

The main effect of this patch is to make gnulib-tool not spam the terminal with failures from ls. Despite the copious stderr output, files still get linked correctly. 2012-06-20 Bernd Jendrissek gnulib-tool: Use readlink if it is available. * gnulib-tool (func_readlink): Choose

Re: [PATCH] supports_delete_on_close

Hi John, > I'm submitting this patch which Windows users have confirmed fixes a bug > where tempfiles are not deleted. This was caused by failing to initialise > the argument to GetVersionEx, like the MS documentation mandates. Oops, a big blunder, as it could cause stack corruption if the unin

Re: parse-duration test output

Sure. Thank you. I am away from where I can play with the stuff for a couple of days, so likely this weekend On Wed, Jun 20, 2012 at 2:22 PM, Bruno Haible wrote: > Hi Bruce, > > $ ./gnulib-tool --test --with-tests parse-duration > produces as part of the unit test output (on glibc/Linux wit

parse-duration test output

Hi Bruce, $ ./gnulib-tool --test --with-tests parse-duration produces as part of the unit test output (on glibc/Linux with bash 4.2 and other platforms): ../../gltests/test-parse-duration.sh: line 68: warning: here-document at line 52 delimited by end-of-file (wanted `_EOF_') could not parse tim

Re: parse-duration-tests: make it build

Simon Josefsson wrote: > I noticed parse-duration didn't build on its own: > > http://autobuild.josefsson.org/gnulib-mega/log-201206201113809165000.txt > > confirmed by > > ./gnulib-tool --create-testdir --dir t --with-tests parse-duration > > Should be fixed by patch below, which is pushed. T

Re: musl, fdopen test

> > 2012-06-19 Bruno Haible > > > > fdopen: Allow implementations that don't reject invalid fd arguments. > > * m4/fdopen.m4 (gl_FUNC_FDOPEN): Let the test pass if fdopen(-1,...) > > succeeds. > > Reported by Rich Felker . > > Thanks, Bruno. > That patch looks perfect.

Re: posixtm: doesn't like -1 for 32-bit time_t's?

On 06/20/2012 10:43 AM, Simon Josefsson wrote: > Has this test worked on any 32-bit time_t machines? Sure, lots. > 190112132045.51 return value mismatch: got 0, expected 1 > > and that time corresponds to (time_t) -1. Any ideas? That time is corresponds to -2147483649 (i.e., -2**31 - 1), not

Re: [musl] Re: musl bugs found through gnulib

On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > [CCing the musl list] > Isaac Dunham wrote in > : > > musl is designed for standards conformance, > > There is a recipe, in

[PATCH] supports_delete_on_close

I'm submitting this patch which Windows users have confirmed fixes a bug where tempfiles are not deleted. This was caused by failing to initialise the argument to GetVersionEx, like the MS documentation mandates. It seems that there are two identical copies (with the identical bug) of supports_d

[PATCH] gnumakefile: work without maintainer-makefile

With gnumakefile being an independent module from maintainer-makefile, we shouldn't have a hard requirement on maint.mk. * top/GNUmakefile: Let maint.mk be optional. Reported by Simon Josefsson. Signed-off-by: Eric Blake --- This is an alternative to merging the 'gnumakefile' and 'maintainer-ma

posixtm: doesn't like -1 for 32-bit time_t's?

The module file in this build log: http://autobuild.josefsson.org/gnulib-mega/log-201206201100033288000.txt The error is: 190112132045.51 return value mismatch: got 0, expected 1 and that time corresponds to (time_t) -1. Any ideas? This is on a Ubuntu 12.04 LTS system with eglibc 2.15. Has t

Re: gnumakefile: usable on its own without maintainer-makefile?

Simon Josefsson wrote: > Building the 'gnumakefile' module fails: > > http://autobuild.josefsson.org/gnulib-mega/log-201206201113065857000.txt > > Looking at that module, I wonder if that module is useful at all without > maintainer-makefile? It seems GNUmakefile is tightly coupled together > with

gnumakefile: usable on its own without maintainer-makefile?

Building the 'gnumakefile' module fails: http://autobuild.josefsson.org/gnulib-mega/log-201206201113065857000.txt Looking at that module, I wonder if that module is useful at all without maintainer-makefile? It seems GNUmakefile is tightly coupled together with maint.mk. Should GNUmakefile be m

parse-duration-tests: make it build

I noticed parse-duration didn't build on its own: http://autobuild.josefsson.org/gnulib-mega/log-201206201113809165000.txt confirmed by ./gnulib-tool --create-testdir --dir t --with-tests parse-duration Should be fixed by patch below, which is pushed. /Simon >From e9b0ec8cb15c0fe6c1ff98f67a53

Re: [bug-gzip] gzip-1.5 test failures on FreeBSD 9.0 and NetBSD 5.1

On 06/20/2012 08:45 AM, Paul Eggert wrote: > More generally, the problem is that often people use scripts > in Perl or Python or whatnot to run a test, or run a test from > a shell spawned by a terminal emulator, and these scripts > or terminal emulators may execute chdir without updating PWD, > s

Re: [bug-gzip] gzip-1.5 test failures on FreeBSD 9.0 and NetBSD 5.1

On 06/20/2012 07:16 AM, Eric Blake wrote: > do we know which shells suffer from this > POSIX non-compliance bug, and whether they are still in active use Sorry, I don't know of a list of such shells. The problem is documented in the Autoconf manual, without listing shells. I have verified that th

Re: [bug-gzip] gzip-1.5 test failures on FreeBSD 9.0 and NetBSD 5.1

[adding bug-autoconf] On 06/20/2012 08:10 AM, Paul Eggert wrote: > This addresses symptoms of the problem reported by Nelson H.F. Beebe in > . > Although Nelson's bug was not necessarily fixed by this patch, > it seems wise to make

Re: [bug-gzip] gzip-1.5 test failures on FreeBSD 9.0 and NetBSD 5.1

On 06/20/2012 06:38 AM, Nelson H. F. Beebe wrote: > This time, the runs succeeded, without > any infinite loops (though that could be because /usr/local/bin/zdiff > is now the latest version). OK, thanks, I've pushed the following change to gnulib and it should percolate to gzip on the next sync.

Re: [musl] Re: musl bugs found through gnulib

On Tue, Jun 19, 2012 at 10:10:11PM -0600, Eric Blake wrote: > Unfortunately, you are out of date. POSIX _does_ require > duplocale(LC_GLOBAL_LOCALE) to work: > > http://austingroupbugs.net/view.php?id=301 OK. I'll add support. For now all it requires is avoiding dereferencing the pointer, anyway

Re: musl, printf out-of-memory test

Bruno Haible wrote: > Rich Felker wrote: >> The problem was an obscure pointer-arithmetic overflow ... >> where the stack pointer is near the 4GB boundary. > > This explains also why it occurred only with a certain probability > outside gdb, but with 100% probability from within gdb: Apparently gdb

Re: Libvirt / GNULIB failures using Mingw64 toolchain

On Wed, Jun 20, 2012 at 02:11:32AM +0200, Bruno Haible wrote: > Daniel P. Berrange wrote: > > > > CC stdio-read.lo > > > > ../../../gnulib/lib/stdio-read.c:102:1: error: redefinition of 'vscanf' > > > > In file included from ./stdio.h:43:0, > > > > from ../../../gnulib/lib/st

Re: musl, printf out-of-memory test

Rich Felker wrote: > The problem was an obscure pointer-arithmetic overflow ... > where the stack pointer is near the 4GB boundary. This explains also why it occurred only with a certain probability outside gdb, but with 100% probability from within gdb: Apparently gdb runs the program without add