[Git][reproducible-builds/reproducible-presentations][master] 2 commits: improve todo/structure for foss-north.se talk

Holger Levsen (@holger) gitlab at salsa.debian.org
Fri Apr 21 15:34:18 UTC 2023



Holger Levsen pushed to branch master at Reproducible Builds / reproducible-presentations


Commits:
fdf079a1 by Holger Levsen at 2023-04-21T03:36:58+02:00
improve todo/structure for foss-north.se talk

Signed-off-by: Holger Levsen <holger at layer-acht.org>

- - - - -
c191c8fb by Holger Levsen at 2023-04-21T17:34:07+02:00
some progress in foss-north talk

Signed-off-by: Holger Levsen <holger at layer-acht.org>

- - - - -


1 changed file:

- 2023-04-24-foss-north.se-R-B-the-first-10-years/index.html


Changes:

=====================================
2023-04-24-foss-north.se-R-B-the-first-10-years/index.html
=====================================
@@ -8,9 +8,20 @@ TODO:
 - hide slides which are too debian specific but might be useful later in a more debian specific talk.
 - try not to assume knowledge about debian release processes.
 - /docs/history 
-- update contributors (seth, more?)
-
-slide: maybe the talk title should have been: _my_ first 10 years...
+- refer to other talks:
+  - 2015 fosdem has a long list of issues
+  - thread model much better explained by lamby
+- slide?: change my mind - or after certain statements (single apps r-b usefulness)
+- slide?: bootstrapable.org - this is limited to software. reproducible hardware & free & reproducible firmware...
+
+slide: but surely: the goal of this talk is
+	- to get you excited & involved &|| caring and thus supportive
+	- recap what we have done, celebrate 10y of awesomeness
+	- explain that 97% is a nice meaningless number, i mean
+	- explain what still needs doing & partly is done of cource etc pp
+	- so yeah, there's still a lot to be done after 100% which will make a UI obsolete
+	- think SBOM binary transparency merkel tree
+	- on a distro scale (say: "please do it with an r-b debian fork. hah, doesnt work because of the 97% only yet".)
 slide: disclaimer: i'm a debian dd but i run tests for a lot of other projects, with more or less help/usage from them.
 slide: r-b is now barely a teenie. I look forward to it being grown up, so in 8 years, I hope to be able to let it go.
 slide: this talk is about my r-b story since 10y. r-b existed at least 30y ago.
@@ -26,6 +37,9 @@ slide: debconf13
 slide: ccc talk 2013
 slide: fosdem 2014
 slide: camp 2015
+slide: SOURCE_DATE_EPOCH 1.0 2015, 1.1 2017
+slide" build path variation: 2023: don't do it. Bug#1034424: buildd.debian.org: Please use predictible build paths
+	(for Debian folks: no more build path variation in unstable)
 slide: r-b summits, 5 so far, next to come.
 slide: talks at debconfs
 slide: funding: first LF, now an SFC project. I like the SFCs focus on freedom.
@@ -33,10 +47,12 @@ slide: 2017: debian-policy: should
 slide: 2023 debian bullseye: will be explained in a bit :)
 slide: recent mail from wireguard
 slide: distro details:
+slide: tails
 slide: free- & netbsd
 slide: fedora (show makro enabled thing)
 slide: archlinux (mention: they are great. have rebuilders. pacman-bintrans a model for debian and everyone else.)
 slide: f-droid
+	single apps reproducibililty not practical
 slide: nix
 slide: guix
 slide: honorable mention: trisqel
@@ -47,13 +63,21 @@ slide:
 	columns: stretch buster bullseye bookworm
 	rows: amd64 arm64 i386 armhf with percentages
 slide: now: teh future!
+slide: recap: we all support SOURCE_DATE_EPOCH
+	/docs/source-date-epoch/
+slide: recap: .buildinfo files / SBOM
+	recorded or predictable/static buildpath
+	(for Debian folks: no more build path variation in unstable)
+slide: SBOMs are nothing new, we know them since 2014 or so.
+	verified SBOMs are cool: = have been used to verify = reproduce a build
 slide: trixie, forky & probably 2 more until 100% reproducible Debian stable.
 	100% reproducible is a politcal task, not technical.
 slide: rebuilders (rebuild Debian on every point release? as in: publish those .buildinfo files as one tar archive maybe?)
-slide: SBOMs are boring, we know them since 2014 or so.
-	verified SBOMs are cool: = have been used to verify = reproduce a build
 slide: technically eventually "done"/doable, but practically?
-slide: we need you.
+slide: personally, i want to finish this. by 2030: no more unreproducible builds in Debian stable.
+slide: we need you. *i* need you. :) we need each other.
+slide: r-b, the only way you can be sure the binary you are running is the free software you think you are running.
+	or in SBOM speak: ... ("did you get what you bought?" :)
 
 -->
 
