(Trimming a lot because running out of time.)

Steven Chamberlain <ste...@pyro.eu.org> (2015-11-17):
> Seems reasonable to factor out and put it here.  If we don't, someone
> may add a new $GZIP call later, forget -n and make it unreproducible
> again.
> Although it is a macro here, GZIP is also the name of an environment
> variable used by gzip (but not pigz?), which is likely confusing.  And
> the later tar invocations call gzip (not pigz) in quite a few places
> regardless of the GZIP macro contents;  those do look at the GZIP
> environment variable though.

Feel free to rename stuff as needed.

> > Finally, not everything is built using debian/rules targets (with or
> > without dpkg-buildpackage). One should still be able to just run e.g.:
> > “make -C build build_netboot-gtk USE_UDEBS_FROM=sid”
> > 
> > See BUILD_DATE handling, for example. We end up with a default setting
> > through:
> > |    build/config/common:BUILD_DATE ?= $(shell date -u '+%Y%m%d-%H:%M')
> That would not be reproducible, then!  (it is embedded in the tarballs)

Sure. I just meant to point out that even if BUILD_DATE is set through
debian/rules, a default value is set for users not building through
debian/rules, meaning BUILD_DATE gets set in the end, instead of just
being empty.

> > [ Please note that calling $(shell dpkg-parsechangelog -SDate) to set
> > SOURCE_DATE_EPOCH there would only work when building from the toplevel
> > directory, and not from the build/ subdirectory for example. ]
> If it's anyway not going to be reproducible, we could similarly fall
> back to a SOURCE_DATE_EPOCH ?= now;  or the caller could choose to
> provide them.


Attachment: signature.asc
Description: Digital signature

Reproducible-builds mailing list

Reply via email to