[pkg-php-pear] Bug#766466: php-guzzle: ftbfs and (sometimes) after built attempt in pbuilder, nodejs still runs server.js

[Holger Levsen]

control: severity -1 important

Hi David,

On Donnerstag, 23. Oktober 2014, David Prévot wrote:
> Seems like the segfault is reproducible with the jenkins setup, but I
> still don’t know what is causing it.

yeah. Just tell me if you have something for me to try...
 
> > on jenkins.d.n there is neither an ntpd running nor such a firewall, but
> > of course other builds could have used port 123...
> 
> NTP listens on UDP, chances that something listening on TCP port 123 are
> thin. Still, Jenkins proves me wrong here. Can you try and disable that
> feature, at least for TCP port 123? 

that's the thing, there is nothing on port 123 on jenkins.d.n nor a 
firewall..!

> If not, these package’s tests won’t
> be able to run in the current jenkins.d.o environment.

yeah, I guess thats the case for now. But I don't think it's the end of the 
world ;-)

> > then outside network access will not work anymore... do you tests really
> > need internet access or "just" local net?
> Only local (that would be an RC issue if it goes outside TTBOMK anyway).

yes, that would be an RC issue. But those exist :)

> A local server (with nodejs) is run for the purpose of these tests, and
> some other tests use http://127.0.0.1:123/ to test failure to connect to
> a server.

*nods*

> Seems like we have to distinct issues:
> - on jenkins.d.n, the segfault breaks the build at about 30% of the test
>   suite (it may be related to jenkins serving content via
>   http://127.0.0.1:123/, but it may also be unrelated, running phpunit
>   with the --debug switch should help pointing to the test actually
>   causing the segfault.

how do I run that exactly?

> - in a normal sid (as pointed in your initial message), some tests are
>   failing, and some other error out.

yes, those are two bugs. I'll leave the cloning to you though. You have a 
better grasp whats happening.

> I’m not able to reproduce any of these issues, and guess I’d need {more
> information to set up,access to} similar environments in order to
> investigate the pointed issues.
> 
> I suspect some specific setup or packages are incompatible here, and
> wonder if I should “just” use Build-Conflicts to exclude the
> incompatible packages from being installed (once they will be
> identified).

if you'd knew which, thats certainly an option.

> Anyway, I’m tempted to downgrade the severity here: FTBFS in a “dirty”
> environment should not be RC IMHO. There is of course an easy fix
> available: don’t run tests during the package build, but I would be more
> comfortable with an important bug to fix, than a closed RC bug via a
> “let’s close our eyes and don’t run the test suite” fix.

yeah, keep the testsuite! (+downgraded as you will have noticed :) Not sure 
whether to tag this bug unreproducible (though _I_ can) or moreinfo too...


cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20141025/3a370098/attachment-0001.sig>