On Tue, Jul 3, 2012 at 10:44 PM, Alan Stern wrote:
> On Tue, 3 Jul 2012, Xiaofan Chen wrote:
>
>> Actually what I complained is this one (extra ">" before "From"
>> which is probably caused by the mailing list software.
>> >From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001
>
>
On Wed, Jul 4, 2012 at 12:22 AM, Pete Batard wrote:
> On 2012.07.03 14:38, Xiaofan Chen wrote:
>> I sent the patch both inline and as an attachment using Gmail.
>> Both are okay from what I see, no extra ">". But maybe you
>> will see the ">" for the inline version. Did you see the ">" for
>> my a
On 2012.07.03 14:38, Xiaofan Chen wrote:
> I sent the patch both inline and as an attachment using Gmail.
> Both are okay from what I see, no extra ">". But maybe you
> will see the ">" for the inline version. Did you see the ">" for
> my attachment?
Yup. This is how Thunderbird displays the inlin
On Tue, 3 Jul 2012, Xiaofan Chen wrote:
> Actually what I complained is this one (extra ">" before "From"
> which is probably caused by the mailing list software.
> >From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001
Xiaofan, have you read "The UNIX-HATERS Handbook" by Garfink
On Tue, Jul 3, 2012 at 9:26 PM, Pete Batard wrote:
> On 2012.07.03 13:59, Xiaofan Chen wrote:
>>> NB: This patch should be attached as inline
>>
>> Actually it comes to me as both inline and attachment
>
> Which is exactly what I want.
I see. In that case, no problem.
> "Pure" inline is a PITA t
On 2012.07.03 13:59, Xiaofan Chen wrote:
>> NB: This patch should be attached as inline
>
> Actually it comes to me as both inline and attachment
Which is exactly what I want.
"Pure" inline is a PITA to work with, because everything's just text and
you never know if there's something of value in
On Tue, Jul 3, 2012 at 6:04 PM, Pete Batard wrote:
> v2, that applies Hans' suggestion.
>
> NB: This patch should be attached as inline
>
Actually it comes to me as both inline and attachment and both
are with the extra ">". Kind of strange, either something is wrong
with Gmail or something is wr
On Tue, Jul 3, 2012 at 5:23 PM, Pete Batard wrote:
> On 2012.07.03 08:33, Hans de Goede wrote:
>> Next time please send patches inline, that makes replying to them for a
>> review a lot easier.
>
> This is getting old.
>
> The thing is, Segher complained once, so I went inline, then Xiaofan
> comp
v2, that applies Hans' suggestion.
NB: This patch should be attached as inline
Regards,
/Pete
>From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Mon, 2 Jul 2012 23:39:19 +0100
Subject: [PATCH] Core: Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflict
On 2012.07.03 08:33, Hans de Goede wrote:
> Next time please send patches inline, that makes replying to them for a
> review a lot easier.
This is getting old.
The thing is, Segher complained once, so I went inline, then Xiaofan
complained about the extra '>' character, so I reverted back to non
On 2012.07.03 09:27, Tobias Powalowski wrote:
> Now libusb-compat errors with this during compile:
> core.c:35:6: error: nested redefinition of 'enum usbi_log_level'
> core.c:35:6: error: redeclaration of 'enum usbi_log_level'
> In file included from core.c:27:0:
This is a known issue.
Please app
Now libusb-compat errors with this during compile:
core.c:35:6: error: nested redefinition of 'enum usbi_log_level'
core.c:35:6: error: redeclaration of 'enum usbi_log_level'
In file included from core.c:27:0:
/usr/include/libusb-1.0/libusb.h:962:6: note: originally defined here
make[2]: *** [libus
Hi,
On 07/03/2012 12:43 AM, Pete Batard wrote:
> As per the roadmap. This is something I realized right after 1.0.12, as
> LOG_LEVEL_XYZ is lilely to be generic enoug to conflict with other apps and
> headers that may define those as well.
>
> This is also in part the source of Trac #31, which i
As per the roadmap. This is something I realized right after 1.0.12, as
LOG_LEVEL_XYZ is lilely to be generic enoug to conflict with other apps
and headers that may define those as well.
This is also in part the source of Trac #31, which is an issue with
libusb-compat, as libusb-compat's core.
14 matches
Mail list logo
