When I ran gettextize to update the hello sources to gettext 0.14.5, it
added build-aux/mkinstalldirs to the top-level EXTRA_DIST.
mkinstalldirs was not an included file in the gnulib gettext module
(I'd previously run gnulib-tool --import). So it seems either it
should be added in gnulib, or
A GNU package should not refer the user to any
non-free documentation for free software.
As far as this issue goes ...
The coding standards themselves mention Standard C. The C Standard is
not free documentation. Admittedly there is no direct link or citation,
but I don't see why
Hi James,
It might be worth pointing out that all valid ASCII files are valid
UTF-8 files, but not all valid Latin-1 files are valid UTF-8 files.
Thanks for the suggestion. I'm glad to know this myself (I thought it
was the case, but didn't know the specifics), but since rms does not
I believe that the standard should probably
suggest a preferred alternative.
Yeah, you're probably right. I was trying to avoid dissension I suspect
there are some GNU'ers who will hate the idea of using `), but it's
likely unavoidable :). Guess I'll try changing the first either to
Hi Simon,
Thanks for the note.
Are they mutual exclusive, or should they
be used in combination? Those things aren't clear to me.
They aren't clear to me either, but I *think* they can be used in
combination. That is, if you use the gnulib quote module or equivalent,
then you could
This is misleading.
I know, but I'm not sure what to say. Just delete the sentence about
Latin1, maybe? I guess it's not really necessary.
To represent them, you need Unicode, i.e. the UTF-8 encoding.
Yes, but rms has explicitly rejected (in previous email with me) the
idea of
to educated people it recommends Unicode, without mentioning it explicitly.
True. I do not know how else to write it. (I'm also not sure rms will
go for it at all.)
That depends on your mailer. Is it a package in Emacs, or is it 'pine'
without Bernhard Kaindl's patches?
My
The main point is that it transmits the perception that
Now I understand. Thanks.
These two paragraphs seem out of place:
I had been thinking of that as referring only to quotation characters,
but I see that you are right. Not sure what rms will think, but it does
seem cleaner to
the text pass. Are there other arguments that might
persuade him?
3) I deleted the sentence. Draft appended.
Thanks,
k
Date: Sun, 12 Jun 2005 15:57:57 -0400
From: Richard Stallman [EMAIL PROTECTED]
To: [EMAIL PROTECTED] (Karl Berry)
Subject: Re: quotation characters
Sticking to the ASCII
| the application domain. For example, if source code deals with
| the French Revolutionary calendar, it is OK if its literal strings
Sounds good, thanks.
I assume you mean punt the 'preferably'?
Actually I meant point out, ie, our text didn't just give `...' as one
+In case you want to use already existing files, you can have a look at
[EMAIL PROTECTED]://www.gnu.org/software/gnulib/, Gnulib}, a centralized
The English seems fine to me, but since Gnulib has a Texinfo manual, it
seems like it might make sense to use a multi-argument xref instead of
Hi Patrice and all,
I think that the gnulib manual isn't very clear about the use of the macros
Very true. No one has ever sat down and tried to write it as a manual,
just incrementally added stuff, so it's not clear about lots of things,
not to mention not having much of an overall
[lessergnulib]
I remember this discussion (somewhat), but I was and am a bit puzzled.
Is the only purpose is to make the functionality available under the
LGPL?
Because it does not seem good, or necessary, for the same routines to
exist in two different forms. It does not increase freedom,
If it's so hard to convince RMS that modern style is different,
maybe it's easier to convince him to drop this subject.
Please, no. It wasn't rms's idea to bring this up. It was ours (mine),
and the reason is that GNU developers ask the question, repeatedly. I
don't want to go back to
Here is a patch for the gnulib texi manual explaining some things I would
have
liked to see in the manual.
Thanks much, I installed those changes.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
+the GNU General Public License http://www.gnu.org/licenses/gpl.html.\n\
I've never seen a url in this message before, for any program. Not that
I object, I guess it makes sense, but it seems new? You said you found
this in the coding standards, but I'm not seeing it ... ? Not that it's
a
dnl Copyright (C) 2001-2003 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
What do we call this?
It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
be synced from libc. Are there libc bug reports or anything to
associate with this, or are we just forked?
Thanks,
k
___
bug-gnulib mailing list
bug-gnulib@gnu.org
If we put a similar declaration in error.c, it would cause two
different definitions of program_name, and some non-Unix linkers
reject this. (The C Standard allows them to reject it.)
Is it a problem in practice, ie, what are these non-Unix linkers?
How about defining it in error.c
* doc/standards.texi: Modify examples to show the new usage pattern
for program_name.
1) The fact that this is ensconced in the coding standards makes me
worry more than ever about compatibility. For one thing, why define the
same symbol program_name as a new,
It seems gnulib changes have been made to argp-fmtstream.h,
localcharset.c, previously synced from libc and gettext-runtime
respectively. Should I comment out the sync, or?
Thanks,
k
___
bug-gnulib mailing list
bug-gnulib@gnu.org
First, regarding gnulib-tool --help.
--update isn't mentioned under Operation modes:, although it is one
of the usages.
I suggest mentioning that --import can also be used for updating,
something like this (as I understand it from gnulib-tool.texi):
--import import the given
Hi everyone,
Bruce Korb implemented a library for straightforward config file
parsing (among other things). We thought it would make sense to use it
for GNU Hello, as an example of how it can be done.
Of course, it involves a new Autoconf macro to test whether the library
is available. And of
I would suggest to add this to the GNU coding
standards:
I'm not sure program_name should be in the coding standards. If/since
gnulib functions require it, then I can see that it should be in the
gnulib doc. But programs that don't use gnulib don't necessarily have
to have it. Do they?
configure.ac will have to include:
gl_EARLY
gl_INIT
So, no more gl_SOURCE_BASE and gl_SOURCE_BASE in configure.ac?
(They're still in the doc.)
Thanks much for the help.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
This isn't a gnulib question, but this seems like the best set of people
to ask :) -- I've recently gotten a couple new po files for Texinfo, but
submitted via email instead of through the translation project.
I've been telling them to go through the translation project, but now I
wonder if
Hmm. Just noticed that those files are normally mirrored from
gettext (see gnulib/config/srclist.txt).
Yes, although I haven't autoupdated yet because of those differences.
Bruno, would you accept Ralf's patch so we don't have to
decouple those files?
Per Bruno, the
Turbulent history?
Of Francois, rms, and GNU.
While we're on the subject, is the translation project on hiatus
I don't know. Unfortunately I've lost track of the individuals who take
care of it; haven't heard anything for a long time. Francois
([EMAIL PROTECTED]) would probably
Hi Loic,
Is frustration :-)
I have shared your frustration.
However, the documentation is so terse
Did you look at gnulib.texi (in cvs)? I agree it is quite terse, but
there is some getting started info there.
What I merely need is to import the config.rpath file from
`file system' over `filesystem'. Automake ships `make-stds.texi'.
I assume some consensus over this rule has been established?
I don't know about consensus, but I think rms decreed it many years ago :).
(Or maybe it was just file name, but anyway ...)
OK to commit this trivial patch
* doc/make-stds.texi: Bump copyright year.
(Command Variables, Directory Variables): Fix spelling
`filesystem' - `file system'.
Got the ok from rms to apply this change (and to apply future typo-like
patches myself without bothering him, yay for that). So I
killing trailing white space
Sure.
one overlong line in the DVI output of standards.texi?
Hmm. I'd rather not hardwire a line break, in principle.
The patch avoids `@/' for the benefit of older texinfo
versions (which are still wide-spread).
But does that matter? The
Hi Ralf,
* doc/standards.texi (System Portability): Spell out `free BSD
variants', instead of using the term `*BSD'.
Before I bother rms with this, can you please explain to me the
objection to *BSD? I'd never heard that before. NetBSD and OpenBSD
don't like being
I thought this was more commonly known
Not by me.
I'm unsure if it's worth bothering.
As always, I'd rather not occupy rms' time if we can avoid it.
In the absence of any clamor to make this tiny change in the GNU
standards.texi, I'd rather skip it.
Thanks,
karl
Hi Michael,
Thanks for writing.
This has the problem that not all languages treat singular and plural
the same way as English.
I see the problem, but what is the solution? Repeating every message
containing a number to have separate cases for so many integers seems
quite impractical.
Karl,
Find here a patch.
Thanks Bruno. I am checking with rms about installing it.
(Sorry for the wide distribution, but I wasn't sure who would be
affected, and wanted to seek advice.)
Eric Blake from m4 (thanks Eric) asked about the coding standards:
And since dvi et. al are not invoked by 'make all', it is not
obvious whether 'make install-dvi' should depend on dvi
I finally started switching to standard gnulib usage in Texinfo. I did
gnulib-tool --import getopt gettext
for starters, did the requisite configure.ac and Makefile.am stuff.
But then, rerunning automake gave me complaints like this:
gnulib/lib/Makefile.am:18: required file
Hi Ralf,
Thanks much.
Where are you finding the energy for all this proofreading :)?!
Are you on the proofreaders@gnu.org list, BTW?
* doc/functions.texi, doc/gnulib-tool.texi, doc/gnulib.texi:
Fix some typos.
I, at least, see no problem with these gnulib changes.
Is it okay to just take some code that was
declared to be in the public domain and redistribute it under the GPL?
Yes. (Or use it in a completely proprietary product, or anything else.)
2) Similarly for texinfo.tex:
It would be better for packages using gnulib to get texinfo.tex from
gnulib. It's (nearly always) newer.
Of course, not all automake-using packages use gnulib. So then getting
texinfo.tex from automake is useful (I guess).
So, does automake refrain from
A few days ago, gnulib-tool --import (or --update) started reporting
gnulib-tool: *** missing --doc-base option
gnulib-tool: *** Stop.
The help msg says doc is supposed to be used as a default, but
apparently not. I looked briefly at the script and surmise that the
default is only effective if
I wanted to add the Gnulib closeout module to Hello. So I ran
gnulib-tool --import closeout
It seemed to run fine (importing lots of other modules as dependencies),
however, closeout.c did not get added to the gnulib Makefile.am (or
Makefile.in or Makefile), apparently because gl_CLOSEOUT
Hi Eric,
I don't know if this is a gendocs.sh bug or a texi2dvi bug.
It's TeX itself, actually.
| ~-\penalty
| [EMAIL PROTECTED] \
~ is an active character in (plain) TeX (the Texinfo equivalent is
@tie{}). Texinfo resets ~ to be a normal character, but the filename
I would remove the old gnulib/m4/gnulib.m4.
Aha! That solved everything.
Perhaps it would be for gnulib-tool to warn if it sees
gnulib/m4/gnulib.m4. Or perhaps it doesn't matter because no other
gnulib users still have one lying around.
Thanks much,
karl
Can you suggest a wording?
Delete the (default \doc\) from the help message, since
evidently it is not so. (Ditto the other dir options, I suppose.)
That was the main thing that misled me.
karl
AC_PROG_RANLIB
This is not needed any more.
Great, thanks.
+This file is free documentation; the Free Software Foundation
+gives unlimited permission to copy and/or distribute it,
+with or without modifications, as long as this notice is preserved.
The text which rms specified for such things (ensconced in
maintain.texi) is:
Copying and
we should be generating it automatically from findutils
My recollection is that James does generate it from findutils, and
checks in the new version to gnulib, or sends it to me, or something
like that. James will inform us, I'm sure.
I am inclined to finesse the license issue by using the
I received a report from Texinfo users (Helge Kretuzmann and Norbert
Preining, cc'd) that the --version output from info just said GNU
General Public License, and that this could be interpreted as meaning
GPL version *1*.
The texinfo tools' --version output comes from the GNU coding standards.
So
License: GPL v2
GNU GPL v2+ ... the + is very important.
The important thing is the URLs, not the abbreviations.
Yes, clearly there has to be something describing what the abbreviations
mean. I'd prefer that to be a url, but it could also be in
standards.texi. I don't know if rms
Number 1 is of course fully specified and would assume nothing. I
think in this case this is most desirable.
One resulting problem is figuring out/maintaining url's for other
licenses. But I guess that's not exactly our problem, as Paul said.
Maybe I will suggest both alternatives to
Please remove the file m4/strerror_r.m4 from hello;
Puzzling. All I ever do is run gnulib-tool, and it's figured out that
other files need to be removed. I wonder why that one wasn't.
Anyway, thanks.
Second, please apply the first patch below.
Ack.
Then, I'd apply the second
Hi Mark,
Thanks for taking a look at this.
Hmmm... It might be nice if there were some kind of a readme that talks
about the non-default location of the m4 directory being in gnulib/m4
Ok, good, I will add something to README.dev about that.
instead of m4 ...
I changed from the
Why would it be help2man's business to deal with cross-compiles?
Agreed.
IMO it is configure's business. What do you think about this patch?
Seems ok to me, but I wonder whether any test is really necessary. As
far as I know coreutils, texinfo, and other packages have used help2man
Here's a fix suggestion, using the x-to-1 script that is in use in
GNU gettext for 5 years.
I'm not sure it's best to add that additional level of
infrastructure/indirection to Hello. E.g., it seems unnecessary to have
a skeleton when all that is being specified is the one-line
It's not theoretical. I invite you to install a cross-compiler and try it.
Sure. By theoretical I meant because so few people cross-compile.
(And even fewer modify the sources. And even fewer than that care that
help2man might fail. I think we might be down to one person in the
world. :)
However, on MinGW all three tests fail because the program outputs CRLF
line endings, while the test suite creates files with LF ending.
(Not sure if you want to worry about this...)
Not sure if I do either. What do other (real) programs do?
I found a typo on the web page, and
Some programs, which produce output from given input
Ack.
accept a --binary option
Ick.
Or produce output with CR/LF always,
Really? That seems wrong to me for Hello (and just about any other
program). Just running hello on a Unixish system shouldn't write a \r!
have the
Can we easily get catfoo (or some equivalent) to produce CRLF files?
I guess I meant, can we get catfoo (or some equivalent) to produce
CRLF files *when hello does*. That is, to get some standard command to
operate in text mode under mingw[/cygwin/whatever]. Does echo also
operate in
the title Copying of gpl.texi makes no sense
I agree, but I don't think we should change the node name in the
canonical gpl.texi. So many manuals already use Copying.
The other title Library Copying is nonsense as well, since
RMS doesn't recomment the LGPL for libraries.
Good
I believe this is a good time to improve things like this.
Well, I see your point, but on the other hand, it doesn't seem good to
me to have two known-different files named gpl.texi. So if we go that
route, I suggest the gnulib file have a different name (gnulib-gpl.texi?).
Also, of course
Is there a way in texinfo to conditionally define a node name?
It's a nice thought, but unfortunately not.
That is, there are conditionals, and other ways to get variable text,
but I fear none of it will work reliably in the context of node names.
Such is life.
k
rms said fine, so I installed the patches to the license Texinfo files
(slightly tweaked) in both gnulib and the (purported) original location,
gnu.org/licenses.
Simon (or anyone), if you want to make a gnulib-gpl.texi or whatever to
change the node name Copying, feel free.
Happy licensing,
karl
@unnumbered - @appendixsec.
Same problem as changing the node name. It would impact all existing
manuals that use gpl.texi, which is a lot. They already have their
node structure set up to assume it's a chapter-level entity.
[EMAIL PROTECTED] License, GNU LGPL
I didn't include this
I think --local-dir together with a context diff is a better solution
I added a couple sentences about this to gnulib.texi. Thanks.
Bruno, or anyone, could you write a few words about --local-dir in
gnulib-tool.texi?
Thanks,
k
with http://directory.fsf.org/gzip.html; no mention there)... which, of
1.3.5 is mentioned on that Directory page as the (devel) release.
Anyway, I wrote rms about the lack of official releases in recent
decades.
k
Subject: Re: hello-2.1.93 internationalization doesn't work
Yikes.
The reason is that HAVE_SETLOCALE is tested, but nowhere defined.
Applied the patch. Thanks.
I put another hello pretest at
ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz).
Maybe someday it'll even be ready for a release :).
Thanks,
Karl
I hope this fulfills the need of an introduction to gnulib.
This is great. Thanks Bruno. I fixed a few Texinfo niglets.
Best,
Karl
(Back on this week-old message, sorry.)
If the GNU coding standards guidelines suggest not to include why
a change was made in a ChangeLog entry, then it should be corrected.
What they suggest is to include the reason for a change as a comment in
the code. From
OK to apply?
Looks good to me.
My (naïve?) understanding is that `miscellanous' is
a rather common spelling error.
That is my understanding also.
In case anyone is not totally bored already, one more time for gettext
0.16 (thanks Bruno)...
ftp://alpha.gnu.org/gnu/hello/hello-2.1.95.tar.bz2 (or .gz)
By the way, a Cygwin user wrote to the Texinfo list, and I asked him to
try make check in hello, and he did (in various modes), and all went
A quick review.
Thanks Paul, I installed that.
Attached is a patch for hello.c.
Thanks Eric, that's much cleaner. I installed it.
the gnulib module exit, to ensure the existence of EXIT_SUCCESS.
Isn't it part of some sufficiently-old standard so that it's not
necessary/recommended?
Solaris release that didn't support atexit
What is it? Using EXIT_SUCCESS, using gnulib to ensure that you have
EXIT_*, using EXIT_* in general?
It = Using EXIT_SUCCESS without using the gnulib exit module. Isn't
EXIT_SUCCESS part of stdlib.h (or something) for a couple of decades now?
Obviously it's no particular problem to
Then your function body isn't dirtied with #if directives,
True, but system.h is :). In this case, I think I'll go for the
#if ENABLE_NLS, not so much because of the potential for warnings, but
because it is two lines of directives vs. six.
Thanks,
karl
I made another pretest of hello, ftp://alpha.gnu.org/gnu/hello. The
only changes are the ones reported here.
When running gnulib-tool --import or --update, there is quite a
long list of #include's. The only modules I've actually specified are
closeout getopt gettext. I imagine that many of the
this change would not force you to learn about or use git.
Granting that git is a zillion times better than cvs, even so, far fewer
people can contribute to a git repository than cvs.
As I understand it, the reason for the proposal is because branches are
supported better in git. But isn't
since no one cares if gzip can't recursively compress or decompress a
hierarchy that's really deep or that contains very long names.
Really?
Well, I guess the deepest things gzip would operate on is distributions
of some sort. That probably doesn't compare to the monstrous stuff you
FYI, maintain.texi in gnulib still says:
Ah, thanks.
Rather than removing the paragraph, I'd prefer if it explained that
the patent expired, and that gif's are now OK. Here is a strawman:
We should probably add something like , but still not recommended; PNG
and JPEG are generally
version numbers we maintain in the .m4 files. They're even worse,
They may be worse in the abstract, but I really hope we don't get rid of
them, ever (even aside from the aclocal question). They have proven
*extremely* useful to me in sorting out auto* problems.
karl
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/10/26 16:20:28 eggert Exp $
Oh. I thought you were talking about the GPL COPYING file. I don't
think that top-level gnulib file should be named COPYING :). I don't
know if I was responsible for that one, but it seems unlikely Paul was
...
Do you really care whether any of the following files (the only ones
affected in gnulib) contain an CVS/RCS-style $Id...$ string?
COPYING
COPYING has no $Id$. What am I missing?
config/srclist-update
config/srclist.txt
config/srclistvars.sh
doc/Makefile
Hi Werner, Mauro, and all,
A generous volunteer (Logan Gabriel, cc'd) has been discussing offering
a long-time project of his for system integrity checking to GNU.
One of the things the project needs is ssl-ish computations,
such as provided by libgcrypt and openssl.
My immediate question is,
have always thought that AIDE is the GNU project for it.
I was unaware of it. It's not a GNU project, as far as I know (not in
the maintainers file), although it is free software. Logan, you should
probably take a look and make sure you're not duplicating effort?
(Mon Dec 18 13:33:01 EST 2006)
Message-Id: [EMAIL PROTECTED]
From: Karl Berry [EMAIL PROTECTED]
Date: Mon, 18 Dec 2006 13:33:04 -0500
Index: ChangeLog
===
RCS file: /sources/gnulib/gnulib/ChangeLog,v
retrieving revision 1.937
retrieving
rms sent me this note. I figured this was the group of people most
likely to have someone able and willing to tackle some regex work.
Anyone want to volunteer?
(Having worked on regex for a couple years back in the late 80's, I have
zero desire to go there again, even for function prototypes. :)
Perhaps the simplest thing to do would be to remove
http://ftp.gnu.org/pub/gnu/regex/,
I doubt rms is thinking of that distribution, which, as you say, is way
obsolete and should be deleted. (Maybe we should move regex.texi to
Gnulib.) I suspect all he cares about is the regex source
Perhaps if he gave the specific problems he ran into, with the
actual compiler output.
Indeed. He was just passing along what someone else sent to him. I
expect rms himself does not have any more info :(.
dropped support for the split-buffer code
So Emacs has to have a forked
The question is merely whether wrapv should be the default
with optimization levels -O0 through -O2.
Perhaps the question of where wrapv gets enabled, together with the
middle ground approach mentioned by Robert Dewar, could be put to the
GCC Steering Committee. (As was already proposed
Documentation is indeed lacking for this topic. Sven, care to write some?
I rewrote the previous msg as doc/error.texi, and just added your point
about program_name and main to it.
Cheers,
k
BTW, Karl, I notice a lot of . log entries in your name. I presume most
are done automatically.
For MODULES.html, yes. Everything else I commit by hand.
name-of-script: regenerate MODULES.html
There is no separate script, and anyway, given below, never mind.
generate it into
It'd be great if you could start doing it already.
Done.
Shouldn't that be 1.2 at least?
Is GFDL 1.1 with no invariant sections accepted by Debian?
Is GFDL 1.2 with no invariant sections accepted by Debian?
As far as I know, yes. More important for a GNU project (seems to me),
the GNU standards say to use 1.2.
(Of course the GNU
+ @item doc/
+ Documentation files are under this copyright:
+
+ @quotation
+ Copyright @copyright{} 2002-2007 Free Software Foundation, [EMAIL
PROTECTED]
I think it would be better not to state the exact license of the doc
files here, but rather give general information,
Meanwhile, I'd like to ask about this unchanged sentence:
The source files always say GPL, but the real license
specification is in the module description file.
I don't understand. Legally, what counts is the license in the actual
source file. You can't point to some other file and say
If we say look yourself in each individual file, how can the
user trust gnulib?
I agree that an overall statement of what licenses gnulib uses is
desirable, including for the doc files. It's only that I think the
documentation should document the licenses, and (must) not *be* the
Why not? If we ensure that every user of the gnulib CVS understands it,
If someone comes across a file for whatever reason (eg, casually
browsing savannah cvs), and they see a license statement in that file,
it is obvious that they will assume that that is the license of the
file. When a
We were syncing strtok_r.c with glibc. Now the change below was made.
Should we revert the change or drop the sync?
Thanks,
k
*** lib/strtok_r.c Sat Jan 27 00:34:48 2007
--- /tmp/strtok_r.c Thu Feb 1 00:34:15 2007
***
*** 1,4
/* Reentrant string tokenizer. Generic
1 - 100 of 431 matches
Mail list logo
