2011-09-19

Series: Introduction to Ubuntu Development – Part 5


This is the fifth article in a series to explain the basics of Ubuntu Development in a way that does not require huge amounts of background and goes through concepts, tools, processes and infrastructure step by step. If you like the article or have questions or found bugs, please leave a comment.
/>Thanks a lot to the Ubuntu Packaging Guide team for their work on this!

Packaging From Scratch


You have found an exciting new piece of software, it needs exposure to the wider world by getting it into Ubuntu or a PPA, so you have decided to package it.

Checking the Programme


The first stage in packaging is to get the released tar from upstream (we call the authors of applications "upstream") and check that it compiles and runs.

This guide will take you through packaging a simple application called KQRCode which has been posted on KDE-apps.org. Download version 0.4 from Sourceforge and put it in a new directory.

Now uncompress it:

$ tar xf kqrcode-0.4.tar.gz $ cd kqrcode-0.4

This application uses the CMake build system so we want to run cmake to prepare for compilation:

$ mkdir build $ cd build $ cmake ..

CMake will check for the required dependencies, in this case it tells us we need Qt and KDE libraries. We also need GCC, packagers can install build-essential which brings this in and is assumed to be installed for all packages. If you do not have the development files for these libraries installed it will fail, you can install them and run CMake again:

$ sudo apt-get install build-essential libqt4-dev kdelibs5-dev $ cmake ..

Now you can compile the source:

$ make

Running this gives some errors about missing headers. This means there are other libraries missing which were not checked by CMake. Make a note to inform upstream of this problem. packages.ubuntu.com can be used to find which packages these headers come from, install these packages and continue the compile:

$ sudo apt-get install libqrencode-dev libzbar-dev libzbarqt-dev $ make

If the compile completes successfully you can install and run the programme:

$ sudo make install $ kqrcode

Starting a Package

bzr-builddeb includes a plugin to create a new package from a template, the plugin is a wrapper around the dh_make command:

$ sudo apt-get install dh-make $ bzr dh-make kqrcode 0.4 kqrcode-0.4.tar.gz

When it asks what type of package type s for single binary.

This will import the code into a branch and add the debian/ packaging directory. Have a look at the contents. Most of the files it adds are only needed for specialist packages (such as Emacs modules) so you can start by removing the optional example files:

$ cd kqrcode/debian $ rm *ex *EX

You should now customise each of the files.

In debian/changelog change the version number to an Ubuntu version: 0.4-0ubuntu1 (upstream version 0.4, Debian version 0, Ubuntu version 1). Also change unstable to the current development Ubuntu release such as oneiric.

Much of the package building work is done by a series of scripts called debhelper. The exact behaviour of debhelper changes with new major versions, the compat file instructs debhelper which version to act as. You will generally want to set this to the most recent version which is 8.

control contains all the metadata of the package. The first paragraph describes the source package. The second and and following paragraphs describe the binary packages to be built. We will need to add the packages needed to compile the application to Build-Depends: so set that to:

Build-Depends: debhelper (>= 7.0.50~), cmake, libqt4-dev, kdelibs5-dev, libqrencode-dev, libzbar-dev, libzbarqt-dev

You will also need to fill in a description of the programme in the Description: field.

copyright needs to be filled in to follow the licence of the upstream source. According to the kqrcode/COPYING file this is GNU GPL 3 or later.

docs contains any upstream documentation files you think should be included in the final package.

README.source and README.Debian are only needed if your package has any non-standard features, we don't so you can delete them.

source/format can be left as is, this describes the version format of the source package and should be 3.0 (quilt).

rules is the most complex file. This is a Makefile which compiles the code and turns it into a binary package. Fortunately most of the work is automatically done these days by debhelper 7 so the universal % Makefile target just runs the dh script which will run everything needed.

Finally commit the code to your packaging branch:

$ bzr commit

This is the fourth article in a series to explain the basics of Ubuntu Development in a way that does not require huge amounts of background and goes through concepts, tools, processes and infrastructure step by step. If you like the article or have questions or found bugs, please leave a comment.

Thanks a lot to the Ubuntu Packaging Guide team for their work on this!

Building the package


Now we need to check that our packaging successfully compiles the package and builds the .deb binary package:

$ bzr builddeb

This should compile the package and place the result in ../build-area. You can view the contents of the package with:

$ lesspipe kqrcode_0.4-0ubuntu1_amd64.deb

Install the package and check it works:

$ sudo dpkg --install kqrcode_0.4-0ubuntu1_amd64.deb

Next Steps

Even if it builds the .deb binary package, your packaging may have bugs. Many errors can be automatically detected by our tool lintian which can be run on both the source .dsc metadata file and the .deb binary package:

$ lintian kqrcode_0.4-0ubuntu1.dsc $ lintian kqrcode_0.4-0ubuntu1_amd64.deb

A description of each of the problems it reports can be found on the lintian website.

After making a fix to the packaging you can rebuild without having to build from scratch using:

$ debuild -nc

FIXME is there a UDD equivalent? Bug https://bugs.launchpad.net/bzr-builddeb/+bug/816376

Having checked that the package builds locally you should ensure it builds on a clean system using pbuilder:

$ bzr builddeb -S $ cd ../build-area $ pbuilder-dist oneiric build kqrcode_0.4-0ubuntu1.dsc

