> 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. -- 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/
Description: This is a digitally signed message part
_______________________________________________ Reproducible-builds mailing list Reproduciblefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds