Samba 4 and OpenChange daily Ubuntu packages

meta = {'category': debian, 'date': Tue 28 September 2010}

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

1
2

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

comments.

bzr-builddeb FTW

meta = {'category': bazaar, 'date': Fri 07 November 2008}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

% 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

Currently Playing: Phideaux - Microdeath Softstar

comments.

bzr-svn push without file properties

meta = {'category': bazaar, 'date': Mon 30 June 2008}

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:

comments.

bzr-svn: now with its own Subversion Python bindings

meta = {'category': bazaar, 'date': Sun 22 June 2008}

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.

Currently Playing: Kathleen Edwards - Independent Thief

comments.

Bazaar in the GNOME world

meta = {'category': bazaar, 'date': Thu 19 June 2008}

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.

comments.

Using bzr-builddeb as a svn-buildpackage replacement

meta = {'category': bazaar, 'date': Wed 26 March 2008}

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.

Currently Playing: Jeff Healey - Mess O’ Blues

comments.

Bzr-Svn

meta = {'category': bazaar, 'date': Fri 03 August 2007}

The next major release of bzr-svn, 0.4, has now been released. The main change in this release is that the behaviour of push is now intuitive. The big hack that allowed push to somewhat work in the previous release has been replaced by proper push which behaves the same way as it would against a Bazaar branch.

It’s now also possible to branch from non-standard branch locations such as /foo in a repository and not necessarily standard locations like /trunk or /trunk/foo. See the release announcement for a list of other changes.

It’s interesting to see what other people are saying about bzr-svn on their blogs:

• Migrating to bzr using bzr-svn
• Missing support for svn:externals
• Issues with branching schemes
• using bzr-svn for rhythmbox
• bzr-svn on Gentoo
• issues with Windows support

Note that bzr-svn 0.4 has been tested on Windows and that branching schemes are now more flexible.

comments.

Using a pqm with Subversion

meta = {'category': bazaar, 'date': Fri 25 May 2007}

One of the things that I’ve always missed in DVCS is the ability to refuse commits in a branch that’s shared by multiple people based on a test suite run. Sure, it’s possible to have a pre-commit hook - but that would mean that you’d have to wait for the full test suite to run until the commit finishes. With the time it takes to run the Samba testsuite, this is not really an option.

One of the things that would work is to have everybody work in a separate branch and then have some sort of tool that merges those revisions from everybody’s personal branches that worked ok. However, to my knowledge, there is no such tool for Subversion.

Bazaar uses a tool called PQM (Patch Queue Manager). PQM usually controls the main branch (for example for Bazaar, it controls bzr.dev), and waits for GPG-signed requests to merge a specific revision into that main branch. Before accepting such a revision, it will try to run the testsuite to make sure it passes. This guarantees that the main branch never contains broken code (as far as can be indicated by the testsuite).

Now that bzr-svn supports true push, it is possible to actually use a PQM with a Subversion branch. I’ve tried it on a smaller branch last week, and am now looking into using this for my Samba work.

comments.

London

meta = {'category': bazaar, 'date': Sat 19 May 2007}

I’m currently doing a bit of sightseeing in London, after attending the Bazaar sprint at the Canonical office. It was a good sprint, and quite different from the previous ones - in that there was only a limited amount of actual coding involved. The view from the Canonical office is magnificent, so we were even able to do some sightseeing while working…

Bazaars’ focus has previously mainly been on correctness and features. The first has always been one of our strengths, and we’re in pretty good shape regarding the second. Performance has been one of the main complaints from users about Bazaar and so we have recently tried to improve in that area.

Since 0.12, we have already tried to optimise some of the common code paths and some people have been working on a high performance smart server (to speed up remote operations).

During the first two-and-a-half days of the sprint, we analysed 20 of the most common use cases with Bazaar and determined what complexity they should ideally require to be able to work. After this analysis, we looked at ways to change our data structures to reach these goals.

I have mainly been a spectator during the latter parts of these discussion, but they were interesting to follow.

One of the things I worked on was support for true push in bzr-svn. This was one of the bugs that has bitten a lot of users of bzr-svn. The upcoming bzr-svn 0.4 now supports true push as well as commits in heavyweight checkouts. I hope to release 0.4 after adding nested tree and ignores support so that I don’t have to change the internal mapping mechanisms again.

And now, it is time for some more sightseeing. After that I hope to get back to the reason I’m doing all of this in the first place: Samba!

comments.

Bazaar and Subversion nested tree support

meta = {'category': bazaar, 'date': Sat 31 March 2007}

As of 0.15, Bazaar will have initial support for nested trees. Nested trees basically allow you to add a ‘magic’ directory to a Bazaar branch that in itself is another Bazaar branch. A very good use case of this is if you have a project for which you need to include some library (e.g. popt). Nested trees allow you to add a reference to the upstream popt branch, avoiding the need to synchronize every time upstream fixes a bug.

Subversion has similar functionality, although the term used there is ‘externals’. Externals are quite easy to use - using them only requires setting the svn:externals property.

I’ve done some early work on supporting externals in bzr-svn and mapping them to nested trees. At the moment, bzr-svn is able to track nested trees that are being added. Removes and changes to existing nested tree locations are still on my todo list, but will definitely be supported in bzr-svn 0.4.0.

comments.