Re: [LEDE-DEV] urandom seed & /etc mount time

On 01/06/2016 23:39, Etienne Champetier wrote: > Hi, > > i'm thinking about adding a urandom seed like any distro do, > just need to know when /etc is first monted (inside procd or via init > scripts?) > > Regards > Etienne from within mount_root John >

Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.

I agree with having somehow a full build available for new users. Now that "market" seems to be catered by custom images published by some in the Owrt forum and consumed by many who want a better router firmware but don't know how to build it, and most probably don't even want to know or take the

[LEDE-DEV] Supported device list and documentation over at openwrt.org

There is a lot of very useful specific router documentation still over at openwrt.org, technical details, de-bricking info, device mods, plus loads more info and photos relating to lots of individual devices.  Would it not be wise to also bring this over to the lede website?  I quite often refer ba

[LEDE-DEV] urandom seed & /etc mount time

Hi, i'm thinking about adding a urandom seed like any distro do, just need to know when /etc is first monted (inside procd or via init scripts?) Regards Etienne ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/l

[LEDE-DEV] [PATCH procd] jail: don't always CLONE_NEWUTS

no -h => no CLONE_NEWUTS -h "" => CLONE_NEWUTS -h "newjailhostname" => CLONE_NEWUTS + sethostname Signed-off-by: Etienne CHAMPETIER --- jail/jail.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/jail/jail.c b/jail/jail.c index e425254..c442847 100644 --- a/jail/jail

[LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

The current blobmsg_format_json* functions will return invalid JSON when the "list" argument is given as false (blobmsg_format_element() will output the name of the blob_attr as if the value is printed as part of a JSON object). To avoid breaking software relying on this behaviour, introduce new f

Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.

On 01/06/2016 20:24, Dave Taht wrote: > To fork this discussion mildly, I would like to see a fuller build, > including the luci gui, available, somehow, somewhere, so that newer > users can get a working config "out of the box" from the daily builds. > > Also, at least on the archer c7v2, the a

Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.

To fork this discussion mildly, I would like to see a fuller build, including the luci gui, available, somehow, somewhere, so that newer users can get a working config "out of the box" from the daily builds. Also, at least on the archer c7v2, the ath10k kmod and firmware were not included in the d

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

On 06/01/2016 11:07 AM, John Crispin wrote: Hi Ben, also inclined to reject this one. it will open up the pandoras box and we will end up maintaining piles of diffconfig files. it would make morse sense to document what the script does inside web.git as a "how to build" or "getting started" page

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Hi, maybe we can add a well annotated variant of this script into web.git as part of the documentation tree and do some kind of build script example page? ~ Jo´ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/l

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Hi Ben, also inclined to reject this one. it will open up the pandoras box and we will end up maintaining piles of diffconfig files. it would make morse sense to document what the script does inside web.git as a "how to build" or "getting started" page John On 27/05/2016 01:57, gree...@c

Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.

Hi Ben, i am inclined to reject this one. i understand the reasoning behind the patch but the general concept is to keep images minimal. the tools might make sense to you for your use case but others will want a different selection of tools/drivers. we will never be able to find a set suitable for

Re: [LEDE-DEV] TR-069, bufferbloat, and BQL

An example of the futility of applying advanced fq and aqm techniques to overbuffered firmware or device drivers is here: http://blog.cerowrt.org/post/dql_on_wifi_2/ You'd think removing a "feature" like overbuffering in the firmware would be easy... I do not know how dsl works well enough to und

Re: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under uClibc

On 01/06/2016 19:28, Waldemar Brodkorb wrote: >> The question to you is where do you think we should fix mentioned problem: >> > 1) In uClibc-ng with addition of "%ms" support in scanf or > I would prefer this solution. I have started reading the code, but I > can't give you any guarantee when I

Re: [LEDE-DEV] TR-069, bufferbloat, and BQL

