I have configured button definition in the mach-file as below:
.desc = "LAN WIFI button",
.type = EV_KEY,
.code = KEY_LAN_WIFI_BUTTON,
.debounce_interval = DB120_KEYS_DEBOUNCE_INTERVAL,
.g
> RFC6303 specifies reverse dns zones that ideally should not be forwarded
> to upstream (root) servers and create unnecessary load upon them.
Shouldn't this be done upstream (i.e. in dnsmasq directly) rather than
in our config?
Stefan
___
open
Hi,
Le 18 oct. 2015 21:31, "Dirk Brenken" a écrit :
>
> Hi,
>
> I can't see the diff/patch below on patchwork, anything wrong with the
> submitted patch?
How did you generate it?
You should use git send-email, and resend.
Also add the size before/after in the commit message.
>
> Thanks
> Dirk
>
Hi,
I can't see the diff/patch below on patchwork, anything wrong with the
submitted patch?
Thanks
Dirk
Am Freitag, den 16.10.2015, 12:10 +0200 schrieb Dirk Brenken:
> busybox binary in openwrt neither supports stat nor find mtime. This
> patch adds find mtime support by default.
>
> Signed-of
On 18 October 2015 at 00:16, Stijn Tintel wrote:
> On 17-07-15 19:35, Roman Yeryomin wrote:
>> Signed-off-by: Roman Yeryomin
>> ---
>>
> Hi Roman,
>
> Since ar71xx uses 4.1 kernel by default, MAC addresses on my Ubiquiti
> RSPro's are random. I suspect it is due to the changes in
> 506-MIPS-ath79
RFC6303 specifies reverse dns zones that ideally should not be forwarded
to upstream (root) servers and create unnecessary load upon them.
Signed-off-by: Kevin Darbyshire-Bryant
---
package/network/services/dnsmasq/files/dhcp.conf | 30
1 file changed, 30 insertions(+)
On 10/18/2015 03:47 PM, Arturo Rinaldi wrote:
> Hello folks,
>
> I need to build a mips-uclicbx-ar71xx toolchain based on the gcc v4.9
> series for purposes of my own. I reverted the trunk to this commit with :
>
> /commit d39916a2a31fa41c5e2dc5a1941d3b5337ad9dd4//
> //Author: nbd //
> //Date:
Hello folks,
I need to build a mips-uclicbx-ar71xx toolchain based on the gcc v4.9
series for purposes of my own. I reverted the trunk to this commit with :
/commit d39916a2a31fa41c5e2dc5a1941d3b5337ad9dd4//
//Author: nbd //
//Date: Sun Sep 6 09:57:02 2015 +//
//
//uboot-ar71xx: fix
Yep, seen this a couple of times.
You're building for an x86 target, but you're including the host Python's
Python.h file.
Any idea why this happens ? Or if you're include paths are ok ?
It could also [very likely] be a regression with the Python package.
If you want, you could show me your Makef
