[reproducible-website] 01/02: fix formatting for 'definition of r-b I+II'

Holger Levsen holger at layer-acht.org
Wed Mar 15 10:39:44 UTC 2017


This is an automated email from the git hooks/post-receive script.

holger pushed a commit to branch master
in repository reproducible-website.

commit d0c30e5a7c547ba82ba5f237f2939ea19b4129ae
Author: Holger Levsen <holger at layer-acht.org>
Date:   Wed Mar 15 11:39:17 2017 +0100

    fix formatting for 'definition of r-b I+II'
    
    Signed-off-by: Holger Levsen <holger at layer-acht.org>
---
 _events/berlin2016/agenda.md                       |  4 +-
 _events/berlin2016/reproduciblebuildsdefinition.md | 78 +++++++++++-----------
 .../berlin2016/reproduciblebuildsdefinitionII.md   | 12 ++--
 3 files changed, 48 insertions(+), 46 deletions(-)

diff --git a/_events/berlin2016/agenda.md b/_events/berlin2016/agenda.md
index f587fbe..8f064c1 100644
--- a/_events/berlin2016/agenda.md
+++ b/_events/berlin2016/agenda.md
@@ -62,7 +62,7 @@ Day 2
      -   **[.buildinfo files]({{ "/events/berlin2016/buildinfofiles/" | prepend: site.baseurl }})**
      -   **[RPM II]({{ "/events/berlin2016/RPMII/" | prepend: site.baseurl }})**
      -   **[Reproducible images]({{ "/events/berlin2016/images/" | prepend: site.baseurl }})**
-     -   **Defining reproducible builds I https://pad.riseup.net/p/reproduciblebuildsII-reproduciblebuildsdefinition**
+     -   **[Defining Reproducible Builds I]({{ "/events/berlin2016/reproduciblebuildsdefinition/" | prepend: site.baseurl }})**
      -   **End user policies https://pad.riseup.net/p/reproduciblebuildsII-userpolicies**
      -   **Test infrastructure https://pad.riseup.net/p/reproduciblebuildsII-testinfrastructure**
      -   **Gettext https://pad.riseup.net/p/reproduciblebuildsII-Gettext**
@@ -94,7 +94,7 @@ Day 2
      -   **[What else]({{ "/events/berlin2016/whatelse/" | prepend: site.baseurl }})** instead of **[Binary Transparency]({{ "/events/berlin2016/binarytransparency/" | prepend: site.baseurl }})**
      -   **SOURCE_PREFIX_MAP https://pad.riseup.net/p/reproduciblebuildsII-SOURCE_PREFIX_MAP**
      -   **Documentation II https://pad.riseup.net/p/reproduciblebuildsII-documentationII**
-     -   **Defining reproducible builds II https://pad.riseup.net/p/reproduciblebuildsdefinitionII**
+     -   **[Defining Reproducible Builds definition II]({{ "/events/berlin2016/reproduciblebuildsdefinitionII/" | prepend: site.baseurl }})**
      -   **Bootstrapping https://pad.riseup.net/p/reproduciblebuildsII-bootstrapping**
      -   **Reproducible builds use cases https://pad.riseup.net/p/reproduciblebuildsII-usecases**
      -   **Reproducible builds and License/GPL compliance https://pad.riseup.net/p/rb-gpl-compliance-20161214**
diff --git a/_events/berlin2016/reproduciblebuildsdefinition.md b/_events/berlin2016/reproduciblebuildsdefinition.md
index 401dd00..ec23962 100644
--- a/_events/berlin2016/reproduciblebuildsdefinition.md
+++ b/_events/berlin2016/reproduciblebuildsdefinition.md
@@ -1,57 +1,58 @@
 ---
 layout: event_detail
-title: Reproducible Builds definition
+title: Defining Reproducible Builds I
 event: berlin2016
 order: 120
 permalink: /events/berlin2016/reproduciblebuildsdefinition/
 ---
 
-What's the definition of a reproducible build?
------------------------------------------------
+### What's the definition of a reproducible build?
 
 We agree on 3 factors:
 
