Re: status of C++ support with GNULIB_NAMESPACE

2016-11-21 Thread Pedro Alves
On 11/20/2016 12:23 PM, Bruno Haible wrote: > To see where we are on C++ GNULIB_NAMESPACE support, I ran > $ ./gnulib-tool --create-testdir --with-c++-tests --with-tests > --dir=/tmp/testdir > (takes one hour, be patient) and built it on a glibc system with > $ ./configure CPPFLAGS="-DGNULIB

Re: ChangeLog entries

2016-11-21 Thread Bruno Haible
Pedro Alves wrote: > > I added ChangeLog entries for your two patches from 2016-11-12 > > (that Paul committed). > > Thanks! Should I assume you're all using git-merge-changelog and Yes, we are all using the git-merge-changelog. It handles about 60% of the ChangeLog entry conflicts correctly. (A

Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func

2016-11-21 Thread Pedro Alves
On 11/21/2016 11:27 PM, Bruno Haible wrote: > Pedro Alves wrote: >> How about breaking this line like the rpl method was breaking it, in order >> to avoid overly-long lines? >> >>inline operator type () const >>{ return reinterpret_cast((rettype2 (*) >> parameters2)(::func)

Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func

2016-11-21 Thread Bruno Haible
Pedro Alves wrote: > How about breaking this line like the rpl method was breaking it, in order > to avoid overly-long lines? > >inline operator type () const >{ return reinterpret_cast((rettype2 (*) > parameters2)(::func)); } > > Likewise the other similar cases. If lin

Re: gettext->gnulib sync conflicts

2016-11-21 Thread Karl Berry
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 ob

fix the license output by --lgpl=3orGPLv2

2016-11-21 Thread Nikos Mavrogiannopoulos
Hi, The recent patch which added the option 3orGPLv2 didn't modify the license text to reflect the 3orGPLv2 license. This patch attempts to do just that (it's a bit ugly but the result seems ok). regards, Nikos From a052732ba0f8fe7e298d02d60943834117855077 Mon Sep 17 00:00:00 2001 From: Nikos Mav

Re: [PATCH] Avoid having GNULIB_NAMESPACE::func always inject references to rpl_func

2016-11-21 Thread Pedro Alves
On 11/20/2016 12:26 PM, Bruno Haible wrote: > Hi Pedro, Hi! > I added ChangeLog entries for your two patches from 2016-11-12 > (that Paul committed). Thanks! Should I assume you're all using git-merge-changelog and include ChangeLog changes in the diff as well as in the commit log? > The membe

Re: relicensing libunistring to "dual LGPLv3+ or GPLv2"

2016-11-21 Thread Kevin Cernekee
On Mon, Nov 21, 2016 at 10:46 AM, Bruno Haible wrote: > I would be willing to put my contributions to these files under LGPLv2+. [...] > === Kevin === > > Would you be willing to do the same for lib/fseterr.c ? Yes, approved.

Re: relicensing libunistring to "dual LGPLv3+ or GPLv2"

2016-11-21 Thread Bruno Haible
Daiki Ueno wrote: > noticed some more dependencies (from the unistdio modules): > > /home/dueno/devel/libunistring/../gnulib/gnulib-tool: *** incompatible > license on modules: > fseterr LGPL > mbchar

Re: [PATCH] dfa: addition of new state on demand

2016-11-21 Thread Norihiro Tanaka
On Mon, 17 Oct 2016 22:00:33 +0900 Norihiro Tanaka wrote: > > On Mon, 17 Oct 2016 11:45:43 +0900 > Norihiro Tanaka wrote: > > > When dfa builds a state, generates all next states. However, I believe > > most of them are not used. > > > > This patch changes as that when dfa builds a state, g

Re: gettext->gnulib sync conflicts

2016-11-21 Thread Daiki Ueno
Hello, Karl Berry writes: > I can sync against dev, or I can sync against releases, or I can not > sync at all, or I can quit being responsible for this job entirely and > someone else can figure out what to do :). I can't go back and forth > depending on development "periods". [Or gettext could