Re: lib/c++defs.h

[Karl Berry]

whereas the latter is literally copied into
other .h files and therefore does not have a copyright notice

Having a file in a public repo is legally a kind of distribution.
(This is why we're able to increment years in copyright notices on Jan 1,
for those who like to do so. :)

So the files, like all files, should have some kind of copyright
statement.  It could be in an accompanying README rather than in the
file itself.

would be possibly legally confusing if a file has two copyright notices

It's only confusing if the notices conflict.  In which case there is a
real problem.  Not having a notice on a file doesn't eliminate such a 
problem, it just obscures it.

k

Re: capitalization of error messages and option descriptions

[Karl Berry]

I'm quite ambivalent about this rule, often disable it, and
would not mind removing it altogether.

I gather by "this rule" you mean the syntax-check rule.  I agree
completely.

I doubt rms would agree to removing the original statement from
standards.texi, since it's a user-visible convention.  However, it's
clearly intended to apply only to messages of the form
PROGRAM:SRCFILE:LINENO:COLUMN: MESSAGE

Diagnostic messages of other sorts, like:
  Input files contain messages in different encodings, %s and %s among others.

certainly should be capitalized and have periods.  That is indeed a
sentence :).  (Although, switching topics a bit, I wonder if
users might like to have all such errors cast in the above format so
that next-error would do something sensible with them ... anyway ...)

k

Re: Standard error message format

[Karl Berry]

>>fumble: you just fumbled this
I am looking for clarity that the second form is to be avoided and

On the contrary, standards.texi is completely clear that this is the
format to use.  See the Errors node.

we are all in vehement agreement that the third is bogus.
[starting with "Fumble:"]

Yes, we are all in vehement agreement on that.

Re: lib/c++defs.h

[Karl Berry]

The difference between build-aux/c++defs.h and lib/c++defs.h is that
the former contains a copyright notice - because every file we
distribute needs to have a copyright notice -, whereas the latter is
literally copied into other .h files and therefore does not have a
copyright notice -

I realized in the middle of my sleepless night that my reply was pretty
bogus, since the point was that lib/c++defs.h is not in the repo.  Sorry.

However, it still seems as conceptually wrong to me to generate it
without a license notice as to be in the repo without one.

And it also still seems like there is no confusion unless the license
notices conflict, and if they conflict there is a real problem, and
avoiding use of license notice doesn't eliminate that problem.

Thus, unless I'm still muddled (far from impossible), Paul's original
idea seems basically sound ...

> Currently we build
> lib/c++defs.h from build-aux/c++defs.h as part of ordinary
> 'make'.  But lib/c++defs.h is the same on all platforms.
> It would save work for ordinary 'make' if we distributed
> lib/c++defs.h, so that the maintainer can build it rather than
> the builder.  Similarly for lib/warn-on-use.h and lib/arg-nonnull.h.

Re: Emacs local variables sections in files; time-stamping

[Karl Berry]

The minor advantage of having time stamps in the text

Minor?  How else can we have an accurate version number?  Doing it by
hand, or doing anything related to particular vc systems, proved
completely untenable for these widespread files.  That's the whole
reason we introduced the timestamps in the first place, as you know.

it would make sense to remove the Local Variables sections
from the copies installed via gnulib, 

I guess, as a compromise to avoid the "attack vector" (vastly
overstated, seems to me).

since changes to the copies should not update those time stamps.

In principle, I am doubtful.  If someone (mistakenly or on purpose)
edits a downstream config.guess or whatever, it seems like a good thing
to me for the timestamp to change, so it won't be confused with the
upstream original.

k

Re: Emacs local variables sections in files; time-stamping

[Karl Berry]

it's just that this feature of timestamp or checksum text in source
files is more trouble than it's really worth.

Hmm, I'm surprised to find that I don't agree with you.

I find it extremely helpful to have a human-comprehensible version
number embedded in the file.  I am continually dealing with many
instances of (most of) these files, and knowing at a glance whether a
particular instance is up to date saves a ton of time.  A mere checksum
is not the same.  A diff is not the same.  Nothing, so far as I can see,
is the same.  I think this is one old convention of ours that's worth
preserving in this brave new world.

Anyway, from the other mail, it sounds like we'll be able to avoid the
"attack vector" while preserving the timestamps one way or another,
which would certainly be the best outcome.

Best,
karl

vfprintf, scanf portability

[Karl Berry]

The GNU coding standards have had these two items since the beginning.

First:
Don't use the return value of @code{sprintf}.  It returns the number of
characters written on some systems, but not on all systems.

I don't see this mentioned in the Gnulib entry for sprintf at
  http://www.gnu.org/software/gnulib/manual/html_node/sprintf.html
Is it still relevant?

Second:
Be aware that @code{vfprintf} is not always available.

Again, I don't see it mentioned in
  http://www.gnu.org/software/gnulib/manual/html_node/vfprintf.html 
though seemingly nearly every other system has some kind of problem.
Is it still relevant?

(Reuben and I are trying to rewrite that node among others.)

Thanks,
karl

Re: GPLv3 blobs in C

[Karl Berry]

Finally, what is the appropriate license for this file?  

Can you check how gdb's source files are set up?
(show copying, show warranty)
Sorry, I can't easily do so myself just now.

GPLv3 doesn't permit modifications, and I'm not sure removing some
parts of the file and keeping others, and modifying the content to
work in a #define string, is OK.

You aren't modifying the GPL's words.  That's the important thing.  Not
how you chop them up.

karl

Re: Mutilated stdlib.h

[Karl Berry]

Remember to always do a "make distclean" before running gnulib-tool or
autoreconf. Otherwise such things can happen.

1. I see nothing about this in the gnulib manual.  Can the cases when
"make distclean" is necessary be defined/narrowed at all?  

2. It is disheartening to read this.  The autotools go to a lot of
trouble to make it possible to rerun make and rebuild the 
infrastructure without resorting to the big hammer of make *clean.
This is very useful.  So gnulib breaks that now?

Thanks,
k

Re: [PATCH] gendocs.sh: variable referenced before being set

[Karl Berry]

Hi Bruce,

As for the split docbook, I see no reason to remove the variable.  I
moved the definition before use, though.

As for the weird "-", I cannot debug in a vacuum.  Send me your sources.

As for , I didn't think Docbook has any such tag.  Hence
the .  I admit I didn't write that code and don't use
Docbook, just relaying at fifth or sixtieth hand ...

Finally, it is best to post gendocs.sh issues to bug-texinfo.

Best,
karl

Re: announce-gen

[Karl Berry]

If no one else feels strongly enough about this to
speak up, I'm willing to drop the "-", 

I don't feel strongly about it either way, but FWIW, the majority of
Subject: lines in the info-gnu archives for this month use the real
package name and a space.

So, as long as we're talking "coreutils" and not "GNU Coreutils", dash
instead of space seems fine to me.  Whatever.

karl

17 lines matching "^subject:" in buffer 
2011-04/info-gnu/lists.gnu.org/texinfo/archive/misc/~.
 37:Subject: GNU/Hurd 0.401 is released!
