Canonical Voices

Posts tagged with 'bzr'

Martin Pool

Jelmer writes:

bzr-builddeb 2.8.1 has just landed on Debian Sid and Ubuntu Precise. This version contains some of my improvements from late last year for the handling of quilt patches in packaging branches. Most of these improvements depend on bzr 2.5 beta 5, which is also in Sid/Precise.

The most relevant changes (enabled by default) are:

  • ‘bzr merge-package’ is now integrated into ‘bzr merge’ (it’s just a hook that fires on merges involving packages)
  • patches are automatically unapplied in relevant trees before merges
  • before a commit, bzr will warn if you have some applied and some unapplied quilt patches

Furthermore, you can now specify whether you would like bzr to automatically apply all patches for stored data and whether you would like to automatically have them applied in your working tree by setting ‘quilt-tree-policy‘ and ‘quilt-commit-policy‘ to either ‘applied‘ or ‘unapplied‘. This means that you can have the patches unapplied in the repository, but automatically have them applied upon checkout or update. Setting these configuration options to an empty string causes bzr to not touch your patches during commits, checkout or update.

We’ve done some testing of it, as well as running through a package merge involving patches with Barry, but none of us do package merges regularly. If you do run into issues or if you think there are ways we can improve the quilt handling further, please comment here or file a bug report against the UDD project.

Caveats:

  • If there are patches to unapply for the OTHER tree, bzr will currently create a separate checkout and unapply the patches there. This may have performance consequences for big packages. The best way to prevent this is to set ‘quilt-commit-policy = unapplied‘.
  • bzr merge‘ will now fail if you are merging in a packaging tree that is lacking pristine tar metadata; I’m submitting a fix for this, but it’s not in 2.8.1.
  • if you set ‘quilt-commit-policy‘ and ‘quilt-tree-policy‘ but have them set to a different value, bzr will consider the tree to have changes.

To disable the automatic unapplying of patches and fall back to the previous behaviour, set the following in your builddeb configuration:

quilt-smart-merge = False

Read more
Vincent Ladeuil

The package importer is an important piece of the Ubuntu Distributed Development. It mirrors source packages and Bazaar branches and relies heavily on Launchpad to achieve that.

The past

During Launchpad downtimes, many (>1000) imports failed and they had to be re-queued semi-manually. The importer would have been better inspired by making tea instead of queuing imports that were bound to fail.

The circuit breaker

An automatically operated electrical switch designed to protect an electrical circuit <…> a circuit breaker can be reset (either manually or automatically) to resume normal operation.

This looks like a good candidate to avoid import failures while Launchpad is down.

In this automaton representing the behaviour of a circuit breaker, three events are used (remember that here closed == works ;)):

  • attempt: we try to use the circuit,
  • failure: an undesired event has occurred,
  • success: the circuit is working.

The main scenario here is:

closed — failure –> open — attempt –> half open — success –> closed

The reality test

A Launchpad rollout happened Friday 30 September 08:32. The importer log file said:

2011-09-30 08:32:02,308 – __main__ – INFO – Launchpad is down, re-trying jcifs

2011-09-30 08:34:09,337 – __main__ – INFO – Launchpad *is* back

The successful import took 27″, so the importer knew Launchpad was down for 1’40″ (back – down – duration(import)). I asked the Launchpad admins how long it took them and their log said:

2011-09-30 08:33:41 INFO    Outage complete. 0:01:40.919527

Make tea… or not

Another interesting number here is that we retried 498 times during this downtime. This is probably excessive and can be fixed by reducing the importer concurrency while Launchpad is down. These 498 attempts were previously seen as failures for 498 different packages.

In the end, not only did we avoid these 498 spurious failures but the imports were only suspended for as long as Launchpad was down, up to the second !

But that’s a bit short to make tea…

Read more
Martin Pool

I’ve worked with Robert Collins for the last 5 years or so at Canonical, and it’s been a real pleasure. Now Robert’s moving on to a great new rôle at Canonical, as technical architect of Launchpad. I can’t think of a better job for him, or a better person for the role, and it’s already paying off through Launchpad becoming faster (shorter page timeouts and hitting them less often) and I think more fun to work on. (See also his stump speech.)

Now we’re looking for a very good software engineer to join the Bazaar team at Canonical, working both on the core tool itself and on how it’s used by Ubuntu developers. We would love to get more applications from people with packaging or distro experience. I want to work with someone who’s very driven, who’ll reach out to their users and not wait to be told what to do, someone who knows the whole environment we work in, and someone who cares about doing good things.


Read more
Martin Pool

At the moment bzr treats deletion of a directory containing unversioned files (either ignored or unknown) as a conflict.

This is a bit annoying because often the unversioned files are generated trash, like .pyc files from Python. However in some cases people do have “precious” files that are ignored but shouldn’t be just deleted.

Vincent has a merge proposal up that will instead move the files into a bzr-orphans directory in the root of the tree.

What would you like to have happen? My feeling is that there should be a configuration option to choose the policy, and we should perhaps eventually distinguish “junk” (safe to delete) from “precious”, as Baz and GNU Arch did.


Read more
Martin Pool

We’re going to release bzr 2.2b4 this week, which will be the final beta for the bzr 2.2 series and the start of the 2.2 release branch.  From this point on the 2.2 will be an API freeze, so that any plugins that are updated to work with 2.2b4 will also work with 2.2.0 and future bugfix updates.  We plan to do 2.2.0 at the end of July.

2.2 brings a bunch of performance, correctness and usability improvements.


Read more
Martin Pool

Review of Launchpad and Bazaar on ArsTechnica by the lead developer of gwibber.

  • Likes the way the bzr client feeds into the web ui, by setting bug links etc
  • Easy automatic imports from cvs, svn, git and hg, either for a one-shot cutover or continuing tracking
  • More powerful bug tracking than github
  • Loggerhead feels slow and poorly integrated with Launchpad, but qbzr is brilliant
  • Merge proposals good for tracking contributions

Read more
Ian Clatworthy

One of the primary reasons why Bazaar exists is that Canonical wants to make it as easy as possible for more people to contribute to FOSS (Free and Open Source Software) projects. After many years of development, the pieces of the puzzle are really falling into place nicely. See the tutorial I put together last week to see just how easy it can be.


Read more
Ian Clatworthy


Are you a Bazaar fan and need some help explaining to others why Bazaar is cool? I published a document last week called Why switch to Bazaar? that may help. I’ve tried hard to present the big picture together with some concrete examples, explaining what we stand for and what that means to users, teams and communities in reality. Furthermore, if you tried Bazaar 1.x but found it too slow or inefficient, I’m sure you’ll find the Bazaar 2.0 benchmarks included in the document great news.

I hope you find the document interesting and food for thought. If there are any mistakes or you’ll like to translate the document to another language, please let me know.

Read more