Canonical Voices

Posts tagged with 'debian'

Timo Jyrinki

It was good that I didn't hold up my blog post in November until the videos from FSCONS 2010 (Free Society Conference and Nordic Summit) are out, but now they finally are:


Timo Jyrinki - Tuning an old but free phone (pt 1/2)
Timo Jyrinki - Tuning an old but free phone (pt 2/2)

Definitely see also all videos and since Vimeo doesn't work in Gnash, use a script to download.

ps. As a related item to the talk's future oriented aspects, while waiting for GTA04A3 boards to arrive, GTA04A2 has been patched to run Debian/LXDE.

Read more
pitti

As a followup action to my recent Talk about PyGI I now re-used my notes to provide some real wiki documentation.

It would be great if you could add package name info for Fedora/SUSE/etc., and perhaps add more example links for porting different kinds of software! Please also let me know if you have suggestions how to improve the structure of the page.

Read more
pitti

On next Monday this cycle’s Ubuntu Application Developer Week classes will start.

The topic that kept me busy most in this cycle was Python gobject-introspection, and porting pygtk2 apps to PyGI (see my initial steps and my report from the PyGI hackfest.)

To spread the love, there will be two talks about this next week: On Monday 17:00 UTC the very Tomeu Vizoso himself will explain what gobject-introspection (“GI”) is, why we need it, and how library developers use it to ship a good and useful GI binding (“typelib”) for application developers. I will then follow up on Tuesday 16:00 UTC about the app developer side, in particular how to use the GI typelibs in Python, and how to port PyGTK2 applications to PyGI.

For the most part these sessions are distribution neutral (we don’t have any special sauce for this in Debian/Ubuntu, it all happened right upstream :-) ); only a very small fraction of it (where I explain package names, etc.) will be specific to Debian/Ubuntu, but shouldn’t be hard to apply to other distributions as well.

So please feel invited to join, and bombard us with questions!

Read more

Photo



Read more
Timo Jyrinki

The 2008 product release, Openmoko Inc's – now in other business areas than mobile phones – Neo FreeRunner is finally starting to get a ”spiritual” successor, in form of the GTA04 project (not to forget about gta02-core project, either). Yes, the ”even schematics and cover CAD files are CC-BY-SA” free mobile phone is back... or at least if the German company Golden Delicious finishes what's it has been doing lately. Of course, the original FreeRunner is also still on sale as an improved version.

Since I have two FreeRunners, I look forward to replacing one of those with the new innards while keeping the other one as a daily phone while kernel and modem drivers get ready with the new platform. With a newer platform with ARMv7 instruction set, there would be easily also other ”traditional” distributions choices besides Debian to choose from, like Ubuntu or MeeGo. Both have oFono (+ telepathy etc.) packaged up, while Ubuntu also has a lot of the FreeSmartphone.Org (FSO) stack that has come to Ubuntu from Debian's pkg-fso team that I'm part of. Both software stacks are capable of getting updated with new modem drivers, although I think currently FSO has more daily / only phone users than oFono at this point of time still (I haven't yet heard of many Nokia N900 users using only free software distribution while using the phone functionality of such a distro as the one to count on).

So, a quote from today's Openmoko Community Updates:

---cut---

GTA04

GTA04 is a project by the long time distributor and hw developer, German company Golden Delicious. The name is loaned from Openmoko project because of the spiritual continuation - GTA01 was the codename for Neo1973, GTA02 was the Neo FreeRunner, and GTA03 was the canceled successor product. Besides offering improved versions of Neo FreeRunner (better battery life, better audio output), they've a complete replacement board planned to fit an existing Neo FreeRunner case and use the existing display.

The key details of GTA04 include among else:

  • OMAP3530 ARMv7 CPU
  • UMTS/3G (HSPA)
  • USB 2.0 OTG
  • WLAN, BT, FM transceiver
  • Barometric Altimeter, Accelerometer, Compass, Gyroscope
  • Optionally camera

Find your GTA04 information at the following addresses:

Latest news:

Visit the FOSDEM in Brussels, Belgium next weekend (5th/6th of February, 2011) to see GTA04 in action and discuss about it! See http://fosdem.org/2011/ , http://wiki.openmoko.org/wiki/FOSDEM_2011 , http://lists.openmoko.org/pipermail/community/2010-December/063899.html

---cut---

Read more
pitti

(Update: Link to Tomeu’s blog post, repost for planet.gnome.org)

Last week I was in Prague to attend the GNOME/Python 2011 Hackfest for gobject-introspection, to which Tomeu Vizoso kindly invited me after I started working with PyGI some months ago. It happened at a place called brmlab which was quite the right environment for a bunch of 9 hackers: Some comfy couches and chairs, soldering irons, lots of old TV tubes, chips, and other electronics, a big Pirate flag, really good Wifi, plenty of Club Mate and Coke supplies, and not putting unnecessary effort into mundane things like wallpapers.

It was really nice to get to know the upstream experts John (J5) Palmieri and Tomeu Vizoso (check out Tomeu’s blog post for his summary and some really nice photos). When sitting together in a room, fully focussing on this area for a full week, it’s so much easier to just ask them about something and getting things done and into upstream than on IRC or bugzilla, where you don’t know each other personally. I certainly learned a lot this week (and not only how great Czech beer tastes :-) )!