On Sat, May 28, 2016 at 7:05 AM, John Crispin wrote: > > > On 28/05/2016 16:02, Hauke Mehrtens wrote: >> On 05/28/2016 03:36 PM, Dave Taht wrote: >>> On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens wrote: On 05/27/2016 12:43 PM, David Lang wrote: > On Thu, 26 May 2016, Delbar Jos wrote:

Re: [LEDE-DEV] brcm47xx legacy broken in trunk?

There's been a similar issue 6 years ago (seems to be related to Kernel+CFE+NVRAM) https://dev.openwrt.org/ticket/7693 Any hints on where to start debugging? (Adding some printk statements, etc.) Kernel and especially the boot process (handover from CFE to kernel) is pretty new stuff for me. Tha

Re: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc

Hi Karl, Karl Palsson wrote, > > John Crispin wrote: > > > > > > On 23/05/2016 20:12, Waldemar Brodkorb wrote: > > > Hi John, > > > John Crispin wrote, > > > > > >> Hi, > > >> is it really a gnu extension or is uclibc b0rked for these symbols ? > > > > > > I think it isn't b0rked. > > > It w

Re: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under uClibc

Hi Alexey, Alexey Brodkin wrote, > Hi Waldemar, > > On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote: > > Hello, > > > > On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote: > > > > > > Hello, > > > > > > On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote: > > > > > > > > >

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] package/devel/gdb: Add support of ARC gdb

Hi Dirk, On Wed, 2016-06-01 at 18:21 +0200, Dirk Neukirchen wrote: > On 01.06.2016 17:32, Alexey Brodkin wrote: > > > > Also we disable sim because if the following breakage while > > building with it: > > >8 > > /usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/en

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] package/devel/gdb: Add support of ARC gdb

On 01.06.2016 17:32, Alexey Brodkin wrote: > Also we disable sim because if the following breakage while > building with it: > >8 > /usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \ > -mono -fast -pbb -switch sem5-switch.c \ > -cpu a5f -infile ./ml

