2016-07-11 20:49 GMT+02:00 p4u <pau(a)dabax.net>:
> From the README: Or to use your own LiMe packages git repository and/or
> OpenWRT/LEDE (must be executed the first time make is invoked or after
> clean).
>
> make LIME_GIT="http://foo.git" <http://foo.git> T=ar71xx P=generic
> OWRT_GIT="http://foo.git" <http://foo.git>
>
I tried to compile LiMe on LEDE using lime-build develop, I simply issued:
make T=ar71xx P=generic OWRT_GIT="
https://git.lede-project.org/source.git"
but I noticed that there are lines in the feeds.conf file [1] included in
lime-build which are pointing to our static OpenWrt repos.
So, what is a good procedure to build LiMe on LEDE using lime-build?
Is it enough to remove those lines in the feeds.conf file and specify the
OWRT_GIT parameter pointing to LEDE source?
Thanks,
Ilario
[1] https://github.com/libre-mesh/lime-build/blob/develop/feeds.conf
Hi.
I was talking with Gui and we both agree on repointing
downloads.libre-mesh.org to builds.libre-mesh.org where there are
automatic builds (using lime-build) of develop and the current release
CommunityChaos 16.07 together with the package repositories for opkg. I
think that is the best option for stock/generic official firmwares. Then
Chef can be used for customizing those communities who need
customization. If someone does not agree we can open a discussion.
However after building the binaries, something took my attention. Now
the generated images are much smaller than before. The ar71xx-mini
target takes only 2.5M and the ar71xx with lime-full profile fits in a
4MB device. My first thinking was that the compilation was wrong but I
tested and everything is fine.
I know we clean up a bit the default packages list of lime-build and
also removed some of them which were not strictly necessary. But I was
not expecting such big difference on output firmware size. That is
actually great!
Cheers.
--
./p4u
Hi!
I saw Gui merged las fixes in 16.07 toniight, so i consider 16.07 is the
latest LiMe release I have just switched the default branch of lime build from
testin/16.07 to 16.07 so now it will build by default latest stable release :)
Congrats!
Hi devs,
here in LiMeCat2016q3 we're preparing a release:
16.07 or CommunityChaos.
I invite you to checkout the pad if you want to drop comments before the
end of the meeting:
https://pad.eigenlab.org/p/LiMeCat2016q3
Anyway after the meeting the discussion will continue on this list :)
Bye!
Ilario
--
Ilario Gelmetti
iochesonome(a)gmail.com
igelmetti(a)iciq.es
ilario.gelmetti(a)estudiants.urv.cat
Hi!
We are currently trying to use the Libre-Mesh.org firmware with
batman-adv enabled on wired Ethernet interfaces alongside with a VLAN
which is a member of the bridge the batX interface also resides in.
------------------------------
E |VLAN---batadv---bat0
T +--------------+ BRIDGE
H |VLAN------------eth0.xx
------------------------------
We do want such a setup to have the best of both worlds: the
performance of a plain bridge but yet benefit from batman-adv topology
information, alfred and all that. As many cheap Ethernet switches do
not support frames larger than 1500 bytes, increasing the MTU is not an
option and thus frames inside batman-adv end up fragmented which hurts
performance if encapsulating all traffic via batman-adv.
I remember there was a discussion during battlemesh about a race-
condition which can confuse BLA and thus batman-adv is still disabled
on wired Ethernet interfaces in Libre-Mesh by default.
So here I am asking you about the current state of affairs regarding
this issue.
We are discussing it on
https://github.com/libre-mesh/lime-packages/issues/56
and it would be great to hear a more detailed summary because I only
remember the rough details and also haven't been watching if anything
was fixed or improved since we all met in Porto.
Cheers
Daniel
It is ok for me
On Saturday 06 August 2016 16:59:20 Ilario Gelmetti wrote:
> -------- Forwarded Message --------
> Subject: Github notifications on dev mailing list
> Date: Thu, 28 Jul 2016 16:49:34 +0200
> From: Ilario <iochesonome(a)gmail.com>
> To: libre-mesh developement <dev(a)lists.libre-mesh.org>
> CC: Nicolás Echániz <nicoechaniz(a)altermundi.net>
>
>
>
> Hi devs!
> Recently there's a lot of interesting discussion [e.g. 50,56] going on
> on Github/libre-mesh bypassing completely this mailing list.
> I think we should mirror Github issues, comments on issues and similar
> stuff here.
> There's an easy solution [1] which doesn't require any software running
> on our side, but requires a mailing list administrator (Nico) to set up it.
> Shall we do this?
> Ciao!
> Ilario
>
> [50] https://github.com/libre-mesh/lime-packages/issues/50
> [56] https://github.com/libre-mesh/lime-packages/issues/56
> [1]
> https://github.com/w3c/webpayments/wiki/Synchronizing-Github-Issues-with-W3C
> -Mailing-Lists
