Planet maemo: category "feed:7db91e18d7877d643bd6041708ad06bd"

David King

Packaging Glom for Maemo 5

2009-11-04 20:01 UTC  by  David King
0
0
I have finally got Glom packaged for Maemo 5. It is currently in extras-devel and is installable from the Application Manager. This took quite a bit of work, which I put down to not knowing enough auto-fu. However, the Debian packages are now /opt-ified, and the DBus .service file and .desktop file are installed to the correct locations on Maemo, which gives working application launcher icons. The process for doing this is not particularly well-documented (the best documentation is from Diablo), so here is a quick list of what the average (moderately complex desktop application) Debian package would need in order to be modified for Maemo:
  • Maemo-optify support. This involves running maemo-optify just before dh_builddeb is run, and adding maemo-optify to the package's Build-Depends. For CDBS packages, this can be performed in the binary-install target. Glom produces several binary packages from a single source package, and maemo-optify is run for each binary package to be optified. There are alternatives to running maemo-optify, but it was something that I wanted to try out, and it worked.
  • DBus .service file and .desktop file modifications. This involves adding a X-Osso-Service line to the .desktop file, e.g. X-Osso-Service=org.maemo.glom. Then, a DBus .service file must be created, with the same service identifier, e.g. Name=org.maemo.glom. The paths for installation of these files can be obtained via pkg-config from osso-af-settings (do not forget to add it to the Build-Depends of the package). My changes to Glom are in git (and a patch in the Glom package). The application must respond to DBus events if it is started in this way, and the simplest way to do this is to pass the DBus service name as a parameter to osso_initialize(), from libosso.
  • Maemo-specific MIME-type modifications. Assuming that an application already installs MIME-type information and desktop files, and updates the databases correctly, there is one modification that can make things nicer on Maemo. There is an additional category that can be added to the MIME-type description. The change is safely ignored on non-Maemo-platforms.
  • Atypically, Glom links to libgettextpo (most packages that use gettext for translations do not need to do this), and the package list on an N900 and in the SDK/package autobuilder is different, such that the required package does not exist on the N900. Rather than packaging gettext or libgettextpo for the N900, I decided to statically link to the library on Maemo only. This neatly solves the problem, and only increases the binary size by a few kB.
Categories: packaging
David King

Glom and Qt — Qlom

2009-10-07 10:12 UTC  by  David King
0
0
I have been learning Qt at Openismus for a while, and recently started playing with the Maemo port. The result so far is Qlom, a Glom database viewer:


While Glom is a Gtkmm application, it has a non-UI library component called libglom, which I have used from within Qt to deal with all the Glom document-parsing. It was interesting to find out that Qt uses the Glib main loop, which made everything a lot easier. I had to use Qt built from git in order to get the Maemo theming shown above, and some widgets are still not themed correctly, but hopefully this will improve with future releases against the final SDK.

I will be presenting a talk at the Maemo Summit in Amsterdam on Saturday, at 12:00 in the N800 room. The talk is titled "Maemomm: Maemo with C++ and a Gtkmm flavour", where I will discuss the C++ bindings for Maemo Fremantle, which I have also worked on at Openismus. There will even be some comparisons with Qt…
Categories: c++
David King

BeagleBoard guide

2009-09-17 09:44 UTC  by  David King
0
0
We got a couple of BeagleBoards at the office a while ago, and have been playing with them a lot. As low-powered Linux-running devices they are quite fun, and being a completely different architecture brings some interesting problems. However, there is lots of active development to improve the support, both from the kernel and userspace. There are several distributions and toolchains that can be used, and the setup is relatively painless.

To make it easier, we have written a guide on Getting started with the BeagleBoard, based on our experiences. We would be grateful for any comments or suggestions, enjoy!
Categories: documentation
David King

New Hildonmm and Gtkmm releases available

2009-07-24 10:49 UTC  by  David King
0
0
With the latest Beta2 SDK for Fremantle, GTK+ was updated to 2.14 from 2.12. We (Openismus) made a new release of Gtkmm and Glibmm, which are both packaged and uploaded to extras-devel, as you can see with the new maemo.org/packages. There is also an updated hildonmm release, with improved documentation. Many thanks to Claudio and Alberto for applying patches that I submitted, to improve the Hildon C API reference (and our C++ API reference, which is automatically generated from it). If you spot any bugs, please email the Gtkmm mailing list about the problem, and we'll fix it.

