[Git][reproducible-builds/reproducible-presentations][master] 23 commits: seagl-two-ways: Only mark contribution years for guix.
Vagrant Cascadian (@vagrant)
gitlab at salsa.debian.org
Fri Nov 8 15:09:04 UTC 2024
Vagrant Cascadian pushed to branch master at Reproducible Builds / reproducible-presentations
Commits:
717adcad by Vagrant Cascadian at 2024-11-07T11:01:43-08:00
seagl-two-ways: Only mark contribution years for guix.
- - - - -
d0763967 by Vagrant Cascadian at 2024-11-07T11:10:36-08:00
seagl-two-ways: dynamic bullet points.
- - - - -
a4eed847 by Vagrant Cascadian at 2024-11-07T11:28:51-08:00
seagl-two-ways: split bootstrappable slides.
- - - - -
43db89ca by Vagrant Cascadian at 2024-11-07T11:29:38-08:00
seagl-two-ways: relatively specific times.
- - - - -
00c676e4 by Vagrant Cascadian at 2024-11-07T11:31:24-08:00
seagl-two-ways: flesh out some details about building debian/guix packages.
- - - - -
2cc5a5ea by Vagrant Cascadian at 2024-11-07T11:39:25-08:00
seagl-two-ways: on correctness and annoyance.
- - - - -
bf4a48d1 by Vagrant Cascadian at 2024-11-07T11:45:08-08:00
seagl-two-ways: Drop redundant vcs slide.
- - - - -
8da9c27c by Vagrant Cascadian at 2024-11-07T11:59:02-08:00
seagl-two-ways: build tools for debugging Debian reproducibility.
- - - - -
e589e27e by Vagrant Cascadian at 2024-11-07T12:07:18-08:00
seagl-two-ways: minimize trust, emphazied auditability and verifyabiliy.
- - - - -
8f1d3d01 by Vagrant Cascadian at 2024-11-07T12:16:15-08:00
seagl-two-ways: expand upon those nineteen years
- - - - -
fb74655b by Vagrant Cascadian at 2024-11-07T12:18:58-08:00
seagl-two-ways: better time specifications
- - - - -
e6781727 by Vagrant Cascadian at 2024-11-07T12:24:25-08:00
seagl-two-ways: transition from history into vcs practices
comparisons.
- - - - -
3761105c by Vagrant Cascadian at 2024-11-07T12:27:38-08:00
seagl-two-ways: vcs comparisons
- - - - -
8fc8549c by Vagrant Cascadian at 2024-11-07T12:39:17-08:00
seagl-two-ways: Add example .buildinfo file.
- - - - -
17c0e0d1 by Vagrant Cascadian at 2024-11-07T12:55:04-08:00
seagl-two-ways: Markup some commands in BEGIN_SRC headers.
- - - - -
23167722 by Vagrant Cascadian at 2024-11-07T13:32:57-08:00
seagl-two-ways: add some troubleshooting slides.
- - - - -
a2a59488 by Vagrant Cascadian at 2024-11-07T13:36:07-08:00
seagl-two-ways: imperfect guix troubleshooting.
- - - - -
afc4b451 by Vagrant Cascadian at 2024-11-07T13:41:15-08:00
seagl-two-ways: wrap more guix calls in BEGIN_SRC header.
- - - - -
2ed748f9 by Vagrant Cascadian at 2024-11-07T13:42:06-08:00
seagl-two-ways: Split reprotest into own slide.
- - - - -
4ebf20e3 by Vagrant Cascadian at 2024-11-07T13:46:06-08:00
seagl-two-ways: wrap commands in headers and include real examples.
- - - - -
70e0e109 by Vagrant Cascadian at 2024-11-07T13:51:25-08:00
seagl-two-ways: split notes into separate file.
- - - - -
931e2dfd by Vagrant Cascadian at 2024-11-07T13:58:21-08:00
seagl-two-ways: simplify example used for debrebuild.
- - - - -
da89be7e by Vagrant Cascadian at 2024-11-07T14:02:27-08:00
seagl-two-ways: give a short description of debrebuild/debrepro.
- - - - -
2 changed files:
- + 2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.notes.txt
- 2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.org
Changes:
=====================================
2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.notes.txt
=====================================
@@ -0,0 +1,160 @@
+* Why compare these two Operating Systems?
+
+They are examples of projects with a very different history,
+organizational structure and even rarer, fundamental differences in
+their approach to packaging
+
+* Fundamental Security vs. Individual issues
+
+Fundamental security allows you to work with confidence that the
+source code is actually what produces the running code.
+
+Without fixing fundamental security problems, without tying the issues
+back to the actual source code, attempting to fix individual issues
+with patches to source code may not have the desired effect.
+
+* Strong vs. Loose maintainership models
+
+Debian has historically had a strong maintainership model, gradually
+moving towards various forms of collaborative maintenence (teams,
+opt-in weaker non-maintainer upload requirements). Updating a package
+maintained by someone else requires a additional processes, at least
+socially. Technically, anyone can upload anything.
+
+Guix is a very weak model; there are not specific maintainers for
+specific packages.
+
+* Middle of the road maintenence
+
+Guix is moving towards more identified ownership, having adding teams
+and more structured expectations for review of updates, though it is
+not comprehensive.
+
+Debian has moved many packages towards team-maintenence or or weakened
+requirements to update an individual package.
+
+* Bootstrapping
+
+You can build guix from a very small set of bootstrap seeds, and end
+up with a bit-for-bit reproducible result for most of the operating
+system. They have historically recorded all of the bootstrap seeds
+from the very beginning.
+
+Exactly how Debian was bootstrapped is more or less lost to
+history. Some compiler was used decades ago to build early versions of
+Debian, and then Debian was used to build newer versions of itself,
+over the course of decades. There is to my knowledge no way to
+reproduce these original bootstrap environments.
+
+* Apples to Kumquats
+
+In Debian each package may have a separate git repository, if any at
+all. It May be hosted on infrastructure outside of Debian. The
+packaging may be a more-or-less complete copy of what is uploaded to
+the archive, or simply the Debian packaging parts.
+
+The entirety of Guix is maintained in a single git repository,
+although this git repository typically only contains references of how
+to download the code from largely infrastructure outside of guix.
+
+* A Bee Eye
+
+Debian infrastructure plans on ABI compatibility, to avoid rebuilding
+the world all the time. It mostly works ok.
+
+Guix rebuilds everything any time a change in a dependency is
+changed. Recursively. Just to make sure it works.
+
+Security fixes for low level packages would require world rebuilds in
+guix, so sometimes guix cheats.
+
+* Sources and Binaries
+
+Debian is fundamentally a binary based distribution.
+
+Guix is a source-based distribution, that distributes binaries as an
+optimization.
+
+* Archiving Reproducibly
+
+This requires very different archival needs, in order to be able to
+get a sufficiently similar build environment.
+
+snapshot.debian.org has had some historic troubles and misses soem
+generations of both binary and source packages.
+
+guix relies on softwareheritage.org to archive the upstream sources,
+as well as some other projects, such as disarchive. Binaries might be
+available, but are semi-frequently garbage collected.
+
+* Building Trust
+
+How do you know who is responsible?
+
+Both projects have structures and teams who handle important things such as security issues.
+
+The Debian security team has had for some years some rotating
+responsibilities with who handles newly identified security issues,
+and works with maintainers to facilitate that the updates follow
+appropriate processes.
+
+Guix also has a team of folks as a security point of contact, though
+my understanding is that it is a bit more informal at this point.
+They have some technical challenges working around security fixes that
+would normally trigger world rebuilds.
+
+Both projects try to be clear and transparent about how they approach
+individual security issues when identified, having teams of trusted
+people who carry out this often thankless work.
+
+* On Youth and Maturity
+
+Guix is a much younger project (2012) and in stage of faster
+evolution, largely focused on a primary development branch in a
+rolling release. It is gradually growing and experimenting with the
+need for more formal or complicated structures.
+
+Debian is a much older project (1993) and mature, often with multiple
+concurrent releases (stable, oldstable, oldoldstable), a development
+branch (testing) and a staging area (unstable), with more established
+guidelines and careful challenging processes for widespread
+change. Sometimes it is conservative to move, having so many competing
+interests within Debian.
+
+* The Scales are Unbalanced
+
+Guix has tens or maybe hundreds of active contributors.
+
+Debian has thousands of active contributors.
+
+They both maintain tens of thousands of packages.
+
+* Being Nimble
+
+In a sense Debian is too big to respond swiftly to big changes. It
+has taken the Reproducible Builds project many years to nudge the many
+packages and projects within towards reproducibility.
+
+To make a change in Debian that affects, say, 5000 packages, you may
+need to make many changes in the individual packages.
+
+In contrast, guix can make some wide-sweeping changes in a single git
+commit.
+
+* Subtle Nuance
+
+Debian is, in some ways, a collection of many small projects for each package.
+
+Guix is a smaller group leveraging those outside projects to create
+packages.
+
+* what you need
+
+to audit code you need to be able to:
+
+- see it (free software)
+
+- bootstrap it (confidence in the used toolchain)
+
+- know the running code is produced from the source code (Reproducible
+ Builds)
=====================================
2024-11-08-SeaGL-Two-Ways-to-Trustworthy/Two-Ways-to-Trustworthy.org
=====================================
@@ -55,16 +55,63 @@ security might evolve, with real-world merits and downsides.
| debian user | 2001 |
| debian developer | 2010 |
| reproducible builds | 2015 |
- | guix user | 2016? |
| guix contributor | 2017 |
| guix committer | 2019 |
* Trustworthy vs. Trust
Trustworthy projects require little Trust
-- auditable
-- verifiable
-- blind trust not required (caveats apply)
+
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- Auditable
+- Verifiable
+- Trust should be minimized
+
+* Archaic and Relative time
+
+Debian 1.5 score and a year ago
+
+Guix 0.5 score and a couple years ago
+
+* Specified time
+
+Debian founded 1993
+
+Guix founded 2012
+
+* A Human Generation apart
+
+What happened in those nineteen years between 1993 and 2012?
+
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- massive adoption of free and open source technologies
+- plethora of software distributions
+- version control became a common best practice
+
+* Variably Crude, Sisyphus
+
+Debian
+
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- predates modern version control
+- one repository per package
+- in a variety of packaging formats (source included, debian/ dir only, etc.)
+- not all on debian infrastructure
+- not all packages use version control
+- debian archive itself a crude sort of version control
+
+* Variably Crude, Sisyphus
+
+Guix
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- git was dominant VCS from the beginning
+- all of guix in a single shared git repository
+- git only contains references to other archives of software
+- full source code mostly on infrastructure outside of guix
* Reproducible Builds
@@ -88,14 +135,11 @@ identical copies of all specified artifacts.
[[./images/reproducible-builds.png]]
-* In practice
-
-- record the build environment
-- recreate the build environment
-
* Binaries at Large
Debian is fundamentally a binary distribution
+#+ATTR_BEAMER: :overlay <+->
+- ...
- relies on ABI for when to rebuild packages
- a given package is built with a specific version
- other packages might use an ABI compatible version
@@ -104,265 +148,222 @@ Debian is fundamentally a binary distribution
* The Source With Optimizations
Guix is a fundamentally a source distribution
+#+ATTR_BEAMER: :overlay <+->
+- ...
- packages optionally pull from substitute server as needed, falling
back to building from source
- packages get rebuilt whenever their dependencies change
-- the current commit builds exactly one set of current packages
-
-* Variably Crude, Sisyphus
-
-Debian
-
-- predates modern version control
-- one repository per package (at best)
-- in a variety of packaging formats (source included, debian/ dir only, etc.)
-- not all on debian infrastructure
-- not all packages use version control
-- the source archive itself is a crude sort of version control
-
-Guix
-
-- git was dominant VCS from the beginning
-- all of guix in a single shared git repository
-- git only contains references to other archives of software
-
-* A score, half a score, and one year ago
-
-Debian 1993
-
-* Half a score and a couple years ago
-
-Guix 2012
-
-* A Human Generation apart
-
-Nineteen years between the start of Debian and Guix
-
-* The challenge of Guix
-
-guix challenge --verbose PACKAGE
-
-* The challenge of Guix
-
-guix challenge --verbose --diff=diffoscope PACKAGE
-
-* Checking in with guix
-
-guix build --check PACKAGE
-
-* Check again
-
-guix build --check --no-grafts --keep-failed PACKAGE
-
-diffoscope /gnu/store/...PACKAGE/ /gnu/store/...PACKAGE-check/
-
-* So many ways in Debian
-
-dpkg-buildpackage, debuild, sbuild, pbuilder, etc.
-
-* rebuilding debian
-
-debrebuild
-
-* Bootstrapping
+- a given guix git commit builds exactly one set of packages
-Guix is bootstrapped from 357 byte hex binary (and 25MB of static binaries)
+* Correctly annoying resources
-https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
+Guix is correct to rebuild, although a bit annoying and resource
+intensive
-The historic versions and their hashes are recorded in guix from very
-early on.
+Makes it difficult to accurately track reproducibility stats
-A simple Debian chroot is 522MB of binaries. The original sources used
-to build the binaries has been lost to time.
+* Correct enough and less annoying
-* Thanks
+Debian is mostly correct to rely on ABI, and less annoying and
+resource intensive
-Help make it happen!
+Fewer rebuilds makes it easier to track reproducibility stats
-https://reproducible-builds.org/contribute/
+* Reproducible Builds: Debian
-https://reproducible-builds.org/donate/
+Reproducible Builds in Debian
-https://reproducible-builds.org/who/sponsors
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- Record the build environment (.buildinfo)
+- Recreate the build environment
+- Perform the build!
+- Compare against the original
-* Copyright and attributions
-\addtocounter{framenumber}{-1}
-\tiny
-
- Copyright 2019-2024 Vagrant Cascadian <vagrant at reproducible-builds.org>
- Portions by contributors to the reproducible-builds.org website.
-
- This work is licensed under the Creative Commons
- Attribution-ShareAlike 4.0 International License.
+* Example .buildinfo
- To view a copy of this license, visit
- https://creativecommons.org/licenses/by-sa/4.0/
+#+BEGIN_SRC Makefile
+Source: libtext-simpletable-perl
+Version: 2.03-1
+Checksums-Sha256:
+ 7a285...a8b 10788 libtext-simpletable-perl_2.03-1_all.deb
+Build-Architecture: amd64
+Build-Date: Fri, 03 Mar 2017 07:56:17 +1400
+Build-Path: /build/libtext-simpletable-perl-2.03/2nd
+Installed-Build-Depends:
+ autoconf (= 2.69-10),
+ automake (= 1:1.15-6),
+ zlib1g (= 1:1.2.8.dfsg-5)
+Environment:
+ DEB_BUILD_OPTIONS="parallel=15"
+ LANG="C"
+ LC_ALL="C"
+ SOURCE_DATE_EPOCH="1439466701"
+#+END_SRC
-* Why compare these two Operating Systems?
+* Reproducible Builds: Debian
-They are examples of projects with a very different history,
-organizational structure and even rarer, fundamental differences in
-their approach to packaging
+.buildinfo files
-* Fundamental Security vs. Individual issues
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- Find the correct file: buildinfos.debian.net
+- Download the correct set of packages: snapshot.debian.org
+- Recreate the build environment
-Fundamental security allows you to work with confidence that the
-source code is actually what produces the running code.
+* The challenges of Reproducible Builds in Debian
-Without fixing fundamental security problems, without tying the issues
-back to the actual source code, attempting to fix individual issues
-with patches to source code may not have the desired effect.
+Debian Challenges
-* Strong vs. Loose maintainership models
+#+ATTR_BEAMER: :overlay <+->
+- ...
+- corner cases with versioning (epoch, source != binary version)
+- snapshot.debian.org may be missing some package versions
+- snapshot.debian.org was sometimes to slow to use
-Debian has historically had a strong maintainership model, gradually
-moving towards various forms of collaborative maintenence (teams,
-opt-in weaker non-maintainer upload requirements). Updating a package
-maintained by someone else requires a additional processes, at least
-socially. Technically, anyone can upload anything.
+* Reproducible Builds: Guix
-Guix is a very weak model; there are not specific maintainers for
-specific packages.
+Guix
-* Middle of the road maintenence
+#+ATTR_BEAMER: :overlay <+->
+- Record the commit hash of guix git
+- binary substitutes may not be available
+- sources may not be available
-Guix is moving towards more identified ownership, having adding teams
-and more structured expectations for review of updates, though it is
-not comprehensive.
+* The challenge of Guix
-Debian has moved many packages towards team-maintenence or or weakened
-requirements to update an individual package.
+#+BEGIN_SRC shell
+guix challenge --verbose PACKAGE
+#+END_SRC
-* Bootstrapping
+Compares against local builds and substitute servers.
-You can build guix from a very small set of bootstrap seeds, and end
-up with a bit-for-bit reproducible result for most of the operating
-system. They have historically recorded all of the bootstrap seeds
-from the very beginning.
+* The challenge of Guix
-Exactly how Debian was bootstrapped is more or less lost to
-history. Some compiler was used decades ago to build early versions of
-Debian, and then Debian was used to build newer versions of itself,
-over the course of decades. There is to my knowledge no way to
-reproduce these original bootstrap environments.
+#+BEGIN_SRC shell
+guix challenge --verbose --diff=diffoscope PACKAGE
+#+END_SRC
-* Very Credible Sources
+Compares differences using diffoscope!
-Debian predates modern version control systems, such as git.
+* Checking in with guix
-guix founded after git was already well established, if not even
-dominant.
+#+BEGIN_SRC shell
+guix build --check PACKAGE
+#+END_SRC
-* Apples to Kumquats
+* Check again
-In Debian each package may have a separate git repository, if any at
-all. It May be hosted on infrastructure outside of Debian. The
-packaging may be a more-or-less complete copy of what is uploaded to
-the archive, or simply the Debian packaging parts.
+#+BEGIN_SRC shell
+guix build --check --no-grafts --keep-failed PACKAGE
+#+END_SRC
-The entirety of Guix is maintained in a single git repository,
-although this git repository typically only contains references of how
-to download the code from largely infrastructure outside of guix.
+#+BEGIN_SRC shell
+diffoscope /gnu/store/...PACKAGE/ /gnu/store/...PACKAGE-check/
+#+END_SRC
-* A Bee Eye
+* So many ways in Debian
-Debian infrastructure plans on ABI compatibility, to avoid rebuilding
-the world all the time. It mostly works ok.
+Debian has many, many options...
+#+ATTR_BEAMER: :overlay <+->
+- dpkg-buildpackage
+- debuild
+- sbuild
+- pbuilder
+- etc.
-Guix rebuilds everything any time a change in a dependency is
-changed. Recursively. Just to make sure it works.
+* Rebuilding Debian packages
-Security fixes for low level packages would require world rebuilds in
-guix, so sometimes guix cheats.
+#+BEGIN_SRC shell
+debrebuild --builder=mmdebstrap hello_2.10-2_amd64.buildinfo
+#+END_SRC
-* Sources and Binaries
+#+ATTR_BEAMER: :overlay <+->
+- rebuild a package with a given .buildinfo file
+- Leverages snapshot.debian.org to recreate build environment from .buildinfo file
+- Active work in progress
-Debian is fundamentally a binary based distribution.
+* Troubleshooting Debian packages
-Guix is a source-based distribution, that distributes binaries as an
-optimization.
+#+BEGIN_SRC shell
+debrepro
+#+END_SRC
-* Archiving Reproducibly
+#+ATTR_BEAMER: :overlay <+->
+- build the package in the current working directory
+- no chroot or isolation
+- basic reproducibility check with some variations
-This requires very different archival needs, in order to be able to
-get a sufficiently similar build environment.
+* Troubleshooting Debian packages second edition
-snapshot.debian.org has had some historic troubles and misses soem
-generations of both binary and source packages.
+#+BEGIN_SRC shell
+reprotest --verbose --vary=-fileordering,-domain_host,-user_group,-time auto -- null
+#+END_SRC
-guix relies on softwareheritage.org to archive the upstream sources,
-as well as some other projects, such as disarchive. Binaries might be
-available, but are semi-frequently garbage collected.
+#+ATTR_BEAMER: :overlay <+->
+- reproducibility build checks with extensive variations
+- flexibly define which variations to use
+- options to "bisect" to identify nature of reproducibility issue
+- needs maintenence and updating
-* Building Trust
+* Troubleshooting Guix packages
-How do you know who is responsible?
+Guix troubleshooting
-Both projects have structures and teams who handle important things such as security issues.
+#+BEGIN_SRC shell
+guix build --keep-failed PACKAGE
+#+END_SRC
-The Debian security team has had for some years some rotating
-responsibilities with who handles newly identified security issues,
-and works with maintainers to facilitate that the updates follow
-appropriate processes.
+Keeps the source tree to re-try the build manually, perhaps with...
-Guix also has a team of folks as a security point of contact, though
-my understanding is that it is a bit more informal at this point.
-They have some technical challenges working around security fixes that
-would normally trigger world rebuilds.
+* Imperfect troubleshooting
-Both projects try to be clear and transparent about how they approach
-individual security issues when identified, having teams of trusted
-people who carry out this often thankless work.
+#+BEGIN_SRC shell
+guix shell --container --development PACKAGE
+#+END_SRC
-* On Youth and Maturity
+Which produces a very similar environment to the build, but not the same...
-Guix is a much younger project (2012) and in stage of faster
-evolution, largely focused on a primary development branch in a
-rolling release. It is gradually growing and experimenting with the
-need for more formal or complicated structures.
+Pretty much stuck iterating build after build entirely from source,
+partial builds are not really possible.
-Debian is a much older project (1993) and mature, often with multiple
-concurrent releases (stable, oldstable, oldoldstable), a development
-branch (testing) and a staging area (unstable), with more established
-guidelines and careful challenging processes for widespread
-change. Sometimes it is conservative to move, having so many competing
-interests within Debian.
+* Bootstrapping: Debian
-* The Scales are Unbalanced
+A simple Debian chroot is 522MB of binaries.
-Guix has tens or maybe hundreds of active contributors.
+The original sources used to build the original binaries have been
+lost to time.
-Debian has thousands of active contributors.
+* Bootstrapping: Guix
-They both maintain tens of thousands of packages.
+Guix is bootstrapped from 357 byte hex binary (and 25MB of static
+binaries)
-* Being Nimble
+https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/
-In a sense Debian is too big to respond swiftly to big changes. It
-has taken the Reproducible Builds project many years to nudge the many
-packages and projects within towards reproducibility.
+The historic versions and their hashes are recorded in guix from very
+early on.
-To make a change in Debian that affects, say, 5000 packages, you may
-need to make many changes in the individual packages.
-In contrast, guix can make some wide-sweeping changes in a single git
-commit.
+* Thanks
-* Subtle Nuance
+Help make it happen!
-Debian is, in some ways, a collection of many small projects for each package.
+https://reproducible-builds.org/contribute/
-Guix is a smaller group leveraging those outside projects to create
-packages.
+https://reproducible-builds.org/donate/
-* what you need
+https://reproducible-builds.org/who/sponsors
-to audit code you need to be able to:
+* Copyright and attributions
+\addtocounter{framenumber}{-1}
+\tiny
-- see it (free software)
+ Copyright 2016-2024 Vagrant Cascadian <vagrant at reproducible-builds.org>
+ Portions by contributors to the reproducible-builds.org website.
-- bootstrap it (confidence in the used toolchain)
+ This work is licensed under the Creative Commons
+ Attribution-ShareAlike 4.0 International License.
-- know the running code is produced from the source code (Reproducible
- Builds)
+ To view a copy of this license, visit
+ https://creativecommons.org/licenses/by-sa/4.0/
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/c399956ee6d04e7fb106774a9f5fe65e4309ebb7...da89be7ea69e9bf535d57c0a71bab8621bdf3fa5
--
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-presentations/-/compare/c399956ee6d04e7fb106774a9f5fe65e4309ebb7...da89be7ea69e9bf535d57c0a71bab8621bdf3fa5
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/20241108/2f271a0d/attachment.htm>
More information about the rb-commits
mailing list