Yesterday, GUADEC hosted a PyGObject hackfest. I was really happy to see so many participants, and a lot of whom who are rather new to the project. I originally feared that it would just be the core crew of four people, as this is not exactly the shiniest part of GNOME development.

So I did not work on the stuff I was planning for, but instead walked around and provided mentoring, help, and patch review. Unfortunately I do not know all the results from the participants, hopefully they will blog some details themselves. But this is what I was involved in:

• Manuel Quiñones added an gtk_tree_view_column_set_attributes() override (the original C function uses varargs and thus is not introspectable). Most time was spent figuring out an appropriate test case.
• I showed Didier Roche some tricks about porting a pygtk application to PyGI/GTK3. He gave a shot to porting Meld, but unfortunately it uses a lot of pygtk hacks/tricks, most of which are obsolete now. So this proved too big a project for one day eventually
• Paolo and I guided Marta Maria Casetti, one of this year’s GNOME GSoC students, through her first pygobject patch. The test case still needs some love (again, nothing regarding GtkTreeView is easy), but the actual patch is good. Thanks Marta for participating, and not getting intimidated by all the new stuff!
• While working on above patch, Marta encountered a rather curious TypeError: Expected Gtk.TreeViewColumn, but got GObjectMeta when writing the override. What seemed to be a trivial problem at first quickly turned into an one-hour debugging session involving grandmaster John Palmieri and me, with others chipping in as well. In the end it (of course!) turned out to be a trivial four-character change in Marta’s patch, but it was fun to get to understand the problem (a loong-forgotten special case of overrides resolution in overrides code). Now pygobject gives a proper error message which is actually helpful, i. e. which argument causes the problem and which module/class/method is provided, which should prevent us from being misguided into the totally wrong direction the next time this happens.
• John Stowers got the Windows build working again, and showed off the gtk-demo under Windows. This is really amazing, I hope we can get that into trunk soon and not let it bitrot again for so long. Thanks!
• Simon and Manuel worked on porting some Sugar extensions. Together with Paolo we also discussed the GStreamer 1.0 API a bit, which parts can become API additions and which need to become overrides.
• Michal Hruby debugged a leak in the handling of GVariant arrays when using libdee.

Thanks everyone for participating! I hope everyone enjoyed it and got to learn a new thing or two. See you at the next one!

PyGObject hackfest at GUADEC 2012

I have had the pleasure of attending GUADEC in full this year. TL;DR: A lot of great presentations + lots of hall conversations about QA stuff + the obligatory be{er,ach} = ?.

Last year I just went to the hackfest, and I never made it to any previous one, so GUADEC 2012 was a kind of first-time experience for me. It was great to put some faces and personal impressions to a lot of the people I have worked with for many years, as well as catching up with others that I did meet before.

I discussed various hardware/software testing stuff with Colin Walters, Matthias Clasen, Lennart Poettering, Bertrand Lorentz, and others, so I have a better idea how to proceed with automated testing in plumbing and GNOME now. It was also really nice to meet my fellow PyGObject co-maintainer Paolo Borelli, as well as seeing Simon Schampier and Ignacio Casal Quinteiro again.

No need to replicate the whole schedule here (see for yourself on the interwebs), so I just want to point out some personal highlights in the presentations:

• Jacob Appelbaum’s keynote about Tor brought up some surprising facts about how the project has outgrown its past performance problems and how useful it was during e. g. the Arab revolution

.

• Philip Whitnall’s presented Bendy Bus, a tool to mock D-Bus services for both unit and fuzz testing. He successfully used it to find and replicate bugs in Evolution (by mocking evolution-data-server) as well as libfolks (by mocking the telepathy daemons). It should work just as well to mock system services like upower or NetworkManager to test the UI bits that use it. This is a topic which has been on my wishlist for a long time already, so I’m happy that there is already an existing solution out there. We might have to add some small features to it, but it’s by and large what I had in mind, and in the discussion afterwards Philip said he’d appreciate patches against it.
• Christophe Fergeau showed how to easily do Windows builds and installers from GNOME tarballs with MinGW-w64, without having to actually touch/use Windows (using cross-building and running tests etc. under wine). I found it surprising how easy that actually is, and it should not be hard to integrate that in a jhbuild-like setup, so that it does not keep breaking every time.
• Colin Walters gave an introduction to OSTree, a project to build bootable images from kernel/plumbing/desktop upstream git heads on a daily basis. This is mostly to avoid the long delays that we otherwise have with doing upstream releases, packaging them, and getting them into a form that can safely be tested by users. In an afterwards discussion we threw some ideas around how we can integrate existing and future tests into this (something in spirit like our autopkgtest). This will be the area where I’ll put most focus on in the next time.
• Adam Dingle of yorba fame shared his thoughts about how we can crowdfunding of Free Software Projects work in practice, comparing efforts like codefoundry and kickstarter. Of course he does not have a solution for this yet, but he raised some interesting concerns and it spun off lots of good discussions over lunchtime.
• Last but not least, the sport event on Saturday evening was awesome! In hindsight I was happy to not have signed up for soccer, as people like Bastian or Jordi played this really seriously. I participated in the Basketball competition instead, which was the right mix of fun and competition without seriously trying to hurt each other.

