Re: test-fseek fails on W32

2013-04-01 Thread Eric Blake
On 04/01/2013 04:36 PM, LRN wrote: >>> Apparently, the MSVCRT implementation of fseek() is used. >>> If not, then we should fix the m4 tests to filter out the buggy W32 fseek and install the gnulib replacement. >>> >>> I'm unsure of how they work. > >> What does 'grep _FSEEK config.stat

Re: test-fseek fails on W32

2013-04-01 Thread LRN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.04.2013 02:33, Eric Blake wrote: > On 04/01/2013 04:25 PM, LRN wrote: >>> That should be fixed, since a seek succeeding on a pipe is >>> contrary to POSIX. Is fseek being replaced on W32? >> The package that hosts the instance of gnulib on which

Re: test-fseek fails on W32

2013-04-01 Thread LRN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.04.2013 02:34, Eric Blake wrote: > On 04/01/2013 04:25 PM, LRN wrote: >> The package that hosts the instance of gnulib on which the >> failure was observed is GnuTLS-3.1.5. > > What commit of gnulib was in use by this GnuTLS release? Is it a >

Re: test-fseek fails on W32

2013-04-01 Thread Eric Blake
On 04/01/2013 04:25 PM, LRN wrote: > The package that hosts the instance of gnulib on which the failure was > observed is GnuTLS-3.1.5. What commit of gnulib was in use by this GnuTLS release? Is it a case where gnutls needs to pull in a newer version of gnulib, or is it already something fairly

Re: test-fseek fails on W32

2013-04-01 Thread Eric Blake
On 04/01/2013 04:25 PM, LRN wrote: >> That should be fixed, since a seek succeeding on a pipe is contrary >> to POSIX. Is fseek being replaced on W32? > The package that hosts the instance of gnulib on which the failure was > observed is GnuTLS-3.1.5. I'm not sure whether it replaces fseek or > no

Re: test-fseek fails on W32

2013-04-01 Thread LRN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.04.2013 02:10, Eric Blake wrote: > On 04/01/2013 04:04 PM, LRN wrote: >> it does fseek on stdin. That is supposed to succeed when stdin is >> a file, and fail when stdin is a pipe. On W32 it always succeeds, >> even on a pipe, and thus fseek test

Re: test-fseek fails on W32

2013-04-01 Thread Eric Blake
On 04/01/2013 04:04 PM, LRN wrote: > it does fseek on stdin. > That is supposed to succeed when stdin is a file, and fail when stdin > is a pipe. > On W32 it always succeeds, even on a pipe, and thus fseek test fails. > Should that be fixed, or marked as XFAIL on W32? That should be fixed, since a

test-fseek fails on W32

2013-04-01 Thread LRN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it does fseek on stdin. That is supposed to succeed when stdin is a file, and fail when stdin is a pipe. On W32 it always succeeds, even on a pipe, and thus fseek test fails. Should that be fixed, or marked as XFAIL on W32? -BEGIN PGP SIGNATURE

Re: bug#14097: [PATCH] Add support for ISO 8601 basic format

2013-04-01 Thread Mihai Capotă
On Mon, Apr 1, 2013 at 2:51 PM, Eric Blake wrote: > This patch is non-trivial in size. I stopped reviewing here; we would > need to have copyright assignment on file to take this patch from you. > Is this still something you are interested in pursuing? Yes, it is. I will take care of the copyrig

Re: bug#14097: [PATCH] Add support for ISO 8601 basic format

2013-04-01 Thread Eric Blake
On 03/30/2013 01:18 PM, Mihai Capotă wrote: > The parser now accepts the basic format for combined date and time > representations, which ommits the date and time separators, "-" and ":". s/ommits/omits/ > > See bug 23767 for GNU coreutils, . > > * lib/pars

[PATCH] human: add unambiguous block_size_args

2013-04-01 Thread Mihai Capotă
The units used in the outputs of "human-readable" and "si" look identical when "K/k" is not present. Add two block_size_args, "binary" and "decimal", that disambiguate between the outputs of "human-readable" and "si" by adding human_B to the list of options. See bug 7176 in GNU coreutils,