Re: Licensing of modules for libposix

Hi Karl, On 4 May 2011, at 22:11, k...@freefriends.org (Karl Berry) wrote: >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

Re: rebasing topic/libposix

Howdy Bruce, On 5 May 2011, at 03:22, Bruce Korb wrote: > Not being a GIT guru, I had previously done "git merge" to > synchronize topic/libposix with master. Seemed straight > forward and obvious to me. However, "rebase" is a better > spelling for the proper process of resynchronization. I'm

[PATCH 2/2] test-fclose: skip part of test if fflush is not present

* modules/fclose (configure.ac): Set module indicator. * tests/test-fclose.c (main): Use improved indicators to avoid test failure when fclose is in lib/ but fflush is in tests/. Signed-off-by: Eric Blake --- Tested on libvirt, where fclose is in lib but fflush is in tests, as well as situations

[PATCH 1/2] tests: allow tests to learn where a module is present

Set up framework to tell from within a test whether a module exists in just tests or also in libs. * m4/gnulib-common.m4 (gl_MODULE_INDICATOR): Refine definition. * gnulib-tool (func_note_Makefile_am_edit): Update condition output. Signed-off-by: Eric Blake --- By making a module indicator 0 (n

[PATCH 2/2] maint: make most gl_REPLACE macros one-shot

See http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00158.html for why this is needed. Without it, if two different modules call gl_REPLACE_*, one from the libs directory and one from the tests directory, then the tests directory is broken because it tries to look for the AC_LIBOBJ file th

[PATCH 1/2] maint: remove useless REPLACE_*_H macros

There are still a few modules, like iconv_h.m4, that still use older paradigms where GNULIB_POSIXCHECK is unsupported and where gl_REPLACE__H is still essential. But since we are moving away from that style, I see no reason to keep the idiom for the modules that don't need it. * m4/arpa_inet_h.m4

Re: Licensing of modules for libposix: math functions

On 05/04/2011 12:18 PM, Bruno Haible wrote: The code is from Paolo Bonzini, based on some other source. That was glibc. Paolo

Re: Licensing of modules for libposix

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 descri

gl_MODULE_INDICATOR

Right now, we have: # gl_MODULE_INDICATOR([modulename]) # defines a C macro indicating the presence of the given module # in a location where it can be used. # | Value | Value | # | in lib/ | in tests/ |

Re: Licensing of modules for libposix

On 05/04/2011 08:04 PM, Bruce Korb wrote: So, if I've not mis-stated nor missed anything, we only wait for Derek, Paolo and Ralf. Ok by me. Paolo

rebasing topic/libposix

Not being a GIT guru, I had previously done "git merge" to synchronize topic/libposix with master. Seemed straight forward and obvious to me. However, "rebase" is a better spelling for the proper process of resynchronization. So, I did a "git rebase" and it was a mess. Lots of stuff would not

Re: help in deciphering a gnulib-tool/bootstrap issue

On 05/04/2011 09:55 AM, Eric Blake wrote: > On 05/04/2011 09:47 AM, Bruno Haible wrote: >> Hi Eric, >> >>> once I update to the very next commit, >>> 7ec62f74 (gnulib-tool: Reduce code duplication.), I start getting these >>> messages when trying to bootstrap: >>> >>> ./bootstrap: aclocal -I m4 --f

Re: dependency creep: canonicalize_file_name

On 05/04/11 10:21, Sam Steingold wrote: > What I was complaining about is that I have to pull 150+ _files_ to define > a function whose C code takes about the same number of _lines_. Sure, and I had similar problems when I recently modified Emacs to use gnulib. I fixed the problems by proposing an

bug-gnulib@gnu.org

Sam Steingold wrote: > 2. dynmod/lib-wildcard.so cannot be created when clisp is configured > --with-debug: > > gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,lib-wildcard.so -o > /export/home/sds/src/clisp/current/build-g/dynmod/lib-wildcard.so wildcard.o > libgnu_wc.a -g -O2 -W -Wswitch -Wcomment -Wp

Re: Licensing of modules for libposix

On 05/04/11 03:20, Jim Meyering wrote: However, adding a new name anywhere in source files for each new author who contributes a copyright-significant change would not be worth the trouble. What I think is abundantly clear is that a notation is needed regarding who has relicensing authority. I

Re: dependency creep: canonicalize_file_name

> * Eric Blake [2011-05-04 10:03:36 -0600]: > On 05/04/2011 09:51 AM, Sam Steingold wrote: >> And yet again it is time for me to bitch about dependency creep. >> >> discovered that it offered canonicalize_file_name instead. > > Try canonicalize-lgpl instead; much lighter-weight, and is the only >

bug-gnulib@gnu.org

Bruno, Trying to build clisp with dynamic modules on solaris 11 (i386), I get interesting errors with gnulib code: 1. dynmod/lib-rawsock.so (which does not use gnulib) is created successfully and can be dynamically loaded. 2. dynmod/lib-wildcard.so cannot be created when clisp is configured --wi

Re: lgpl clock-time module

On 05/04/11 09:34, Andy Wingo wrote: > Would you all be OK with making "clock-time" to be LGPL? Yes, that one's trivial: it actually contains only BSD-like license code so it could be marked BSD-like if gnulib had a mark for that.

Re: Licensing of modules for libposix

Reuben Thomas writes: > $ ls > */{acosl,asinl,atanl,cosl,expl,logl,sinl,sqrtl,tanl,isfinite,tmpfile,fflush,futimens,nanosleep,getgroups,tzset,strtoimax,strtoumax}.* > |xargs git log --pretty=format:%aN |sort |uniq -c > 3 Ben Pfaff > 54 Bruno Haible > 1 Derek R. Price > 34 Er

lgpl clock-time module

Hello, Would you all be OK with making "clock-time" to be LGPL? It doesn't actually include any GPL code, and depends only on "extensions", which is LGPL. Thanks, Andy -- http://wingolog.org/

Re: glob-libc.h not installed

On 4 May 2011 17:24, Bruce Korb wrote: > > I cannot tell.  My version of time.in.h is only 250 lines long, so I > don't know what line 469 looks like.  My guess is some auto-editing > variation of: > > _GL_FUNCDECL_RPL (gmtime_r, struct tm *, (time_t const *restrict __timer, >                    

Re: Licensing of modules for libposix

On 05/04/11 08:51, Bruno Haible wrote: > We are asking your agreement to relax the license to LGPL for the files > > lib/nanosleep.c > lib/getgroups.c > Thanks for clarifying; and yes, those are fine for the LGPL.

Re: glob-libc.h not installed

On 05/04/11 00:08, Reuben Thomas wrote: 2. fiddle a project to detect that it is "sufficiently recent" . I ignored this problem. My principle interest at present is to build the luaposix Lua bindings for POSIX APIs, so any version of libposix makes things better and is hence "new enough".

Re: dependency creep: canonicalize_file_name

On 05/04/2011 09:51 AM, Sam Steingold wrote: > And yet again it is time for me to bitch about dependency creep. > > I thought about pulling realpath from gnulib (because clisp includes its > own implementation - BTW, are there still unixes which lack it?) and Read doc/posix-functions/realpath.tex

Re: help in deciphering a gnulib-tool/bootstrap issue

On 05/04/2011 09:47 AM, Bruno Haible wrote: > Hi Eric, > >> once I update to the very next commit, >> 7ec62f74 (gnulib-tool: Reduce code duplication.), I start getting these >> messages when trying to bootstrap: >> >> ./bootstrap: aclocal -I m4 --force -I 'gnulib/m4' ... >> missing file gnulib/te

Re: Licensing of modules for libposix

Paul Eggert wrote: > I'm not sure what I'm being asked. We are asking your agreement to relax the license to LGPL for the files lib/nanosleep.c lib/getgroups.c Bruno -- In memoriam Henri Curiel

dependency creep: canonicalize_file_name

And yet again it is time for me to bitch about dependency creep. I thought about pulling realpath from gnulib (because clisp includes its own implementation - BTW, are there still unixes which lack it?) and discovered that it offered canonicalize_file_name instead. I tried pulling it and the list

Re: help in deciphering a gnulib-tool/bootstrap issue

Hi Eric, > once I update to the very next commit, > 7ec62f74 (gnulib-tool: Reduce code duplication.), I start getting these > messages when trying to bootstrap: > > ./bootstrap: aclocal -I m4 --force -I 'gnulib/m4' ... > missing file gnulib/tests/fseeko.c > configure.ac:80: error: expected sourc

Relicensing of modules for libposix branch: abort

Bruno has pointed out that I got it wrong again, and that furthermore there is authorship information that I couldn't have deduced from any VCS. So, I give up. Sorry for wasting all your time. -- http://rrt.sc3d.org

Re: Licensing of modules for libposix

On 05/04/11 03:05, Reuben Thomas wrote: >> 39 Paul Eggert That's a bit terse; I'm not sure what I'm being asked.

help in deciphering a gnulib-tool/bootstrap issue

If I update libvirt.git to use commit 380f4f7a (and relax bootstrap.conf to deal with the temporary window of GPL requirements on fclose), then everything works fine. But once I update to the very next commit, 7ec62f74 (gnulib-tool: Reduce code duplication.), I start getting these messages when tr

Re: Relicensing of modules for libposix branch

On 05/04/2011 05:06 AM, Reuben Thomas wrote: > Sorry for the confusion. I shall start a new thread. > > Bruno & Jim, at least, you've both written several replies to earlier > messages which I have little hope of collating in a sane amount of > time, so I'd be most grateful if you could just reply

Re: gnulib's licensing

On 05/04/2011 02:55 AM, Bruno Haible wrote: libposix is intended to be under LGPL, but we have some way to go (agreements to get from the authors) for some modules: FWIW, I'm okay with LGPL for the mathl modules. They mos

Re: do-release-commit-and-tag requires that I be on master branch?

On 4 May 2011 12:56, Jim Meyering wrote: > > BTW, please make your patches in-line, or at least make > the type be text or x-patch rather than "octet-stream". > Here, we prefer not to have to take extra measures (not even > to click on a button/link) to see a patch. I've explained before that I d

Re: do-release-commit-and-tag requires that I be on master branch?

Reuben Thomas wrote: > On 4 May 2011 09:34, Jim Meyering wrote: >> Reuben Thomas wrote: >> For now, I'd just comment out the test so you can make your release. Then, maybe add an option to accomplish the same thing. >>> >>> Such as providing the correct branch name as an argument? >

Re: do-release-commit-and-tag requires that I be on master branch?

On 4 May 2011 09:34, Jim Meyering wrote: > Reuben Thomas wrote: > >>> >>> For now, I'd just comment out the test so you can make your release. >>> Then, maybe add an option to accomplish the same thing. >> >> Such as providing the correct branch name as an argument? > > Sure. Patch attached. --

Re: Relicensing of modules for libposix branch

Reuben Thomas wrote: > Sorry for the confusion. I shall start a new thread. > > Bruno & Jim, at least, you've both written several replies to earlier > messages which I have little hope of collating in a sane amount of > time, so I'd be most grateful if you could just reply once, here. > > On 4 Ma

Relicensing of modules for libposix branch

Sorry for the confusion. I shall start a new thread. Bruno & Jim, at least, you've both written several replies to earlier messages which I have little hope of collating in a sane amount of time, so I'd be most grateful if you could just reply once, here. On 4 May 2011 10:14, Reuben Thomas wrote

Re: Licensing of modules for libposix

Reuben Thomas wrote: > >  fflush, futimens > > These are Eric's. Eric? lib/fflush.c is also by me and Jim. I give permission to LGPL my contributions to this file. > >  nanosleep > > Bruno & Jim's. Bruno & Jim? lib/nanosleep.c is by Jim, Paul, Eric, and me. I give LGPL permission for my part.

Re: Licensing of modules for libposix: isfinite

Reuben Thomas wrote: > > isfinite, tmpfile > > are from Ben Pfaff, who gave his permission for relicensing in > > http://lists.gnu.org/archive/html/bug-gnulib/2010-12/msg00185.html lib/isfinite.c has changes from me as well. I give my permission to LGPL them. Bruno -- In memoriam Henri Curiel

Re: Licensing of modules for libposix

Reuben Thomas wrote: > On 4 May 2011 10:37, Jim Meyering wrote: >> >> Copyright is covered by the notice at the top of every file. >> Authorship is another story. I've seen no reason to add the name >> of every "author" to each source file that's affected (and am >> strongly inclined never to do t

Re: Licensing of modules for libposix: math functions

Hello Reuben, > > functions: > > > acosl, asinl, atanl, cosl, expl, logl, sinl, sqrtl, tanl > > These modules all seem to come from Bruno You need to look at the history of the source code files in lib/: lib/acosl.c lib/asinl.c lib/atanl.c lib/cosl.c lib/expl.c lib/logl.c lib/sinl.c lib/sqrt

Re: Licensing of modules for libposix

Reuben Thomas wrote: > it's all copyright the FSF, so why all the canvassing to relicense > anyway? The authors have a say on the code they wrote. If they contribute to a GPLed file and then someone - even from the FSF - changes it to LGPL license, they might be offended or frustrated. > Can't so

Re: Licensing of modules for libposix

On 4 May 2011 10:14, Reuben Thomas wrote: > $ ls > */{acosl,asinl,atanl,cosl,expl,logl,sinl,sqrtl,tanl,isfinite,tmpfile,fflush,futimens,nanosleep,getgroups,tzset,strtoimax,strtoumax}.* > |xargs git log --pretty=format:%aN |sort |uniq -c Could you please reply to this thread, and for all modules,

Re: Licensing of modules for libposix

On 4 May 2011 10:37, Jim Meyering wrote: > > Copyright is covered by the notice at the top of every file. > Authorship is another story. I've seen no reason to add the name > of every "author" to each source file that's affected (and am > strongly inclined never to do that). > That is meta data an

Re: Licensing of modules for libposix: strtoimax, strtoumax

Bruno Haible wrote: > Paul Eggert wrote: >> >> strtoimax, strtoumax >> > Paul's. Paul? >> >> These modules are clearly LGPLish, and I have no objection >> to relicensing them under the LGPL. > > Looking at the contributors of this modules' files in lib/ > $ gitk lib/strtoimax.c lib/strtoumax.c >

Re: Licensing of modules for libposix: strtoimax, strtoumax

Paul Eggert wrote: > >> strtoimax, strtoumax > > Paul's. Paul? > > These modules are clearly LGPLish, and I have no objection > to relicensing them under the LGPL. Looking at the contributors of this modules' files in lib/ $ gitk lib/strtoimax.c lib/strtoumax.c Jim's agreement is needed as well

Re: Licensing of modules for libposix

Reuben Thomas wrote: > On 4 May 2011 10:03, Jim Meyering wrote: >>> the underlying problem appears to be that copyright holders are not >>> listed in the file headers. > > This needs to be addressed, because otherwise any package using gnulib > has to go back to gnulib git to determine authorship.

Re: Licensing of modules for libposix

On Wed, May 04, 2011 at 10:09:47AM +0100, Reuben Thomas wrote: > On 4 May 2011 10:03, Jim Meyering wrote: > >> Further, I've signed a copyright assignment for gnulib, so presumably > >> it's all copyright the FSF, so why all the canvassing to relicense > >> anyway? > > > > Sometimes, an author wil

Re: Licensing of modules for libposix

On 4 May 2011 09:43, Jim Meyering wrote: > Reuben Thomas wrote: >> On 4 May 2011 09:08, Jim Meyering wrote: > getgroups, tzset Jim's. Jim? >>> >>> Relaxing to LGPL for those three modules is fine by me. >>> However, note that Paul is listed as coauthor of tzset.m4 >>> and Eric

Re: Licensing of modules for libposix

On 4 May 2011 10:03, Jim Meyering wrote: > >> the underlying problem appears to be that copyright holders are not >> listed in the file headers. This needs to be addressed, because otherwise any package using gnulib has to go back to gnulib git to determine authorship. One expects to be able to d

Re: Licensing of modules for libposix

Reuben Thomas wrote: > On 4 May 2011 09:43, Jim Meyering wrote: >> >> Very few people end up being listed as a gnulib module maintainer >> if they are not also an author (aka patch contributor). >> >> To determine "authorship", you must look at the commit logs: >> >>    $ git log --pretty=format:

Re: Licensing of modules for libposix

On 4 May 2011 09:43, Jim Meyering wrote: > > Very few people end up being listed as a gnulib module maintainer > if they are not also an author (aka patch contributor). > > To determine "authorship", you must look at the commit logs: > >    $ git log --pretty=format:%aN lib/getgroups.c|sort |uniq

Re: Licensing of modules for libposix

Reuben Thomas wrote: > On 4 May 2011 09:08, Jim Meyering wrote: >>> getgroups, tzset >>> >>> Jim's. Jim? >> >> Relaxing to LGPL for those three modules is fine by me. >> However, note that Paul is listed as coauthor of tzset.m4 >> and Eric as the other "Maintainer" in modules/getgroups. > > T

Re: do-release-commit-and-tag requires that I be on master branch?

Reuben Thomas wrote: > On 4 May 2011 09:19, Jim Meyering wrote: >> Reuben Thomas wrote: >>> But I'm trying to make an alpha release, which is on a different >>> branch, so that I can carry on making stable releases from master >>> until the new version is ready. >>> >>> Suggestions? >> >> For now

Re: Licensing of modules for libposix

On 4 May 2011 09:08, Jim Meyering wrote: >> >>> getgroups, tzset >> >> Jim's. Jim? > > Relaxing to LGPL for those three modules is fine by me. > However, note that Paul is listed as coauthor of tzset.m4 > and Eric as the other "Maintainer" in modules/getgroups. That doesn't seem to matter, since

Re: do-release-commit-and-tag requires that I be on master branch?

On 4 May 2011 09:19, Jim Meyering wrote: > Reuben Thomas wrote: >> But I'm trying to make an alpha release, which is on a different >> branch, so that I can carry on making stable releases from master >> until the new version is ready. >> >> Suggestions? > > For now, I'd just comment out the test

Re: do-release-commit-and-tag requires that I be on master branch?

Reuben Thomas wrote: > But I'm trying to make an alpha release, which is on a different > branch, so that I can carry on making stable releases from master > until the new version is ready. > > Suggestions? For now, I'd just comment out the test so you can make your release. Then, maybe add an opt

Re: Licensing of modules for libposix

Reuben Thomas wrote: > Going through the list provided by Bruno: > >> Among the modules that will be part of libposix, i.e. that are listed as >> gnulib modules for some POSIX functions or headers, the following are >> currently under GPL license: ... >> nanosleep > > Bruno & Jim's. Bruno & Jim?

Re: gnulib's licensing

On 4 May 2011 01:55, Bruno Haible wrote: > > Technically there's no problem linking a BSD program against an LGPLed > library, or even a GPLed library. But some people in the BSD camp have > a problem with it. It's their problem, not ours. That's something I wasn't clear about. Since I find argui

Re: Licensing of modules for libposix

On 05/04/11 00:27, Reuben Thomas wrote: >> strtoimax, strtoumax > Paul's. Paul? These modules are clearly LGPLish, and I have no objection to relicensing them under the LGPL.

Licensing of modules for libposix

Going through the list provided by Bruno: > Among the modules that will be part of libposix, i.e. that are listed as > gnulib modules for some POSIX functions or headers, the following are > currently under GPL license: > functions: > acosl, asinl, atanl, cosl, expl, logl, sinl, sqrtl, tanl T

Re: Todo for libposix branch?

On 4 May 2011 00:56, Bruce Korb wrote: > > 1.  configure, build and install the thing.  Perhaps from: >    http://autogen.sourceforge.net/data/ >    or roll your own, but the distribution should be there, I think. I configured, built and installed from gnulib git; no problem there. > 2.  fiddle