[buildd-tools-devel] Bug#843773: Bug#843773: Bug#843773: misleading timestamps in binnmus

[Johannes Schauer]

Hi,

Quoting Ximin Luo (2016-11-10 18:13:00)
> Holger Levsen wrote:
> > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> > > binNMU to a package.
> > > 
> > > Any other ideas?
> > set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
> > entry?
> I'm tending towards the latter suggestion because it's simpler. There's no
> need to stick to a +1 second scheme etc, and it might mislead people into
> thinking they can do calculations with this - such as reversing the original
> timestamp of the sourceful-upload.

maybe I'm misunderstanding the problem but for the sake getting a better
picture, let me write a summary of the conversation so far:

Currently, buildds (using sbuild) create binNMU changelog entries by copying
the date from the last changelog entry. See for example
libghc-yesod-auth-oauth-dev. 16 binNMUs and the same timestamp is used for all
of them. In his original post, Ian complains that despite the package version
being incremented, the file mtimes are not. This is because we now use the
timestamp from the latest changelog entry for the mtimes of the binary package
contents so that the binary packages become reproducible. If we want to have
later mtimes for the files in binNMU binary packages compared the ones in the
last version, then the question becomes: which mechanism should we use to set
this timestamp?

I do not think that reproducibility is an issue here. No matter which mechanism
we choose to determine the timestamp of the new changelog entry, that timestamp
will be recorded in the Binary-Only-Changes field of the generated .buildinfo
file. The content of that field can then be used by package builders to
generate the new debian/changelog which in turn means that at the time that
dpkg-buildpackage is run, SOURCE_DATE_EPOCH will be set to a deterministic
value: the value of the last changelog entry which we obtain from the
Binary-Only-Changes field.

Back to the question of how we should determine the initial timestamp for the
new binNMU. One way would be to just use the timestamp of the time at which the
binNMU changelog entry is created by sbuild on the buildds. The problem with
this approach is, that binNMUs will be done at slightly different times on each
architecture and thus a different changelog timestamp will be used per
architecture. This does not cause Multi-Arch:same file conflicts because of the
changelog itself because these are stored in architecture-specific paths for
binNMUs (if dh_installchangelogs is used). Instead, file conflicts might be
created from files with content that depends on SOURCE_DATE_EPOCH. Because each
architecture will generate their own timestamp, SOURCE_DATE_EPOCH will be
different on each. If the content of shared files depends on the set timestamp,
then these packages will not be co-installable anymore. One solultion to this
problem would be to mandate that files shared across Multi-Arch:same binary
packages must be independent of SOURCE_DATE_EPOCH but that might impose too
much of a burden of writing and then maintaining the appropriate patches for
upstreams that refuse to become independent of SOURCE_DATE_EPOCH. Moving the
architecture-invariant but SOURCE_DATE_EPOCH dependent files to
Architecture:all packages is not a solution either because we might want the
packages containing these files be able to transport their architecture to
their dependencies.

Thus I think it would be best if the changelog timestamp for the same binNMU
version would be equal across all architectures. One way to achieve this would
be by using a unified scheme to generate the timestamps, for example by
incrementing the original timestamp by one second for each binNMU. Another way
to achieve this would be to require a timestamp to be supplied (or generated)
every time a binNMU is scheduled. That timestamp would then be passed to all
buildds and be used by sbuild to generate the new entry in debian/changelog.

What do you think?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161112/9e628db7/attachment.sig>