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

[Paul Kocialkowski <contact@paulk.fr>]

> 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/
-------------- 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/20150719/78c0c713/attachment.sig>