When you are happy with your package you will want others to review it. You can upload the branch to Launchpad for review:

$ bzr push lp:~<lp-username>/+junk/kqrcode-package

You could also upload the source package to REVU for review:

$ bzr builddeb -S $ cd .. $ dput revu kqrcode_0.4-0ubuntu1.dsc

You will need to log in to REVU before you can upload to it. The package must also be correctly signed by the GPG key you have in Launchpad. See the REVU wiki page for full details.

Uploading it to a PPA (Personal Package Archive) will ensure it builds and give an easy way for you and others to test the binary packages. You will need to set up a PPA in Launchad then upload with dput:

$ dput ppa:<lp-username> kqrcode_0.4-0ubuntu1.dsc

See uploading for more information.

You can ask for reviews in #ubuntu-motu IRC channel, or on the MOTU mailing list. There might also be a more specific team you could ask such as the Kubuntu team for KDE packages.



Source

Recent Unity Updates Bring Changes to Workspaces Overview, Alt+Tab & Unity Launcher


With Beta 2 of Ubuntu 11.10 quickly approaching us – it’s due on September 22nd – things haven’t exactly been standing still in development land.

Below are a number of minor, but pretty noteworthy, visual tweaks that Ubuntu 11.10 has received over the last week.

Alt+Tab changes>
Windows displayed in the Alt+Tab window switcher are now all the same height; only the width varies between applications.



Tapping down whilst highlighintg an app icon in the switcher now reveals a larger preview with a new orange border for highlighting.


Launcher


The Unity Launcher,, “Big Fat Button”, Workspace Switcher, Lenses and Track launcher icon all use the “average background colour” of your wallpaper – just as the Dash and Panel have done for the last few releases.

The result is stunning in action, as demonstrated in the short video below: -


Window Snapping


I won’t call it “Aero Snap”, but I will call it less blinding: the golden effect when dragging a window to the edge of your screen has been toned down in recent updates: -


Workspaces


The “Workspaces Overview” has a tighter, more compact look, complete with orange border for “active/selected” workspace and the dimming out of workspaces without an active application on.


Software Centre


The revamped Ubuntu Software Centre has had a detailed eye cast of it, with recent updates brining tighter spacing and less padding, along with less gaudy headers (no more orange), a much better banner, and other subtle improvements.



To keep you abreast of installation progress the Software Centre has a new look toolbar-based ‘spinner’: -



Accessibility wise, the Software Centre now plays nicely with High Contrast themes: -


Dash


The Dash and Lenses now sport slightly bigger icons.



Source

Semantic Launcher Synapse Sees New Release


It’s been a literal age since we last mentioned the neat semantic file and application launcher Synapse.

With the introduction of Unity as Ubuntu’s default desktop shell the need for a dedicated ‘shortcut based’ app launcher was negated thanks to the keyboard-friendly nature of Unity’s Dash.

But Synapse has always been more than ‘just an application Launcher’; with the push of Ctrl+Space its Zeitgeist integration provides comprehensive searching of files, places, recent activities, websites and more. A raft of additional plugins provide ‘actions’ for files other than ‘open’ – such as quick uploading of images to online hosting site Imgur; control of music players Banshee and Rhythmbox; searching a dictionary for definitions, and much, much more.

What’s new in Synapse 0.2.8?


Today saw the release of Synapse 0.2.8, and with a new release comes new features, the most notable of which is the inclusion of a new theme: ‘Side Doish’.

‘Side Doish’ is a narrower version of the ‘Doish’ theme previously included.

Side Doish theme in Synapse 0.2.8

A ‘Related Files’ plugin also debuts in this release, and makes finding applications, folders and other files used in, resulting from, or otherwise used in relation to another file stupidly easy.

In the example below I searched for ‘related files’ to a ‘lastfm.py’ script that enables Last.FM scrobbling in Google Music Frame. Synapse found the file, the application it’s used with, Gedit – which was used to edit a config file – and the Terminal – which I had been using to launch Google Music Frame. 

related files plugin for Synapse

Download


Ubuntu 10.04, 10.10, 11.04 and 11.10 users who want in on the Synapse action can do so by adding the official ‘stable release’ PPA – ppa:synapse-core/ppato their Software Sources, running an update and then installing ‘Synapse’ from the Ubuntu Software Centre.

N.B: Synapse works (and looks) best under a composited desktop. 



Source

Desura Client for Linux Enters Beta, Hints At New Games For Linux


Linux users are one step closer to having a native version of indie-game store Desura with the recent launch of a closed beta client for the service.

Currently the beta is only available to a ‘selected few’ as it undergoes testing and bug elimination. But don’t let this annoy you as the developers have stated: -

“Once our testers are happy, we will be opening the beta to everyone.”

Anyone wishing to apply for the Beta Programme – “it’s never too late” say the developers – will need to join this Desura group.

The developers also note that whilst users can browse and buy games on Linux, anyone without access to the beta won’t be able to download and play them.

New Games


Interestingly – or should that be teasingly? – the release announcement gives an exciting hint as to the future of Linux-compatible games to be offered by the service:

“We’ve got plenty more games coming, some never before on Linux, so much to look forward to.”

Source

 



Source