I got a beer bread kit from Mum for Christmas this year.

It seems pretty easy, so for a pre-new-year treat, I gave it a go.

Of course, for the beer I'm using one of my first batch of home brewed beer that I made just before the holidays.

Chuck it in…

Mix it for around 30 seconds.

Discover there is no bread tin here, so use cake tins instead.

Flatter than it should be, but otherwise YUM YUM YUM

After a tiring UDS in which I very nearly achieved my goal of mentioning Debian in every session and conversation, I ventured out to a nearby outlet mall.

Imagine my surprise when this little chap ended up in my bag!

and then I found out where the Angry Birds hang out when taking a break from destroying those evil pigs

and after this twin impact, I needed some retail therapy. This is probably the second pair of shoes I have ever purchased for myself.

Good week :-). And so to the delayed flight home…

Ello,

This is a quick public service announcement. Earlier today, ajmitch reminded me of a little gotcha that exists around Mono applications in Ubuntu 11.10. As a five second summary, in 11.10 the Debian Mono team switched the default runtime version from 2.0 to 4.0. This involved recompiling (and sometimes patching) all libraries and applications in the distribution with the new verison.

That's all well and good for programs you get from the repositories, but unfortunately that is not always the case. Sometimes you may receive an application precompiled or from a PPA that was originally compiled against the 2.0 profile. If you have an 11.10 system with its updated 4.0 libraries, that's not going to work. You'll get errors like

Missing method System.Reflection.PropertyInfo::op_Inequality(PropertyInfo,PropertyInfo) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/glib-sharp/2.12.0.0__35e10195dab3c99f/glib-sharp.dll

Unhandled Exception: System.MissingMethodException: Method not found: 'System.Reflection.PropertyInfo.op_Inequality'.
  at Gtk.ListStore..ctor (System.Type[] types) [0x00000] in <filename unknown>:0 
  at Sysinfo.Sysinfo..ctor (System.String[] args) [0x00000] in <filename unknown>:0 
  at Sysinfo.Sysinfo.Main (System.String[] args) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method not found: 'System.Reflection.PropertyInfo.op_Inequality'.
  at Gtk.ListStore..ctor (System.Type[] types) [0x00000] in <filename unknown>:0 
  at Sysinfo.Sysinfo..ctor (System.String[] args) [0x00000] in <filename unknown>:0 
  at Sysinfo.Sysinfo.Main (System.String[] args) [0x00000] in <filename unknown>:0 

which is a classic indicator that Mono tried to run an application using the 2.0 profile using libraries compiled for 4.0. A quick workaround is to force the application to run using 4.0, like so

mono --runtime=v4.0 /usr/lib/myapp/myapp.exe

which will get the program running and is useful if you don't have the facility or the inclination to rebuild it.

