Stefan Monnier mentioned that the FSF copyright form has been recently
updated adding the following clause:
[Additional people we should notify about the progress of the
assignment.]
Gnulib takes its version from fencepost:/gd/gnuorg/Copyright, which is
where the maintainers
I'm using makeinfo 7.1. Maybe that is the difference? That's what I've
had for a while (since it was released), but maybe INSTALL hasn't been
updated since then.
Other than that, my environment has not changed for ages. LC_ALL=C, if
it matters. I didn't do anything different this time than any
Looks like the pragmas recently added to lib/regex.c have not been
installed upstream. I did the sync from libc anyway ... -k
*** lib/regex.c Sun Dec 31 00:26:03 2023
--- /tmp/gnulib.srclist/regex.c Tue Jan 2 00:26:37 2024
***
*** 1,4
/* Extended regular expression matching
+ gendocs: support chapter- and section-level split
Seems sensible to me. Basically making the html-by-node part of the
template conditional along with the other split options?
(Overall, it seems to me that several of these variants are pretty
pointless nowadays, but never mind.)
FWIW, in
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.
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,
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
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
I run it from cron nightly. Either I'm in or out :).
Ok, I'll keep doing it ...
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
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
Looks like libgcrypt.m4 was modified in gnulib a couple days ago (from
AC_HELP_STRING to AS_HELP_STRING), but in theory it's supposed to be
synced with the libgcrypt repository. Help?
--- libgcrypt/src/libgcrypt.m4 2020-03-31 09:57:48.0 -0700
+++ gnulib/m4/libgcrypt.m4 2020-09-28
It would need to be applied upstream (maybe by Karl?).
Not me, these days. Writing bug-standa...@gnu.org is the right thing to do.
It seems to me that the root of the problem is that the fdl-1.3.texi in
www is different from the fdl.texi in gnustandards. This should not ever
have happened
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
I can understand increasing permissions to allow +rx on installation
directories, but why force 755, thus disallowing group writability?
I've never understood this forcing of 755.
I don't think Zack plans to release a new Automake.
Thanks for all your work on this.
Also, I used 2020 for the copyright year. Should that instead be
something like 2007-2020?
Yes. The lone year "2020" stuff is only for the online web pages.
Also, I think the Parent-Version: value should be incremented in
gendocs_template. I'm not sure
Asher and all - the CC-BY-ND (or, previously, "verbatim copying is
allowed") is intended to refer to the web page as posted publicly
(that's why it's visible text), not the gendocs_* template files
themselves.
I suppose there should be commented-out text stating the license of the
template text,
Hi Paul,
How about the attached Automake patch instead?
Thanks much. Clever. Seems good to me. Can you install it in am, please?
Perhaps it is worth a comment that it's desired to create the file with
$cp_umask (not just cp-ing it), in order in ensure $dsttmp is writable,
else strip can
it here to see if anyone had any ideas before we
install it ... --thanks, karl.
From: Karl Berry
To: bug-autom...@gnu.org
Subject: install-sh -s on 555 executable fails
(I'm not on this list, so please keep me in cc if need be.)
It seems that install-sh -s (what automake's install-strip target can
I don't think I have the bits to fiddle with commit hooks
I forgot that Savannah disallows user access to hooks. Sorry.
better just to trim the trailing white space in the
Fair enough. Thanks much for dealing with it. Quite frustrating.
While I was at it, I configured srclist.txt
[Ping? Anyone there?]
Can the gnulib git hook please be changed to allow trailing whitespace
in doc/standards.texi and doc/maintain.texi? rms inserted some and did
not reply to my request to remove it. Unless we want to stop
having these files in gnulib ... --thanks, karl.
build-aux/texinfo.tex
bug-texi...@gnu.org
and doc/maintain.texi.
bug-standa...@gnu.org
I think Karl Berry can do those so I'll CC: him.
Technically I can still commit to the repos, but I think it would be
better if I didn't step in.
(I can't help but remark that backward
I find that traffic on this list is so heavy nowadays (all to the good,
of course), and my involvement with gnulib is so tangential, that I need
to unsubscribe. I have now done so. Please cc me explicitly in the
future in the unlikely event that I need to be in on some mail.
I don't mind
iconv.m4 was updated in gnulib, but purportedly it's supposed to come
from the last gettext release. Remove it from the sync until the next
gettext, I suppose? Daiki, anyone?
(Also, it seems the copyright line should have been updated to include
2017.)
Thanks,
karl
---
As usual, the copyright year update included all synced files (including
licenses), and so as usual everything is now out of sync.
Can the changes in these files be reverted please? --thanks, karl.
build-aux/config.guess Sun Jan 1 09:52:15 2017
build-aux/config.sub Sun Jan 1 09:52:15 2017
Hi Daiki,
That can be done by the attached patch (though it's a bit ugly).
Since you went to the trouble of writing the code, it's certainly
fine by me. Please go ahead and commit that? --thanks, karl.
I assume this is because Karl's procedure, which he runs periodically,
Nightly, for the record ... -k
Hi Daiki (and all),
if srclist-update were aware of the serial numbers of the files.
1) Not all synced files have serial numbers.
2) It's not clear to me that the decision about syncing
should, in principle, be based on serial numbers (or timestamps).
3) Nevertheless I have no particular
However, in periods where only small and safe changes are being made,
The problem from my point of view is that I just see a change and can't
(don't want to) guess if it's "small and safe". If I can't blindly sync
the changes I see, that creates an additional burden that I can't (don't
want
Regarding the sync of gettext files into gnulib and the change to
iconv.m4.
Bruno, you updated iconv.m4 in the gettext dev repo with your change
made in gnulib. However, as I said, gnulib has been synced against
gettext releases, not gettext dev. This was a change I made at Daiki's
suggestion a
Nothing to do for you now.
It's still unresolved. As I said, gnulib gettext is synced from
*released* gettext (ie, the tarball), not development gettext. Should I
switch gnulib to check against development gettext, then? -k
-# iconv.m4 serial 19 (gettext-0.18.2)
+# iconv.m4 serial 20
Bruno - some time ago, Daiki and the crew here made iconv.m4 and the
rest of the gettext files in gnulib synced from the most recent gettext
release. Should I undo that now so gnulib's gettext files are just on
their own again?
RHEL 7
Vast numbers of people run RHEL/CentOS/whatever < 7.
It seems highly unfortunate that the automake changes created a
(seemingly gratuitious) incompatibility :(. -k
was defeated by Perl's ôòø-iôòù support (which, IIUC, says to take all
script args as filenames, hence leaving no room for the script to
check/handle args specially
Untried, but what comes to mind first is to check if ($ARGV eq "--help").
Or, omit the -i,
check for
>
http://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html#gettextize-and-autopoint
[...]
> It is unfortunate that the second practice doesn't really work nowadays,
Probably I'm crazy, but maybe gettext should simply be removed from
gnulib? Then users could
Is there some reason gettext is special here?
Yes. At least in Bruno's time: he was adamant that the gettext files
come as a group from an official release because he did not want partial
updates of "some" files coming through. It seemed reasonable when he
said it.
(Aside: the whole
sync them manually
FWIW, this is precisely what gnulib/config/srclist* is about: keeping
individual files in sync between different places, unrelated to any
"module" concept. It is not gnulib-specific (or git-specific or
anything-specific). -k
I was under the impression that the following .m4 files, list from
gnulib/config/srclist.txt, were still maintained in gnulib, and
therefore should be kept in sync with the latest gettext release, and
not updated in gnulib. (While the other .m4 files in gettext-runtime
are indeed maintained in
Gnulib people - Eli Z reported seeing this familiar shell diagnostic
with the current Texinfo configure:
./configure: line 22339: test: =: unary operator expected
That line turns out to be:
if test $HAVE_MSVC_INVALID_PARAMETER_HANDLER = 1; then
And looking at gnulib/m4, indeed that
Hello gnulib folks,
It looks as if we have out-of-date files in the [texinfo] repository.
Evidently, but I am puzzled as to how it came about. We (I) have always
intended to use gnulib in the recommended way, namely (for the last few
years), gnulib-tool --add-import. So why would a stale
Finally back on this mail from February, sorry.
paul How about the following list of .m4 files to be maintained
paul in gettext?
paul codeset.m4 gettext.m4 iconv.m4 intldir.m4 intl.m4 intlmacosx.m4
paul lcmessage.m4 nls.m4 po.m4
In the past, gettext files were
You got the wrong impression.
Ok, good :).
So please do install the patch.
Done.
k
Ludo: for gendocs.sh, this patch adds a new option --tex by analogy with
--html.
Also update the copyright year in the help msg, which had not been done
before, and one typo in the leading comments.
karl
--- a/build-aux/gendocs.sh
+++ b/build-aux/gendocs.sh
@@ -2,7 +2,7 @@
# gendocs.sh --
Thanks, that all looks good. Any reason you didn't install?
My impression from the last exchange was that Ludo wanted to make all
changes himself.
k
I agree with adding them to srclist.txt
Ok, thanks. Sounds good, I will. So now my question is, are all of the
*.m4 files in gettext-runtime/m4 really maintained in gettext? I.e.,
they should all be added to srclist.txt?
$ ls gettext-0.19.4/gettext-runtime/m4/
ChangeLog gettext.m4
From running gettextize, my understanding is that at least the following
files are maintained in gettext, not gnulib:
M build-aux/config.rpath
M gnulib/m4/gettext.m4
M gnulib/m4/iconv.m4
M gnulib/m4/nls.m4
M gnulib/m4/po.m4
M gnulib/m4/progtest.m4
Paul (I
Paul (I guess) - so can the massive auto-updating of the copyright year
list refrain from touching them?
Sure, just put their names into config/srclist.txt; that's the plan, right?
Bruno never wanted to use the srclist.txt sync mechanism, preferring to
do it by hand, and so far
Quoting doc/Copyright/assign.*.manual:
rms wrote that text 30+ years ago.
If you want to propose changing it, licens...@fsf.org is the place to
start. Gnulib just holds slave copies.
best,
k
As Paul said, certainly no problem with the patches, but
like I said, aside from the changing the maintainer, the texinfo
url/mailing list references in gendocs.sh need to be changed.
k
The copies of config.guess, config.sub, and install.texi, among others,
in gnulib should not get the automatic copyright update since they are
maintained elsewhere. Maybe the massive new year update could somehow
avoid the files listed in config/srclist.txt?
K
Ludo (and all),
0) Since you wanted to take over gendocs, and since (I guess) you wanted
to maintain it in gnulib, do you follow bug-gnulib? I don't see your
address(es), but maybe you read it through gmane or whatever.
1) regarding gendocs_template{,_min}, they were munged by the global
gnulib
as Karl suggested at
I feel the need to clarify that I did not suggest it. My exact words
were that would be fine. In other words, I was willing for it to
happen, since although I find your proposed CSS changes quite wrong, I
didn't (and don't) want to debate it and don't feel it's my place
Sorry, I don't want to lose any more of life to CSS debating.
If you want to take over maintenance of gendocs.sh, that would be fine.
Right now the upstream is in Texinfo, but that is historical -- no one
else wanted to maintain it, so I ended up doing so. It could be
maintained as part of
To the best of my knowledge, you can use --html or override MAKEINFO or
probably other things to get whatever css you want into the gendocs.sh
output. Feel free to do that for your own manuals.
I don't want to change the defaults in any such wholesale way. (I also
don't expect you to agree with
I don't agree with changing the default css in gendocs.sh. (And I also
don't want to debate it, sorry.) If you want to do that for your
manuals, you can use --html or override MAKEINFO or probably other
things.
k
I'd like to ask for your feedback regarding the attached script, which does
the same but pushes updates to the GIT repositories.
My feedback is that instead of being a separate script that is mostly
the same, it seems like it would be better as an option. Even better,
it seems like it would
You didn't volunteer for libiconv- and gettext-related modules
so I reverted their maintainer to 'all';
Daiki has been the maintainer of gettext (the package) for quite some
time, as you know. I asked him about libiconv (the package) in other
email; I'm guessing he'll reply after the
As far as I know, bug-libunistring is still intended to exist
independent of gnulib. At least I have never heard otherwise from
Bruno.
However, Bruno has just today officially stepped down as maintainer of
libunistring, and all his other remaining packages.
Daiki, would you like to become the
* doc/fdl.texi: Fix typo (missing '@').
Somehow this was in fdl.texi but not fdl-1.3.texi.
Oh, good. I apparently failed to copy the updated fdl.texi from
www/licenses to gnustandards, which I used as the master for gnulib's
copy, for convenience, since the FSF didn't want an actual file
1.00rc0
Personally, when I see a version number like that, I'm never sure what
it means. Probably the first rc leading up to 1.00, but maybe it is an
rc for 1.01 after 1.00. And suffixes sort badly in long lists (see,
e.g., http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change
your
http://www.gnu.org/software/gnulib/ to the bug-gnulib mailing list page?
Sounds good. I made that change and a few more.
Thanks,
Karl
Perhaps I'm reading too much into the standards, but that's how
--with-jpeg etc. behave in GNU Emacs 'configure'.
FWIW, I think you are right, and --with should fail if the specified
package is not installed, per the standards text. Alternatively, it
could configure as if the
a licensing violation by linking to both libreadline (GPLv3+)
and a libvirt.so containing virtualbox code (LGPLv2-only) at the same
time (those two licenses are incompatible).
For the record ... as far as I know, LGPLv2, both -only and -later, is
compatible with GPLv-anything (in
No, some Gnulib modules are intended for use only in standalone
applications,
But Paul, as you know, this is precisely not the distinction between
LGPL and GPL (library vs. program) that rms wants for GNU.
http://www.gnu.org/licenses/why-not-lgpl.html
The somewhat-valid argument for the
The difference lies in *non*-glibc functionality offered by gnulib.
Of which there is also plenty, afaik.
k
Date: Mon, 08 Jul 2013 09:48:12 +0900
From: Daiki Ueno u...@gnu.org
bruno The mechanism is to update the .m4 files from gettext to
bruno gnulib once, shortly after a gettext release.
Thanks. So, here is the update from 0.18.3 released yesterday.
Thanks very much, Daiki.
or we can even leave decision to users: if they want to use
pygnulib, they can get it from pygnulib repo
That sounds to me like a very sensible way to go, at present.
I'm also fine with having pygnulib inside gnulib, if (other) people want
that. I just got worried that all of gnulib was
Hi Dimitry (and all),
I don't like to be so negative, but ... I was not aware of any general
agreement on replacing the current gnulib world with a Python-based
world.
Note that gnulib-tool now will be the name for the gnulib-tool.py.
It seems to me that gnulib will become completely
Hi Stefano,
You can use CVS in a read-only way, to retrieve the latest version
from the Git repository, using a command like this:
I deleted that text from the web page, thanks.
Since I reckon nobody in his sane mind is still using CVS to access
to the Gnulib repository,
Is there a portability reason to use 12 vs. just 2 to redirect to stderr?
I don't know of one, and don't see it mentioned in autoconf(Portable Shell).
The gnupload script currently uses both.
Just wondering.
k
Right, thanks for the report. I just made this change (in Texinfo) and
propagated it to gnulib. Let me know if it still fails.
karl
--- gendocs.sh (revision 5220)
+++ gendocs.sh (working copy)
@@ -339,7 +340,16 @@
mv $PACKAGE.html $outdir/
ls -l $outdir/$PACKAGE.html
Hi Paul,
Richard Lloyd (cc'd again) followed up with the info below (on
bug-texinfo).
(Richard: Paul/et al. are not on bug-texinfo, so please keep discussion
on the gnulib/lib/xalloc.h change on this list, bug-gnulib.)
Thanks,
k
Date: Tue, 19 Feb 2013 15:56:41 + (GMT)
From: Richard Lloyd
Hello gnulib,
Richard Lloyd (cc'd) reported this to bug-texinfo:
* gnulib/lib/xalloc.h:
XALLOC_INLINE needed to be be defined as static (rather than extern
inline) to avoid multiple defintions of *alloc() routines. I just
put this in xalloc.h as follows (line 30):
#ifdef __hpux
1. This code isn't used - due to the combination of #if's.
Sorry if I'm missing the point here, but FWIW, my suggestion for
cpp-related debugging is to take the line from make for compiling the
file and change it to:
gcc -E -dD -o foobar ...copy rest of cmdline from make output...
Then
Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ...
sharutils-4.13.3.tar.xz: 939.65 kB 76.84
kB/s
...
Uploading sharutils-4.13.3.tar.xz to ftp.gnu.org:sharutils ...
ncftpput sharutils-4.13.3.tar.xz: server said: Could not create
would be a good first step.
Almost nothing happens on the savannah side. The basic process is a
hook into cvs commit that does (effectively) wget
something.gnu.org/something.cgi where the CGI is maintained by the FSF,
and does all the real work.
Getting visibility into the active code for
Wouldn't it be great if someone could convince the Savannah admin
1) It's not a matter of just changing savannah. There are numerous
(*numerous*) processes involved with web pages repositories, most of
which are written, maintained, and controlled by the FSF sysadmins, not
Savannah. FSF
regexprops-generic. The last one seems to be a mistake,
it should be fdl
I seem to recall that the issue there was that regexprops-generic is
both documentation and code. Therefore neither GPL nor GFDL work, and
dual licensing seems like far too much trouble.
The unlimited license text
One is maintain.texi. Karl, can you please apply the following
patch?
Will do.
The other file is fdl-1.2.texi; can that be fixed too?
It really seems pointless to me to change an old version of a license
for such a cosmetic matter. I am loath to do so.
k
of anybody who's using fdl-1.2.texi. Perhaps we
should remove it from gnulib, if it's not useful there?
Works for me. Any project that misses it needs to update to fdl-1.3
anyway.
k
Here is a patch to gnupload to implement --replace, per the new upload
protocol. Any comments/suggestions before I commit it?
k
--- a/build-aux/gnupload
+++ b/build-aux/gnupload
@@ -28,6 +28,7 @@ GPG='gpg --batch --no-tty'
conffile=.gnuploadrc
to=
dry_run=false
+replace=
symlink_files=
Is there any reason for gnupload -n to ask for the gpg password?
When testing, it seems rather more convenient not to be asked.
(If I actually commit this I'll reindent in the obvious way.)
k
--- a/build-aux/gnupload
+++ b/build-aux/gnupload
@@ -243,11 +249,13 @@ unset passphrase
# listings
I know it's a pain to update lgpl-2.1.texi,
I'll ask Brett if there is any prospect of updating the v2 license text.
recommendations were synced with regards to listing the same address.
gpl-howto.html is in sync with v3. I guess it could at least explicitly
say that it is ok to use
(2) Information for the users, on how to get in touch with the
developers (community related stuff).
I think it's useful for such basic information as mailing lists to be in
the manual as well, as well as on the web and README. It's important
enough and stable enough that the
Someone asked me today about whether gnulib required C99. I couldn't
remember the answer for sure (which is no :), so I went to look it up,
and was surprised to find it (as far as I could see) only in
gnulib/README and not gnulib.texi. It looks like there were several
nontrivial sections in that
+# Similarly undesirable, See @xref{...} expands to See *Note
Doesn't it actually expand to See see *Note?
Not that it matters since the comment was changed, but it would actually be
See See *Note.
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
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 k...@freefriends.org
Subject: Re: fsf address change
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
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
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,
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
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''
and something like the proposed patch to standards.texi
http://lists.gnu.org/archive/html/bug-gnulib/2011-12/msg00217.html.
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
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.
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
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,
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
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
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.
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
1 - 100 of 431 matches
Mail list logo
