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

Fixed title to match bug...

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.

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?

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


live well,
  vagrant

Hi Vagrant,

The package contains metadata for external repositories. If the package
is updated, it is a good thing that the metadata is made more recent; it
makes no sense to provide metadata for repositories that are no longer
accessible.

I have not yet considered whether we want to provide common updates to
stable. Perhaps I should talk to the SRMs about that...

At any rate, the purpose of this package is to provide an alternative to
the online version of the same data that can be downloaded through a
pages.debian.net URL. Thus it should be as similar as possible to that
one.

Which in the context of extrepo-data is a feature, not a bug.

Possibly, I don't know what the reasoning behind all that is :)

Indeed.

If you missed it, I have just opened a thread in debian-release@l.d.o
about it. Please join the discussion.

Agreed.

Thomas Goirand (zigo)