Re: getting dpkg ready for reproducible sid
On Mon, 2016-05-09 at 12:26:13 +0000, Holger Levsen wrote:
> Looking at this I notice we have some changes without bugs and some
> changes involving several bugs, still I think it would be good to
> discuss them as uploaded.
> IOW: dear dpkg maintainers, what are your comments regarding getting the
> following changes into sid:
> a.) single timestamp for ar headers
Pending rereview of local changes, and staged until the treewalk
changes have brewed in the rebootstrap, reproducible rebuilds and
in unstable for a bit.
I might have added this earlier if the treewalk code had been tested
earlier, but didn't want to entangle these kind of changes together
w/o prior wide testing.
> b.) common build timestamp for all files created at a later time
Pending release of new upstream tar. And the patch reworked to stop
trying to detect the presence of --clamp-mtime at run-time.
> c.) build timestamp using SOURCE_DATE_EPOCH
Should be fine, I've added infrastructure to not have to use
date(1), but otherwise should get in probably for 1.18.8 already.
> d.) preset build timestamp to latest changelog entry
I've been reluctant to consider this before the .buildinfo is
generated and ideally actually stored in ftp-master. But I think
at this point, I think I'll just merge it, so that we can get
reproducible ar containers in the archive. Or I could merge WIP
.buildinfo support and mark it as Format 0.0 and then we can tune
it until we consider it ready and then mark it 1.0, let's see.
> e.) normalize file permissions when creating control.tar
The current change in the repro git is not correct as it changes the
perms for control.tar and data.tar. The side-effects of refactoring!
I've to take a look at this.
> f.) add support for .buildinfo files
I need to finish commenting on this, hopefully in the coming days.
And wasn't it missing at least man pages for the .buildinfo file?
> g.) teach dpkg-genbuildinfo the new --build=[...] syntax
This should be squashed in the existing patch before submission.
> And, do we need bugs for a+b+c+g ?