@@ -184,7 +208,7 @@ slide: we need you.
       <section>
         <br>
         <h3>
-	Reproducible Builds <br>the first ten years
+	Reproducible Builds, <br>the first ten years
         </h3>
         <br>
         <img src="images/reprobuilds-display.jpeg" style="height: 220px; border-radius: 10px;">
@@ -193,7 +217,8 @@ slide: we need you.
  <h6>
           <small>
           Holger Levsen<br>
-	foss-north 2023
+	foss-north 2023-04-24<br>
+	Göteborg, Sverige
           </small>
         </h6>
         <img src="images/fn-logo.png" style="height: 70px;">
@@ -201,14 +226,15 @@ slide: we need you.
 
       <section>
           <p style="font-size: 120%"><em>
-	        where we come from and where we are going
+maybe the talk title should have been:<br> </em>my<em> first 10 years with reproducible builds...
+
 		<span class="fragment">
-			<br>or<br>
-			the last mile and other lightyears ahead
+			<br>though this is not about my work.
 		</span>
 		<span class="fragment">
-			<br>or<br>
-			I still haven't found what I'm looking for
+			<br>
+			Reproducible builds, like Free Software in general,
+			is a collective effort:
 		</span>
 	</em>
           </p>
@@ -218,8 +244,8 @@ slide: we need you.
 
 
       <section data-background="images/fn-logo.png" data-background-size="12%" data-background-position="90% 10%">
-        <h3>very incomplete list of people<br>who have been working on <em>this</em></h3>
-<p style="font-size: 50%">
+        <h3>very incomplete list of people<br>who have been working on this <em>so far</em></h3>
+<p style="font-size: 42%">
 
 	<!-- taken from website.git/_data/contributors.yml -->
 
@@ -330,6 +356,7 @@ slide: we need you.
     • Mathieu Parent
     • Mattia Rizzolo
     • Michael Pöhn
+    • Mike Perry
     • Morten Linderud
     • Muz
     • Mykola Nikishov
@@ -357,7 +384,9 @@ slide: we need you.
     • Santiago Vila
     • Sascha Steinbiss
     • Satyam Zode
+    • Seth Schoen
     • Scarlett Clark
+    • Simon Josefsson
     • Simon Schricker
     • Snahil Singh
     • Stefano Rivera
@@ -378,8 +407,8 @@ slide: we need you.
     • Wookey
     • Ximin Luo
 	</p>
-<p style="font-size: 42%">
- (Huge sorry if YOU are missing, please lets fix this. I'd think there should probably be 50 more people on this list at least..!)
+<p style="font-size: 52%">
+ (Huge sorry if YOU are missing, please lets fix this. The real list is twice as big at least..!)
 </p>
 	  </section>
 
@@ -387,8 +416,8 @@ slide: we need you.
         <p>Who am I</p>
         <ol>
           <li>Holger Levsen / holger at debian.org</li>
-          <li>Debian user since 1995, contributing since 2001, Debian member since 2007</li>
           <li>Located in Hamburg, Germany</li>
+          <li>Debian user since 1995, contributing since 2001, Debian member since 2007</li>
           <li>Working on Reproducible Builds since 2014</li>
      </ol>
       </section>
@@ -435,7 +464,7 @@ slide: we need you.
         <ul>
           <li style="font-size: 80%">When is a build reproducible?</li>
           <li class="fragment">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.</li>
-          <li class="fragment">The relevant attributes of the build environment, the build instructions and the source code as well as the expected reproducible artifacts are defined by the authors or distributors. The artifacts of a build are the parts of the build results that are the desired primary output.<li>
+          <li class="fragment" style="font-size: 80%">The relevant attributes of the build environment, the build instructions and the source code as well as the expected reproducible artifacts are defined by the authors or distributors. The artifacts of a build are the parts of the build results that are the desired primary output.<li>
 	  <li class="fragment">https://reproducible-builds.org/docs/definition/</li>
 
         </ul>
@@ -446,7 +475,6 @@ slide: we need you.
         <p>I'll mostly ignore <em>why</em> and <em>how to do such builds</em> today.</p>
         <p class="fragment">I'll just mention that by now this has been widely understood as a problem: 
 		<br><span style="font-size: 70%">https://www.whitehouse.gov/briefing-room/statements-releases/2021/06/08/...</span></li>
-        <p class="fragment">So today I will give a short overview about various projects and then I'll explain the situation in Debian.</p>
       </section>
 
       <section data-background-color="white">



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/f24e93d11dcc9ba712bdfa05fd566dedfde48914...c191c8fba04df81304e3e53997c9db0bf9ddaaaf

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/f24e93d11dcc9ba712bdfa05fd566dedfde48914...c191c8fba04df81304e3e53997c9db0bf9ddaaaf
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20230421/f367aa6f/attachment.htm>


More information about the rb-commits mailing list