Older blog entries for ctrlsoft (starting at number 94)

Back to blogging

Hello Internet. After a long silence and several fights with Serendipity I am back.

The contents from my old Serendipity install have been migrated to restructuredText in pelican. Among other things, this means I can now get rid of the last PHP install I had left on my server.

Syndicated 2012-11-26 02:17:00 from Stationary Traveller

Last day at Canonical

This Friday will be my last day at Canonical.

It has been a lot of fun working here. There is so much I have learned in the last three years. I'm going to miss my colleagues.

Over the last couple of months I have slowly stepped down from my involvement in Bazaar and the Bazaar packaging in Debian and Ubuntu. I would like to stay involved in Ubuntu, but we will see how that goes.

I'm taking some time off until the end of the year to see the world and hack, before starting something new in February.

Syndicated 2012-10-16 22:00:00 from Stationary Traveller

Summer of Code 2011

The Samba team is once again participating in the Summer of Code this year. This year we have 4 students working on various projects related to Samba.

This year I am mentoring Dhananjay Sathe, who is improving the GTK+ frontends for Samba. In particular, he is making it possible to manage shares and users of a remote Samba or Windows machine.

Dhananjay is also blogging about his progress.

Syndicated 2011-07-18 08:53:05 from Stationary Traveller

libapache2-mod-bzr

During the last two days I hacked together a Bazaar module for Apache. This module makes it possible to easily enable the Bazaar smart server for Bazaar branches. It also can display a simple placeholder page for Bazaar branches without working tree. It's surprisingly easy to write Apache modules.

The main advantage this has over a mod_wsgi / mod_python / mod_fcgi setup is that it doesn't require any additional Python hacking on the users side or other configuration outside of Apache, and it doesn't require configuration for each single branch in the Apache configuration. In the future I'd also like to support the settings "BazaarFrontend Wikkid" and "BazaarFrontend Loggerhead".

The configuration is currently as simple as:


LoadModule bzr_module /usr/lib/apache2/modules/mod_bzr.so
BazaarSmart on
BazaarFrontend Basic

in your apache2.conf. The BazaarSmart and BazaarFrontend directives can appear in or clauses as well, if you'd like to have different behaviour for different directories.

At the moment this project is a proof of concept, and probably not something you would want to run in production. For example, there is no way to limit the access to a branch to read only. I need to double-check there are no threading issues.

Testing and patches are welcome. The project is hosted here:

Syndicated 2011-01-02 19:07:53 from Stationary Traveller

On the way to Samba 4

After Samba XP 2008 Andrew and I started keeping a wiki page with our bi-weekly goals and achievements for Samba 4. Because planning in a Free Software project is hard (time availability and priorities change over time, and other volunteers are equally unpredictable) we called this our "Fantasy page"; it listed things we wanted to work on next ("fantasies"), but reality being what it is we would usually actually end up working on something entirely different. We discussed our progress and new plans in - what I would now call - a bi-weekly standup call.

There were several reasons for doing this. It gave us some sense of direction as well as a sense of accomplishment; a way to look back at the end of the year and realize how much we had actually achieved. Because Samba 4 is such a long term project (it is 7 years old at this point) it is easy to become disillusioned, to look back at a year of commits and to not see the gradual improvement, just the fact that there is no release yet.

We managed to keep this up for two years, much longer than I had anticipated, and eventually started to slip last year.

More recently Kai and Tridge have started to blog weekly about their efforts to make Samba 4.0 a reality and I'm going to join them by trying to blog regularly - every two weeks - about my contributions, even if there were none.

In the next two weeks I plan to work on finally getting alpha 14 of Samba 4 out and on fixing the daily builds of Samba 4 and OpenChange for Ubuntu on Launchpad after we did a massive reorganization of the private libraries in Samba 4.

cp: Zero 7 - Somersault

Syndicated 2010-11-24 20:44:00 from Stationary Traveller

Mumble and bluetooth

Mumble is an open source, low-latency, high quality voice chat application that we're using at Canonical, and which Samba has recently also adopted.

After I busted the cable of my cabled headset and inspired by Matt's post about Mumble and Bluetooth I bought a cheap Nokia Bluetooth headset that works with my laptop as well as my phone. By using BlueMan I even found that the headset worked out of the box on Maverick.

A nice feature in Mumble is that it is controllable using D-Bus. Blueman supports running an arbitrary command when the answer button is pressed. Combining these two features, it is possible to automatically toggle mute when the answer button is pressed:


#!/usr/bin/python
import dbus
bus = dbus.SessionBus()
mumble = bus.get_object("net.sourceforge.mumble.mumble", "/")
is_muted = mumble.isSelfMuted()
mumble.setSelfMuted(not is_muted)

To use this script, set its path in the configuration tab for the "Headset" plugin in blueman.

The only remaining problem with this setup is that I can't keep the headset on during my work day, as I don't have a way to put it in standby mode automatically. This means that my battery runs out pretty quickly, even when nothing is happening on Mumble.

cp: Red Sparowes - Finally As That Blazing Sun Shone

Syndicated 2010-11-07 21:38:35 from Stationary Traveller

