[Reproducible-commits] [reproducible-builds-howto] 01/01: explain this has been moved to https://reproducible-builds.org/website.git
Holger Levsen
holger at moszumanska.debian.org
Mon Nov 9 14:36:42 UTC 2015
This is an automated email from the git hooks/post-receive script.
holger pushed a commit to branch master
in repository reproducible-builds-howto.
commit d5eafd04806b9e7b5e8cca4d33310c70ecadc85d
Author: Holger Levsen <holger at layer-acht.org>
Date: Mon Nov 9 15:36:36 2015 +0100
explain this has been moved to https://reproducible-builds.org/website.git
---
Makefile | 17 --
README | 6 +
reproducible-builds-howto.mdwn | 169 --------------------
style.css | 354 -----------------------------------------
4 files changed, 6 insertions(+), 540 deletions(-)
diff --git a/Makefile b/Makefile
deleted file mode 100644
index f2aac75..0000000
--- a/Makefile
+++ /dev/null
@@ -1,17 +0,0 @@
-all: html
-
-reproducible-builds-howto.html: reproducible-builds-howto.mdwn
- pandoc --standalone -f markdown -t html \
- --css=style.css \
- --number-sections \
- --table-of-contents \
- --output $@ $<
-
-html: reproducible-builds-howto.html style.css
- mkdir -p html
- cp style.css html
- cp reproducible-builds-howto.html html/index.html
-
-clean:
- rm -rf html
- rm -f reproducible-builds-howto.html
diff --git a/README b/README
new file mode 100644
index 0000000..dc8d6de
--- /dev/null
+++ b/README
@@ -0,0 +1,6 @@
+This HowTo has been moved to
+
+git clone https://reproducible-builds.org/website.git
+cd website
+cd _docs
+
diff --git a/reproducible-builds-howto.mdwn b/reproducible-builds-howto.mdwn
deleted file mode 100644
index bbcbd1c..0000000
--- a/reproducible-builds-howto.mdwn
+++ /dev/null
@@ -1,169 +0,0 @@
-% How to make your software reproducible?
-% Debian reproducible builds squad <reproducible-builds at lists.alioth.debian.org>
-% 2015-07-16
-
-> This document is still a work-in-progress. Please help!
->
-> git clone https://anonscm.debian.org/git/reproducible/reproducible-builds-howto.git
->
-> The talk given at CCCamp15 on this topic might contain information not yet in this document. [Recordings](https://media.ccc.de/browse/conferences/camp2015/camp2015-6657-how_to_make_your_software_build_reproducibly.html), [slides](https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15.pdf) and [script](https://reproducible.alioth.debian.org/presentations/2015-08-13-CCCamp15-outline.pdf) are available for download.
-
-The idea of “reproducible” builds is to empower anyone to verify that no flaws have been introduced during the build process by reproducing byte-for-byte identical binary packages from a given source.
-
-Achieving reproducible builds require cooperation from multiple roles involved in software production. On small projects, all these roles might be carried by a single person, but it helps to differentiate the responsibilities.
-
-In order for software to allow reproducible builds, the source code might not introduce uncontrollable variations in the build output. To enable meaningful comparison of different builds, the build environment must be reproducible, although it is not required that the toolchain[^toolchain] itself be byte-for-byte identical, as long as its output stays the same. When distributed in its binary form, the build environment used to transform the source should also be distributed, ideally in a [...]
-
-[^toolchain]: By *toolchain*, we mean any piece of software needed to create the build output.
-
-Common issues affecting source code and build systems
-=====================================================
-
-A software cannot be easily be built reproducibly if the source varies depending on factors that are hard or impossible to control like the ordering of files on a filesystem or the current time. What follows are some advices on common issues that can affect source code or build systems that makes multiple builds from the exact same source different.
-
-Volatile inputs can disappear
------------------------------
-
-A file on a webserver could go away anytime.
-
-If you need to rely on something the network will give you: save it in a fallback location you control, and use a cryptographic hash to verify that the content stayed the same.
-
-Stable order for inputs
------------------------
-
-If building your software requires processing several inputs at once, make sure the order is stable accross builds.
-
-A typical example is creating an archive from the content of a directory. Most filesystems do not guarantee that listing files in a directory will always result in the same order.
-
-Bad example[^sorted-wildcard]:
-
- SRCS = $(wildcard *.c)
- tool: $(SRCS:.c=.o)
- $CC) -o $@ $^
-
-Solutions:
-
-a) List all inputs explicitely and ensure they will be processed in that order.
-
- SRCS = util.c helper.c main.c
- tool: $(SRCS:.c=.o)
- $CC) -o $@ $^
-
-b) Sort inputs:
-
- SRCS = $(sort $(wildcard *.c))
- tool: $(SRCS:.c=.o)
- $CC) -o $@ $^
-
-[^sorted-wildcard]: GNU Make used to sort the output of the [wildcard](https://www.gnu.org/software/make/manual/html_node/Wildcard-Function.html#Wildcard-Function) function until version 3.82.
-
-When sorting inputs, one must ensure that the sorting order is not affected by
-the system locale settings. For example, some locale will not make differences
-between uppercase and lowercase.
-
-Bad example:
-
- $ tar -cf archive.tar src
-
-Solution:
-
- $ find src -print0 | LC_ALL=C sort -z | tar --null -T - --no-recursion -cf archive.tar
-
-Stable order for outputs
-------------------------
-
-Data structures such as [Perl hashes](http://perldoc.perl.org/functions/keys.html), [Python dictionaries](https://docs.python.org/2/library/stdtypes.html#mapping-types-dict), or [Ruby Hash objects](http://ruby-doc.org/core/Hash.html) will list their keys in a different order on every run to limit [algorithmic complexity attacks](http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks).
-
-To get a deterministic output, the easiest way is to explicitely sort the keys. Again, watch out for the locale affecting the sort order.
-
-Bad:
-
- foreach my $package (keys %deps) {
- print MANIFEST, "$package: $deps[$packages]";
- }
-
-Good:
-
- foreach my $package (sort keys %deps) {
- print MANIFEST, "$package: $deps[$packages]";
- }
-
-For Perl, it is possible to set `PERL_HASH_SEED=0` in the environment. This will result in hash keys always being in the same order. See [perlrun(1)](http://perldoc.perl.org/perlrun.html) for more information.
-
-Python users can similarily set the environment variable [PYTHONHASHSEED](https://docs.python.org/2/using/cmdline.html#envvar-PYTHONHASHSEED). When set to a given integer value, orders in dictionnaries will be the same on every run.
-
-Controlled value initialization
--------------------------------
-
-In languages which don't initialize values, this needs to be explicitely done in order to avoid capturing what random bytes are in memory when run.
-
-[Example fix](http://review.coreboot.org/gitweb?p=coreboot.git;a=commitdiff;h=2d119a3f01eee6c4e86248b17b4c9ce14ab77836)
-
-Use deterministic version information
--------------------------------------
-
-If the software needs to know version information, make them deterministic. A version number can come from a dedicated source file, a changelog, or from a version control system. If a date and time is needed, extract it from a changelog or the version control system.
-
-The date and time of the build is not useful information as one can always build an old version long after it has been released.
-
-XXX: add examples
-
-Use a known date and time
--------------------------
-
-If you need timestamps, extract a date and time from a changelog or the version control system instead of using the current date and time.
-
-Another option is to implement support for the `SOURCE_DATE_EPOCH` environment variable. When set, its value —a number of seconds since January 1st 1970, 00:00 UTC— should be used instead of using the current date and time.
-
-Timestamps can creep in many unexpected places, but file modification times in archives might be the most common trap.
-
-Watch out for timestamps in archives
-------------------------------------
-
-Most archive formats will record the latest modification time of every files in their metadata. If files added to the archive are created during the build process, the archive will differ from one build to the next.
-
-Some tools will allow to specify a specific timestamp on the command line (e.g. Tar has `--mtime`) to solve this. In all cases, it is possible to set the modification time (`touch`) of the files before adding them to an archive. XXX: link to previous section
-
-Static libraries (`.a`) on Unix-like systems are archives. XXX: document binutils `--enable-deterministic-archives`.
-
-Avoid true randomness
----------------------
-
-Don't ship any data created using properly random sources. Avoid using random data if possible. If not, use a known value as the PRNG seed. For example, extract a value using a hash of some file content, a changelog or the version control system.
-
-When using GCC, you might one to specify `-frandom-seed` if you use feature like Link-Time Optimization. Intermediate files might be created using temporary file names which will be written in debug symbols. Using `-save-temps` will make these names deterministic.
-
-Define environment variables affecting outputs
-----------------------------------------------
-
-Some environment variables might affect some tools output. A common example is the `LC_CTIME` environment variable which affects the format of dates.
-
-While someone building your software might want to see build error messages in their preferred language, it is better to have the output always be in the same format.
-
-Don't record information about the build environment
-----------------------------------------------------
-
-Avoid recording any information related to the compilation process in the software being distributed. This includes information such as date and time of the build, build system hostname, path, network configuration, CPU type, memory size, environment variables. Instead make sure that variations in these parameters do not affect the build products or make them stable as part of your controlled build environment. XXX add link
-
-If you really want to record it, it should be in a separate build product that can be easily ignored or distributed separately—eventualy as a way to reproduce the build environment. XXX: add link
-
-One caveat though: build paths are often recorded in debug information by compilers in order to locate the associated source files. For the specific case of DWARF files, there is currently no good tool to change them after a build to a pre-determined value. A work-around is to define the build path as part of the build environment.
-
-Reproducible build environment
-==============================
-
-The output of a tool building software is likely to be different from one version to another. Typically, better optimizations are integrated into compilers all the time. To allow different builds to be easily compared, there must be a way to know which software versions to (re)use.
-
-Other aspects of the environment affecting the output of the compilation tools must be either set or recorded so they can be reproduced as well.
-
-XXX: explain how
-
-Distributing the build environment
-==================================
-
-XXX: explain how to tie source+build env+resulting binary and distributing it.
-
-Acknowledgements
-================
-
-David A. Wheeler and his fantastic work on [Diverse Double-Compilation](http://www.dwheeler.com/trusting-trust/).
diff --git a/style.css b/style.css
deleted file mode 100644
index 91189d9..0000000
--- a/style.css
+++ /dev/null
@@ -1,354 +0,0 @@
-html {
- font-size: 100%;
- -webkit-text-size-adjust: 100%;
- -ms-text-size-adjust:100%;
- height:100%;
-}
-
-body {
- border-sizing: border-box;
- font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
- font-size: 14px;
- line-height: 20px;
- color: #333333;
- padding: 0em 1em 0em 1em;
- margin: 0;
- height: 93%;
-}
-
-pre {
- overflow: auto;
-}
-
-img {
- vertical-align: middle;
- max-width: 100%;
- height: auto;
-}
-
-img.halfview {
- max-width: 49%;
-}
-
-img.overview {
- max-width: 32%;
-}
-
-img.metaoverview {
- max-width: 3.0%;
-}
-
-.beta {
- color:#555555;
- font-size:0.8em;
-}
-
-a, a.package {
- color:#0088cc;
- text-decoration:none;
-}
-
-a.noted {
- color:#0088cc;
- font-weight: bold;
-}
-
-a:hover, a:focus, a.package:hover, a.package:focus {
- color:#005580;
- text-decoration:underline;
-}
-
-a.noted:hover, a.noted:focus {
- color:#005580;
- text-decoration:underline;
- font-weight: bold;
-}
-
-a.package:visited, a.noted:visited {
- color:green;
-}
-
-header {
- border-bottom: 1px solid #d70a53;
-}
-
-footer {
- text-align: center;
- margin-top: 1em;
-}
-
-ul, ol {
- padding-left: 0;
-}
-
-ul ul, ol ol {
- padding-left: 1.5em;
-}
-
-ul, li {
- list-style: none;
-}
-
-ul li a {
- background: #fafafa;
- border: 1px solid #ddd;
- margin: 0 0.5em 0.3em 0;
- border-radius: 0.5em;
- padding: 0.15em 0.5em;
- line-height: 1.5em;
- display: block;
-}
-
-nav ul li {
- display: block;
-}
-
-nav ul li a {
- background: none;
- border: none;
- padding: 0;
-}
-
-h1 {
- font-size : 250%;
- padding: 0;
- margin: 0;
- margin-right: 260px;
- line-height: 1.4em;
-}
-
-h2 {
- font-size : 110%;
- background: #d70a53;
- margin: 0.25em 0 0;
- padding: 0.5em;
- color: #fff;
- border-radius: 0.5em;
-}
-
-h2 a {
- color: #fff;
-}
-
-#header h2 {
- color: black;
- background: none;
-}
-
-#header .date {
- margin: 0.25em 0 0;
- padding: 0 0.5em;
-}
-
-h3 {
- font-size : 110%;
-}
-
-table {
- counter-reset: rowNumber; /* used for automatic row count with CSS */
- border: 1px solid #ddd;
- border-radius: 0.5em;
- border-collapse: collapse;
- box-shadow: 0 1px 3px #eee;
- padding: 0
-}
-
-table.head {
- width: 100%;
- margin: 0;
- border-top: 0;
- border-left: 0;
- border-right: 0;
-}
-
-table.body {
- margin: 0.75em 0.25em 0em 0em;
-}
-
-table.main {
- margin: 0.75em 0.25em 0.25em 0.75em;
- float: left;
- display: inline-block;
-}
-
-tr:nth-child(odd) {
- background-color: #fafafa;
-}
-
-/* automatic row count with CSS */
-table.scheduled tr:not(:first-child) {
- counter-increment: rowNumber;
-}
-table.scheduled tr td:first-child::before {
- content: counter(rowNumber);
- min-width: 1em;
- margin-right: 0.5em;
-}
-/* end automatic row count with CSS */
-
-a.bug-patch:after {
- content: "+";
- color: #cc0000;
- font-weight: bold;
-}
-
-a.bug-done {
- text-decoration: line-through;
- color: #73d216;
- font-weight: bold;
-}
-
-span.bug {
- color: #cc0000;
- font-weight: bold;
-}
-
-span.bug-patch {
- color: #f57900;
- font-weight: bold;
-}
-
-span.bug-done {
- text-decoration: line-through;
- color: #73d216;
- font-weight: bold;
-}
-
-td, th {
- text-align: left;
- padding: 0.25em 0.5em;
- border-bottom: 1px solid #ddd;
- border-collapse: collapse;
- vertical-align: top;
-}
-
-table tr:last-child td {
- border: none;
-}
-
-th {
- background: #eee;
- padding: 0.5em;
-}
-
-table:target th {
- background: #ffb;
-}
-
-
-
-iframe#main {
- margin: 0;
- width: 100%;
- height: 100%;
- border: 0;
-}
-
-hr {
- border-top: none;
- border-bottom: 1px solid #d70a53;
- margin-bottom: 1em;
-}
-
-form {
- overflow: hidden;
- margin: 1em 0;
-}
-
-#searchform {
- text-align: center;
- padding: 1em 0;
- border-top: 1px solid #ddd;
- border-bottom: 1px solid #ddd;
-}
-
-label {
- cursor: pointer;
- display: inline-block;
-}
-
-input[type="text"] {
- background: #fff;
- border: 1px solid #ddd;
- padding: 0.25em;
- border-radius: 0.3em;
-}
-
-input[type="submit"] {
- cursor: pointer;
- padding: 0.25em 0.5em;
- border-radius: 0.3em;
- border: 1px solid #ddd;
- background: rgb(226,226,226); /* Old browsers */
- background: -moz-linear-gradient(top, rgba(226,226,226,1) 0%, rgba(219,219,219,1) 15%, rgba(209,209,209,1) 28%, rgba(254,254,254,1) 100%); /* FF3.6+ */
- background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(226,226,226,1)), color-stop(15%,rgba(219,219,219,1)), color-stop(28%,rgba(209,209,209,1)), color-stop(100%,rgba(254,254,254,1))); /* Chrome,Safari4+ */
- background: -webkit-linear-gradient(top, rgba(226,226,226,1) 0%,rgba(219,219,219,1) 15%,rgba(209,209,209,1) 28%,rgba(254,254,254,1) 100%); /* Chrome10+,Safari5.1+ */
- background: -o-linear-gradient(top, rgba(226,226,226,1) 0%,rgba(219,219,219,1) 15%,rgba(209,209,209,1) 28%,rgba(254,254,254,1) 100%); /* Opera 11.10+ */
- background: -ms-linear-gradient(top, rgba(226,226,226,1) 0%,rgba(219,219,219,1) 15%,rgba(209,209,209,1) 28%,rgba(254,254,254,1) 100%); /* IE10+ */
- background: linear-gradient(to bottom, rgba(226,226,226,1) 0%,rgba(219,219,219,1) 15%,rgba(209,209,209,1) 28%,rgba(254,254,254,1) 100%); /* W3C */
- filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#e2e2e2', endColorstr='#fefefe',GradientType=0 ); /* IE6-9 */
-}
-
-input[type="submit"]:hover {
- text-shadow: 0 0 3px #666;
-}
-
-input[type="checkbox"] {
- vertical-align: middle;
-}
-
-label[rel="urgency"] {
- padding: 0.5em 0;
- color: #fff;
- background: #729fcf;
- /*background: #ad7fa8;*/
- /*background: #f74a73;*/
-}
-
-label[rel="scope"] {
- padding: 0.5em 0;
- color: #fff;
- background: #3465a4;
- /*background: #75507b;*/
- /*background: #e72a53;*/
-}
-
-label[rel="extra"] {
- padding: 0.5em 0;
- color: #fff;
- background: #204a87;
- /*background: #5c3566;*/
- /*background: #d70a53;*/
-}
-
-label[rel="extra"]:last-child {
- margin-right: 0.5em;
- padding-right: 0.5em;
-}
-
-span.red { color: #d70a53; }
-span.purple { color: purple; }
-span.green { color: green; }
-span.dangerous { color: orange; }
-span.avoidwrap { display: inline-block; }
-
- at media all and (max-width: 641px) {
- body {
- font-size: 13px;
- }
- table {
- table-layout: fixed;
- }
- td, th {
- overflow: hidden;
- }
-}
-
-/*
- * @media all and (min-width: 841px) {
- * img.graph {
- * width: 70%;
- * height: auto;
- * }
- * }
- */
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-builds-howto.git
More information about the Reproducible-commits
mailing list