Canonical Voices

Posts tagged with 'cool new stuff'

Matthew Revell

Some bugs get reported more than once. That’s why we’ve got the dupe finder.

Some duplicate bugs slip through the dupe finder. Really common issues get quite a few dupes and someone from the relevant project usually goes through and marks them as duplicates of the master bug where the actual discussion and tracking is taking place.

There has been a really annoying bug in the way Launchpad has handled all this, though, and Deryck’s just fixed it :)

Let’s say you’ve got a bug report that has a few duplicates attached to it. You then discover that, actually, there’s an older bug with a more mature discussion and that, really, that’s the master bug. Until now, before you marked your bug as a duplicate of the master, you’d first have to take all the dupes of your bug and manually make them dupes of the master.

Still with me? :)

For a busy bug with many dupes, some of which have their own dupes, that’s a real disincentive to clearing up the multiple duplicates and gathering everything together on the one true master bug.

Now, though, simply mark your bug as a duplicate and Launchpad will automatically transfer your bug’s dupes to the new master bug.

Simple :)

Read more
Matthew Revell

Some bugs attract many, many comments.

For a while now, Launchpad has displayed only the first 80 comments on any bug report, with the option of viewing the full comment history. That’s been good for speeding up page loads but not so great at offering an accurate view of the current state of discussion about the bug.

Bryce has fixed that. Now, a bug report page still shows only 80 comments, by default. However, to give a better overview of the state of discussion, it now shows the first 40 and the last 40 comments.

So, half way down the comments you’d see something like:

Here's what you see in the middle of the bug comment history

Here's what you see in the middle of the bug comment history

Then, at the bottom of the summarised comment history there’s this:

Comment history summary

Comment history summary

With any luck, this should result in new bug comments that take into account the most recent discussion.

Read more
Matthew Revell

Better dupe finding

One of my favourite things about Launchpad’s bug tracker is the dupe finder: when you report a new bug, it’ll search to see if there’s already a similar bug report. It’s the same for questions in Launchpad Answers, too.

Getting to see possible dupes before you file a bug or question is a great time saver for you and the people on the other end. However, the dupe finder has been timing out a lot lately.

Rob Collins, Launchpad’s new Technical Architect, has introduced some changes that should make the dupe finder more reliable.

Other than fewer timeouts, here’s what you might notice:

  • the dupe finder now returns fewer matches — three or four rather than ten or more
  • the results should be more relevant.

We want to know how this works in practice. Let us know how you get on with the new dupe finder. Either leave a comment here, mail feedback@launchpad.net or join us on the launchpad-users mailing list.

How Rob did it

The previous dupe finder had a number of problems, not least that the search engine it’s built on is less efficient than we need. We’re planning to replace the search engine but not straight away, so Rob looked for a temporary solution that would work for the next five or six months.

I’ll hand over to Rob to explain what he actually did:

The old search did a pre-pass over every possible hit, which is 400,000 items for Ubuntu bugs and very slow to do. It then did a search matching any document that had a rare search term in it.

So, by rare we mean that the term showed up in less than half of the possible hits.

For example, if you searched for “firefox crashes on <website> in flash” on /ubuntu/+filebug it would search for any bug with any of “firefox” (< 50% of bugs are on firefox), "crash" (<50% of bugs say "crash"), "<<50%...), "flash" (< 50%...)

However, many, many bugs mention "firefox" and many, many bugs mention "crash" and many, many mention "flash".

So, the total return from the search could be 10,000 or 100,000 quite easily and — unlike other search engines — the more terms you typed in, to make it more precise, the less precise it became.

That sounds odd but here's why: it started bring back bugs from anywhere that happened to mention any search term and, adding in the relevance weighting we had just added confusion to it.

What we do now is: if you sesarch for "firefox crashes on <website> in flash" we search for any bug continaing three of the four non stopwords, i.e."firefox, crashes, <website>,flash". If a bug mentions any three, it will be returned.

We can switch this off easily if we have to, so we do want feedback about how people find this.

Read more
Julian Edwards

Improvements, you say?

Very recently we saw the beta release of a new feature on Launchpad: building packages from recipes. Recipes bring Bazaar branches for the upstream source code and a packaging branch together to generate a Debian source package. We informally referred to this internally as “the Wellington project” because we first embarked on this long road of development back in November 2009 with a coding sprint in Wellington, New Zealand.

So, why do we need to use the build farm for this?

Very early on we realised that this would be a challenging project because packaging recipes allow untrusted arbitrary code to run as part of building the package, so we decided that the only place we could do this operation was in the same place that we do one of the other untrusted operations – the PPA build machines.

The PPA build machines work for untrusted code because they run as a virtual machine. After the build job has finished, the machine is simply ripped out and restarted so if any code did something nasty, we throw all the nastiness away!

Why can’t the build farm do this already?

The Launchpad build farm has been around for a while now, but it’s of course only used for building source packages into binary debs. We realised that we’d need a whole new data model on the Launchpad side, changes to the master/slave protocol and changes in the slave code to make it actually run this new job type – a lot of work! It was also about this time I became aware of a further untrusted job type, generation of translation templates for Launchpad Translations, so we began work on making the build farm able to process any kind of job.

What had to change?

By far the biggest change for this was to fix how we store the build/job information in the database. The canonical way to refer to a “job” on the build farm was via “build” record, and this is what all of the history pages in the UI were using. We’ve now re-architected this to use a generic “build farm job” and a bunch of new database tables that re-factor all the information needed for various jobs on the build farm, in fact we found out that the recipe build jobs and the source package build jobs had quite a lot in common which resulted in some merciless code re-factoring indeed.

The other major change was the slave builder code itself. This runs as a Twisted executive that we talk to using XMLRPC from the build manager, which kicks off external processes to run the job and monitors them. The only job it knew about was to run sbuild to build source packages. We’ve changed this to also run bzr builder and a custom script to generate the translations templates.

So, will I see anything different?

A recipe build in action

A recipe build in action

You won’t see much visually that’s changed in the Build Farm. If you’re observant, you’ll see the occasional job appear in the list that announces it’s a recipe build, but they’re generally pretty quick to complete!

We’ll post a more detailed explanation of how to use recipe builds in the future, but for now it’s remaining in beta until all the problems are ironed out. If you have any feedback, please file a bug or send us an email.

Read more
Matthew Revell

SFTP uploads holding post

You can now use SFTP to upload source packages to your Personal Package Archive!

If you’re already familiar with uploading to a PPA, all you need to do is ensure your dput.cf includes the following:


method = sftp
login = <your Launchpad account name>

If you’re new to PPAs, but already know how to create packages for Ubuntu, take a look at our guide.

Read more
Matthew Revell

Via Planet Launchpad: Launchpad’s Strategist, Jonathan Lange, writes on his blog:

We’re starting to get a picture of what we want to do in the second half of 2010. In particular, lots of people within the team and within Canonical are starting to get fed up with our privacy and permissions model, which is quite patchy. It’s currently tangled up with the way we send emails to people, and we’d love to untangle them.

The Foundations team are already at work making Launchpad faster, and that’s something we want work on even more in the coming months. Derivative distributions – that is, a Linux distribution that extends or customizes another one, generally Ubuntu – have always been a key part of the vision for Launchpad, and they are finally going to get the effort they deserve.

Finally, we want to do whatever we can to make the Ubuntu Software Center rock harder than it does already. Launchpad occupies a special place in the Software Center world, since it can help make it easier to get applications for your desktop and make it easier to develop those applications.

If you’re keen to know what we have planned for Launchpad, you can subscribe to the roadmap page on our dev wiki.

Read more