Re: [PATCH]: Parse ISO 8601 extended date and time of day format

[Jim Meyering]

J.T. Conklin wrote:

> Jim Meyering  writes:
>> I would change two doc-related things:
>>
>>   [...]
>>
>>   - I noticed that the new format  "T" 
>> is not documented.  There's already a sentence or two on the
>> @sc{iso} 8601 date format.  Dare I ask? ... Would you care
>> to add a few words about the new one?  If so, and if you send
>> me a simple patch, I'll merge it into the existing commit.
>
> Hi Jim,
>
> While parse-datetime.texi's "Calendar date items" section has some
> text on ISO 8601 dates, since the new format combines both date and
> time, I have some doubts whether that is the best place to document
> it.  Since the grammar introduces a new item type, I think we could
> create a new "Calendar date plus time of day items".  Right now, it
> would only document support for ISO 8601 extended date and time of
> day formats.  But when/if we add support for basic date and time of
> day format (or any other format that can't be supported by separate
> date and time items), we'll have a place for it.
>
> Thoughts?

That sounds fine.  Thanks!

Re: [PATCH 8/8] fts: do not exhaust memory when processing million-entry directories

[Jim Meyering]

Jim Meyering wrote:
> Paul Eggert wrote:
>> Thanks for all that work to make fts better!  A couple of minor things
>> about comments:
>>
>> On 08/18/2011 06:53 AM, Jim Meyering wrote:
>>
>>> +   into memory at once.  However, When an fts_compar function
>>
>> The "However," can be removed (there are too many Buts etc. in the
>> neighborhood already ...).

Removed.  Thanks.

>>> +   The other conditionals ensure
>>> +   that we are using the *at functions (FTS_CWDFD) and that we
>>> +   are not in no-chdir mode (induced by use of FTS_LOGICAL).  */
>>
>> Are these other conditionals independent of whether we want to avoid
>> putting too many entries in RAM?  If so, perhaps we should remove these
>> other conditionals; if not, it'd help for the comment to explain why not.
>
> Initially I didn't even write that "The other conditionals..." sentence.
> I agree that it doesn't say enough.  The main motivation was to solve
> the problems that were most common, and to avoid getting bogged down in
> the less-common use cases.  Already, this change is defending against
> something very unusual: applying common tools to directories with
> millions of entries.  Worrying about applying "du -L" (FTS_LOGICAL)
> on such a directory is far lower priority.
>
> I'll add a FIXME saying that we should try to remove those conditionals,
> but that doing so will require careful testing of those less-common
> use cases.  Actually, as I write this, I confess I'm thinking that the
> marginal gain is not worth the risk.

However ;-)

Everything appears to work fine even without those two conditionals
(retested via coreutils and find, both with the default
FTS_MAX_READDIR_ENTRIES and using a value of 2, and a few
manual uses of du -L vs. large directories),
so I'm merging in the change below.

Thanks for the prod.


diff --git a/lib/fts.c b/lib/fts.c
index 736350e..e3829f3 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -1329,19 +1329,15 @@ fts_build (register FTS *sp, int type)
   }
   }

