Bug#774422: perl: please make perl builds reproducible

[Niko Tyni]

clone 774422 -1
retitle -1 perl: build timezone affects LOCALTIME_{MIN,MAX}
severity -1 normal
thanks

On Mon, May 04, 2015 at 02:28:04PM +0200, Jérémy Bobbio wrote:
 
> Here's an update after rebasing my patches on 5.20.2-4.

Thanks. I had a look at this and will try to get a reproducible 5.22
package into experimental soonish. It looks like the only thing that
needs upstream source changes (as opposed to configuration) is the
__DATE__/__TIME__ stuff. I understand the 'ar D' patch isn't necessary
anymore since binutils was changed.

I'll discuss at least the __DATE__ part upstream, but I think disabling
it at this phase should be good enough.

> Niko Tyni:

> >   I assume varying uname et al. isn't actively tested yet?
> 
> We do now test it by calling `linux64 --uname-2.6`. It will make the
> version look like 2.6.56-4. And indeed, this is an issue.

> I'm not sure what's the best answer here. Always use 2.6.42? As in
> Debian we can't really know which version of the kernel the package is
> going to be used with, it should stay compatible with older kernels as
> much as possible.

It gets worse when we take kfreebsd and hurd into account too, but
maybe we shouldn't care about those at this point.

I suspect the uname (stored as $Config{myuname}) doesn't matter much:
codesearch.debian.net only finds libcrypt-openssl-x509-perl using it
(and even that should probably use $^O instead, which gives the runtime
OS name instead of the build time one.)

As for osvers, which has much more hits, I think it should be good enough
to hardcode a version that approximates a ~current Debian stable kernel.

My current candidate for an override in config.debian is this monstrosity:

myhostname=localhost
case "$osname" in
  linux)
      osvers=3.16.0
      osdesc="#1 smp debian $osvers"
      os=gnulinux
      ;;
  gnu)
      osvers=0.6
      osdesc="gnu-mach"
      os=gnu
      ;;
  gnukfreebsd)
      osvers=9.0
      osdesc="#0"
      os=gnukfreebsd
      ;;
esac
if [ -n "$osdesc" ]; then
  machine_uname=$(uname -m | tr '[A-Z]' '[a-z]' | sed -e "s,['/],,g")
  myuname="$osname $myhostname $osvers $osdesc $machine_uname $os "
fi

which probably is too much work for little gain.

Not sure if "leaking" uname -m output is appropriate, but making
that constant between architectures doesn't feel right either.

> Another issue that surfaced now that we are doing timezone variations is
> that LOCALTIME_MIN and LOCALTIME_MAX gets different values depending on
> the value of the TZ environment variable.

> The minimum I had on my amd64 system is with TZ=UTC-24, -62167305600.
> The maximum is with TZ=UTC and is 67768036191590399.
> 
> It feels like a bug to have something that can be configured through an
> environment variable on a running system affect what gets encoded in the
> binary.

This feels like a bug to me too, and should be handled separately.
I'm cloning this and will export TZ=UTC in debian/rules, at least
for now.
-- 
Niko Tyni   ntyni at debian.org