[Git][reproducible-builds/reproducible-website][master] venice 2022: move https://pad.riseup.net/p/rbsummmit2022-packaging-keep to here

[Holger Levsen (@holger)]

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


Commits:
55c9ee5c by Holger Levsen at 2023-01-13T13:12:09+01:00
venice 2022: move https://pad.riseup.net/p/rbsummmit2022-packaging-keep to here

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

- - - - -


2 changed files:

- _events/venice2022/agenda.md
- + _events/venice2022/packaging.md


Changes:

=====================================
_events/venice2022/agenda.md
=====================================
@@ -53,7 +53,7 @@ Day 1 - Tuesday, November 1st
 * 13.30 Collaborative Working Sessions
   * Documentation FIXME https://pad.riseup.net/p/rbsummmit2022-documentation-keep
   * Tools FIXME https://pad.riseup.net/p/rbsummmit2022-tools-keep
-  * Packaging FIXME https://pad.riseup.net/p/rbsummmit2022-packaging-keep
+  * [Packaging]({{ "/events/venice2022/packaging/" | relative_url }})
 * 15.00 Break
 * 15.30 Closing Circle
 * 15.45  Hacking Time
@@ -70,7 +70,7 @@ Day 2 - Wednesday, November 2nd
 * 9.30 Collaborative Working Sessions, break-out discussions continue.
   * [Documentation + Tooling]({{ "/events/venice2022/documentation+tooling/" | relative_url }})
   * [Metrics]({{ "/events/venice2022/metrics/" | relative_url }})
-  * Packaging FIXME https://pad.riseup.net/p/rbsummmit2022-packagingII-keep
+  * [Packaging]({{ "/events/venice2022/packaging/" | relative_url }})
   * Motivation FIXME https://pad.riseup.net/p/rbsummmit2022-motivation-keep
 * 11.15 Break
 * 11.15 Participant Skill Share


=====================================
_events/venice2022/packaging.md
=====================================
@@ -0,0 +1,88 @@
+---
+layout: event_detail
+title: Collaborative Working Sessions - Packaging
+event: venice2022
+order: 30
+permalink: /events/venice2022/packaging/
+---
+
+Reproducible Builds Summit 2022
+
+Day 1:
+------
+
+Points to work on:
+
+ * Minimal input for reproducible builds env + instructions (should be as small as possible)
+ * The metadata information to be provided to the user to ensure that the build is reproducibile
+ * A handfull of ecosystems should be choosen to work on
+
+
+The package managers that would be taken into account:
+    Pip, Stack, Kabal, Debian, FreeBSD, OpenBSD, rpm, Guix, Cargo, Go modules, Gradle, Npm, Docker, OCI, Maven, opam (missing in the group: Ruby Gems, Composer, Nuget)
+
+What reproducible would mean in comparison between binaries or just "text" like source code (JavaScript, Python or any other type of intrepretable): what is distributed?
+=> there is probably a classification between package managers to be found
+
+Once you have a reproducible candidate (release manager thinks his package should be rebproducible), you need to have another actor that should try to verify the reproducibility by rebuilding and checking against the published reference: only when someone can get the same output is the release marked as "reproducible verified/confirmed". 
+
+Language specific packagers:
+    
+ * Pip
+ * Stack
+ * Kabal
+ * Pip
+ * Debian, FreeBSD, OpenBSD (Non-language-specific ones)
+ * Cargo, Go modules
+ * Gradle
+ * Npm 
+ * Docker 
+ * Maven
+ * Nuget
+ * Composer
+
+
+
+Day 2: 
+------
+  
+Starting actions:
+    
+
+ * What does reproducible mean?
+ * Split them into buckets, what are the particularities  
+ * What is the metadata we need
+ * What is there minimal input(build.spec) and their output (build.info)
+
+
+
+Artefact:
+
+ * *build.spec* - everything that needs to be input for building. Reproducibility will be checked against reference artefact. 
+ * *build.info* - what actually happens. It can contain the hashes of the parts and the hash of everything. 
+
+In case of Debian, the build.info file provides all the information and can be used as input for debrepro.
+
+From the perspective of the reproducibility we can have the following when it comes to languages:
+    
+Reproducibility classes:
+
+ * A - everything is reproducible  
+ * B - everything code is reproducible (functional)
+ * C - everything in the programming language is reproducible, except the native dependencies 
+ * TBD - everything in development is reproducible, dependencies might not be reproducible 
+ * TBD - naming
+ * TBD Reproducibility stamps from different organisations.
+
+
+Practical tests:
+
+ * Herve tried Python to see how reproducible it is: https://github.com/jvm-repo-rebuild/repro-summit
+ * Matt hacked on NPM starting with:
+   * Npm version
+   * Node version
+   * Git tag
+   * Git repo
+
+
+In debian's case everything that is released is built from scratch, including Java packages for instance. The minimal subset of inputs required to be able to generate reproducibile builds is the set of dependencies and some environment variables. The assumption is that the dependecies are safe. 



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/55c9ee5c71262cfb04029b90e4ca2af3658f816e

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/55c9ee5c71262cfb04029b90e4ca2af3658f816e
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/20230113/b98b16a9/attachment.htm>