[Reproducible-builds] Bug#798558: Bug#798557: libapache-dbi-perl: please make the build reproducible

[Niko Tyni]

On Thu, Sep 10, 2015 at 07:25:52PM +0200, Dhole wrote:
> On 09/10/2015 06:10 PM, Niko Tyni wrote:
> > This is a toolchain issue that potentially affects hundreds of packages
> > and should IMO be fixed centrally, at least for those packages that use
> > these debhelper short form dh rules.
> > 
> After thinking about it, I agree too; a toolchain fix would be more
> appropriate for this podman issue.
> 
> What do you think would be a better solution?
> - Make debhelper export POD_MAN_DATE

This was the plan before we had the SOURCE_DATE_EPOCH spec.
While I agree with Chris that it isn't very pretty, I don't think
it's quite that bad a layering violation as it could be done
only for the perl_build and perl_makemaker subsystems. I would
expect that to fix the vast majority of issues.

> - Patch podman to honour SOURCE_DATE_EPOCH (with this option, podman
> would replace embedded timestamp either by the env var POD_MAN_DATE, or
> by SOURCE_DATE_EPOCH. The later would need formatting the timestamp to
> "%Y-%m-%d")

Yes, I think this would probably be better. I suppose POD_MAN_DATE should
override SOURCE_DATE_EPOCH as a more specific variable.

This has a sort of déjà vu effect as pod2man upstream (Russ Allbery,
cc'd) already accepted POD_MAN_DATE for this purpose. Russ, what do you
think about supporting SOURCE_DATE_EPOCH too? For reference, the spec
is at <https://reproducible-builds.org/specs/source-date-epoch/>.

> > The reason only a handful show up in the current reproducible.debian.net
> > CI setup is that it only triggers when the two builds happen on different
> > sides of midnight UTC. Once we start testing builds on different dates,
> > I expect the number of those to explode.
> > 
> The difference that shows up in the affected packages in
> reproducible.debian.net show a difference in the day within the
> timestamp, because we use two different timezones between builds that
> have a 26h difference. That makes the embedded timestamp to have a
> different day whenever the package is built. I don't understand why when
> we start testing builds on different dates you expect this to explode.
> Am I missing anything? Maybe you are referring to timestamps in general,
> and not only to this podman embedding timestamps issue? (in which case,
> I'd agree that the number of issues like this will explode)

The piece you're missing is that Pod::Man already normalizes the time
zone to UTC when generating the date, see #780259. So the TZ variation
on reproducible.debian.net doesn't trigger the issue anymore but a real
clock difference would.

The two packages discussed here were indeed tested at midnight UTC
by chance, and the issues will vanish again when they get re-tested.
-- 
Niko Tyni   ntyni at debian.org