There were a lot of other good ones, some of them technical and some amusing and enlightening, such as Frederico’s review of the history of GNOME.

On Monday I prepared and participated in a PyGObject hackfest, but I’ll blog about this separately.

I want to thank all presenters for the excellent program, as well as the tireless GUADEC organizer team for making everything so smooth and working flawlessly! Great Job, and see you again in Strasbourg or Brno!

I just received confirmation that my request for a PyGObject hackfest has been approved by the GUADEC organizers.

If you are developing GObject-introspection based Python applications and have some problems with PyGObject, this is the time and place to get to know each other, getting bugs fixed, learn about pygobject’s innards, or update libraries to become introspectable. I will prepare a list of easy things to look into if you are interested in learning about and getting involved in PyGObject’s development.

See you on July 30th in A Coruña!

Phew, tiring trip to PyCon this year. This was my second year after hitting up my first last year. The conference definitely felt larger than last year as they crossed 2,200 attendees. It’s unbelievable to see how large the Python community has gotten. I can’t stress what great job the people that put this together.

Last year I hardly knew anyone. This year, however, I got to put faces to people I’ve interacted with over the last year, welcome back those I met last year, and get some face to face time with new co-workers from Canonical. The social aspect was a larger chunk of my time this year for sure.

Side note, I listen to The Changelog podcast from time to time, and I love their question on who you’d love to pair up/hack with as a programming hero type question. I got to meet and greet mine at this PyCon by meeting up with Mike Bayer. He’s behind some great tools like SqlAlchemy and Mako. What I love is that, not only does he rock the code part, but the community part as well. I’m always amazed to see the time he puts into his responses to questions and support avenues. Highlight of my PyCon for sure.

I’ll post a seperate blog post on my sprint notes. I feel that if you’re going to go, you might as well stay for sprints. I get as much out of that as the conference parts itself. I think I made some good progress on things for Bookie this year. The big thing is that an invite system is in place, so if you’d like an account on Bmark.us let me know and I’ll toss an invite your way.

Notes

• Introduction to Metaclasses
  • Basic but reminded me how the bits worked and had some good examples. I like this because I often write ‘the code I want to be writing’ and then write my modules/etc to fit and metaclasses help with this sometimes.
• Fast Test, Slow Test
  • Just a reminder that fast tests are true unit tests and run during dev which helps make things easier/faster as you go vs the whole ‘mad code’ then wait for feedback on how wrong you are.
• Practical Machine Learning in Python
  • mloss.org – check out for lots of notes/etc on ML in OSS
  • ml-class.org – teach me some ML please
  • sluggerml – app he built as a ML demo
  • scikit-learn : lots of potential, very active right now
• Introduction to PDB
  • whoa…where have you been all my life ‘until’ command?
  • use ‘where’ more to move up stack vs adding more debug lines
• Flexing SQLAlchemy’s Relational Power
• Hand Coded Applications with SQLAlchemy
  • <3 SqlAchemy. Some really good examples of writing less code by automating the biolerplate with conventions.
• Web Server Bottlenecks And Performance Tuning
  • lesson: if you think it’s apache’s fault think again. You’re probably doing it wrong.
• Advanced Celery
  • check out cyme https://github.com/celery/cyme, possible way to more easily run/distribute celery work?
  • cool to see implementations of map/reduce using celery
  • chords and groups are good, check them out more
• Building A Python-Based Search Engine
  • Good talk for into into terms and such for fulltext search
• Lighting talks of note
  • py3 porting docs: http://docs.python.org/howto/pyporting
  • bpython rewind feature is full of win over ipython
  • ‘new virtualenv’ trying to get into stdlib for py3.3, cool!
  • asyncdynamo cool example of async boto requests for high performance working with AWS api (uses tornado)
  • I WANT the concurrent.features library…but it’s Python 3

