FFADO-ppa

The first packaging I did with my ppa was FFADO. Just like working with prevu, I needed to build the updated or non-existing dependencies in Hardy to build JACK and Ardour.

Under my ~/build directory I created a /ppa directory and copied my ~/build/libffado directory into it and renamed /libffado to /ffado-ppa

I edited the ~/build/ppa/ffado-ppa/libffado-2.0~rc1/debian/changelong file.

libffado (2.0~rc1-0ubuntu3~ppa2) hardy; urgency=low

* backport to hardy (LP: #469717)

-- Scott Lavender (ubuntustudio-dev) Sun, 01 Nov 2009 15:33:00 -0600

libffado (2.0~rc1-0ubuntu2) jaunty; urgency=low

* Fix linking against libffado (broken symlink) (LP: #332692)
* Rename README.Debian.source to README.source
* Install a .desktop file and icon for ffado-mixer.
* Drop ffado-mixer-qt3 (see README.source).

-- Andrew Hunter Mon, 23 Feb 2009 16:17:25 -0500

Notice I updated the revision number and changed the Ubuntu version to hardy. Both critically important. Also I followed the exact format including spaces and empty lines.

Next I change directories up one level so that I was at ~/build/ppa/ffado-ppa/libffado-2.0~rc1 to start building the package.

cd ..
debuild -S

Once again I moved up one directory and transferred the correct files to my ppa

cd ..
dput hardybackports libffado_2.0~rc1-0ubuntu3~ppa2_source.changes

The quick witted will notice the ppa2 tag at the end of the package version. This was because I originally forgot to change Ubuntu's version from jaunty to hardy. Since I had already transferred a ppa1 version to my ppa I had to build it again with a new version number.

After that I waited a few hours and the package was built for me.
https://launchpad.net/~slavender/+archive/ppa

ppa

Ubuntu's Personal Package Archive (ppa) is a great tool. I realize this now. But the overall concept isn't explained very clearly (in my opinion) so I shall rectify this, followed by some guidelines.

Please keep in mind that the scope of this post is for building packages already in Ubuntu's primary archives for backporting. This does not include building packages from scratch, patching the existing packages or installing them from a ppa.


(Simplified) Overall Concept
Ubuntu virtual machines will build packages for you after you have loaded the source code onto your computer, run a building command and then uploaded some of the resulting files to your ppa.

The ppa system will then schedule your build by ranking it against over things to be built. Packaging with higher importance, say security updates, will be ranked higher in the queue. Therefore, you may need to wait many, many hours.

The general order would be:
* prerequisites - having a launchpad account, establish gpg key and configuring your ppa and dput
* getting source code - downloading from Ubuntu's archives
* updating the changelog - incrementing the package revision
* building the package locally - debuild for dummies
* uploaded the changes file - dput dfile to dserver
* waiting for your ppa to build - tick, tick, tick

Prerequisites
There are several prerequisites than must be met before you can build a package. These include:
* having a Launchpad account
* creating a gpg key and registering it with Ubuntu
* signing the Ubuntu code of conduct
* configuring your dput
* creating your ppa

A very helpful (and verbose) post covering the first four bullet points and more can be found at the Ubuntu Forums [1].

You can create your ppa at your Launchpad page by clicking the Create New PPA link. The ppa name will be part of the link and used for dput, the display name is pretty trivial as is the description. When you are asked to give a ppa name I would suggest using something short since you may be typing it when you use dput.

Getting the Source Code
This is pretty straight forward: make a directory, change directories into it and download the source code.

mkdir ffado
cd ffado
apt-get source ffado

Updating the changelog
While not quite as succinct as getting the source code, this is still relatively short and simple.

After retrieving the source code you should have a new folder name source-version_number, change into this directory. Under this directory you will find a directory called debian, change into this directory. You should find a file called changelog. We will edit this file. Using the example of FFADO again:

cd libffado-2.0~rc1
cd debian
gedit changelog

A new entry will need to be made at the top of the file. Pay attention to the package version as shown in the ppa help page [2].

You name and email address must match your gpg key including any description you included when creating it. You can find this by typing gpg --list-keys.

The changelog also requires a very special time and date format. Use date -R to get the current time and date.

Lastly, follow the format of the previous entries for spacing and empty lines. If any formatting (including getting your name wrong) is incorrect the build process will blow up.

Building the Package Locally
Another simple step, but first make sure you are under the source code folder (but not the debian folder). For the example we would need to be directly under the libffado-2.0~rc1 folder. If you just changed the changelog:

cd ..

Now we need to run the debuild command:

debuild -S

This will read the changelog file you changed and create some new files with the new version number that will be used to upload to your ppa.

Uploading the Changes
When you creating your ~/.dput.cf file a name of your ppa was placed in brackets, this is the name you will use in your dput command. Here is my dput.cf file:

[hardybackports]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~slavender/ppa/ubuntu/
login = anonymous
allow_unsigned_uploads = 0

[build]
fqdn = ppa.launchpad.net
method = ftp
incoming = ~slavender/build/ubuntu/
login = anonymous
allow_unsigned_uploads = 0

The first entry is for my original ppa which is named ppa (notice the ~slavender/ppa/ubuntu directory) and the hardybackports in the brackets. When I want to upload to my primary ppa I type dput hardybackports package_verison_source.changes which puts the code into my primary ppa.

The upload to my second ppa, notice the [build] and ~slavender/build/ubuntu, I type dput build package_verison_source.changes.

See the ppa help page [3] for more information.

Waiting for Your PPA to Build
There isn't much here to do other than find out how long you are expected to wait.

From you Launchpad page click on the link with your ppa name. Click on the link in the upper right that says View package details. Click the View all builds link at the upper right. Lastly pick package name link and the resulting page will have an approximate time until your build.

As mentioned at the beginning, build are ranked and built according to their respective ranks. More important ones (i.e. security) are ranked higher and therefore built earlier. The scheduling for this build is explained at the ppa help page [4].

Build times are approximate and conservative. I have found that they tend to move along pretty quickly. I don't recommend checking every five minutes but you may find that after an hour your time might have been reduced by two hours or more.

[1] http://ubuntuforums.org/showthread.php?t=929498
[2] https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
[3] https://help.launchpad.net/Packaging/PPA/Uploading
[4] https://help.launchpad.net/Packaging/BuildScores

Ardour

Building soundtouch was the last step in building Ardour.

The familiar steps follow.

mkdir ardour
cd ardour
apt-get source ardour
cd ardour-2.7.1
prevu

And now I have a brand new, shinning Ardour-2.7.1 .deb file.

Trouble is, this doesn't really help me get it into backports readily, which will lead me into my next series of post about Ubuntu's Personal Package Archive (ppa).

Understanding prevu

So I finished building soundtouch which I am hoping will be the last necessary build dependency before I am able to build to build Ardour. Therefore I will test the how prevu handles newly build packages.

prevu can set up the newly build .deb files as a local apt repository. This is important if you want to install newly built .dep files for updated applications.

But also this is rather important (I believe) when you want to build an application which has a dependency which needs to be built first. Let's say you want to build an application called bar that has a dependency called foo.

Therefore, you need to build foo (the dependency) first, update prevu next and then build bar (the application you want). It appears that foo (the dependency) does not need to actually be installed (via synaptic or apt-get install), simply updating prevu will make the dependency (foo) available to prevu.

I tested this after building soundtouch when compiling Ardour. It was unnecessary to actually install soundtouch (via synaptic or apt-get install) in order to compile Ardour. Updating prevu after building soundtouch was enough to build Ardour.

soundtouch

After building and installing (via synaptic) libtool I tried to build soundtouch again.

Common drill again.

mkdir soundtouch
cd soundtouch
apt-get source soundtouch
cd soundtouch-1.3.1
prevu

Success! Apparently the '-i' argument for libtoolize was for the later version of libtool :)

Next I will move back to building Ardour again after this circuitous route.

libtool

While trying to build soundtouch I ran into more problems:

make[1]: Leaving directory `/var/cache/prevu/src/14938/source'
cd build-tree/soundtouch-1.3.1 && libtoolize -c -f -i
libtoolize: unrecognized option `-i'
Try `libtoolize --help' for more information.
make: *** [debian/stamp-autotools-files] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

I researched libtool a bit and find that the version in hardy is quite old compared to Jaunty (1.5.26-1ubuntu1 vs 2.2.6a-1ubuntu1).

At this point I did what works for me; I walked away again and did some thinking. Guessing that perhaps the '-i' was an argument for a later version I'm going to try to build libtool first before trying to build soundtouch again.

I made sure I was using the Jaunty source repository again.

sudo gedit /etc/apt/sources.list

I made sure the additional source at the bottom referenced Jaunty.

# Adding interpid sources for prevu
deb-src http://archive.ubuntu.com/ubuntu jaunty main restricted universe multiverse

Update prevu.

sudo -E prevu-update

Then I did the usual song and dance.

mkdir libtool
cd libtool
apt-get source libtool
cd libtool-2.6.2a
prevu

Success.

Next I installed the libtool package in the hopes that the '-i' argument was a new feature in the later versions libtool. Next on to building soundtouch again.

[edit: as it turned out, I was right and soundtouch then built correctly]

Note that I had such trouble that I couldn't conclusively determine if I needed to install packages via synaptic or would prevu recognize them from the local repository.

cdbs

As mentioned in the previous post I needed to build soundtouch in order to hopefully build Ardour but got no love from building soundtouch. It turns out I needed a more recent version of cdbs. So to build cdbs before I can build soundtouch before I can build Ardour.

Trouble is that as I tried to build cdbs from the jaunty repository I received an error rather than the expected and familiar unmet dependency. A quick Google search and I wasn't any better off. Therefore I do what I do best; I walked away and thought about it.

Thinking back from what I read I guessed that I might need to build the correct version of cdbs from the oldest release of Ubuntu, in this case intrepid.

I changed my sources.list so that I could get sources from the intrepid sources repository rather than jaunty.

sudo gedit /etc/apt/sources.list

and a changed this:

# Adding interpid sources for prevu
deb-src http://archive.ubuntu.com/ubuntu jaunty main restricted universe multiverse

to this:

# Adding interpid sources for prevu
deb-src http://archive.ubuntu.com/ubuntu intrepid main restricted universe multiverse

Now I needed to update my sources.

sudo apt-get update

Finally, I updated prevu.

sudo -E update-prevu

Now, I could follow the familiar steps.

mkdir cdbs
cd cdbs
apt-get source cdbs
cd cdbs-0.4.52ubuntu7
prevu

I really didn't think this would work but it did.

So now I've build cdbs with the correct required version so I can now build soundtouch (hopefully) and then build Ardour (also hopefully) without any more trouble.

Prediction: I expect soundtouch will build fine, but I would probably lay even money against Ardour building without some other trouble.

Lastly, I can now test how the prevu-update works. Specifically, do I need to actually install the latest cdbs on my system or can I just update prevu and let it recognize that a more recent version of cdbs is available from my local repository.