Hi Daiki,
That can be done by the attached patch (though it's a bit ugly).
Since you went to the trouble of writing the code, it's certainly
fine by me. Please go ahead and commit that? --thanks, karl.
Daiki Ueno writes:
> 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
I assume this is because Karl's procedure, which he runs periodically,
Nightly, for the record ... -k
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
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
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)
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
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
However, in periods where only small and safe changes are being made,
The problem from my point of view is that I just see a change and can't
(don't want to) guess if it's "small and safe". If I can't blindly sync
the changes I see, that creates an additional burden that I can't (don't
want to
Hi Karl,
Sorry for not having replied to your first mail on this topic.
> gnulib has been synced against gettext releases, not gettext dev.
> This was a change I made at Daiki's suggestion a couple years ago.
I fully support this: the maintainer of a package needs the ability to
have unstable ch
Regarding the sync of gettext files into gnulib and the change to
iconv.m4.
Bruno, you updated iconv.m4 in the gettext dev repo with your change
made in gnulib. However, as I said, gnulib has been synced against
gettext releases, not gettext dev. This was a change I made at Daiki's
suggestion a co
11 matches
Mail list logo
