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 nt...@debian.org
