Open gregoa opened 3 months ago
We see the same on openSUSE: https://build.opensuse.org/package/live_build_log/devel:languages:perl/perl-Data-Fake/openSUSE_Tumbleweed/i586
Here's a workaround that seems to work on Debian 32bit architectures:
Description: Time::Piece's strptime() fails with timestampgs >= 2**31 on 32bit perls
As a workaround, add an upper limit for future timestamps.
Origin: vendor
Bug: https://github.com/dagolden/Data-Fake/issues/15
Bug-Debian: https://bugs.debian.org/1071967
Author: gregor herrmann <gregoa@debian.org>
Last-Update: 2024-07-13
--- a/lib/Data/Fake/Dates.pm
+++ b/lib/Data/Fake/Dates.pm
@@ -17,12 +17,17 @@
);
use Time::Piece 1.27; # portability fixes
+use Config;
sub _past { int( rand(time) ) }
sub _future {
my $now = time;
- return $now + int( rand($now) );
+ if ($Config{longsize} == 8) {
+ return $now + int( rand($now) );
+ } else {
+ return $now + int( rand(2**31 - 1 - $now) );
+ }
}
#pod =func fake_past_epoch
Does this make sense for openSUSE as well, @perlpunk?
(Ultimately, this feels like a Time::Piece bug …)
@gregoa yes, this works, thanks :)
t/dates.t
fails on X86_32, as seen on https://ci.debian.net/packages/libd/libdata-fake-perl/testing/i386/46574760/#S6Running the tests locally I get on amd64 (X86_64):
On i386 (X86_32) I get:
It looks to me like
fake_future_datetime
inlib/Data/Fake/Dates.pm
callsTime::Piece
which fails instrptime()
with dates beyond the infamous time_t 32bit / 2038 border …Not sure if this is a bug in Data::Fake, Time::Piece, Debian's perl or somewhere else but maybe handling Time::Piece errors more gracefully in Data::Fake might be possible.
Cheers, gregor, Debian Perl Group