Page MenuHomePhabricator

[PATCH] [llvm-ranlib] Take in consideration UTC offset for D-flag.test
AbandonedPublic

Authored by zatrazz on Jan 9 2020, 6:30 AM.

Details

Summary

The llvm-ar uses localtime to print the object timestamp and it is
subject to UTC offset (daylight for instance). The patch changes
the test to check against output of a 'date' command.

It fixes the D-flag.test failure on some aarch64 and arm bots,
which are situated on GMT with currently BST timezone.

Diff Detail

Event Timeline

zatrazz created this revision.Jan 9 2020, 6:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 9 2020, 6:30 AM
kristof.beyls added inline comments.Jan 9 2020, 6:53 AM
llvm/test/tools/llvm-ranlib/D-flag.test
13

I wonder if 'date' is available on all platforms that LLVM builds on. For example, is it available on Windows (with GnuWin32 installed, as per the requirements listed at https://llvm.org/docs/GettingStartedVS.html)? http://gnuwin32.sourceforge.net/packages.html doesn't seem to list "date" explicitly?

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

arichardson added inline comments.Jan 9 2020, 7:15 AM
llvm/test/tools/llvm-ranlib/D-flag.test
23

Wouldn't this line also have to change?

zatrazz updated this revision to Diff 237134.Jan 9 2020, 11:17 AM

Updated patch based on previous comments.

zatrazz marked 2 inline comments as done.Jan 9 2020, 11:18 AM
zatrazz added inline comments.
llvm/test/tools/llvm-ranlib/D-flag.test
13
23

It does and I updated the patch.

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

The issue is setting TZ=UTC still might use internal database with UTC offsets. For instance, on the buildbot
that accused the regression, setting TZ=UTC make it use the tz database /usr/share/zoneinfo/UTC. At least
on Linux with glibc one way to actually use UTC without transit changes are to set TZ=":", it won't try to
access either the default '/etc/localtime'. However, I am not sure how portable it is and it might be in fact
an glibc issue (https://sourceware.org/bugzilla/show_bug.cgi?id=24004).

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

I am not sure now if it was something wrong with the bot tzdata, I reinstalled the tzdata packages
and reconfigured the timezone and now 'TZ=UTC date -d '@0' +%H:%M' does show the expected
00:00.

Indeed, although the workaround shouldn't change the expected result, the issue I am observing
on some machine does not make sense (TZ=UTC date -d '@0' +%H:%M' not showing 00:00).

I will hold this and investigate further.

zatrazz abandoned this revision.Jan 10 2020, 12:21 PM