-/* Maximum number of readdir entries to read at one time.
-   This limitation is to avoid reading millions of entries
-   into memory at once.  However, When an fts_compar function
-   is specified, we have no choice: we must read all entries
-   into memory before calling that function.  But when no such
-   function is specified, we can read entries in batches that are
-   large enough to help us with inode-sorting, yet not so large
-   that we risk exhausting memory.  The other conditionals ensure
-   that we are using the *at functions (FTS_CWDFD) and that we
-   are not in no-chdir mode (induced by use of FTS_LOGICAL).  */
-size_t max_entries =
-  (sp->fts_compar == NULL && ISSET (FTS_CWDFD) && ! ISSET (FTS_NOCHDIR)
-   ? FTS_MAX_READDIR_ENTRIES : SIZE_MAX);
+/* Maximum number of readdir entries to read at one time.  This
+   limitation is to avoid reading millions of entries into memory
+   at once.  When an fts_compar function is specified, we have no
+   choice: we must read all entries into memory before calling that
+   function.  But when no such function is specified, we can read
+   entries in batches that are large enough to help us with inode-
+   sorting, yet not so large that we risk exhausting memory.  */
+size_t max_entries = (sp->fts_compar == NULL
+  ? FTS_MAX_READDIR_ENTRIES : SIZE_MAX);

 /*
  * Nlinks is the number of possible entries of type directory in the

Re: CLISP does not compile on MinGW with latest gnulib

[Michael Kappert]

> Von: Eric Blake 
> An: Michael Kappert 
> CC: bug-gnulib@gnu.org
> Betreff: Re: CLISP does not compile on MinGW with latest gnulib

> On 08/18/2011 09:50 AM, Michael Kappert wrote:
> > Hi,
> >
> > When trying to compileCLISP  on MinGW,
> > make fails with
> >
> > libgnu.a(regex.o): In function `rpl_regerror':
> >
> c:\users\michael\repo\clisp\build.test\gllib/../../src/gllib/regcomp.c:559:
> > undefined reference to `libintl_gettext'
> 
> Sounds like your Makefile.am is not linking in the libintl/libiconv 
> libraries correctly.  Make sure $(LIBINTL) (or $(LTLIBINTL) if using 
> libtool) is being added to the link line of your program, per the 
> recommendations of the Link: section of the regex module.

Ok, thanks. Turns out this was indeed an error in the link command line.

Michael

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

wget fails to build under HP-UX 11.00

[Giuseppe Scrivano]

Hello,

The following bug report was sent to the wget mailing list, I am not
sure why it happens, it seems related to gnulib, has anyone an idea
about it?

I don't have access to any HP-UX box to test it by myself.

Thanks,
Giuseppe

> With HP-UX 11.00 and HP C-ANSI-C it doesn't even *compile* anymore!
>
> $ ./configure --prefix=/pro --disable-nls --with-ssl=openssl 
> --without-libiconv-prefix --without-libintl-prefix --without-libgnutls-prefix
> :
> $ make
> :
> cc -DHAVE_CONFIG_H -I. -I../src -I/pro/local/include
> -I/usr/local/include -Ae -O2 +Onolimit +Z -z -I/pro/local/include
> -I/usr/local/include -I/usr/include/X11R6 -I/usr/local/X11R6/include
> -I/usr/contrib/X11R6/include -c -o c-ctype.o c-ctype.c
> source='cloexec.c' object='cloexec.o' libtool=no \
> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
> cc -DHAVE_CONFIG_H -I. -I../src -I/pro/local/include
> -I/usr/local/include -Ae -O2 +Onolimit +Z -z -I/pro/local/include
> -I/usr/local/include -I/usr/include/X11R6 -I/usr/local/X11R6/include
> -I/usr/contrib/X11R6/include -c -o cloexec.o cloexec.c
> cpp: "./", line 4: warning 2014: Illegal ^A, ^B, ^C, or ^D in source. Changed 
> to space.
> cpp: "./", line 7: warning 2014: Illegal ^A, ^B, ^C, or ^D in source. Changed 
> to space.
> cpp: "./", line 13: warning 2014: Illegal ^A, ^B, ^C, or ^D in source. 
> Changed to space.
> cpp: "./", line 21: warning 2014: Illegal ^A, ^B, ^C, or ^D in source. 
> Changed to space.
> cc: "", line 2: error 1000: Unexpected symbol: "�".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "�".
> cc: "", line 4: error 1000: Unexpected symbol: "�".
> cc: "", line 4: error 1000: Unexpected symbol: ".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "|".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "".
> cc: "", line 4: error 1000: Unexpected symbol: "`".
> cc: "", line 6: error 1000: Unexpected symbol: "".
> cc: "", line 7: error 1000: Unexpected symbol: "p".
> cc: "", line 13: error 1000: Unexpected symbol: "�".
> cc: "", line 16: error 1000: Unexpected symbol: "".
> cc: "", line 18: error 1000: Unexpected symbol: "".
> cc: "", line 20: error 1000: Unexpected symbol: "".
> cc: "", line 21: error 1000: Unexpected symbol: "$float".
> cc: panic 2017: Cannot recover from earlier errors, terminating.
> make[4]: *** [cloexec.o] Error 1
> make[4]: Leaving directory `/pro/3gl/GNU/wget-1.13.1/lib'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/pro/3gl/GNU/wget-1.13.1/lib'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/pro/3gl/GNU/wget-1.13.1/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/pro/3gl/GNU/wget-1.13.1'
> make: *** [all] Error 2
> Exit 2

Re: [Bug-tar] Improve sparse file scan through extent_scan module

[Eric Blake]

[adding coreutils and bug-gnulib]

On 08/18/2011 07:33 AM, Jeff liu wrote:

Dear developer,

As the fiemap exent-scan module has been added to coreutils for about half 
year, and looks it works stable in the past few releases.

Is it possible to make use of it to improve the current tar sparse file scan 
procedure?


We need to migrate the scanner out of coreutils and into gnulib, at 
which point tar can use it.  Also, be aware that the latest 3.1 kernel 
and glibc.git have added support for SEEK_HOLE and SEEK_DATA, and we 
should prefer those higher-level interfaces over the lower-level extent 
scanners, where possible.



I'd like to work a patch out if you guys like it.


Sure, but it starts on the gnulib side.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: wget fails to build under HP-UX 11.00

[Paul Eggert]

On 08/19/2011 06:23 AM, Giuseppe Scrivano wrote:
> it seems related to gnulib

What makes you think that?  The error came when compiling gnulib
source code, true, but the diagnostic makes it look like there's
an '#include "./"' in config.h, or something like that, which
could well be non-gnulib related.

Re: [Bug-tar] Improve sparse file scan through extent_scan module

[Jeff liu]

Hi Eric,

Thanks for your response!

在 2011-8-19，下午9:42， Eric Blake 写道：

> [adding coreutils and bug-gnulib]
> 
> On 08/18/2011 07:33 AM, Jeff liu wrote:
>> Dear developer,
>> 
>> As the fiemap exent-scan module has been added to coreutils for about half 
>> year, and looks it works stable in the past few releases.
>> 
>> Is it possible to make use of it to improve the current tar sparse file scan 
>> procedure?
> 
> We need to migrate the scanner out of coreutils and into gnulib, at which 
> point tar can use it.  Also, be aware that the latest 3.1 kernel and 
> glibc.git have added support for SEEK_HOLE and SEEK_DATA, and we should 
> prefer those higher-level interfaces over the lower-level extent scanners, 
> where possible.
Yes, I recalled Jim have also mentioned to put extent scan module to gnulib 
first.

Consider SEEK_HOLE/SEEK_DATA,  I have submitted a patch to coreutils which can 
be found at:
http://lists.gnu.org/archive/html/bug-coreutils/2011-04/msg00106.html

At that time, it was wrote for ZFS only, I'll take a look at the kernel and 
glibc for this stuff later.

In the meantime, could anyone give a review?

  
> 
>> I'd like to work a patch out if you guys like it.
> 
> Sure, but it starts on the gnulib side.
Thanks,  let's make it present to gnulib first. :)

Regards,
-Jeff
> 
> -- 
> Eric Blake   ebl...@redhat.com+1-801-349-2682
> Libvirt virtualization library http://libvirt.org

Re: make -q and maintainer-makefile issues?

[Ben Pfaff]

"Bruno Haible"  writes:

> Nevertheless, the gettext package tries to help you do that: It contains
> a file autogen.sh in the tarball, and it explains
>   "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."

I would not have guessed that gettext was incompatible with
Autoconf versions later than 2.65.

Have you considered making gettext warn when its "configure" is
run with a too-new Autoconf?  Perhaps something like this:
  m4_version_prereq(
[2.66], 
[m4_warn([Only Autoconf 2.60..2.65 is supported.])],
[:])
-- 
Ben Pfaff 
http://benpfaff.org

Re: Portability issue for error_tail().

[Bruno Haible]

Paul Eggert wrote:
> portable programs should not pass a NULL format to 'error', so this is not
> a gnulib bug.

Yes. But why does it not yield a GCC warning?

 foo.c =
#include 
#include 
extern void error (int __status, int __errnum, __const char *__format, ...)
  __attribute__ ((__format__ (__printf__, 3, 4)))
#ifdef DECLARE_NONNULL
  __attribute__ ((__nonnull__(3)))
#endif
;

void foo ()
{
  error (EXIT_FAILURE, EPERM, NULL);
}
=

$ gcc -Wformat=2 -c foo.c
$ gcc -Wformat=2 -c foo.c -DDECLARE_NONNULL
foo.c: In function 'foo':
foo.c:12: warning: null argument where non-null required (argument 3)

Should the declaration in glibc's and gnulib's error.h be changed to contain a
__attribute__ ((__nonnull__(3)))  ?

Or should gcc be changed so that  __attribute__ ((__format__ (__printf__, m, 
n)))
implies __attribute__ ((__nonnull__(m))) ?

Bruno

Re: wget fails to build under HP-UX 11.00

[H.Merijn Brand]

On Fri, 19 Aug 2011 21:44:21 +0200, Giuseppe Scrivano
 wrote:

> Paul Eggert  writes:
> 
> > On 08/19/2011 06:23 AM, Giuseppe Scrivano wrote:  
> >> it seems related to gnulib  
> >
> > What makes you think that?  The error came when compiling gnulib
> > source code, true, but the diagnostic makes it look like there's
> > an '#include "./"' in config.h, or something like that, which
> > could well be non-gnulib related.  
> 
> this is the config.h file, I can't see anything that might trigger that
> error.
> 
> Unfortunately I can't test it by myself, so I am only guessing, what
> could be?  Any idea?
> 
> H.Merijn, can you please look for '#include "./"' in the generated files
> you have in you tree?
> 
> ...the next release is just one bug far now :-)

$ ack -l '^\s*#\s*include.*\.\/'
Exit 1
$ grep -r #include * | fgrep ./
Exit 1


-- 
H.Merijn Brand  http://tux.nl  Perl Monger  http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/   http://www.test-smoke.org/
http://qa.perl.org  http://www.goldmark.org/jeff/stupid-disclaimers/

Typo fix for README-release

[Reuben Thomas]

diff --git a/top/README-release b/top/README-release
index 69841d2..0299c82 100644
--- a/top/README-release
+++ b/top/README-release
@@ -40,7 +40,7 @@ Here are most of the steps we (maintainers) follow
when making a release.
 # "TYPE" must be stable, beta or alpha
 make TYPE

-* Test the tarball.  copy it to a few odd-ball systems and ensure that
+* Test the tarball.  Copy it to a few odd-ball systems and ensure that
   it builds and passes all tests.

 * While that's happening, write the release announcement that you will

Changelog:

2011-08-19  Reuben Thomas  

* top/README-release: Fix typo.

(Is this paragraph actually necessary, though? These days, if more
"odd-ball" systems are needed for testing, they should be added to
nix, surely?)

-- 
http://rrt.sc3d.org