Re: [LEDE-DEV] brcm47xx legacy image building issues

[Rafał Miłecki]

On 01/02/2017 04:50 PM, Eric Masson wrote:

I get the following error while trying to generate an image for a WGT634U :
emss@vmwdebems:~/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64$ make image 
PACKAGES="aiccu fwknopd luci luci-app-firewall luci-app-fwknopd luci-app-sqm 
luci-proto-ipv6 luci-proto-ppp tcpdump -dnsmasq iputils-traceroute6 
kmod-nf-nathelper-extra"

(...)

lede-imagebuilder-brcm47xx-legacy.Linux-x86_64.tar.xz is Mon Jan 2 16:40:22 
2017 version.

This used to work, any idea, please ?


I just downloaded and extracted
https://downloads.lede-project.org/snapshots/targets/brcm47xx/legacy/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64.tar.xz

I entered lede-imagebuilder-brcm47xx-legacy.Linux-x86_64 and executed your 
command. It worked fine.

I see 3 options:
1) Something got fixed in "Tue Jan 3 06:46:26 2017"
2) You are doing something extra you didn't describe
3) There is some issue specific to your host

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

Re: [LEDE-DEV] Bug in ipkg?

[Philip Prindeville]

> On Jan 2, 2017, at 10:08 PM, Philip Prindeville 
>  wrote:
> 
> Okay, resolved….  I needed to change the Package/perl-cgi/install macro in 
> the Makefile to invoke perlmod/Install/NoStrip instead of perlmod/Install.  
> Sigh.
> 
> Would it be reasonable to add a global variable which disables the stripping 
> in perlmod/Install?
> 
> If you’re on a box with a decent amount of cycles and adequate flash, then I 
> don’t really see the point of stripping comments from the Perl anyway…
> 
> -Philip
> 


Okay, and here’s a fix… though it might also be nice to allow packages 
themselves to indicate that they’re known to get mangled by perlmod.mk…




perlmod-unstripped.patch
Description: Binary data
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Bug in ipkg?

[Philip Prindeville]

> On Jan 2, 2017, at 9:59 PM, Philip Prindeville 
>  wrote:
> 
> 
>> On Jan 2, 2017, at 9:32 PM, Philip Prindeville 
>>  wrote:
>> 
>> I just saw something bizarre.
>> 
>> I had a Perl module (CGI v4.35) which contained the following:
>> 
>> my $appease_cpants_kwalitee = q/
>> use strict;
>> use warnings;
>> #/;
>> 
>> which is just a quoted string containing the lines that some sanity checking 
>> code expects to see (albeit as actual code, and not embedded as a string 
>> constant).
>> 
>> That was in the original source.
>> 
>> Getting into build_dir/target-xxx/perl/CGI-4.35/ and looking at 
>> ipkg-install/usr/lib/perl5/5.22/CGI.pm it’s identical to what’s in the 
>> tarball.
>> 
>> However, looking at ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22/CGI.pm I see 
>> that every line starting with /^#/ has been deleted.  WTH???
>> 
>> Interestingly, lines beginning with /^[ \t]+#/ are untouched.
>> 
>> Is ipkg doing something evil like stripping lines that it (apparently 
>> incorrectly) thinks are comments to save space?  And if so, why
>> 
>> How do I disable this?
>> 
>> Thanks,
>> 
>> -Philip
>> 
> 
> 
> And here’s the offending code:
> 
> (cd 
> /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-install/usr/lib/perl5/5.22
>  && rsync --relative -rlHp --itemize-changes --exclude=\*.pod 
> --exclude=.packlist  --prune-empty-dirs CGI CGI.pm auto/CGI 
> /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22)
>> f+ CGI.pm
> cd+ CGI/
>> f+ CGI/Carp.pm
>> f+ CGI/Cookie.pm
>> f+ CGI/Pretty.pm
>> f+ CGI/Push.pm
>> f+ CGI/Util.pm
> cd+ CGI/File/
>> f+ CGI/File/Temp.pm
> cd+ CGI/HTML/
>> f+ CGI/HTML/Functions.pm
> chmod -R u+w 
> /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
> ---> Stripping modules in: 
> /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
> find 
> /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
>  -name \*.pm -or -name \*.pl | xargs -r sed -i -e 
> '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,/^=cut/d' -e 
> '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,$d' -e 
> '/^#$/d' -e '/^#[^!"'"'"']/d’
> 
> 
> those last 2 expressions being passed to sed…
> 
> If I have something like:
> 
> my $hdr = <<__EOF__ ;
> #!/bin/bash -x
> 
> __EOF__
> 
> then it’s going to totally do the wrong thing…  It thinks that’s a comment 
> but it’s not, it’s a literal in a here-document…
> 

Okay, resolved….  I needed to change the Package/perl-cgi/install macro in the 
Makefile to invoke perlmod/Install/NoStrip instead of perlmod/Install.  Sigh.

Would it be reasonable to add a global variable which disables the stripping in 
perlmod/Install?

If you’re on a box with a decent amount of cycles and adequate flash, then I 
don’t really see the point of stripping comments from the Perl anyway…

-Philip


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

Re: [LEDE-DEV] Bug in ipkg?

[Philip Prindeville]

