Debian Bug report logs - #1020648
extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: submit@bugs.debian.org

Subject: extrepo-data: reproducible builds: Timestamps recorded for all packaged files

Date: Sat, 24 Sep 2022 12:44:35 -0700

[Message part 1 (text/plain, inline)]

Source: extrepo-data
Severity: normal
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org, distro-info@packages.debian.org

It seems extrepo-data embeds different repository information depending
on when it is built, inferring the resolution of the "testing" suite to
a specific named released based on the current date (e.g. bookworm
vs. trixie).

  https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/extrepo-data.html

  usr/share/extrepo/offline-data/debian/trixie/consol.asc
  vs.
  usr/share/extrepo/offline-data/debian/bookworm/consol.asc

This is because extrepo-data calls DebianDistroInfo->new() from
libdistro-info-perl:

  tools/lib/ExtRepoData.pm:my $info = DebianDistroInfo->new();

Which resolves testing to a suite based on the current date.


The attached patch works around this by explicitly passing the codenames
instead of the "testing" suite, though I am not sure the specified
repositories actually exist, so should require further verification
before applying. There may be similar issues with using "stable" suites
as well, though I have not found any examples at the moment.


There are likely better ways to resolve this issue (e.g. adding
SOURCE_DATE_EPOCH support to libdistro-info-perl), though hopefully
someone with a bit more perl skills can tackle that. Specifying suites
explicitly might be better than relying on a "testing" suite that may
change codename regardless of weather libdistro-info-perl is fixed
anyways. (e.g. a security or stable or oldstable update might result in
a package with totally with different respositories).


With this patch applied, extrepo-data should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining extrepo-data!


live well,
  vagrant

[0001-Avoid-using-testing-which-produces-different-results.patch (text/x-diff, inline)]

From eccf2ad7e59696bd9c2dd4f1db58ab15ef628968 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagrant@reproducible-builds.org>
Date: Sat, 24 Sep 2022 19:19:52 +0000
Subject: [PATCH] Avoid using "testing" which produces different results
 depending on the current date.

This is because extrepo-data uses DebianDistroInfo->new() from
libdistro-info-perl, which does not appear to provide the ability to
pass a desired time, or respect SOURCE_DATE_EPOCH.
---
 repos/debian/consol.yaml      | 3 ++-
 repos/debian/feistermops.yaml | 4 +++-
 repos/debian/janitor.yaml     | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/repos/debian/consol.yaml b/repos/debian/consol.yaml
index dd26d83..65a81ac 100644
--- a/repos/debian/consol.yaml
+++ b/repos/debian/consol.yaml
@@ -10,7 +10,8 @@ consol:
   suites:
   - buster
   - bullseye
-  - testing
+  - bookworm
+  - trixie
   - unstable
   policy: main
   gpg-key: |
diff --git a/repos/debian/feistermops.yaml b/repos/debian/feistermops.yaml
index c2a96ce..a9b43c8 100644
--- a/repos/debian/feistermops.yaml
+++ b/repos/debian/feistermops.yaml
@@ -17,7 +17,9 @@
       "jessie",
       "sid",
       "stretch",
-      "testing",
+      "bullseye",
+      "bookworm",
+      "trixie",
       "wheezy"
     ]
   }
diff --git a/repos/debian/janitor.yaml b/repos/debian/janitor.yaml
index 1259be4..644ec66 100644
--- a/repos/debian/janitor.yaml
+++ b/repos/debian/janitor.yaml
@@ -13,7 +13,7 @@ janitor:
     - sid
     - bookworm
     - unstable
-    - testing
+    - trixie
 
   policy: main
 
-- 
2.30.2

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 1020648@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: 1020648@bugs.debian.org

Subject: 1020648 extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date

Date: Sat, 24 Sep 2022 13:08:28 -0700

[Message part 1 (text/plain, inline)]

Control: retitle 1020648 extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date

Fixed title to match bug...

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 1020648-submitter@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: 1020648-submitter@bugs.debian.org

Subject: This is on purpose...

Date: Sat, 8 Apr 2023 13:31:23 +0200

Control: tags 1020648 - patch

This behavior is on purpose. The build system is used for the one on
salsa too, and there we *want* the name "testing" (as well as the name
"stable") to resolve to "whatever is current".

The build is reused for the package, because we want to make 100% sure
that the contents of the package (at the time of the package build, at
least) is the same as what would be served on the website.

Looking at the source of Debian::DistroInfo, there does not currently
appear to be a way to ask for information at a given date, but that
sounds like a reasonable wishlist for Debian::DistroInfo to provide.

Once that's available, updating extrpo-offline-data to use that to build
on a source epoch in the past seems like a reasonable course of action
to fix this bug.

The patch as given is unacceptable, for reasons as explained above.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Message #22 received at 1020648-quiet@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: Wouter Verhelst <w@uter.be>, 1020648-quiet@bugs.debian.org

Subject: Re: Bug#1020648: extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date

Date: Sat, 08 Apr 2023 20:23:29 -0700

[Message part 1 (text/plain, inline)]

On 2023-04-08, Wouter Verhelst wrote:
> This behavior is on purpose. The build system is used for the one on
> salsa too, and there we *want* the name "testing" (as well as the name
> "stable") to resolve to "whatever is current".
>
> The build is reused for the package, because we want to make 100% sure
> that the contents of the package (at the time of the package build, at
> least) is the same as what would be served on the website.

This is probably because I am not understanding something, but how would
you perform a security update or update for a stable point release?

The package ends up shipping entirely different repository information
based on when you happen to build the package. In the case of the
tests.reproducible-builds.org, we are building a little over a year in
the future, and I guess DistroInfo is hard-coding when it expects future
distributions to become testing?


> Looking at the source of Debian::DistroInfo, there does not currently
> appear to be a way to ask for information at a given date, but that
> sounds like a reasonable wishlist for Debian::DistroInfo to provide.
>
> Once that's available, updating extrpo-offline-data to use that to build
> on a source epoch in the past seems like a reasonable course of action
> to fix this bug.

Yes, this sounds like that a better way to fix the issue overall!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.