Re: [Reproducible-builds] [coreboot] coreboot reproducible builds almost there

2015-06-13 Thread Holger Levsen
Hi,

On Donnerstag, 11. Juni 2015, Patrick Georgi wrote:
> > Things is, _AIUI_, there is no common payload which can be enabled for
> > all boards. Is that correct?
> The one that should run everywhere is Google's depthcharge, and that
> isn't hooked up to the build system like SeaBIOS is (and even
> depthcharge isn't available for emulation/qemu-riscv). So you're
> correct, there is no single payload for every board.

ok.
 
> Since we select default payloads in our Kconfig rules (seabios for
> x86), I guess we should start doing the same for other architectures.
> I don't think that belongs in your test script - things might change
> in the future, and that shouldn't require additional effort on your
> part.

agreed :)

> We'll work on that, and will tell you once there's a plan and/or
> implementation.

cool, thanks.

That said, as the current tests have reached 100%, I'm thinking about removing 
the "--payloads none" switch again now already, so that then some images have 
payloads and some not.
 
> > And then I'm wondering, "what next"? AIUI you don't ever offer images for
> > download and instead expect users to build coreboot themselves. So the
> > whole topic of verifying and reproducing the vendors (=your!) binaries
> > is a bit mood here, at least atm. Any comments on that?
> 
> There are distributions, sort of.
> Google ships coreboot as part of Chrome OS (which requires a huge
> build system even to build just coreboot).
> Then there's libreboot (www.libreboot.org), which ships their
> coreboot-variant (without blobs and with as few patches against
> coreboot as possible) with GRUB2 as payload for a small selection of
> boards that they can support.
> There are also some other vendors, but they're less visible.

Hm. I guess I will leave it here for the moment, hoping that someone will pick 
up the task of verifying actually released and downloadable images...
 
> If you want to support coreboot distributions (that ship binaries),
> libreboot is currently your best bet.

added as question to my TODO :)

> > Last, and probably least: currently the headline of the page says "fast,
> > flexible and reproducible Open Source firmware_?_" which I felt was
> > appropriate when only a few images with payload were reproducible.
> Oh, I loved it, still do! At some point we should replace the question
> mark with an exclamation mark, though :-)

:-)

I've change the code to exchange the question mark against an exclaimation 
mark if 100% are reached... :)
 
> > Oh, and as the page says, it's currently only updated once a month and on
> > demand, so please do ping me if you merged some reproducible changes into
> > master!
> Thanks, will do. Let's start immediately :-)


> Since you mentioned 'once we reach 100% (without payloads)' earlier:
> the issue of the remaining 7 non-reproducible board should be fixed
> since today, in response to your report. I'd appreciate if you could
> do another run to verify this.

https://jenkins.debian.net/view/reproducible/job/reproducible_coreboot/44/console
 
has just finished and https://reproducible.debian.net/coreboot/coreboot.html 
now says "248 (100.0%) out of 248 built coreboot images were reproducible in 
our test setup" - kudos!!


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] [coreboot] coreboot reproducible builds almost there

2015-06-11 Thread Paul Menzel
Dear coreboot and reproducible build folks,


Am Donnerstag, den 11.06.2015, 21:58 +0200 schrieb Patrick Georgi:
> 2015-06-11 10:25 GMT+02:00 Holger Levsen :

[…]

> > Last, and probably least: currently the headline of the page says 
> > "fast, flexible and reproducible Open Source firmware_?_" which I 
> > felt was appropriate when only a few images with payload were 
> > reproducible.
>
> Oh, I loved it, still do! At some point we should replace the 
> question mark with an exclamation mark, though :-)
>
> > Oh, and as the page says, it's currently only updated once a month 
> > and on demand, so please do ping me if you merged some reproducible
> > changes into master!
>
> Thanks, will do. Let's start immediately :-)
> Since you mentioned 'once we reach 100% (without payloads)' earlier:
> the issue of the remaining 7 non-reproducible board should be fixed
> since today, in response to your report. I'd appreciate if you could
> do another run to verify this.

Patrick, thanks a lot for submitting patches to fix the remaining
issues. With 4.0-9975-g1f38d79 only one board is listed [1] as not
reproducible buildable and that is Google Urara [2].

-3  0020:  009a 0799 afe7 009b 1d3c 0020 bd27  ...<. .'
+3  0020:  009a 0719 ae47 009b 1d3c·0020·bd27  ...G...<. .'


Thanks,

Paul


[1] https://reproducible.debian.net/coreboot/coreboot.html
[2] https://reproducible.debian.net/coreboot/dbd/google_urara.html

signature.asc
Description: This is a digitally signed message part
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] [coreboot] coreboot reproducible builds almost there

2015-06-11 Thread Patrick Georgi
2015-06-11 10:25 GMT+02:00 Holger Levsen :
> I'm now wondering how to proceed further. I *believe* another set of tests,
> this time with payloads, would be useful, if only to prove that the
> combination "reproducible coreboot" plus "reproducible payload" also is
> reproducible.
>
> Things is, _AIUI_, there is no common payload which can be enabled for all
> boards. Is that correct?
The one that should run everywhere is Google's depthcharge, and that
isn't hooked up to the build system like SeaBIOS is (and even
depthcharge isn't available for emulation/qemu-riscv). So you're
correct, there is no single payload for every board.