> On Jan 2, 2017, at 9:32 PM, Philip Prindeville 
>  wrote:
> 
> I just saw something bizarre.
> 
> I had a Perl module (CGI v4.35) which contained the following:
> 
> my $appease_cpants_kwalitee = q/
> use strict;
> use warnings;
> #/;
> 
> which is just a quoted string containing the lines that some sanity checking 
> code expects to see (albeit as actual code, and not embedded as a string 
> constant).
> 
> That was in the original source.
> 
> Getting into build_dir/target-xxx/perl/CGI-4.35/ and looking at 
> ipkg-install/usr/lib/perl5/5.22/CGI.pm it’s identical to what’s in the 
> tarball.
> 
> However, looking at ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22/CGI.pm I see that 
> every line starting with /^#/ has been deleted.  WTH???
> 
> Interestingly, lines beginning with /^[ \t]+#/ are untouched.
> 
> Is ipkg doing something evil like stripping lines that it (apparently 
> incorrectly) thinks are comments to save space?  And if so, why
> 
> How do I disable this?
> 
> Thanks,
> 
> -Philip
> 


And here’s the offending code:

(cd 
/home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-install/usr/lib/perl5/5.22
 && rsync --relative -rlHp --itemize-changes --exclude=\*.pod 
--exclude=.packlist  --prune-empty-dirs CGI CGI.pm auto/CGI 
/home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22)
>f+ CGI.pm
cd+ CGI/
>f+ CGI/Carp.pm
>f+ CGI/Cookie.pm
>f+ CGI/Pretty.pm
>f+ CGI/Push.pm
>f+ CGI/Util.pm
cd+ CGI/File/
>f+ CGI/File/Temp.pm
cd+ CGI/HTML/
>f+ CGI/HTML/Functions.pm
chmod -R u+w 
/home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
---> Stripping modules in: 
/home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
find 
/home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22
 -name \*.pm -or -name \*.pl | xargs -r sed -i -e 
'/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,/^=cut/d' -e 
'/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,$d' -e '/^#$/d' 
-e '/^#[^!"'"'"']/d’


those last 2 expressions being passed to sed…

If I have something like:

my $hdr = <<__EOF__ ;
#!/bin/bash -x

__EOF__

then it’s going to totally do the wrong thing…  It thinks that’s a comment but 
it’s not, it’s a literal in a here-document…



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

Re: [LEDE-DEV] sqm-scripts change GitHub link to https:// instead of git://

[Etienne Champetier]

(forgot to send in plain text, sending again for the ML)

Hi Nick,

2017-01-02 17:02 GMT-08:00 Nick Kamenyitzky :
>
> Is there any reason that the sqm-scripts makefile has a git:// link
> instead of a https:// link?  At my office git:// doesn't work but
> https:// does.
>
> Should this be something that is standardised or considered?

We should default to https I think but in the mean time, git config
can solve your problem

git config --global url.https://github.com/.insteadOf git://github.com/

http://stackoverflow.com/a/11383587/7270974

Regards
Etienne

>
>
>
>
> Kind Regards,
>
> Nick Kamenyitzky
>
> -
> Email: n...@kamenyitzky.com.au
> -
>
> ___
> 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] Release Planning - Current Status?

[Rich Brown]

Hi Jo,

> there hasn't been much progress on the planning since I didn't follow
> any mails for the last week or so :)
> 
> I plan to factor in the various suggestions into the roadmap I initially
> posted and put the result into the wiki tomorrow.

Excellent! Once that's public, we can spread the word on the forums as needed.

> The idea is to have a definitive timeline until Friday so we can start
> branching and preparing builds.

Sounds good.

> I'm not totally sure whether we want to have a distinct RC phase (as in
> tagging RCs). The pre-release branch build artifacts can serve the same
> purpose and are reasonably stable - there should be no incompatible
> kmods every 24h in contrast to master builds as the kernel config will
> likely remain the same unless we really need to fix something there.

I have a few questions/concerns:

- Who are the people driving the release? Who makes the decisions about when to 
freeze features, to review bug reports, to branch, etc? (I care mostly that 
there is a decision-making process in place, not so much about the particular 
choices.)

- Your note directly addresses my worries about incompatibilities during 
testing. I think people hold off on testing a project because it's moving too 
quickly. A symptom of this is people who're complaining that they can't load 
package xyz today because their build from yesterday had all its underpinnings 
switched out overnight. 

- I believe we will see a step function in the number of people testing once we 
declare a version that will remain stable for a week or two, that can be opkg'd 
safely a couple days after the initial install. And given that it's a pain in 
the patootie for most people to flash their firmware (especially getting 
"clearance" from our spouses and children who rely on the router), these people 
will flock to try out LEDE once we cross that threshold.

- As someone who's trying to come up with a description of this ever-changing 
software status, I want to know that there'll be a "name" or a URL that I can 
use to refer people to that "stable" (stable-ish) build once we get a "release 
candidate" out.

- Has anyone been thinking about publicity for the release candidates and 
final? I envision an expanding circle of announcements for our release 
candidates: First to lede-dev and the forum. Later an announcement on the 
OpenWrt forum. And who's going to write the announcement for Slashdot? Do we 
need to buy another server first? :-) 

Thanks.

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

[LEDE-DEV] sqm-scripts change GitHub link to https:// instead of git://

[Nick Kamenyitzky]

Is there any reason that the sqm-scripts makefile has a git:// link
instead of a https:// link?  At my office git:// doesn't work but
https:// does.

Should this be something that is standardised or considered?



Kind Regards,

Nick Kamenyitzky

-
Email: n...@kamenyitzky.com.au
-

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Philip Prindeville]

> On Jan 2, 2017, at 1:38 PM, Alberto Bursi  wrote:
> 
> 
> 
> On 01/02/2017 07:36 PM, Philip Prindeville wrote:
>> 
>> 
>> Right, this is why I’m trying to create a new target (or subtarget) called 
>> “xeon” which is optimized for Xeon targets and leverages the on-chip 
>> crypto-accelerators.
>> 
>> We’ve come a long way since the Athalon-64 (k8) in 2004.
>> 
>> -Philip
>> 
> 
> Wait a sec, what you mean exactly for "on chip crypto accelerators"?
> If you mean AES-NI there was already a discussion about that in the 
> mailing list, see here 
> http://lists.infradead.org/pipermail/lede-dev/2016-October/003545.html
> 
> -Alberto

No, not specifically for wireless, no.

I’m looking at IPsec and encrypted GRE usage cases.

-Philip



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

Re: [LEDE-DEV] Adding new targets/subtargets

[Philip Prindeville]

> On Jan 2, 2017, at 1:05 PM, Stefan Lippers-Hollmann  wrote:
> 
> Hi
> 
> On 2017-01-02, Philip Prindeville wrote:
>>> On Jan 2, 2017, at 10:01 AM, Jo-Philipp Wich  wrote:
>>> 
>>> Hi,
>>> 
 The x86/64/config-default is missing the following switches:
 
 CONFIG_MCORE2=y  
> [...]
>> Right, this is why I’m trying to create a new target (or subtarget) called 
>> “xeon” which is optimized for Xeon targets and leverages the on-chip 
>> crypto-accelerators.
> 
> This is just an optimization, but not actually needed to get the
> firmware running on your target CPU. While it may, or may not, provide
> measurable speedups, none of the large(r) binary distros consider this
> to be a necessary optimization, so why do you think it's necessary to
> provide just this tiny micro-optimization as a dedicated subtarget with
> all the overhead this entails - rather than just using as a local 
> configuration for your own builds?


There are several useful reasons to do so.

Because it may shake out some bugs in the x86_64 configuration or make 
machinery.

Because it may provide a useful example of how someone might optimize a build 
should they have a similar need in the future.

Because the low power Opteron, the Athalon-FX/2, Atom64, Core2/duo, and 5th gen 
Xeon processors have significant differences in pipeline depth and how many 
cycles it takes the ALU to settle after an overlapped operation, which has 
strong implications to how the code generator, optimizer, and peep-hole 
post-optimizer (in an optimizing loader) would emit code.

Lastly, because we’re not limited to committing this directly into the main 
tree… they could also go into “targets” feed.



> 
>> We’ve come a long way since the Athalon-64 (k8) in 2004.
> 
> The situation on amd64/ x86_64 is quite a bit better than on i[3456]86,
> probably very little actually makes a difference for routing tasks
> (this could be different if LEDE would be a common basis for image
> or video transcoding, but I seriously doubt that optimizing for core2
> would actually make a significant difference on a router, especially
> considering that pretty much any amd64/ x86_64 CPU[1] is way more 
> powerful than any of the more prevalent routing architectures). I think 
> it would be useful to actually show the difference your change makes on 
> modern CPUs, before proactively introducing new subtargets for cosmetic 
> reasons.


Well, I’d be happy to try that, but first need to validate the build machinery… 
since we’ve only ever had one x86_64 target, it hasn’t been validated…  since 
it hasn’t been validated, that’s probably discouraged anyone from testing (and 
adding) any useful additional targets… so we have a circular dependency.

If you’re using a single server with several 802.11ac cards in it and 
point-to-point connections, you can easily get into several gigabits/sec worth 
of traffic.  Further, if you have multi-tenancy and per-customer SLA’s, you can 
get into some sophisticated shaping/policing scenarios, and it might be the 
case that an x86, while “way more powerful than any of the more prevalent 
routing architectures”, is still going to be taxed as a software only solution 
(versus say a MIPS 7K with ASICs).



> 
> Regards
>   Stefan Lippers-Hollmann
> 
> [1]   I'm quite convinced that even a 2003 vintage AMD64 Opteron from
>   the first generation sledgehammer design wouldn't find its 
>   limitations on the CPU side (unless you go beyond 1 GBit/s), but
>   rather on the bus connection of your ethernet cards (old PCI 
>   won't saturate a 1 GBit/s link).


And that’s the scenario I’m looking at: multiple connections each potentially 
significantly more than a gigabit per-second.

-Philip


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

Re: [LEDE-DEV] Adding new targets/subtargets

[Felix Fietkau]

On 2017-01-03 00:41, Philip Prindeville wrote:
> And I’d like to do that.
> 
> (a) we’d need to decide what benchmarks are meaningful… are the openssl 
> encryption benchmarks sufficient?
I think it's a good start. However, please make sure you have the same
encryption acceleration drivers enabled in both builds, so you're not
comparing apples to oranges. I've verified that the drivers don't depend
on selecting a specific CPU type, so they should work in generic kernel
images.

> (b) but even before that, it’s not clear that the CPU_TYPE target makefile 
> machinery has ever worked correctly… so we’d need to remedy that.
You can set CFLAGS directly for testing if you want to.

- Felix

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Philip Prindeville]

