On 11.05.2018 00:55, Lev wrote:
On Thu, 10 May 2018 23:49:36 +0200
Felix Fietkau wrote:
On 2018-05-10 23:23, Lev wrote:
From: Lev
Please explain what you're trying to do here.
The patch makes no sense to me.
glibc v2.26 was not found any of
On 05/10/2018 04:55 PM, Lev wrote:
> On Thu, 10 May 2018 23:49:36 +0200
> Felix Fietkau wrote:
>
>> On 2018-05-10 23:23, Lev wrote:
>>> From: Lev
>> Please explain what you're trying to do here.
>> The patch makes no sense to me.
>
>
> glibc
On Thu, 10 May 2018 23:49:36 +0200
Felix Fietkau wrote:
> On 2018-05-10 23:23, Lev wrote:
> > From: Lev
> Please explain what you're trying to do here.
> The patch makes no sense to me.
glibc v2.26 was not found any of the mirrors, but v2.22 is.
On 2018-05-10 23:23, Lev wrote:
> From: Lev
Please explain what you're trying to do here.
The patch makes no sense to me.
- Felix
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
From: Lev
---
toolchain/glibc/common.mk | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/toolchain/glibc/common.mk b/toolchain/glibc/common.mk
index b10e797de6..7ff684d52c 100644
--- a/toolchain/glibc/common.mk
+++
> On 9 May 2018, at 11:27, Daniel Danzberger wrote:
>
> On 05/
>>
>>
>> So that smells more of a race condition between the writer filling with 0xFF
>> and the reader catching up.
> The open() syscall does the memset(0xff) and blocks. This ensures the memory
> is
>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Tested-by: Michael Yartys
Hi Micheal,
> -Original Message-
> From: Michael Heimpold [mailto:m...@heimpold.de]
> Sent: Wednesday, May 9, 2018 6:29 PM
> To: Y.b. Lu
> Cc: lede-dev@lists.infradead.org; Xiaobo Xie ;
> openwrt-de...@lists.openwrt.org; Hauke Mehrtens
On Donnerstag, 10. Mai 2018 05:29:01 CEST Dongming Han wrote:
> We actually allocate two MAC per GL-AR750. In manufacturing procedure, every
> scan of device label consumes two MAC in database.
Thanks for the fast reply.
> Is there any pitfall not having unique MAC per interface on some use