[U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

[Paul Kocialkowski]

Le samedi 13 juin 2015 à 11:10 +0200, Holger Levsen a écrit :
> Hi Paul,
> 
> thanks for contacting us!
> 
> On Freitag, 12. Juni 2015, Paul Kocialkowski wrote:
> > I think a bit more is needed to get truly reproducible builds in U-Boot,
> > but this is a first good step!
> 
> you've seen https://reproducible.debian.net/u-boot ?

This seems very minimalistic, but it's good to see U-Boot was given some
attention already!

> > It would certainly be relevant to get in touch with the people working
> > on reproducing builds for Debian (I know Lunar is involved with this),
> > since Debian packages U-Boot for many devices and they're apparently
> > willing to help upstream with automated tests, as they're doing with
> > coreboot and OpenWRT!
> 
> we're definitly happy to help! 
> 
> that said, I'm not sure I want to treat uboot like openwrt or coreboot, simply 
> because uboot is packaged for several distributions, so (in my maybe naive 
> assumptions) it should be tested within those distros.
> 
> coreboot is really exceptional here, as it doesn't make much sense to package 
> it as part of a distro. (though this could also change, at least sources could 
> be shipped...)
> 
> but maybe you can explain why u-boot needs more reproducibility testing than 
> what there currently is. i'm definitly interested and not opposed, even though 
> I think there shoukd be good reasons to treat some software specially.

The point is to make U-Boot reproducible for all possible targets, not
only the few ones that are supported by U-Boot. I think this requires
some extra infrastructure. In that sense, it is very similar to
Coreboot.

> (also please note that we currently only have amd64 hw to run our tests on.)

The problem is the same as Coreboot, which uses its own toolchain to
build images. We don't need to have native armhf builds for U-Boot,
testing with the armhf toolchain that is in Debian should be enough.

> In a similar way I have for now decided that I'm not interested in adding 
> tests of libreboot, as it's basically just a fork of coreboot, so the 
> reproducibility issues should be the same. OTOH libreboot releases images 
> (which coreboot doesnt do) so that might become interesting to validate. But 
> there I think that the validation should be done as part of that project 
> (=libreboot), and not as part of reproducible.debian.net, which I mostly see 
> as a.) effort to test and push Debians reproducibility effort and b.) show 
> that this is possible for other distros too - but I think in long term that 
> should move to a setup located+maintained at those other distros. (because we 
> lack the *human*power to look after too/so many things...)

I understand, this works out nicely because all the work on Coreboot
will be inherited by Libreboot. However, on U-Boot, the work to bring
reproducible builds has to take place initially. I know for a fact that
parts of the code use things like __FILE__ or timestamps.

Also, if those were fixed in Debian, it would be nice to get those
changes back in upstream.

> (And really, testing on reproducible.debian.net is not enough, it's just the 
> first step: now we know that coreboot is 100% reproducible, now what? This 
> "what" needs to happen on the coreboot side...)
> 
> So it's not (so much or maybe at all) a question of hardware ressources, which 
> we can scale up rather easily, but mostly human ressources maintaining the 
> hw+sw *and* translating this into meaningful action for the project tested.

That makes sense. For U-Boot, it will certainly make sense for the
distributions packaging it. I'm the main developer of Replicant, the
fully free version of Android, and it would definitely be useful to have
a smartphone on which we can trust that the bootloader can be built in a
reproducible manner (and checked after being installed).

> All this said, if you send me patches, I will probably deploy them as I'm very 
> curious and more reproducibility efforts are good :-) We can can always decide 
> to remove or move them later.

I wish to make all contributions upstream. What would really help at
first would be to have all targets built regularly to see where work is
needed. This is where I think the Debian infrastructure could help, in a
similar way as what was started for Coreboot.

Thanks for your help!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150613/f54e04ce/attachment.sig>