Earlier "negative timestamp" patch had a 64-bit timestamp in the test.

The date in the comment is correct - for -0x80000000.  Sadly, the *code*
actually said -0x90000000.  That works on 64-bit systems (and filesystems)
not not 32-bit ones, where python gives an encoding error.

In any case, based on the comment (June 10, 1893) it seems tat -0x80000000
must have been the intended value anyway.  Now 'make test' passes on 32-bit
Linux again.

Signed-off-by: Avery Pennarun <apenwarr@gmail.com>

diff --git a/lib/bup/t/tindex.py b/lib/bup/t/tindex.py
index 5d7f02d3bc7b340f6049d6bc7cac94902b1f34ae..9c618a443620f1ea246a41e437221c2ec7281eef 100644 (file)
--- a/lib/bup/t/tindex.py
+++ b/lib/bup/t/tindex.py
@@ -60,7 +60,7 @@ def index_negative_timestamps():
     WVPASS()
 
     # Jun 10, 1893
-    os.utime("foo", (-0x90000000, -0x90000000))
+    os.utime("foo", (-0x80000000, -0x80000000))
     e = index.BlankNewEntry("foo")
     e.from_stat(xstat.stat("foo"), time.time())
     assert len(e.packed())