[reproducible-website] 02/02: fix formatting

[Holger Levsen]

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

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

commit fbf3684c077e06613f366dabf9fa063fe9a84d3f
Author: Holger Levsen <holger at layer-acht.org>
Date:   Tue Mar 14 14:23:47 2017 +0100

    fix formatting
    
    Signed-off-by: Holger Levsen <holger at layer-acht.org>
---
 _events/berlin2016/agenda.md         |  2 +-
 _events/berlin2016/images.md         | 52 +++++++++++++++++++++++++++++++++
 _events/berlin2016/reusableimages.md | 56 ------------------------------------
 3 files changed, 53 insertions(+), 57 deletions(-)

diff --git a/_events/berlin2016/agenda.md b/_events/berlin2016/agenda.md
index 5670876..43ba260 100644
--- a/_events/berlin2016/agenda.md
+++ b/_events/berlin2016/agenda.md
@@ -61,7 +61,7 @@ Day 2
 
      -   **[.buildinfo files]({{ "/events/berlin2016/buildinfofiles/" | prepend: site.baseurl }})**
      -   **[RPM II]({{ "/events/berlin2016/RPMII/" | prepend: site.baseurl }})**
-     -   **Reproducible images https://pad.riseup.net/p/reproduciblebuildsII-reusableimages**
+     -   **[Reproducible images]({{ "/events/berlin2016/images/" | prepend: site.baseurl }})**
      -   **Defining reproducible builds I https://pad.riseup.net/p/reproduciblebuildsII-reproduciblebuildsdefinition**
      -   **End user policies https://pad.riseup.net/p/reproduciblebuildsII-userpolicies**
      -   **Test infrastructure https://pad.riseup.net/p/reproduciblebuildsII-testinfrastructure**
diff --git a/_events/berlin2016/images.md b/_events/berlin2016/images.md
new file mode 100644
index 0000000..7608b56
--- /dev/null
+++ b/_events/berlin2016/images.md
@@ -0,0 +1,52 @@
+---
+layout: event_detail
+title: Reproducible images
+event: berlin2016
+order: 110
+permalink: /events/berlin2016/images/
+---
+
+### agreed points:
+ * docker image, vagrant box, etc. are all just "packages"
+
+ * which container/VM does not matter for reproducibility
+ * it does matter for ease of use/setup
+
+ * perfect buildinfo is the goal
+ * intermediate steps can be useful
+
+
+
+### notes:
+
+ * bazel, build only from directly available sources, no net, into docker
+ * fdroid, vagrant to build up on VirtualBox
+ * mozilla/nix, build up images per task, never use a base image
+
+ * docker, AWS image, VirtualBox
+
+ * basel builds up debian/ubuntu docker images
+ * all source code, local and upstream, are checked into local source repo
+ * 5 base images, security and legal reviewed
+
+ * nix could do base images, but don't see the need yet.
+ * could be used for caching to speed things up
+
+ * with certain compilers (e.g. javac), wide variations can produce the same thing
+ * can't be a buildinfo dependency, too hard to deal with problems
+
+ * tools for specifying buildinfo
+ * blaze forces central build infrastructure, so forces standard build envs
+ * nix is a build tool first, and incidentally a package manager
+
+ * Debian images can be reproducible using snapshots, specify date to snapshots in /etc/apt/sources.list
+
+ * it is possible to not require full buildinfo in advance, if there is a reproducible base image that builds against user input, and it reproduces any given user submitted build, then that can also generate the buildinfo
+
+### what are the benefits of bit-perfect reproducible
+
+ * more effective caching
+ * security audits, easy to track binaries to find original source
+ * catching bugs by finding unexpected changes
+
+-
diff --git a/_events/berlin2016/reusableimages.md b/_events/berlin2016/reusableimages.md
deleted file mode 100644
index 44cc8c5..0000000
--- a/_events/berlin2016/reusableimages.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-layout: event_detail
-title: reusableimages
-event: berlin2016
-order: 110
-permalink: /events/berlin2016/reusableimages/
----
-
-agreed points:
-* docker image, vagrant box, etc. are all just "packages"
-
-* which container/VM does not matter for reproducibility
-* it does matter for ease of use/setup
-
-* perfect buildinfo is the goal
-* intermediate steps can be useful
-
-
-
-notes:
-
-* bazel, build only from directly available sources, no net, into docker
-* fdroid, vagrant to build up on VirtualBox
-* mozilla/nix, build up images per task, never use a base image
-
-* docker, AWS image, VirtualBox
-
-* basel builds up debian/ubuntu docker images
-* all source code, local and upstream, are checked into local source repo
-* 5 base images, security and legal reviewed
-
-* nix could do base images, but don't see the need yet.
-* could be used for caching to speed things up
-
-* with certain compilers (e.g. javac), wide variations can produce the
-same thing
-* can't be a buildinfo dependency, too hard to deal with problems
-
-* tools for specifying buildinfo
-* blaze forces central build infrastructure, so forces standard build envs
-* nix is a build tool first, and incidentally a package manager
-
-* Debian images can be reproducible using snapshots, specify date to
-snapshots in /etc/apt/sources.list
-
-* it is possible to not require full buildinfo in advance, if there is a
-reproducible base image that builds against user input, and it
-reproduces any given user submitted build, then that can also generate
-the buildinfo
-
-what are the benefits of bit-perfect reproducible
-* more effective caching
-* security audits, easy to track binaries to find original source
-* catching bugs by finding unexpected changes
-
--

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