[reproducible-website] 01/01: rws3: liberate notes about user tools

Holger Levsen holger at layer-acht.org
Mon Dec 18 14:05:45 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 a583e5715f089a7ac6662dbdabefcee6d29e31f7
Author: Holger Levsen <holger at layer-acht.org>
Date:   Mon Dec 18 14:05:40 2017 +0000

    rws3: liberate notes about user tools
    
    Signed-off-by: Holger Levsen <holger at layer-acht.org>
---
 .../ReproducibleSummitIIIEventDocumentation.md     | 290 +++++++--------------
 _events/berlin2017/agenda.md                       |  10 +-
 _events/berlin2017/usertools.md                    |  59 +++++
 3 files changed, 163 insertions(+), 196 deletions(-)

diff --git a/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md b/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
index 9590971..24680b9 100644
--- a/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
+++ b/_events/berlin2017/ReproducibleSummitIIIEventDocumentation.md
@@ -24,8 +24,7 @@ Working sessions I
 * [Reviewing existing reproducible builds tools]({{ "/events/berlin2017/existingtools/" | prepend: site.baseurl }})
 * [Discussing the current status of .buildinfo files]({{ "/events/berlin2017/statusbuildinfofiles/" | prepend: site.baseurl }})
 * [What is the ecosystem around rpm?]({{ "/events/berlin2017/ecosystemrpm/" | prepend: site.baseurl }})
