Bug#868773: khal FTBFS: AssertionError: assert not OSError(6, 'No such device or address')

2017-10-07 Thread Christian Geier
advise you to skip those tests for now, as their failing does not indicate a bug in khal, but a peculiarity in Debian's test system. Best regards, Christian Geier Quoting Guido Günther (2017-08-24 18:55:50) > Hi, > On Tue, Jul 18, 2017 at 03:41:33PM +0300, Adrian Bunk wrote: >

Bug#844081: Reproducer

2017-01-02 Thread Christian Geier
ease. >> > >> > Anyway wouldn't it better to ensure data is written to disk >directly >> > during db updates and other operations? Eg. use O_SYNC for safety >as >> > these operations doesn't happen so often. >> > >> > Filip >>

Bug#844081: Reproducer

2016-12-19 Thread Christian Geier
it > for you, I'll apply it and make new release. > > Anyway wouldn't it better to ensure data is written to disk directly > during db updates and other operations? Eg. use O_SYNC for safety as > these operations doesn't happen so often. > > Filip > > On

Bug#844081: Reproducer

2016-12-10 Thread Christian Geier
Hi Filip, could you perhaps try to change all those sleep()s to `os.sync()`? For me it seems to fix the issue. See [0] for a patch. If this doesn fix the issue, we obviously need to move the sync call out of the tests and into the db update. Best regards, Christian [0] https://github.com/pimut

Bug#844081: Reproducer

2016-11-26 Thread Christian Geier
Hi Filip, could you perhaps run the attached file on the test machine (with `py.test vdir_test.py`, py.test is needed for the creation of a temp directory). On my machine the output looks like this: [(0, 10), (0.0001, 8), (0.001, 0), (0.01, 0), (0.1, 0), (1, 0)] Similar experiments before made me

Bug#844081: Which FS was this run on?

2016-11-21 Thread Christian Geier
data and re-reading the mtime . Best regards, Christian Geier