-* Input - same source code.
-* Output - bit by bit identical output, verifiable by a checksum. But we
-need to define the output files, because a build can also generate
-debugging files or other output.
-* Environment - what's an environment? kernel, source tree, build path,
-versions of all installed packages. discussion about trust and shipping
-vms as build environments.
-
-
-We agree on saying that
-reproducible builds is
-----------------------
-* bit-by-bit identical
-* checksum verifiable
-* specified outputs
-* no specialized comparator (make stripping part of your build - output
+ * Input - same source code.
+ * Output - bit by bit identical output, verifiable by a checksum. But we
+   need to define the output files, because a build can also generate
+   debugging files or other output.
+ * Environment - what's an environment? kernel, source tree, build path,
+   versions of all installed packages. discussion about trust and shipping
+   VMs as build environments.
+
+
+We agree on saying that:
+
+### reproducible builds is:
+ * bit-by-bit identical
+ * checksum verifiable
+ * specified outputs
+ * no specialized comparator (make stripping part of your build - output
 must still be usable)
 
-We've set up an axis to define INPUTS (source and build environments)
+We've set up an axis to define INPUTS (source and build environments).
 
+<pre>
 Axis
 ----
 
 (the y-axis is "relevance", the x-axis is how hard it is to fix)
 
-*  same source code
-* build instructions (command line)
-* same environment configuration, build flags
-* dependencies and their versions
-* locations where dependencies are installed
-* pre-existing keys
+ *  same source code
+ * build instructions (command line)
+ * same environment configuration, build flags
+ * dependencies and their versions
+ * locations where dependencies are installed
+ * pre-existing keys
 
 ABOVE THIS LINE: Ideal reproducible build
--------------------------------------------------------------------------
+----
 BELOW THIS LINE LEFT: Minimal viable reproducible build
+
 ON THE RIGHT: these are things which should not be done
 
-* LOCALE
-* saved optimization metadata
-* build path prefix
-* SOURCE_EPOCH_DATE
+ * LOCALE
+ * saved optimization metadata
+ * build path prefix
+ * SOURCE_EPOCH_DATE
                                              * different person building
                                            * host dependent optimization
 
@@ -67,14 +68,15 @@ matter
                                                                                         
                                              * random data (/dev/random)
 
+</pre>
 
-The ideal reproducible build
-----------------------------
-* same source code
-* build instructions (command line)
-* same environment configuration, build flags
-* dependencies and their versions
-* locations where dependencies are installed
+### The ideal reproducible build
+ 
+ * same source code
+ * build instructions (command line)
+ * same environment configuration, build flags
+ * dependencies and their versions
+ * locations where dependencies are installed
 
 <img style="margin-top: 10px; vertical-align: top;" src="{{ "/images/berlin2016/reproduciblebuildsdefinition_01.jpg" | prepend: site.baseurl }}" alt="Reproducible Builds definition Post-It notes" />
 <img style="margin-top: 10px; vertical-align: top;" src="{{ "/images/berlin2016/reproduciblebuildsdefinition_02.jpg" | prepend: site.baseurl }}" alt="Reproducible Builds definition Post-It notes" />
diff --git a/_events/berlin2016/reproduciblebuildsdefinitionII.md b/_events/berlin2016/reproduciblebuildsdefinitionII.md
index 364f45f..cbab247 100644
--- a/_events/berlin2016/reproduciblebuildsdefinitionII.md
+++ b/_events/berlin2016/reproduciblebuildsdefinitionII.md
@@ -1,12 +1,12 @@
 ---
 layout: event_detail
-title: Reproducible Builds definition II
+title: Defining Reproducible Builds II
 event: berlin2016
 order: 200
 permalink: /events/berlin2016/reproduciblebuildsdefinitionII/
 ---
 
-# When is a build "reproducible"?
+### When is a build "reproducible"?
 A build is reproducible if, given the same source code, build environment and
 build instructions, any party can recreate bit-by-bit identical copies of all
 specified artifacts.
@@ -16,8 +16,8 @@ source code, as well as the expected reproducible artifacts, are defined by the
 authors. The artifacts of a build are the parts of the build results that are the
 desired primary output.
 
+### Examples Section (NOT part of the definition)
 
-## Examples Section (NOT part of the definition)
 Source code is usually a version control checkout at a specific revision or
 a source code archive.
 
@@ -36,17 +36,17 @@ usually achieved using checksums (better: strong/cryptographically secure hash f
 TODO Hyperlink me to other parts of the website!1!!
 
 #### Notes
+
 We've looked at the GNU discussion on the r-b@ list; we think our definition is
 a superset.
 
 Not bit-by-bit identical but similar (according to $algorithm) builds shall
 henceforth be referred to as "equivalent builds".
 
-//////////////////////////////////////////
 
-Update 20 Decmeber 2016:
+## Update 20 December 2016:
 
-Definition published at https://reproducible-builds.org/docs/definition/
+Definition published at [https://reproducible-builds.org/docs/definition/](https://reproducible-builds.org/docs/definition/)
 
 <img style="margin-top: 10px; vertical-align: top;" src="{{ "/images/berlin2016/reproduciblebuildsdefinitionII_01.jpg" | prepend: site.baseurl }}" alt="Reproducible Builds definition II Post-It notes" />
 <img style="margin-top: 10px; vertical-align: top;" src="{{ "/images/berlin2016/reproduciblebuildsdefinitionII_02.jpg" | prepend: site.baseurl }}" alt="Reproducible Builds definition II Post-It notes" />

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git



More information about the Reproducible-commits mailing list