> On Jan 2, 2017, at 3:06 PM, Felix Fietkau  wrote:
> 
> On 2017-01-02 19:36, Philip Prindeville wrote:
>> Right, this is why I’m trying to create a new target (or subtarget)
>> called “xeon” which is optimized for Xeon targets and leverages the
>> on-chip crypto-accelerators.
>> 
>> We’ve come a long way since the Athalon-64 (k8) in 2004.
> I think it should be easily possible to enable the crypto accelerator
> support by default, it probably gets enabled only on CPUs that actually
> support it.
> 
> If you still want to add a subtarget to use different CFLAGS, you need
> to prove (with hard numbers) that it has a meaningful impact and is more
> than just a potentially pointless micro-optimization.
> 
> - Felix


And I’d like to do that.

(a) we’d need to decide what benchmarks are meaningful… are the openssl 
encryption benchmarks sufficient?

(b) but even before that, it’s not clear that the CPU_TYPE target makefile 
machinery has ever worked correctly… so we’d need to remedy that.

-Philip


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

[LEDE-DEV] [PATCH] musl: update musl to 1.1.16 and switch to download from git

[Christian Lamparter via Lede-dev]

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 ---
This patch updates musl to 1.1.16 [0] and removes all the
backported patches. This is a major release and tagged as such.
For more information visit musl-libc.org or read the WHATSNEW.

Furthermore, this patch also changes musl to download directly
from git. This makes it easier to update musl in the future.
This has also an effect on the cached copy of musl in the dl/
directory, from now on, it's a tar.xz.

[0] 


Signed-off-by: Christian Lamparter 
---
No idea, if you want to fudge that in for the upcoming release or
not. A few 4.9 ABI changes could break a few things... This can
be a problem for some packages in the feeds or architectures.
---
 toolchain/musl/Config.version  |   2 +-
 toolchain/musl/common.mk   |   8 +-
 ...ime-day-month-names-not-to-vary-by-locale.patch |  41 ---
 ...regression-in-tcsetattr-on-all-mips-archs.patch |  67 
 ...d-pwrite-syscall-calling-convention-on-sh.patch |  71 
 ...ttyname-refers-to-the-same-file-as-the-fd.patch |  49 ---
 .../025-fix-ffsync-by-changing-it-to-osync.patch   |  25 --
 ...-alt-form-octal-zero-flag-and-field-width.patch |  31 --
 ...-ifru_data-and-ifcu_buf-types-in-net-if.h.patch |  35 --
 .../030-fix-if_indextoname-error-case.patch|  36 --
 ...and-wcsftime_l-prototypes-to-wchar-header.patch |  38 --
 ...fined-behavior-in-sched.h-cpu_set_t-usage.patch |  43 ---
 ...getservby_r-result-pointer-value-on-error.patch |  41 ---
 .../036-fix-strftime-y-for-negative-tm_year.patch  |  23 --
 ...hecks-in-regexec-buffer-size-computations.patch |  72 
 ...with-haystack-strings-longer-than-int_max.patch | 189 --
 ...float-printf-needed-precision-computation.patch |  35 --
 ...ows-and-uncaught-eoverflow-in-printf-core.patch | 390 -
 .../patches/048-math-fix-pow-signed-shift-ub.patch |  38 --
 .../049-fix-clock_nanosleep-error-case.patch   |  30 --
 .../musl/patches/050-add-pthread_setname_np.patch  |  58 ---
 ...at-formatting-of-some-exact-halfway-cases.patch |  30 --
 ...pt_long_only-misinterpreting-as-an-option.patch |  24 --
 ...gratuitous-undefined-behavior-in-strptime.patch |  33 --
 ...-strtof-rounding-with-many-trailing-zeros.patch |  36 --
 ...optimization-in-non-nearest-rounding-mode.patch |  38 --
 ...teger-overflow-of-tm_year-in-__secs_to_tm.patch |  39 ---
 ...-internal-buffer-state-and-error-handling.patch |  36 --
 ...gression-on-archs-with-variable-page-size.patch |  32 --
 ...t-attribute-to-some-function-declarations.patch | 197 ---
 .../musl/patches/400-fix_quoted_timezone.patch |  11 -
 31 files changed, 6 insertions(+), 1792 deletions(-)
 delete mode 100644 
toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
 delete mode 100644 
toolchain/musl/patches/010-fix-regression-in-tcsetattr-on-all-mips-archs.patch
 delete mode 100644 
toolchain/musl/patches/015-fix-pread-pwrite-syscall-calling-convention-on-sh.patch
 delete mode 100644 
toolchain/musl/patches/020-verify-that-ttyname-refers-to-the-same-file-as-the-fd.patch
 delete mode 100644 
toolchain/musl/patches/025-fix-ffsync-by-changing-it-to-osync.patch
 delete mode 100644 
toolchain/musl/patches/028-fix-printf-regression-with-alt-form-octal-zero-flag-and-field-width.patch
 delete mode 100644 
toolchain/musl/patches/029-fix-ifru_data-and-ifcu_buf-types-in-net-if.h.patch
 delete mode 100644 
toolchain/musl/patches/030-fix-if_indextoname-error-case.patch
 delete mode 100644 
toolchain/musl/patches/031-add-missing-unlocked-and-wcsftime_l-prototypes-to-wchar-header.patch
 delete mode 100644 
