[Git][reproducible-builds/reproducible-website][master] rbs 2026: day1: fix formatting of notes

Thu Oct 1 08:31:30 UTC 2026


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


Commits:
f068a415 by Holger Levsen at 2026-10-01T10:31:15+02:00
rbs 2026: day1: fix formatting of notes

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

- - - - -


3 changed files:

- _events/gothenburg2026/agenda/d1-atproto.md
- _events/gothenburg2026/agenda/d1-imagebuilds.md
- _events/gothenburg2026/agenda/d1-longtail.md


Changes:

=====================================
_events/gothenburg2026/agenda/d1-atproto.md
=====================================
@@ -16,7 +16,7 @@ permalink: /events/gothenburg2026/agenda/d1-atproto/
 
 -   Grab bag of thoughts (from "what are people interested in" phase):
     -   Formats don't explain how things are published. We're interested in publish.
-    -   Atproto is a publishing platform.
+    -   Atproto is a publishing platform, see [https://en.wikipedia.org/wiki/AT_Protocol](https://en.wikipedia.org/wiki/AT_Protocol) and [https://atproto.com](https://atproto.com)
     -   Enumeration/discoverability is slightly distinct from distribution.
         -   You can publish/distribute something but if it's in a forest and nobody hears it, it can't be enumerated/discovered.
     -   Interest in publishing, in observability.


=====================================
_events/gothenburg2026/agenda/d1-imagebuilds.md
=====================================
@@ -10,7 +10,7 @@ permalink: /events/gothenburg2026/agenda/d1-imagebuilds/
 - Lots of timestamp cleanup
 - Handling logs: the output of some build tools can be piped to /dev/null
 - An archive is needed for bootstrapping: use yesterday's archive to bootstrap today's image
-- Pacman has some non-determinism (key material embedded in the binary), which is stripped from the image. This breaks pacman out of the box; you need to run a command to fix pacman. Pacman also supports redirecting logs (to /dev/null) and using `SOURCE_DATE_EPOCH` for installed package metadata.
+- Pacman has some non-determinism (key material embedded in the binary), which is stripped from the image. This breaks pacman out of the box; you need to run a command to fix pacman. Pacman also supports redirecting logs (to /dev/null) and using [SOURCE_DATE_EPOCH](https://reproducible-builds.org/docs/source-date-epoch/) for installed package metadata.
   - Comment: does apt support this?
 - For WSL, the rootfs is enough; very little translation is needed after that
 - For containers, the builder takes the rootfs but needs additional flags to make the container image itself reproducible. One of the major ones is the epoch time; Arch uses the release timestamp


=====================================
_events/gothenburg2026/agenda/d1-longtail.md
=====================================
@@ -14,29 +14,17 @@ In 2026, distributions such as Debian and openSUSE are already achieving 98% or
 We would like to provide users with reproducible (more trustable) software.
 
 - users could still install non-reproducible software, what can be done about this?
-
 - For enterprise SUSE, the non-reproducible software is documented. Then a meta-package conflicts all the packages with known reproducibility issues, preventing their installation. = [https://build.opensuse.org/package/show/home:bmwiedemann/SLES-reproducible-builds](https://build.opensuse.org/package/show/home:bmwiedemann/SLES-reproducible-builds)
-
 - Another idea is that non-reproducible packages could be dropped from the main repository, and placed elsewhere
-
 - For Debian, non-reproducible packages are blocked from migrating to testing
-
 - CI runs on Debian Salsa, and this tests if things build reprodciblly (debrebuild)
-
 - repro-threshold allows checking for signatures on installation time on Debian based systems [https://github.com/kpcyrd/repro-threshold](https://github.com/kpcyrd/repro-threshold)
-
 - Is there a need to distinguish how "bad" the reproducibility issues are, e.g. just docs or build-id vs more significant differences
-
 - For GNU Guix, k of n trust of substitutes would allow users to trust substitues more (currently Guix doesn't have a mechanism for this on the client side)
-
 - Maybe APT could fallback to building from source if something is non-reproducible?
-
 - Let's add documentation to reproducible-builds.org for distributions to allow users to avoid non-reproducible software
-
 - List out known approaches to allow users to avoid the small proportion of non-reproducible software
-
 - For F-Droid, packages could be reproducible when build by F-Droid, but they could still match or not match the package provided and signed by the upstream developer.
-
 - option: get to 100% reproducible
 
 Why not have apt-transport by default in Debian:
@@ -47,6 +35,6 @@ Why not have apt-transport by default in Debian:
   * resistance to adding more files to Debian servers
   * property of the repository - not of the package
 
-Todo: add to _docs/long_tail.md in [https://salsa.debian.org/reproducible-builds/reproducible-website](https://salsa.debian.org/reproducible-builds/reproducible-website)
-
-link in _data/docs.yml
+Todo:
+* add to _docs/long_tail.md in [https://salsa.debian.org/reproducible-builds/reproducible-website](https://salsa.debian.org/reproducible-builds/reproducible-website)
+* link in _data/docs.yml



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/f068a415723fb1b1693680486ffa48de62ae8a0b
You're receiving this email because of your account on salsa.debian.org. Manage all notifications: https://salsa.debian.org/-/profile/notifications | Help: https://salsa.debian.org/help


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