-
Notifications
You must be signed in to change notification settings - Fork 28
[1.2.3] use debian's package snapshot repo for old buster packages needed in reproducible build #1834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
linh2931
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just keep this way until 2.0 (as 2.0 already changed) so that 1.x users will not see breaking changes.
tools/reproducible.Dockerfile
Outdated
| RUN <<EOF | ||
| cat <<EOS > /etc/apt/sources.list | ||
| deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/$(date -d @${SOURCE_DATE_EPOCH} +%Y%m%dT%H%M%SZ)/ buster main | ||
| deb [check-valid-until=no] http://snapshot.debian.org/archive/debian-security/$(date -d @${SOURCE_DATE_EPOCH} +%Y%m%dT%H%M%SZ)/ buster/updates main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While scrutinizing this method some I realized an oversight: This only includes the 'buster' and 'buster security'1. It does not include 'buster-updates'. I probably copied the template from the main https://snapshot.debian.org/ page but that example is for ancient lenny.
I will need to make a small tweak to include 'buster-updates'. Probably no fatal issue to leave it out but it's unrepresentative of what really was released at this given date otherwise.
Footnotes
-
Which is confusingly the 'buster/updates' suite -- this is probably how I got confused. On Debian 11+ this is more clearly named something like 'trixie-security'. ↩
linh2931
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the PR title be [1.2.2]?
I thought for PRs to a release branch we use the version it will first be released in. Otherwise seems difficult when viewing a list of PRs to remember that something prefixed with 1.2.2 was actually first released in 1.2.3. That said it's not certain if this will be a 1.2.3 or a 1.2.2-1 sort of thing |
Oh, 1.2.3 makes sense then. |
Unfortunately it is no longer possible to build the 1.x pinned/reproducible package from scratch because it is based on Debian 10 which has had its packages removed from Debian's package repo around July 12 (it has been out of support for about a year now).
This moves the build to use Debian's package snapshot repo which contains all prior releases. This was previously plumbed through here (since pinning to exact packages would presumably be even more reproducible), though I had disabled it in the past since the package snapshot repo can be kind of slow.
Taking this approach will ensure no operational changes to any users who are using 1.2.x on an old distribution like Ubuntu 18. Though we didn't actually claim support for these old distributions, so it's not clear how aggressively we should maintain this compatibility. Maybe in 1.3 we could increase the base build to Debian 11 (it already is on our 2.0 branch).