*: fix 32bit builds

[cyphar]

80f787e ("*: replace syscall with unix") did not correctly replace
the usage of (*syscall.Stat_t).[AM]tim.Unix() in tests, which resulted
in 32-bit builds failing in OBS because we run those tests in a %check
section. We need to add CI testing to make sure that we don't miss stuff
like this in the future.

Fixes: 80f787e ("*: replace syscall with unix")
Signed-off-by: Aleksa Sarai asarai@suse.de

[cyphar]

Sorry I missed this in #141. I've added some checks to CI to avoid this happening in the future.

[cyphar]

LGTM.

[vrothberg]

@cyphar I am surprised this fixes the mentioned issue as Timespec.Unix() does effectively the same thing plus a cast (which is redundant IMHO as both members are of type int64 [1]). I feel that I miss some important piece. Would you explain why using Unix() fixes the issue?

[1] https://godoc.org/golang.org/x/sys/unix#Timespec

[cyphar]

@vrothberg On 32-bit systems, Timespec.Sec and Timespec.Nsec are int32 which will cause compilation errors when used directly with time.Unix (see the current umoci package in openSUSE which cannot build on 32-bit, or just try running make GOARCH=386 local-validate-build before this patch was applied). However .Unix() will always convert it to int64 which means we don't have to deal with it ourselves. On 64-bit systems this doesn't change anything.

That was the original reason I used Unix and I completely forgot when reviewing your patch. It's my fault that I didn't make this part of the CI when I first figured out this same issue several months ago. Not to worry, it's part of CI now. 😸

[cyphar]

If you're wondering about what will happen in 2038 to Go programs that use Timespec on a 32-bit machine, your guess is as good as mine. I imagine it won't end well.

[vrothberg]

On 32-bit systems, Timespec.Sec and Timespec.Nsec are int32 [...]

Ha, I should have been more careful as I was aware of the casts, but found accessing the members more explicit. Thanks for the fix and the explanation 👍