Utility script for gnulib
Hello, GNU findutils has a shell script that automatically checks out a given list of gnulib modules from CVS. You might want to include this or link to it to avoid duplication of this work. The script is called "import-gnulib.sh" and its configuration file is named "import-gnulib.config". They should be easy to find. Best, Leslie -- Personal homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpfZMXKeW67b.pgp Description: PGP signature
Re: Utility script for gnulib
[EMAIL PROTECTED] writes: > Hello, > > GNU findutils has a shell script that automatically checks out a given > list of gnulib modules from CVS. You might want to include this or > link to it to avoid duplication of this work. > > The script is called "import-gnulib.sh" and its configuration file is > named "import-gnulib.config". They should be easy to find. Gnulib already includes a similar script, called gnulib-tool. Did you notice it, or was there some special need for which you needed your import-gnulib? Gnulib-tool is used in many projects already, and is pretty flexible. /Simon
second call: please nail down the license terms of some more modules
Hi all, There was no objection when I said that: the majority of gnulib modules will migrate from GPLv2+ to GPLv3+ and from LGPLv2+ to LGPLv3+. So I assume we can go for it in a few days? Before that, please mark the modules that you want to stay at the current license. We can also revert a license change for a module afterwards, if all contributors agree, but it's easier if it can be done upfront, because then it's legally a no-op. Bruno
Re: second call: please nail down the license terms of some more modules
Bruno Haible <[EMAIL PROTECTED]> wrote: > There was no objection when I said that: the majority of gnulib modules will > migrate from GPLv2+ to GPLv3+ and from LGPLv2+ to LGPLv3+. So I assume we can > go for it in a few days? No objection here. On a related note, I've already don that for everything under version control in coreutils.
Re: gplv3 files and updates
Bruno Haible <[EMAIL PROTECTED]> wrote: > Eric Blake wrote: >> Would it still be possible to keep symlink development (yes, that means >> during development, the linked files bear a looser license than necessary, >> but only on the developer's machine), so long as a maintainer-check >> guarantees a fresh gnulib checkout with proper licenses at 'make dist' >> time (so that the tarball has the correct license)? > > This sounds like a good compromise. If a developer never makes releases > of a particular package, this approach causes no trouble to him. If a > developer is a maintainer, he only has to remember to tell gnulib-tool > to update the copyright notices during the last gnulib import before the > release. > > I'm adding this patch to gnulib-tool. It should be complemented by some > patch to build-aux/bootstrap and coreutils/Makefile.maint. At first, this approach sounds ok, but then consider what it means: You prepare everything for a release, test to your heart's content, and then at release time you rerun gnulib-tool to update copyright notices. Unfortunately, that might also pull in other (untested) changes. Of course, we can control that, but it is a potential source of trouble. I'm inclined to stick with the status quo unless there's a very strong argument for changing.
Re: gplv3 files and updates
Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Paul, > >> If this sort of bootstrap were changed to make copies rather than >> symbolic links, it would be much more of a pain to develop when >> changes to both gnulib and an application are being debugged. It >> would be far too easy to mistakenly edit the coreutils copy of a >> gnulib file rather than the original; and later, when everything is >> checked in, some of the gnulib fixes would be lost. > > An alternative approach would be to rely on a versioning system which > supports easy branching, like git. Here is a rough idea how this could > work: > > Use three branches > - master = the code which you pull and push from/to the public repository. > - autogened = the code, augmented with files from gnulib and (optionally) > other files brought in by autopoint, automake etc. > - work = the code you work on. > > The branches 'autogened' and 'work' are private - they exist only in your > local repository. ... > In the current state, the set of commands to use is so complicated that > I wouldn't use it myself: I have not much experience with git. > Can someone simplify this and polish the rough edges? Hi Bruno, I find it unacceptably complicated, too, and don't see any significant simplifications.
Re: second call: please nail down the license terms of some more modules
Hello, * Bruno Haible wrote on Sun, Jul 15, 2007 at 04:59:02PM CEST: > > There was no objection when I said that: the majority of gnulib modules will > migrate from GPLv2+ to GPLv3+ and from LGPLv2+ to LGPLv3+. So I assume we can > go for it in a few days? > > Before that, please mark the modules that you want to stay at the current > license. We can also revert a license change for a module afterwards, if all > contributors agree, but it's easier if it can be done upfront, because then > it's legally a no-op. Libtool/libltdl stays at its current state of licensing until all the exception issues have been sorted out. libltdl uses the argz module. I assume this is what I should apply then? Thanks, Ralf 2007-07-15 Ralf Wildenhues <[EMAIL PROTECTED]> * modules/argz (License): LGPLv2+. Index: modules/argz === RCS file: /cvsroot/gnulib/gnulib/modules/argz,v retrieving revision 1.10 diff -u -r1.10 argz --- modules/argz13 Oct 2006 12:40:23 - 1.10 +++ modules/argz15 Jul 2007 20:26:37 - @@ -27,7 +27,7 @@ License: -LGPL +LGPLv2+ Maintainer: [EMAIL PROTECTED]
Re: second call: please nail down the license terms of some more modules
Ralf Wildenhues wrote: > libltdl uses the argz module. I assume this is what I should apply then? Yes, please. Bruno
Re: gplv3 files and updates
Jim Meyering wrote: > consider what it means: > You prepare everything for a release, test to your heart's content, > and then at release time you rerun gnulib-tool to update copyright > notices. Unfortunately, that might also pull in other (untested) > changes. Of course, we can control that, but it is a potential > source of trouble. Just today, Patrick Leslie Polzer pointed us to the autogen.sh script used in findutils (mistakenly called 'import-gnulib.sh' although it does more than importing gnulib), see [1]. Look at the variable 'gnulib_version': If you set it to a date in the past, you eliminate this sort of trouble. And if you set it to 'HEAD', you track all changes like you currently do. If the coreutils 'bootstrap' script had the same configuration parameter, you would only - at some point before the release - change this variable from HEAD to the the current date, until after the release. > I'm inclined to stick with the status quo unless there's > a very strong argument for changing. There is also Brett's argument #2 in [2], which I find understandable. I'm trying to find a constructive solution that would be compatible with your and Paul's way of working. Bruno [1] http://cvs.savannah.gnu.org/viewvc/findutils/?root=findutils [2] http://lists.gnu.org/archive/html/bug-gnulib/2007-07/msg00102.html
Re: licenses.texi and sectioning commands
Someone just tell me. Well, Roland, I'm sorry I didn't anticipate it. I had actually thought of it at one point with respect to the plain text files (COPYING.LESSER has the same issue), but simply dropped that ball. Anyway, my immediate reaction is that there should be one node, it should be named "GNU Lesser General Public License", and it should @include both lgpl-3.0.texi and gpl-3.0.texi, in that order. Except unfortunately there has to be some text in between: @node GNU Lesser General Public License @appendix GNU Lesser General Public License @include lgpl-3.0.texi @heading The GNU General Public License @include gpl-3.0.texi COPYING.LESSER could be done the same way, for consistency. It would be good to get reactions from Brett and others about this, and I won't be around for the coming week. Whatever gets decided is fine by me. (Sorry, I know you don't want to be part of the discussion, just get the decision.) karl
Re: second call: please nail down the license terms of some more modules
Hi Bruno, * Bruno Haible wrote on Mon, Jul 16, 2007 at 12:04:36AM CEST: > Ralf Wildenhues wrote: > > libltdl uses the argz module. I assume this is what I should apply then? > > Yes, please. Applied. Thanks! Ralf
Re: second call: please nail down the license terms of some more modules
Bruno Haible <[EMAIL PROTECTED]> writes: > Hi all, > > There was no objection when I said that: the majority of gnulib modules will > migrate from GPLv2+ to GPLv3+ and from LGPLv2+ to LGPLv3+. So I assume we can > go for it in a few days? > > Before that, please mark the modules that you want to stay at the current > license. We can also revert a license change for a module afterwards, if all > contributors agree, but it's easier if it can be done upfront, because then > it's legally a no-op. I need the following modules to be usable in a LGPLv2 project: Libidn: gettext-h stdint striconv strverscmp Gsasl: base64 crypto/gc crypto/gc-hmac-md5 crypto/gc-hmac-md5-tests crypto/gc-md5 crypto/gc-md5-tests crypto/gc-random crypto/gc-tests getline gettext maintainer-makefile strdup strverscmp vasprintf GnuTLS: crypto/gc crypto/gc-arcfour crypto/gc-arctwo crypto/gc-des crypto/gc-hmac-md5 crypto/gc-md2 crypto/gc-md4 crypto/gc-md5 crypto/gc-pbkdf2-sha1 crypto/gc-random crypto/gc-rijndael crypto/gc-sha1 getpass gettext memmem memmove minmax read-file snprintf socklen stdint strverscmp sys_socket sys_stat time_r unistd vasprintf Libntlm: check-version des des-tests maintainer-makefile md4 md4-tests strdup strverscmp unistd I'm not sure about libidn, I haven't been following whether glibc is going to be upgraded to LGPLv3 or not. Will it? Libidn is part of libc, so it makes sense for it to use only LGPLv2 helpers if glibc will remain LGPLv2. I moving today, so I don't have time to go through them and check who is the owner etc. I'll see if I find time later this week. Unless someone else beats me to it... /Simon
