build: create time and date independent binary
PATCH 1/1 build: create time and date independent binary
With this option enabled each compilation creates the exact same binary. There are no timestamps, with which a U-Boot binary can be identified.
This option is disabled by default.
---
Kconfig | 9 +++++++++ Makefile | 8 ++++++++ 2 files changed, 17 insertions(+)
Kconfig +9 -0
@@ -81,6 +81,15 @@ menuconfig EXPERT Only use this if you really know what you are doing. if EXPERT + config SYS_EXACT_BINARY + bool "Create time and date independent binary" + default n + help + With this option enabled each compilation creates the exact + same binary. There are no timestamps, with which a U-Boot + binary can be identified. + This option is disabled by default. + config SYS_MALLOC_CLEAR_ON_INIT bool "Init with zeros the memory reserved for malloc (slow)" default y
Makefile +8 -0
@@ -1230,11 +1230,19 @@ define filechk_version.h echo \#define LD_VERSION_STRING \"$$($(LD) --version | head -n 1)\"; ) endef +ifeq ($(CONFIG_SYS_EXACT_BINARY),y) +define filechk_timestamp.h + (LC_ALL=C date +'#define U_BOOT_DATE "NODATE"'; \ + LC_ALL=C date +'#define U_BOOT_TIME "NOTIME"'; \ + LC_ALL=C date +'#define U_BOOT_TZ "NOTZ"') +endef +else define filechk_timestamp.h (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ LC_ALL=C date +'#define U_BOOT_TZ "%z"') endef +endif $(version_h): include/config/uboot.release FORCE $(call filechk,version.h)
Signature · 1 line
2.1.0
PATCH 1/1 build: create time and date independent binary
Le vendredi 12 juin 2015 ? 17:31 +0200, Heiko Schocher a ?crit :
Quoted 5 lines
With this option enabled each compilation creates the exact same binary. There are no timestamps, with which a U-Boot binary can be identified.
This option is disabled by default.
I think a bit more is needed to get truly reproducible builds in U-Boot, but this is a first good step!
I have been thinking about bringing reproducible builds to U-Boot for a little while, but never got around actually doing it. Are you interested in helping me on that? I have some free time these days, so I could do some work on this.
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!
Quoted 51 lines
Signed-off-by Heiko Schocher <[email protected]>---
Kconfig | 9 +++++++++ Makefile | 8 ++++++++ 2 files changed, 17 insertions(+)Kconfig +9
-0@@ -81,6 +81,15 @@ menuconfig EXPERT Only use this if you really know what you are doing. if EXPERT + config SYS_EXACT_BINARY + bool "Create time and date independent binary" + default n + help + With this option enabled each compilation creates the exact + same binary. There are no timestamps, with which a U-Boot + binary can be identified. + This option is disabled by default. + config SYS_MALLOC_CLEAR_ON_INIT bool "Init with zeros the memory reserved for malloc (slow)" default yMakefile +8
-0@@ -1230,11 +1230,19 @@ define filechk_version.h echo \#define LD_VERSION_STRING \"$$($(LD) --version | head -n 1)\"; ) endef +ifeq ($(CONFIG_SYS_EXACT_BINARY),y) +define filechk_timestamp.h + (LC_ALL=C date +'#define U_BOOT_DATE "NODATE"'; \ + LC_ALL=C date +'#define U_BOOT_TIME "NOTIME"'; \ + LC_ALL=C date +'#define U_BOOT_TZ "NOTZ"') +endef +else define filechk_timestamp.h (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ LC_ALL=C date +'#define U_BOOT_TZ "%z"') endef +endif $(version_h): include/config/uboot.release FORCE $(call filechk,version.h)
Signature · 16 lines
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/20150612/dc33cfbb/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Hi Paul,
thanks for contacting us!
Quoted 2 lines · Paul Kocialkowski
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 ?
Quoted 4 lines
I have been thinking about bringing reproducible builds to U-Boot for a little while, but never got around actually doing it. Are you interested in helping me on that? I have some free time these days, so I could do some work on this.
cool!
Quoted 5 lines
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.
(also please note that we currently only have amd64 hw to run our tests on.)
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...)
(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.
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.
cheers,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150613/8d73dec1/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Le samedi 13 juin 2015 ? 11:10 +0200, Holger Levsen a ?crit :
Quoted 9 lines
Hi Paul,
thanks for contacting us!
Quoted 2 lines · Paul Kocialkowski
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!
Quoted 12 lines
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 1 line
(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.
Quoted 10 lines
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.
Quoted 7 lines
(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).
Quoted 3 lines
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!
Signature · 16 lines
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>
PATCH 1/1 build: create time and date independent binary
Hi Paul,
sorry for the late reply.
Quoted 3 lines · Paul Kocialkowski
Quoted 1 line
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!
:-)
Quoted 6 lines
Quoted 4 lines
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??!?
Quoted 10 lines
I think this requires
some extra infrastructure. In that sense, it is very similar to Coreboot.Quoted 2 lines
(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.
Quoted 4 lines
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.
Quoted 5 lines
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).
indeed!
Quoted 8 lines
Quoted 3 lines
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..."?
cheers,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150719/b087fd9c/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Quoted 8 lines · Holger Levsen
Quoted 8 lines
Quoted 3 lines
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.
FWIW, I was planning on including this patch to u-boot in the next upload to Debian:
I *think* that actually makes u-boot build reproducibly with Debian's reproducible builds toolchain when SOURCE_DATE_EPOCH is set, but I haven't tested it fully. I might have missed some other sources of non-determinism...
Hoping to get some armhf buildd nodes up an running soonish... although it should also be buildable with the cross-toolchains, if the reproducible buildds coulld be made to support that.
live well,
vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150719/5b82d61c/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Le dimanche 19 juillet 2015 ? 06:14 -0700, Vagrant Cascadian a ?crit :
Quoted 13 lines · Holger Levsen
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
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.
FWIW, I was planning on including this patch to u-boot in the next upload to Debian:
Quoted 6 lines
I *think* that actually makes u-boot build reproducibly with Debian's reproducible builds toolchain when
SOURCE_DATE_EPOCHis set, but I haven't tested it fully. I might have missed some other sources of non-determinism...
We came up with something similar last week. This is not actually sufficient, but close. I will submit what I have to the U-Boot mailing list soon (hopefully, later today), feel free to review it there and import it to Debian.
Quoted 3 lines
Hoping to get some armhf buildd nodes up an running soonish... although it should also be buildable with the cross-toolchains, if the reproducible buildds coulld be made to support that.
Native builds don't seem realistic given the many different architectures that U-Boot supports, unless done with virtualisation (see my other email from today).
Now that I think about it, maybe virtualisation would require simply too many VMs to setup.
Either way, we can always try to add a toolchain build script to U-Boot.
Signature · 16 lines
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/a9acaffd/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Hi,
Quoted 8 lines · Paul Kocialkowski
Quoted 4 lines
I *think* that actually makes u-boot build reproducibly with Debian's reproducible builds toolchain when
SOURCE_DATE_EPOCHis set, but I haven't tested it fully. I might have missed some other sources of non-determinism...We came up with something similar last week. This is not actually sufficient, but close. I will submit what I have to the U-Boot mailing list soon (hopefully, later today), feel free to review it there and import it to Debian.
cool!
Quoted 3 lines
Native builds don't seem realistic given the many different architectures that U-Boot supports, unless done with virtualisation (see my other email from today).
[...]
Quoted 1 line
Either way, we can always try to add a toolchain build script to U-Boot.
I agree, I also think we should test uboot with such a script, similar like we do for coreboot. That wouldnt need armhf buildds.
That said, making use of these armhf buildds Vagrant is planning to setup would also useful to test Debian packages (incl uboot) on armhf.
cheers,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150719/0f2f5a3a/attachment.sig>
PATCH 1/1 build: create time and date independent binary
In reply to Vagrant CascadianHello Vagrant,
Am 19.07.2015 um 15:14 schrieb Vagrant Cascadian:
Quoted 21 lines · Holger Levsen
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
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.
FWIW, I was planning on including this patch to u-boot in the next upload to Debian:
I *think* that actually makes u-boot build reproducibly with Debian's reproducible builds toolchain when
SOURCE_DATE_EPOCHis set, but I haven't tested it fully. I might have missed some other sources of non-determinism...
Quoted 3 lines
Hoping to get some armhf buildd nodes up an running soonish... although it should also be buildable with the cross-toolchains, if the reproducible buildds coulld be made to support that.
Did you see my v2 patch [1] for u-boot?
It also builds now u-boot images created with mkimage reproducible ...
If I interpret your patch from above correct, you add with SOURCE_DATE_EPOCH a specific fix timestamp?
I think, this could be included to my approach too ...
If SOURCE_DATE_EPOCH is defined, use it, fi not defined define U_BOOT_DATE, U_BOOT_TIME and U_BOOT_TZ with my default settings from [1] ...
All only if CONFIG_SYS_EXACT_BINARY is set in the u-boot config of course ...
What do you think?
bye,
Heiko
[1] http://patchwork.ozlabs.org/patch/487530/
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 build: create time and date independent binary
Quoted 9 lines
Did you see my v2 patch [1] for u-boot?
It also builds now u-boot images created with mkimage reproducible ...
If I interpret your patch from above correct, you add with
SOURCE_DATE_EPOCHa specific fix timestamp?I think, this could be included to my approach too ...
Quoted 8 lines
If
SOURCE_DATE_EPOCHis defined, use it, fi not defined defineU_BOOT_DATE,U_BOOT_TIMEandU_BOOT_TZwith my default settings from [1] ...All only if
CONFIG_SYS_EXACT_BINARYis set in the u-boot config of course ...What do you think?
I think adding a config option adds all sorts of unnecessary complications. SOURCE_DATE_EPOCH is sufficient for what we want.
Thanks a lot for your work, it has been a great base for the patch I just sent: http://patchwork.ozlabs.org/patch/497577/
Feel free to add your signed-off-by line since it's inspired by your patch.
Signature · 16 lines
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/20150720/5ef28ae6/attachment.sig>
PATCH 1/1 build: create time and date independent binary
In reply to Holger LevsenQuoted 1 line
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.
Quoted 5 lines · Paul Kocialkowski
Quoted 2 lines
Quoted 1 line
you've seen https://reproducible.debian.net/u-boot ?
This seems very minimalistic, but it's good to see U-Boot was given
some
Quoted 1 line
attention already!
As far as I understood, this was only for the U-Boot tools.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
but maybe you can explain why u-boot needs more reproducibility
testing
Quoted 1 line
Quoted 1 line
than what there currently is. i'm definitly interested and not
opposed,
Quoted 8 lines
Quoted 1 line
Quoted 1 line
even though I think there shoukd be good reasons to treat some
software
Quoted 2 lines
Quoted 1 line
specially.
The point is to make U-Boot reproducible for all possible targets,
not
Quoted 1 line
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!
Quoted 5 lines
Quoted 5 lines
I think this requires
some extra infrastructure. In that sense, it is very similar to Coreboot.Quoted 1 line
(also please note that we currently only have amd64 hw to run our
Quoted 8 lines
tests
Quoted 5 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 1 line
reproducible builds has to take place initially. I know for a fact
that
Quoted 1 line
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.
Quoted 8 lines
Quoted 1 line
Quoted 1 line
All this said, if you send me patches, I will probably deploy them
as I'm
Quoted 1 line
Quoted 1 line
very curious and more reproducibility efforts are good :-) We can
can
Quoted 4 lines
Quoted 1 line
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
Quoted 8 lines
is
Quoted 1 line
needed. This is where I think the Debian infrastructure could help,
in a
Quoted 1 line
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.
Signature · 16 lines
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>
PATCH 1/1 build: create time and date independent binary
Hi Paul,
Quoted 6 lines · Paul Kocialkowski
Quoted 1 line
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.
oh, nice!
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
you've seen https://reproducible.debian.net/u-boot ?
As far as I understood, this was only for the U-Boot tools.
yes
Quoted 9 lines
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 forceI 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.
these hosts also need maintenance so I actually prefer the first.
Quoted 6 lines
The basics for building U-Boot are the following (e.g. for the Cubieboard2 target)
git clonegit://git.denx.de/u-boot.git
cd u-boot
make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILECubieboard2_defconfigmake -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILE
aint there a makefile with a proper target? Also how to build these cross compilers?
Quoted 1 line
Let me know if you need more indications on this.
yes, please. best a complete runnable script, aka a _working_ 5-10 liner, not the fancy one with variations, rebuilds and running debbindiff. Just the above "4 lines in working" - (those 4 lines dont work cause the variables are not defined...)
cheers,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150719/03b3da11/attachment.sig>
PATCH 1/1 build: create time and date independent binary
Le dimanche 19 juillet 2015 ? 17:47 +0200, Holger Levsen a ?crit :
Quoted 11 lines
Quoted 9 lines
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 forceI 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.
these hosts also need maintenance so I actually prefer the first.
I understand. We could raise the topic on the U-Boot mailing list and see whether adding the scripts to build the cross-compilers tu U-Boot would be doable or not.
Otherwise, we can just grab those scripts aside the U-Boot source code for the reproducible task, so that we don't have to wait for a long discussion to conclude.
Quoted 9 lines
Quoted 6 lines
The basics for building U-Boot are the following (e.g. for the Cubieboard2 target)
git clonegit://git.denx.de/u-boot.git
cd u-boot
make -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILECubieboard2_defconfigmake -C $SRC O=$DST CROSS_COMPILE=$CROSS_COMPILEaint there a makefile with a proper target? Also how to build these cross compilers?
I am using those scripts, that I wrote:
http://git.paulk.fr/gitweb/?p=embedded-freedom-scripts.git;a=tree;f=u-boot;h=f735bc015b056c3b63a0144703d7f7168382ca59;hb=HEAD
That can help but is not really usable as-is.
Quoted 6 lines
Quoted 1 line
Let me know if you need more indications on this.
yes, please. best a complete runnable script, aka a _working_ 5-10 liner, not the fancy one with variations, rebuilds and running debbindiff. Just the above "4 lines in working" - (those 4 lines dont work cause the variables are not defined...)
I could do that, but we have to figure out the toolchain issue first, I suppose.
Signature · 16 lines
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/76224846/attachment.sig>
PATCH 1/1 build: create time and date independent binary
In reply to Paul KocialkowskiHello Paul,
Am 12.06.2015 22:21, schrieb Paul Kocialkowski:
Quoted 7 lines
Le vendredi 12 juin 2015 ? 17:31 +0200, Heiko Schocher a ?crit :
Quoted 5 lines
With this option enabled each compilation creates the exact same binary. There are no timestamps, with which a U-Boot binary can be identified.
This option is disabled by default.
Quoted 7 lines
I think a bit more is needed to get truly reproducible builds in U-Boot, but this is a first good step!
I have been thinking about bringing reproducible builds to U-Boot for a little while, but never got around actually doing it. Are you interested in helping me on that? I have some free time these days, so I could do some work on this.
Hmm.. define what is a "reproducible build" ... my patch produces always the same u-boot binary if you not change the toolchain ...
Quoted 5 lines
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!
Yep, that would be helpful ...
bye,
Heiko
Quoted 53 lines
Quoted 52 lines
Signed-off-by Heiko Schocher <[email protected]>---
Kconfig | 9 +++++++++ Makefile | 8 ++++++++ 2 files changed, 17 insertions(+)Kconfig +9
-0@@ -81,6 +81,15 @@ menuconfig EXPERT Only use this if you really know what you are doing. if EXPERT + config SYS_EXACT_BINARY + bool "Create time and date independent binary" + default n + help + With this option enabled each compilation creates the exact + same binary. There are no timestamps, with which a U-Boot + binary can be identified. + This option is disabled by default. + config SYS_MALLOC_CLEAR_ON_INIT bool "Init with zeros the memory reserved for malloc (slow)" default yMakefile +8
-0@@ -1230,11 +1230,19 @@ define filechk_version.h echo \#define LD_VERSION_STRING \"$$($(LD) --version | head -n 1)\"; ) endef +ifeq ($(CONFIG_SYS_EXACT_BINARY),y) +define filechk_timestamp.h + (LC_ALL=C date +'#define U_BOOT_DATE "NODATE"'; \ + LC_ALL=C date +'#define U_BOOT_TIME "NOTIME"'; \ + LC_ALL=C date +'#define U_BOOT_TZ "NOTZ"') +endef +else define filechk_timestamp.h (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ LC_ALL=C date +'#define U_BOOT_TZ "%z"') endef +endif $(version_h): include/config/uboot.release FORCE $(call filechk,version.h)
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 build: create time and date independent binary
In reply to Heiko SchocherQuoted 3 lines · Heiko Schocher
With this option enabled each compilation creates the exact same binary. There are no timestamps, with which a U-Boot binary can be identified.
Works on usbarmory.