
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!