OpenChange server and SOGo

There's more good news on the OpenChange front. Julien has been working together with Wolfgang and Ludovic from Inverse recently to leverage the server-side support in OpenChange to provide native Exchange server support in SOGo.

A couple of days ago we announced that there now is an initial version that allows the use of Outlook against a SOGo server through OpenChange.

As far as I know, this is the first time it's possible to actually use Outlook clients with a non-Microsoft Exchange-compatible server without the need for plugins on the Outlook side. And it's all Free Software. Of course, this is just a preview, and not something we'd recommend everybody to run in production yet. But it's exciting to finally see this come together.

We already have OpenChange packages in Debian and Ubuntu but I hope I can help get SOGo packaged for both distributions as well.

Syndicated 2010-10-26 17:47:16 from Stationary Traveller

Samba 4 and OpenChange daily Ubuntu packages

Daily builds

As of a month ago there are Ubuntu archives with fresh packages of Samba 4 and Openchange, built on a daily basis day from the latest upstream revision.

This means that it is now possible to run a version of Samba 4 that is less than 24 hours old, without having to know how to extract source code from the version control system that upstream is using, without having to know how to build and install an application from source, but perhaps most importantly: without having to go through the tedious process of manually updating the source code and rebuilding.

OpenChange is tightly coupled to Samba 4, so installing a new version of OpenChange usually involves installing a new version of Samba 4 as well. To make matters more confusing, the two projects use different version control systems (Samba 4 is in Git, while OpenChange is in Subversion) and different build systems (Samba 4 uses waf, OpenChange uses autoconf and make).

I have been involved in Samba 4 and OpenChange as an upstream developer and more recently also as a packager for both Debian and Ubuntu.

As an upstream developer for both these projects it is important for me that users can easily run the development versions. It makes it possible for interested users to confirm the fixes for issues they have reported and to test new features. The more users run the development version, the more confident I can be as a developer that doing a release will not cause any unexpected surprises.

As a packager it is useful to know when there are upstream changes that are going to break my package with the next release.

Recipes

The daily builds work using so-called recipes which describe how to build a Debian source package from a set of Bazaar branches. For example, the Samba 4 recipe looks like this:

  # bzr-builder format 0.2 deb-version 4.0.0~alpha14~bzr{revno}~ppa{revno:packaging}+{revno:debian}
lp:samba
merge debian lp:~samba-team/samba/unstable
merge packaging lp:~samba-team/samba/4.0-ppa-maverick

This dictates that a source package should be built by taking the upstream Samba branch and merging the Debian packaging and some recipe-specific tweaking. The last bit on the first line indicates the version string to be used when generating a changelog entry for the daily build.

Every night Launchpad (through bzr-builder) merges these branches and attempts to build the resulting source package, e-mailing me in case of build problems. Generally I fix issues that come up by committing directly to upstream VCS or to the Debian packaging branch. There is no overhead in maintaining the daily build after I've set it up.

For more information on creating source package recipes, see getting started.

Toolchain

The entire toolchain that does the daily package builds for Ubuntu is Free Software, and I have contributed to various bits of that toolchain over the years. It's exciting to see everything come together.

Soyuz

Launchpad consists of multiple pillars - one of those pillars is Soyuz, which I hack on as part of my day job at Canonical. Soyuz is responsible for the archive management and package building. Debian source packages (a combination of upstream source code and packaging metadata) get uploaded by users and then built for various architectures on our buildfarm and published to the Ubuntu archive or to users personal package archives.

Launchpad-code

Another pillar of Launchpad is Launchpad-code, which is responsible for the hosting and management of version control branches. Launchpad users can either host their branches on Launchpad directly or mirror branches (either native Bazaar branches or branches in a foreign format such as Subversion, Git or Mercurial). The mirrorring of native and foreign branches happens using standard Bazaar API's. In the case of Samba and OpenChange we import the branches of the upstream projects (Samba is in Git, OpenChange is in Subversion) and the packaging for both projects is in Bazaar.

Launchad-code calls out to Bazaar to do the actual mirrorring. Over the last few years I have done a lot of work to improve Bazaars support for foreign branches, in particular on supporting Subversion, Git and Mercurial. As the code mirrorring in Launchpad is one of the biggest users of bzr-svn and bzr-git it has helped find some of the more obscure bugs in those plugins over the last few years, to the point where there are only a handful of issues with Git and Subversion imports left.

bzr-git and dulwich

bzr-git provides transparent access to Git repositories from within Bazaar and is built on top of Dulwich. Dulwich is a Python library that provides access to the Git file formats and protocols that is completely independent of Bazaar. James Westby originally started it and I adopted it for bzr-git and further extended it. There are now several other projects that use it as well, including hg-git, and rabbitvcs. Apart from James and me almost two dozen other people have contributed it so far.

bzr-svn and subvertpy

bzr-svn provides transparant access to Subversion repositories in Bazaar. When I grew frustrated with the existing Subversion Python bindings for various reasons, I decided to create independent Python bindings for Subversion from scratch. These bindings have since been split out into a separate project - subvertpy - and other projects have since also started using them, e.g. hgsubversion and basie.