153:Subject: GNU libsigsegv 2.10 released
225:Subject: ncurses-5.9
577:Subject: GNU Typist 2.8.5 released
646:Subject: GNU xorriso 1.0.6 released
791:Subject: Gnubik 2.4 is released
893:Subject: coreutils-8.11 released [stable]
   1077:Subject: autoconf-archive-2011.04.12 released [stable]
   1193:Subject: GNU xorriso 1.0.8 released (important bug fix)
   1335:Subject: GNU mtools 4.0.16 released
   1421:Subject: FreeIPMI 1.0.4 Released
   1534:Subject: GNU Parallel 20110411 ('Libya') released
   1661:Subject: Libidn 1.21 released
   1860:Subject: coreutils-8.12 released [stable]
   2043:Subject: new release of 4.5.2 of XBoard
   2130:Subject: GNU Chess 6 released
   2292:Subject: GNU Guile 2.0.1 released

Re: remove 'exit'?

[Karl Berry]

FWIW, I also agree with just removing the module instead of trying to
ever-escalate warnings.  My experience is that few people are likely to
deal with it until it becomes an error regardless of warning.

I would agree even more with keeping the module as an "alias" for stdlib
so as to avoid this seemingly-gratuitious backward incompatibility, but
nobody suggested that, so I guess I won't :).

k

Re: Licensing of modules for libposix

[Karl Berry]

If you're the author (or if all the authors
agree), and you want to relicense your code, you still have that right,

That is correct.  The standard FSF copyright assignment "grants back"
the right to authors to do anything they like with their own code.  So
the kinds of scenarios you describe in your email are ok.

k

Re: do I need "ifdef HAVE_UNISTD_H" if I import unistd?

[Karl Berry]

> warnings about HAVE_ALLOCA_H in ChangeLog, aclocal.m4, and configure.

Why should there ever be a warning about an occurrence of HAVE_ALLOCA_H
in the ChangeLog?  Just wondering.

Re: Dealing with character ranges in grep

[Karl Berry]

I guess I don't follow the purpose of involving glibc now.  Because
whatever changes they might or might not agree to make, they obviously
won't reach user systems for years.  So for anyone to make use of the
new options, it all has to be implemented in gnulib regex anyway.  If
the goal is to minimize the changes (certainly desirable, of course),
could make proposals to glibc afterwards?

I have the impression that we all agree that the best change, in theory,
would be to support equivalence classes along with rational range
interpretation (RRI :).

However, I suspect that isn't implementable in a reasonable time frame
for gawk4.  That's ok; Arnold can always use the code he's got now.
Beyond that, is it reasonably implementable at all in gnulib?

Sorry if I'm being dumb here ...
k

Re: PATH_MAX and test-stat.h

[Karl Berry]

IMHO ...

I suspect that the most useful thing we can do in gnulib is define
PATH_MAX to a non-constant expression on all platforms, 

And intentionally break loads of existing code?
I am highly doubtful that that is "useful"; "painful" sounds more
accurate :).

I am aware that conceptually there is no PATH_MAX on Hurd and no
requirement for it to be a smallish constant, but it seems to me that
any real-world system has to define PATH_MAX as a reasonable constant
simply for compatibility with all the code that has been written with
that assumption over the last 30+ years.

maintainers who want to go in for this can probably achieve the same
sort of effect with a syntax check.

I agree with that, and I would extend it to the idea of PATH_MAX as a
non-constant.  Programmers who want to worry about it are free to do so
(and in GNU we *should* worry about it), but let's not impose it on
everyone.

k

Re: good place for blogging on C/POSIX programming?

[Karl Berry]

Subject: good place for blogging on C/POSIX programming?

Since you asked ...

1. There is advogato.org if you want to just type in blog entries
(simple HTML) and have them posted and be aggregate-able.  (This is
what I do for myself.)

2. Regardless of where you write blogs, planet.gnu.org can easily
include your posts.  Just write Jose Marchesi with the url
(jema...@gnu.org).

3. Since this isn't gnulib specific, I'm not sure about having it in the
gnulib manual.  But maybe it could be a new section about programming
in general, especially if you have other topics in mind.  I agree
with Paul that having it just in a blog entry seems insufficiently
advertised :).

4. I also agree with Paul about posting a news entry in gnulib with a
url to wherever it ends up (your site or the manual or wherever).  In
general, making more use of gnulib's news area (e.g., incompatible
changes, major additions, other milestones) seems like it would be a
good thing.

Hope this is of some value.

Best,
Karl

Re: good place for blogging on C/POSIX programming?

[Karl Berry]

in fact the text I wrote will also be valid and applicable in 5 or 10
years

We can hope.

Until this separate manual exists, I think the best place is the
gnulib manual.

Indeed, I think the gnulib manual is the best place, especially if
gnulib modules are going to be discussed.  I don't see much gain in
introducing the overhead of another manual.

Re: good place for blogging on C/POSIX programming?

[Karl Berry]

Also:  https://savannah.gnu.org/projects/gnu-c-manual/ (not the same

Yes, although that's intended to be a reference for the C language only,
not the C library, let alone POSIX.  So I didn't think it would be
appropriate for extensive portability discussions like Bruno's.

k

Re: PATH_MAX on the Hurd

[Karl Berry]

My impression is that a good deal of code wants PATH_MAX
because it wants to create an array of size
PATH_MAX.

Definitely true.  That is by far the most common use of PATH_MAX in my
experience.

ylwrap in gnulib/build-aux?

[Karl Berry]

Should the ylwrap script be autoupdated in gnulib/build-aux from
automake, like compile/depcomp/etc./etc.?

Thanks,
k

Re: ylwrap in gnulib/build-aux?

[Karl Berry]

But Eric's argument from [1], the ability to get the newest version
between Automake releases, 
[1] http://lists.gnu.org/archive/html/bug-gnulib/2009-03/msg00175.html

Yes.

However, the finicky gnulib hook declines to install it, due to
space/tab madness.  Can someone fix this in the automake sources and
I'll try again?

Thanks,
karl


build-aux/ylwrap:140: space before tab in indent.
+   from="y_tab.c"
build-aux/ylwrap:142: space before tab in indent.
+   if test $from = "y.tab.h"; then
build-aux/ylwrap:143: space before tab in indent.
+ from="y_tab.h"
build-aux/ylwrap:144: space before tab in indent.
+   fi
build-aux/ylwrap:151: space before tab in indent.
+   [\\/]* | ?:[\\/]*) target="$2";;
build-aux/ylwrap:152: space before tab in indent.
+   *) target="../$2";;

Re: Improve sha1sum speed

[Karl Berry]

There are a few files in gnulib that are not copyright of the FSF,

There are?

so would Nicolas and Linus need to assign copyright?

Evidently.

Re: Improve sha1sum speed

[Karl Berry]

only a few, like sinl.c

GNU policy is all or nothing on this.  There shouldn't be any.

Re: [PATCH 1/4] ptsname_r: new module

[Karl Berry]

> +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX
> +5.1, HP-UX 11, IRIX 6.5, Solaris 11 2010-11, Cygwin 1.7.9, mingw, MSVC 
9, BeOS.
>  @end itemize

Could you please break the line after a comma? 

