Canonical Voices

Posts tagged with 'bug'

Martin Pool

We’ve recently deployed two features that make it easier to find bugs that you’re previously said affect you:

1: On your personal bugs page, there’s now an Affecting bugs that shows all these bugs.

2: On a project, distribution or source package bug listing page, there’s now a “Bugs affecting me” filter on the right (for example, bugs affecting you in the Launchpad product).

Counts of the number of affected users already help developers know which bugs are most urgent to fix, both directly and by feeding into Launchpad’s bug heat heuristic. With these changes, the “affects me” feature will also make it easier for you to keep an eye on these bugs, without having to subscribe to all mail from them.

screenshot of

Read more
Iain Farrell

Every day just about everyone at Canonical gets email by the bucket load. Even someone like me who’s only peripherally involved in desktop development and files his own bugs through the release cycle can get get hundreds of emails from Launchpad every day. So it made our day to get a letter like this from Neil in Monroeville.

In his letter Neil says he’s been using Ubuntu since 8.10, praises Unity and also files a bug he’s experiencing with the launcher in 11.04!

Letter from America by Neil W. Kitzmiller


Neil, you don’t give us an email address but if you read this I’ve triaged your bug, marked it as confirmed and will be sending you a CD in the post which I hope will fix your problem :) Drop us an email if you can!

Read more

Pywin32 is a very cool project that allows you to access the win api without having to go through ctypes and deal with all the crazy parameters that COM is famous for. Unfortunately sometimes it has som issues which you face only a few times in your life.

This case I found a bug where GetFileSecurity does not use the GetFileSecurityW method but the w-less version. For those who don’t have to deal with this terrible details, the W usually means that the functions knows how to deal with utf-8 strings (backward compatibility can be a problem sometimes). I have reported the bug but for those that are in a hurry here is the patch:

diff -r 7dce71d174a9 win32/src/win32security.i
--- a/win32/src/win32security.i	Sat Jun 18 10:16:06 2011 -0400
+++ b/win32/src/win32security.i	Mon Jun 20 14:15:27 2011 +0200
@@ -2108,7 +2108,7 @@
  if (!PyWinObject_AsTCHAR(obFname, &fname))
   goto done;
-	if (GetFileSecurity(fname, info, psd, dwSize, &dwSize)) {
+	if (GetFileSecurityW(fname, info, psd, dwSize, &dwSize)) {
   PyErr_SetString(PyExc_RuntimeError, "Can't query for SECURITY_DESCRIPTOR size info?");
   goto done;
@@ -2117,7 +2117,7 @@
   PyErr_SetString(PyExc_MemoryError, "allocating SECURITY_DESCRIPTOR");
   goto done;
- if (!GetFileSecurity(fname, info, psd, dwSize, &dwSize)) {
+ if (!GetFileSecurityW(fname, info, psd, dwSize, &dwSize)) {
   goto done;
@@ -2153,7 +2153,7 @@
  if (!PyWinObject_AsSECURITY_DESCRIPTOR(obsd, &psd))
   goto done;
-	if (!SetFileSecurity(fname, info, psd)) {
+	if (!SetFileSecurityW(fname, info, psd)) {
   goto done;

Read more
Robert Collins

A short headsup about an upcoming change.

A very long time ago the team owner was always a team member. This was changed to make team owners optionally members (sometime before 2008!). However the change was incomplete – there has been an inconsistency in the codebase ever since. For the details see bug 227494.

I wanted to let everyone know about us actually finishing this change though, because for a small number of teams (about 400) their administrators may be surprised when they cannot do things.

The inconsistency was this: if a team owner leaves the team, so they just own it, then they are not listed as a team member. But if they try to exercise a privilege the team grants – e.g. if the team is a bug supervisor – the team owners were able to do this. This setup made it impossible for users to accurately determine who can carry out the responsibilities of a team : the Launchpad web UI incorrectly reported team members.

The fix which will be deployed in the next day or so corrects this inconsistency: Team ownership will no longer grant access to anything that team membership grants.

For clarity, these are the rules around team owners:

  1. When a team owner is assigned (or a team made) the owner defaults to being an administrator-member.
  2. If a team owner deactivates their team membership then they are not considered a team member anymore: resources and access that team membership grants will not be available to the owner at this point.
  3. Team owners can always perform adminstrative tasks on the team: creating new administrators, edit the team description, rename the team etc.
  4. Point 3 allows an owner to add themself to the team they own even if they deactivated their membership previously.

Read more
Robert Collins

We have a small quandry on the Launchpad development team at the moment. As bug 268508 discusses, when one searches for a bug on Launchpad we do a substring search on the names of bug targets.

For instance, searching in Ubuntu for ‘gcc’ will return all bugs on the packages ‘gcc’, ‘gcc-4.4′, ‘gcc-4.3′, ‘gcc-3.3′ and so forth. Likewise search for bugs in a project group will do a similar substring search on each of the individual projects in the project group.

It turns out that doing this search is itself expensive. I asked on the Ubuntu devel list about turning it off. We would close bug 268508 and also significantly improve search performance.

However this is a possibly contentious change – there was one mail strongly in favour of the current behaviour – so I’d like to get this change proposed to a wider community.

If you’ve got a strong opinion – that the current behaviour is good, or like bug  268508 describes, that its a poor behaviour and we would be better off without it, then I’d love to hear from you. Just leave a comment on this post, drop me an email – robert at – or post to the launchpad-users mailing list.

Rob (LP technical architect)

Read more

I have been working for about 2 moths now and after releasing our internal alpha release I have found a very interesting bug. In our port to windows we have decided to try and make your live as nice as possible in an environment as rough as Windows and to do so we allow our port to auto-update to always deliver the latests bug fixes.

Ofcourse to ensure that we are updating you system with the correct data we always perform a check sum of the msi. While our msi is updating to S3 using python, the code that downloads it is C#. Here are the different codes to calcualte the checksum:

    fd = open(filename,'r')
    md5_hash = hashlib.md5(
private static string Checksum(AlgoirhtmsEnum algorithm, string filePath)
            HashAlgorithm hash;
            switch (algorithm)
                case AlgoirhtmsEnum.SHA1:
                    hash = new SHA1Managed();
                case AlgoirhtmsEnum.SHA256:
                    hash = new SHA256Managed();
                case AlgoirhtmsEnum.SHA384:
                    hash = new SHA384Managed();
                case AlgoirhtmsEnum.SHA512:
                    hash = new SHA512Managed();
                    hash = new MD5CryptoServiceProvider();
            var checksum = "";
            using (var stream = new FileStream(filePath, FileMode.Open, FileAccess.Read))
                var md5 = hash.ComputeHash(stream);
                for (var i = 0; i < md5.Length; i++)
                    checksum += md5[i].ToString("x2").ToLower();
            return checksum;

Believe it or not the hash returned by each piece of code was different. WTF!!!! After a ridiculous time looking at it I managed to spot the issue. If you are using python on windows, unless you use the b option when opening a file, python will convert all the CRLF to LF making the hash to be different, how to fixed this? simply open the file this way:

fd = open(filename,'rb')

Go an figure….

Read more