bug#39575: guix time-machine fails when a tarball was modified in-place

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> Well, now, I am failing at the Python 3.7.3 step too:
>
>   /gnu/store/s0lw23myd3hvpw28sffkhz8b30x1hcz0-python-minimal-3.7.3.drv failed
>
>
>
> However, the python error seems about TLS:
>
> test.test_asyncio.test_windows_utils (unittest.loader.ModuleSkipped)
> ... test test_asyncio failed
> skipped 'Windows only'
>
> ======================================================================
> ERROR: test_start_tls_server_1
> (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
> line 507, in test_start_tls_server_1
>     self.loop.run_until_complete(run_main())
>   File "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/base_events.py",
> line 584, in run_until_complete
>     return future.result()
>   File "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_asyncio/test_sslproto.py",
> line 502, in run_main
>     loop=self.loop, timeout=self.TIMEOUT)
>   File "/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/asyncio/tasks.py",
> line 423, in wait_for
>     raise futures.TimeoutError()
> concurrent.futures._base.TimeoutError

It seems to be timing-sensitive, is it deterministic?

One lesson here is that we should keep substitutes for a longer amount
of time—we actually have a lot of storage space on berlin so we should
investigate what happened.  (The NixOS folks currently keep substitutes
forever but they found it’s starting to be expensive…)

Thanks,
Ludo’.