Posts tagged 'openchange'

OpenChange 2.0 released

Apparently ‘tis the season for major software releases.

Julien has just announced the release of OpenChange 2.0, codenamed quadrant. This release fixes a number of important bugs and enables integration with SOGo.

With the SOGo backend, it is now possible to set up an Exchange-compatible groupware server that can be accessed from Outlook without the need to connect any connectors.

See the release notes for more details.

comments.

OpenChange server and SOGo

There’s more good news on the OpenChange front. Julien has been working together with Wolfgang and Ludovic from Inverse 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.

There is a screencast up on youtube (there is also a .mov version of the screencast).

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 just 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.

comments.

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:

1
2
3
4
# 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 imports 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 myself, 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:

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

Currently Playing: Karnivool - Themata

comments.

Proof of concept OpenChange server working

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.

comments.

DebConf

I’m looking forward to going to my first DebCamp/DebConf. I won’t be giving a talk, but I hope to work together with others on integrating Samba 3 and 4 better with the rest of the system and VCS integration.

comments.

OpenChange Evolution plugin preview and Debian packages

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 was assigned to OpenChange earlier this year.

I’ve packaged new snapshots of Samba and OpenChange for Debian/Ubuntu. They’re available from my personal apt repository and will hopefully soon also be available from Debian experimental.

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

comments.

Epitech/OpenChange meeting

I’ve had a lot of time to practice my French skills this weekend while visiting Epitech and meeting up with Julien, Ali, Dan and the other OpenChange folks in Paris.

There was a forum at Epitech where student teams present the projects that they’ve been working on over the course of the last year. One of the Epitech student teams has done an excellent job on an OpenChange plugin for Evolution that now even appears to have been picked up by upstream. The other projects were also quite interesting as well and varied from a fun to play 3D racing game to a much improved LGPL’ed implementation of the ClamAv virus scanner or a personal logging application for diabetics. Afterwards there was a little bit of an Open Source conference, where Dan and I gave talks about Open Source and Samba, respectively.

comments.

OpenChange team member

As of today, I’m officially a member of the OpenChange development team. I already had access to the Subversion server and have contributed a number of patches in the last couple of years, mainly related to the build system.

comments.

OpenChange Interview

Linux Weekly News had a good interview with Julien Kerihuel, lead developer of OpenChange, two weeks ago. It’s now also available for those who are not subscribed.

comments.