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
signature.asc
Description: This is a digitally signed message part.
