Re: gettext->gnulib sync conflicts

2016-11-22 Thread Karl Berry
I assume this is because Karl's procedure, which he runs periodically, Nightly, for the record ... -k

Re: gettext->gnulib sync conflicts

2016-11-22 Thread Daiki Ueno
Paul Eggert writes: > On 11/22/2016 12:58 AM, Daiki Ueno wrote: >> Why can't we continue >> syncing with the gettext releases, even if one checks in a change into >> gnulib directly? > > I assume this is because Karl's procedure, which he runs periodically, > is to grab the latest release from va

Re: gettext->gnulib sync conflicts

2016-11-22 Thread Paul Eggert
On 11/22/2016 12:58 AM, Daiki Ueno wrote: Why can't we continue syncing with the gettext releases, even if one checks in a change into gnulib directly? I assume this is because Karl's procedure, which he runs periodically, is to grab the latest release from various sources, and to copy the re

Re: gettext->gnulib sync conflicts

2016-11-22 Thread Daiki Ueno
Karl Berry writes: > 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)

Re: status of C++ support with GNULIB_NAMESPACE

2016-11-22 Thread Mike Miller
On Mon, Nov 21, 2016 at 23:35:12 +, Pedro Alves wrote: > BTW, do we know which programs use GNULIB_NAMESPACE? > I believe the initial support was done for GNU Octave, but I see > that quite recently Octave switched away from it, maybe because of > the problems with newer GCCs (I believe fixed n