Using the daily builds

To use the Samba 4 and OpenChange daily builds (Ubuntu Maverick only for now), run:

  $ apt-add-repository ppa:samba-team/ppa
$ apt-add-repository ppa:openchange/daily-builds

cp: Karnivool - Themata

Syndicated 2010-09-28 10:39:50 from Stationary Traveller

subunit usage in Samba

Both Samba 3 and Samba 4 are now using the "subunit" protocol inside their testsuite (aka "make test"). subunit is a streaming protocol used to report test results that is aimed at being simple to generate and parse as well as being human readable.

A very simple subunit stream might look like this:

  test: samba4.tests.util.strlist.check_list_make
creating list...
list created!
success: samba4.tests.util.strlist.check_list_make
test: samba4.tests.util.strlist.check_list_make_shell
creating list...
xfail: samba4.tests.util.strlist.check_list_make_shell [
returned NT_STATUS_NOT_IMPLEMENTED
]

For those that are familiar with the TAP protocol used by Perl, it is similar to that, although it has a couple of features that TAP does not have. For example, it can report timestamps (useful for determining test duration) and has more flexible progress reporting.

Subunit is particularly useful for projects that use multiple programming languages as it allows a single tool to be used for test visualization or analysis rather than one per language. All that's required per-language is a test runner that can spit out subunit streams.

selftest.pl, the main engine behind Samba's test suite, has been using subunit internally since its creation couple of years ago. Most other test tools we use can also report subunit, in particular our Python tests, blackbox tests, Perl tests (using tap2subunit) and smbtorture.

"make test" never displays raw subunit results, it always formats them using our format-subunit script. Samba 4's "make test" stores the raw subunit output in st/subunit.

I'm attending SNIA SDC at the moment and a couple of people here have asked me about the tools I use to display and analyse test results. They are:

The subunit project contains a bunch of convenience tools for working with subunit. Other than libraries for parsing/generating subunit for several languages it contains tools for manipulating and analysing subunit streams, including:

  • subunit-ls: List all tests in a subunit stream, optionally including their run times (I used this for the test duration summary I sent to the Samba mailing list earlier)
  • tap2subunit: convert a TAP stream to a Subunit stream
  • subunit-stats: Print statistics for a subunit stream (how many successful tests, failed tests, skipped tests, etc)
  • subunit-filter: E.g. remove test result or output from a stream
  • subunit-diff: Compare two subunit streams and see what tests have started failing or are no longer failing
  • subunit2pyunit: Format a subunit stream using Python's standard unit test test result formatter

We're including the subunit tree in the Samba git tree at lib/subunit.

Tribunal is a GTK+ viewer for subunit streams. It allows for easy browsing of test results. Tribunal is still a bit rough around the edges, although it should already be useful.

Example usage:

  $ make test
$ tribunal-subunit st/subunit

Test Repository provides a database of test results which fits into developers work flow and keeps track of useful information like what tests are failing, or which failures have the same backtrace.

In particular Test Repository can re-run only the tests that failed in the previous test run:

  $ testr init
# Run the full testsuite (1 hour goes by)
$ testr run
# Run those tests from the testsuite that failed in the previous run 
# (this would be a lot shorter usually, depending on how many tests were
# failing)
$ testr run --failing

testrepository is also still in its early days, but can potentially be very useful, e.g. when comparing old test runs on the buildfarm.

Syndicated 2010-09-24 00:46:11 from Stationary Traveller

It's that time of year again

Ik ga op vakantie en neem mee:

  • Agalloch - Ashes Against the Grain
  • Aimee Mann - Lost In Space
  • Anathema - Alternative 4
  • Arch Enemy - Burning Japan
  • Blackfield_-_Blackfield
  • Camel - Coming of Age
  • Dream Theater - Black Clouds And Silver Linings
  • Evanescence - Fallen
  • Gazpacho - Tick Tock
  • Green Day - American Idiot
  • Heather Nova - Redbird
  • Isis - Wavering Radiant
  • Karnivool - Sound Awake
  • Karnivool - Themata
  • Kashmir - The Good Life
  • Mostly Autumn- Glass Shadows
  • Muse - Black Holes And Revelations
  • Orgy - Vapor Transmission
  • Redemption - Snowfall on Judgement Day
  • Red Sparowes - The Fear Is Excruciating, But Therein Lies the Answer
  • Riverside - Anno Domini
  • Sophie Ellis Bextor - Trip The Light Fantastic
  • Sylvan - Posthumous Silence
  • The Mars Volta - The Bedlam in Goliath
  • Third Eye Blind - Out Of The Vein
  • This Town Needs Guns - This Town Needs Guns
  • Threshold - Critical Mass
  • Trivium - Ascendancy
  • We Are Scientists - Barbara
  • Zero 7 - The Garden

In other words, I'm for two weeks of camping. The final destination of our annual cycling tour is either Slovenia or Croatia, in 10 stages of about 130 km each.

Syndicated 2010-07-02 13:40:00 from Stationary Traveller

85 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!