Monday, November 2, 2009

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).

Sunday, November 1, 2009

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.

Saturday, October 31, 2009

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.

Friday, October 30, 2009

VAMP

My first build attempt to build Ardour failed and told me that I needed vamp-plugin-sdk. This was not unexpected.

So, the familiar mantra followed: make a directory, change to that directory, download source, change into new directory and run prevu.
mkdir vamp
cd vamp
apt-get source vamp-plugin-sdk
cd vamp-plugin-sdk-1.3-1
prevu

This built well so I installed vamp-plugin-sdk via synaptic and update prevu.
sudo -E prevu-update


Next I treid to build Ardour again but ran into another problem which apparently has something to do with an old version of soundtouch. I found this out from an old debian multimedia mail list.

It appears that an older version of soundtouch (1.3.0-2.2) that is in Hardy doesn't is not configured correctly. Fortunately, the version in Jaunty is a later version (1.3.1-2) which is configured correctly.

Therefore my next step is to grab the soundtouch source code from the Jaunty repository and build it. I shall also test to see if I need to actually install the library or will the prevu update work without it.

JACK

My first prevu build of JACK failed. I think it was because I needed to update prevu after building CELT and FFADO.

First I made a new directory, changed directory into it and got the source code.
mkdir jack
cd jack
apt-get source jack-audio-connection-kit


Then I reloaded the package list (since I had a new set of *.deb packages from CELT and FFADO) and installed them via synaptic before I updated prevu. Next I tried to build the package.
cd jack-audio-connection-kit-0.116.1
prevu

This build failed and told me I still needed the libcelt-dev and libffado-dev.

Once the first build failed I also moderated the control and changelog files to remove the libcelt-dev and libffado-dev build-depends and built JACK via prevu. This compiled correctly. So renamed this directory to jack-moderated from jack and recreated the jack directory and downloaded the source code again.

But before I tried to build again I updated prevu.
sudo -E prevu-update

This seemed to do the trick as when I tried to build again it worked.
prevu

Thursday, October 29, 2009

libcelt-dev

Next I need to build libcelt-dev which is part of the celt source package.

Starting in the ~/build directory I need to make a new directory and change directories to it.
mkdir celt
cd celt

Next I need the source.
apt-get source celt

Which gives a celt-0.5.1 directory, a celt_0.5.1.orig.tar.gz file, a celt_0.5.1.diff.gz file and the celt_0.5.1-0ubuntu1.dsc file.

Move intot he celt-0.5.1 directory and run prevu.
cd celt-0.5.1
prevu

And again, you are greeted with success.
** Success!. You can find source packages and .debs at /var/cache/prevu/hardy-debs **


The reason I built FFADO and CELT is because I believe libffado-dev and libcelt-dev are needed to build JACK. I do have concerns that even though I install these libraries that prevu still will not recognize them because it is running in an chroot environment. We shall see.

But the attempt will have to wait until later tonight as Ubuntu Studio 9.10 "Karmic Koala" has been released and I want to download and seed the torrent.

Wednesday, October 28, 2009

libffado

I have found that in order to build the packages that I had originally intended, i.e. JACK and Ardour, than I would need to package several others during this process. Notably, I needed to build the FFADO driver (libffado).

To this end, I first created a created under my /home directory called /build. Not very imaginative I admit.
mkdir build

This will be the main directory where other directories will be stored for the various applications and their respective source packages to be stored.

Next, I moved into the build directory and created another directory for libffado. Move into the new directory also.
cd build
mkdir libffado
cd libffado

Then I downloaded the source package.
apt-get source libffado

Under the /libffado directory that I created this created a /libffado-2.0~rc1 directory, a libffado_2.0~rc1.orig.tar.gz archived package, a libffado_2.0~rc1-0ubuntu2.diff.gz archived package and a libffado_2.0~rc1-0ubuntu2.dsc file.

The directory is for the source files, the orig.tar.gz is the original tarball from upstream, the diff.gz is a tarball of the differences between the original and the Ubuntu built pacakge and the .dsc file is a description file.

Okay, now comes the really hard part; running prevu. First we need to change directory to the source code directory and then type:
cd libffado-2.0~rc1
prevu

That's it, watch it work. It might be a while though.

If everything works well you will be told that you have a .deb file located under the /var/cache/prevu/hardy-debs directory. Of course, this is for Hardy 8.04.

Next I will be moving onto libcelt-dev because JACK requires it as a build-depends. This will provide the capability for Hardy users to use netjack if they build the CELT codec, which is a low latency codec for sending audio over the net.