toolchain/musl/patches/033-fix-undefined-behavior-in-sched.h-cpu_set_t-usage.patch
 delete mode 100644 
toolchain/musl/patches/035-fix-getservby_r-result-pointer-value-on-error.patch
 delete mode 100644 
toolchain/musl/patches/036-fix-strftime-y-for-negative-tm_year.patch
 delete mode 100644 
toolchain/musl/patches/037-fix-missing-integer-overflow-checks-in-regexec-buffer-size-computations.patch
 delete mode 100644 
toolchain/musl/patches/038-fix-regexec-with-haystack-strings-longer-than-int_max.patch
 delete mode 100644 
toolchain/musl/patches/039-fix-integer-overflow-in-float-printf-needed-precision-computation.patch
 delete mode 100644 
toolchain/musl/patches/040-fix-integer-overflows-and-uncaught-eoverflow-in-printf-core.patch
 delete mode 100644 
toolchain/musl/patches/048-math-fix-pow-signed-shift-ub.patch
 delete mode 100644 
toolchain/musl/patches/049-fix-clock_nanosleep-error-case.patch
 delete mode 100644 toolchain/musl/patches/050-add-pthread_setname_np.patch
 delete mode 100644 

Re: [LEDE-DEV] Adding new targets/subtargets

[Alberto Bursi]

On 01/02/2017 07:36 PM, Philip Prindeville wrote:
>
>
> Right, this is why I’m trying to create a new target (or subtarget) called 
> “xeon” which is optimized for Xeon targets and leverages the on-chip 
> crypto-accelerators.
>
> We’ve come a long way since the Athalon-64 (k8) in 2004.
>
> -Philip
>

Wait a sec, what you mean exactly for "on chip crypto accelerators"?
If you mean AES-NI there was already a discussion about that in the 
mailing list, see here 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003545.html

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Stefan Lippers-Hollmann]

Hi

On 2017-01-02, Philip Prindeville wrote:
> > On Jan 2, 2017, at 10:01 AM, Jo-Philipp Wich  wrote:
> > 
> > Hi,
> >   
> >> The x86/64/config-default is missing the following switches:
> >> 
> >> CONFIG_MCORE2=y  
[...]
> Right, this is why I’m trying to create a new target (or subtarget) called 
> “xeon” which is optimized for Xeon targets and leverages the on-chip 
> crypto-accelerators.

This is just an optimization, but not actually needed to get the
firmware running on your target CPU. While it may, or may not, provide
measurable speedups, none of the large(r) binary distros consider this
to be a necessary optimization, so why do you think it's necessary to
provide just this tiny micro-optimization as a dedicated subtarget with
all the overhead this entails - rather than just using as a local 
configuration for your own builds?

> We’ve come a long way since the Athalon-64 (k8) in 2004.

The situation on amd64/ x86_64 is quite a bit better than on i[3456]86,
probably very little actually makes a difference for routing tasks
(this could be different if LEDE would be a common basis for image
or video transcoding, but I seriously doubt that optimizing for core2
would actually make a significant difference on a router, especially
considering that pretty much any amd64/ x86_64 CPU[1] is way more 
powerful than any of the more prevalent routing architectures). I think 
it would be useful to actually show the difference your change makes on 
modern CPUs, before proactively introducing new subtargets for cosmetic 
reasons.

Regards
Stefan Lippers-Hollmann

[1] I'm quite convinced that even a 2003 vintage AMD64 Opteron from
the first generation sledgehammer design wouldn't find its 
limitations on the CPU side (unless you go beyond 1 GBit/s), but
rather on the bus connection of your ethernet cards (old PCI 
won't saturate a 1 GBit/s link).


pgpYYJ3vuiMmP.pgp
Description: Digitale Signatur von OpenPGP
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] dhcpv6-pd subnet allocation?

[Dave Taht]

1) In a topology like this:

ISP
 |
routerA
 |
routerB
 |
routerC

what options now exist in lede for getting an ipv6 subnet to routerC
from routerA after being provided by the ISP? (the basic PD allocation
from ISP to A seems to work)

Can routerB get one from routerA, then C from B?

dhcp-pd?
hncpd?
shcncpd?
wget?

2) I'd like to be able to toss a dhcp address allocation into its own
routing table
(having some trouble with default routes) - according to this

https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/036212.html

option ipv4table 16

is the way? (cause ip route show table 16 shows nothing)

config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'
option defaultroute '0'
option ipv4table 16





-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Philip Prindeville]

> On Jan 2, 2017, at 10:08 AM, Jo-Philipp Wich  wrote:
> 
>> Why not instead just add a profile attribute like:
>> 
>> BUILDBOT_BUILD_ME:=no
> 
> Because we want to have complete coverage. Experience has shown that
> untested subtargets quickly become stale and broken.
> 
> ~ Jo


Then we need more buildbot resources, not fewer targets…

-Philip


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

Re: [LEDE-DEV] Release Planning - Current Status?

[Jo-Philipp Wich]

Hi Rich,

there hasn't been much progress on the planning since I didn't follow
any mails for the last week or so :)

I plan to factor in the various suggestions into the roadmap I initially
posted and put the result into the wiki tomorrow.

The idea is to have a definitive timeline until Friday so we can start
branching and preparing builds.

