Re: gplv3 files and updates
Bruno Haible <[EMAIL PROTECTED]> wrote: > 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 "mistakenly"? I prefer that name to "autogen.sh", since the script has nothing to do with the GNU Autogen project: http://www.gnu.org/software/autogen/ > 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. That sounds reasonable. However, I'm not likely to make bootstrap do this in the next few weeks. Are you?
Re: second call: please nail down the license terms of some more modules
Le dimanche 15 juillet 2007 à 16:59 +0200, Bruno Haible a écrit : > 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? For the reasons I mentioned earlier, I think it would be wise waiting before performing the definitive move to GPLv3. Even if we provide a list of modules we use doesn't mean that we're not going to need new module tomorrow, or that another library project licensed under GPLv2 will need that module. > 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. The modules (and their dependencies) we currently use in Prelude are: alloca arpa_inet d-type extensions fnmatch fseeko getline getlogin_r gettext-h inet_ntop localcharset malloc malloca mempcpy mktime netinet_in snprintf socklen ssize_t stdbool stdint stdio strcase strdup string strnlen strpbrk sys_select sys_socket sys_stat sys_time time time_r unistd vasnprintf wchar wctype -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
Re: second call: please nail down the license terms of some more modules
Le lundi 16 juillet 2007 à 09:33 +0200, Yoann Vandoorselaere a écrit : > Le dimanche 15 juillet 2007 à 16:59 +0200, Bruno Haible a écrit : > > 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? > > For the reasons I mentioned earlier, I think it would be wise waiting > before performing the definitive move to GPLv3. > > Even if we provide a list of modules we use doesn't mean that we're not > going to need new module tomorrow, or that another library project > licensed under GPLv2 will need that module. > > > > 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. > > The modules (and their dependencies) we currently use in Prelude are: > > alloca arpa_inet d-type extensions fnmatch fseeko getline getlogin_r > gettext-h inet_ntop localcharset malloc malloca mempcpy mktime > netinet_in snprintf socklen ssize_t stdbool stdint stdio strcase strdup > string strnlen strpbrk sys_select sys_socket sys_stat sys_time time > time_r unistd vasnprintf wchar wctype The previous mail was missing module, here is the full list: alloca arpa_inet d-type extensions fnmatch fseeko getaddrinfo getline getlogin_r getpass gettext-h gettimeofday glob inet_ntop localcharset malloc malloca memmem mempcpy memset minmax mktime netinet_in pathmax poll regex snprintf socklen ssize_t stdbool stdint stdio strcase strcasestr strdup strndup string strnlen strpbrk strptime strsep sys_select sys_socket sys_stat sys_time time time_r timegm unistd vasnprintf vsnprintf wchar wctype -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
Re: second call: please nail down the license terms of some more modules
Yoann Vandoorselaere wrote: > Even if we provide a list of modules we use doesn't mean that we're not > going to need new module tomorrow, or that another library project > licensed under GPLv2 will need that module. I believe we can handle this on demand, like we did in the past. gnulib-tool will continue to give an error if it encounters a situation where the desired license and the current license of a module don't match, so you cannot make accidental mistakes. Bruno
Re: second call: please nail down the license terms of some more modules
Le lundi 16 juillet 2007 à 11:28 +0200, Bruno Haible a écrit : > Yoann Vandoorselaere wrote: > > Even if we provide a list of modules we use doesn't mean that we're not > > going to need new module tomorrow, or that another library project > > licensed under GPLv2 will need that module. > > I believe we can handle this on demand, like we did in the past. gnulib-tool > will continue to give an error if it encounters a situation where the desired > license and the current license of a module don't match, so you cannot make > accidental mistakes. This sound okay for project like GnuTLS or Prelude which are used to work with the GnuLib project (although it will bring another maintenance overhead), but don't you think this could be a show stopper to early GnuLib adopters? -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
Re: second call: please nail down the license terms of some more modules
Le lundi 16 juillet 2007 à 10:14 +0200, Yoann Vandoorselaere a écrit : > Le lundi 16 juillet 2007 à 09:33 +0200, Yoann Vandoorselaere a écrit : > > Le dimanche 15 juillet 2007 à 16:59 +0200, Bruno Haible a écrit : > > > 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? > > > > For the reasons I mentioned earlier, I think it would be wise waiting > > before performing the definitive move to GPLv3. > > > > Even if we provide a list of modules we use doesn't mean that we're not > > going to need new module tomorrow, or that another library project > > licensed under GPLv2 will need that module. > > > > > > > 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. > > > > The modules (and their dependencies) we currently use in Prelude are: > > > > alloca arpa_inet d-type extensions fnmatch fseeko getline getlogin_r > > gettext-h inet_ntop localcharset malloc malloca mempcpy mktime > > netinet_in snprintf socklen ssize_t stdbool stdint stdio strcase strdup > > string strnlen strpbrk sys_select sys_socket sys_stat sys_time time > > time_r unistd vasnprintf wchar wctype > > The previous mail was missing module, here is the full list: > > alloca arpa_inet d-type extensions fnmatch fseeko getaddrinfo getline > getlogin_r getpass gettext-h gettimeofday glob inet_ntop localcharset > malloc malloca memmem mempcpy memset minmax mktime netinet_in pathmax > poll regex snprintf socklen ssize_t stdbool stdint stdio strcase > strcasestr strdup strndup string strnlen strpbrk strptime strsep > sys_select sys_socket sys_stat sys_time time time_r timegm unistd > vasnprintf vsnprintf wchar wctype Here is the patch for the above module, -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com 0002-Use-the-synonymous-term-LGPLv2.patch Description: application/mbox
Re: second call: please nail down the license terms of some more modules
Yoann Vandoorselaere wrote: > Here is the patch for the above module, Thanks. I applied it, plus the same on a few dependencies that you missed: lseek (needed by fseeko) and getdelim (needed by getline). 2007-07-16 Bruno Haible <[EMAIL PROTECTED]> * modules/lseek (License): Use the synonymous term "LGPLv2+". * modules/getdelim (License): Likewise. --- modules/getdelim13 Oct 2006 12:40:23 - 1.4 +++ modules/getdelim16 Jul 2007 10:53:00 - @@ -17,7 +17,7 @@ "getdelim.h" License: -LGPL +LGPLv2+ Maintainer: Simon Josefsson --- modules/lseek 24 May 2007 16:59:21 - 1.1 +++ modules/lseek 16 Jul 2007 10:53:00 - @@ -18,7 +18,7 @@ License: -LGPL +LGPLv2+ Maintainer: Eric Blake
Re: second call: please nail down the license terms of some more modules
Yoann Vandoorselaere wrote: > don't you think this could be a show stopper to early GnuLib adopters? No, I don't think so. Projects which have been using already cannot have missed the long thread here; projects which will adopt it in the future will see that there is no problem with the first few modules they need, and later on, they will ask. Bruno
Re: licenses.texi and sectioning commands
@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. Actually, I woke up this morning and realized it was not consistent -- there's no way to do an include in a plain text file, after all. So the consistent way would be to insert @majorheading The GNU General Public License @include gpl-3.0.texi at the end of lgpl-3.0.texi. And the actual text of gpl-3.0.txt aka COPYINGv3 aka COPYING to the end of lgpl-3.0.txt aka COPYING.LESSERv3 aka COPYING.LESSER. (@majorheading is better than the @heading I wrote yesterday, too.) Brett, if you think this is a reasonable way to go, can you ask rms, please? The alternative I see is to have two @nodes, one for the GPL and one for the LGPL, and two files, COPYING and COPYING.LESSER. Personally I think there is some benefit/clarity (for readers) in having the lgpl instantiations be self-contained, though I can't think of any really definitive reason to prefer one way to the other. Thanks, karl
Re: licenses.texi and sectioning commands
> I.e., don't forget gfdl.texi. Is that the intention? > > Yes. I checked in new versions of all the Texinfo licenses to gnulib: > fdl.texi gpl-2.0.texi gpl-3.0.texi lgpl-2.1.texi lgpl-3.0.texi. > > Let me know if problems ... The old lgpl.texi was usable in a manual like libc's with: @set lgpl-appendix @node Copying, Documentation License, Free Manuals, Top @include lesser.texi The LGPLv3 text is not self-contained, but refers to the GPLv3 text. So dropping lgpl-3.0.texi in omits the bulk of the license. Firstly, GNU Central should do more to explicitly show maintainers exactly what is required to update a package. It would have been very easy to think I'd updated correctly, but produce a manual that nowhere had the text of the heart of the license. So, if there were coherent instructions for maintainers like there ought to have been already, what would they say? Should gpl-3.0.texi and lgpl-3.0.texi be used as two separate nodes and appendices? What's the canonical node name for each now that "Copying" and "License" are no longer unambiguous? I know there are various coherent ways to do it. I don't want to choose. Someone just tell me. It's a GNU manual, wholly owned the FSF. There ought to be a standard answer that the Project tells me as a maintainer. Thanks, Roland
RE: make error with tar-1.18
Hello Bruno,
The patch you suggested worked fine. The make was successful without error and
the executable seems to be working okay.
Many thanks for your help.
Cheers!
--Alex Z.
-Original Message-
From: Bruno Haible [mailto:[EMAIL PROTECTED]
Sent: Thu 7/12/2007 4:46 PM
To: Zimmerman, Alex (TS); bug-gnulib@gnu.org
Cc: Noam G. Nudelman
Subject: Re: make error with tar-1.18
Hello,
Alex Zimmerman reported:
> compiler info:
> jade> gcc -v
> Using built-in specs.
> Target: mips-sgi-irix6.5
> Configured with: /jade1/GNU/gcc-4.1.2/configure --with-gnu-as --with-gnu-ld
> --enable-version-specific-runtime-libs
> Thread model: single
> gcc version 4.1.2
>
> error encountered:
> if gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/jade1/GNU/tar-1.18/lib -I.. -g
> -O2 -MT xstrtoumax.o -MD -MP -MF ".deps/xstrtoumax.Tpo" -c -o xstrtoumax.o
> /jade1/GNU/tar-1.18/lib/xstrtoumax.c; \
> then mv -f ".deps/xstrtoumax.Tpo" ".deps/xstrtoumax.Po"; else rm -f
> ".deps/xstrtoumax.Tpo"; exit 1; fi
> In file included from ./stdint.h:71,
> from /usr/include/inttypes.h:242,
> from ./inttypes.h:31,
> from /jade1/GNU/tar-1.18/lib/xstrtol.h:25,
> from /jade1/GNU/tar-1.18/lib/xstrtol.c:32,
> from /jade1/GNU/tar-1.18/lib/xstrtoumax.c:6:
> ./inttypes.h:44:3: error: #error "This file assumes that 'int' has exactly 32
> bits. Please report your platform and compiler to ."
Can you please try this patch? Just modify lib/stdint_.h as indicated
(with "patch lib/stdint_.h < this-mail"), then "make". Does the error
go away?
Bruno
--- lib/stdint_.h 21 Jun 2007 04:39:10 - 1.43
+++ lib/stdint_.h 12 Jul 2007 22:41:42 -
@@ -66,9 +66,9 @@
/* In OpenBSD 3.8, includes , which defines
int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
also defines intptr_t and uintptr_t. */
-# define _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
+# define _GL_JUST_INCLUDE_SYSTEM_INTTYPES_H
# include
-# undef _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
+# undef _GL_JUST_INCLUDE_SYSTEM_INTTYPES_H
#elif @HAVE_SYS_INTTYPES_H@
/* Solaris 7 has the types except the *_fast*_t types, and
the macros except for *_FAST*_*, INTPTR_MIN, PTRDIFF_MIN, PTRDIFF_MAX. */
Re: second call: please nail down the license terms of some more modules
Simon Josefsson <[EMAIL PROTECTED]> writes: > I haven't been following whether glibc is > going to be upgraded to LGPLv3 or not. Will it? Yes. That has started to happen already; the v2-only files were updated to say v2-or-later on July 14. The rest of the v3 patch is kinda large and is still being debugged.