Finally, there is a testing release of libhildondesktopmm, available from the Maemomm garage page. It's not finished yet, and does not appear to work well in Scratchbox, but with some testing and bug reports, we're sure that it will improve.
Categories: c++
David King

Maemomm documentation 2.1.0

2009-06-11 18:16 UTC  by  David King
0
0
For the past couple of weeks I have been writing some documentation for the C++ bindings for the Maemo platform. This was my first chance to use DocBook for writing documentation, although I learnt about it previously. I am used to writing with LaTeX in academia, but found DocBook to be quite easy. Much of this was due to the build system and styling already being in place, making my changes a simple matter of copying the style and formatting of existing sections in the documentation. Of course, simple changes don't take two weeks, and the fun started when writing examples.

There is a lot of new API that was added to hildon since Diablo, and unfortunately the API reference is quite poor, compared to the GTK+ documentation, for instance. This made my job a lot harder, as much of the documentation for the C++ bindings is automatically copied from the C API reference. In some cases, there was not even skeleton documentation for the C API, so I had to look at the source code of hildon to guide me. However, eventually I was able to figure out how the new API was supposed to be used and write some examples, as well as tutorial documentation to go with them. Not only that, but a bug that I filed regarding the lack of documentation got fixed, and I will surely find a few more bugs, so the documentation should improve for everyone (eventually).

When I committed my documentation changes, Murray would review and send me comments, or apply some simple fixes himself, and over the course of the project I was able to get closer to his desired coding and writing style. Hopefully, in future, fewer or no changes will be required! Now that I've finished, I feel a lot more comfortable with the Maemo APIs and also Gtkmm, and the process of documenting an API which I had very little experience of was actually pretty fun.
Categories: packaging
David King

Maemomm (re)packaging

2009-05-12 08:34 UTC  by  David King
0
0
With the recent release of the Maemo 5 Beta SDK, I was given the task to update the Maemomm bindings maintained by Openismus and upload them to the extras repository. I had previously done some packaging for the Maemo 5 Alpha SDK, but this was to be a much bigger job.

Much of the work was quite simple, as Murray had pointed me to his short guide on updating Debian packages. For some simple packages it was sufficient to bump version numbers, check and update dependencies and upload to extras. Where libraries were concerned, I also had to be sure to update the .so version correctly.

Some of the packages that I updated did not provide debug symbol packages, so these had to be added. This was a case of checking the debhelper compatibility level, and passing the correct package name to dh_strip in the debian/rules file. For some unknown and stupid reason, when the debhelper compatibility level is set to less than or equal to 4, and dh_strip is passed the --dbg-package=packagename argument, the specified "debug package" is stripped of its debug symbols which are then placed in a new package with "-dbg" appended to the original packagename. When the debhelper compatibility level is greater than 4, this behaviour is (correctly) reversed, and the --dbg-package argument really does specify a "debug package", traditionally named "packagename-dbg", and not a stripped package.

I also had to make some tarball releases, as most of the packages that needed packaging for Maemo 5 had received changes to keep current with the updates in the SDK. This was quite simple, as all the packages made use of autotools, so a "./autogen.sh && make && make distcheck" was sufficient in most cases, after updating version numbers, ChangeLog, NEWS and some package-specific things. This meant that for the first time I got to commit my changes to a public SVN repository. It was quite a scary experience as opposed to Git, where committing changes is local, and only pushing them is scary.

The final stage was uploading the packages to the Maemo autobuilder, where the source is built using a minimal dependency list (generated from the "Depends:" line of the debian/control file), and, if the build was successful, uploaded to the extras-devel repository for wider consumption. The status of the build is made available once the process is complete, allowing changes and a re-upload if it failed, or adding the package to the extras-devel repository on success.

I now feel a bit more confident about Debian packaging (although I have surely made some mistakes), so hopefully next time the process should be even smoother.
Categories: packaging