Launchpad itself

Building Java Based Debian / Ubuntu Packages

Asked by Matt Haynes

Hey,

Im having a few issues building my scala / jvm, based project. My packages build fine on my local machine but fail on Launchpad.

I have the following customisation to my build process:

dh_autobuild is overridden to call the 'sbt' tool which I have bundled within my debian directory. This is a scala build tool based on Maven / Ivy architecture, it's only dependency is default-jvm which is specified in my control file.

The sbt tool will download all the java (jar) dependencies for my project and compile them into what's known as a 'fat jar'. This way I can deploy said jar into /usr/share/myproject and be confident that all the dependent jars are available on the target machine.

The sbt tool gets called and starts up perfectly fine, however I see these error messages on Launchpad that are not present within my local build env (pbuilder):

https://launchpadlibrarian.net/157513847/buildlog_ubuntu-precise-i386.juicer_0.0.1-1_FAILEDTOBUILD.txt.gz

Specifically:

"You probably access the destination server through a proxy server that is not well configured."

So my question is does the Launchpad package builder allow outbound HTTP connections at the dh_autobuild stage ? Is there some proxy config I should know about?

Any help would be awesome thanks!

Matt

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
William Grant
Solved:
Last query:
Last reply:
Revision history for this message
William Grant (wgrant) said : 		#1

Launchpad builds must be self-contained; they cannot access network resources other than their dependency archives. You'll need to alter the build to not try to talk to the Internet.

Revision history for this message
Matt Haynes (c-matt-9) said : 		#2

Thanks William. I'll have to think about how to do this correctly, the dependency chain in java software projects becomes quite nightmarish without tools like maven.

Out of interest what is the rationale for this?

Revision history for this message
Best William Grant (wgrant) said : 		#3

There are a number of reasons. For example, Ubuntu needs to be buildable in a self-contained environment so some some external website going away can't make the distribution unbuildable, and to allow builds to be reproducible so changes in the distribution are predictable and can be audited. And letting anyone with an email address use our machines with full Internet access would open some rather unfortunate potential for abuse.

Revision history for this message
Matt Haynes (c-matt-9) said : 		#4

Thanks, makes sense. I'll mark this ticket as answered but update if I find a decent work around.

Cheers,

Matt

Revision history for this message
Matt Haynes (c-matt-9) said : 		#5

Thanks William Grant, that solved my question.

Revision history for this message
Matt Haynes (c-matt-9) said : 		#6

Hiya,

I managed to get this working with a fair amount of hackery, thought I'd update here for future reference.

The sbt program that builds my project has two sets of dependencies:

* sbt versions and plugins by default stored in ~/.sbt/boot
* project dependencies by in ~/.ivy2/cache

I am able to override these directories to be within the debian directory of my package. This way I can upload all the java build and project dependencies in the .debian.tar.gz part of my source package.

To override ~/.sbt/boot set the property -Dsbt.boot.directory=debian/sbt-boot/ when you call sbt

To override ~/.ivy2/cache set the property -Dsbt.ivy.home=debian/ivy-cache when you call sbt

This is how I now call sbt:

  java -Dsbt.ivy.home=debian/ivy-cache -Dsbt.boot.directory=debian/sbt-boot/ -jar `dirname $0`/sbt-launch.jar

My source packaging process for Launchpad now looks a little like this:

  cd $(PKGDIR)
  mkdir debian/ivy-cache debian/sbt-boot
  ./debian/sbt update test assembly stage
  find debian/sbt-boot/ | grep jar >> debian/source/include-binaries
  find debian/ivy-cache/ | grep jar >> debian/source/include-binaries
  find . -type d -name target | xargs rm -rf
  cd ..
  dpkg-buildpackage -S -us -uc
  lintian -i -I --show-overrides *.changes

Perhaps this helps somebody in future!

Cheers,

Matt