Hi, Am Montag, den 26.01.2015, 14:41 -0400 schrieb David Prévot: > Hi, > > Le 21/01/2015 14:23, David Prévot a écrit : > > Le 19/01/2015 13:34, Daniel Beyer a écrit : > > >> I'm not 100% sure if it really fixes the problem, since I'm not able to > >> reproduce those errors on my local system (neither local, nor with > >> pbuilder sid/jessie). > > > > Same here, even within sbuild. > > > >> […] check if the DEP-8 tests are working on ci.debian.net > >> (exactly the same errors mentions in #775625 occurring there). > > Unfortunately, the DEP-8 tests are still failing with the fix: > > http://ci.debian.net/packages/s/symfony/unstable/amd64/ >
That's really bad. The last days I spend a lot of time, trying to reproduce this locally by setting up artificially slowed down VMs. I kind of managed to get those errors, but I needed to slow down the VM to a completely unrealistic speed (tests took ~5h and quite some other tests were failing with such a slow machine as well). In my opinion a slow machine is not the cause AbstractProcessTest::testStartAfterATimeout() is failing on ci.d.n. > > If that’s not enough, or if upstream gives feed back on your PR, > > we can still roll out another update. > > Maybe the people behind the bug report or ci.d.n will be able to offer a > shell to reproduce the issue we’ve not managed to reproduce so far… > A shell would be really great. I think something in Process/Process.php start() [1] is slow on that machine (and if I put a delay in there, I get those errors). However I have no idea what it could be. Who do we need to ask for a shell on ci.d.n? > Deactivating the tests will also be an option if we can’t reproduce it, > but it would be way nicer to keep a eye on eventual php5 regressions > (especially with the new fancy “upload to the latest minor version” > trend for fixing security issues…). > I don't like deactivating the test, too. Especially since I have no clue what is causing this behavior on ci.d.n. I would like to try one more thing and increased the timeout in the test from 0.1s to 0.5s. This is just an other wild guess and still we will not know what really is causing the problem. But it might prevent us from an other FTBFS in BTS. I've already added a new patch in the jessie branch, but did not update d/changelog. If you agree to try this out, it would be great if you could upload a 2.3.21+dfsg-3 to the archives. > > An unblock request may not be necessary > > Adam is indeed fast ;). > > taffit@persil:/tmp/partclone-0.2.73$ grep-excuses symfony > […] > Ignoring block request by freeze, due to unblock request by adsb > Definitely. Greetings Daniel [1] http://anonscm.debian.org/cgit/pkg-php/symfony.git/tree/src/Symfony/Component/Process/Process.php?h=jessie#n221 [2] http://anonscm.debian.org/cgit/pkg-php/symfony.git/tree/src/Symfony/Component/Process/Tests/AbstractProcessTest.php?h=jessie#n667
signature.asc
Description: This is a digitally signed message part
