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-W2PA-LIME-XXXX/

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!

On 28/06/17 11:41, Nk via lime-users 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.

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/de31181ed4e4a0c9c2249848cf3a5418295dcc70

> Do you have a list of changes?

Yes, we will publish it soon once the release is officially launched.

> How do I maintain a https://github.com/libremesh/network-profiles/ community in a way that is future-consistent?

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.

> 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?

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 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?

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.

> Thank you!

Cheers!

>
> Nk
>
>
>
>
> _______________________________________________
> lime-users mailing list
> lime-users@lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
>

--
./p4u

_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users