Bug#844081: Reproducer

2017-01-02 Thread Filip Pytloun
Great, thank you. We have two options now before stretch code freeze: - do upload of new upstream (even major, eg. 0.9) version before 2017-02-05 (minus 10 days, better sooner) - maintain 0.8.x as a stable serie in stretch with bugfixes, etc. Newer releases will be uploaded normally to unsta

Bug#844081: Reproducer

2017-01-02 Thread Christian Geier
I'll backport those changes onto the 0.8 branch tomorrow. I'll send another email when it's done. Am 2. Januar 2017 22:48:21 MEZ, schrieb Filip Pytloun : >Hello, > >I checked the changes and as they are done on top of huge refactoring >(introduce of vdir.py), backporting it back to 0.8.4 seems t

Bug#844081: Reproducer

2017-01-02 Thread Filip Pytloun
Hello, I checked the changes and as they are done on top of huge refactoring (introduce of vdir.py), backporting it back to 0.8.4 seems to be too risky so I will workaround this occasional FTBFS by marking the test as xfail to avoid autoremoval from stretch. If we want to fix this issue correctly

Bug#844081: Reproducer

2016-12-19 Thread Christian Geier
Hi, I could reproduce the issue and have fixed it, see the PR on github [1]. Depending on how urgent this is, you can either just take the os.sync() commit and apply that to the version currently in Debian (which, while brute force, certainly fixes this problem), or you might want to wait if we fin

Bug#844081: Reproducer

2016-12-11 Thread Filip Pytloun
Hello, unfortunately I have no longer access to environment where this was happening. But if you were able to reproduce the issue and this fixed 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 operati

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-29 Thread Filip Pytloun
Hello Christian, I tried to execute the script during build process. Here is a couple of outputs from machine where this build is sometimes failing: [(0, 9), (0.0001, 9), (0.001, 8), (0.01, 0), (0.1, 0), (1, 0)] [(0, 10), (0.0001, 10), (0.001, 7), (0.01, 0), (0.1, 0), (1, 0)] [(0, 10), (0.0001,

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: Reproducer

2016-11-23 Thread Filip Pytloun
On 2016/11/24 00:00, Santiago Vila wrote: > Try using a chroot without union-type=overlay. Unfortunately it will result in the same error :-/ signature.asc Description: Digital signature

Bug#844081: Reproducer

2016-11-23 Thread Santiago Vila
On Wed, Nov 23, 2016 at 11:34:41PM +0100, Filip Pytloun wrote: > So I got access to affected host and was able to reproduce it there. > Spent some time debugging it and unfortunately I am still clueless why this is > happening. > > Found out that it doesn't matter if eatmydata is used or not, test

Bug#844081: Reproducer

2016-11-23 Thread Filip Pytloun
So I got access to affected host and was able to reproduce it there. Spent some time debugging it and unfortunately I am still clueless why this is happening. Found out that it doesn't matter if eatmydata is used or not, test is occasionally failing in both cases. I tried my patch and it didn't h

Bug#844081: Reproducer

2016-11-23 Thread Adrian Bunk
On Wed, Nov 23, 2016 at 06:37:17PM +0100, Filip Pytloun wrote: >... > That's the reason why lowering the priority down from serious (maybe to > important instead of normal) to avoid autoremoval. >... Your package can get scheduled for autoremoval due to this bug. But when you get notified that yo

Bug#844081: Reproducer

2016-11-23 Thread Filip Pytloun
On 2016/11/23 18:54, Adrian Bunk wrote: > Control: severity -1 serious > Control: tags -1 -moreinfo > > On Sun, Nov 20, 2016 at 10:03:04AM +0100, Filip Pytloun wrote: > >... > > Unfortunately running tests during build is always fragile and it seems > > that what's working in one environment may b

Bug#844081: Reproducer

2016-11-23 Thread Adrian Bunk
Control: severity -1 serious Control: tags -1 -moreinfo On Sun, Nov 20, 2016 at 10:03:04AM +0100, Filip Pytloun wrote: >... > Unfortunately running tests during build is always fragile and it seems > that what's working in one environment may be FTBFS for anyone else :-( >... Running tests during

Bug#844081: Reproducer

2016-11-20 Thread Filip Pytloun
Hello, I tried to reproduce the issue in my environment with: i=0;while true;do python -m pytest tests;ret=$?;i=$[ $i+1 ];echo "Run: $i"; [ $ret -ne 0 ] && break; done and in similar way with pbuilder that I am using and FTBFS didn't ever happen (tried 50+ builds). I have suspicion that these