as in subject you can reproduce it by creating an image for the canmasdeu/
bridge profile with plain lede flavour
I suspect it is because the profile get opkgized and it may be installed before
lime-system and then the file get overwritten
haven't tested if with last cooker it happens or not to confirm my theory
Cheers
Agree!
On May 29, 2018 2:17:13 AM CDT, Paul Spooren <p(a)aparcar.org> wrote:
>Hi all,
>
>The lime-packages repository has currently a huge amount of branches
>making it rather hard to spot active ones. I'd propose to use the
>following structure (stolen from OpenWrt):
>
>* Use one branch for developing (currently called "development", may
>better be unified to " master").
>* One brach per release
>
>
>This is great because new people don't start developing on master and
>eventually find out its "outdated". The structure is used on literally
>every other GH project I'm working on, even on other LibreMesh repos.
>
>All pull requests should come from forked repos.
>
>Additionally, the dev branch is currently (partly) protected so that
>most devs can't directly push there but need an approved PR, which is
>good. However, the master branch aka current stable release lacks this
>security measurement.
>
>Best,
>Paul
>_______________________________________________
>lime-dev mailing list
>lime-dev(a)lists.libremesh.org
>https://lists.libremesh.org/mailman/listinfo/lime-dev
--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Hello again,
I think for development it would be nice to automatically compile all packages on the dev branch on every push. Offering them on a server making it easy to use in dev machines.
As this introduces plenty of compiling of suggest to use cheap cloud service instead of burning our own (community) hardware.
Scaleway offers 4 cores and 25GB SSD for 3€ a month, which should be just enough. Any reasons against pointing snapshots.libremesh.org to such a VM? I'd be happy to set it up and can also pay for now.
Best,
Paul
Hi all,
The lime-packages repository has currently a huge amount of branches making it rather hard to spot active ones. I'd propose to use the following structure (stolen from OpenWrt):
* Use one branch for developing (currently called "development", may better be unified to " master").
* One brach per release
This is great because new people don't start developing on master and eventually find out its "outdated". The structure is used on literally every other GH project I'm working on, even on other LibreMesh repos.
All pull requests should come from forked repos.
Additionally, the dev branch is currently (partly) protected so that most devs can't directly push there but need an approved PR, which is good. However, the master branch aka current stable release lacks this security measurement.
Best,
Paul