Back at the Ubuntu Platform Rally last week, I’ve pestered some of the Bazaar team with questions about co-location of branches in the same directory with Bazaar. The great news is that this seems to be really coming for the next release, with first-class integration of the feature in the command set. Unfortunately, though, it’s not quite yet ready for prime time, or even for I’m-crazy-and-want-this-feature time.

Some background on why this feature turns out to be quite important right now may be interesting, since life with Bazaar in the past years hasn’t really brought that up as a blocker. The cause for the new interest lies in some recent changes in the toolset of the Go language. The new go tool not only makes building and interacting with Go packages a breeze, but it also solves a class of problems previously existent. For the go tool to work, though, it requires the use of $GOPATH consistently, and this means that the package has to live in a well defined directory. The traditional way that Bazaar manages branches into their own directories becomes a deal breaker then.

So, last week I had the chance to exchange some ideas with Jelmer Vernooij and Vincent Ladeuil (both Bazaar hackers) on these problems, and they introduced me to the approach of using lightweight checkouts to workaround some of the limitations. Lightweight checkouts in Bazaar makes the working tree resemble a little bit the old-style VCS tools, with the working tree being bound to another location that actually has the core content. The idea is great, and given how well lightweight checkouts work with Bazaar, building a full fledged solution shouldn’t be a lot of work really.

After that conversation, I’ve put a trivial hack together that would make bzr look like git from the outside, by wrapping the command line, and did a lightning talk demo. This got a few more people interested on the concept, which was enough motivation for me to move the idea forward onto a working implementation. Now I just needed the time to do it, but it wasn’t too hard to find it either.

I happen to be part of the unlucky group that too often takes more than 24 hours to get back home from these events. This is not entirely bad, though.. I also happen to be part of the lucky group that can code while flying and riding buses as means to relieve the boredom (reading helps too). This time around, cobzr became the implementation of choice, and given ~10 hours of coding, we have a very neat and over-engineered wrapper for the bzr command.

The core of the implementation is the same as the original hack: wrap bzr and call it from outside to restructure the tree. That said, rather than being entirely lazy and hackish line parsing, it actually parses bzr’s –help output for commands to build a base of supported options, and parses the command line exactly like Bazaar itself would, validating options as it goes and distinguishing between flags with arguments from positional parameters. That enables the proxying to do much more interesting work on the intercepted arguments.

Here is a quick session that shows a branch being created with the tool. It should look fairly familiar for someone used to git:


[~]% bzr branch lp:juju
Branched 443 revisions.

[~/juju]% bzr branch
  master
* new-feature
  other-feature


Note that cobzr will not reorganize the tree layout before the multiple branch support is required.

Even though the wrapping is taking place and bzr’s –help output is parsed, there’s pretty much no noticeable overhead given the use of Go for the implementation and also that the processed output of –help is cached (I said it was overengineered).

As an example, the first is the real bzr, while the second is a link to cobzr:


[~/juju]% time /usr/bin/bzr status
/usr/bin/bzr status 0.24s user 0.03s system 88% cpu 0.304 total

[~/juju]% time bzr status
bzr status 0.19s user 0.08s system 88% cpu 0.307 total


This should be more than enough for surviving comfortably until bzr itself comes along with first class support for co-located branches in the next release.

In case you’re interested in using it or are just curious about the command set or other details, please check out the web page for the project:

• http://labix.org/cobzr

7 years ago, The Ubuntu 4.10 “The Warty Warthog” was announced. A huge congrats to the community, Canonical, and especially Mark for getting so far from “there” to “here”.

This brings back old memories of my first conference in Oxford in August, the great-great-grandfather to what is UDS these days. Back then, there was no company, no Launchpad, no Blueprints, no work items, no detailled plans, just a bunch of ideas, BoFs, and this was a third of the entire crowd:

Back then we worked on the famous TRLS technology (“Totally Rad Laptop Support”) and were proud when we got the ThinkPads to suspend once. During that conference I wrote pmount to provide automatic mounting of USB sticks in a safe manner. Those were the days…

But I can also safely say that there are some things that haven’t changed. Even though both the community and the company (which changed away from www.no-name-yet.com recently) grew by two magnitudes since then, we still have the same serious attitude, stern look, and formal attire as we had back then:

We are professionals, really!

