Sign up ×

I wanted to try creating my own PPA. The project I have is a java project built with maven. This is what I've already done so far:

  • Created a PPA.
  • Set up a new project on Launchpad.
  • Added a branch that is importing my project from a SVN repository.
  • Created a recipe for that branch that is publishing the builds to my PPA.

This is where I'm stuck.

I've read the tutorials and Googled a lot; but, I wasn't able to find out how to build my project.

I can start a build for the branch; but, as I expected, it fails. I guess I have to put some meta information like a makefile into the repository. Is it even possible to build and package Maven projects on Launchpad? I also tried to build a .deb file locally using bzr dh-make and debuild. bzr dh-make created a lot of files in the ./debian folder but debuild failed. I guess that it would work if I specified the right meta information in my project so it's the same problem as on Launchpad.

I know this is a pretty general question but I think there is a lack of proper tutorials for packaging .deb files even if you don't have an "exotic" case like me.

To sum it up:

What files/information do I have to provide in my project so that it can be properly build and packaged?

Any help would be great :-)

share|improve this question
afaict it is possible. i'm looking at a solution, but it's going to take some time –  hbdgaf Jul 23 '12 at 17:59
Thanks a lot! I already lost all hope. –  André Stannek Jul 23 '12 at 21:09
So??? How is it done. This is driving me crazy. –  i30817 Aug 9 '12 at 16:43
@i30817 - sorry, i was away for defcon, now i'm working on a game for ubuntu. i'll fill in the answer as quickly as other demands allow –  hbdgaf Aug 9 '12 at 21:22
I'm at the point where i'm trying to call debuild to see if it's able to build the deb before uploading to a ppa. No luck: dh build --with javahelper dh_testdir dh_auto_configure jh_linkjars dh_auto_build jh_build dh_auto_test fakeroot debian/rules binary dh binary --with javahelper dh_testroot dh_prep dh_installdirs dh_auto_install dh_install cp: cannot stat `debian/tmp/bookjar.jar': No such file or directory dh_install: cp -a debian/tmp/bookjar.jar debian/bookjar/usr/share/bookjar/ returned exit code 1 make: *** [binary] Error 2 –  i30817 Aug 10 '12 at 0:07

1 Answer 1

Look in my bookjar project:

specifically the debian directory (especially the debian/ file) and the build.xml (ant) file. In that file there is a new target 'upload' that uploads a buildable artefact to the launchpad buildbot.

I'm using ivy and the netbeans ant infrastructure so it's likely to be slightly different for you. However, one thing is certain: you can't use ivy or maven from the remote buildserver. You need to upload all libraries you use, either in the form of code or jars. ivy:retrive downloads the files to the current_dir/lib so my project in netbeans is setup to look for it's libraries there ( is part of the netbeans infrastructure for that). Read the build.xml for details (basically the debian/rules files call a special ant target to build in the server that doesn't try to symlink the jar files - because they are already copied there).

I'm also taking advantage in my of my project being in mercurial to build a changelog file from the hg log, so there are other problems to solve if you want the same degree of automatism and don't use hg (in fact, i think that my changelog is bending the rules of debian changelogs by having each change be a 'minor' release).

share|improve this answer
Sounds promising but it can take a few days before I have time to look into it. –  André Stannek Sep 9 '12 at 13:50
Forgot: In this scheme you're responsible for the uploads to the ppa releases instead of linking the ppa to a code repository with a watchdog file and having it build periodically. I prefer it this way and didn't even try to do the other, but it's probably possible. My ppa built with this (after 13 failed attempts!). Also be careful because your changelog has to be in OCD-pristine order to be accepted by debuild - which means that your hg log also has to be so - i had to reinit the repo because of a 'user' that didn't follow the guidelines –  i30817 Sep 9 '12 at 14:14
After three months it's a lot better than nothing ;-) –  André Stannek Sep 9 '12 at 14:17
You probably don't want to use the hg log > changelog trick. It has some dubious requirements such as not having any hg tag except numeric ones (releases) or having to have all commit commiters follow debian guidelines (and since hg doesn't allow changing history... if this happens you either use a complicated extension or reinit the repository ... and in any case hose remote clones). It does have the advantage of not having to maintain the changelog if you manage it though. –  i30817 Sep 9 '12 at 14:27
Still couldn't find the time to look into it :-( Just wanted you to know that I haven't forgotten this issue. –  André Stannek Jan 28 '13 at 19:12

Your Answer