(You can skip the rest if you're not a developer)

If you are able to recompile the program then you can do the above, but you can also rebuild the program against the 4.0 profile to fix the error properly. The most important thing for package maintainers to know is that (for Debian and Ubuntu only), you ought to be using the distribution's default compiler to build your software. This means that you should tell your build system to use /usr/bin/mono-csc. If you don't then you'll get whatever the upstream maintainer has used, which is likely to be gmcs, the 2.0 compiler. When you use mono-csc, you get the distribution's default compiler and if the default runtime is changed in the future then compatibility will be a no-change rebuild away.

Greetings real ale fans,

This most exciting time of year is almost upon us again. Yes, it's the Nottingham Robin Hood Beer Festival!

This year I have followed in the footsteps of Alex and Karen and decided to trawl through the list of over 900 beers so that I can best sample the delights on offer. My selection is here. I'm attending on both the Thursday and Saturday, so there's plenty of time for me to sample a reasonable number of different ales.

Beer aficionados, I'd welcome suggestions for alternative beers to try, if you'd recommend any of them. I promise to update the list after. I might even be tempted by the ciders, perries and wines. Generally I tend to prefer paler ales, but I also quite like a mild given half the chance.

See you on the other side!

(Image by Ant & Carrie Coleman, cc-by-nd 2.0)

Dear lazyweb,

In a couple of weeks I'm likely to be going cycle touring around the North East of England. This will involve first taking a train from Nottingham. While looking at train options just now, I was reminded of a little survey that I wanted to conduct.

Taking bicycles on trains in the UK can be a hit-or-miss experience.

The UK's train routes are operated by a variety of train operating companies who each have different policies on taking bicycles on their trains. Some require a reservation, some do not. Some do not even allow reservations at all. There's no official database of these policies. It is up to you to check all of the companies' websites individually. As far as I can tell it is impossible to make a cycle reservation online. If you don't make a reservation, chances are that you'll be OK, but there are no guarantees you won't find yourself stranded in Bolton when none of your connections will take you.

The number of spaces reserved for cycles is extermely limited. Two seems to be the most common number that a train can officially carry (you may be able to stash it in the vestibule). Even given this, it is usual to find that the cycle spaces are taken up by prams, luggage and other crap when you actually board the train, so the effective number may actually be 0.

However, it is thankfully not uncommon to find staff and other passengers who are more than willing to go out of their way to help you if they see you are trying to take a bicycle onto a train.

Anyway, I'm interested in how this situation is in other non-UK countries. Better or worse? A lot of countries certainly have a more cycle-friendly culture — I'd like to know how this kind of thing works there so that I can write a Strongly Worded Letter about how we Should Be Doing Better.

(Image by onohiroki, CC-by-nd.)

Here's some information.

• The DMB grants both Ubuntu Membership and upload rights to (portions of) the Ubuntu archive. Both are assessed rather differently (one community and one somewhat more technical). Most of the current argument is about Membership (the only person the DMB deferred for upload rights was correctly so; it was a Per-Package Uploader application for packages which were not in the archive yet)
  • The rest of the current argument stems from the DMB failing to achieve quorum a few times.
    1. This is not a unique problem to the DMB. All boards (up to and including the Technical Board and Community Council, FWIW) experience this from time to time.
    2. We are conducting an internal poll to find a new meeting time which is more amenable to achieving quorum, and exploring alternatives such as using email voting a bit more. We are firm in wanting to retain the basic structure of our application process though.
• Sometimes people who encourage others to apply for membership have a different idea of what is required than those assessing the applications do. Sometimes these people doing the encouragement get annoyed when people they have pushed are deferred because of this. Membership boards expect to see a significant and sustained period of contribution, where sustained ordinarily means at least 6 months. Please bear this in mind.
• Members of most of these membership-granting boards are volunteers, and I imagine their motivation for wanting to participate on the boards is to recognise and reward contributors for doing excellent work. They are contributors themselves who have feelings and motivation, both of which can be taken away when others let their frustration have a target. Please let cool heads prevail, even when you are disappointed.
• As project leaders have repeatedly said, we elect governance bodies to take decisions, and we should trust them to make those decisions. If people are deferred, I expect everybody involved to deal with the situation with grace and sensitivity. If someone wishes to appeal, they should do this through the appropriate private communication channels first, only going public if this does not work.
• The Community Council is going to consider to what extent upstream contributions shall be able to form an individual's portfolio of contributions as part of their membership application.
• When you discuss someone's work, particularly if you are trying to change the way they go about it, it is polite to include them in the conversation. When this happens repeatedly in a short period of time, people may begin to suspect something strange is going on.

Is risking alienating people who have volunteered to serve as community leaders really worth this? Remember, we are only talking about a handful of deferrals here. Every one of those people is welcome to come back once they have addressed the issues at hand.

All of this could have been dealt with with some sensitive private communication.

I took my university hire bike out for a spin along Nottingham's big track at the weekend. It was great. If you're ever in the area with a bike I thoroughly recommend it.

I'll be getting my own trusty steed back after 11.5 months later this week. More on that saga later.

There are two different uses (within Debian/Ubuntu) of the initialism UDD: Ubuntu Distributed Development and the Ultimate Debian Database. This article talks about the latter.

At UDS-O in Budapest a few weeks ago we had a session (video) on DEX: an initiative to improve collaboration between Debian and its derivatives. There's an Ubuntu DEX subproject, and this is what the session was about, thinking up ideas.

I thought of something that could possibly yield some results --- my action from the session was:

[laney] measure relative uploads between ubuntu and debian and see if anything interesting pops up: TODO

It seems to me that if we could tell which packages were uploaded with the most frequency to Ubuntu with respect to Debian, then we may be able to figure out why this is and if there's any way we can do the work in Debian instead.

Clearly for this to happen we are going to need data! And where better to house a load of data than the Ultimate Debian Database itself?

So I wrote some scripts to download the Ubuntu changes, handily made available as mbox archives, chop them around a bit and eventually split them out in a format that UDD can understand. Lucas Nussbaum then kindly integrated the output into UDD itself, and the end result is that an as-near-as-possible complete history of Ubuntu uploads is now available for your creative querying. For example, Wednesday sees the most uploads and Sunday the fewest:

udd=> SELECT EXTRACT (DOW FROM date) AS dow, COUNT(EXTRACT (DOW
FROM date)) AS count FROM ubuntu_upload_history GROUP BY dow ORDER
BY count DESC;
 dow | count 
-----+-------
   3 | 26739
   2 | 26699
   1 | 25361
   5 | 23497
   4 | 22154
   6 |  9687
   0 |  8752
(7 rows)

I'll lovingly craft a script to generate the data we need for the DEX project in the next few days. But I hope that the data proves useful for other things too. The three tables you want to look at (with \d+ at a psql prompt) are ubuntu_upload_history, ubuntu_upload_history_launchpad_closes (LP bugs closed by uploads) and ubuntu_upload_history_closes (Debian bugs closed, probably not so interesting).

Information on how to use UDD yourself is on this wiki page.

I posted this a few weeks ago to the ubuntu-motu mailing list. Perhaps planet would like to see it too.

I'm writing this on the flight back from UDS1. Traditionally this week is when I contemplate my usefulness as a MOTU.

We had a couple of sessions this week about ways we can involve new developers (I'm using developer here to mean what you might incorrectly call a packager. Think ~ubuntu-dev) and find interesting things for them to do.

One idea I had is holding "projects". Say I'm running a Haskell transition which involves rebuilding a couple of hundred packages in the correct order, checking their dependencies are correct and then uploading to the archive. I could create a project out of this by describing what needs to be done and what level of experience someone will need to help me out. Others will do the same for their projects (whatever they may be), and contributors can then scan this list for something to work on in partnership with an existing developer. The developer gets some useful help and the contributor gets some useful experience. Get in contact with me when you next have a project (good candidates may be transitions or porting work) and we'll work out how to get it listed.

Mr. Motivator

Anyway, that wasn't the point of this post.

What I now realise that we completely missed is helping with the motivation of existing developers. Taking myself as an example, while my motivation in the specific areas I find interesting remains high, for the goals of MOTU more generally it is as low as ever. I'm a terrible sponsor. I almost never look at this or this or this. Do you?

Dear MOTU, how do you feel about your work on Universe and the team in general? How can we make continued contributions to Universe more rewarding? It is my impression that MOTU is often seen as a gateway to the more sexy work available in the main component. Is this accurate? If, as I suspect, it is then why is that?

I think a big part of the problem is that a lot of the work is difficult, repetitive and ultimately dull2. Who wants to grind through a huge list of failed upgrades and tease out what went wrong? Certainly not me.

The task is daunting, the team small and the rewards scant. When I first got involved I had little to no perception of the scale involved.

These are my feelings, but I'm really much more interested in hearing from my colleagues in MOTU. Please let's have a discussion about this. I care a lot for Universe and feel that it is often neglected in discussions around the distribution as a whole. We're here to take care of it, and I feel that, on the whole, we could be doing a better job.

I apologise for the negativity of this post. Actually I do feel that, despite constantly treading water, we do manage to deliver a decent Universe component every cycle. If only we could keep the old hands as enthusiastic as they were when they started. Yes, a big part of our job is to help new contributors be effective, but we should also be helping ourselves to lead by example.

Epilogue: Since I wrote this post, I've gotten involved with some aspects of release management, namely running the transition tracker and joining the release team. Having some kind of responsibility has helped motivation somewhat.

Well hello there.

A couple of days ago my debian.org account was created, meaning that I'm one1 of the crop of current new Debian Developers.

Actually the news was broken to me by Rhonda when I attached to irssi after arriving at work, a nice surprise

<Rhonda> All congratulate Laney on becoming a Debian Developer.  ;)
* Rhonda . o O ( http://db.debian.org/search.cgi?dosearch=1&uid=laney )
<Laney> Rhonda: I did?!?!?!

I'll quickly introduce myself by paraphrasing from the background section of the AM report before letting you go about your business.

I apparently submitted my first thrilling patch to the alsa-tools package in Ubuntu on February 2nd, 2008. This was sponsored into Hardy by Daniel Chen. Thereafter followed a myriad of exciting patches to various packages that somehow managed to convince a bunch of people that I had enough skill to become an Ubuntu developer.

Fast forward a while and I get sucked into the world of Debian packaging by the CLI/Mono strike force of Mirco Bauer and Jo Shields by way of the Mono 2.0 transition. This was where I got my first Debian upload, and it was in this team that I fully realised both the excellence and importance of Debian in the FOSS world2.

At some point the Debian Haskell Group formed and I've been involved to some extent there all along too.

What I've mainly learned from these two groups is that team maintenance is a really great way to look after a bunch of related packages. When I see people touting new packages about, I often recommend that they look at the list of teams to find a nice home. Perhaps one or two actually did.

Thanks to everyone who's supported me so far. I hope to be able to do the same for others in the future.