-
-:::[[#RefHeadingToc4088118152727|End user tools: What does exist, what is still needed]]
+* [End user tools: What does exist, what is still needed]({{ "/events/berlin2017/usertools/" | prepend: site.baseurl }})
 
 Working sessions II
 
@@ -97,96 +96,7 @@ Working sessions VII
 = Session Notes =
 == Day 1 ==
 === Working sessions I ===
-
-
-==== {{anchor|RefHeadingToc4088118152727}} End user tools: What does exist, what is still needed ====
-
-
-
-which users are we talking about?
-
-- people who are installing software
-
-- admins who maintain systems for users
-
-
-user stories are good
-
-- scientific users: if you want to write reproducible papers, you must use reproducible software.
-
-- doctors (and lawyers) are faced with the mandate to encrypt user data. with r-b they can have more confidence the software is untampered with.
-
-- developers who want a trustworthy base to develop software on.
-
-- verify software build or installed on systems one is not allowed to touch. useful for admins to support (external or internal) users.
-
-- users who want confirmation they run free software!
-
-- users who want confirmation they run the software they intend to run
-
-
-the apt-hook (exist)
-
-gnome software center (doesnt exist)
-
-
-what might the user want to know, what problem they want solve?
-
-
-is it helpful to show that a software is unreproducible to the user? is that meaningful information?
-
-
-the user wants to set a policy on their device: only reproducible software. they dont care much about individiual unreproducible software…
-
-
-there will be different policies: (incomplete list)
-
-- only install reproducible software which all rebuilders agreed on
-
-- fine if one rebuilder disagrees
-
-- fine if two rebuilder disagrees
-
-- rebuild locally in case of conflict
-
-- always rebuild locally
-
-- i only want reproducible software with the exception of my wifi driver and i need flash in the webbrowser - and i love that 3d tetris game too
-
-
-it should be possible to upgrade to a stricter policy.
-
-
-could be opt-in, people who are not interested in reproducible builds (who have not opted in) should never be informed that/if software is unreproducible.
-
-because cavevat:
-
-- warning fatigue. too many warnings can scare users away.
-
-
-users dont care about reproducbility, its a technical detail. they care that they run the "right" software.
-
-
-denial of service by malicious rebuilder
-
-
-unrelated
-
-<nowiki>---------</nowiki>
-
-we need rebuilder howtos
-
-
-outcome
-
-<nowiki>-------</nowiki>
-
-another session to enumerate possible policies
-
-another session to write user stories
-
-=== {{anchor|RefHeadingToc4090118152727}} Working sessions II ===
-
+=== Working sessions II ===
 
 
 ==== {{anchor|RefHeadingToc4092118152727}} How to fix the current issues with BUILD_PATH_PREFIX_MAP? ====
@@ -237,11 +147,11 @@ of them.
 
 We had some brief discussion around the similarity of the BUILD_PATH_PREFIX_MAP proposal with SOURCE_DATE_EPOCH:
 
-<nowiki>* they're both environment variables</nowiki>
+* they're both environment variables
 
-<nowiki>* they both have clearly established semantics of how we want build systems to transform/stabilize certain forms of ephemeral data</nowiki>
+* they both have clearly established semantics of how we want build systems to transform/stabilize certain forms of ephemeral data
 
-<nowiki>* in many situations, the goal is for the build system to not need either env var, because the ephemeral data in question simply isn't a part of the build process at all.</nowiki>
+* in many situations, the goal is for the build system to not need either env var, because the ephemeral data in question simply isn't a part of the build process at all.
 
 
 We currently have patches oustanding for gcc and golang. We don't think that anyone has even asked clang for support yet.
@@ -317,7 +227,7 @@ Vagrant proposes putting literal string '$VARNAME' as argument for
 Followup discussions/hacking proposed:
 
 
-<nowiki>* investigate what netbsd is doing.</nowiki>
+* investigate what netbsd is doing.
 
 ==== {{anchor|RefHeadingToc4094118152727}} How bootstrapping relates to reproducible builds and how to improve it ====
 
@@ -338,7 +248,7 @@ Why should we care?
 We need to trust binaries used during build. If build binaries are not trustworthy, this makes build results less trustworthy.
 
 
-<nowiki>#If we have a exe at the top and a lib it depends on, do we call the exe reproducible even if the lib is not reproducible?</nowiki>
+#If we have a exe at the top and a lib it depends on, do we call the exe reproducible even if the lib is not reproducible?
 
 
 is trust binary / black&white? no...
@@ -440,7 +350,7 @@ more to be discussed
 
 newbee docs
 
-<nowiki>===========</nowiki>
+===========
 
 
 - entrypoint of https://r-b.org good.
@@ -539,7 +449,7 @@ Grovy 2.0 depends on gradle 1.0, which depends on groovy 1.8.4 which has a maven
 
 Problem with java projects which have tests which depend on the parent project. --> dependency cycles
 
-<nowiki>-----------</nowiki>
+-----------
 
 
 Javadoc --> produces unreproducable output based on filesystem order
@@ -645,7 +555,7 @@ Partial dependecy graph of a ghc bootstrap path, early boostsrapping information
 One idea to consolidate the approach in the link was proposed, is to use nhc98 to build a 32 version of ghc, then crosscompile ghc to x86_64.
 
 
-<nowiki>----- Transcription of the poster</nowiki>
+----- Transcription of the poster
 
 
 A node in this graph represents a particular compiler. Edges are "can build" relationships.
@@ -789,23 +699,23 @@ e.g. Qt, google, GNU, facebook, python
 How can the end user define what they want in terms of reproducibility?
 
 
-<nowiki># Policies</nowiki>
+# Policies
 
 
-<nowiki>* there is no one size fits all policy</nowiki>
+* there is no one size fits all policy
 
-<nowiki>* can you verify using a checkbox that the software is the one we want to install?</nowiki>
+* can you verify using a checkbox that the software is the one we want to install?
 
-<nowiki>* but we want the computer to verify that many people have reproduced the same software.</nowiki>
+* but we want the computer to verify that many people have reproduced the same software.
 
-<nowiki>* how to handle exceptions to the policy?</nowiki>
+* how to handle exceptions to the policy?
 
-<nowiki>* providing these policies to users is a different question than to provide this kind of information to developers/researchers</nowiki>
+* providing these policies to users is a different question than to provide this kind of information to developers/researchers
 
-<nowiki>* after the installation, we should also be able to verify the software we installed on the computer</nowiki>
+* after the installation, we should also be able to verify the software we installed on the computer
 
 
-<nowiki>* question: what if the news arrives via Twitter, should this be part of the policy?</nowiki>
+* question: what if the news arrives via Twitter, should this be part of the policy?
 
 
 Questions:
@@ -819,32 +729,32 @@ Questions:
 - What are the downsides of these policies?
 
 
-<nowiki># Example policies</nowiki>
+# Example policies
 
 
 EXAMPLE 1
 
 REBUILDERS BUILD INFO FILES
 
-<nowiki>========== </nowiki><nowiki>================</nowiki>
+========== ================
 
-<nowiki>---------------</nowiki>
+---------------
 
 | rebuilder A | -------→ pkgX matches digest N
 
-<nowiki>---------------</nowiki>
+---------------
 
-<nowiki>---------------</nowiki>
+---------------
 
 | rebuilder B | -------→ pkgX matches digest N
 
-<nowiki>---------------</nowiki>
+---------------
 
-<nowiki>---------------</nowiki>
+---------------
 
 | rebuilder C | -------→ pkgX matches digest N
 
-<nowiki>---------------</nowiki>
+---------------
 
 |
 
@@ -855,7 +765,7 @@ v
 
 MACHINE
 
-<nowiki>=======</nowiki>
+=======
 
 policy configured to
 
@@ -1001,23 +911,23 @@ Rebuilders
 
 EASY GUI:
 
-<nowiki>---------------------------------------------------------</nowiki>
+---------------------------------------------------------
 
 Policy Chooser per repository
 
-<nowiki>---------------------------------------------------------</nowiki>
+---------------------------------------------------------
 
 x default (none)
 
-<nowiki>---------------------------------------------------------</nowiki>
+---------------------------------------------------------
 
 o Debian
 
-<nowiki>---------------------------------------------------------</nowiki>
+---------------------------------------------------------
 
 o Debian stricter
 
-<nowiki>---------------------------------------------------------</nowiki>
+---------------------------------------------------------
 
 Advanced button
 
@@ -1026,33 +936,33 @@ ADVCANCED GUI:
 
 REPOSITORY X
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Trusted rebuilders INCLUDED REQUIRED
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Rebuilder A x
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Rebuilder B
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Rebuilder C x
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Number of rebuilders needed for consensus (m out of n): 2
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 → by default weight is binary (0/1), and...
 
 ..in advanced mode we could use non-binary weights.
 
-<nowiki>----------------------------------------------------------</nowiki>
+----------------------------------------------------------
 
 Consensus fail policy
 
@@ -1488,7 +1398,7 @@ TOP THREE AUDIENCES TO FOCUS ON:
 
 Pad1
 
-<nowiki>====</nowiki>
+====
 
 
 Directed graph we came up with in dot:
@@ -1565,7 +1475,7 @@ isolation of external failure causes
 
 Pad2
 
-<nowiki>====</nowiki>
+====
 
 
 Reproducible, deterministic:
@@ -1602,7 +1512,7 @@ Bootstrappable
 
 SOURCE_DATE_EPOCH
 
-<nowiki>==============================================</nowiki>
+==============================================
 
 
 - current spec talks about "current time of system";
@@ -1830,7 +1740,7 @@ What do we need to have/run rebuilders?
 
 Who does rebuilds already?
 
-<nowiki>==========================</nowiki>
+==========================
 
 
 - One attendee runs a rebuilder for GUIX (~1k packages).
@@ -1846,7 +1756,7 @@ published `buildinfo`.
 
 Example scenario
 
-<nowiki>================</nowiki>
+================
 
 
 What's the simplest, cheapest and useful rebuilder?
@@ -1901,7 +1811,7 @@ the `buildinfo` we don't leak much.
 
 What does the concept of rebuilding mean?
 
-<nowiki>=========================================</nowiki>
+=========================================
 
 
 For example, do we try to reproduce a previous build in a build env.
@@ -1926,7 +1836,7 @@ this package with a different version of `libfoo` than what's in the
 
 How do we rebuild?
 
-<nowiki>==================</nowiki>
+==================
 
 
 Do we want a centralized/generic rebuilding infrastructure?
@@ -1936,7 +1846,7 @@ Or specific to the project we're rebuilding?
 
 How/where do we store results of rebuilds?
 
-<nowiki>==========================================</nowiki>
+==========================================
 
 
 (both matching and non-matching)
@@ -1970,7 +1880,7 @@ we need access to all such databases?
 
 How do we lookup reports?
 
-<nowiki>-------------------------</nowiki>
+-------------------------
 
 
 Lookup by hash? This only tells us that someone reproduced a build,
@@ -1985,7 +1895,7 @@ e.g. distro + (package, arch, version)?
 
 Marketing
 
-<nowiki>=========</nowiki>
+=========
 
 
 How do we convince orgs to run rebuilders?
@@ -2000,7 +1910,7 @@ can each explain their own reasons.
 
 Bonus features & ideas
 
-<nowiki>======================</nowiki>
+======================
 
 
 - Reuse this for the "I want to rebuild all packages locally before
@@ -2057,7 +1967,7 @@ rebuilder publishes diffoscope output for non-matching builds.
 
 One year
 
-<nowiki>========</nowiki>
+========
 
 
 - Reproducible hackaton #2
@@ -2079,7 +1989,7 @@ One year
 
 Two years
 
-<nowiki>=========</nowiki>
+=========
 
 
 - rebuilder run by recognized organizations
@@ -2119,7 +2029,7 @@ community worldwide
 
 Distant goals
 
-<nowiki>=============</nowiki>
+=============
 
 
 - 100% reproducible packages (verifiable)
@@ -2149,7 +2059,7 @@ non-reproducible is considered as a bug by a broad community
 
 Unknown
 
-<nowiki>=======</nowiki>
+=======
 
 
 - reproducible Lineage OS
@@ -2175,18 +2085,18 @@ want: web-page with "gzip" in red and "gzip -n" in green
 
 want: find the reproducibility status of packages in other distributions => is it reproducible, what patches are required?
 
-<nowiki>=> make rb status pages more discoverable</nowiki>
+=> make rb status pages more discoverable
 
-<nowiki>=> needs UI designer to make tiny hidden links more visible</nowiki>
+=> needs UI designer to make tiny hidden links more visible
 
-<nowiki>=> FAQ how to find information about status of a package in a distribution ; also past rb bugs + patches relating to that package - if possible also tools patches</nowiki>
+=> FAQ how to find information about status of a package in a distribution ; also past rb bugs + patches relating to that package - if possible also tools patches
 
-<nowiki>=> more advertising of toolchain patches</nowiki>
+=> more advertising of toolchain patches
 
 
 For developers, wanting to get reproducible results from make
 
-<nowiki>=> describe your build environment</nowiki>
+=> describe your build environment
 
 
 Q: how to make my software reproducible?
@@ -2215,9 +2125,9 @@ How to ask for help with the above?
 
 ML, IRC, useful information to include
 
-<nowiki>=> add call for action</nowiki>
+=> add call for action
 
-<nowiki>=> add "for developers" / "how to get involved" page to r-b.org</nowiki>
+=> add "for developers" / "how to get involved" page to r-b.org
 
 "Resources" is wrong for ML => Community/Communication channels
 
@@ -2226,9 +2136,9 @@ People without own software:
 
 What can I do to help?
 
-<nowiki>=> work on r-b tools, fix debian packages and FLOSS upstream projects, work on test infrastructure</nowiki>
+=> work on r-b tools, fix debian packages and FLOSS upstream projects, work on test infrastructure
 
-<nowiki>=> use "reproducible-check" on your Debian system</nowiki>
+=> use "reproducible-check" on your Debian system
 
 
 
@@ -2238,7 +2148,7 @@ Good: want to discover about the subject with direct links to videos, link to ev
 
 News blog under debian.org instead of r-b.org, news on r-b.o is not updated, can appear orphaned
 
-<nowiki>=> move ?</nowiki>
+=> move ?
 
 separate marketing updates from developer information?
 
@@ -2250,7 +2160,7 @@ Next steps: add "get involved", "for developers", "for distributors" page
 
 Tools section: links to debian package of reprotest, disorderfs, strip-nondeterminism instead of generic project website
 
-<nowiki>=> de-debianize, have tarballs discoverable </nowiki><nowiki># pypi is outdated anyway and not as useful</nowiki>
+=> de-debianize, have tarballs discoverable # pypi is outdated anyway and not as useful
 
 
 ==== {{anchor|RefHeadingToc4138118152727}} Identifying next actionable steps for marketing outreach ====
@@ -2300,7 +2210,7 @@ For each audience we want to identify:
 
 Developers in general
 
-<nowiki>=========</nowiki>
+=========
 
 
 Developers:
@@ -2328,7 +2238,7 @@ Action items:
 
 Toolchain developers
 
-<nowiki>=========</nowiki>
+=========
 
 
 They have 2 key issues:
@@ -2377,7 +2287,7 @@ Table: even better espec. for folks who don't know rb yet
 
 Academics
 
-<nowiki>=========</nowiki>
+=========
 
 
 We're focussing on scientist, and particularly on disciplines whose
@@ -2434,7 +2344,7 @@ and reproducibility.
 
 Companies
 
-<nowiki>=========</nowiki>
+=========
 
 
 We focused on companies that produce and/or distribute software.
@@ -2442,7 +2352,7 @@ We focused on companies that produce and/or distribute software.
 
 Value of RBs to them
 
-<nowiki>--------------------</nowiki>
+--------------------
 
 
 
@@ -2495,7 +2405,7 @@ software works here too.
 
 Success stories
 
-<nowiki>---------------</nowiki>
+---------------
 
 
 - We're told that Microsoft has shortened a lot their feedback loop
@@ -2654,7 +2564,7 @@ Recomendation: gcc 4.7 (which doesn't require C++ support to compile)
 For a canonical TOR, you need to agree on library versions.
 
 
-<nowiki>-----</nowiki>
+-----
 
 Goal:
 
@@ -2691,7 +2601,7 @@ Current state:
 At some point Suse had a non-polished reproducibly building gcc patch. This patch was not submitted.
 
 
-<nowiki>----</nowiki>
+----
 
 
 New goal:
@@ -2699,13 +2609,13 @@ New goal:
 Don't solve the build dependency comparison problem yet, because we don't know how to solve it. Solve the SIMPLIST case. Try to create a golden tinycc.
 
 
-<nowiki>----</nowiki>
+----
 
 
 How much work can we share in a canonical build process for a bootstrapped binary identical tinycc?
 
 
-<nowiki>----</nowiki>
+----
 
 
 Should we have a shared build system or a shared recipe and multiple build systems?
@@ -2717,13 +2627,13 @@ This recipe should work with any c compiler/multiple compilers.
 We want to specify only the parts of the recipe which actually effect the output. But not specify the entire "hash" of the exact system used to build.
 
 
-<nowiki>-------------------------------------------------------</nowiki>
+-------------------------------------------------------
 
 
 This is DDC (Diverse double compilation)
 
 
-|-------------| |-------------| |-------------||tinycc source| <nowiki>== |tinycc source| </nowiki><nowiki>== |tinycc source|</nowiki>
+|-------------| |-------------| |-------------||tinycc source| == |tinycc source| == |tinycc source|
 
 |-------------| |-------------| |-------------|
 
@@ -2746,10 +2656,10 @@ This is DDC (Diverse double compilation)
 |-------------| |-------------| |-------------|
 
 
-<nowiki>-------------------------------------------------------</nowiki>
+-------------------------------------------------------
 
 
-|-------------| |-------------| |-------------||tinycc source| <nowiki>== |tinycc source| </nowiki><nowiki>== |tinycc source|</nowiki>
+|-------------| |-------------| |-------------||tinycc source| == |tinycc source| == |tinycc source|
 
 |-------------| |-------------| |-------------|
 
@@ -2769,7 +2679,7 @@ This is DDC (Diverse double compilation)
 
 |-------------| |-------------| |-------------|
 
-| tinycc bin | <nowiki>== | tinycc bin </nowiki>| <nowiki>== | tinycc bin </nowiki>|
+| tinycc bin | == | tinycc bin | == | tinycc bin |
 
 |-------------| |-------------| |-------------|
 
@@ -2794,7 +2704,7 @@ Try on many computers even running the same system.
 
 
 
-<nowiki>----</nowiki>
+----
 
 
 End goal: Create a common bootstrap method and start comparing hashes.
@@ -2850,9 +2760,9 @@ Apple doesn't seem to care about Reproducible Software. They use their own toolc
 
 However, it is possible to:
 
-<nowiki>* cross-compile for Mac OS X with clang;</nowiki>
+* cross-compile for Mac OS X with clang;
 
-<nowiki>* use Xcode to build reproducibly for iOS (except when signing)</nowiki>
+* use Xcode to build reproducibly for iOS (except when signing)
 
 
 In the same repository as above, there are also instructions for cross-building for Mac OS X. It downloads and leverages the official SDK for Mac OS X.
@@ -2880,7 +2790,7 @@ real-world use-case brought up involves computer clusters shared among many user
 
 code signing
 
-<nowiki>============================================</nowiki>
+============================================
 
 
 General area of this session: source code
@@ -3085,15 +2995,15 @@ k = 2x signed buildinfo
 
 Signed .buildinfos coccia.debian.org (ftp master mirror)
 
-<nowiki>================== </nowiki><--- buildinfo.debian.net?
+================== <--- buildinfo.debian.net?
 
-<nowiki>* signed statement: (?)</nowiki>
+* signed statement: (?)
 
-<nowiki>* reproduced by: 6</nowiki>
+* reproduced by: 6
 
-<nowiki>* dissent by: 2</nowiki>
+* dissent by: 2
 
-<nowiki>* not found/not built yet 2</nowiki>
+* not found/not built yet 2
 
 ^
 
@@ -3111,16 +3021,16 @@ Signed .buildinfos coccia.debian.org (ftp master mirror)
 
 buildinfo query
 
-<nowiki>===============</nowiki>
+===============
 
 
-<nowiki>* by hash - only finds _agreements_, not dissent</nowiki>
+* by hash - only finds _agreements_, not dissent
 
-<nowiki>* by domain-specific unique ID:</nowiki>
+* by domain-specific unique ID:
 
 - debian: $pkg, $vers, $arch
 
-<nowiki>* by buildingo! (contains the above)</nowiki>
+* by buildingo! (contains the above)
 
 
 
@@ -3129,17 +3039,17 @@ buildinfo query
 
 Debian main Rebuilders
 
-<nowiki>=========== </nowiki><nowiki>==========</nowiki>
+=========== ==========
 
-archive/mirror <nowiki>* ccc</nowiki>
+archive/mirror * ccc
 
-.deb -------------> <nowiki>* k of n agree on hash? <--- * nsa</nowiki>
+.deb -------------> * k of n agree on hash? <--- * nsa
 
-(n = fixed number) <nowiki>* aclu</nowiki>
+(n = fixed number) * aclu
 
-<nowiki>* all must agree?</nowiki>
+* all must agree?
 
-<nowiki>* signed .buildinfo</nowiki>
+* signed .buildinfo
 
 ==== {{anchor|RefHeadingToc4152118152727}} Discussing current status and potential improvements in regards to .buildinfo files for rpm and iso ====
 
@@ -3179,7 +3089,7 @@ We discussed about where to put .buildinfo file. We suggest to have a seperate f
 
 iso
 
-<nowiki>###</nowiki>
+###
 
 
 The iso contains of:
diff --git a/_events/berlin2017/agenda.md b/_events/berlin2017/agenda.md
index 75b1799..e810fb3 100644
--- a/_events/berlin2017/agenda.md
+++ b/_events/berlin2017/agenda.md
@@ -32,16 +32,14 @@ Participants generated a list of topics and questions that they wanted to discus
 * [Reviewing existing reproducible builds tools]({{ "/events/berlin2017/existingtools/" | prepend: site.baseurl }}) – Chris
 * [Discussing the current status of .buildinfo files]({{ "/events/berlin2017/statusbuildinfofiles/" | prepend: site.baseurl }}) – Mattia
 * [What is the ecosystem around rpm?]({{ "/events/berlin2017/ecosystemrpm/" | prepend: site.baseurl }}) – Bernhard
-* End user tools: What does exist, what is still needed – dkg
-
-
-
-
+* [End user tools: What does exist, what is still needed]({{ "/events/berlin2017/usertools/" | prepend: site.baseurl }}) – dkg
 
 15:05 Break
 
 
-15: 25 Working sessions II (Session notes start on page 27)* How to fix the current issues with BUILD_PATH_PREFIX_MAP? – Ximin
+15: 25 Working sessions II 
+
+* How to fix the current issues with BUILD_PATH_PREFIX_MAP? – Ximin
 * How bootstrapping relates to reproducible builds and how to improve it – Ricardo
 * What documentation is still to be created for developers who are new to reproducible builds? – Holger
 
diff --git a/_events/berlin2017/usertools.md b/_events/berlin2017/usertools.md
new file mode 100644
index 0000000..0138dd8
--- /dev/null
+++ b/_events/berlin2017/usertools.md
@@ -0,0 +1,59 @@
+---
+layout: event_detail
+title: End user tools: What does exist, what is still needed
+event: berlin2017
+order: 60
+permalink: /events/berlin2017/ReproducibleSummitIIIEventDocumentation/
+---
+
+which users are we talking about?
+- people who are installing software
+- admins who maintain systems for users
+
+user stories are good
+- scientific users: if you want to write reproducible papers, you must use reproducible software.
+- doctors (and lawyers) are faced with the mandate to encrypt user data. with r-b they can have more confidence the software is untampered with.
+- developers who want a trustworthy base to develop software on.
+- verify software build or installed on systems one is not allowed to touch. useful for admins to support (external or internal) users.
+- users who want confirmation they run free software!
+- users who want confirmation they run the software they intend to run
+
+the apt-hook (exist)
+
+gnome software center (doesnt exist)
+
+what might the user want to know, what problem they want solve?
+
+is it helpful to show that a software is unreproducible to the user? is that meaningful information?
+
+the user wants to set a policy on their device: only reproducible software. they dont care much about individiual unreproducible software…
+
+there will be different policies: (incomplete list)
+- only install reproducible software which all rebuilders agreed on
+- fine if one rebuilder disagrees
+- fine if two rebuilder disagrees
+- rebuild locally in case of conflict
+- always rebuild locally
+- i only want reproducible software with the exception of my wifi driver and i need flash in the webbrowser - and i love that 3d tetris game too
+
+it should be possible to upgrade to a stricter policy.
+
+could be opt-in, people who are not interested in reproducible builds (who have not opted in) should never be informed that/if software is unreproducible.
+
+because cavevat:
+- warning fatigue. too many warnings can scare users away.
+
+users dont care about reproducbility, its a technical detail. they care that they run the "right" software.
+denial of service by malicious rebuilder
+
+unrelated
+---------
+
+we need rebuilder howtos
+
+outcome
+-------
+
+* another session to enumerate possible policies
+* another session to write user stories
+

-- 
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