I suggest using @tie{} between os (or program or ...) names and
versions.  That way the line breaks come out ok in both the source and
the output.  Requiring manually broken source lines defeats M-x
fill-paragraph.  It means you have to take account of @tie{} in your
grep, though, of course.

(Also, I suggest MacOSX or MacOS@tie{}X instead of MacOS X, for
precisely the reason you cite.)

k

Re: [PATCH 1/4] ptsname_r: new module

[Karl Berry]

But it reduces the readability of the .texi file, 

True, but it's one of those things you have to do to get correct output.

Basically I was explaining to Eric that he should not use M-x fill-paragraph

I know.  And I was explaining that trying to make a convention "don't
use fill-paragraph" seems doomed to failure to me.  It is reflex with
me to do that, anyway.  Especially if any source line is >79 chars.

I wouldn't want to have half of the spellings be "MacOS X" and the other
half "MacOS@tie{}X".

Indeed.  It would be simpler to use "MacOSX" and avoid the issue
entirely.

Anyway ...

Best,
k

Re: [PATCH 1/4] ptsname_r: new module

[Karl Berry]

As for things like AIX@notie{}5.1 

I don't understand the "no".

just to prevent paragraph fill from 
breaking things

It's not primarily about paragraph fill; that's a side benefit.
The primary purpose is to get good line breaks in the output (and the
source), without having to think about it.

I'll shut up now.

k

Re: [PATCH 1/4] ptsname_r: new module

[Karl Berry]

  - .info output when viewed by the 'info' program in a UTF-8 locale.

Just for the record, Emacs Info is a much more important/widespread
reader than standalone Info.

Personally, I find using any non-7-bit ASCII character when not
absolutely necessary is simply a pain agent.  But I don't expect you to
agree, and that is fine :).

k

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Karl Berry]

Ping Karl...

Sorry, I didn't know I was in the loop here.  Didn't see my name at the
bottom of a 200-line msg with lots of quotes.

Having now read it, I am not sure what the question is.  Maybe it's
this: ChangeLog's of FSF-copyrighted packages must keep the "(tiny
change)" convention as far as I have ever heard.  rms has always very
strongly resisted the idea of putting necessary information into VC
metadata and nowhere else.

On the other hand, any method for creating the "(tiny change)" is
acceptable.

Does that help?  Probably not.  Let me know ...

>> Even if somewhere you've felt "insistence" on this issue,
>> let's just write "request":

"(tiny change)" is more than a request.

k

Re: info readers

[Karl Berry]

Well, can you please give me a hint how to use it? 

C-u M-x info RET
/full/path/to/gnulib.info RET

gnulib.info buffer from fundamental-mode to info-mode.

It might work to say M-x Info-mode RET after visiting gnulib.info, but I
don't know for sure.

I've been working on changing that for 12 years. 

Like I said, I didn't expect you to agree, and wasn't expecting you to
change your decision.  But despite all your efforts, it is a fact that
7-bit ASCII remains the only thing that is 100% portable.

interoperability with other programs. 

By your own admission, it decreases readability across programs, not
increases it.  Anyway ...

k

Re: [PATCH 2/2] gitlog-to-changelog: support 'tiny change' commits.

[Karl Berry]

Can we just take the difference between lines added and lines
removed per patch, and automatically add the (tiny change) annotation
to the generated ChangeLog if that turns out to be 5 or less?  I
tend to think not, 

I tend to agree with you, for the reasons you state.  (Unfortunately.)

I'm also interested in whether you have an opinion on my preference
for 'Copyright-paperwork-required' as the VCS tag, 

Sounds good to me, again for the reasons you state.

k

gnulib copyright method

[Karl Berry]

https://www.gnu.org/software/gnulib/manual/html_node/Copyright.html

which says

The source files always say "GPL", but the real license
specification is in the module description file.

.. which is highly anomalous.  I'm not aware of any other project
anywhere which deliberately puts incomplete licensing in the source
files.  (Thankfully.)

As I recall, this situation came about to placate projects which were
using gnulib without using gnulib-tool, notably coreutils and others
that Paul E and Jim M were working on.  In the years since then, all
those projects (to my knowledge) have started using gnulib-tool.

Even if there is still a gnulib-using project or two not using
gnulib-tool, clarifying the issue of "what's the real copyright" for
once and for all seems much more important to me.  Especially for
gnulib, which is otherwise so pedantically careful about everything.

So how about normalizing gnulib to have the actual license in the source
files?

k

Re: Removing -Wunsuffixed-float-constants, -Wdouble-promotion, -Wformat-zero-length

[Karl Berry]

1) The gcc manual doesn't list all warning flags.

2) The gcc --help=warnings doesn't list all warning flags, although it
   is a different subset than 1).

How about reporting bugs about these things to gcc?

3) Several of the warnings mentioned by gcc --help=warnings does not
   apply to C.

Could also say that a way to autoparse the warnings by language would
be helpful, and describe what we are trying to accomplish.

k

Re: [PATCH 0/4] quotearg improvements

[Karl Berry]

In non-Unicode locales, the left-pointing
grave accent is replaced by the closing quote.  

I am very fond of my ` characters and hate the fact that stupid
standards broke what was the obviously useful thing to do ... but have
nothing substantive to add to the discussion.

If the patch is accepted, I'll follow-up patching standards.texi.

Shouldn't acceptance of the standards.texi change (by rms) come first?
(I have no idea whether rms will accept the change.)

karl

Re: [PATCH 0/4] quotearg improvements

[Karl Berry]

very convincing.

I find the tone quite high-handed.  But never mind.  I don't want to
debate Markus' web pages, it's not germane.

Now, in this particular case, GCC has been doing the experiment:

I know.  And no one I've seen has complained about it (even me; not that
I'm happy about it, but it's a trivial point and my complaints would be
ignored anyway).  So where's the need for more experiments?

In general, you probably don't want to put into standards.texi rules
that have never been experimented, and never been tried on real
users?

It's one thing when the standards do not address an issue.  But in this
case, quoting characters in the C locale is specifically addressed, and
the proposal runs directly against it.

I fail to see why it's preferable to implement it in the name of
"experimentation" instead of simply asking rms the question.

karl

Re: [PATCH] standards: rewrite section on quoting

[Karl Berry]

use "X" when X should be translated, and 'X' when X should
not be translated.

I don't see that clearly stated in the patch.  I can try to add it if
you wish (if I'm not just missing it, quite possible).

-(Fexecute_extended_command): Deal with `keymap' property.
+(Fexecute_extended_command): Deal with keymap property.

This loses information.  Before, it was clear that `keymap' was an
identifier; now it isn't.  I think it should be 'keymap', in this new
world.

k

Re: [PATCH 3/3] Fix minor quoting issues, mostly with `. [in gnulib documentation]

[Karl Berry]

and something like the proposed patch to standards.texi
.

FWIW, I sent it to rms a couple days ago.  No reply yet.

-Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type @samp{show 
w}.

Regardless of what he decides in general, I don't think it is worth
thinking about changing the (L)GPL sources for mere quoting changes.  If
someone feels differently, *they* can ask rms :).

k

Re: [PATCH] standards: rewrite section on quoting

[Karl Berry]

And attached is a slightly-updated proposal for standards.texi,