So what did I do?

Application porting

After already having ported four Ubuntu PyGTK applications to GI before (apport, jockey, aptdaemon, and language-selector),
my main goal and occupation during this week was to start porting a bigger PyGTK application. I picked system-config-printer, as it’s two magnitudes bigger than the previous projects, exercises quite a lot more of the GTK GI bindings, and thus also exposes a lot more GTK annotation and pygobject bugs. This resulted in a new pygi s-c-p branch which has the first 100 rounds of “test, break, fix” iterations. It now at least starts, and you can do a number of things with it, but a lot of functionality is still broken.

As a kind of “finger exercise” and also to check for how well pygi-convert works for small projects now, I also ported computer-janitor. This went really well (I had it working after about 30 minutes), and also led me to finally fixing the unicode vs. str mess for GtkTreeView that you got so far with Python 2.x.

pygobject and GTK fixes

Porting system-config-printer and computer-janitor uncovered a lot of opportunities to improve pygi-convert.sh, a big “perl -e” kind of script to do the mechanical grunt work of the porting process. It doesn’t fix up changed signatures (such as adding missing arguments which were default arguments in PyGTK, or the ubiquitous “user_data” argument for signal handlers), but at least it gets a lot of namespaces, method, and constant names right.

I also fixed three annotation fixes in GTK+. We also collaboratively reviewed and tested Pavel’s annotation branch which helped to fix tons of problems, especially after Steve Frécinaux’s excellent reference leak fix, so if you play around with current pygobject git head, you really also have to use the current GTK+ git head.

Speaking of which, if you want to port applications and always stay on top of the pygobject/GTK development without having to clutter your package system with “make install”s of those, it works very well to have this in your ~/.bashrc:

export GI_TYPELIB_PATH=$HOME/projects/gtk/gtk:$HOME/projects/gtk/gdk
export PYTHONPATH=$HOME/projects/pygobject

Better GVariant/GDBus support

The GNOME world is moving from the old dbus-glib python bindings to GDBus, which is integrated into GLib. However, dbus-python exposed a really nice and convenient way of doing D-Bus calls, while using GDBus from Python was hideously complicated, especially for nontrivial arguments with empty or nested arrays:

from gi.repository import Gio, GLib
from gi._gi import variant_type_from_string

d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)

vb = GLib.VariantBuilder()
vb.init(variant_type_from_string('r'))
vb.add_value(GLib.Variant('s', 'test'))
vb.add_value(GLib.Variant('u', 1))
vb.add_value(GLib.Variant('s', 'gtk-ok'))
vb.add_value(GLib.Variant('s', 'Hello World!'))
vb.add_value(GLib.Variant('s', 'Subtext'))
# add an empty array
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('as'))
vb.add_value(eavb.end())
# add an empty dict
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('a{sv}'))
vb.add_value(eavb.end())
vb.add_value(GLib.Variant('i', 10000))
args = vb.end()

result = notify.call_sync('Notify', args, 0, -1, None)
id = result.get_child_value(0).get_uint32()
print id

So I went to making the GLib.Variant constructor work properly with nested types and boxed variants, adding Pythonic GVariant iterators and indexing (so that you can treat GVariant dictionaries/arrays/tuples just like their Python equivalents), and finally a Variant.unpack() method for converting the return value of a D-Bus call back into a native Python data type. This looks a lot friendlier now:

from gi.repository import Gio, GLib

d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)

args = GLib.Variant('(susssasa{sv}i)', ('test', 1, 'gtk-ok', 'Hello World!',
    'Subtext', [], {}, 10000))
