Philip Prindeville wrote on 28.10.2017 23:20:
Hi all,
Does it seem to anyone else that we’re making this more complicated than it
needs to be?
If one of the goals we’re going for from here on out is “equality”, then a
basic litmus test to be applied to any action might be “does this get us
On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote:
> Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017:
> > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605
> > fix regression in glob with literal . or .. path component
>
> Based on musl mailing list,
Hi all,
Does it seem to anyone else that we’re making this more complicated than it
needs to be?
If one of the goals we’re going for from here on out is “equality”, then a
basic litmus test to be applied to any action might be “does this get us closer
to a level playing field, or further
Hi,
I recently updated my Netgear WNDR4300 to LEDE 17.01.4 and the only thing that
appears broken is the USB LED trigger. The LED works fine and while the USB
port is detected, functional, setting it as a trigger does not make the LED
blink. Was there any fix not backported to the lede-17.01
Dear Florian,
Seems the discussion that was raised on using a personal openwrt address in a
SOB does not do much good so far and it is certainly not my intention to go
against rule #12; I would be sorry if I did. The question I raised is, although
about personal addresses, absolutely not aimed
Hi,
I have a TL-WR841N v13 with LEDE git snapshot r5174-34958c8.
With the same Hardware running on OEM firmware I had a working wireless
link in the garden house (~15m away), since I flashed LEDE I can see the
Basestation, but association/authentication fails due to timeout.
The awesome AES performance was too good to be true: it seems to produce
incorrect results when encrypting on the pine64 and decrypting on a x86_64
machine :(
Possibly some assembler is optimized away by the compiler, which would
explain why it's so fast. Please don't merge for now until I
