Roman Bolshakov wrote:
> I'm quite new to gnulib but thanks to Eric and your comments that should do
> it:
>
> diff --git a/modules/maintainer-makefile b/modules/maintainer-makefile
> index 39b51583c..13b8c546a 100644
> --- a/modules/maintainer-makefile
> +++ b/modules/maintainer-makefile
> @@
Hi Roman,
> May I ask you to review what way we should go with ARG_MAX?
>
> I'm okay with both ways whether it's:
> * computing effective argument length and passing it to "-s" option;
> * or exploiting behaviour of GNU/BSD xargs and specifying "-n" beyond
>the limit.
Use the approach
Hi Akim,
> > This shift of work from the maintainers to the translation coordinator
> > would require
> > 1. that the translation coordinator installs whatever tooling is needed
> > to build a particular package,
>
> It is true that some of the messages might not be in the package
> itself,
Hi,
Darshit Shah wrote:
> I recently tried to use the hash table implementation in gnulib which resides
> in the "hash" module. However, I quickly realised that the hash table in
> gnulib
> seems to be what is otherwise popularly known as a hash set, i.e., it supports
> storing and retrieving
On 02.12.2018 16:41, Bruno Haible wrote:
> Hi,
>
> Darshit Shah wrote:
>> I recently tried to use the hash table implementation in gnulib which
>> resides in the "hash" module. However, I quickly realised that the hash
>> table in gnulib seems to be what is otherwise popularly known as a hash
>>
On Sun, 2018-12-02 at 15:38 +0100, Benno Schulenberg wrote:
> > Ah, you were assuming that the POT file is stored in the version
> > control system? This is a practice that produces problems,
>
> What problems does this produce? (Probably this was discussed
> earlier and elsewhere? Maybe have
Roman Bolshakov wrote:
> But then we will need to correct calculation of VC_ARG_MAX. We can take
> formulae from [2]:
> expr `getconf ARG_MAX` - `env|wc -c` - `env|egrep '^[^ ]+='|wc -l` \* 4 - 2048
This formula assumes that a pointer in the 'environ' array is 4 bytes long.
On 64-bit platforms it
Paul Smith wrote:
> It's also possible that different versions of gettext could generate
> slightly different POT files, so if committers have different versions
> installed you get "warring commits" which change them back and forth.
> I don't know if POT files have this issue but other files
Hi Benno,
> > Ah, you were assuming that the POT file is stored in the version control
> > system?
> > This is a practice that produces problems,
>
> What problems does this produce?
There are basically three ways to deal with generated files in the context
of a version controlled
> Akim Demaille wrote:
>> maybe the translation project could work on top of git now?
No, I'm not going to do that. The TP is geared toward packages that
make releases. So I need a (prerelease) tarball that contains the
corresponding POT file.
Benno
Op 01-12-18 om 17:00 schreef Bruno Haible:
> Akim has just moved some code from Bison to Gnulib. He writes:
>
>> Also, I feel sorry for Bison's translators when submitting modules to
>> gnulib: it's kind of throwing away their work; it would be great if there
>> were a means to preserve these
Op 02-12-18 om 13:10 schreef Bruno Haible:
> - Thus the interface between the package maintainers and the TP is simpler
> if
> the package maintainers submit a tarball to the TP.
Precisely. Furthermore, when following git, how is the translator to
know that a release is approaching and
On 11/30/18 12:14 PM, Roman Bolshakov wrote:
> May I ask you to review what way we should go with ARG_MAX?
>
> I'm okay with both ways whether it's:
> * computing effective argument length and passing it to "-s" option;
> * or exploiting behaviour of GNU/BSD xargs and specifying "-n" beyond
>
13 matches
Mail list logo