The decision to build libcelt-dev was slightly difficult for me because of my general ignorance of package building. It was either build CELT also or remove it as a build-depends but then I would have jacked with the changelog and then had to change the version number of JACK and I decided that it would be simpler (hopefully) just to build CELT before building JACK. I suppose we shall find out.

prevu

prevu is an extremely handy tool for backporting and I am hoping to use it extensively in my efforts.

The first thing I did was to clean a 30 gig partition of my drive and install Ubuntu Studio 8.04 and install all the updates.

Next I installed prevu with:
sudo apt-get install prevu

The next step was to add the source repository from Juanty. This is important because prevu will build the most current available version of your application through this repository. Therefore, I opened my /etc/apt/sources.list by typing:
sudo gedit /etc/apt/sources.list

and added the following to the bottom:
# Adding jaunty sources for prevu
deb-src http://archive.ubuntu.com/ubuntu jaunty main restricted universe multiverse

This allows you (and more importantly prevu) to download the source packages from the main, restricted, universe, and multiverse repositories for jaunty.

Next I needed to initialize prevu by typing:
sudo -E prevu-init

Wait a while while it does its thing. Then it will ask if you want to add the .deb's you create as a repository. I answered yes.

This will allow you to either apt-get install or use synaptic to install the newer version applications into your older (but very stable) LTS version of Ubuntu Studio. And remove them also when necessary with apt-get or synaptic.

That's it for installing and initializing prevu. Next I'm going to document building libffado.

Changes

Well, first a brief notice of change.

I have decided to put the FOSS Music Project on indefinite hold as I have begun to help the Ubuntu Studio developers. Currently I am helping with documentation (which is effectively what this project was about, although slighter in scope), testing and perhaps backporting.

Therefore, I will probably be using this blog to help myself document some of the backporting processes.

I will be attempting to backport several applications and libraries to Ubuntu Studio 8.04 LTS Hardy including FFADO, JACK and Ardour. This will not only provide updated version of these applications but this will also provide fire wire support via the FFADO driver.

I should also point out that the next long term support (LTS) version is due in approximately six months, negating the effect of my backports with the following notable exception; I will have gained the experience of doing them. This should hopefully prepare a good foundation for helping to keep up with backporting applications for the upcoming LTS version.

Sunday, July 26, 2009

Event Horizon

It's past time for an update, so here we are.

Website
I haven't made any appreciable progress on a website. Well, not appreciable to anyone else.

I've been exploring using Drupal for the site, including as a wiki. I have bought the book Using Drupal and have read it once. My next step will be to install Drupal onto my server and perform the exercises with the book.

At this time I am more concerned with getting the content of the wiki in a state that people may use, therefore neither Drupal nor a generalized website are priorities at this point.

Wiki
The wiki is coming along nicely although it is still with minimal problems. The wiki can be found here.

Currently the wiki is usable through installation of Ubuntu Studio and I am currently working on the section that discusses tweaking the settings to improve the performance Ubuntu Studio.

Direcly following this will be defining some concepts about digital recording. And this in turn will be followed by sections discussing recording, mixing and mastering.

I will note also, that I find the main page lacking. My goal was to have it look less like a wiki, which is does, but also be appealing, which is almost, but not quite, completely fails to do.

Blog
I will try to post more in this blog as I attain significant milestones. No guarentees though, things are pretty jumping right now and the wiki takes a lot of my extra time.

Monday, May 4, 2009

Opening Remarks

We are getting close in our preparations to open the project officially which is tentatively scheduled for the beginning of June.

Some of the more immediate changes are the addition of a column to the blog so that it now contains three columns in lieu of the original two. We still need to moderate some of the widgets and their locations. And lastly, the banner needs attending as you can see that the banner picture is not centered since we added the third column.

On other fronts, we have been sending out emails to various parties and posting on some forums for advice and help. And in a remarkable case Dave Phillips, the noted Linux audio journalist and author, responded directly to our email and has offered his assistance in a few matter as his schedule allows.

We should also note that this week should culminate with the purchase of the domain name and the VPS service. This will afford us the latitude to start making the web pages and installing the wiki and tidying up a bit before going live. I had originally wanted more input before beginning but I now feel that it is more important to get it started. If things need improving or changing then we will do that as necessary.

Lastly, I would expect more posts on this blog as more of the tedious planning, research and work is accomplished.

Friday, April 17, 2009

ad initium

This is the "official" start of the FOSS Music Project.

During the following weeks I will start the project proper but this will serve to document the preparations and creation of the project.

Yay!