Re: [LEDE-DEV] A Wiki for LEDE Documentation

2016-09-12 Thread Fernando Frediani
A while ago in the begining of the project, put my time and myself to
be one of the responsible to set it up, give it LEDE's face, and start
transfering content from OpenWrt but unfortunatelly almost nobody
bored much at the time. It seemed that if you are not a "known person"
you might not get much reply.

Here we go with this topic again, thankfuly as a nice wiki is more than needed.

I don't mind about the wiki software much, they all have pretty much
the same concept and even if it's a different one it mighy actually be
a chance to refresh formats and review information with more care.
I like MediaWiki with VisualEditor plugin. Makes it a lot friendly for
everybody to edit.

On 9 September 2016 at 21:26, J Mo  wrote:
>
> On 09/09/2016 05:17 PM, nobody in particular wrote:
>>
>> we should
>
>
>
> Less "We oughta"
>
> More "I will"
>
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] [PATCH v2] toolchain: Rework external toolchain libc selection

2016-09-12 Thread Florian Fainelli
On 09/07/2016 10:26 AM, Florian Fainelli wrote:
> Make it a choice menu which offers the 3 C libraries we know about: glibc,
> uClibc and musl. While at it, make it possible for the external toolchain libc
> to select USE_GLIBC, USE_UCLIBC or USE_MUSL which is used by several packages
> to conditionally include specific CFLAGS (e.g: iproute2).
> 
> Because USE_GLIBC et al. can now be selected by external toolchains, we need 
> to
> restrict the per-libc menus to check on !EXTERNAL_TOOLCHAIN.
> 
> While at it, make musl the default C library for external toolchain to match
> the internal toolchain.
> 
> Signed-off-by: Florian Fainelli 
> ---
> Changes in v2:
> 
> - do not make musl broken
> - make musl the default
> 
>  toolchain/Config.in| 21 ++---
>  toolchain/glibc/Config.in  |  2 +-
>  toolchain/uClibc/Config.in |  2 +-
>  3 files changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index 75dc5361a682..7ec1875862d4 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -96,17 +96,32 @@ menuconfig EXTERNAL_TOOLCHAIN
>   default "/opt/cross/powerpc-unknown-linux-gnu"  if powerpc
>   default "/opt/cross/x86_64-unknown-linux-gnu"   if x86_64
>  
> - config TOOLCHAIN_LIBC
> - string

Since this was directly passed down to scripts/ext-toolchain.sh, it
seems like we may need need to assign this value somehow based on the
choice offered below, I will respin a patch doing that.
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


[LEDE-DEV] gen_initramfs_list.sh escaping problem or stale dependency file?

2016-09-12 Thread Florian Fainelli
Hi,

I have a root filesystem embedding filenames that look like these:

/lib/data/:

these are essentially files that can be matched against an USB
vendor/product id in an easy way.

Now, the fun part is that this is only a problem when doing the
following (using OpenWrt/LEDE as a build system):

1:
- set CONFIG_INITRAMFS_SOURCE=""
- build kernel modules
- build my user-space tools
- build the kernel image
- reconfigure the kernel to now use an initramfs
- build the kernel w/ initramfs

and then back to step 1 with the kernel build, would I hit this error:

usr/Makefile:64: *** multiple target patterns.  Stop.

which comes from usr/.initramfs_data.cpio.d containing these files
without escaping:

deps_initramfs := ./scripts/gen_initramfs_list.sh \
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib
\
...

/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan
\
/exp00/fainelli/openwrt/trunk/build_dir/target-arm-linux-gnueabihf/root-brcmstb/lib/network/wwan/19d2:0063
\

Which sorts of make sense here because the file name contains a ":"
which is not escaped, so GNU Make tries to interpret it.

Now the part that does not quite make sense to me is why this file is
even relevant here considering that the first thing we do is set
CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.

Any clues what could be wrong here? I am happy to provide any build
drops you may need to reproduce that.

Thanks!
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] A Wiki for LEDE Documentation

2016-09-12 Thread Jan-Tarek Butt
Hi,

> Yeah, I'm also willing to dedicate some hours per week to wiki gardening, 
> whatever wiki technology is chosen.

Shall I do set up a dokuwiki on our open wireless community infrastructure?

cheers
Tarek



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev