On 13/07/16 17:36, p4u wrote:
In-line.
On 13/07/16 17:21, Ilario wrote:
2016-07-13 16:31 GMT+02:00 p4u <pau@dabax.net
<mailto:pau@dabax.net>>:
On 13/07/16 15:50, Ilario wrote:
2016-07-13 15:39 GMT+02:00 p4u
<<mailto:pau@dabax.net>pau@dabax.net>:
Hi. After working and testing lime-build, I think we can publish
again the link to http://downloads.libre-mesh.org. I've tested
(also Ilario) the resulting images and they work fine.
Yep, lime-build is working but still I support the fact that we
can't indicate two different sources for stable images: chef and
downloads. So I would keep downloads pointing to chef and I would
open a new subdomain for downloading the development version of
Libre-Mesh built with lime-build. For example
unstable.libre-mesh.org <http://unstable.libre-mesh.org> or
something similar.
I don't see any reason why Chef images would be more stable than
lime-build release images. The only fact is the testing process
which might be involved. However until we solve all this "mess" and
we decide to go in a single direction, I accept your suggestion.
Well, you were there when this was decided...
http://lists.libre-mesh.org/pipermail/users/2016-April/000101.html
One of my suggestions was to change to "builds", but not "unstable"
because I still don't see why Chef images should be more stable than
lime-build release ones.
In any case, the important thing here is what we put on the web page
because people will just click the link whatever the name of it is.
But OK, I'll change to "builds" and redirect "downloads" again to
Chef.
Maybe instead of "unstable" (which is not the case because the
release 15.09 should be stable) I would do "builds.libre-mesh.org
<http://builds.libre-mesh.org>" or something like that. Or maybe
leave "downloads.libre-mesh.org <http://downloads.libre-mesh.org>"
but announce on the web page that for the moment the safe way is to
use the poor set of images provided by Chef ;)
There should be just one place where you can download the official
stable release (official implies unique). Clearly, whatever is the
official stable release, downloads.libre-mesh.org
<http://downloads.libre-mesh.org> has to point at it. The problem
that chef doesn't include many devices can be solved in next stable
release.
I don't think the current Chef implementation can handle more than
one different architecture.
It does currently handle atheros and ar71xx, but i haven't
used/maintained atheros targets since 2013.
All i wanted to say is that: yes, multi arch are supported
Well, chef is now used for stable releases and that uses
lime-build, right?
Not at all. These Images are manually compiled by Guido in some
local machine. So there is no way to reproduce the same building
unless you know the exact parameters Gui is using.
I hope in next Chef releases we would use the ImageBuilder
generated by lime-build. So there will be an actual way to
reproduce it.
Gui wrote that Chef is using that, if I got him correctly.
http://lists.libre-mesh.org/pipermail/dev/2016-July/000721.html
I'm not sure of that. Maybe in this last release he did it, but it
has not been like this the last years.
I've been feeding the chef with an ImageBuilder created with lime-build
since the day you commited that feature into lime-build :)
In any case, if it is like this then there should not be any
difference between the generic binaries in Chef and the binaries of
builds.libre-mesh.org. So what's the point for all this discussion?
Lime-Build was kind of broken until now but it works fine now and
compiles all possible targets.
lime-build is the only way to nightly build bleeding edge code, we all
agree to use it for that
it can also be used (by advanced users = linux cli users) to build
stable-release binaries (generic in principle but also customized, by
placing files in appropiate dirs)
this second use case overlaps with chef use case (build stable-release
customized binaries, or download generic stable-release binaries). But
chef is usable by a lot more users (windows, androids, etc)
So i don't see a point in publishing generic stable-release binaries
made with lime-build, if that will also be necesarily generated as well
by chef (using an IB made with lime-build)
I think it's more consistent to say
"we publish/manage releases inside chef, both generic and customizations"
and "we also publish generic, bleeding edge binaries, made with
lime-build branch develop, at whatever.libremesh.org"
the list of supported hardware (available binaries) at
whatever.libremesh.org will be normally larger (but with less testing)
than what's available at chef.libremesh.org
a new router model, that has been tested to run fine on develop (i.e.
whatever.libremesh.org), will be made available on chef (i.e. stable
releases) during the next release cycle. We could also "backport" models
availability to previous releases for some reason, but i'd evaluate it
case-by-case
all this is simply inspired by the "normal" openwrt/LEDE release schema