On Sat, Mar 11, 2017 at 03:53:15AM +0100, Pau wrote: Having different flavors and package sets can be achieved with the released binaries and doesn't need rebuilding the kernel and everything from scratch. However, kernel-config modifications are indeed are no-go when we want to use the vanilla release binaries. Hopefully ar71xx-mini won't be needed any more once we migrate the target to use device-tree instead of shipping all the mach-* board initialization on each and every binary eventhough exactly one is needed ona specific board.... The problem for now has been that OpenWrt always used to decided to make a half-broken release (e.g. 15.05) and then it took us more than a year to release another build addressing the issues (e.g. 15.05.1). And then we got stuck and never made a binary build fixing the remaining issues despite the fact that the fixes have already made it to our git tree... Hence I do understand that you didn't have another choice than building your own binaries using up-to-date sources from scratch. As release builds in LEDE are generated automatically this will be a much shorter cycle now. But sure, I can see how you got to the point you are now, so just watch it and decide for yourself. It's not about using any ImageBuilder, but about using the binary one which is released on downloads.lede-project.org. In that way, e.g. a stackdump triggered by a kernel bug or segfault traces from userspace are meaningful to everybody, as we know that we are actually dealing with the exact same binaries and have collected debugging symbols for them. The advantage is reproducibility and ability to trace down bugs in LEDE in a common shared effort instead of each project with their own build having to deal with their own individual set of bugs and debugging information being useless for upstream developers. And sure, there is no reason to be dogmatic, so binaries of the lime-packages which are built with the released SDK can easily be provided in addition to the ones created using lime-build. I'll get back to that approach below in my reply about the additional hardware platforms. I can understand your resentiments when it comes to bashism, but those arguments are not necessarily true for all Shell code. Have a look at that /bin/config_generate for example: https://git.lede-project.org/?p=source.git;a=blob;f=package/base-files/file… So it's not necessarily the language which makes scripts horrible, but the way it is being used. And honestly, Lua can also be used in horrible ways despite the fact that being a functional language it prevents you from some of the worst programming styles... The LiMe code is not bad, but also sometimes bloated or a bit weird. People who know OpenWrt/LEDE very well still need months or even years to get into it, and a large fraction of them don't know or even care about LuCI or Lua at all. I understand that Lua was already part of the packages included in a default build because of LuCI in the past, however, today this is something we'd like to get rid of... Hence, to me a lot of LiMe looks like concepts inspired from LuCI, which was revolutionary at a time most routers were using CGI scripts generating HTML3 code using echo commands... Today even LuCI looks old-fashioned and it's weird to have *any* kind of dynamically generated code at all, because we don't need that any more. HTML can be static, JS can be static, RPC handler doesn't need to generate anything else than JSON or XML, ie. serialized objects and that can be done in any language including C or even Shell. I'm fully aware of that and there is no reason to have everything in one long and horrible spaghetti script even when using Shell. Things can and should be functional and modular, of course. I agree, so let's take LEDE there :) About the pro-Lua arguments: libremesh has learned some principles of good programming practise and has become more mature. You can argue that this is because of the language you have chosen and I agree this choice has educated programmers as they were forced to write functional code. However, please differentiate: I'm not saying you should write your web interface or RPC API in Shell. Just everything around lime-config, as we already got the libraries and framework for everything needed to do that in /lib/functions/* as part of the base-files package in OpenWrt/LEDE. I just don't see the point in have a lot of redundant code written in two different languages which basically does the same thing. To me the current lime-config approach just looks like coming from an approach which was working around missing features in OpenWrt 5 years ago but are now present and happen to be provided by Shell libraries. I had a look at all the things dealing with UCI in lime-system, and yes, I believe it's worth replacing it or at least dropping major parts of it in favour of using the new board-config approach. The needed changes should be integrated in LEDE's board-config and config-generate framework rather than maintaining a seperate configuration generation framework. Obviously this will not happen all at once, ideally you will just see how you less and less need things like lime-hwd-openwrt-wan, just to name one of the most ugly and confusing corners. Good to hear that! Though I'm not a big fan of github, I've seen that people who are coming from a web or l10n/i18n corner are much more comfortable contributing using github's webui than using mercurial. Running a gitlab instance would also do the trick, I guess. Just make sure you have a web-based editor and don't force people to work on a local copy -- they might be using windows or macos and not familiar with working on the terminal at all. Providing a good how-to on working and contributing to CHEF using some IDE like Eclipse could also do the trick. However, I just found myself lost and couldn't direct people willing to contribute because of the fact that mercurial and using the shell was just to much for them (while they are perfectly able to do web-stuff or l10n/i18n) It's deffinitely stable on ath9k and by using it there we can start testing other drivers like ath10k, mwlwifi, brcm*, mt76 and rt2x00 (all of them don't support Ad-Hoc mode nicely but do support 802.11s). And let's find out how useful it is and fix the bugs :) I don't see that we ever had a purely theoretical test-bed for anything. That, I was taught and agree with, is the big difference between ICT and IT: In IT you got development, testing and production. In ICT you only got development and production. There are no testing mobile towers and no testing access concentrator boxes in the streets, because that would mean having the whole infrastructure twice -- not really a big deal if it's about a bunch of web or database servers, but when it comes to telecom stuff that whole idea is just impossible. You do have one mobile cell or DSL access concentrator for development somewhere in a lab, but you can't duplicate the whole infratructure for testing. I do have many ramips boards flying around, some lantiq and irq806x. mvebu became more common since that whole WRT1200AC and WRT1900AC story, I don't have any of those, though, but we should ask Linksys to provide them to the community as they claim to be OpenWrt friendly while selling those boxes are commonly sold around $200 (which isn't exactly friendly in terms of budget) About using the vanilla SDK+ImageBuilder: Definitely yes. I'm really struggling with lime-build. It kinda always fails for me with weird errors like line[0]: Using: command not found So ok, in this case there definitely is some horrible Shell code involved... Or it sabotages me by re-downloading things on every run. I usually don't have a lot of bandwidth while programming, often while on the train or sitting somewhere in the nature, many times without any connectivity. So I rely in local git trees and a huge dl/ folder which I carry around... In that way, lime-build is just as impossible for me to use as e.g. Docker turned out to be. It generates hundreds of megabytes of traffic on every single run... Hence I suggest this: I'll write a script which downloads the SDK for an arbitary OpenWrt target platform and builds all of lime-packages with it. Then downloads ImageBuilder for that very same platform and generates images for all boards which include lime-basic and all it's dependencies. I wouldn't really bother with devices which haven't got enough flash at this point (though there are tons of Rt305x devices with 4MB flash and 32MB ram, however, as ramips uses device-tree and is generally a more modern and hence more modular target than ar71xx I see hope that we'll still fit everything even on those boxes) If you can provide me with access to a host which I can use have stuff built and publish the resulting binaries that'd be amazing! And it would obviously also resolve the first point above, ie. have lime-packages for LEDE release builds on ar71xx. Sure true, and hence it should only be the default for new communities or those who deliberately want to make the switch (which, indeed, is a lot of work...)