[reproducible-website] 01/01: fix formatting: buildinfofiles

Tue Mar 14 11:36:39 UTC 2017

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

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

commit f13af61a0cdbaf8e600b525307e88ec0aedbb276
Author: Daniel Shahaf <danielsh at apache.org>
Date:   Tue Mar 14 11:31:37 2017 +0000

    fix formatting: buildinfofiles
---
 _events/berlin2016/agenda.md         |  2 +-
 _events/berlin2016/buildinfofiles.md | 78 +++++++++++++++++++-----------------
 2 files changed, 43 insertions(+), 37 deletions(-)

diff --git a/_events/berlin2016/agenda.md b/_events/berlin2016/agenda.md
index 8cde486..68726fa 100644
--- a/_events/berlin2016/agenda.md
+++ b/_events/berlin2016/agenda.md
@@ -59,7 +59,7 @@ Day 2
 *    10.00 Opening Session
 *    10:20 Working Sessions II
 
-     -   **build info files https://pad.riseup.net/p/reproduciblebuildsII-buildinfofiles**
+     -   **build info files [RPM]({{ "/events/berlin2016/RPM/" | prepend: site.baseurl }})**
      -   **RPM II https://pad.riseup.net/p/reproduciblebuildsII-RPMII https://github.com/woju/rpmbuildinfo**
      -   **Reproducible images https://pad.riseup.net/p/reproduciblebuildsII-reusableimages**
      -   **Defining reproducible builds I https://pad.riseup.net/p/reproduciblebuildsII-reproduciblebuildsdefinition**
diff --git a/_events/berlin2016/buildinfofiles.md b/_events/berlin2016/buildinfofiles.md
index 41d2853..ec014e5 100644
--- a/_events/berlin2016/buildinfofiles.md
+++ b/_events/berlin2016/buildinfofiles.md
@@ -1,84 +1,90 @@
 ---
 layout: event_detail
-title: buildinfofiles
+title: `.buildinfo` files
 event: berlin2016
 order: 90
 permalink: /events/berlin2016/buildinfofiles/
 ---
 
-= early work
+# Early work
 
-a goal was to minimise the conditions needed to reproduce a binary
+A goal was to minimise the conditions needed to reproduce a binary.
 
-buildinfo would be a formula to reproduce a build - it should be small as possible
+`.buildinfo` files ("buildinfo files") would be a formula to reproduce a build.  It should be small as possible.
 
-they don't/can't describe every possible input - build process is affected by obscure things or external, variable factors
+They don't/can't describe every possible input;
+[a] build process [can be] affected by obscure things or external, variable factors.
 
 1. buildinfo files:
-record inputs to the build that produced the output - so that you can recreate its state
+record inputs to the build that produced the output, so that you can recreate its state.
 
 2. analysis of buildinfo and outputs:
 as more builders provide buildinfo files, we can look for intersections (reproducible binaries), and causes of any differences (non-reproducibility)
 
-should contain the minimal information needed to produce a given binary
-
 3. the ideal (reproducible) build would depend only the source code and build dependencies
 
-buildinfo should be small, compact, and easily distributable
+buildinfo files should:
+
+- contain the minimal information needed to produce a given binary
+
+- be small, compact, and easily distributable
+
 
+# buildinfo files might contain:
 
-= they might contain:
+- source package (name, version, hash?)
+- binaries produced (name, arch, checksums)
+- build dependencies (recursively)
+- build path (until recently?)
+- environment variables (since recently?)
 
-source package (name, version, hash?)
-binaries produced (name, arch, checksums)
-build dependencies (recursively)
-build path (until recently?)
-environment variables (since recently?)
+In Debian, buildinfo is a separate file.
 
-in Debian, buildinfo is a separate file
-in Arch Linux, buildinfo is included in the package files (but signatures are detached)
+In Arch Linux, buildinfo is included in the package files (but signatures are detached).
 
 
-= consuming and aggregating buildinfo files:
+# Consuming and aggregating buildinfo files:
 
 in Debian, buildinfo files are used when:
+
   * DD uploads a package
   * debian-ftp system distributes packages
   * end-user installs packages
 
 and now we also realised:
+
   * rebuilders
   * buildinfo distributors
 
 
-= further work
+# Further work
 
-we want to collate and distribute buildinfo files from external parties too;
-not just those from Debian developers and the official builds
+We want to collate and distribute buildinfo files from external parties too;
+not just those from Debian developers and the official builds.
 
-collecting and distributing those, is a quite different task than just distributing buildinfo from Debian's official builds
+Collecting and distributing those, is a quite different task than just distributing buildinfo from Debian's official builds.
 
-lamby's buildinfo.debian.net already collects and distributes some non-official buildinfo files
+lamby's buildinfo.debian.net already collects and distributes some non-official buildinfo files.
 
-we will need to write tools making it easy to test reproducibile and submit buildinfo,
-and tools to retrieve buildinfo files/signatures when installing
+We will need to write tools making it easy to test [reproducibility] and submit buildinfo,
+and tools to retrieve buildinfo files/signatures when installing.
 
-signed buildinfos save people from having to build every package themselves -
-it gives them sufficient confidence to trust pre-built binaries
+Signed buildinfos save people from having to build every package themselves:
+it gives them sufficient confidence to trust pre-built binaries.
 
 
-= ongoing concerns
+# Ongoing concerns
 
-buildinfo files should to be detailed enough to explain the causes of non-reproducibility
+buildinfo files should to be detailed enough to explain the causes of non-reproducibility;
 but too much information ($HOME, hostname, installed packaged versions)
 
-argument arose that a normalised build environment evoids lots of reproducibility issues,
-like build path, environment etc. affecting the build
-whilst that would be easier, some of us think that is really a bug in the software that ought to be fixed
-
-in the extreme case, 
+An argument arose that a normalised build environment avoids lots of reproducibility issues,
+like build path, environment, etc., affecting the build.
+Whilst that would be easier, some of us think that is really a bug in the software that ought to be fixed.
 
-when a build-dependency affects an output binary, we may need to generate a new set of buildinfo files
-describing that situation
+In the extreme case, 
+when a build-dependency affects an output binary,
+we may need to generate a new set of buildinfo files
+describing that situation.
 
 -

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