> If it is, is there another way to sensible group targets by payloads or detect
> sensible ones? Currently I'm building all targets in one pass using abuild,
> but I could also loop through each target and build it individually, as long
> as I dont have to configure 247 different configurations... (rather easy would
> be, all i386 targets use seabios, all mips target $that_one and all arm
> targets $another_one...
Since we select default payloads in our Kconfig rules (seabios for
x86), I guess we should start doing the same for other architectures.
I don't think that belongs in your test script - things might change
in the future, and that shouldn't require additional effort on your
part.

We'll work on that, and will tell you once there's a plan and/or implementation.

> And then I'm wondering, "what next"? AIUI you don't ever offer images for
> download and instead expect users to build coreboot themselves. So the whole
> topic of verifying and reproducing the vendors (=your!) binaries is a bit mood
> here, at least atm. Any comments on that?
There are distributions, sort of.
Google ships coreboot as part of Chrome OS (which requires a huge
build system even to build just coreboot).
Then there's libreboot (www.libreboot.org), which ships their
coreboot-variant (without blobs and with as few patches against
coreboot as possible) with GRUB2 as payload for a small selection of
boards that they can support.
There are also some other vendors, but they're less visible.

If you want to support coreboot distributions (that ship binaries),
libreboot is currently your best bet.

> Last, and probably least: currently the headline of the page says "fast,
> flexible and reproducible Open Source firmware_?_" which I felt was
> appropriate when only a few images with payload were reproducible.
Oh, I loved it, still do! At some point we should replace the question
mark with an exclamation mark, though :-)

> Oh, and as the page says, it's currently only updated once a month and on
> demand, so please do ping me if you merged some reproducible changes into
> master!
Thanks, will do. Let's start immediately :-)
Since you mentioned 'once we reach 100% (without payloads)' earlier:
the issue of the remaining 7 non-reproducible board should be fixed
since today, in response to your report. I'd appreciate if you could
do another run to verify this.


Regards,
Patrick

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


Re: [Reproducible-builds] [coreboot] coreboot reproducible builds almost there

2015-06-11 Thread Holger Levsen
Dear coreboot folks,

adding the Debian reproducible-builds lists to cc: - please either cc: that 
list or me on replies, i'm not subscribed to the coreboot list.

On Donnerstag, 11. Juni 2015, Paul Menzel wrote:
> Holger Levsen joined #coreb...@irc.freenode.net yesterday to report that
> he integrated coreboot into the reproducible builds infrastructure [1].

indeed :) Thanks for sharing this here!

I'm now wondering how to proceed further. I *believe* another set of tests, 
this time with payloads, would be useful, if only to prove that the 
combination "reproducible coreboot" plus "reproducible payload" also is 
reproducible.

Things is, _AIUI_, there is no common payload which can be enabled for all 
boards. Is that correct?

If it is, is there another way to sensible group targets by payloads or detect 
sensible ones? Currently I'm building all targets in one pass using abuild, 
but I could also loop through each target and build it individually, as long 
as I dont have to configure 247 different configurations... (rather easy would 
be, all i386 targets use seabios, all mips target $that_one and all arm 
targets $another_one...


And then I'm wondering, "what next"? AIUI you don't ever offer images for 
download and instead expect users to build coreboot themselves. So the whole 
topic of verifying and reproducing the vendors (=your!) binaries is a bit mood 
here, at least atm. Any comments on that?

Last, and probably least: currently the headline of the page says "fast, 
flexible and reproducible Open Source firmware_?_" which I felt was 
appropriate when only a few images with payload were reproducible. Now I've 
been thinking about removing the questionmark, but in a way I like to keep it, 
til you reached 100% (without payloads) - do you think thats "ok"? IOW: do you 
feel offended (or maybe just a bit "hmm") by the questionmark or do you see it 
as motivation (to reach 100%)? ;-)

Oh, and as the page says, it's currently only updated once a month and on 
demand, so please do ping me if you merged some reproducible changes into 
master!


Thanks for your work on coreboot - it's really awesome & amazing! Free the 
hardware! :-)


cheers,
Holger, happy about any feedback basically. coreboot.html is *your* 
page, not mine! :-)


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] [coreboot] coreboot reproducible builds almost there

2015-06-11 Thread Paul Menzel
Dear coreboot folks,


Am Donnerstag, den 26.02.2015, 17:23 +0200 schrieb Emilian Bold:

> I was trying to duplicate a coreboot build back in November and I noticed I
> couldn't get my ROM file to be identical to the one I found online.
> 
> It seems that coreboot doesn't have reproducible builds yet.
> 
> Debian has been looking into this for a while
> https://wiki.debian.org/ReproducibleBuilds and I think coreboot should
> adopt this concept.

[…]

Holger Levsen joined #coreb...@irc.freenode.net yesterday to report that
he integrated coreboot into the reproducible builds infrastructure [1].

After configuring the used build script [2] to build without a payload,

nice ionice -c 3 \
bash util/abuild/abuild --payloads none || true # don't fail 
the full job just because some targets fail

it looks like most boards are passing the test now [1]. Big thanks to
Alexander (lynxis) for submitting the necessary patches!

The only exceptions are the six boards below.

  * a-trend_atc-6220 (256K) is unreproducible.
  * a-trend_atc-6240 (256K) is unreproducible.
  * google_nyan (4096K) is unreproducible.
  * google_nyan_big (4096K) is unreproducible.
  * google_rush (4096K) is unreproducible.
  * google_rush_ryu (8192K) is unreproducible.

Also, as a side node, SeaBIOS also supports to be built reproducible
since commit 624e8127 (build: Support "make VERSION=xyz" to override the
default build version) [3], though not by default.

So the coreboot build system, building the SeaBIOS payload, would need
to be adapted, if a reproducible build with the SeaBIOS payload is
required.


Thanks,

Paul


[1] https://reproducible.debian.net/coreboot/coreboot.html
[2] 
http://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_coreboot.sh
[3] http://seabios.org/pipermail/seabios/2015-June/009253.html


signature.asc
Description: This is a digitally signed message part
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds