(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. Mraw, KiBi.
signature.asc
Description: Digital signature
