[LEDE-DEV] Reproducible builds & feeds

Jonas Gorski jonas.gorski at gmail.com
Wed Oct 19 03:31:50 PDT 2016


On 15 October 2016 at 17:32, Rafał Miłecki <zajec5 at gmail.com> wrote:
> Hi,
> After Holger & Alexander talk at OpenWrt Summit I started thinking
> about handling feeds in LEDE. Right now we simply point to external
> repositories within feeds.conf(.default):
> src-git packages https://git.lede-project.org/feed/packages.git
> src-git luci https://git.lede-project.org/project/luci.git
> src-git routing https://git.lede-project.org/feed/routing.git
> src-git telephony https://git.lede-project.org/feed/telephony.git
> I see few problems with this solution:
> 1) No info on used feeds revisions
> Problem: When you get an image you can't say which revisions of feeds
> were used to build it.
> Possible solution: Include some extra file with info about each feed
> and used revision

Not sure yet how much this is actually helps/makes sense. Usually
images do not contain packages from feeds, just from base packages,
and the packages in the feeds might have been updated since
downloading the image. The info might be better stored along side the
actual feeds, not in the image. Note that you also don't get a .config
in your image, so if e.g. kernel options were changed you won't be
able to reproduce it either (unless you correctly guess the options).

> 2) No pointing specific revision
> Problem: We always use the latest revision of each feed. It's easy to
> hit some problem/regression introduced in a feed without an easy way
> of tracking it down. You have to guess which was the latest working
> revision.
> Possible solution: Always point specific revision in
> feeds.conf.default, e.g. src-git packages
> https://git.lede-project.org/feed/packages.git^commithash .
> Unfortunately this will require us to update this file over and over.

Yeah, I don't think this is a healthy way of doing it, unless we have
a bot that does that every X hours or so. And that leads to a lot of
noise in the commit log. At most it might makes sense for release
(-candidate) branches, where we want to be careful which feeds
revisions we do want to build.

> 3) The way of specifying revisions
> Problem: This is only possible with manually creating a proper
> feeds.conf. I'm wondering if this would make sense to make is somehow
> more script friendly? Alexander, Holger: what do you think about this?
> Possible solution: Implement solution suggested in problem 2 or maybe
> add support for some env variable(s) pointing revision(s)?

For making this easier I added the ability for scripts/feeds to give
you the current feeds with their revisions a while ago in the expected
format, e.g.

# ./scripts/feeds list -s -f
src-git packages https://git.lede-project.org/feed/packages.git^144812d
src-git luci https://git.lede-project.org/project/luci.git^6be6904
src-git routing https://git.lede-project.org/feed/routing.git^fe8fa0b
src-git telephony https://git.lede-project.org/feed/telephony.git^1f0fb25

Adding this to along side the config.<target> we ... used to provide
should make it much easier to reproduce a build (then I guess as a
feeds.<arch> or so in phase2).

> I think the problem that really needs solving is the first one. The
> rest we can probably just discuss (hint: waiting for your opinions).
> Right now it's not possible/easy to rebuild image I got downloaded.
> Even if I'm ready to create my own feeds.conf I don't know what
> revisions to put there. Also please note this is only an introduction
> to have binary reproducible builds.

Maybe we could add a step in the build that at the end that will
compile all build info, i.e. revision of the repo, revisions of the
feeds, minimized config, and put it along side the images / packages.


More information about the Lede-dev mailing list