Last mail of 3 [to understand context please see the first one] What if we created a “unified configuration” file for LiMe? Example that perfectly explains my POV: I see quintanalibre has a script in uci-defaults that overwrites /etc/config/libremap with just the details it wants to overwrite, and nothing else, without, for instance, conflicting with the most recent update from upstream that introduces the freifunk libremap details, which instead would never have made it in their images if they had included the actual /etc/config/libremap file itself. We could make one file, once and for all, that cleanly substitutes variables all over where needed, leaving every line of every file open for updates from upstream. As more variables become available over time, the maintainer of that community can simply pull the new “LiMe-UCF” file from upstream, merge in his or her variables from his or her /network-profiles/ community, define the new ones that have become available [such as the freifunk libremap contact name and email, which just showed up recently], and know that any SDK build will be as bleeding-edge as any other. This would also reduce fragmentation between communities, which is already a problem when we introduce “hard forks” such as adhoc-to-802.11s changes. Let’s try and reduce all other incompatibilities to zero by having everyone be one click away from the latest version. Don’t you think? And if so, what do you think of this idea? Thanks! Nk On June 28, 2017 at 2:53:09 PM, Nk (nk(a)os.vu) wrote: A quick update: I’ve recreated our config files [https://github.com/libremesh/network-profiles/tree/master/openNET.io/1144-W…] by only porting the required details [SSID Name, libremap lat, long, etc…] in the new /etc/config/lime-defaults AND in /etc/lime-config-firstboot/lime-defaults, so that both lime-defaults and libremap files are both in /etc/config/ AND /etc/lime-config-firstboot/. I don’t think this is correct however, as I’m having issues with devices meshing but not reaching eachother and DHCP from ISP router passing through the 10. LAN created by the LiMe router, overwriting the LiMe router’s DHCP on both wired and wireless clients. What files do I need to edit and what should I not be touching? Could anyone take a look at the link above to see if everything looks good? Thank you! Nk On June 28, 2017 at 11:41:34 AM, Nk (nk(a)os.vu) wrote: Hi In order to understand how to start using 802.11s from SDK, I’ve downloaded a pre-built image from http://repo.libremesh.org/lime-17.04/ [downloads.libremesh.org isn’t responding at least for me - I think I need a 17.02 version to compare with an SDK output, no?]. I’ve noticed a few changes such as the directory /etc/config/ becoming /etc/lime-config-firstboot/ and more in luci-defaults and so on. Do you have a list of changes? How do I maintain a https://github.com/libremesh/network-profiles/ community in a way that is future-consistent? I’d like to be able to have details in there that really only override things I’ll always want to override, such as the SSID, but allow for all other file changes [like adhoc becoming 802.11s for instance] from upstream to pour down into my SDK images, with no interference at all and no risk of having conflicts. Also because images I’m building now, once flashed, don’t work at all, so there is a big risk in upstream changes conflicting with network-profiles, don’t you think? I know this means a line-based granularity and not a file-based one such as now, but there must be a way, no? In any event, for now, what changes do I have to make to my community files in order to get SDK to cook valid and up-to-date in every way images? Thank you! Nk _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

Hi Pau Thanks for your reply This was introduced on August 2016 [1] and the purpose is to have a  backup of the original UCI files, but in any case it should affect the  behavior of the libremesh configuration system. Ok so lime-config first boot is an auto backup of /etc/config if I understand correctly, so I should not create that directory or any file inside it in the community profile, is this correct? Yes, we will publish it soon once the release is officially launched.  Thank you Most of the options of lime-defaults have a 'default' value which is  hardcoded on the LUA code, so in case there is a new option on the  official lime-defaults file but it is not in the one from your  community, things should work as expected.  We try to always maintain the consistency with old firmwares. In case  you find something which is not consistent you might report it and it  must be fixed.  That should not happen. You must be able to maintain your own  lime-defaults file for your community. However it might be useful to  have a tool for comparing and updating the options of lime-defaults  (maybe a python or bash script which can be run in your local computer).  That’s good to know. I do think a diff tool would be great, so that each community can implement customized settings right away as they become available I'd like to know what made your SDK to generate a non-valid firmware  image for your community. Then we might figure out how to solve it for  future libremesh versions.  You can find our non-working code here: https://github.com/libremesh/network-profiles/tree/master/openNET.io/1144-W… It still has the lime-config-firstboot directory but I’ll delete it right away. The fact is that that update to /etc/config/lime-defaults and /etc/config/libremap would have never made it into our community profile had I not checked the new version in pre-compiled images, and I was only able to implement them after having rewritten ours, merging our customizations variable by variable, one by one, into the new files, which had, for instance, 802.11s support and new variables for the freifunk libremap that were not there before. I know that the invalid image is either my fault or a separate and distinct error, but being able to define actual variables one by one without overwriting entire config files would still make me feel much more at ease, since the margin of error would go down practically to zero, allowing for new and updated config files to be directly merged into every community profile, with default values in case of new variables of course, but only until the maintainer of that community realized such new availability of variables, and decided to customize them if desired. I’ll try to understand what is making our profile invalid and report back, in any event. Hope this makes sense, even if you might not agree. Thank you for maintaining this extremely stable and avant-garde project, this goes always without saying, of course. Thanks! Nk On June 29, 2017 at 12:45:26 PM, Pau (pau(a)dabax.net) wrote: On 28/06/17 11:41, Nk via lime-users wrote: This was introduced on August 2016 [1] and the purpose is to have a backup of the original UCI files, but in any case it should affect the behavior of the libremesh configuration system. [1] https://github.com/libremesh/lime-packages/commit/de31181ed4e4a0c9c2249848c… Yes, we will publish it soon once the release is officially launched. Most of the options of lime-defaults have a 'default' value which is hardcoded on the LUA code, so in case there is a new option on the official lime-defaults file but it is not in the one from your community, things should work as expected. We try to always maintain the consistency with old firmwares. In case you find something which is not consistent you might report it and it must be fixed. That should not happen. You must be able to maintain your own lime-defaults file for your community. However it might be useful to have a tool for comparing and updating the options of lime-defaults (maybe a python or bash script which can be run in your local computer). I'd like to know what made your SDK to generate a non-valid firmware image for your community. Then we might figure out how to solve it for future libremesh versions. Cheers! -- ./p4u _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users