Re: [LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to populate sysinfo

On 01.06.2016 17:14, Jo-Philipp Wich wrote: > Use the DMI data available in sysfs to extract manufacturer and model info > and write it to /tmp/sysinfo/. > > The data will be picked up by board_detect and can be used by e.g. LuCI to > display a more appropriate model description. > > On an APU bo

Re: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc

John Crispin wrote: > > > On 23/05/2016 20:12, Waldemar Brodkorb wrote: > > Hi John, > > John Crispin wrote, > > > >> Hi, > >> is it really a gnu extension or is uclibc b0rked for these symbols ? > > > > I think it isn't b0rked. > > It was added for ARM GNU libc here under #ifdef __USE_GNU: >

[LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb

As of today gdb port for ARC is not yet in upstream even though we're working hard on that. Still to allow ARC users to debug user-space apps on top of Linux kernel we're adding here support for building GDB from sources hosted on our GitHub here: https://github.com/foss-for-synopsys-dwc-arc-proce

[LEDE-DEV] [RFC v3 1/2] x86: enable DMI and DMI_SYSFS

Enable support for DMI decoding in the kernel so that we can access manufacturer and model information via sysfs. Signed-off-by: Jo-Philipp Wich --- target/linux/x86/config-4.4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/co

[LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to populate sysinfo

Use the DMI data available in sysfs to extract manufacturer and model info and write it to /tmp/sysinfo/. The data will be picked up by board_detect and can be used by e.g. LuCI to display a more appropriate model description. On an APU board the files will contain the following values: # ca

[LEDE-DEV] [RFC v3 0/2] x86: populate sysinfo from DMI data

This is a simple patch series I use locally to better identify x86 devices, I'd appreciate any opinions and testing feedback on it. Changes in v3: Use sysfs instead of dmidecode Jo-Philipp Wich (2): x86: enable DMI and DMI_SYSFS x86: use sysfs DMI information to populate sysinfo target/linu

[LEDE-DEV] [RFC v2 1/2] x86: enable DMI and DMI_SYSFS

Enable support for DMI decoding in the kernel so that we can access manufacturer and model information via sysfs. Signed-off-by: Jo-Philipp Wich --- target/linux/x86/config-4.4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/co

[LEDE-DEV] [RFC v2 2/2] x86: use sysfs DMI information to populate sysinfo

Use the DMI data available in sysfs to extract manufacturer and model info and write it to /tmp/sysinfo/. The data will be picked up by board_detect and can be used by e.g. LuCI to display a more appropriate model description. On an APU board the files will contain the following values: # ca

[LEDE-DEV] [RFC v2 0/2] x86: populate sysinfo from DMI data

This is a simple patch series I use locally to better identify x86 devices, I'd appreciate any opinions and testing feedback on it. Changes in v2: Use sysfs instead of dmidecode Jo-Philipp Wich (2): x86: enable DMI and DMI_SYSFS x86: use sysfs DMI information to populate sysinfo target/linu

Re: [LEDE-DEV] [RFC v2 2/2] x86: use sysfs DMI information to populate sysinfo

Please ignore, I exported the wrong series. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC 0/3] x86: populate sysinfo from DMI data

On Wed, 1 Jun 2016 16:32:47 +0200 Jo-Philipp Wich wrote: > This is a simple patch series I use locally to better identify x86 > devices, I'd appreciate any opinions and testing feedback on it. > > Jo-Philipp Wich (3): > x86: enable CONFIG_DEVMEM > packages: import dmidecode > x86: include

[LEDE-DEV] [RFC 2/3] packages: import dmidecode

Import the dmidecode utility from the packages feed so that we can include it by default on x86 builds. Signed-off-by: Jo-Philipp Wich --- package/utils/dmidecode/Makefile | 48 1 file changed, 48 insertions(+) create mode 100644 package/utils/dmidecode/

[LEDE-DEV] [RFC 0/3] x86: populate sysinfo from DMI data

This is a simple patch series I use locally to better identify x86 devices, I'd appreciate any opinions and testing feedback on it. Jo-Philipp Wich (3): x86: enable CONFIG_DEVMEM packages: import dmidecode x86: include dmidecode by default and use it to populate sysinfo package/utils/dmide

[LEDE-DEV] [RFC 3/3] x86: include dmidecode by default and use it to populate sysinfo

Use the dmidecode utility to extract manufacturer and model info from the system DMI data and write it to /tmp/sysinfo/. The data will be picked up by board_detect and can be used by e.g. LuCI to display a more appropriate model description. On an APU board the files will contain the following va

[LEDE-DEV] [RFC 1/3] x86: enable CONFIG_DEVMEM

Enable support for /dev/mem in the kernel since it is required by the dmidecode utility. Signed-off-by: Jo-Philipp Wich --- target/linux/x86/config-4.4 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4 index 5b54031..f1a3218 100644 ---

Re: [LEDE-DEV] [PATCH] netifd: Add option to configure gc_stale_time for each device

Hi Alin, pulled into netifd.git after some slight rebasing: http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=fef10041f3a495d79f03f99bdf416a68a0ee91aa Please verify whether the change is still correct before we bump the netifd package. Thanks! ~ Jow ___

Re: [LEDE-DEV] [OpenWrt] TR-069 for OpenWrt

On 30 May 2016 at 11:58, Delbar Jos wrote: > > Felix Fietkau wrote: > > > We are conscious of the fact that together with the proposals made by > > > Felix, Luka and Wojtek we are now looking at many "competing" proposals. > > > As a next step, we recommend to organize a wor

Re: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under uClibc

Hi Waldemar, On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote: > Hello, > > On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote: > > > > Hello, > > > > On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote: > > > > > > > > > This fixes util-linux building with uClibc. > > > Patch