automatically add keys when whitelisted for apturl

Bug #328486 reported by Colin Watson on 2009-02-12
Affects Status Importance Assigned to Milestone
software-properties (Ubuntu)
Michael Vogt
Michael Vogt

Bug Description

If the user adds a custom third-party repository that happens to be whitelisted for the purposes of apturl adding keys (under the jaunty-apturl-add-repo and partner-repositories specifications), then we should find the key automatically in software-properties too, since we already know what it is, rather than requiring the user to download it separately and import it from a file.

Colin Watson (cjwatson) on 2009-02-12
Changed in software-properties:
milestone: none → ubuntu-9.04-beta
Changed in software-properties:
status: New → Incomplete

 Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

Changed in apturl:
importance: Undecided → Wishlist
Siegfried Gevatter (rainct) wrote :

Eddie: Thank you for attempting to triage this bug and helping improving Ubuntu, but you action on this one wasn't correct. Please note that ideas should not necessarily be banned, Launchpad has an importance called "Wishlist" specifically for them (and Brainstorm is, rather, a place to get feedback on ideas and where people who don't know how to work on something can ask others to do it, but some ideas from there actually end up being handled as wishlist bug reports). Even more, this report looks more like an usability bug than a request for a new feature, and looking at the profile of the person who reported it you can see that he is unlikely to file a wrong report (Ubuntu Core Developer, Canonical employee, over 100.000 karma, etc); in fact, being a Core Developer he is one of the people responsible for the collective maintenance of this package (as it resides in "main"). Please see for further information.

Changed in apturl:
status: Incomplete → New
Colin Watson (cjwatson) wrote :

Furthermore I had already discussed this with the author of the application before filing this bug.


Thank you for your feedback. I'm fairly new to triaging bugs and am still learning my way around.

However, I'm unclear on some of your suggestions. To begin with, I never indicated that this idea should be banned. I posted the brainstorm response because I thought (based on QA procedures ) that the report sounded like a feature request and by marking it as such the package team could see the report and be in a better position to evaluate it.

When I started working on this bug report the status was set to new and I saw no indication that anyone had begun working on it. Colin may have been working with the application's developer, but I had no way to know that based on the information in this report. Again, following the triage procedure, I left my stock response and then left a note on #ubuntu-bugs asking someone on the Bug Control Team to review this bug and change the status to Wishlist.

Sorry if I stepped on anyone's toes. I was just trying to stick to the guidelines set in the Bug Squad KnowledgeBase.

Siegfried Gevatter (rainct) wrote :


First of all, I hope my message didn't sound like a personal attack or anything like that, as that wasn't my intention - it's great that you are contributing to bug triaging, and of course everyone can make mistakes :).

I used the word "banning" for "closing the bug" (although you did not close it, but mark it "Incomplete", but that still gets the bug out of developer's overview), I guess it wasn't the most appropriate term. I wasn't aware of those instructions, but they do not mention changing the status of the bug - please do not do this for other cases like this unless you are sure that the report is not relevant here.

The blog entry to which I referred you mentions a set of Greasemonkey plugins, at, which can do stuff like adding team icons next to the names of people; this can be very useful to identify developers and the like. I'd suggest having giving it a try. (As I already said, checking the profile of the reporter is another option, although this one is rather slow and not very practical).

Colin Watson (cjwatson) wrote :

Brainstorm is not useful for us for dealing with detailed wishlist bugs raised by developers or other knowledgeable users. It's useful for aggregating lots of perhaps less-detailed ideas raised by ordinary users so that we can assess what the top priorities for future releases should be. For wishlist bugs like this one that already make a very specific suggestion for improvement in a particular package, putting it in Brainstorm would make it *harder* for us, not easier! (The Bugsquad documentation should be improved in this regard.)

Changed in apturl:
assignee: nobody → mvo
Martin Pitt (pitti) wrote :

Milestoned release blocker, needs assignee. Assigning to Michael for now.

FWIW, as a wishlist bug this shouldn't be a release blocker, and even less so a blocker for beta. Please adjust the priority or un-milestone accordingly.

Michael Vogt (mvo) on 2009-03-18
Changed in apturl (Ubuntu Jaunty):
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package software-properties - 0.71.3

software-properties (0.71.3) jaunty; urgency=low

  * fix combobox_server unicode for bug #102773
    (thanks to Savvas Radevic)
  * fix warning from 'import md5', thanks to Marco Rodrigues
  * softwareproperties/
    - if a entry is added that matches a known channel automatically
      add the right gpg signing key (LP: #328486)

 -- Michael Vogt <email address hidden> Wed, 18 Mar 2009 17:53:09 +0100

Changed in software-properties:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers