ubuntu

Seeing this makes me very happy. It's taken us a couple of years to get to this point but we've finally made it, mostly thanks to the dedication and persistence of Julien and Brad.

After over 7 years of working on it off and on, I'm looking for somebody to help maintain (and eventually take over) CtrlProxy. I started working on CtrlProxy somewhere in 2002, only a short while after Wilmer started hacking on BitlBee. If I remember correctly I started working on it because I didn't want to run a separate dircproxy (the only real competitor at the time) instance (with configuration) for each IRC network that I connected to. It was also just a good excuse to play with the IRC protocol a bit.

Over the years, CtrlProxy has served as a playground for me to try out new and interesting things. It's been rewritten or severely refactored several times in its early history, the latest time being the 3.0 release (from 2005). I've tried different build systems, I've tried different implementation languages, I've tried different configuration file formats, I've tried different support libraries, I've tried different version control systems, I've tried different documentation formats. So while it's definitely been a very educational project for me personally, I haven't really had the time or the interest to dedicate to the project that it deserved during the last few years. This was mostly because there were other more interesting FOSS projects I spent my spare cycles on.

These days there are plenty of other good IRC proxies out there, such as BIP, so I doubt CtrlProxy will be missed if it were to disappear. Despite that, if anybody is interested in taking over, please send me an email (jelmer@samba.org) or contact me on IRC (jelmer on the OFTC and Freenode networks).

cp: Anathema - Shroud of False

At the moment I'm in Barcelona, attending the Bazaar sprint, which happens to be cohosted with the Ubuntu Developer Summit. I attended half a day of the UDS in Sydney a couple of years ago, so I had some idea of what I was in for already. It's a lot of fun, and having the two events at the same place at the same time was really worthwhile :-) I finally got to meet some of the Ubuntu server people in person.

I flew here a couple of days early so I could do some sightseeing, never having been in Barcelona (or Spain) before. The city was much nicer than I had expected, and we had some great weather. The timing was great, too: we we were there during the Cycling Tour of Catalonia and F.C.B. won both the national title and the European champions league (I hope I got that right, the important bit was the large amount of people partying outside :-).

During the first day of the summit I gave a short plenary talk on the Samba packaging in Ubuntu. Other than that I spent most of the time during the day switching back and forth between the Bazaar sprint room and the various break-out sessions. The main topics in the Bazaar world were the 2.0 release, and what had to be done to get it out of the door.

% bzr branch deb:line6-usb-source debian
Retrieving Vcs locating from line6-usb-source Debian version 0.7.4-1
Branched 354 revision(s).
% bzr merge-upstream https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/trunk
All changes applied successfully.
Using version string 0.7.4+svn511 for upstream branch.
The new upstream version has been imported. You should now update the changelog (try dch -v 0.7.4+svn511-1 "New upstream snapshot."), resolve any conflicts, and then commit.
% dch -v 0.7.4+svn511-1 "New upstream snapshot.
% bzr builddeb
Building using working tree
Preparing the build area: ../build-area
Purging the build dir: ../build-area/line6-usb-0.7.4+svn511
[...]
Placing result in /home/jelmer/bzr/line6-usb/result
% ls ../result
line6-usb_0.7.4+svn511-1_amd64.changes line6-usb_0.7.4+svn511-1.dsc
line6-usb-source_0.7.4+svn511-1_all.deb
line6-usb_0.7.4+svn511-1.diff.gz line6-usb_0.7.4+svn511.orig.tar.gz

cp: Phideaux - Microdeath Softstar

I just got back home after spending the weekend in Goettingen at Ubucon.de. The conference was very nice and well organized. Since the talks were mainly user-oriented, I didn't attend a lot of them but spent most time working with the other Samba developers on Franky and (trying to) talk to other people. That last bit was a harder than I thought since my German seems to be a bit rusty when it comes to speaking; listening is usually fine.

We made a lot of progress on the merged build; we're getting close to having about half the code shared between Samba 3 and Samba 4.

cp: Van der Graaf Generator - The Least We Can Do Is Wave To Each Other

It took a while, but I've now got Kerberos authentication working for most services.

Done:

• IMAP (Dovecot, Evolution, Thunderbird, Mutt)
• SMTP (Postfix)
• NFS (NFSv4, Linux)
• SMB (Samba, CIFSFS)
• HTTP (apache, firefox, epiphany)
• FTP (kftp, heimdal ftp server, bzr)
• IPP (CUPS, GTK+)
• XMPP (Jabberd2, pyxmpp, gossip/telepathy, gajim, BitlBee)
• LDAP (OpenLDAP)
• SSH (OpenSSH)
• libvirt
• DNS (bind, for dynamic updates)
• Subversion

Todo:

• IRC using SASL?
• bzr smart server
• VNC
• X11
• LDAP GSSAPI authentication in Evolution
• Thunderbird MANAGIESIEVE extension

It's still a lot more work to set this sort of thing up then it should be. Mac OS X and Windows are way ahead of any of the Linux distributions in this area.

cp: Cynic - Veil of maya

While a few of us have been working very hard on Samba 4 to allow it to rock your socks off as an Active Directory Domain Controller, some of the other Samba developers have been working just as hard on improving the existing Samba 3 codebase and adding features to that. This situation has caused tension between developers as well as technical problems in the past - code with the same purpose is being developed in parallel, libraries diverge because features are only added in one branch and not in the other, one codebase is considered "obsolete" by some and the other is considered only a playground for experimental features by others.

As of yesterday, we now have the two codebases living in one and the same git branch. This should make it a lot easier for the two to use the same libraries. Better yet, it should allow us to reconcile the copies of various libraries that exist in both codebases, all of which have diverged to some degree in the last few years.

After a few problems came up merging the two branches the easy way (they both have a directory called "source" and git doesn't deal well with renaming them to "source3" and "source4" respectively), we decided to replay the history of both branches . This has the disadvantage that all existing branches that are based on the Samba 3 and Samba 4 branches will have to be rebased against the new master branch, but it also means we keep the ability to run "git log" inside of our source directories and having it work right.

Other than the fact that this makes it possible to share more code between the two codebases, one of the ideas we have is also to see if it is possible to provide an Active Directory DC by glueing the best bits of Samba 3 and Samba 4 together (aka "Franky") before they are eventually merged completely.

cp: Phideaux - Formaldehyde

I wish SASL was more like GSSAPI. Sure, GSSAPI is horribly overengineered, way too generic and too complex but at least that scares people away from going NIH on it.

The fact that everybody has their own SASL implementation is not really a problem by itself, but most of the implementations only cover a few of the wide range of SASL mechanisms (PLAIN and DIGEST-MD5 usually) that are standardized. There's also tiny bugs that spring up because the implementations differ; for example, inserting whitespace between the elements in a DIGEST-MD5 challenge breaks some clients.

Ever since bzr-svn started supporting "true push", people have been complaining about the extra file properties it sets.

The key thing about "true" push is that it preserves the exact revisions that were present in Subversion. This lets bzr behave on Subversion branches transparently using the same UI you also use for "native" Bazaar branches.

In other words, if I push to a Subversion branch from my machine, then that branch in Subversion contains enough information for somebody else to reconstruct the exact bzr branch I had.

Since some Bazaar metadata can not be represented in Subversion, it is stored in Bazaar-specific Subversion properties. Unfortunately, these file properties show up in email commit notifications and trac and so they tend to annoy people.

There are two ways around this:

• Revision properties

Bazaar-specific metadata can be stored in in custom Subversion revision properties (these don't show up in commit notifications). Unfortunately, this requires Subversion 1.5 or newer to run on the server.

I hope to start setting revision properties instead of file properties when possible as of the next bzr-svn release.

• less strict push

It's also possible to throw away any data that can not be represented in Subversion. Since this means that the remote branch won't end up an exact same copy of the local revisions, this isn't true push. The two branches will have diverged (no matter how slightly) after such a push so it is necessary to rebase on the remote branch after pushing.

This is similar to the way git-svn pushes data into Subversion - it calls it "dcommit".

Since this uses rebase it has the usual disadvantages of rebases, which I won't get into right now.

As of a couple of days ago, bzr-svn now also supports this mode of pushing using the "dpush" command, by popular demand.

cp: Brandi Carlile - The Story

bzr-svn has always been using the standard Python bindings that were provided with Subversion itself. Unfortunately, I had to fix some issues in these bindings since they were incomplete or broken and thus bzr-svn has always depended on a development snapshot of Subversion.

As of today, bzr-svn is using its own Python bindings for Subversion.

There were several reasons for switching to our own bindings:

• There are no requirements for backwards compatibility within bzr-svn. This means the API can be made sane without worrying about the mess it was in the past and users who still rely on that.
• Deployment. It took 2 years for my fixes to the Subversion Python bindings to be part of a release. It'll be even longer before Subversion 1.5 makes it into most available distributions. That makes it very hard to just download and install bzr-svn.
• They're in plain C, not SWIG. SWIG has a big advantage for the Subversion folks since it can generate python, ruby, java or tcl bindings all at once without a lot of overhead per language. However, it has issues as well that make it a bad choice for bzr-svn.
  • It generates inefficient code - it generates proxy classes that add more layers in the stack
  • Bindings tend to be very much like the C API rather than "Pythonic". To make them more Pythonic, you need tons of typemaps. For example, the Python bindings in bzr-svn provide an iterator when browsing the revision history rather than a callback as C and the SWIG bindings do.
  • Hard to write - personally at least, I write bindings in C faster than in SWIG
  • Adds an extra dependency to the build process. Several people had trouble building Subversion on their Mac machines because they didn't have the right version of SWIG available.

Since all of the patches that bzr-svn depended on previously were in the Python bindings for Subversion, it is now possible to use bzr-svn with any version of Subversion newer than 1.4.0. Of course, you do need to have the development headers installed as well.

cp: Kathleen Edwards - Independent Thief

I was happy to see that John Carr has set up a Bazaar Mirror of all projects in GNOME Subversion, all created using bzr-svn. There's also a quick introduction to using Bazaar for GNOME developers on the GNOME wiki.

Wouter, long time Bazaar user and GNOME dude, recently blogged about pushing Bazaar branches into GNOME Subversion, working around the restrictions imposed by the pre-commit hooks in GNOME Subversion.

The problems John ran into with memory usage in the Python Subversion bindings encouraged me to continue the work on bzr-svn's own Python bindings, thus avoiding any dependency on unreleased versions of Subversion and several other issues.

My relationship with git is still one of love and hate. It cuts corners to increase performance in a couple of places and that can be really bloody annoying.

For example, jerry renamed one of the top-level directories in Samba 3 (revision 9f672c26d63955f613088489c6efbdc08b5b2d14). Git will skip rename detection in this revision because of the number of files it affects, thus causing the output of "git log <path>" of this particular directory to be useless.

I'm the first to admit "bzr log" on directories and files in large history projects is painfully slow, but at least it gets the output right.

cp: Brandi Carlile - The Story

It's been a busy two weeks. Wilco and I drove up to Göttingen on Sunday two weeks ago to spend some days hacking and meeting up with the other developers before the start of SambaXP. It was really nice to see everybody again after more than 7 months.

SambaXP was a bit different this year. There were three tracks during the second part of the conference this year, one more than previously and of course, there were several engineers from Microsoft attending this time! Some of the interesting talks this year included Julien's update on OpenChange, Tridge's talk on PFIF, the talk from the likewise folks and of course the talk from Microsofts' Wolfgang Grieskamp on SMB2. We also had some other informal discussions with the Microsoft folks about specific topics - very useful!

There are some photos up on the SambaXP homepage. And just to be ahead of the comments: yes, I know I need a haircut.

I did some initial work on several bits and pieces of code that I hope to expand over the next few months. Volker has started working on ncacn_ip_tcp support and I have been working on making the Samba 3 DCE/RPC library compatible with Samba 4. This should allow OpenChange to use Samba 3 in the future.

Guenther, Wilco and I made some initial progress on the policy library, allowing client-side manipulation of (group) policies in Samba. I worked with Simo on trying to get rid of an evil hack in Samba4's event subsystem.

David Holder blogged about some of the IPv6 development that we did during the conference: http://www.ipv6consultancy.com/ipv6blog/?p=34

And lots of other things I can't remember at the moment...

After the conference Andrew, Wilco and I drove back to the Netherlands and I played tour guide for a bit showing Andrew around the country during the afternoon and hacking Samba together in the morning. Later this week we took the train to Brussels, Eurostar to London and visited Sam's company
in the UK Midlands for a couple of days.

And in the midst of all this, it seems Ubuntu Hardy was released. Congratulations to all those involved!

cp: Brandi Carlile - Turpentine

This slightly evil hack to bzr-svn allows using bzr-builddeb as a drop-in replacement for svn-buildpackage, making it recognize the "mergeWithUpstream" property svn-buildpackage uses.

cp: Jeff Healey - Mess O' Blues

The London bzr sprint is over again for this year. It was really good to meet everybody in person again and also to meet some of the folks who hadn't been to a sprint before.

Last years sprint was mainly about improving performance; this year, we discussed adoption blockers and how to remove them. A short summary of the brainstorming is on the wiki.

Martin's blog has some pictures.

The Mars Volta concert we went to last night in Tilburg was absolutely brilliant. Very energetic and definitely one of the best acts I've ever seen live. We were standing in the back of a completely packed venue for 3 hours, but it was very much worth it.

cp: Soft Machine - Teeth

FOSDEM was once again a lot of fun, although (as many others have already blogged) it's starting to become a bit too big for the venue where's it currently held, the ULB. I think I only attended 3 actual talks this year because it was so hard to get into a room.

Every now and then I come across a brilliant package in Debian. Nemiver is one. It is a simple GTK+ frontend for gdb, much like kgdb or ddd.

In other news, Andrew was interviewed about Samba 4 last week; the interview is here.

cp: Mars Volta - Miranda That Ghost That Just Isn't Holy Anymore

Srini writes that a preview of the Evolution OpenChange plugin has just been published. This plugin is now developed in the Evolution Subversion repository, but is based on the original plugin that was written by the Epitech team that worked for the OpenChange project this year.

I've packaged new snapshots of Samba and OpenChange for Debian/Ubuntu, available from my personal apt repository and hopefully soon also from Debian experimental.

Update: These packages are now in Debian experimental as well as the upcoming Intrepid release of Ubuntu. I have removed them from my personal repository because of disk quota.

At the moment, I have two Guitar amplifiers: a simple Behringer Modelling Amplifier and an Aria Pro II (my first amplifier). The input socket of the Aria broke a couple of weeks ago and since it has also gotten a bit noisy I don't feel like paying a lot of money to get it fixed.

In a bad attack of Gear Acquisition Syndrome, I ordered a Line 6 XT POD yesterday, as well as a new Marshall Amplifier. The XT Pod should be usable without PC and there are at least some experimental Linux drivers for it. The Linux support is one of the reasons for picking the Line 6, since I'd like to give Linux (maybe UbuntuStudio?) another try in favor of good old Cubase. I'm interested to hear if there are any apps in particular I should give a try.

cp: Coheed and Cambria - No World For Tomorrow

As some may have noticed, a large portion of my Samba 4 work during the last few months has been focussed on adding Python bindings for our various public libraries and the refactoring necessary to make it possible to add Python bindings. So far, we have bindings for LDB and TDB but I intend to add bindings for most of our public API so it is possible to, for example, open Windows registry files, join domains, etc. from Python.

LDB is our LDAP-like embedded database, and is for LDAP what sqlite is for SQL. Last night I decided to see how hard it would be to write a graphical browser for LDB using Python, and it turned out to be quite easy, thanks to PyGTK. There is a screenshot of what it looks like [h ttp://samba.org/~jelmer/gtkldb.png here]. Packages with the Python bindings for LDB are already in Debian.

The sources for gtkldb are available in the samba-gtk bzr branch at http://people.samba.org/bzr/jelmer/samba-gtk/trunk, along with some of the GTK+ frontends for Samba 4 I wrote earlier (gregedit, gwcrontab, gwsvcctl, gepdump and gwsam).