Java buildd service
This thread belongs to

2007-07-02 05:40 GMT   |   #1

Hello everyone,

I have setup a local buildd locally to be able to testbuild all packages
maintained by the Debian Java Maintainers. In the first test builds only
the usual suspects failed which have already filed FTBFS bugs in the

I would like to provide this service to be able to test all the java
packages when a dependency gets updated and may be API incompatible.
This allows us to find issues before we upload the package into the
official archive. We can also test new toolchains.

The setup currently uses pbuilder but I will migrate it to
cowbuilder/lvmpbuilder soon to get a better performance.

If you packages you want me to test build with all its
reverse-dependencies please mail me.

What do you think?
2007-07-02 06:00 GMT   |   #2
What was the result for dom4j? I would like to have more data on #427456.
What is the arch and CPU of the build system?

2007-07-02 08:20 GMT   |   #3

The buildf failed but differently:

[junit] Running org.dom4j.xpath.MatrixConcatTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.833 sec

/tmp/buildd/dom4j-1.6.1+dfsg/build.xml:276: Test org.dom4j.xpath.MatrixConcatTest failed

I think it would be okay for now to turn off the checks during build-time to fix #427456.

The buildd currently runs on i386 userspace on amd64 cpu. I will add an
additional flavor to be able to build on i386 *and* amd64. I have a fast
enough powerpc machine here too which needs some love and can then act
as another buildd too.

2007-07-02 08:40 GMT   |   #4
Ok, so the ThreadingTest succeeded at least.

Could you send me the test result for the MatrixConcatTest from
build/test-results/xml, it should contain the exception message.

  I think it would be okay for now to turn off the checks during build-time
  to fix #427456.

Perhaps, but I don't like to turn off test suites just because they fail Smile
It can make multi-threaded programs break randomly...

  The buildd currently runs on i386 userspace on amd64 cpu.

Is it an SMP system? 
2007-07-02 09:50 GMT   |   #5

<testcase classname="org.dom4j.xpath.MatrixConcatTest" name="testMatrixConcat" time="0.458">
<error message="Exception occurred evaluting XPath: matrix-concat('EQUITY_',/product/cashflows/CashFlow/XREF). Exception: No Such Function matrix-concat" type="org.dom4j.XPathException">org.dom4j.XPathException: Exception occurred evaluting XPath: matrix-concat('EQUITY_',/product/cashflows/CashFlow/XREF). Exception: No Such Function matrix-concat
at org.dom4j.xpath.DefaultXPath.handleJaxenException(
at org.dom4j.xpath.DefaultXPath.selectNodes(
at org.dom4j.tree.AbstractNode.selectNodes(
at org.dom4j.xpath.MatrixConcatTest.testMatrixConcat(
at org.dom4j.xpath.MatrixConcatTest.testMatrixConcat(

Doesnt make much sense to me currently, but I haven't looked into the code.

This is a single-cpu/single-core machine.
2007-07-02 10:20 GMT   |   #6
That fits the pattern. The problem seems to hit SMP machines.

2007-07-10 06:10 GMT   |   #7

Is it possible to set up the build environment so that access to the
network will fail (after downloading the Build-depends of course)? I'm
thinking of packages that attempt to download binary blobs (e.g.

2007-07-10 06:30 GMT   |   #8

No, pbuilder uses apt to download build dependencies that are not in its
cache. My special setup even updates the apt lists always to allow build
ing with just build other packages (build-dependencies).

I have thought about this problem and I think the we should have a
preloadable library (packaged as deb) that prevents all network
operations. This should be easy to do with re-implementing the socket()
function from glibc. Then its still possible to ioctls into the kernel
to do create a socket but thats unlikely occur. Then something like

nonet debuild ....

should be possible to build without network access without breaking your
system. This can then be built into our buildd.

I'm investigating this solution more.

2007-07-10 21:00 GMT   |   #9
I suggest contacting Lucas Nussbaum (of debian-qa), who has been
rebuilding the archive regularly on a 5000 node distributed cluster in
France (no net access from inside the cluster). I'm sure he would be
more than willing to help setup whatever special situation is needed
for debian-java. He did a presentation about this at debconf, video is
probably on meetings-archive.d.n by now. I imagine the tests you
mention across all of debian-java would take a matter of minutes.

Latest FTBFS logs from his archive rebuild are here:

2007-07-11 02:20 GMT   |   #10

I've spoken with Lucas on IRC before and his work is really useful. But
his work has a different goal. Lucas does checks on current archive.
My buildd can do builds before packages enter the archive. E.g. I've
used it to rebuild all packages build-depending on ant before I uploaded
ant 1.7.0 into the archive to make sure it dont break too much. This way
I found a breakage in ow-util-ant-tasks with the new ant version.

1 2nextlast