(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!

Again early wake up… This time 4:44 but I think that today will be better then yesterday because 6h of sleep is often my default amount. Few minutes ago room mate woke up and said: you will never convert to this timezone if you will not sleep longer. But why do I have to? In few days I will be back home.

After “let’s do nothing” Sunday it is time to start doing UDS things. I have quite long list of sessions to attend and for few I will need to select which one to go:

Monday:

• 11:00 Linaro@UDS roundtable
• 12:00 Xdeb cross-compilation environment
• 15:00 Current state of Linaro toolchain
• 16:15 Package development tools
• 17:10 Future Linaro toolchain areas

Tuesday:

• 09:00 Toolchain consumption models
• 11:00 Design a safe and stable build cluster for public ARM PPAs based on the OMAP4 Pandaboard
• 11:00 Using QEMU for demonstrations
• 12:00 Integrate gdbserver support in Linaro
• 15:00 Kexec
• 16:15 Improve detection of device class at install time
• 16:15 Current and future GDB for ARM plans

Wednesday:

• 09:00 Create minimal preinstalled developer images
• 11:00 The Multi-Monitor User Experience multimedia
• 12:00 State of ARM developer tools
• 12:00 Kubuntu Natty and X.org
• 15:00 Provide ARM cross-compiler packages for Ubuntu Natty
• 16:15 Linaro toolchain integration in Ubuntu Natty
• 17:00 Cross-Compilation Environment

Thursday:

• 10:00 Git for Bzr users
• 11:00 Kernel version and flavours
• 11:00 Performance inside of GCC
• 12:00 ARM specific library tuning
• 15:00 Produce an image suitable for set-top boxes for armel

Friday:

• 09:00 Provide a Linaro image with a set of developer-oriented tools installed by default
• 10:00 More stable VM solution for running armel VMs
• 11:00 Multiarch Support for gcc, binutils, dpkg, and apt
• 12:00 Discuss the way forward with the 2D ARM netbook UI
• 15:00 Provide solutions for netbooting and minimally installed Thin Clients on ARM boards

For now this is a list of sessions which I will attend or consider to. Some of them are required for me, some I will lead, some are for curiosity and few I will attend to check what is going on and maybe provide some hints. Compared to UDS-M this one will be rather busy for me. And I have to catch Jamie to grab my PandaBoard from him :)

BTW — if you are interested in checking something on PandaBoard then catch me. Maybe it will be possible to organize some kind of hacking session (but note that I do not have any of required things for board — no psu, no cables/keyboard/mouse/etc).

All rights reserved © Marcin Juszkiewicz
UDS-N: Monday was originally posted on Marcin Juszkiewicz website

Share/Bookmark

Related posts:

1. UDS continues
2. Ubuntu cross compilers
3. PandaBoard: Beagleboard XM killer?

At 4:30 had to get up and ~hour later I was in a bus to Berlin Tegel (TXL) airport. Arrived, met few people from Canonical, got first coffee. Lufthansa did not has so much luck with 10s as Ubuntu did so our flight moved from 10:10 by about hour. Reason was bad weather and traffic jam over Frankfurt airport.

But finally plane landed there and trip though terminal began. After few minutes I heard that passengers to Orlando should hurry so I did. Just to wait insane amount of time in shuttle bus and then in a plane… Good part of flight was that there were many free seats so we (zyga and me) were able to seat next to each other.

But long flights are boring… Lufthansa on board entertainment system uses wrong calibrated touch screens with very long reaction time. There were few good movies to choose but seating after the jet engine does not make it comfortable due to amount of background noise. On return trip I will test headphones from Nokia N900 as they should isolate more then Lufthansa ones (or ones which I use with laptop).

Arrived in Orlando with about 40 minutes delay. Acceptable I think. Customs queue was huge and I did not track how much time we wasted there but everything went fine. We met few other people and took a taxi to hotel. American seat belts are strange – I prefer European way of mounting them instead of “let it hang from ceiling” which is used here.

