[pkg-php-pear] Bug#775625: symfony: FTBFS in jessie: Tests failures

[Daniel Beyer]

On Sun, 18 Jan 2015 17:33:40 +0100 Lucas Nussbaum <lucas at lucas-nussbaum.net> wrote:
> On 18/01/15 at 23:12 +1100, Stuart Prescott wrote:
> > Control: tag -1 unreproducible
> > 
> > A timeout issue like this is often sensitive to the machine used and I cannot 
> > reproduce this FTBFS here -- the test suite also took less than half the time 
> > to run on this old laptop cf the EC2 instance. The three timeout values could 
> > be increased if necessary but that hardly seems worth it.
> 

It seems to be the same issue as it is with the failing DEP-8 tests on
ci.debian.net [1]. I'm unable to reproduce this myself, but taking a
closer look to AbstractProcessTest::testStartAfterATimeout(), the test
itself is pretty useless:


First: The command that is executed actually is this one:
# php -r "$n = 1000; while ($n--) {echo ''; usleep(1000); }" 

This does not wait ~1s, but produces the following error:
PHP Parse error:  syntax error, unexpected '=' in Command line code on line 1


Second: Any \Exception is caught in the try{}...catch(), while a
RuntimeException should be caught instead.
Currently even the Exception potentially thrown with
"$this->fail('A RuntimeException should have been raised.');"
is caught, making a mockery out of the whole tests.


> Which timeout values are you talking about?
> 
> You seem to think that the problem is that the test is taking too long.
> That doesn't seem to be the case to me: the test's purpose is to test
> stuff related to timeouts in Symfony's Process component.
> 
> What seems to happen here is that the call to start() causes a call to
> checkTimeout(), that detects that the process should be timeouted.
> So it's either a matter of start() taking too long to start the process,
> or of insufficient timer accuracy. Assuming that Process can start a
> process in 0.1s might be a bit optimistic.
> 

Actually upstream once doubled [2] the timeout to 0.2s, but this got
lost later on - most likely due to resolving merge conflicts.


I'm currently preparing a fixed version of
AbstractProcessTest::testStartAfterATimeout() for upstream.
Afterward I will prepare a new upload for Debian, containing the fix.
I don't think it's needed to double the process timeout, once the test
is working as expected again.

Daniel

[1] http://ci.debian.net/packages/s/symfony/unstable/amd64/
[2] https://github.com/symfony/symfony/commit/ae8481038e6f7eefc8c39bcc86415438214e12b9?diff=unified#diff-8b27fa124d6320de1b3f9bb9b527a663R588


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20150119/990be364/attachment.sig>