Hi! Here's an update after rebasing my patches on 5.20.2-4.
Niko Tyni:
> - the build system also embeds information about the build host, at
> least the kernel version and hostname. Those need to be stripped too.
> From 'perl -V':
>
> osname=linux, osvers=3.16.0-4-amd64,
> archname=x86_64-linux-gnu-thread-multi
> uname='linux estella 3.16.0-4-amd64 #1 smp debian 3.16.7-ckt2-1
> (2014-12-08) x86_64 gnulinux '
>
> 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.
The kernel version shows in Config.pm (`osvers`), Config_heavy.pl
(`osvers`).
The full uname is shown in Config_heavy.pl (in a comment, and in
`myuname`), in CORE/config.h (in a comment, in `OSVERS`), and in the
binaries.
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.
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.
This shows in CORE/conf.h, in Config_heavy.pl, and in the binaries.
If I read it right, `sLOCALTIME_min` and `sLOCALTIME_max` can be
overloaded from `Configure`.
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.
--
Lunar .''`.
lu...@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