rms accepted the new 'quoting' or "quoting" regime.  I installed it last
night.  I'll make an announcement about this and other
standards/maintain changes later today.

BTW, I left out the typographical changes of `s' to ``s'' since that's
an independent issue, and honestly, I've seen it both ways forever on
tiny fragments like that, even in the US, and Texinfo uses single quotes
in similar circumstances (that is, for @samp).

k

Re: update-copyright request and patch...

[Karl Berry]

I just want to go one step
further and just collapse all years into one single range, based on
the fact that I have verified that we have made significant changes
to at least one file each year since 1986.

Based on my conversations with rms about this, I feel safe to say that
that is fine.  Just add the note to the README, as Jim described.

k

Re: [PATCH 2/8] maint: remove empty lines at EOF, but excluding modules/*

[Karl Berry]

However, I am optimistic that I will be able to make matching
changes upstream.

Sorry, but for myself, I think it is a terrible waste of time to be
thinking about this for fdl*.texi.  The blank lines don't hurt anything
and you're not supposed to be modifying those files, so can't we just
leave them alone?  Argh.

As for these files:

>> * doc/Copyright/assign.translation.manual: Remove empty lines at EOF.
>> * doc/Copyright/request-assign.future: Likewise.
>> * doc/Copyright/request-disclaim.changes: Likewise.

The originals of those files live on some inaccessible FSF machine
somewhere, as far as I know.  You're not really going to take up
Donald's time with such a thing, are you?

Painfully,
karl

cvs access to gnulib?

[Karl Berry]

Was the cvs access to git intentionally shut down?
(Sorry if I missed the announcement.)
As of some time ago -- looks like it might have been six months, call me
late! -- I am seeing:

cvs [update aborted]: connect to [pserver.git.sv.gnu.org]:2401 failed:
Connection timed out

That is, :pserver:anonym...@pserver.git.sv.gnu.org:/gnulib.git.

Alternatively, is it possible to tell git "I only want to clone one
subdirectory" (namely build-aux)?  All the incantations I tried failed.

Thanks,
karl

Re: cvs access to gnulib?

[Karl Berry]

git archive --remote=git.sv.gnu.org:/srv/git/gnulib.git \
refs/heads/master build-aux > build-aux.tar

It works!  Thank you Ben!!

(Also thanks to Bruno for all the other info.)

k

fsf address change (not)

[Karl Berry]

FYI, the recent FSF address "change" turns out to be a no-op.
I suggested to Brett that the /about/contact page say so, to avoid
further confusion about the discrepancy.

k


Date: Wed, 15 Feb 2012 12:25:39 -0500
From: Brett Smith
To: Karl Berry 
Subject: Re: fsf address change

On 02/11/2012 12:18 PM, Karl Berry wrote:
> I haven't seen any announcements, but from
> http://www.fsf.org/about/contact/ I gather the FSF physical address has
> changed.  The zip code is now 02110-1335 instead of 02110-1301.  (And
> there is Suite 500 instead of Fifth Floor, though I imagine Fifth Floor
> will keep working.)

The "Fifth Floor"/"Suite 500" distinction is meaningless; we regularly
get mail at both addresses, as well as other variants.  It's the
difference between writing "Apartment 1" and "#1".

> So, regarding the many places in the licenses where the address is
> embedded, should we:
> 1) update the physical address.
> 2) replace the physical address with the url
>(http://www.gnu.org/licenses/) that we have in GPLv3. 
> 3) do nothing.
> 4) ?

According to <http://zip4.usps.com/>, -1301 is still a valid +4 for our
address, just slightly less specific.  So I vote we do nothing.

copyright years breaking sync with automake

[Karl Berry]

The following files are/were all synced from automake.  They had their
copyright years unified in gnulib.  But not in automake.  Can this be
resolved one way or another, please?

   build-aux/ar-lib
   build-aux/compile
   build-aux/depcomp
   build-aux/elisp-comp
   build-aux/mdate-sh
   build-aux/missing
   build-aux/ylwrap

karl

Re: untabify - last call for objections

[Karl Berry]

*** README.orig 2009-12-09 20:16:50.0 +0100
--- README  2009-12-09 19:36:18.0 +0100

How about adding everything in README to gnulib.texi, and generating it?

The README grows and grows, in both length and importance ...

Re: untabify - last call for objections

[Karl Berry]

I'm not sure `indent` is being kept up to date TBH.

As Simon mentioned, David Ingamells released indent 2.2.10 early this
year after a lapse of some years.  So perhaps sending a report to
bug-indent about the missing type definitions, etc. would have some
effect.

-l80

I strongly suggest 79; I'd hate 80, myself.  Indent's default of 78 also
seems ok to me here.

Best,
Karl

Re: maint.mk: heads-up: ftpmirror urls are not quick to be updated

[Karl Berry]

I uploaded coreutils several hours ago, and the http://ftpmirror.gnu.org...
URL that went into my announcement template still is not yet valid.

A few hours is not enough.  Most mirrors update once a day.

Re: maint.mk: heads-up: ftpmirror urls are not quick to be updated

[Karl Berry]

Can mirrors be updated more frequently like every 6 hours, 

The answer is, basically, no.  For starters, we'd have to contact mirror
admins and ask them to change.  Not easy, or fun.

Second, we'd have to push ftp.gnu.org to ibiblio more often, and doing
anything with that connection is such a headache that I don't want to go
there.

Third, even if all that happens, it is inevitable that some mirrors will
be unwilling or unable to implement it.

Fourth, even for those mirrors who do implement it, I doubt six hours
would be fast enough for you guys.  I don't get the impression anything
but up-to-the-minute replication would be fast enough, and that's not
going to happen.

or avoid in some way to redirect to a mirror that wasn't updated
after the requested file mtime?

Technically, it's possible, since anything's possible.  But the current
redirection mechanism won't do it and I doubt Randy wants to implement
it.  It's also not clear to me that it would really be the answer, or
just get us in deeper.  Imperfect net connections are a main source of
problems, so the checks themselves could cause more trouble.

I guess I didn't make it clear, but the expectation of ftpmirror.gnu.org
was never that it would be perfectly up to the minute, or hour.  The
idea is that most people do not both (a) read an announcement and (b)
dory the download within a few minutes of the announcement being sent.
If the few people who do (like most of us on this list, probably) all go
to ftp.gnu.org, that won't matter.

Probably the most important thing for ftpmirror is to use it on the web
pages, where people are downloading asynchronously from the announcement
and ftpmirror will likely work fine.

Sigh.

Re: btwowc(EOF) hang with gcc 4.4.2

[Karl Berry]

[Limiting to gnulib]

+  - Don't use the flags -std=c99 or -std=gnu99.

This is not a realistic option as far as I can tell.  As the user, I
never specified -std=gnu99.  coreutils and/or gnulib and/or gcc
"helpfully" inserted it somewhere, somehow.  I have no practical way
(that I can see) to omit it.

Thanks to all for the follow-up on my obscure issue ...

Re: btwowc(EOF) hang with gcc 4.4.2

[Karl Berry]

> correctly, then if your gcc supports -fgnu89-inline, you can work around 
the 
> issue by specifying CFLAGS='-fgnu89-inline' at configure time.

Thanks.

By the way, I don't have it 100% nailed down yet, but it seems likely
that the fixed wchar.h was not installed (it did get built) because I
did the build in the source directory, despite the gcc doc saying they
don't like this approach (though it's still supposed to be supported).
Probably no one else will ever have this particular confluence of
circumstances ... sorry to wake up everyone.

Best,
k

Re: copyright question on recent autoupdate

[Karl Berry]

I just noticed that with the recent autoupdate, config.sub now has a
copyright of 2010 but a timestamp of 2009-12-30 two lines later.  It
looks rather awkward.  Is there any legal issue with listing a
copyright year too soon?

It seems suboptimal, but I can't imagine that it's a substantive
problem.  And since the issue is going to disappear with the next
config.* update, I vote we ignore it.  If you like, you could ask Ben to
push out another change just to get the years in sync :).

Re: maint.mk and NEWS footer

[Karl Berry]

Copyright (C) 1992, 1993, 1994, 2004, 2005, 2006, 2007, 2008, 2009, 2010
Free Software Foundation, Inc.
[becoming]
Copyright (C) 2001-2010 Free Software Foundation, Inc.

Such a change would be quite undesirable, IMHO.

So I'm glad you found another approach.

junk mail on bug-gnulib

[Karl Berry]

Date: Thu, 14 Jan 2010 17:03:12 +
From: Admin Junk Summary 
To: "bug-gnulib@gnu.org" 

FYI, this made it through to the list because bug-gnulib@gnu.org was
mistakenly on the list of approved senders (from a long long time ago).
I've removed it.

Re: copyright statement

[Karl Berry]

Hi Ralf and all,

I don't know if there is either legal or by-convention significance to

There is no significance to the whitespace in the copyright "line".
(Nor does it have to be on one physical line.)

At Jim's suggestion, I replaced the two spaces with one in
maintain.texi.

I do remember patches to explicitly add back those two spaces
to some GNU projects.  

I guess I wasn't involved, or have forgotten.  At any rate, FWIW, I
can't imagine an important reason for it.

Not even a '(C)', oops!  

(C) is neither required nor forbidden.  I tend to omit it in new files,
saving three more characters for those pesky year lists :).  I just
changed the maintain.texi text along those lines.

Re: Gnulib TP template out of date?

[Karl Berry]

Unfortunately, the POT file is very out of date
(http://translationproject.org/POT-files/gnulib-1.0.0.1991.dbebf.pot

Gnulib folks -- perhaps we should set up a cron job to update it
monthly, or some such?

Unfortunately I don't know how the previous pot was generated.  Maybe
a Makefile could be supplied with a "pot" target, or something?

k

Re: gnulib module install

[Karl Berry]

What I mean - I wouldn't mind commiting gnulib stuff to VCS, but only
if I can omit files generated by autoreconf.

FWIW, that is exactly what I do for Texinfo.  It helps my contributors
to not spend time dealing with gnulib, and it helps me because it avoids
gnulib-skew differences between me and my contributors.

Of course, you have to be careful not to commit (and to .vcignore) the
files generated by make, such as lib/foo.h when lib/foo.in.h exists.

Feel free to peruse the Texinfo source repo
(https://savannah.gnu.org/cvs/?group=texinfo) if you're interested.

>From reading the manual, I got the impression that it is strictly the
either-or approach, 

I think the manual (node "VCS Issues") could mention this "middle road"
as a possibility.  As far as I can see, you are correct that it only
describes the all-or-nothing approach now.

If the idea acceptable to the other gnulib folks, I could try to write a
patch for it.

Best,
Karl

Re: gnulib module install

[Karl Berry]

Here's my attempt at describing the third "mixed" approach to Gnulib
sources.  Is it ok?


@node VCS Issues
@section Issues with Version Control Systems

If a project stores its source files in a version control system (VCS),
such as CVS, Subversion, or Git, one needs to decide which files to commit.

In principle, all files created by @code{gnulib-tool}, except
@file{gnulib-cache.m4}, can be treated like generated source files,
like for example a @file{parser.c} file generated from
@file{parser.y}.  Alternatively, they can be considered source files
and updated manually.

Here are the three different approaches in common use.  Each has its
place, and you should use whichever best suits your particular project
and development methods.

@enumerate
@item
In projects which commit all source files, whether generated or not,
into their VCS, the @code{gnulib-tool} generated files should all be
committed.  In this case, you should pass the option
@samp{--no-vc-files} to @code{gnulib-tool}, which avoids alteration of
VCS-related files such as @file{.cvsignore}.

Gnulib also contains files generated by @command{make} (and removed by
@code{make clean}), using information determined by
@command{configure}.  For a Gnulib source file of the form
@file{lib/foo.in.h}, the corresponding @file{lib/foo.h} is such a
@command{make}-generated file.  These should @emph{not} be checked
into the VCS, but instead added to @file{.cvsignore} or equivalent.

@item
In projects which customarily omit from their VCS all files that are
generated from other source files, none of these files and directories
are added into the VCS.  The only file that must be added to the VCS
is @file{gnulib-cache.m4} in the M4 macros directory.  Also, the
script for restoring files not in the VCS, customarily called
@file{autogen.sh} or @file{bootstrap.sh}, will typically contain the
statement for restoring the omitted files:

@smallexample
$ gnulib-tool --update
@end smallexample

The @samp{--update} option operates much like the @samp{--import} option,
but it does not offer the possibility to change the way Gnulib is used.
Also it does not report in the ChangeLogs the files that it had to add
because they were missing.

@item
Some projects take a ``middle road'': they do commit Gnulib source
files as in the first approach, but they do not commit other derived
files, such as a @code{Makefile.in} generated by Automake.  This
increases the size and complexity of the repository, but can help
occasional contributors by not requiring them to have a full Gnulib
checkout to do a build, and all developers by ensuring that all
developers are working with the same version of Gnulib in the
repository.  It also supports multiple Gnulib instances within a
project.  It remains important not to commit the
@command{make}-generated files, as described above.

@end enumerate

Re: copyright years x-z instead of x,y,z

[Karl Berry]

led me to believe there has been a change in recommendations from the
FSF, but apparently there haven't been any.

No, there hasn't, and there never has been.

I have asked Eben.  Let's please hold any further discussion on this
(endlessly repeating) topic until he gets back to me, which (of course)
might be a while.

Re: new syntax-check rule for @acronym?

[Karl Berry]

syntax-check test for this seems useful, to foster harmonization across
GNU packages.  How about the patch below?

I have no objection, certainly.

COPYING text updates

[Karl Berry]

FYI, at Brett's request, I have updated the gnulib/doc/COPYING* files
(and gnu.org, etc.) to not contain tabs.  The only one that did not
changes was COPYINGv3.

Sigh.

Re: portability of 'printf' command

[Karl Berry]

And the reason that I would _like_ to have printf(1) added to the list
of portable tools is because of the number of non-portable shell scripts
that are currently using 'echo -n', which is doomed to failure in some
shells, instead of printf because printf was not listed in the permitted
tools.

About that, echo -n was and never will be portable, have to go through
the tests of -n vs. \c, etc.  I doubt that's news to anyone here :).

I seem to recall that we've already given up on explicitly testing other
things lacking in SunOS 4, though the specifics elude me. 

In any event, I suspect that anyone using such an ancient system *and*
installing a brand-new version of package foo that uses printf in its
autoconfery would also have installed coreutils (or at least sh-utils),
and therefore will have printf after all.

So I'm not seeing a strong argument against this.  Barring objections,
I'll send it on to rms ... except I'll be offline until next Tuesday, so
don't expect anything before next week.

Thanks,
Karl

Re: portability of 'printf' command

[Karl Berry]

Solaris 7 lacks this, so one does not have to go back as far as you
believe.

I fully recognize that people are still running Solaris 7 (and probably
older versions) on mission-critical and other systems.  But, how many of
those systems are (a) installing brand-new GNU packages (which
presumably wouldn't be happening on mission-critical systems) *and*
(b) have *not* previously installed coreutils/sh-utils?

I suspect the answer is zero.  If it's not zero, then it's at least very
rare, and for those times, it's hardly impossible to get printf one way
or another.  Using bash is another possibility.

I'm still not seeing the problematic scenario here.

Being able to depend on basic printf functionality would be a great boon ...

Re: portability of 'printf' command

[Karl Berry]

Hi Harlan,

>From my POV, as long as one can bootstrap to the point where there is a
sufficient base of utilities, all is well.

I agree.

"we can't get there from here".

As has been said: install (say) coreutils-8.4, which does not require
printf.  This gives you printf.  Then proceed.

I still believe this is an epsilon-probability event.  Like most people
here I've updated lots of machines running lots of versions over lots of
years, production and otherwise.  I still cannot fathom a case where
*new* source releases requiring a printf command would be a serious
problem.

k

Re: portability of 'printf' command

[Karl Berry]

rms said fine to adding printf to the list.  It is committed now.

Re: setproctitle()

[Karl Berry]

Hi Peter,

if the FSF needs a copyright assignment, does that not imply that I
no longer get to choose the copyright?

As the author, your desire/recommendation would carry a lot of weight :).
If you want it released under LGPLv2+, I can't imagine there being a
problem with that.

Aside from that: the FSF will also accept a copyright disclaimer,
putting changes in the public domain.  So if that's your preference (as
I think I saw in another message), it is fine.

I can send you the request form to get whichever one you want started,
if no one else has.

Thanks,
Karl

Re: setproctitle()

[Karl Berry]

Yes, from the FSF side of things, having the FSF own the copyright is
handy for upgrading licenses; 

Probably everyone here knows, but for the archives: FSF holding
copyright is about more than being handy for license changes.  It's
about defending the program's copyright in court.  This is what leads to
all the rules about getting assignments, listing authors, etc.

Re: check-news target fails if NEWS file starts with a copyright header

[Karl Berry]

A while ago, Karl encouraged GNU maintainers to just license files like

Well, more precisely, I attempted to clarify rms' recommendation which
has been the intention since the early days of GNU.  I don't make policy
decisions like this myself :).

However, I don't see any particular problem with using the
no-invariant-GFDL, or with putting the copyright at the end of NEWS, if
that's a maintainer's preference.

However however, I also see no harm in looking at the first 20 lines
instead of the first 10 lines to match the version.

My $0.2 :).

karl

Re: _Exit detection

[Karl Berry]

Sorry for my ignorance, but what's the advantage for RCS of using _exit
or _Exit instead of just plain exit() and thus eliminating the
complications?

Re: A little more regex.h pedantry

[Karl Berry]

deprecate the manual setting of those particular fields, 

As I recall, Kathy and I wrote all that based on actual usage (Emacs was
the main thing we looked at).  I am not in favor of "deprecating"
anything that has been around so long, precisely because it has been
around so long.  What is gained?  I hope something besides pedantic
cleanliness.

paticular, `fastmap' can't be set (you have to call
re_compile_fastmap, and `no_sub' can't be set (because re_compile
always overwrites it, as it does newline_anchor).

I certainly can't remember the state of the code 18 years ago, but
simply based on the above quote of what we wrote, I expect that it was
true at the time that fastmap and no_sub could be set.  We wouldn't have
written it otherwise.  So someone broke that in the meantime.  Obviously
life went on.

BTW, if you look for "xx" in regex.texi, you'll see more things that we
didn't finish back then.  And as far as importing it wholesale, I'd be
amazed if the RE_ bit settings and API functions haven't changed (been
added to, at least) since then.

karl

Re: Question about some fields in regex's re_pattern_buffer

[Karl Berry]

two real arguments in favour
of regex.texi are:
  - It less Makefile rules to use it directly, and regex.h changes rarely
enough.

These days, I agree with that.  I think the simplicity of having the doc
not be generated outweighs the automatic sync-ing.  (Back in time, Kathy
and I were actually changing regex.h a lot, so the automatic sync made
sense.)

  - Debian people may have a legal problem if they have to generate a

And more crucially for GNU, rms may have a problem too / require extra
hoops / whatever.  I no longer want to venture to guess his reaction to
any doc/code combination, after having been thoroughly confused by a
recent gcc scenario.

In any case, having the manual under GFDL and the code under LGPL is the
desired state of affairs for GNU, and is a no-brainer if there is no
automatic generation, so let's do it that way.

> Supplementary question: in regexprops-generic.texi, I think that
> having a plain English definition of the various syntaxes obscures the
> fact that each is defined as a strict combination of features. Would
> you be happy if I rewrote the manual as English documentation of each
> feature plus a simple list (possibly automatically generated from
> regex.h) of which features are present in which syntax?

Sounds fine to me.  James can decide if he wants to pick up that version
for findutils or keep using regexprops ...

Thanks (and sorry for the delayed reply),
Karl

Re: characters allowed in --enable-*/--with-*

[Karl Berry]

I was merely musing on my experiences in that initial reply, not making
final proclamations or anything.  Sorry if I gave that impression.  I
realize there are advantages to allowing +, which you have ably
enumerated :).

I'm ok with proposing to rms that + be allowed, along with: -_.A-Za-z

I wasn't actually aware that . was allowed, but it seems ok to me too.

Isn't this an indication that *not* allowing the '+' character makes
it hard for the user to guess? 

Certainly.  If + had been universally supported in all needed contexts
from the beginning, that would have been much better.  We don't live in
that world, though.

In my experience, '+' characters cause no more hassles than '-' and '.'.

I was referring exactly to the endless confusion/speculation by users
about whether + is used literally, or xx, or pp, or plusplus, or some
other variation.  Perhaps allowing + in --with will allow us to reduce
that confusion, instead of increase it.  We'll see.

Just to mention it: of course + is special in one way that - and . are
not: it's used to encode a space in some cases in url's.  (This doesn't
seem like a serious drawback to me as far as --with goes, but just for
the record.)

Thanks,
karl

Re: New auxiliary archive script

[Karl Berry]

could you please adjust your scripts to also autoupdate the 'ar-lib'
script from Automake to Gnulib, 

Sure, done.  Tx.

Re: gnulib.pdf formatting issues

[Karl Berry]

Two suggestions to improve formatting of gnulib.pdf:

I attempted to install both changes.  Thanks.

Re: Question about some fields in regex's re_pattern_buffer

[Karl Berry]

re_set_registers is not documented; there's a note about this. I'd be
happy to write some documentation for that. 

I see no reason not to.  I don't know why we never got to it.

There's also the technique of re-using a registers data structure by
NOT re_compile_fastmap, but using the fastmap member of the struct
directly.

If it still actually works in the current code.

Finally, there's the problem of the non-thread-safety of RE_NO_SUB
which Paolo mentioned; again, I can document that if we're not going
to solve it immediately.

I defer to Paolo on that one.

Thanks much,
karl

Re: Documentation question

[Karl Berry]

[reducing to bug-gnulib]

unhappy with code-generated documentation. 

We can have code-generated documentation *if* you (or someone) writes
rms with a detailed explanation of the situation (I can review any
draft).  He always (to my knowledge) has had various
requests/recommendations for how to proceed.  So it's not forbidden, but
the details of every situation seem to be different, and my guesses
about how to handle them have sometimes been wrong, so I can't be the
advisor :).

karl

Re: Question about some fields in regex's re_pattern_buffer

[Karl Berry]

3. "@comment xx something about leftmost-longest": I found this
comment in the section "Alternation Operator". Since there is already
a paragraph about leftmost-longest matching in general ("What Gets
Matched?"), what was intended here?

Probably we wrote the xx comment before writing the what gets matched
chapter and didn't go back and clean it up.  Seems like the xx can just
be deleted at this point.

6. It is not clear whether "@c xx i'm not sure this is all true
anymore." refers to what precedes or follows it. 

Follows, so I'm glad you investigated that :).

Thanks,
k

Re: failure to build due to ignoring fwrite() result

[Karl Berry]

And it would be better to update the GCS so that they give
reasonable advice also for today's situations, 

Yes, I agree.  Can you propose a patch to bug-standards?


Overall, the point of rms's comments here is/was to state what we all
agree with: we want useful warnings, and don't want useless ones, and we
want code that's as readable as possible, not cluttered with useless
casts or wrappers.  Of course, none of these things are black&white.

The particular text here is one of his instances of more casual writing
in the GCS, not to be taken literally or dogmatically.

Thanks,
k

Re: Updated and completed patches to regex.texi

[Karl Berry]

Date: Fri, 20 Aug 2010 12:04:39 +0100
From: Reuben Thomas 
To: bug-gnulib 
Subject: Updated and completed patches to regex.texi

I (finally) installed these changes.  Thanks much.

Re: failure to build due to ignoring fwrite() result

[Karl Berry]

Here's a proposed rewrite that tries to take all the comments in mind,
while trying to improve the prose a bit.

FWIW, this standards.texi change looked good to me.  I sent it to rms.
Thanks to all.

Re: failure to build due to ignoring fwrite() result

[Karl Berry]

Here's a proposed rewrite that tries to take all the comments in mind,
while trying to improve the prose a bit.

rms was fine with the proposed change to standards.texi.  I installed it.
Thanks.

Re: author names in .c files

[Karl Berry]

First, adding author names to files suggests that there is some
ownership, in copyright terms, 

No, I have to strongly disagree here.  The copyright lines (not to
mention actual signed papers) are what count, not random commentary
lines.

new contributors tend to leave the existing author lines alone,

Yes, I've observed that as well, though it doesn't seem like a problem
per se to me.

As far as GNU conventions go, if people want to have comments that say
"Original author Foo Bar", that's fine -- it's fairly traditional to do
so in GNU packages, and it can be helpful on occasion, as Jim and Bruno
pointed out.  But if people don't want to have such comments, that's
fine too.  This is not a situation that has to have one right answer.

karl

Re: build-aux confusion

[Karl Berry]

Honestly, what is the problem with gnulib-tool? Why do you find it
hard to understand?

Personally, I think g-t is about as well written as anything of its size
and purpose could be, but 6000 lines of anything is not prima facie
obvious and easy to understand, regardless of language.

not easily possible to determine the default value for a variable?! 

Ruben, I commend sh -vx to you :).

k

RE: Fwd: sed porting trouble

[Karl Berry]

Ah, OK, thanks for digging that up. As I mentioned OSS came into
existence in the early 1990s.

Off the subject of these endless pragma issues, but I feel compelled to
point out for the record that rms started GNU in 1983
(http://www.gnu.org/gnu/gnu-history.html).

Granted GNU is not part of "open source" (which started in 1998 afaik;
http://www.gnu.org/philosophy/open-source-misses-the-point.html), but I
suspect you don't technically mean "open source".

Best,
karl

Re: libposix license

[Karl Berry]

> What do you think? Should libposix be LGPL or GPL?

This seems directly analogous to libc to me, ie, it should be LGPL.

Re: [PATCH 1/2] maint: new rule to update copyright year ranges

[Karl Berry]

Thanks.  Those are probably worth excluding manually.
Let's hear what Karl has to say.

Excluding INSTALL* and install.texi from this process sounds good to me.

BTW, is there some reason why install.texi makes the nonstandard
formatting setting:
@firstparagraphindent insert
Personally, I think it would be better to take the default, just because
it's the default, though I can't say I'm too worked up about it.

And, does anyone mind if I remove the @acronym commands from
install.texi, per our too-long prior discussion?

k

copyright year ranges and README.gnulib

[Karl Berry]

Subject: Re: [PATCH 1/2] maint: new rule to update copyright year ranges

This brings up a related topic that belatedly crossed my mind recently.
rms stated an extra requirement of making a statement in the README
about copyright ranges when they are used.  Thus, ever since gnulib
started using ranges, every gnulib-using package has this new
requirement -- unbeknownst to them.

Instead of educating the whole world about this painful point, would it
be feasible to have gnulib-tool create a README.gnulib file in the
"gnulib" directory (wherever the lib and m4 directories it messes with
are)?  I think that (plus a bit of doc) would satisfy both the spirit
and the letter of the requirement.

Thanks,
k

Re: [PATCH 1/2] maint: new rule to update copyright year ranges

[Karl Berry]

It was added explicitly in Autoconf v2.62-95-g02fa53b for better
plaintext rendering, see:
http://lists.gnu.org/archive/html/autoconf-patches/2008-08/msg00132.html
http://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00239.html

Well, sigh.  "better" here is an aesthetic opinion, not a technical
argument.  I don't agree with that judgement, obviously, or the Texinfo
default wouldn't be what it is.

However, I don't really care about the indentation or lack thereof in
the INSTALL file, specifically.  I am being annoyingly persistent about
all this because it just seems wrong to me to override defaults in a
shared source file (as opposed to a per-package manual).

I failed to notice Eric's last change in that thread :(.
(http://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00241.html)
Before that, I saw that Bruno did the inserting via gnulib's Makefile
(the outcome of which I dislike personally but have no systemic
objection to).

So, I'd like to go back to the gnulib Makefile approach, and eradicate
@firstparagraphindent.  Ok with ... whoever cares?  Eric?

As for autoconf/INSTALL syncing with gnulib (the point Eric raised which
led to his change), seems to me you could equally argue that
autoconf/INSTALL should match the style of the autoconf manual.  Anyway,
you can get either way easily enough.  (We could conceivably generate
both flavors of INSTALL in gnulib, which I don't object to, but don't
care about that much either.)

> And, does anyone mind if I remove the @acronym commands from
> install.texi, per our too-long prior discussion?

FWIW, I don't mind, but please do it in upstream Autoconf.

I don't currently have write permission in autoconf.  I could give it to
myself :), but would you mind just doing it instead, since it's such a
trivial change?  (removing @acronym; BTW, @acronym{GNU} is the only
one.)

Thanks,
k

configmake doc?

[Karl Berry]

Should the configmake module be documented in the gnulib manual?

Re: Interix list of mounted file systems.

[Karl Berry]

So, finally, i think assignments are in place :) i didn't receive a
copy of em yet (clerk told me he'll send the copy now a few weeks

Donald sent you the PDF's on Mon Dec 06 18:39:39 2010 (don't know time
zone, maybe US/Eastern).  It was an attachment apparently named
"Duft.627645..tar.gz".  If it's not in your spam, I can send it to you.

ago, but he said they are in place). can we proceed?

Yes.  You have an entry for gnulib in copyright.list now, so you're all
set.

Best,
Karl

Re: [PATCH 1/2] maint: new rule to update copyright year ranges

[Karl Berry]

In other words

Right.  Thanks for reading my screed :).

+0.1 Basic Installation

Oops, thanks for noticing.  It's a temporary bug in the development
makeinfo that I've been using.  I'll regenerate to fix it, no need to
change anything in gnulib.

k

Re: configmake doc?

[Karl Berry]

Currently the doc is in the module description
(lines 13..25 of modules/configmake), which is an unusual place.
Feel free to move it to a new file doc/configmake.texi, 

I did.  Thanks for the specific instructions :).

(Eric/Ralf, you can add a specific reference to the new "configmake"
node from the Automake/Autoconf manuals now if you wish.)

what's a stable release?

[Karl Berry]

In gnulib-intro.texi, I noticed some text:

We also make stable releases every two months, at
@url{http://erislabs.net/ianb/projects/gnulib/}.

I wasn't aware this was being promulgated as an official release that
"we" make.

Anyway, what's stable about it?  As far as I was aware, Gnulib did not
promise any stability of anything at any level or make any attempt to do
anything special every two months.

That is, I thought these tarballs are essentially a snapshot taken for
the convenience of distro people, nothing more.

Thanks,
k

Re: Documentation for the regexp module

[Karl Berry]

I think it would be nice to make the regex module to import a texinfo
file documenting the supported regular expressions syntax 

I agree in principle, but ...

We could get the "Regular Expression Syntax"
chapter in its own file regex-syntax.texi, 

.. this isn't ideal as-is.  There's a bunch of stuff in there referring
to syntax bits.  That's needed as documentation of the library, but
isn't relevant to users.

I fear the ideal would be to actually write new text with users in mind.
But as we all know, the ideal is hard to put into practice.

As an available-now alternative, James (Youngman) developed some
automatically-generated Texinfo for each syntax for findutils.  I'd
suggest going that way for recutils.  I don't remember why we never
generated/imported/exported those docs in gnulibs, but see the findutils
sources for what he did.

POSIX BREs and EREs

And the GNU extensions that we should all be supporting by default :).
Everything except the "Overview" and "Programming with Regex" chapters
looks more or less relevant, modulo the caveats above ...

Best,
k

Re: libgcrypt.m4 gnulib/libgcrypt unsync

[Karl Berry]

Hi Werner - libgcrypt.m4 was modified in gnulib back in September (from
AC_HELP_STRING to AS_HELP_STRING). In theory it's supposed to be synced
with the libgcrypt repository. Should I give up on that, or can you (or
someone) take the change back in libgcrypt? Or maybe you already did and
I don't know where the current development repository? Please advise.

Thanks,
Karl

--- libgcrypt/src/libgcrypt.m4  2020-03-31 09:57:48.0 -0700
+++ gnulib/m4/libgcrypt.m4  2020-09-28 00:24:10.741933569 -0700
@@ -1,3 +1,3 @@
 # libgcrypt.m4 - Autoconf macros to detect libgcrypt
-# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018 g10 Code GmbH
+# Copyright (C) 2002, 2003, 2004, 2011, 2014, 2018, 2020 g10 Code GmbH
 #
@@ -11,3 +11,3 @@
 #
-# Last-changed: 2018-11-13
+# Last-changed: 2020-09-27
 
@@ -32,3 +32,3 @@
   AC_ARG_WITH(libgcrypt-prefix,
-AC_HELP_STRING([--with-libgcrypt-prefix=PFX],
+AS_HELP_STRING([--with-libgcrypt-prefix=PFX],
[prefix where LIBGCRYPT is installed (optional)]),

Re: gmp revision to sync to Gnulib?

[Karl Berry]

I seem to also be using that same "gmp" branch from their repo-usage
page, but I wasn't updating it properly on my machine (fixed now). I
thought something was going awry but failed to track it down. Sorry.

In any case ... I think it's (well past) time for me to bow out of doing
these updates.  I gather you're dealing with it anyway, so will you take
over the commits?

Thanks,
Karl

Re: gmp revision to sync to Gnulib?

[Karl Berry]

I run it from cron nightly. Either I'm in or out :).
Ok, I'll keep doing it ...

Re: bug#48113: Module suggestion: timeout

[Karl Berry]

What do bug-automake people think?

For myself, I have no objection to sprinkling timeout commands through
the Automake test infrastructure wherever appropriate. It's not ever
going to rise to the top of my own list of things to do, though, so if
it's going to happen, you or someone will have to write the patch.

Of course I don't speak for Jim, but from what he's said in the past,
I suspect he is in a similar situation.

No one else has come forward to work on Automake, despite my plea
(https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html),
so I guess that's where we are.

the functionality could be opt-in initially, 

Certainly.

and then after a few years become the default behaviour.

Personally, I think it should be opt-in forever. People could easily
have test suites that need to run for days. I prefer not to
unnecessarily break compatibility.

Thanks,
Karl

Re: bug#56524: doc: timezone offset conversion/info

[Karl Berry]

I installed the attached patch to Gnulib 

Thanks. 

+Simple POSIX rules like this can also specify nonzero Greenwich offsets.

Nothing about this seems "simple" to me :). Anyway.

+More-complex POSIX TZ strings can specify simple daylight saving

There shouldn't be a hyphen after "More". --thanks again, karl.

scratch_buffer.h, scratch_buffer_dupfree.c sync

[Karl Berry]

1) LIBC/include/scratch_buffer.h has introduced some substantial changes
over GNULIB/lib/malloc/scratch_buffer.h. I'm not sure if it is safe
to sync them any more. Especially because:

2) LIBC/nalloc/scratch_buffer_dupfree.c no longer exists.  There is no
such file in libc any more.

Paul, anyone, please advise. -k

Re: scratch_buffer.h, scratch_buffer_dupfree.c sync

[Karl Berry]

Whatever happens, can one of you make the desired changes in gnulib?  I
have never tried to follow the glibc/gnulib stuff. This one is above my
pay grade :). I just blindly sync the changes ... --thanks, karl.