result = notify.call_sync('Notify', args, 0, -1, None)
id = result.unpack()[0]
print id

I also prepared another patch in GNOME#640181 which will provide the icing on the cake, i. e. handle the variant building/unpacking transparently and make the explicit call_sync() unnecessary:

from gi.repository import Gio, GLib

d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)

result = notify.Notify('(susssasa{sv}i)', 'test', 1, 'gtk-ok', 'Hello World!',
            'Subtext', [], {}, 10000)
print result[0]

I hope that I can get this reviewed and land this soon.

Thanks to our sponsors!

Many thanks to the GNOME Foundation and Collabora for sponsoring this event!

Read more
Timo Jyrinki

Just a note that the slides are available (non-slideshare link) for my presentation ”Tuning an old but free phone” (description) that I held in the tremendously great event FSCONS 2010. It could be described as a smaller scale FOSDEM, but that would be actually down-playing it since the free software effects on society are something that I've actually never seen elsewhere on such a scale. My talk was among the purely technical ones, though.

I was planning to hold on with this blog post until the recorded videos arrive, but since it seems it might not be during this year I will just post this now that slides are available.

I've shared a few photos as well at Flickr...


Keynote: Karin Kosina, The Inanna Project. A tech + art workshop for female artists in Damascus, Syria. An experiment in art, technology, and the transformative power of Free Hardware and Software.


Erik de Bruijn, The Future of RepRap, a self-replicating open source 3D printer that fabricates arbitrary objects including parts of itself.


Social event at the Berg 211.


Malin Nilsson on Gender, class and global flows. Using free software to fuel a revolution in home based industrial work.



Keynote: Glyn Moody, Ethics of Intellectual Monopolies.


Keynote: Glyn Moody, Ethics of Intellectual Monopolies (audience).

A few summaries available on a Qaiku seminar channel.

Read more
Timo Jyrinki