I'm not totally sure whether we want to have a distinct RC phase (as in
tagging RCs). The pre-release branch build artifacts can serve the same
purpose and are reasonably stable - there should be no incompatible
kmods every 24h in contrast to master builds as the kernel config will
likely remain the same unless we really need to fix something there.

~ Jo

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Jo-Philipp Wich]

Hi,

> If this is going to be the road we travel down (I'm bikeshedding here)
> wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?

it wouldn't as buildbot activity is distributed randomly and the master
currently lacks suitable scheduling logic to implement such behavior.

Besides that, we're incrementally building anyway already means we'd not
save any resources doing that while adding a huge amount of complexity
to the build scheduling logic.

> We have more then a few full on targets that for the most part are
> much less popular then say ar71xx.

~ Jo

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

Re: [LEDE-DEV] Adding new targets/subtargets

[Jo-Philipp Wich]

Hi,

> Pruning useful subtargets to solve a buildbot resource shortage seems
> like taking a sledgehammer to kill a fly.

Saving resources was only one of the considerations to cut back the
amount of sub targets.

The introduction of per-device/per-profile rootfs support in LEDE
allowed us to build images with a different package selection per device
so sub targets that merely selected different kmods become completely
needless.

> Why not instead just add a profile attribute like:
> 
> BUILDBOT_BUILD_ME:=no

Because we want to have complete coverage. Experience has shown that
untested subtargets quickly become stale and broken.

~ Jo


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

Re: [LEDE-DEV] Adding new targets/subtargets

[Jo-Philipp Wich]

Hi,

> The x86/64/config-default is missing the following switches:
> 
> CONFIG_MCORE2=y

That would break support for older x86_64 iirc.

> CONFIG_MDIO=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y

Those can probably go into x86/64 directly, at least I see no reason why
not.

> [...]
> ARCH_SUFFIX is taken from CONFIG_CPU_TYPE, but in my setup that value seems 
> to have been set to “ “ which I can’t say I understand. 

This setting is usually used to denote specific distinct, incompatible
CPU types which belong to the same "arch" e.g. CPU_TYPE:=arm1136j-s vs.
CPU_TYPE:=cortex-a15 which are both ARCH:=arm .


~ Jo

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

Re: [LEDE-DEV] Image Wizard for LEDE?

[Ufo]

for "Freifunk Leipzig" we are using Meshkit since years.  yes, its done 
via a VM. We are forced to compile the whole LEDE (or openwrt) by 
ourself every month in order to have ALL packages properly. (f.i. to use 
"luci2" or "rpcd-mod-alfred" or sound-drivers..)


i can recommend using our leipzig one, its almost up-to-date and with LEDE:

http://gadow.freifunk.net:8086/meshkit/

for ar71xx please use target: ar71xx-lede-20161220
for x86/virt testing: x86-lede-20161121
-community: Freifunk-Leipzig (still in usage and tested), best with 
"expert mode"


for package selection the meshkit is very, very nice. you can add 
package-names (f.i. tcpdump-mini) to package-list in expert mode to have 
that package inside the new kompilieded image. so there is no need to 
post-install packages, and the device is pre-configured when flashing 
(or resetting!) a device :-)


video tutorial howto use meshkit (in 60 seconds) 
https://www.youtube.com/watch?v=EnkmHkFE_YQ
video example (with Nanostation M5): 
https://www.youtube.com/watch?v=2tdJcV0NkAw


please test it with devices with  more than 4 MB flash to have complete 
webinterface!
otherwise there is a need for changing package list manually (the image 
would be too big) ..  (delete all lua + "luci-". stuff, and add "luci2")


some limitations:
* its mostly used for mesh-devices with OLSR, batman-adv was added 
months ago but you can also try it without mesh-routing (please change 
files in /etc/config afterwards). but there are not presets for that

* the (auto-) update functions of meshkit are not programmed to the end yet
* other freifunk-towns forked this to make package-presets possible. but 
its not gitted upstream yet. (weimarnetz, freifunk berlin, freifunk halle)


