Thanks, I installed that into the gnulib master.
On Tuesday 06 of October 2015 00:42:01 Paul Eggert wrote:
> Pavel Raiskup wrote:
> > Adjusted patch re-attached.
>
> Whoops, it looks like that patch has a problem with unicase/locale-language;
> could you please look into it? Here's how to reproduce it:
>
> ./gnulib-tool --test unicase/locale-
Pavel Raiskup wrote:
Adjusted patch re-attached.
Whoops, it looks like that patch has a problem with unicase/locale-language;
could you please look into it? Here's how to reproduce it:
./gnulib-tool --test unicase/locale-language
This eventually generates:
executing aclocal -I glm4
config
Thanks, I installed that.
Berny, thanks for the review and sorry for the delay.
On Thursday 16 of July 2015 16:53:42 Bernhard Voelker wrote:
> On 07/16/2015 04:19 PM, Jim Meyering wrote:
> >echo "$final_modules" | LC_ALL=C grep '^extensions$' >/dev/null \
>
> why would we need LC_ALL here at all? IMO this is sufficie
On 07/16/2015 04:19 PM, Jim Meyering wrote:
echo "$final_modules" | LC_ALL=C grep '^extensions$' >/dev/null \
why would we need LC_ALL here at all? IMO this is sufficient:
echo "$final_modules" | grep '^extensions$' >/dev/null \
btw: one could even completely avoid the "| grep" by let
On Thursday 16 of July 2015 07:19:37 Jim Meyering wrote:
> Please change that to use LC_ALL=C rather than LANG=C.
> LC_ALL supercedes all other LC_* variables. LANG=... used to be
> relevant with old glibc, but even then, that was contrary to POSIX.
>
> Also, prefer single quotes around the regexp
On Thu, Jul 16, 2015 at 6:58 AM, Pavel Raiskup wrote:
> On Tuesday 14 of July 2015 06:29:15 Eric Blake wrote:
>> Overall, seems like it is correct, once you fix the typos.
>
> Thanks for your review, fixed patch attached.
Thanks for the patch.
Haven't reviewed thoroughly, but did see this:
+
On Tuesday 14 of July 2015 06:29:15 Eric Blake wrote:
> Overall, seems like it is correct, once you fix the typos.
Thanks for your review, fixed patch attached.
Pavel
>From cc0cd1c751d54af0d7211e321f40ce99b0f68b62 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup
Date: Thu, 2 Jul 2015 13:58:22 +0200
On 07/02/2015 06:32 AM, Pavel Raiskup wrote:
> Subject: [PATCH] gnulib-common.m4: fix gl_PROG_AR_RANLIB/AM_PROG_AR clash
>
> The gl_PROG_AR_RANLIB (it is always called by gl_EARLY) sets AR
> and ARFLAGS variables. Doing this unconditionally could brake
s/brake/break/
> latter Automake's AM_PRO
On Wednesday 01 of July 2015 16:38:57 Pádraig Brady wrote:
> On 01/07/15 16:22, Pavel Raiskup wrote:
> > Yes, there is still nothing like that in gnulib-tool, am I right? I mean
> > dependency among configure.ac-early snippets -- those seem to be all just
> > sorted by name (by 'LANG=C sort -u').
On 01/07/15 16:22, Pavel Raiskup wrote:
> On Wednesday 01 of July 2015 15:19:15 Pádraig Brady wrote:
>> On 01/07/15 14:57, Pavel Raiskup wrote:
>>> On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
>> On 01/07/15 09:00, Pavel Raiskup wrote:
> This becomes painfully complicated, sor
On Wednesday 01 of July 2015 15:19:15 Pádraig Brady wrote:
> On 01/07/15 14:57, Pavel Raiskup wrote:
> > On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
> On 01/07/15 09:00, Pavel Raiskup wrote:
> >>> This becomes painfully complicated, sorry to bothering you - just trying
> >>> to
On 01/07/15 14:57, Pavel Raiskup wrote:
> On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
On 01/07/15 09:00, Pavel Raiskup wrote:
>>> This becomes painfully complicated, sorry to bothering you - just trying
>>> to make this ARFLAGS/AR_FLAGS mess resolved. I would appreciate any hel
On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys: I haven't done proper analysis yet. Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project? If yes, could we possibly at least set the ARFLAGS
> default value to 'cr' instead of '
15 matches
Mail list logo