Met more people in hotel, got “all american burger” for dinner (was quite good) and went to sleep. Timezones difference kills — I woke up at 3:30 and could not get to sleep again ;(

All rights reserved © Marcin Juszkiewicz
UDS-N day one was originally posted on Marcin Juszkiewicz website

Share/Bookmark

Related posts:

1. UDS day 0
2. I am living in a village
3. OpenedHand X-mas

Greetings! If you’re going to be at Velocity 2010 next week, we hope you’ll join us at the Ubuntu Server Users and Developers BoF, Tuesday June 22 @ 8:30pm.

We’re going to cover a number of topics:

• UEC – We’ll do our best to build a fully functioning “private cloud” with just a couple of USB keys.
• Ubuntu Server 10.10 – The release is just around the corner in October, we’ll talk about some of the things planned.
• Feedback – The BoF will be attended by members of the Ubuntu Server development team, so bring your questions and feedback!

This year I attended only one day of LinuxTag: Friday. There were many reasons for that but I am glad that I made at least that.

Wake up at 05:00 is hard… But I had a train to Berlin to catch. It was IC so power sockets were available and I watch some film and checked once again program for a day.

First attended talk was “Truths and Lies: Where’s the Open Source Modern Mobile Phone?” by Mickey Lauer. I like his presentations – they are always interesting and professional. His expertise in mobile phones running open systems warrant good talk. This time he did not mentioned FSO or oFono but told why Android (HTC Dream), WebOS (Palm Pre), Maemo (Nokia N900) are not open source systems. Why does it matter? Open system allows you do anything with device — you can even send it to space (like it was done with Openmoko GTA02).

I missed “Mobile Development with Qt and Qt Creator” presentation but Nokia guy at their stand explained later how does it work and why it is worth checking. In short: usable IDE with simulation of target device screen (from 1:1 display size to 1:1 resolution size).

Dirk Hohndel from Intel had a talk about “MeeGo – Linux for Mobile Devices”. Nice talk with presentation of current release on older laptop. Some background informations how it started from meeting of Intel and Nokia guys. And then someone asked will all existing applications will be rewritten to Qt (which is primary toolkit in MeeGo). Dirk tried to not answer it directly but finally said that no, current apps will stay with GTK+ (Clutter, MX) and only new ones will use Qt. I was not surprised — I know Moblin guys and their preferences when it comes to UI toolkit.

Next talk was about writing native code for Android and about how much can be done without going to Java world. As I am considering Android as a system for my next cell phone I was interested. But native does not free developer from Java. The idea is that you write C code, build it into library and then you need to write JNI which will be used from Java application to calls functions from native library. So ok, it gives speed but you still need to know Java ;(

“Debian Pure Blends” talk did not attracted many people. Andreas Tille told that many derivatives exists and some of them got merged back into Debian (like Skolelinux) while some does not even look like having sense in them.

“Debian GNU/kFreeBSD” summarised why Debian with FreeBSD kernel was made, what it gives and what is missing. Also note that NetBSD and OpenBSD based attempts were done but died few years ago. Is it worth using? I can not answer to that question. But if you need ZFS…

And at the end of a day Amit gave a talk about Linaro. There were about few people and most of them from Canonical.

But LinuxTag is not only talks. There are booths to visit, friends, coworkers and other people to meet etc.

Texas Instruments presented their low cost boards: HawkBoard, LeopardBoard and BeagleBoard XM. Each has own uses as they are using different processors and have other features. I hope that one day BB XM will replace my normal one but first they need to be available to buy (Digikey information is “6 weeks”).

Nokia had big stand where they presented Qt Creator software and Qt demos on N900 connected to flat TV. I asked some questions, got answers and now need to find some time to check their software and move my Protracker module player ahead.

OpenEmbedded had stand as well — this year not as a part of Tarent embedded area but small one in next hall. Florian Boor spent whole day manning it and presented few interesting boards. KaRo one (based on Sheeva cpu) was interesting — too bad that this is only armv5te ;(

Speaking of Tarent… Was nice to meet them, but did not had a time to talk much.

Met Matthias Klose (widely known as ‘doko’) who is Debian/Ubuntu toolchain maintainer. We had a short talk about our cooperation.

Conference ended, we went to centre for some food and then I had a train to catch to go back home.

Overall it was good to be there. But it was last time when I go for one day — it is simply too short to be able to meet everyone and talk longer then few minutes.

Related posts:

1. I am on the LinuxTag
2. FOSDEM X
3. ST-Ericsson Community Workshop 2009

Over the past few months, friends and family have been very curious about how my new job is going, and it’s been hard to stop for a moment and go into detail about it. I’ve been simply nodding and saying “It’s fine”.

This is an attempt at summarizing all the activity that happened in the last five months, though it’s far from being a short summary. If I had to pick a two words to describe my first five months at Canonical, it would be “Pure Awesomeness“. For a more detailed view, grab a cup of joe or your favorite other beverage and keep on reading.

Today is a special day. Exactly five months ago, on January 5th, I joined Canonical to work on the Landscape project.

It has been quite a ride so far, with two sprints with the Landscape team, AllHands and UDS in Barcelona just a week ago, and lots of excitement about the future. Saying that I’m completely stunned by the work everyone at Canonical has been putting together and how much the teams have grown in the last few months doesn’t do enough justice to it.

At AllHands and UDS we got a short preview of the things that are coming out in the next cycle and beyond. An example of that is the newly formed Design and User Experience (DUX) team which will not only be focusing on Ubuntu itself, but on many other areas across Canonical and the whole Open Source community in general.

At UDS, the DUX team had a special ‘booth’ where any person from any project could walk to them and get advice about their personal or favorite application. One person which has favorably used such advice already was Seif Lofty, from Gnome Zeitgeist. I met Seif during breakfast at the first day of UDS and I cannot describe how excited he was about simply *being* at UDS. And he was certainly twice as happy when he left.

Another person I had the joy to meet was David Siegel, of Gnome Do fame. We teamed during AllHands on the infamous “Fun In The Woods” activity, which had some people walking like zombies on the day after.

Even more importantly, I was able to meet many many more other colleagues from different teams and wrap up some loose ends from tasks that I got started during the first couple months. I’m definitely impressed by the amount of plain brilliant people that are part of Canonical as of today.

In a sense, being at a Canonical event is very much like being at a Plone conference. Everyone seems to be very receptive about new ideas and very friendly and laid back. And as a bonus, I was able to exercise my (not so secret now) power of throwing some crazy ideas around and see how they influence people. And man, I’m already impressed by the outcomes, just a week after the fact.

To me, this has been the most rewarding thing so far, to be able make big contributions not in lines of code, but in ideas that can make a concrete difference in the hands of the right people. This is something that can only be possible at a company the size Canonical is at the moment, where it’s just big enough that you can grab a mind or two to push an agenda without affecting the rest of the team and still small enough that you can influence decisions.

As my colleague Jamu would best describe, “I’m PUMPED!”. :)

But that’s not all. Software-wise, I was able to make some big contributions too. The Landscape team just finished a 6 month development cycle that brought many cool features to life. I’m really happy with that, and specially with the speed that this team can get features from the black board into reality. It’s also a much different environment than what I was used to, with very well-defined and refined processes for ensuring the overall quality of anything that is produced. One process that I’m specially enjoying is the requirement for two positive reviews before landing a branch. I hope to talk more about that soon (that is, sooner than 5 months from now *wink*).

As for my role in the team, it is quite different than what I’m used to. I’ve been focusing a lot on the UI aspects of Landscape, on ways to make things more obvious and more streamlined. I’ve been also writing a ton of Javascript, and collaborating with other teams to define better policies for Javascript testing in general. And finally, we will now have a person from the DUX team dedicated to working with us, which will push work on the Landscape UI even further.

I also had the chance of interacting with the Launchpad team, which has a much more refined process due to the size of their team. Over at Launchpad, I started a branch back in mid-December, even before starting at Canonical, to allow Launchpad to use the Chameleon Template Engine.

That was another wild ride, and during the course of this project I was able to contribute tons of fixes upstream to Malthe Borch to make Chameleon even more compatible with plain old ZPT. In fact, it is so compatible at the moment that due to the magic of z3c.ptcompat Launchpad will be able to run *both* Chameleon and ZPT with the flip of an environment variable. Even more stunning, the changes required to code were minimal, basically changing imports to use z3c.ptcompat, and in templates we’ve had to fix some non-XHTML compliant ones and remove unused i18n tags. I am happy to announce that this branch will soon be merged (it was submitted to PQM, successfully accepted and is waiting to land the buildbot queue). The bad news is that not all tests pass at the moment with Chameleon enabled, but we will be dogfooding and fixing those tests as we go. It was too much pain already to maintain a nearly 6 month old branch outside the main tree. ;)

I am really interested in many of the things that the Launchpad team is doing, process-wise. The PQM seems like a very nice idea for a bigger team like theirs, though it would probably be useful to our smaller team in Landscape too, and to others in general. Hopefully I will get a chance to explore it more and talk about it during the upcoming FISL 10, in Porto Alegre.

Lastly, but not least important, I’m also working on getting nightly builds of the Bzr Installer for Windows rolling, and a more streamlined process for the official builds. Karl Fogel, of Producing OSS fame, and our Launchpad Ombudsman is making sure I keep my promises about that, which is yet another great incentive.

All in all, there’s of course a ton of things I forgot to talk about and which happened in the last 5 months, but this post is already getting too long so I will stop right here and save some of the meat for a future one. Stay tuned!