| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Add-the-repr_str-attribute-to-the-test-add_count-fun.patch | Add the repr_str attribute to the test add_count function Without, the following traceback happen ====================================================================== |
=?utf-8?q?Pierre-Elliott_B=C3=A9cue?= <becue@crans.org> | no | 2018-05-16 | ||
| 0002-Sleep-before-modifying-first_path-otherwise-the-mtim.patch | Sleep before modifying first_path otherwise the mtime isn't updated It seems that the mtime handling by python acts weirdly. First, as this snippet shows, the mtime is lower than the initial time although the file got modified after. """ import os import time def test_mtime(): _s = time.time() with open("/tmp/test", "w") as testfile: testfile.write("") _t = os.path.getmtime("/tmp/test") print(repr(_s)) print(repr(_t)) In [4]: test_mtime() 1563311822.154947 1563311822.153427 """ Second, as this snippet shows, it doesn't update in each and every condition. """ In [35]: def test_mtime(): ...: with open("/tmp/test_mtime", "w") as myfile: ...: myfile.write("") ...: print(repr(os.path.getmtime("/tmp/test_mtime"))) ...: time.sleep(1) ...: with open("/tmp/test_mtime", "a") as myfile: ...: myfile.write("") ...: os.sync() ...: time.sleep(1) ...: print(repr(os.path.getmtime("/tmp/test_mtime"))) ...: In [36]: test_mtime() 1563349885.8835335 1563349885.8835335 """ Sleeping right before the file modification in the test seems enough, but it's a messy solution. The bug has been reported upstream, and upstream should consider relying definitely on pyinotify instead of trying to do something with a custom class. |
=?utf-8?q?Pierre-Elliott_B=C3=A9cue?= <peb@debian.org> | no | 2019-07-20 |