[Git][reproducible-builds/reproducible-website][master] Interview Jochen: fix wording, thanks Mattia and kp!

[Jochen Sprickerhof (@jspricke)]

Jochen Sprickerhof pushed to branch master at Reproducible Builds / reproducible-website


Commits:
7e141852 by Jochen Sprickerhof at 2026-09-03T20:57:41+02:00
Interview Jochen: fix wording, thanks Mattia and kp!

- - - - -


1 changed file:

- _posts/2026-09-15-supporter-spotlight-jochen-sprickerhof.md


Changes:

=====================================
_posts/2026-09-15-supporter-spotlight-jochen-sprickerhof.md
=====================================
@@ -37,7 +37,7 @@ I started my Debian journey as a teenager, converting my school to Debian and se
 **Jochen:**
 A recent example is [*metasnap.debian.net*](https://metasnap.debian.net). It is a 'meta archive' of
 [*snapshot.debian.org*](https://snapshot.debian.org) which is itself archive of all packages in Debian. But let
-me explain it the other way round: with *reproduce.debian.net*, we try to reproduce the packages as they are distributed by the Debian archive. For that, we need the same build environment (compilers, libraries, build tools, etc) that was used by Debian back when the original package was compiled. Luckily, *snapshot.debian.org* has all those packages, but they are not easily accessible via *apt*, Debian's package manager. So, *metasnap* provides a mapping from a package name and version pair to the APT repo on *snapshot.debian.org* needed to download it from. It was created by `josch` some time ago, and is an awesome work. But when we tried to reproduce more and more packages on *reproduce.debian.net*, we found that some were missing packages from the build environment — even though they where visible on *snapshot.debian.org*. We found that *metasnap* excluded some archive areas because they where not expected to be needed. Reimporting all the data took more than two months and surfaced a couple more flaws.
+me explain it the other way round: with *reproduce.debian.net*, we try to reproduce the packages as they are distributed by the Debian archive. For that, we need the same build environment (compilers, libraries, build tools, etc) that was used by Debian back when the original package was compiled. Luckily, *snapshot.debian.org* has all those packages, but they are not easily accessible via *apt*, Debian's package manager. So, *metasnap* provides a mapping from a package name and version pair to the APT repo on *snapshot.debian.org* needed to download it from. It was created by `josch` some time ago, and it's awesome work. But when we tried to reproduce more and more packages on *reproduce.debian.net*, we found that some were missing packages from the build environment — even though they where visible on *snapshot.debian.org*. We found that *metasnap* excluded some archive areas because they where not expected to be needed. Reimporting all the data took more than two months and surfaced a couple more flaws.
 
 With this fixed, we were able to build more packages, only to find out that *metasnap* also needs better support for version numbers. Luckily we were able to rewrite the data in a day instead of starting the import again.
 



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

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/7e141852c0b9519934f6ddda34e79a37cbf9de3a
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/20260903/a692332e/attachment.htm>