[lime-dev] LiMe on LEDE 17.01 or rather LiMe-NG?

Hi! Good to see that lime is still alive after all. I thought about some things which need to be taken care of and would like to get some feedback and opinions: * wouldn't it be great to finally use LEDE's SDK + ImageBuilder instead of lime-build (which is hard to maintain)? LEDE does rolling-release for packages and promissed regular maintainace cycle for their releases. 17.01 just came out, 17.01.0 is already in the pipe, 17.01.1 will come in May/June, and so on. suggestion: drop lime-build in favour of using the lime-packages feed with the SDK to provide packages to be used with the ImageBuilder. If there is any real reason to fork LEDE and/or use custom builds, please speak up, I'll be your advocate on board of the LEDE team to resolve those issues. * lime-config currently re-writes UCI configuration. ie. if I mess up /etc/config/network, running lime-config will not necessarily fix it. There are also situations which make re-running lime-config impossible as that would break the config completely. To resolve that mess I suggest to refrain from re-writing UCI configuration and rather generate it from scratch every time by using the new /bin/config_generate script. If anything is missing in that new board-config aka. uci-defaults approach, then we should add it and discuss with upstream, ie. make sure that all board-specific details needed to generate the entire configuration are covered. Hence I'd like to re-write lime-config from scratch. And maybe use Shell instead of Lua. I know, this may sound terrible, but I'm sure it'd be a great step towards reusability of the code for other projects (which may not use all the rest of LiMe, maybe not even use Lua at all) and also make the lime firmware more robust and cover more use-cases (such as re-configuring images on the go rather than using CHEF or imagine changing things in the field using some remote mass-management tools, I'm thinking of OpenWISP) * speaking about CHEF: what's happening on that scene? I find CHEF very complicated, but I'm not a web guy :( I saw it finally found someone willing to maintain it. Is there a roadmap or something? And how can people contribute documentation, localization and all that? And will it move to github? * hardware support: I think we should support more hardware targets, not just ar71xx, x86 and mt7621 (I do appreciate that mt7621 made it to the current release!). I'm working a lot on MT7620 lately, there are a terrible lot of devices out there and though this chip (or driver...) does not allow combining Ad-Hoc + AP, it apparently does allow combining 802.11s + AP! suggested additional hardware platforms, in random order, high- priotity is marked with an '!': !mvebu, !ramips/rt305x, ramips/rt3883, !ramips/mt7620, !ramips/mt7628, !ramips/mt7688, !ipq806x, !lantiq/xrx200, !lantiq/xway, octeon, !x86/generic, x86/geode, !x86/64, arm64, armvirt, sunxi, mediatek, brcm2708/bcm2708, brcm2708/bcm2709, brcm2708/bcm2710 (ie. all up-to-date platforms with good support in LEDE) I don't know enough about the bcm53xx, brcm47xx and brcm63xx targets to tell if any of those could be useful, but most likely they can, especially those with brcmsmac or brcmfmac wifi. For all others, especially those marked to be high-priority in the list above, I'm more than willing to help and contribute whatever is needed to get going. * speaking about 802.11s: should we switch to use the 802.11s MAC by default? Ad-Hoc/IBSS has many known problems and nobody among the people hacking the drivers seems to really care about it as it's broken by design... Cheers Daniel