[Reproducible-builds] getting dpkg ready for reproducible sid

[Guillem Jover]

Hi!

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 ?

No need.

Thanks,
Guillem