some issues:
* "opkg package repository directory management" seems to be changes 
every month with LEDE :-( so you may change it manually when 
post-installation of packages is needed.
* (adv.) LAN-Settings in meshkit are not set for x86-devices, its still 
192.168.1.1 with dhcp by default
* normal lede problem: horst doesnt compile anymore since some weeks: 
https://github.com/br101/horst/issues/64
* problems with newer OLSR jsonplugin: 
https://github.com/openwrt/luci/pull/907 (please help me)
* luci-mod-freifunk: hostname missing: 
https://github.com/openwrt/luci/issues/571
* LEDE new wifi named: "default_radio0 / LEDE" 
https://plan.leipzig.freifunk.net/issues/360
* multicast ping6 doesnt work outgoing anymore (security feature?) 
https://plan.leipzig.freifunk.net/issues/273
* maybe a "normal" problem: channel 1 has less wifi-power than channel 2 
(at least with tplink)


cheers, ufo


p.s.
there are several meshkit instances online, please see official sources 
(instead of forks) here

* https://github.com/freifunk/meshkit
beware, the official freifunk meshkit is outdated! (at least the 
target/kompilats)

* http://meshkit.freifunk.net and http://testing.meshkit.freifunk.net





On 02.01.2017 13:51, Alberto Bursi wrote:


On 01/02/2017 11:23 AM, Jo-Philipp Wich wrote:

Hi,


Freifunk (or another german site about wifi) also has a webinterface for
the Image Builder. I would really like to have that too.

Count me in, I also support this idea. I can lend a hand with
implementing stuff.

~ Jo


Nice, thanks for the offer. I was planning to try setting it up in a VM
locally after I finished the automated package list indexing script for
the wiki (within a month or so).
I had a look at the docs and it should only need some configuration to
work for LEDE/OWRT, but since I have yet to try it I don't know if there
are limitations or issues yet.

If you want to have a look...

This is the site:
http://imagebuilder.augsburg.freifunk.net/

Source and installation docs are here:
https://github.com/weimarnetz/meshkit



-Alberto

___
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

[LEDE-DEV] Release Planning - Current Status?

[Rich Brown]

If I remember correctly, there was a window for submitting updates for the 
initial Release Candidate. Where does that process stand?


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

[LEDE-DEV] brcm47xx legacy image building issues

[Eric Masson]

Hello,

I get the following error while trying to generate an image for a WGT634U :
emss@vmwdebems:~/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64$ make 
image PACKAGES="aiccu fwknopd luci luci-app-firewall luci-app-fwknopd 
luci-app-sqm luci-proto-ipv6 luci-proto-ppp tcpdump -dnsmasq 
iputils-traceroute6 kmod-nf-nathelper-extra"


...
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies 
for luci:
 *  uhttpd *uhttpd-mod-ubus *   luci-mod-admin-full * 
firewall *  libuci *
 * satisfy_dependencies_for: Cannot satisfy the following dependencies 
for luci-app-sqm:

 *  libuci-lua *rpcd *  libubus-lua *
 * satisfy_dependencies_for: Cannot satisfy the following dependencies 
for base-files:
 *  netifd *ubusd * ubus *  libjson-script * 
ubox *  libubox *   libubus *   jsonfilter *usign * 
ubox *

 * opkg_install_cmd: Cannot install package firewall.
 * opkg_install_cmd: Cannot install package mtd.
 * opkg_install_cmd: Cannot install package netifd.
 * opkg_install_cmd: Cannot install package odhcp6c.
 * opkg_install_cmd: Cannot install package odhcpd.
 * satisfy_dependencies_for: Cannot satisfy the following dependencies 
for opkg:

 *  uclient-fetch *
 * opkg_install_cmd: Cannot install package swconfig.
 * opkg_install_cmd: Cannot install package uci.
 * opkg_install_cmd: Cannot install package uclient-fetch.
 * opkg_install_cmd: Cannot install package wpad-mini.
Makefile:140: recipe for target 'package_install' failed
make[2]: *** [package_install] Error 255
make[2]: Leaving directory 
'/home/emss/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64'

Makefile:110: recipe for target '_call_image' failed
make[1]: *** [_call_image] Error 2
make[1]: Leaving directory 
'/home/emss/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64'

Makefile:196: recipe for target 'image' failed
make: *** [image] Error 2
emss@vmwdebems:~/lede-imagebuilder-brcm47xx-legacy.Linux-x86_64$

lede-imagebuilder-brcm47xx-legacy.Linux-x86_64.tar.xz is Mon Jan 2 
16:40:22 2017 version.


This used to work, any idea, please ?

Regards

Éric Masson


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

Re: [LEDE-DEV] Image Wizard for LEDE?

[Alberto Bursi]

On 01/02/2017 11:23 AM, Jo-Philipp Wich wrote:
> Hi,
>
>> Freifunk (or another german site about wifi) also has a webinterface for
>> the Image Builder. I would really like to have that too.
>
> Count me in, I also support this idea. I can lend a hand with
> implementing stuff.
>
> ~ Jo
>

Nice, thanks for the offer. I was planning to try setting it up in a VM 
locally after I finished the automated package list indexing script for 
the wiki (within a month or so).
I had a look at the docs and it should only need some configuration to 
work for LEDE/OWRT, but since I have yet to try it I don't know if there 
are limitations or issues yet.

If you want to have a look...

This is the site:
http://imagebuilder.augsburg.freifunk.net/

Source and installation docs are here:
https://github.com/weimarnetz/meshkit



-Alberto

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

Re: [LEDE-DEV] Image Wizard for LEDE?

[Jo-Philipp Wich]

Hi,

> Freifunk (or another german site about wifi) also has a webinterface for 
> the Image Builder. I would really like to have that too.

Count me in, I also support this idea. I can lend a hand with
implementing stuff.

~ Jo

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

Re: [LEDE-DEV] [PATCH v2] package-ipkg: Do not fail build without base-files

[Jo-Philipp Wich]

Hi Florian,

ACK from me on this one. I think it makes sense.

~ Jo

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

Re: [LEDE-DEV] LEDE Fails to build

[Mauro M.]

Magnus,


Thank you.

I found that libustream-mbedtls is forced to enabled in the new releases 
and this conflicts with libustream-polarssl that I had already enabled 
in my router's configuration.


I disabled libustream-polarssl (libustream-mbedtls cannot be disabled) 
and now the code builds. Perhaps the project might want to look at 
checking dependencies and conflicts in the .config file.


Looking further into the matter I found that now I have the following in 
my configuration.


 -*- libmbedtls 
Embedded SSL (library)
 -*- libopenssl... Open source 
SSL toolkit (libraries)  --->
 -*- libpolarssl... 
Embedded SSL (library)


I wonder why they are all forced (I cannot disable any of them) and if I 
need all of them at all.


Best regards,

Mauro


On 01/01/17 17:23, Magnus Kroken wrote:

Hi Mauro

On 01.01.2017 16.10, Mauro M. wrote:

Collected errors:
 * check_data_file_clashes: Package libustream-polarssl wants to install
file
/net2/router/lede/trunk-ipvs/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/lib/libustream-ssl.so 



But that file is already provided by package  * libustream-mbedtls
 * opkg_install_cmd: Cannot install package libustream-polarssl.


Try updating all LEDE code as well as all enabled package feeds, and 
updating your configuration (backup, then make defconfig). This is 
probably caused by LEDE and feeds moving to mbed TLS 2.x as default 
TLS library.


If it still fails, run make menuconfig and find out which package 
selects libustream-polarssl. Grepping my tree, cshark (in 
feeds/packages) is the only package that depends on 
libustream-polarssl at this point.


Regards
/Magnus



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

[LEDE-DEV] Bug#842710: [gcc-6] Fails to compile OpenWrt/LEDE prereq-build

[Charlemagne Lasse]

Package: gcc-6
Version: 6.2.0-10
Severity: serious
X-Debbugs-CC: lede-dev@lists.infradead.org

There is a regression after gcc-6 6.2.0-6. I get following output when
trying to compile LEDE/OpenWrt "Please install a static zlib"

This is wrong

$ ls -ltr /usr/lib/x86_64-linux-gnu/libz.a
-rw-r--r-- 1 root root 149834 Nov 27  2014 /usr/lib/x86_64-linux-gnu/libz.a

Following can be found in their include/prereq-build.mk

ifeq ($(HOST_OS),Linux)
  zlib_link_flags := -Wl,-Bstatic -lz -Wl,-Bdynamic
else
  zlib_link_flags := -lz
endif

$(eval $(call TestHostCommand,zlib, \
Please install a static zlib. (Missing libz.a or zlib.h), \
echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0; }' | \
gcc -include zlib.h -x c -o $(TMP_DIR)/a.out - $(zlib_link_flags)))

Testing it with gcc-6 6.2.0-6 works:

$ echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0;
}' | gcc -include zlib.h -x c -o a.out - -Wl,-Bstatic -lz
-Wl,-Bdynamic
$ echo $?
0

with gcc-6 6.2.0-10 fails:

$ echo 'int main(int argc, char **argv) { gzdopen(0, "rb"); return 0;
}' | gcc -include zlib.h -x c -o a.out - -Wl,-Bstatic -lz
-Wl,-Bdynamic
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libz.a(gzlib.o):
relocation R_X86_64_32S against `.rodata' can not be used when making
a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
$ echo $?
1

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

Re: [LEDE-DEV] [OpenWrt-Devel] Adding host Java support to the buildbots

[Ralph Sennhauser]

On Fri, 30 Dec 2016 06:52:32 -0800
Dana Myers  wrote:

> On 12/29/2016 11:50 PM, Ralph Sennhauser wrote:
> > Hi Dana
> >
> > On Thu, 29 Dec 2016 12:30:37 -0800
> > Dana Myers  wrote:
> >  
> >> In reference to https://github.com/openwrt/packages/pull/3686
> >>
> >> We've added OpenWRT support for:
> >>
> >> * JamVM 2.0: Java JVM
> >> * GNU Classpath 2.0: Java class library  
> > There is no classpath 2.0  
> 
> Right you are - serves me right for spewing version numbers off the
> top of my head from something I initially did two years :-) It's
> classpath 0.99
> >  
> >> * RXTX Java serial communications library
> >>
> >> However, the build bots won't build these packages yet because
> >> a host Java compiler is required. To build these packages, I
> >> install:  
> > The main reason to use jamvm with gnu classpath is you can
> > bootstrap it without a jdk, right? If you already require a host
> > jdk why not go for jamvm with the openjdk classpath to get full
> > java support?  
> 
> I don't understand the question about bootstrapping and host vs
> target JDK. Host JDK is used specifically for javac to compile Java
> to bytecodes; target has no dependency on JDK otherwise.

Well, if you require openjdk-7-jdk on the build host you sidestep
bootstrapping java all together (c compiler & source code -> build) in
which case jamvm with openjdk classpath is as easy to get as with gnu
classpath but the latter only supports part of 1.5 & 1.6.

The question boils down to why you settle for something inferior when
you can have something much better.

> 
> Classpath was, for many years, the only library supported by JamVM,
> is much smaller than OpenJDK (valuable on resource-constrained
> systems) and remains the default library supported by JamVM. For the
> purposes of my project from which I contributed, Classpath is
> adequate and appears to avoid concerns about encumbrance of the
> target builds/devices with OpenJDK. Most specifically, however, was
> the apparent lack of support for MIPS32 which is a show-stopper for
> the AR71xx architecture I'm using.

Another alternative to hotspot on mips would be cacao, again with
openjdk classpath. Though jamvm certainly is a vaild pick.

What encumbrance concerns do you have in mind? Debian also ships the
binaries as in openjdk-7-jdk.

I don't object to jamvm with gnu classpath, just that I was wondering
why you'd pick it over the alternatives. Basically it's adding java
support that is hardly usable this days apart of a few specialized
cases.

Cheers
Ralph

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