Re: [LEDE-DEV] Severe dnsmasq vulnerabilities affecting LEDE
In addition to Jo-Philipp Wich's announcement the buildbots in LEDE's infrastructure are backlogged meaning that the following targets (including notable mentions) does not have an updated package for dnsmasq as time of writing: arc_arc700 arm_arm926ej-s arm_cortex-a5 arm_cortex-a53_neon-vfpv4 arm_cortex-a8_vfpv3 arm_cortex-a9 arm_cortex-a9_neon - QCA ARM 11ac capable devices arm_cortex-a9_vfpv3 - Marvell ARM 11ac capable devices arm_fa526 arm_mpcore i386_geode - PC Engines ALIX devices i386_i486 mips_24kc - Includes the majority of supported MIPS devices mips64_octeon - EdgeRouter Lite (not X) powerpc_464fp ETA for the following platforms is 12h. To verify that a new version of dnsmasq is available on your platform run "opkg update; opkg list dnsmasq" which will show version 2.78-1 once the package has been updated. Best regards, Daniel Engberg ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Updating Perl to 5.26.1
Hi, Sorry for for not including the history (not subscribed). Perhaps taking a peek at https://github.com/buildroot/buildroot/tree/master/package/perl might help as they seem to have it working? Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] update triggerhappy package to version 0.5.0
Hi Stefan, Thanks for submitting a patch, I think however the preferred way is to use GitHub (PR) as that's the main repo and it's still under the OpenWrt project. However, triggerhappy needs a bit more love than just adjusting what version to pull. PKG_SOURCE should be changed to xz instead of gz, you can also remove the line completely if I'm not mistaken. PKG_SOURCE_URL should use https instead of git because it "plays" better with firewalls and is the preferred protocol when pulling sources from git repos. PKG_MIRROR_HASH needs to be added, which contains a SHA256 HASH of the packaged downloaded source code. PKG_LICENSE should be GPL-3.0 not GPL-3.0+? Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] mbedtls: update to 2.5.1
Hi, This is exactly why I want to add https://github.com/lede-project/source/pull/1133 so we don't need to chase around for odd mirrors. :-) Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Fixing ath10k (5Ghz) on TP-Link C58, C59, C60
Hi, I've been trying to fix ath10k (5Ghz) on my C59 (all in the same series seems to share the same issue) but I'm struggling as I can't find any documentation on how to debug. dmesg (trunk), using stock non -CT firmware yields pretty much the same. http://paste.ubuntu.com/24892442/ Looking at ipq8 it seems that caldata hotplug.d-script is writing different files/data? https://github.com/lede-project/source/blob/master/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata Any help or pointers would be helpful gettting it to work. Thanks in advance! Please CC me as I'm not subscribed to the list. Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Toolchain/Buildroot requirements, testing and common lowest denominator?
Long story short: * Updated tools/sparse * Compiles fine on my side (Debian 8) * Blows up on buildbot (slave-lede-local) because it runs GCC 4.7 (lacks bswap, 4.8+ works according to https://sourceware.org/bugzilla/show_bug.cgi?id=20530) Having a look at the buildbots, it shows that tictex-02 uses GCC 4.9 (probably Debian 8) while slave-lede-local runs Debian 7 (LTS). I have on idea what the phase2 buildbots uses however as the web interface doesn't say. However this bring my question about what we are targeting and what's the view on supported versions and common lowest denominator? Version of base GCC on common distros, haven't looked at external packages: Debian 7 (LTS): 4.7 Debian 8: 4.9 RHEL/CentOS 7.3: 4.8 Ubuntu 16.04.2 (LTS): 5.3.0 Ubuntu 17.04: 6.3.0 Arch Linux: 6.3.1 Linux Mint 17.3: 4.8.4 FreeBSD 10.3/11.0: 5.4.0 (default via ports) We already have requirements for a few utils and libs so I don't think it's a huge deal in the end. https://github.com/lede-project/source/blob/master/include/prereq-build.mk#L17 This should probably be adjusted as it tests for really old versions of GCC etc. While hacking in bswap in this case isn't an issue it however raises the question of what we want to support and for how long. Also, do we want unified buildbots? It's been mentioned on Github that some build bots doesn't support all download protocols or at least have issues with a few such as svn, I don't if that's the case anymore but do we have any guidelines for such setups? Bots also have different software installed meaning that some packages fails depending on bot, however I'm not sure if that applies to any of the current packages but it occurred in the past. Jo-Philipp Wich also pointed out on irc that using different versions also irons out bugs, while this is true it also adds a lot more of complexity to debugging. Perhaps we should try to have a unified setup first and have "experimental" bots later on if there's capacity? Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] kernel: update kernel 4.9 to 4.9.28
On 2017-05-16 11:06, Koen Vandeputte wrote: On 2017-05-16 10:06, Daniel Engberg wrote: Hi, Thanks for providing a patch, however it fails when applied to master (83e4ed3497d40dc7da9d2d2c2febbf6272815c51) or maybe I'm doing something wrong (tm). :-/ . Applying /home/diizzy/testme/source/target/linux/generic/patches-4.9/060-0004-mtd-bcm47xxpart-move-TRX-parsing-code-to-separated-f.patch using plaintext: patching file drivers/mtd/bcm47xxpart.c Hunk #3 FAILED at 241. Hunk #4 succeeded at 368 (offset 2 lines). 1 out of 4 hunks FAILED -- saving rejects to file drivers/mtd/bcm47xxpart.c.rej Patch failed! Please fix /home/diizzy/testme/source/target/linux/generic/patches-4.9/060-0004-mtd-bcm47xxpart-move-TRX-parsing-code-to-separated-f.patch! Makefile:101: recipe for target '/home/diizzy/testme/source/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/linux-4.9.20/.prepared' failed make[3]: *** [/home/diizzy/testme/source/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/linux-4.9.20/.prepared] Error 1 make[3]: Leaving directory '/home/diizzy/testme/source/toolchain/kernel-headers' . Marvell Armada (WRT3200ACM) Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev Hi Daniel, Everything seems fine here. I tried to recreate your steps: - Download master - Checkout that specific commit - Apply kernel update patch - Select target using make menuconfig --> Target System: Marvel Armada 37x/38x/XP --> Target Profile: Linksys WRT3200ACM - Make See this: https://pastebin.com/raw/LditxBLp Also applied patches separately: https://pastebin.com/raw/GnyrRh8M in short: Applying /mnt/ramdisk/test/firmware/builds/source/target/linux/generic/patches-4.9/060-0003-mtd-bcm47xxsflash-support-reading-flash-out-of-mappi.patch using plaintext: patching file drivers/mtd/devices/bcm47xxsflash.c patching file drivers/mtd/devices/bcm47xxsflash.h Applying /mnt/ramdisk/test/firmware/builds/source/target/linux/generic/patches-4.9/060-0004-mtd-bcm47xxpart-move-TRX-parsing-code-to-separated-f.patch using plaintext: patching file drivers/mtd/bcm47xxpart.c Applying /mnt/ramdisk/test/firmware/builds/source/target/linux/generic/patches-4.9/060-0005-mtd-bcm47xxpart-support-layouts-with-multiple-TRX-pa.patch using plaintext: patching file drivers/mtd/bcm47xxpart.c Please let me know if I missed something above in simulating it. Kind Regards, Koen Hi, using the correct email helps... ;-) Using that checkout works, also... it might have been caused by using patch instead of git. Anyhow, thanks! Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] kernel: update kernel 4.9 to 4.9.28
Hi, Thanks for providing a patch, however it fails when applied to master (83e4ed3497d40dc7da9d2d2c2febbf6272815c51) or maybe I'm doing something wrong (tm). :-/ . Applying /home/diizzy/testme/source/target/linux/generic/patches-4.9/060-0004-mtd-bcm47xxpart-move-TRX-parsing-code-to-separated-f.patch using plaintext: patching file drivers/mtd/bcm47xxpart.c Hunk #3 FAILED at 241. Hunk #4 succeeded at 368 (offset 2 lines). 1 out of 4 hunks FAILED -- saving rejects to file drivers/mtd/bcm47xxpart.c.rej Patch failed! Please fix /home/diizzy/testme/source/target/linux/generic/patches-4.9/060-0004-mtd-bcm47xxpart-move-TRX-parsing-code-to-separated-f.patch! Makefile:101: recipe for target '/home/diizzy/testme/source/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/linux-4.9.20/.prepared' failed make[3]: *** [/home/diizzy/testme/source/build_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.4.0_musl_eabi/linux-4.9.20/.prepared] Error 1 make[3]: Leaving directory '/home/diizzy/testme/source/toolchain/kernel-headers' . Marvell Armada (WRT3200ACM) Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Kodi
On 03/15/2017 11:57 AM, Daniel Engberg wrote: > Hi, Huhu, > > While I applaud your achievement I'd don't see such projects viable in > terms of maintainability and longevity. Applauds from me as well! I started doing so with XBMC a couple of years ago and eventually gave up.. > > Pulling in Kodi will result in lots of external packages and > dependencies to make it usable in a reasonable way. Sorry, but I totally disagree. I always saw (and still see) OpenWrt/LEDE as a toolchain and Linux embedded distribution - *not* just for routers. Me and few others already started very early to get it running on rather unusual devices (landline phones, mobile phones, digital picture frames, even (mini) notebooks (OLPC, Qi NanoNote, etc.)). Sure, you can do "novelty" stuff but unless there's a commitment by several people you'll end up with a rather hackish (in most cases) approach and code rot in the end due to lack of interest of original committer(s). Not to forget someone(tm) needs (I guess you could call it good practice) to take care about the code because it's in the tree even if current devs doesn't have the hardware and/or interest. As far as I can tell nothing of what you mentioned is in the main repo and for the very reasons above most likely or other developers plainly refused to include it in the tree from the beginning. I'm not saying it should never expand, however going into a very niche "market" where you already have very good alternatives and code infrastructure isn't something you want to do with 1 or 2 devs even full time. I do consider LibreELEC very competent at what it does and regarding my concern feel free to have a look at the package repo and compare it to what we have currently. Of course, not every package is needed but I hope you get my point. https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages Almost a decade ago by now we ported Xorg and all it's dependencies to OpenWrt/LEDE. Later on GTK, enlightenment and its EFL stack, Qt and what else. Although the xorg-feed is not in a good shape anymore (and I rather discourage anybody from using Xorg if there's no real need for a windowing system), lot's of stuff remained, is still maintained and used. The new video feed is supposed to be kind of a reincarnation of the outdated xorg feed. This is pretty much my point, it never got much interest because lack of users (possibly several reason for it etc) and the ball stopped rolling. I highly encourage approaches like those and don't see any need for forcing OpenWrt/LEDE being only a router distribution. This only counts of course, if one approach doesn't interfere with the other. So let's come to your concrete issues: > > There are several issues with this: > > * In general binary size > performance and/or functionality pretty much > always takes priority, this is a major issue when it comes to multimedia > (ffmpeg and friends comes mind). I fail to see in which way additional packages - in this case: dependencies for Kodi - do add size/performance issues the existing device configurations. While we still lack a great deal of packages for Kodi there's a quite high resistance in doing performance enhancements while increasing the size of packages (ffmpeg comes to mind). Adding to that there's little to no desire doing platform specific configurations. > * It's more or less duplicating work already done by projects like > LibreELEC, OSMC etc. Then all work for OpenWrt / LEDE is duplicated work already done by Gentoo (emerge build instructions), Debian (deb rules-file), OpenEmbedded, you name it... I honestly think you see my point here, in this particular case. Please refrain from dumbing down the discussion. > * You'll need to import a lot more of 3rd party libs and applications to > make it a viable/reasonable user experience and there's a overall > concern about build performance of the buildbots. I heard that buildbot performance argument quite often. Back then, I eventually gave up, excluded the xorg-feed from the default feeds.conf and problem solved. Funny enough however, the discussion comes up every now and then again. Last time - without me re-initiating it nor taking sides - quite a few people who're participating at OpenWrt/LEDE for a long time by now, tried to encourage me to migrate the video feed into the packages feed. Right now I'm fine with having the extra video feed and maybe will open up the discussion about having it enabled by default some day. So, no additional build time (for now). This is an issue, recently nbd and jow (if I missed someone sorry) put a lot of work into getting package builds more efficient. It's better but as far as I know there isn't much headroom. You can read about the infrastructure here: http://lists.infradead.org/pipermail/lede-dev/2016-December/004786.html I'm sure jow, nbd and others can fill you
Re: [LEDE-DEV] Kodi
Hi, While I applaud your achievement I'd don't see such projects viable in terms of maintainability and longevity. Pulling in Kodi will result in lots of external packages and dependencies to make it usable in a reasonable way. There are several issues with this: * In general binary size > performance and/or functionality pretty much always takes priority, this is a major issue when it comes to multimedia (ffmpeg and friends comes mind). * It's more or less duplicating work already done by projects like LibreELEC, OSMC etc. * You'll need to import a lot more of 3rd party libs and applications to make it a viable/reasonable user experience and there's a overall concern about build performance of the buildbots. * Will anyone properly maintain all packages? We're already now struggling keeping the current repo somewhat up to date and maintainable, adding very niche packages certainly won't help. Whether we like or not about 90% or so of all efforts goes into something network related, I don't think we in a foreseeable future want LEDE to turn into a swiss army knife and/or jack of all trades. Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] iperf3: update to version 3.1.5 and download via git
Hi, Thanks for submitting a patch but can you please outline why we would want to switch from a tarball release to a git repo pull for iperf3? Best regards, Daniel Engberg ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Fading out PolarSSL
Hi, I'm in favor of dropping it, don't see anything good in keeping outdated and unsupported libraries. As far as package status goes... shadowsocks-libev --> https://github.com/openwrt/packages/pull/3729 + https://github.com/lede-project/source/pull/657 pianod + shairport-sync* --> https://github.com/openwrt/packages/issues/3733 transmission* --> https://github.com/openwrt/packages/issues/3731 umurmur --> doesn't compile, pr submitted upstream Best regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Request for help: Getting 3rd party libs/apps up to date
Luiz Angelo Daros de Luca has submitted a patch to update libs/elflibs, https://github.com/lede-project/source/pull/416 Current status: tools/libtool - Move to 2.4.6 tools/lzma-old - Move to 4.32.7 (http://tukaani.org/lzma/)? Newer versions available at link below tools/lzma - Move to 16.03 (https://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/) ? tools/mkimage - Move to a newer snapshot, reduces amount of patches? tools/mklibs - Move to 0.1.42 tools/squashfs4 - Update to 4.3 package/utils/mdadm - Update to 3.4 package/utils/fuse - Update to 2.9.7 package/utils/lua - Update to 5.3.3 (Should be added as a separate package) network/utils/iproute2 - Update to 4.8.0 <-- New version released network/utils/iptables - Update to 1.6.0 network/utils/iw - Update to 4.7 network/utils/tcpdump - Update to 4.8.0 libs/elflibs - WIP, Luiz Angelo Daros de Luca (https://github.com/lede-project/source/pull/416) libs/gettext-full - Updated by Dirk Neukirchen libs/libiconv-full - Update to 1.14 libs/libpcap - WIP, Michael Richardson libs/ncurses - Update to 6.0 libs/libbsd - Update to 0.8.3 (needs a.out.h, I got stuck on that) libs/libtool - Update to 2.4.6 (needs m4, blocking) Many thanks for helping out! Daniel On 2016-10-13 10:08, Daniel Engberg wrote: To follow up in order to prevent duplicate work, Michael Richardson has offered to update libpcap in the beginning of November Dirk Neukirchen has submitted a patch for libs/gettext-full 0.19.8.1 which has been accepted - http://patchwork.ozlabs.org/patch/681336/ Karl Palsson and Dirk Feytons have expressed concerns updating the current version Lua due to possible performance regressions and code (language) incompatibilities. Suggested upgrade path is to create a separate package and go from there, pretty much like python 2 vs 3. Many thanks for the response and commitment to this request. Best regards, Daniel On 2016-10-10 12:24, Daniel Engberg wrote: Hi, I've been trying with my limited set of skills to get most packages and libraries up to date but I'm getting stuck on these below since they have a lot patches and I can't adapt these for current versions or even make out if they're all even needed. Since there's going to be a release later on I think it's a good idea to keep everything up to date even if it may cost a bit of storage space since it's going to help porting new software and easier to report bugs etc upstream if needed. I also think that if we're going to do this we should get it in tree as soon as possible so there's time to fix occasional issues that may occur. If anyone wants to take a stab at these I think it would be beneficial to the project in the end. tools/libtool - Move to 2.4.6 tools/lzma-old - Move to 4.32.7 (http://tukaani.org/lzma/) ? I'm not sure how "old" this needs to be, newer versions are also available at the link below (sourceforge.net). tools/lzma - Move to 16.03 (https://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/) ? tools/mkimage - Move to a newer snapshot, reduces amount of patches? tools/mklibs - Move to 0.1.42 tools/squashfs4 - Update to 4.3 package/utils/mdadm - Update to 3.4 package/utils/fuse - Update to 2.9.7 package/utils/lua - Update to 5.3.3 (some lang regressions may occur?) network/utils/iproute2 - Update to 4.7.0 network/utils/iptables - Update to 1.6.0 network/utils/iw - Update to 4.7 network/utils/tcpdump - Update to 4.8.0 libs/elflibs - Update to 0.167 libs/gettext-full - Update to 0.19.8 libs/libiconv-full - Update to 1.14 libs/libpcap - Update to 1.8.0 libs/ncurses - Update to 6.0 libs/libbsd - Update to 0.8.3 (needs a.out.h, I got stuck on that) libs/libtool - Update to 2.4.6 (needs m4, blocking) Best regards, Daniel Engberg ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Request for help: Getting 3rd party libs/apps up to date
To follow up in order to prevent duplicate work, Michael Richardson has offered to update libpcap in the beginning of November Dirk Neukirchen has submitted a patch for libs/gettext-full 0.19.8.1 which has been accepted - http://patchwork.ozlabs.org/patch/681336/ Karl Palsson and Dirk Feytons have expressed concerns updating the current version Lua due to possible performance regressions and code (language) incompatibilities. Suggested upgrade path is to create a separate package and go from there, pretty much like python 2 vs 3. Many thanks for the response and commitment to this request. Best regards, Daniel On 2016-10-10 12:24, Daniel Engberg wrote: Hi, I've been trying with my limited set of skills to get most packages and libraries up to date but I'm getting stuck on these below since they have a lot patches and I can't adapt these for current versions or even make out if they're all even needed. Since there's going to be a release later on I think it's a good idea to keep everything up to date even if it may cost a bit of storage space since it's going to help porting new software and easier to report bugs etc upstream if needed. I also think that if we're going to do this we should get it in tree as soon as possible so there's time to fix occasional issues that may occur. If anyone wants to take a stab at these I think it would be beneficial to the project in the end. tools/libtool - Move to 2.4.6 tools/lzma-old - Move to 4.32.7 (http://tukaani.org/lzma/) ? I'm not sure how "old" this needs to be, newer versions are also available at the link below (sourceforge.net). tools/lzma - Move to 16.03 (https://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/) ? tools/mkimage - Move to a newer snapshot, reduces amount of patches? tools/mklibs - Move to 0.1.42 tools/squashfs4 - Update to 4.3 package/utils/mdadm - Update to 3.4 package/utils/fuse - Update to 2.9.7 package/utils/lua - Update to 5.3.3 (some lang regressions may occur?) network/utils/iproute2 - Update to 4.7.0 network/utils/iptables - Update to 1.6.0 network/utils/iw - Update to 4.7 network/utils/tcpdump - Update to 4.8.0 libs/elflibs - Update to 0.167 libs/gettext-full - Update to 0.19.8 libs/libiconv-full - Update to 1.14 libs/libpcap - Update to 1.8.0 libs/ncurses - Update to 6.0 libs/libbsd - Update to 0.8.3 (needs a.out.h, I got stuck on that) libs/libtool - Update to 2.4.6 (needs m4, blocking) Best regards, Daniel Engberg ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Request for help: Getting 3rd party libs/apps up to date
Hi, I've been trying with my limited set of skills to get most packages and libraries up to date but I'm getting stuck on these below since they have a lot patches and I can't adapt these for current versions or even make out if they're all even needed. Since there's going to be a release later on I think it's a good idea to keep everything up to date even if it may cost a bit of storage space since it's going to help porting new software and easier to report bugs etc upstream if needed. I also think that if we're going to do this we should get it in tree as soon as possible so there's time to fix occasional issues that may occur. If anyone wants to take a stab at these I think it would be beneficial to the project in the end. tools/libtool - Move to 2.4.6 tools/lzma-old - Move to 4.32.7 (http://tukaani.org/lzma/) ? I'm not sure how "old" this needs to be, newer versions are also available at the link below (sourceforge.net). tools/lzma - Move to 16.03 (https://sourceforge.net/projects/sevenzip/files/LZMA%20SDK/) ? tools/mkimage - Move to a newer snapshot, reduces amount of patches? tools/mklibs - Move to 0.1.42 tools/squashfs4 - Update to 4.3 package/utils/mdadm - Update to 3.4 package/utils/fuse - Update to 2.9.7 package/utils/lua - Update to 5.3.3 (some lang regressions may occur?) network/utils/iproute2 - Update to 4.7.0 network/utils/iptables - Update to 1.6.0 network/utils/iw - Update to 4.7 network/utils/tcpdump - Update to 4.8.0 libs/elflibs - Update to 0.167 libs/gettext-full - Update to 0.19.8 libs/libiconv-full - Update to 1.14 libs/libpcap - Update to 1.8.0 libs/ncurses - Update to 6.0 libs/libbsd - Update to 0.8.3 (needs a.out.h, I got stuck on that) libs/libtool - Update to 2.4.6 (needs m4, blocking) Best regards, Daniel Engberg ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
