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 nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
