OK, thanks, I pushed it.
On 07/05/2012 12:29 AM, Paul Eggert wrote:
> Thanks for reporting this. Does the following patch fix things?
>
> ---
> ChangeLog |9 +
> m4/pthread.m4 | 33 +++--
> 2 files changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/ChangeLog b/Chan
Thanks for reporting this. Does the following patch fix things?
---
ChangeLog |9 +
m4/pthread.m4 | 33 +++--
2 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index cd3ba33..a332d7b 100644
--- a/ChangeLog
+++ b/C
Dear everyone,
Commit a6322904ea944ba119aaa62c0c3ee7cfade8b59c in gnulib causes
coreutils to fail to build on FreeBSD 9. This broke the Gentoo Prefix
bootstrap process, for which there is an open bug:
https://bugs.gentoo.org/show_bug.cgi?id=415439
The build system assumes that the presence of pt
On 04-07-12 14:08, Eric Blake wrote:
[adding gnulib]
On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
==6825==
==6825== Invalid read of size 4
==6825==at 0xA57E4B9: base64_encode (in
/usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
==6825==by 0x10DDBC98: base64_encode_alloc (base64.c:
With URL-safe base64 the + and / are replaced by - and _
This way we can accept base64 strings which are URL-safe.
Signed-off-by: Wido den Hollander
---
lib/base64.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/base64.c b/lib/base64.c
index 194e9ca..be91495 100644
--- a/lib/base
On Wed, Jul 04, 2012 at 06:08:59AM -0600, Eric Blake wrote:
> [adding gnulib]
>
> On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
>
> >>> ==6825==
> >>> ==6825== Invalid read of size 4
> >>> ==6825==at 0xA57E4B9: base64_encode (in
> >>> /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
> >>> =
On Wed, Jul 04, 2012 at 04:17:39PM +0200, Wido den Hollander wrote:
>
>
> On 04-07-12 14:08, Eric Blake wrote:
> >[adding gnulib]
> >
> >On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
> >
> ==6825==
> ==6825== Invalid read of size 4
> ==6825==at 0xA57E4B9: base64_encode (in
>
[adding gnulib]
On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:
>>> ==6825==
>>> ==6825== Invalid read of size 4
>>> ==6825==at 0xA57E4B9: base64_encode (in
>>> /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
>>> ==6825==by 0x10DDBC98: base64_encode_alloc (base64.c:140)
>>>
>>> This one
Jim Meyering wrote:
> Bruno Haible wrote:
>> Jim Meyering wrote:
>>> +static inline unsigned char to_uchar (char ch) { return ch; }
>>
>> For the use of 'inline', one needs this too:
>> +++ m4/parse-datetime.m4 Wed Jul 4 10:04:36 2012
>> + AC_REQUIRE([AC_C_INLINE])
>
> Thanks, Bruno.
> Here's
On Tue, Jul 3, 2012 at 12:51 PM, Misty De Meo wrote:
> The bug Don is experiencing is a gnulib bug. It seems to have been
> introduced by commit d0f486f09869cad33c4a7039d88e45fedd815c23, which
> removed several automake scripts. I've verified that it occurs on both
> OS X and Ubuntu; I'll take thi
Bruno Haible wrote:
> Jim Meyering wrote:
>> +static inline unsigned char to_uchar (char ch) { return ch; }
>
> For the use of 'inline', one needs this too:
> +++ m4/parse-datetime.m4 Wed Jul 4 10:04:36 2012
> + AC_REQUIRE([AC_C_INLINE])
Thanks, Bruno.
Here's the complete patch on the gnuli
Jim Meyering wrote:
> +static inline unsigned char to_uchar (char ch) { return ch; }
For the use of 'inline', one needs this too:
--- m4/parse-datetime.m4.orig Wed Jul 4 10:04:43 2012
+++ m4/parse-datetime.m4Wed Jul 4 10:04:36 2012
@@ -1,4 +1,4 @@
-# parse-datetime.m4 serial 19
+# pa
peter evans wrote:
> Thank you for closing this as "not a bug".
>
> So it is not a bug that date is unable to parse its own output in
> arbitrary locales.
> Indeed, it would "not be a bug" if it stopped and complained about
> it. That would be
> perfectly acceptable.
>
> "date" however, goes one be
> From: Paul Eggert [mailto:egg...@cs.ucla.edu]
> Sent: Wednesday, July 04, 2012 9:10 AM
> To: Joachim Schmitz
> Cc: bug-gnulib@gnu.org
> Subject: Re: alloca in HP NonStop
>
> On 07/04/2012 12:05 AM, Joachim Schmitz wrote:
> > Still missing seems the detection of this by configure?
>
> As things
On 07/04/2012 12:05 AM, Joachim Schmitz wrote:
> Still missing seems the detection of this by configure?
As things stand, I don't see why 'configure' needs to
detect anything. You mentioned the possibility of
it detecting but the code works fine
without needing HAVE_BUILTINS_H. So I assume this
> From: Paul Eggert [mailto:egg...@cs.ucla.edu]
> Sent: Tuesday, July 03, 2012 7:13 PM
> To: Joachim Schmitz
> Cc: bug-gnulib@gnu.org
> Subject: Re: alloca in HP NonStop
>
> On 07/03/2012 02:56 AM, Joachim Schmitz wrote:
> > Or rather: we need that prototype before the pragma
>
> OK, in that case
17 matches
Mail list logo
