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

[David Prévot]

Hi Holger,

On Thu, Oct 23, 2014 at 07:26:51PM +0200, Holger Levsen wrote:
> On Donnerstag, 23. Oktober 2014, David Prévot wrote:

> > My guess is it’s due to a previous “Segmentation fault” failed build:
> > AFAICT, a proper tear down is made at the end of the tests, even if some
> > fail (and the segfault you’re having prevents to execute this tear
> > down).
> 
> ok, i've just rescheduled the package on jenkins.d.n, the result should be 
> available in 5-15m or so. 

Seems like the segfault is reproducible with the jenkins setup, but I
still don’t know what is causing it.

> > > <h1>ERROR</h1> <h2>The requested URL could not be retrieved</h2> </div>
> > > <hr>  <div id="content"> <p>The following error was encountered while
> > > trying to retrieve the URL: <a
> > > href="http://127.0.0.1:123/">http://127.0.0.1:123/</a></p>  <blockquote
> > > id="error"> <p><b>Access Denied.</b></p> </blockquote>
> > 
> > Do you have a process actually listening locally on port 123? Some tests
> > are using http://127.0.0.1:123 to test a failure to connect…
> 
> not a process listening, but at least locally my firewall will not allow that.

Actually, Jenkins seems to be the one replying here, via squid, see the
end of the output:

> <p>Generated Thu, 23 Oct 2014 17:20:03 GMT by
> jenkins.debian.net (squid/2.7.STABLE9)</p> <!-- ERR_ACCESS_DENIED -->
> </div> </body></html>

> 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? If not, these package’s tests won’t
be able to run in the current jenkins.d.o environment.

> > > In a normal sid it fails like this:
> > > +Via: 1.1 tinyproxy (tinyproxy/1.8.3)
> > Heh, I through this error was due to tinyproxy, but after installing it
> > locally, I still don’t manage to reproduce your test issues. Do you have
> > a specific setup for it? Do you still reproduce the test issues once
> > tinyproxy removed (or at least stopped)?
> 
> 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).
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.

> > In order to at least workaround the issue for the reproducible builds,
> > can you simply deactivate the tests (add nocheck to DEB_BUILD_OPTIONS)
> > for this package?
> 
> how would you enable such a workaround? that's not a good idea, we want 
> packages to always build reproducibly! :)

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.
- in a normal sid (as pointed in your initial message), some tests are
  failing, and some other error out.

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).

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.

Regards

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20141023/eaee0565/attachment.sig>