(many exciting news from this old project/community working on the "Free Your Phone" idea, so as an publisher of the update sharing via blog as well. FreeRunner still available at eg. http://www.pulster.de/engl/index.html and the improved "+" versions at http://www.handheld-linux.com/wiki.php?page=Neo%20Freerunner, if an old/slow hardware is enough for you when you know you can tweak it to your liking)
Period 2010-09-01 to 2010-10-31

Distributions

Debian GNU/Linux

Debian is a universal operating system used on many embedded devices, servers and home computers. Using Debian on the FreeRunner gives access to the huge army of software packaged in the Debian repositories, already compiled for the Neo's ARM(v4) processor. Moreover, one can build one's own source files for programs without having to learn the OpenEmbedded way. For an existing Debian/Ubuntu user, choosing Debian for Neo FreeRunner makes phone a very familiar, trustworthy and flexible place to hack in.

General news:



Codename: 'sid'
Homepage: http://wiki.debian.org/DebianOnFreeRunner
Image: http://wiki.openmoko.org/wiki/Debian

Hardware Works
Neo 1973 yes
FreeRunner yes
HTC-Dream yes
Other yes


Applications

New Applications

aTrack 0.8

APRS tracker and communicator for mobile devices. It turns your Neo into bidirectional APRS unit and besides others it allows you to track your position, do text messaging, object creation or display stations around.


Homepage: http://atrack.googlecode.com/
Package: [1]
Tested on: SHR-Unstable


Application Updates

Gamerunner GnuBoy 0.8

A gameboy emulator which runs very nice, even with sound (sometimes it freezes, then you have to press the A button and everything is ok). You need the gamerunner distro or a gamepad to use it. Using frameskip to run smooth at 320*240 pixel. In second controll mode in gamerunner you can use savestates by pressing top right corne to save and left lower corner to load. Select is right lower corner.


Homepage: http://jlime.com/forum/viewtopic.php?f=117&t=3005
Package: [nopacket no packet sorry]
Tested on: Gamerunner, QTMoko


FoxtrotGPS 1.0.0

FoxtrotGPS is an offshoot of Marcus Bauer's excellent Free & Open Source tangoGPS application, with a focus on cooperation and fostering community innovation. 1.0.0 announcement.

  • Gracefully recovering from gpsd shutting down
  • GPX routepoints support
  • Integration of distribution patches
  • Map tiles are displayed immediately after downloading
  • GeoRSS points can be imported as POIs (script)
  • Various other fixes and improvements
  • Since no feedback gotten from the sister project and some changes will not be imported, version number 1.0.0 was selected to show that there is divergence


Homepage: http://www.foxtrotgps.org/
Package: foxtrotgps
Tested on: Debian


General News

Most important and change making mails on the mailing lists, blogs etc.. Coolest hacks, screenshots, themes etc..

GPRS

  • GPRS on FreeRunner is unstable? Too many connections hang the modem? Unfixable? NO MORE! Our magician lindi has conjured a tc (traffic control) command that makes the data flow more stable even under heavy load. Huge thanks! http://docs.openmoko.org/trac/ticket/2264#comment:21 (use the lower one for faster operation)

Kernels

Spin-off Hardware Projects

Event News

  • 2010-10-12 Next "FYP.de / Openmoko Stammtisch" in Munich, Germany [2]
  • 2011-01-24 Mobile FOSS MiniConf at LCA2011 announced a call for papers that closes on Friday 22nd October 2010. So submit something about OpenMoko today!
  • 2011-02-05/06 FOSDEM 2011 calls for Main Speakers and Devrooms [3] that closes on Saturday 16th October 2010. So submit something about OpenMoko today!

Read more
pitti

After 20 days of final polishing and maturing since the release candidate, the PostgreSQL team released the final 9.0 version today.

Hot off the press, I uploaded postgresql-9.0 final into Debian unstable; they will not go into Debian Squeeze, because Squeeze is frozen and it will take a long time to port all the packaged server side extensions to 9.0.

If you are on Ubuntu 10.04 LTS or Ubuntu 10.10, you can add my PostgreSQL backports for stable Ubuntu releases PPA, which will carry 9.0 until it can be moved to the official Ubuntu backports (i. e. when 9.0 goes into Ubuntu Natty).

Enjoy, and kudos to the PostgreSQL team!

Read more
pitti

It’s been a decade ago when I did my first steps with contributing to Free Software, about seven years when I joined Debian, and about 6 with Canonical and Ubuntu. Time for some reflection what I have done over these years!

Distribution Packaging and Maintenance

My first sponsored Debian upload ever was cracklib2, which seriously needed some love and was looking for a new maintainer. So in that upload I managed to close all outstanding bugs. Thanks to my mentor Martin Godisch about providing a lot of guidance for this!

Since then I’ve maintained various packages, where the most popular ones are certainly the free database server “PostgreSQL” (see next section) and the e-book management software “Calibre”.

“Maintaining” by and large means “making it really easy to get and use this software”. This decomposes to:

  • Packaging it in a way that a simple apt-get install makes the software work out of the box (as far as possible)
  • Provide a default configuration/customizations so that it integrates and plays well with the rest of the system; this includes the paths and permissions for log files, log rotation, debconf, configuration file standards, etc.
  • Be the front line for bug reports from users, sort, answer, and de-duplicate them, and either fix them myself, or forward useful bugs to upstream.
  • Providing security updates for stable releases
  • To some extent, help with the development of the software; this gets mostly driven by user demand, and of course my personal interests.

In August 2004 I got employed by Canonical to work full time on Ubuntu, which pretty much turned a hobby into a profession. I never regretted this in the past years, it’s an awesome job to do!

In principle I’m doing the same thing in Ubuntu as well: Bring stuff from developers to the people out there. Except with a different focus, in Ubuntu my daily bread and butter is the GNOME desktop and stuff around (and immediately below) it. And even though after a long day of bug triaging and debugging I feel a bit low-hearted (“50.000 bugs away from perfection”), when I take a step back and see how much the usage of Free Software in the world has grown since 2004, I am very proud of being part of Ubuntu, which certainly has its fair contribution and share in this growth. So what seemed like a crazy idea from Mark back in 2004 actually has made a remarkable progress.

In the beginning of Ubuntu I mostly sent back patches to the Debian bug tracker, but this evolved quite a bit on both sides: These days I try to keep “my” packages in sync and commit stuff directly to Debian, which works very well with e. g. the pkg-utopia team, which is responsible for HAL, udisks, upower, PolicyKit, and related packages. At this point I want to thank Michael Biebl for being such an awesome guy on the Debian side! Also, it seems that Debian has moved a fair bit away from the strong “Big Maintainer Lock” towards team based maintenance, so these days it is easier than ever to commit stuff directly to Debian for a lot of packages, without much fuss.

PostgreSQL

I have done a handful of changes to PostgreSQL, but these mostly concerned easy packaging and crash fixes, nothing out of the ordinary. I’m not really a PostgreSQL upstream developer.

The thing I am really proud of is the postgresql-common package, which is a very nice example what a distro can provide on top of upstream: If you install the upstream tarball, you have to manually care for creating clusters, providing a sensible configuration for them, set up SSL, set up log rotation, etc. With postgresql-common, this is all done automatically. The biggest feature it provides is a robust and automatic way of upgrading between major releases with the pg_upgradecluster tool, which takes care of a dozen corner cases and the nontrivial process of dumping the old cluster and reloading the new one. Also, you can effortlessy run several instances of the same version in parallel, so that you can e. g. have a production and a development instance, or try the new 9.0 RC1 while still running the 8.4 production one. (more details)

Crash Reporting with Apport

This has been a pet peeve of mine pretty much from day 1. Back in the old days, crashes in software were a pain to track down: many crashes are hard to reproduce, it takes ages to get useful information from bug reporters, and a lot of data cannot be recovered any more when you try to reproduce and analyze a crash after the fact.

With the growing demand for QA from both Canonical and Ubuntu, in 2006 I finally got some time to start Apport, which would make all this a lot easier: It intercepts crashes as they happen, collects the data that we as a developer need, and makes it very easy for the user to submit them as a bug report. This is accompanied by a backend service (called “retracers”) which would reprocess the bug reports by taking the core dump, reproducing a chroot with the packages and versions that the reporter had, installing the debugging symbols, and re-running gdb, to produce a fully symbolic stack trace.

See this bug report for how this looks like. Since then, tons of crashes were fixed, way more than we could ever have done “the old way” with asking users to rebuild with “-g -O0″, running gdb, etc.

By today, Apport has grown quite a bit: rich bug reports, per-package hooks, automatic duplication of crashes, interactive GUI elements in hooks, etc.

Plumbing Development

Handling hotpluggable hardware has always interested me, since the day when I got my first USB stick and it was ridiculously hard (from an user perspective) to use it:

    $ su -
    # mount -t vfat -o uid=1000 /dev/sda1 /mnt

My first go at this was to write pmount which would allow normal users to mount hotpluggable storage without root privileges and worrying about mount paths and options, and then integrate it into GNOME and HAL. Personally I abandoned it years ago, but it seems other people still use it, so I’m glad that Vincent Fourmond took over the maintenance now.

Since then, the entire stack evolved quite a bit: HAL grew to something useful and rather secure, and finally into some monstrous unmaintainable beast, which is why it was declared dead in 2008, and replaced with the “U” stack: udev, udisks, upower, etc. I enjoy hacking on that a lot, and since it’s part of my Desktop Team Tech Lead/Developer role in Canonical, I can spend some company time on it. so far I worked on bug fixes, small new features, and writing a rather comprehensive test suite for udisks (see my udisks commits so far). I also did a fair share of porting stuff away from HAL to the new stack, including some permanent commitments like maintaining the keymaps in udev.

GNOME

Before I started with Canonical I was never much of a GUI person: I was fully content with fvwm and a few xterms around it. But as an Ubuntu developer I do dogfooding, and thus I switched to GNOME for my day to day work. It didn’t take long before I really fell in love with it!

Similar to my Debian packages, my upstream involvement with GNOME is mostly integration and bug fixing. As already explained, we get a looooot of bug reports, so my focus is mostly on bug fixing. To date, I sent 93 patches to bugzilla. Since January 2010 I became a committer, so that it’s easier for me to get patches upstream.

Debugging problems and fixing bugs is a pretty tedious task, but I still enjoy the rewarding nice feeling when you finally tracked down something and can close a bug with 50 duplicates, and you have made people’s life a little bit easier from now on.

Read more
beuno

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it's been 8 months since I've left the team and the established process is still on-going.

I wrote a paper on the whole experience and presented it at the agile conference XP2010 in Norway.

Here's the introduction:

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn't about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

Here's the paper for download: xp2010_paper.pdf

Read more
pitti

PostgreSQL 9.0 with a whole lot of new features and improvements is nearing completion. The first release candidate was just announced.

As with the beta versions, I uploaded RC1 to Debian experimental again. If you want to test/use them on Ubuntu 10.04 (Lucid Lynx), you can get packages from my “PostgreSQL backports for stable Ubuntu releases” PPA. Please let me know if you need them for other releases.

Just for the records, both Debian 6.0 “Squeeze” and Ubuntu 10.10 “Maverick Meerkat” will release and officially support 8.4 only, as 9.0 is too late for the feature freezes of both. Also, it will take quite some time to update all the packaged extensions to 9.0. As usual, 9.0 will be provided as official backports for both Debian and Ubuntu.

Happy testing!

Read more

During our Debconf we were wondering how many people shared the common link of being both Ubuntu Developers and working in Debian. The initial list is 62! (Make that 59, see below) Thanks to Lucas Nussbaum and Michel Bienia for this first cut.

Ond?ej Surý, Fabio Tranchitella, Kees Cook, LI Daobing, Fathi Boudra, Steve Kowalik, Benjamin Mako Hill, Scott Kitterman, Alexander Sack, Colin Watson, Sebastien Bacher, Martin Meredith, Andrew Mitchell, Daniel Silverstone, LaMont Jones, Fabio Massimo Di Nitto, Loïc Minier, ???? ???????? (Ahmed El-Mahmoudy), Luca Falavigna, Laurent Bigonville, Philipp Kern, Martin Pitt, Matthias Urlichs, Sebastian Dröge, Luke Faraone, Steve Langasek, Thom May, Matthias Klose, Alessio Treglia, Iulian Udrea, Timo Jyrinki, Emilio Pozuelo Monfort, Albin Tonnerre, Stefan Potyra, Andrea Veri, Scott Howard, Nicolas Valcárcel, Raphaël Hertzog, Reinhard Tartler, Julian Andres Klode, Barry deFreese, Benjamin Drung, Michael Banck,  Riccardo Setti, Lucas Nussbaum, Adam Conrad, Michael Vogt, Jelmer Vernooij, Adrian Perez, Robert Collins, Tollef Fog Heen, Gerfried Fuchs, Mark Shuttleworth, Andrew Pollock, Sylvestre Ledru, Michael Casadevall, Ben Collins, Jo Shields, and Chris Cheney

This is a list of people who are in ubuntu-dev or ubuntu-core-dev AND have their key in the Debian keyring, it’s not an indicator of how active that person may or may not be. Here are the scripts they used if you’re interested in working on this sort of thing.

UPDATE: mdz, keybuk, and Kyle McMartin are emeritus, I’ve removed them from the list.

Read more
beuno

We have very exciting and challenging plans for the future of the new web+mobile Ubuntu One team (more on this soon), and we’re looking for an exceptional web engineer to join us.

The summary for this position is:

We are looking for an exceptional engineer to work on Ubuntu One’s web infrastructure with a proven track record for exceptional problem solving and integration into third-party systems. This person should help the team design, build, and deploy web and mobile applications with a high degree of quality and passion. If you’re the type of person who gets excited about delivering cutting-edge technology to hundreds of thousands of users, in a lean and friendly environment, we are looking for you!

If this sounds like you, check out the full job description and send us your CV!

Read more
Barry Warsaw

My friend Tim is working on a very cool Bazaar-backed wiki project and he asked me to package it up for Ubuntu. I'm getting pretty good at packaging Python projects, but I always like the practice because each time it gets a little smoother. This one I managed to package in about 10 minutes so I thought I'd outline the very easy process.


First of all, you want to have a good setup.py, and if you like to cargo cult, you can start with this one. I highly recommend using Distribute instead of setuptools, and in fact the former is what Ubuntu gives you by default. I really like adding the distribute_setup.py which gives you nice features like being able to do python setup.py test and many other things. See lines 18 and 19 in the above referenced setup.py file.

The next thing you'll want is Andrew Straw's fine stdeb package, which you can get on Ubuntu with sudo apt-get install python-stdeb. This package is going to bootstrap your debian/ directory from your setup.py file. It's not perfectly suited to the task (yet, Andrew assures me :), but we can make it work!

These days, I host all of my packages in Bazaar on Launchpad, which is going to make some of the following steps really easy. If you use a different hosting site or a different version control system, you will have to build your Ubuntu package using more traditional means. That's okay, once you have your debian/ directory, it'll be fairly easy (but not as easy as described here ). If you do use Bazaar, you'll just want to make sure you have the bzr-builddeb. Just do sudo apt-get install bzr-builddeb on Ubuntu and you should get everything you need.

Okay, so now you have the requisite packages, and a setup.py, let's build us a deb and upload it to our personal package archive so everyone on Debian and Ubuntu can easily try it out.

First, let's create the debian directory. Here's the first little icky bit:

% python setup.py --command-packages=stdeb.command sdist_dsc

Notice that this leaves us with a deb_dist/ directory, not the debian/ directory we want. The latter is in there, just buried a bit. Let's dig it out:

% mv deb_dist/wikkid-0.1/debian .
% rm -rf deb_dist
% bzr add debian
% bzr commit -m'Debianize'

Note that "wikkid-0.1" will be replaced by the name of your package. In order to build the .deb package, you need an "orig.tar.gz" file. Packaging sort of assumes that you've got an original upstream tarball somewhere and you're just adding the necessary Debian goo to package the thing. In this case, we don't have an upstream tarball, although we could easily create one, and upload it to the Cheeseshop or Launchpad or wherever. However, that just slows us down so let's skip that for now! (Aside: if you do have an upstream tarball somewhere, you'll want to add a debian/watch which points to it; that'll eliminate the need to do the next step, by downloading the tarball instead).

Let's create the tarball right now and copy it to where the following step will expect it:

% python setup.py sdist
% mv dist/Wikkid-0.1.tar.gz ../wikkid_0.1.orig.tar.gz

Here's the second icky bit. Building a Debian source package imposes a very specific naming convention on the tarball. Wikkid's setup.py happens to build a tarball with an incompatible name, while the sdist command leaves it in a place where the next step can't find it. The rename just gets everything into the proper place. YMMV.

Now we can build the Debian source package. It's the source package that we'll upload to our Launchpad PPA. Launchpad will then automatically (if we've done everything right) build the binary package from the uploaded source package, from which Ubuntu and Debian users can easily install.

Oops! Before we do this, please edit your debian/changelog file and change unstable to lucid. You should also change the version number by adding a ~ppa1 to the end of it. Yeah, more ickiness.

Alright now we're ready to build our source package:

% bzr bd -S

Now let's upload it (assuming you've enabled a PPA):

% cd ..
% dput ppa:barry/python wikkid_0.1-1~ppa1_source.changes

That's it! If you've done everything successfully, you'll have the package in your PPA in 5 minutes or so. Then anybody who's added your PPA can just apt-get install wikkid (or whatever your package is called).

I do hope to work with the appropriate developers to make some of the ickiness go away. Please do contact me if you want to help!

Addendum (2010-06-10)

Let's say you publish your tarball on the Cheeseshop or Launchpad, and you don't want to have to build a different tarball locally in order to package it. Here's what I think works:

Create a debian/watch file that points to the download location you publish to. If your package is not yet available in Debian or Ubuntu, then use this command to build your source package:

bzr bd -S -- -sa

The bit at the end tells the Debian packaging primitives to include your tarball when your source package is uploaded. The debian/watch file is used to download your published tarball and automatically renamed to the required .orig.tar.gz name. When you dput your package, your tarball will be uploaded too, and everything should build properly.

Oh, and don't forget to look carefully at the lintian output. Try to make this as clean as possible. The Debian and Ubuntu packaging guides can help here.

Addendum 2 (2010-06-10)

Andrew Straw has added a debianize command to his stdeb package, which makes things much nicer. With this you can create the debian/ directory right next to your setup.py. AFAIK, this version of stdeb isn't released yet, so you need to install his git head in a virtualenv, and it has a few minor buglets, but it does seem like the best-of-breed solution. I'll post another article with a more detailed follow up later.

Read more
pitti

I just did the 1000th commit of postgresql-common, the Debian/Ubuntu PostgreSQL management utilities. Wow, what started as a small hack in December 2004 to be able to install several major PostgreSQL versions in parallel has turned out to be a > 600 kB project providing a comprehensive tool set for uniformly setting up, upgrading, and maintaining PostgreSQL database instances from version 7.4 up to the just announced 9.0 beta-1, with a comprehensive test suite that I’m really proud of (it tests just about every aspect, option, and corner case of the installation, integration, upgrade, locale support, and error handling, and takes about half an hour on my system).

The actual commit is rather dull though, it’s just the release/upload tag for version 107 which I just uploaded to Debian unstable (it will hit Ubuntu maverick and backports soon). 107 introduces support for PostgreSQL 9.0, and I fixed up the scripts and tests enough so that all the tests pass now, and thus it’s good for public release.

I also uploaded the 9.0 beta 1 server itself now. It’ll be in Debian’s NEW queue for a bit, and hit experimental in a few days (or hours; recently the ftpmasters have been awesome!) It has a few cool new features (see the announcement), and upstream really appreciates testing and feedback. So, bug reports appreciated!

In particular, if you have existing 8.4 clusters you can just try to pg_upgradecluster them to 9.0 beta 1. Remember, if anything goes wrong, the cluster of the previous version is still intact and untouched, so you can run upgrades as many times as you like and only pg_dropcluster the old one when you’re completely satisfied with the upgrade.

Read more
pitti

PostgreSQL did microrelease updates three weeks ago: 8.4.3, 8.3.10, and 8.1.20 are the ones relevant for Debian/Ubuntu. There haven’t been reports about regressions in Debian or the upstream lists so far, so it’s time to push these into stable releases.

The new releases are in Lucid Beta-2, and hardy/jaunty/karmic-proposed. If you are running PostgreSQL, please upgrade to the proposed versions and give feedback to LP #557408.

Updates for Debian Lenny are prepared as well, and await release team ack.

On a related note, I recently fixed quite a major problem in pg_upgradecluster in postgresql-common 106: It did not copy database-level ACLs and configuration settings (Debian #543506). Fixing this required some reenginering of the upgrade process. It’s all thoroughly test case’d, but practical feedback would be very welcome! Remember, if anything goes wrong, the cluster of the previous version is still intact and untouched, so you can run upgrades as many times as you like and only pg_dropcluster the old one when you’re completely satisfied with the upgrade.

Thanks,

Martin

Read more
Timo Jyrinki

Thanks to Dr. H. Nikolaus Schaller's efforts, a new "A7+" version of the world's only 100% free software (and even free hardware design, leading to further community development) phone, Neo FreeRunner, is available for sale at www.handheld-linux.com for 299€! New in this hardware version is prolonged battery life, due to a fix applied to the famous "#1024" bug. Now you should have theoretically about 5 days time suspended, but that's of course only if you don't actually do anything with this phone-computer.

In other news, despite the fact or because Openmoko Inc. has ceased its development efforts for now at least, concentrating on the WikiReader to recover from the economic problems, community finally questioned the reasoning behind some of the Linux kernel debug configuration in the official Openmoko kernel branch. Results? Speedup of certain kernel operations in the range of 2x to 5x! In practice that means Neo isn't actually anymore the sluggish device you used to get to know with. Of course it's not top of the line by any means, but being the only Free phone available on the market still, more free than most full-size computers in fact, it's a quite nice improvement to eg. boot time, application start up time et cetera. I merely was a messenger of these news from the kernel mailing list to the community, but I also provided a readily compiled kernel which I use in Debian and which seems to works for others as well (until their distributions package it up).

Over 1,5 years after launch of the FreeRunner, and even more since the original Neo 1973, the software is getting better all the time. The pace is slow, as is the case with any free/open project with limited community-only resources, but the best thing is that it never has to stop. A lot of the middleware, applications and so on will make it to future phones as well. Things like Intone music player, TangoGPS and literki keyboard might be nice little finger-usable applications in the future as well.

So, if you can manage without 3G and want to still have an unique mobile computer experience with basic phone functionality, running for example Debian for the "familiar experience" if you use Debian or Ubuntu on your other computers, it's still not too late to catch it. It seems we're still a couple of years away from any next effort of such level of freedom. I'm making through it by having bought a 59€ 3G modem for the more serious data needs. I'm still also thinking about a privoxy setup on my home server that would clean up and compress pages even via Neo's GPRS connection.

Read more
pitti

I finally listened to Sebastien Bacher and applied for GNOME commit rights yesterday, after hassling Seb once more about committing an approved patch for me. Surprisingly, it only took some 4 hours until my application was approved and my account created, wow! Apparently 71 patches are enough. :-)

With my new powers, I fixed a crash in gdm, and applied two stragglers into gvfs’ build system today.

More to come!

Read more
beuno

We’re trying to improve the icons we have in Launchpad so they’re more usable across different cultures and types of users, and our first step is to do some user testing on our current icons.

The Canonical User Experience team has set up a survey to gather information on how users see our icons, so if you have a few spare minutes (it’s very quick!), please take the survey and pass it on to other people, especially if they don’t use Launchpad, as they will be less biased.

Survey is available at: http://www.surveymonkey.com/s.aspx?sm=8hXmjrmFS7TmQCjh7jJB_2bQ_3d_3d

Read more