sorry for the late reply.
No problem, I haven't kept you or the list posted on this either.
I got a chance to discuss the issue with Lunar during RMLL 2015 and we came up with a nice way of doing things, using SOURCE_DATE_EPOCH.
On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
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!
As far as I understood, this was only for the U-Boot tools.
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 your sentence is missing some word…?!?
not only for the few one that are supported by U-Boot maybe?
Looks good otherwise!
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.
I see.
There seem to be two solutions to this: * Including a script (e.g. the one from coreboot) to build the toolchain as part of the build process * Using native builds with visualization on the servers that run the builds for the reproducible task force
I tend to prefer the second one since it only requires a one-time setup cost, while the other one, that requires to build toolchains for each test build, implies a considerably longer build time for each test.
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.
Ah.
Not all the targets are using that though, and the target we used during RMLL required only timestamp changes to become reproducible (it was the Cubieboard2 IIRC). Still, I have seen that code around, so it must be used somewhere, so it should be fixed, too.
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.
can you point me to a how to explaining this or tell me those steps, starting with "git clone..."?
The basics for building U-Boot are the following (e.g. for the Cubieboard2 target) git clone git://git.denx.de/u-boot.git cd u-boot make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE Cubieboard2_defconfig make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE
I usually also pass ARCH=$ARCH to make but that's useless, apparently.
Let me know if you need more indications on this.