[01:23] <tgm4883> im having some trouble grasping the difference between a release and a milestone
[01:24] <tgm4883> it seems like if we wanted to have an alpha version of our project, would that be a milestone?
[01:25] <tgm4883> or would milestones only be used as a basis for when we want to have something done, and then make a release when we officially release the alpha
[02:05] <mthaddon> tgm4883: that's how I understand the difference (what you said last)
[02:06] <tgm4883> thanks mthaddon
[02:06] <tgm4883> i think were getting a little better organized now, instead of having every bug and blueprint all fall under 1 category
[02:10] <tgm4883> mthaddon, your a launchpad admin, correct?
[02:10] <mthaddon> yep
[02:11] <tgm4883> are launchpad admins only able to remove a release or series from a project?
[02:12] <tgm4883> we don't seem to be able to, we were trying a few different things and would like to remove some of these items as they are incorrect
[02:12] <mthaddon> I think the process is for you to file a new "question" here https://answers.launchpad.net/launchpad/+addquestion asking for it to be removed and then I can take care of it
[02:13] <tgm4883> ah
[02:13] <tgm4883> i'll go ahead and ask there, i have one more question if you have the time
[02:13] <mthaddon> sure
[02:14] <tgm4883> I noticed that launchpad also list distrobutions, is there a way to become a distrobution
[02:15] <mthaddon> I'm not sure what the best way to do that is - best to try and catch kiko when he's not afk and he should be able to help you
[02:15] <tgm4883> ah thank you
[02:16] <tgm4883> i will file that other question now
[02:16] <mthaddon> cool
[02:18] <tgm4883> the question is located here https://answers.launchpad.net/launchpad/+question/11188
[02:19] <mthaddon> cool, I should be able to get to that tomorrow - thx
[02:19] <tgm4883> thank you
[02:30] <kauai> hi, um.  I did something real stupid and committed a file I didn't want to... how can I remove it entirely?
[02:44] <kauai> anyone
[02:45] <tgm4883> kauai, you could ask the question here https://answers.launchpad.net/launchpad/+addquestion, thats where I had to ask to get a series removed from a project
[03:00] <kiko-afk> kauai, just bzr rm it and commit again?
[03:01] <kauai> yeah, but then it's still visible in the old revisions right?
[03:01] <kauai> I want it removed forever
[03:01] <kauai> is this possible?
[03:01] <Spads> perhaps uncommit?
[03:02] <kauai> Spads, thanks, I will look into it... sorry all of this is all new to me
[03:03] <Spads> kauai: #bzr may be a better place to ask questions like this
[03:03] <kiko-afk> uncommit and then push, yeah
[03:05] <kiko-afk> RAOF, seems like it goes to sleep every time this time? :)
[03:05] <kiko-afk> cprov-out, you know what's up?
[03:05] <RAOF> I've got some queued builds, and the buildds are idle, but there's no building happening :)
[03:06] <kiko-afk> I wonder why this is happening. did you write to launchpad-users cc: cprov RAOF?
[03:06] <RAOF> kiko-afk: No, actually.  This is a new problem, the other one got resolved :)
[03:06] <kiko-afk> RAOF, what was it yesterday?
[03:07] <RAOF> kiko-afk: The builds weren't queuing.
[03:07] <RAOF> Now a new package is queued, but isn't being sent to the buildd.
[03:08] <kiko-afk> how was it solved?
[03:09] <RAOF> I'm not sure, actually.  It just started working again.
[03:09] <RAOF> I hadn't got around to writing the lp email, and it got fixed before I did.
[03:11] <kiko-afk> odd.
[03:11] <kiko-afk> it sounds to me like a similar problem
[03:21] <cprov-out> RAOF: dogfood is back on track again 
[03:22] <cprov-out> RAOF: sorry for the inconvenience.
[03:23] <RAOF> cprov-out: That's ok.  Beta code, testing, it's hardly mission critical :)
[03:23] <RAOF> cprov-out: Thanks :)
[03:24] <cprov-out> RAOF: the problem is not the PPA code, since yesterday we have other parts under test in the same environment.
[03:25] <RAOF> Oh?  What is/was the problem?
[03:27] <cprov-out> RAOF: builders were configured to only build packages target to ubuntu primary archive, not PPAs (Trusted/Untrusted builder state)
[03:27] <RAOF> Oh, whoops :)
[03:28] <cprov-out> https://dogfood.launchpad.net/+builds/rubidium/, for instance (letf portlet)
[03:29] <cprov-out> RAOF: yes, big whoops. You are more than welcome to ping me if anything strange is happening with PPA-beta, I will be able to help you.
[03:30] <RAOF> cprov-out: Thanks.  Do you prefer here or lp-users ML?
[03:31] <cprov-out> RAOF: whatever suits better to you, usually IRC is faster than email, but some question should fit better in the ML
[03:31] <RAOF> Fair enough.  Now, to fix my nouveau build.  I suck :)
[03:31] <cprov-out> RAOF: looking forward to see "Nouveau Xorg driver" coming out of PPA :)
[03:31] <RAOF> Thanks again
[03:32] <cprov-out> g'night, guys
[04:14] <_Poseidon_> Good evening
[05:40] <jkakar> Where do I find the link to create a new milestone for a project?
[08:25] <ubotu> New bug: #131231 in malone "Timeout is occurring frequently with "short" queries" [Undecided,New]  https://launchpad.net/bugs/131231
[08:57] <carlos> morning
[08:59] <Hobbsee_> morning carlos!
[09:18] <Kuhrscher> carlos, danilos: Good morning. I just noticed that dolphin is not translateable via Launchpad, although it is in "main".
[09:19] <Kuhrscher> carlos, danilos: This is propabably not correct ;-)
[09:19] <Hobbsee> you should probably check the upstream kde translation for that
[09:20] <Hobbsee> why translate it only for kubuntu?
[09:20] <Kuhrscher> It is translated upstream ;-)
[09:20] <Kuhrscher> The translation is only missing for Ubuntu ;-)
[09:21] <Kuhrscher> If an app is in "main" it gets its translations via the langpacks generated from Rosetta or there won't be any translation.
[09:23] <Kuhrscher> Hobbsee: Dolphin's upstream translations did not find their way to Rosetta, so they are missing just for Kubuntu. For other distributions everything is alright.
[09:23] <Kuhrscher> Hobbsee: But generally you are absolutely right :)
[09:23] <Hobbsee> ah right.  i wonder why they didnt
[09:24] <danilos> carlos, Kuhrscher: it seems to be due to dolphin rename to d3lphin
[09:24] <carlos> danilos: I got the unapproved .pot files
[09:24] <carlos> Kuhrscher: thanks for the warning
[09:25] <Kuhrscher> carlos, No problem. Thanks for your quick response.
[09:27] <Kuhrscher> Hobbsee: There is also they way around. KMplayer switched from main to universe. Before it got its translations via the langpacks generated from the Rosetta translations. Now it _should_ use just the packaged upstream translations, but these are missing in the Ubuntu package. So KMplayer is untranslated for now, but only in Kubuntu. I filed a bug about this issue some month ago...
[09:28] <Hobbsee> Kuhrscher: bug #?
[09:28] <Kuhrscher> https://bugs.launchpad.net/bugs/123544
[09:28] <ubotu> Launchpad bug 123544 in kmplayer "Kmplayer Package does not contain translations" [Undecided,New]  
[09:30] <carlos> Kuhrscher: the only solution for that is a package rebuild
[09:31] <Hobbsee> carlos: just that?  no need to remove the "export stuff to rosetta" stuff?
[09:32] <Kuhrscher> carlos, Hobbsee: The mplayer entries are still in Rosetta...
[09:32] <carlos> Hobbsee: well.. that's also something interesting to do, but not a must to get it using directly what comes from the package itself
[09:32] <Hobbsee> carlos: right.  so there's no net loss in leaving that stuff in there?
[09:33] <carlos> well, removing it helps that translators focus on useful information
[09:34] <Kuhrscher> carlos, Hobbsee: I just hope it will get its package rebuild with included translations before the release of Gutsy ;-)
[09:34] <carlos> Kuhrscher: I see kmplayer as still being in main
[09:34] <carlos> in fact
[09:35] <carlos> it was moved back from universe to main 4 days ago
[09:35] <carlos> https://launchpad.net/ubuntu//+source/kmplayer/
[09:35] <Kuhrscher> Ahh, right
[09:35] <Kuhrscher> I didn't checked that again.
[09:35] <Hobbsee> carlos: wonder why it got demoted, then.
[09:36] <Kuhrscher> Ok, so this issue should be fixed with the next langpack, right?
[09:36] <carlos> Kuhrscher: yes, next language pack rebuild should include its translations again
[09:36] <carlos> Kuhrscher: it should be a base rebuild
[09:37] <Hobbsee> carlos: just checking - so kmplayer, etc, doesnt need to be touched?
[09:37] <carlos> Hobbsee: what do you mean about 'doesn't need to be touched' ?
[09:37] <carlos> rebuilt? or translated?
[09:37] <Hobbsee> carlos: rebuilt, sorry
[09:37] <carlos> Hobbsee: no, no need to rebuild it again
[09:37] <Hobbsee> great )
[09:38] <Kuhrscher> Ok, thank you everybody :)
[09:38] <carlos> Kuhrscher: you are welcome
[09:39] <RAOF> cprov-ZzZ: For your enjoyment when you awake, try !nouveau :)
[10:59] <head_victim> I'm having problems importing a pgp key into launchpad. It keeps telling me it cannot import it and tells me to check 3 things. I have done everything as it suggests and I even query the database and it's been there over 12 hours. Is this long enough or should I just wait to see if it works tomorrow?
[11:31] <ubotu> New bug: #131258 in malone "Pagetests should use the test browser" [Undecided,New]  https://launchpad.net/bugs/131258
[11:44] <Hobbsee> mrevell: OOPS-586D1018
[11:44] <ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/586D1018
[11:45] <mrevell> Hobbsee: Thanks :) I'm still getting an error on that so I'll check it.
[11:45] <Hobbsee> mrevell: it's basically from searching for a word on a list of bugs.
[11:46] <Hobbsee> mrevell: the URL in particular for that is https://bugs.launchpad.net/~gothicx/?field.searchtext=sync&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[11:46] <Hobbsee> but i assume you can see that
[11:46] <mrevell> head_victim: Apologies for not spotting your question earlier. Let me see if I can get some help for you.
[11:48] <mrevell> Hobbsee: List of bugs such as https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[11:51] <head_victim> Thats ok, I've never played with keys much before and I'm pretty sure I've done everything exactly as described. It does say it can take up to an hour or so to make sure it's mirrored correctly but it's been a lot longer than that.
[11:53] <Hobbsee> mrevell: i cant seem to make that one oops
[11:54] <mrevell> head_victim: Another user had a similar problem last week and one of the LP developers had to manually fix insert the user's key. It looks as though the person I need to speak to (who is in Brazil) isn't online yet. I'll ping him when he comes online. What's your LP username?
[11:55] <mrevell> Hobbsee: Hmm. So, the problem is that when you have a list of bugs and perform a search within that list, sometimes you get an OOPS? Is there a bug report yet?
[11:55] <Hobbsee> mrevell: correct, and no idea.  i havent filed one
[11:55] <mrevell> Hobbsee: Okay, thanks. How many bug lists have you found this problem on? Just the gothicx one above or on others?
[11:56] <head_victim> mrevell, Jared Norris is the display name.
[11:56] <Hobbsee> mrevell: various others. unfortunately, i didnt keep the oops numbers.  various others are having this too
[11:56] <mrevell> Hobbsee: Sorry that you're experiencing the problem. Thanks for letting me know. I shall file a bug and raise it in today's meeting. Cheers :)
[11:57] <Hobbsee> mrevell: thanks
[11:57] <mrevell> head_victim: Thanks. I'll email my colleague and ask him to take a look. He may contact you directly, his name is salgado.
[11:57] <head_victim> No worries, should I idle in here or is it enough that I am in other channels on the network?
[12:08] <mrevell> head_victim: If you could private message me with your email address, I'll get back to you using that, so you don't have to wait around here.
[12:09] <head_victim> mrevell, thank you for your assistance tonight it has been appreciated.
[12:10] <mrevell> head_victim: No problem :)
[12:36] <Hobbsee> mrevell: i must be a muppet.
[12:36] <Hobbsee> mrevell: surely, i must be a muppet.  launchpad wouldnt do this
[12:36] <Hobbsee> mrevell: to prove my muppetry, please tell me where the "view the bugs" sectoin is on https://bugs.launchpad.net/ubuntu-winfoss/
[12:37] <mrevell> Hobbsee: You press the "Search" button with an empty search box and it shows you all the related bugs 
[12:38] <mrevell> Hobbsee: Why do you think you're a muppet? :)
[12:38] <Hobbsee> mrevell: because i didnt think that launchpad could possibly have hidden the "view the bugs" button.  i knew i probably wasnt finding it
[12:39] <BjornT> Hobbsee: or, you look at the right, and click on "List all open bugs", which is right above the "Report a bug" button.
[12:39] <Hobbsee> mrevell: can i just say that that's *really* not intuitave.
[12:39] <Hobbsee> ohhhhhh....there it is
[12:39] <Hobbsee> that's moved
[12:39] <mrevell> BjornT: I wonder if that link could be more prominent. Perhaps a button. What do you think?
[12:39] <Hobbsee> mrevell: why is that right beneath, and in the same section as, the summary of bugs?
[12:40] <mrevell> Hobbsee: I don't know the exact reason but I can find out.
[12:40] <Hobbsee> the attention there is on report a bug or ask a question - there really should be a "view the bugs", or something button there
[12:46] <BjornT> mrevell: i don't think a button is good to use here, since it's not really an action. maybe rename the "Search" button to make it more obvious that you don't have to enter a search string, or something.
[12:47] <BjornT> Hobbsee, mrevell: mpt can probably tell you why the 'list all open bugs' link was moved.
[12:48] <mrevell> BjornT: My expectation would be to see the bug list when you visit that page by default, without having to click anything. The fact that there isn't a button to list all open bugs means that the option is almost hidden behind the prominence of the "Report a bug" and "Ask a question" buttons.
[12:48] <Hobbsee> BjornT: if people who have used LP for ages, and are fairly fluent in LPesque cant find simple things like how to view bugs, then clearly your approach is wrong.  new users arent going to have a hope in hell of finding them.
[12:49] <Hobbsee> mrevell: yes, it does promote the idea of "report bugs without searching"
[12:49] <Hobbsee> i'm not sure why they're saying "report a bug" first -because clearly you should search before you report
[12:51] <BjornT> Hobbsee: well, i think one reason for you not finding the link, is that you expected the link to be somewhere else, and you didn't expect it to have been moved to that place.
[12:51] <BjornT> Hobbsee: although, i do agree that the link should be more prominent
[12:52] <Hobbsee> BjornT: this is true
[12:52] <Hobbsee> BjornT: i then and went and looked for a likely looking link, and found nothing.
[12:52] <pcardune> (somewhat OT) speaking of bugs, I'm looking for a way to put in the "fix committed" message a link to the precise revision in which the fix was committed.  I like Trac's "r78" syntax.  I looked for this feature in LP but could not find it?  
[12:54] <mwhudson> pcardune: you mean a codebrowse link?
[12:55] <pcardune> mwhudson: yes... it might be nice to have src:branchname:revnumber or something to that effect
[12:57] <mwhudson> what would be even nicer is bzr ci --fixes support
[12:58] <mwhudson> so that when a revision that has been annotated to be fixing a bug gets merged into trunk, the bug automatically flips over into "fix committed" and a link added
[12:59] <mwhudson> there is work towards this sort of thing being done
[01:00] <pcardune> that would really be quite awesome indeed.  But still I there should be a way to link easily to something that has already been committed.  In case you forget to use --fixes
[01:01] <mwhudson> yes
[01:01] <mwhudson> file a bug? :)
[01:01] <mwhudson> i'm not aware of any existing bugs like this
[01:02] <pcardune> ok, will do
[01:02] <pcardune> I just wanted to see if it was yet another "undocumented" feature (those pop up every now and then)
[01:25] <ubotu> New bug: #131279 in launchpad "Easily link to codebrowse interface from bug reports" [Undecided,New]  https://launchpad.net/bugs/131279
[03:02] <mrevell> Hobbsee: ping
[03:02] <Hobbsee> mrevell: pong
[03:03] <mrevell> hey Hobbsee - I've just tried that bug search again and it seems to be working to me.
[03:05] <Hobbsee> mrevell: hmm.  seems it only doesnt work some of the time
[03:05] <Hobbsee> mrevell: i cant reproduce it now, either, but i have been able to earlier...
[03:05] <Hobbsee> mrevell: we didnt have a code change, have we?
[03:05] <Hobbsee> (seems like a random thing)
[03:06] <mrevell> Hobbsee: Yeah, me too. I'll report nonetheless. I can't see any cherrypicks that fix it, so AFAIK nothing has changed that could fix this between when we were talking earlier and now.
[03:08] <Hobbsee> mrevell: right
[03:21] <mrevell> Hobbsee: How long has the bug search problem been around?
[03:22] <Hobbsee> mrevell: couple of weeks, maybe?
[03:22] <mrevell> Hobbsee: thanks
[03:23] <mrevell> Hobbsee: bug 131299
[03:23] <ubotu> Launchpad bug 131299 in malone "Searching from a user's bug page sometimes results in an OOPS" [Undecided,New]  https://launchpad.net/bugs/131299
[03:31] <ubotu> New bug: #131299 in malone "Searching from a user's bug page sometimes results in an OOPS" [Undecided,New]  https://launchpad.net/bugs/131299
[03:56] <mwhudson> m
[03:56] <gmb> mwhudson: mmm?
[03:57] <mwhudson> i wonder if i have time to make coffee before the meeting gets going...
[03:57] <gmb> Better get started.
[04:00] <SteveA> Hello!
[04:00] <SteveA> Welcome to this week's Launchpad development meeting.
[04:00] <SteveA> For the next 45 minutes or so, we'll be coordinating about Launchpad development.
[04:00] <SteveA> Who is here today?
[04:00] <bigjools> me
[04:00] <jtv> me
[04:00] <intellectronica> me
[04:00] <EdwinGrubbs> me
[04:00] <gmb> me
[04:00] <mpt> me
[04:00] <BjornT> me
[04:00] <adeuring> me
[04:00] <ddaa> me
[04:00] <mrevell> me
[04:00] <SteveA>  - Barry sends apologies.
[04:00] <bac> me
[04:00] <jsk> me
[04:00] <schwuk> me
[04:00] <sinzui> me
[04:01] <danilos> me
[04:01] <salgado> me
[04:01] <mthaddon> me
[04:01] <mwhudson> me
[04:01] <danilos> carlos: you?
[04:01] <cprov> me
[04:01] <matsubara> me
[04:01] <carlos> me
[04:02] <stub> me
[04:02] <Rinchen> me
[04:02] <SteveA> anyone see a team-mate missing?
[04:02] <BjornT> allenap: ping - meeting time
[04:02] <allenap> me
[04:02] <statik> me
[04:03] <allenap> BjornT: thanks
[04:03] <jamesh> me
[04:03] <SteveA> == Agenda ==
[04:03] <SteveA>  * Roll call
[04:03] <SteveA>  * Agenda
[04:03] <SteveA>  * Next meeting
[04:03] <SteveA>  * Actions from last meeting
[04:03] <SteveA>  * Oops report (Matsubara)
[04:03] <SteveA>  * Critical Bugs (Rinchen)
[04:03] <SteveA>  * Bug tags
[04:03] <SteveA>  * Operations report (mthaddon)
[04:03] <SteveA>  * DBA report (stub)
[04:04] <SteveA>  * Sysadmin requests (Rinchen)
[04:04] <SteveA>  * A top user-affecting issue (mrevell)
[04:04] <SteveA> ----
[04:04] <SteveA>  (other items)
[04:04] <SteveA> ----
[04:04] <SteveA>  * Blockers
[04:04] <SteveA> 
[04:04] <SteveA> Next meeting: same time next week please.
[04:04] <SteveA> Anyone know in advance that they'll be unable to be at that meeting?
[04:04] <kiko-zzz> me
[04:04] <BjornT> i won't attend next week's meeting
[04:04] <SteveA> kiko: you won't be at teh meeting? or you're belatedly here?
[04:04] <kiko> I'm belatedly here
[04:04] <SteveA> cool
[04:05] <SteveA>  * Actions from last meeting
[04:05] <SteveA> there were no actions
[04:05] <SteveA>  * Oops report (Matsubara)
[04:05] <matsubara> Today's oops report is about bug 131299
[04:05] <ubotu> Launchpad bug 131299 in malone "Searching from a user's bug page sometimes results in an OOPS" [Undecided,New]  https://launchpad.net/bugs/131299
[04:05] <kiko> is this a performance oops, matsubara?
[04:05] <kiko> BjornT, so, I'm REALLY concerned that +bugs is timing out all over the shop
[04:06] <matsubara> kiko: seems so
[04:06] <kiko> BjornT, the interesting this is that this ties in to bigjools message this morning :)
[04:06] <mpt> I get bug search timeouts fairly often, not just from person pages
[04:06] <mwhudson> me too
[04:06] <kiko> same here
[04:06] <matsubara> I'm running some explain analyze on staging and the offending query is taking a long time
[04:06] <kiko> this did not happen two cycles ago
[04:06] <kiko> so what's happening
[04:06] <SteveA> is this a side-effect of switching back to the old index implementation?
[04:06] <mwhudson> well, we changed indexes this weekend, is that part of it?
[04:06] <kiko> I don't /think/ so
[04:07] <BjornT> kiko: me too. i'll take a look at it today to see if i can find something obvious.
[04:07] <kiko> does anyone know if it's a too-many-queries or a too-expensive-query problem?
[04:07] <SteveA> so... I want to take a step back for a minute
[04:07] <BjornT> kiko: it's a too-expensive-query problem
[04:07] <kiko> BjornT, I can spend some time trying later today too, so send your findings and I can help continue
[04:07] <danilos> in my tests (not directly related to this), gin indexes proved to be 2-3 times faster than gist indexes on FTI fields
[04:07] <matsubara> the oopses shows a too expensive query
[04:07] <SteveA> when we get timeout OOPS reports, what do we do about it?
[04:08] <SteveA> how do we investigate it
[04:08] <danilos> jtv, now is the time for you to chip in ;)
[04:08] <SteveA> I have a feeling, (and this is just an impression,) that we kind of invent how we approach this afresh, each time we get a critical OOPS that isn't a Rosetta OOPS
[04:08] <SteveA> the Rosetta ones being a longer-term issue
[04:08] <jtv> danilos: do I _look_ like a database person?
[04:09] <danilos> jtv: no, but you are the one who has most recently worked on those sorts of problems, afaik
[04:09] <SteveA> jtv: I appreciate your insightful comments whenever database issues come up on the mailing list
[04:09] <SteveA> so, perhaps a few of us can get together after this meeting
[04:09] <SteveA> and work out how best to approach this kind of OOPS
[04:09] <SteveA> so that we'll have a good system for it, and for knowing our options, when the next one comes up
[04:10] <kiko> okay
[04:10] <kiko> sounds good
[04:10] <jtv> ack
[04:10] <SteveA> BjornT, jtv, stub, jamesh, me... kiko if you're interested
[04:10] <jamesh> okay
[04:10] <SteveA> and I'd like mthaddon to contribute too
[04:10] <mthaddon> ok
[04:10] <kiko> I am interested
[04:11] <SteveA> we can use the slot after this meeting, normally reserved for an infrastructure team conf call
[04:11] <BjornT> sure
[04:11] <SteveA> Rinchen: I'll discuss the outcome of this with you after the meeting.  You needn't be there, as I'm sure you have lots and lots of other things to do :-)
[04:12] <Rinchen> Great and many thanks :-) 
[04:12] <SteveA> matsubara: back to you.  thanks for letting me interrupt.
[04:12] <bigjools> BjornT: we'll have to change the time for our call then
[04:12] <matsubara> SteveA: actually that's the only oops, so back to you again. :-) thanks!
[04:12] <SteveA> matsubara: okay.  although I saw many rosetta oopses, as usual.
[04:13] <BjornT> bigjools: yes, let's aim for 1600 UTC?
[04:13] <bigjools> BjornT: +1
[04:13] <matsubara> that's already known. no point bring it up again. jtv is on it.
[04:13] <SteveA> do we have a list of "unfortunately expected" rosetta oopses, and the quantity we expect them in?
[04:13] <jtv> SteveA: I keep track, it's a short list
[04:14] <SteveA> jtv: please put something up on a wiki page, when convenient
[04:14] <SteveA> matsubara: done, thanks
[04:14] <kiko> pizza is thicker than blood
[04:14] <jtv> SteveA: ok
[04:14] <SteveA>  * Critical Bugs (Rinchen)
[04:14] <Rinchen> Howdy. Two for today: carlos, status for Bug 56820 please.  Also, Bug 131043 is unassigned. SteveA did you intend jamesh to take this one on?
[04:14] <ubotu> Launchpad bug 56820 in rosetta "Po export script is not robust enough" [Critical,Confirmed]  https://launchpad.net/bugs/56820 - Assigned to Carlos Perell Marn (carlos)
[04:14] <ubotu> Launchpad bug 131043 in launchpad "database adapter serialisation tests disabled" [Critical,Confirmed]  https://launchpad.net/bugs/131043
[04:14] <bigjools> pizza is tastier than blood
[04:14] <stub> stop making me hungry you twats
[04:15] <carlos> Rinchen: hmm, we are supposed to change the that priority to high
[04:15] <kiko> Rinchen, thanks for pointing out the export script oops. that's one which is really awful
[04:15] <jtv> stub: come on, it's Ronny's, just around the corner from you & you can even order in Dutch
[04:15] <carlos> s/the that/that/
[04:15] <kiko> I'm inclined to even keep it at critical to make it get fixed
[04:15] <kiko> I mean, us only finding out it's broken because tom fished it out of -error-reports?
[04:15] <carlos> kiko: that's a different oops
[04:16] <jamesh> Rinchen: it isn't clear how to fix bug 131043 -- by my understanding, the root cause is a design fault in psycopg1
[04:16] <ubotu> Launchpad bug 131043 in launchpad "database adapter serialisation tests disabled" [Critical,Confirmed]  https://launchpad.net/bugs/131043
[04:16] <kiko> is it?
[04:16] <stub> That is sort of tom's job - monitoring that stuff
[04:16] <carlos> kiko: yes
[04:16] <kiko> stub, I kinda expect developers to monitor /their/ parts of production.
[04:16] <stub> And the monitoring picked it up (yay)
[04:16] <matsubara> kiko: no, we found out because the script monitoring alerted us.
[04:16] <kiko> -error-reports isn't really a very good monitoring facility
[04:16] <mpt> kiko, a bug's scheduling may depend on its importance, but its importance does not depend on it scheduling :-)
[04:16] <kiko> heh
[04:16] <SteveA> jamesh: should we switch to psycopg2?
[04:17] <carlos> kiko: although I agree that the other oops should be fixed, but it depends on danilo, jeroen or me doing a bad approval so it's not so critical (but important, yes)
[04:17] <kiko> good point
[04:17] <kiko> carlos, the fact that the whole script blows up is pretty bad, isn't it?
[04:17] <SteveA> jamesh: please put your thoughts about what the root cause is as a comment in that bug report
[04:17] <carlos> kiko: indeed, we already talked about move to use OOPs infrastructure for scripts during the sprint in Alicante
[04:17] <kiko> nice!
[04:17] <jamesh> SteveA: the problem appears to exist in psycopg2 as well, but should be a lot easier to fix there.
[04:17] <jamesh> SteveA: I'll add my analysis
[04:18] <SteveA> jamesh: does the author of psycopg2 know about the problem?
[04:18] <Rinchen> kiko, are you ok with us downgrading that to High but having carlos attempt to fix it during this current cycle? 
[04:18] <stub> I  think we should switch to psycopg2 on the storm branch. psycopg1 is no longer maintained (well... apart from the patches Ubuntu devs do)
[04:18] <SteveA> is there a bug we can link to in their bug tracker?
[04:18] <jamesh> SteveA: I filed a bug report about it, but have not had a response from him yet
[04:18] <SteveA> is there a linnk to that bug report in our launchpad bug?
[04:18] <statik> jamesh: I haven't heard any response about the psycopg2 bug I filed either, I was wondering if upstream is alive
[04:18] <jamesh> I'll link the bug too
[04:19] <SteveA> thanks
[04:19] <Rinchen> kiko, are you ok with us downgrading that to High but having carlos attempt to fix it during this current cycle? 
[04:19] <kiko> yes
[04:19] <Rinchen> thanks
[04:19] <jamesh> statik: yeah.  there hasn't been any activity in SVN since the 2.0.6 release
[04:20] <kiko> (Rinchen, I am overreacting. it's not the end of the world)
[04:20] <SteveA> jamesh: is the test that intermittently fails due to that bug diabled ?
[04:20] <jtv> Rinchen: this current cycle is "tomorrow," no?
[04:20] <Rinchen> SteveA, we still need an owner for that bug.  Seems jamesh might be the right person. Do you agree?
[04:20] <jamesh> SteveA: yes
[04:20] <kiko> it's not only disabled, it's diabled!
[04:20] <SteveA> jamesh: ok.  is the launchpad bug referenced in the text to the diabled bug?
[04:20] <jamesh> SteveA: yes
[04:20] <Rinchen> jtv, yes that's a very good point. 
[04:20] <SteveA> jamesh: great, thanks
[04:21] <jtv> and carlos isn't exactly picknicking right now...
[04:21] <jamesh> SteveA: actually, the bug reference is next to the place where the bug was disabled rather than in the doctest itself
[04:21] <kiko> Rinchen, jtv: not if it's a critical bugfix
[04:21] <kiko> it can be done later. but it can't be big.
[04:21] <jtv> and it can't be "High"..?
[04:21] <kiko> the test was diabled, not the bug
[04:22] <carlos> right, it should be a fast fix
[04:22] <SteveA> the whole doctest was diabled, and not just the failing portion of it?
[04:22] <Rinchen> carlos, jtv - go a head an downgrade it to HIGH but please attempt to get the fix out quickly
[04:22] <mwhudson> i think the failing portion was copied to a new file and that file disabled
[04:22] <Rinchen> yikes... "go ahead and" 
[04:22] <carlos> Rinchen: ok
[04:22] <kiko> SteveA, yeah, I'm not sure why jamesh did that.
[04:23] <jamesh> SteveA: I moved the failing portion into its own doctest, since it was doctest it was in had grown a fair bit
[04:23] <kiko> mpt, you ignore me.
[04:23] <mpt> what?
[04:23] <kiko> mpt, what what?
[04:23] <mpt> I ignore you when?
[04:23] <jamesh> I didn't disable unrelated tests
[04:23] <SteveA> ok, you performed bug chiropody on an ingrown doctest
[04:23] <kiko> mpt, when I privmsg.
[04:24] <mpt> kiko, ah, apparently I'm unregistered
[04:24] <SteveA> freenode is lame like that
[04:25] <stub> But you don't need to privmsg using freenode, and probably shouldn't...
[04:25] <jtv> statik: no, not while you're recovering
[04:25] <SteveA> I asked that NickServ would actually talk to you, privmsg, to say "your message isnt' being delivered because..."
[04:25] <SteveA> instead, there's just some server message that most irc clients don't show prominently at all
[04:25] <kiko> SteveA, I think it does but you can't have a server tab or it goes there
[04:25] <mpt> It's not confidential, just personal, and anyway, problem solved
[04:26] <mpt> Sorry for disturbing the meeting
[04:26] <kiko> exactly
[04:26] <kiko> what mpt said
[04:26] <SteveA> kiko: I meant a proper /msg from nickserv.  it does it on other occassions, so the code is there.
[04:26] <kiko> yeah
[04:26] <kiko> what's next?
[04:27] <SteveA> Rinchen: done with bugs?
[04:27] <SteveA>  * Bug tags
[04:27] <SteveA> none proposed
[04:27] <Rinchen> SteveA, yes thanks
[04:27] <SteveA>  * Operations report (mthaddon)
[04:27] <mthaddon> edge is now using the devel branch
[04:27] <mthaddon> bzr 0.18 has been upgraded
[04:27] <mthaddon> will be working on adding loggerhead into RF today
[04:27] <kiko> mthaddon, you rock! but what about edge-redirects?
[04:27] <mthaddon> that's it from me for the moment unless there are any questions
[04:28] <kiko> I am unhappy that that didn't get done this week
[04:28] <kiko> not really unhappy but say 60%
[04:28] <mthaddon> kiko: been delayed a bit since we decided to switch the branch we're using, but the week's not over yet
[04:28] <mthaddon> kiko: we have to change the branch that's being synchronized to all the production servers
[04:28] <mthaddon> I have an RT ticket in to do that
[04:28] <kiko> mthaddon, oh, sorry, the branch switching was much lower priority than the auto-redirect
[04:29] <kiko> maybe we can delay that?
[04:29] <SteveA> I don't see daily oops summaries about edge.
[04:29] <SteveA> am I missing something?
[04:29] <kiko> I didn't mean to imly it was urgent
[04:29] <matsubara> I can arrange that
[04:29] <stub> You don't need to change the branch that is being synced - you could just change the job that builds rocketfuel-built/edge to use launchpad/devel instead of the edge branch
[04:29] <mthaddon> kiko: but we can't auto-redirect until we move edge off asuka, so it's all part of the app server reconfig project
[04:30] <SteveA> you mean we can't auto-redirect cos we're worried about load?
[04:30] <mthaddon> stub: I did think about doing that, but it was decided that we wanted to use devel itself, not overwrite edge with devel
[04:30] <SteveA> I thought we'd done a day or week's test of that
[04:30] <SteveA> and it was fine
[04:30] <mthaddon> SteveA: yes
[04:30] <kiko> SteveA, a day's test and it was, tbh
[04:30] <kiko> but..
[04:30] <SteveA> I still think we should reconfigure the app servers
[04:30] <SteveA> but it needn't block continuing to use edge on asuka
[04:31] <kiko> what do people think?
[04:31] <mthaddon> ok, if you're okay with it, I can set up the edge redirect and continue working on app server reconfig
[04:31] <SteveA> I don't really know everything that's involved, so I don't want to make a lot of extra work for people
[04:31] <stub> asuka becomes unusable for a couple of hours a day when staging is rebuilding
[04:31] <stub> So I'd be -1
[04:32] <mthaddon> yeah, that was my main concern - DB rebuild on asuka really slows things down
[04:32] <SteveA> do we need staging to rebuild every day?
[04:32] <kiko> mthaddon, how's the reconfig looking?
[04:32] <kiko> I mean, will it be done by tomorrow?
[04:32] <kiko> (no pressure, just a question)
[04:32] <SteveA> maybe we can stop staging rebuilding until we finish the reconfiguration
[04:32] <danilos> I'd love to have staging available for testing rollouts
[04:33] <mthaddon> kiko: just need the devel code sync-ed to the production servers so I can set up edge (that's the first stage) - the entire project won't be done by the end of the week
[04:33] <stub> We need staging rebuilding every day during db thaw. Other than that probably not.
[04:33] <mthaddon> kiko: but I'll see what I can do about getting it done for the edge setup by the end of the week
[04:34] <kiko> okay
[04:34] <SteveA> ok, all done
[04:34] <SteveA> ?
[04:34] <kiko> let's talk again tomorrow mthaddon 
[04:34] <mthaddon> kiko: sure
[04:34] <kiko> thanks.
[04:34] <SteveA> thanks mthaddon 
[04:34] <SteveA>  * DBA report (stub)
[04:34] <stub> DB patch review call with Mark has been rescheduled for tomorrow, so there may be some hope for people who tried to sneak their branches in after the deadline.
[04:34] <stub> Downtime on Sunday went smoothly.
[04:34] <stub> Nothing else to report.
[04:34] <SteveA> thanks stub 
[04:35] <SteveA>  * Sysadmin requests (Rinchen)
[04:35] <Rinchen> matsubara, I haven't seen any status on your rt ticket. I've given the requisite amount of time for it's completion so I'll attempt to get that closed this week on your behalf.
[04:35] <Rinchen> Anyone else blocked on RT tickets?
[04:35] <kiko> hang on
[04:35] <SteveA> kiko: after Rinchen's item is finished
[04:35] <kiko> stub, the last time we did some DB maintenence the number of OOPSes went down a lot
[04:35] <matsubara> thanks Rinchen. I've received your email about the time constraint.
[04:35] <kiko> I am curious as to why this didn't happen this time
[04:35] <kiko> SteveA, you have to wait for people to ask questions or else it's not a meeting :)
[04:35] <danilos> kiko: wasn't that gist -> gin, and now reverse, gin -> gist
[04:35] <jtv> kiko: in rosetta's case, a performance regression that had been held up because staging wasn't rebuilding
[04:36] <stub> kiko: Last time we did DB maintenance we did it because we had massive bloat in one particular table that was causing a lot of OOPSes.
[04:36] <jtv> kiko: nm, that's staging, sorry
[04:36] <kiko> danilos, no, I am referring to something we did a year ago to improve bug search performance
[04:36] <kiko> stub, that's correct
[04:36] <kiko> stub, and there was no bloating this time?
[04:36] <mwhudson> Rinchen: jml is waiting on 28580
[04:36] <Rinchen> thank mwhudson I'll go after that as well
[04:36] <SteveA> kiko: the bloat was caused by bad start-up code in launchpad
[04:36] <stub> kiko: Not much bloat. Bloat on the POMsgSet table was the worst, so things might have improved on the Rosetta end if bloat was an issue.
[04:36] <SteveA> kiko: stub fixed that code
[04:37] <kiko> really?
[04:37] <stub> kiko: Although I suspect bloat not an issue in that particular case (as the table would have still been generally packed, just bloated with a load of unused space at one end)
[04:37] <kiko> are SteveA and stub talking about the same thing? :)
[04:37] <danilos> doesn't sound like it, no :)
[04:38] <kiko> stub, thanks.
[04:38] <kiko> okay that clears up my questions
[04:38] <stub> kiko: Elsewhere there was bloat, but just normal and I don't think it was a major contributer to OOPSes
[04:38] <SteveA> kiko: didn't know you cared ;-)
[04:38] <SteveA>  * A top user-affecting issue (mrevell)
[04:39] <mrevell> The user-affecting issue I was planning to talk about this week has already been discussed in Matsubara's OOPS report - i.e. the intermittment timeout problem when searching bugs. 
[04:39] <mrevell> I've reported this as bug 131299, as mentioned in Matsubara's OOPS report. 
[04:39] <ubotu> Launchpad bug 131299 in malone "Bug searches often time out" [High,Confirmed]  https://launchpad.net/bugs/131299
[04:39] <mrevell> I won't paste my original report, as it's all been covered already. However, I did want to ask if this problem is related to bug 107722.
[04:39] <ubotu> Launchpad bug 107722 in launchpad "Improve accuracy of database timeouts" [High,Fix released]  https://launchpad.net/bugs/107722 - Assigned to Stuart Bishop (stub)
[04:39] <mrevell> Apologies for the now redundant report; I didn't think it would get raised before my part of the meeting.
[04:39] <mrevell> Thank you, back to you SteveA.
[04:39] <kiko> hmmm
[04:40] <SteveA> could be related, in the sense that a request could take up to twice as long as it ought to have been able to
[04:40] <stub> It could be related. Previously pages could take up to timeout*2 seconds to actually timeout.
[04:40] <kiko> hmmmm
[04:40] <kiko> I see!
[04:40] <SteveA> nonetheless, the bug searches timing out is an issue now
[04:40] <kiko> we could try increasing time out times
[04:40] <kiko> has anyone considered that? or would it make the system unbearably slow?
[04:40] <SteveA> stub, mthaddon: what's the current hard timeout in production?
[04:41] <matsubara> SteveA: 25000 
[04:41] <SteveA> 25 seconds to service a web request
[04:41] <kiko> matsubara, will that fix many of the oopses, or not really?
[04:41] <SteveA> I'm -1 on making that longer
[04:41] <kiko> SteveA, we /are/ the nexus of open source activity. :)
[04:41] <SteveA> we should make it shorter if anything
[04:41] <jtv> We should fix the timeouts we have now, and _then_ make it shorter
[04:42] <matsubara> kiko: the queries I tried on staging took ~30s to complete. 
[04:42] <SteveA> we can try it for a couple of days though, moving it 10s each way
[04:42] <SteveA> and comparing results
[04:42] <SteveA> I have a feeling we may see counter intuitive things there
[04:43] <mpt> I thought we had a soft timeout to warn us when things are taking too long
[04:43] <mpt> in which case the hard timeout should be determined by our hardware and resulting ability to spend time on requests
[04:43] <SteveA> mpt: not as simple as that
[04:43] <SteveA> we have a certain amount of concurrency available
[04:44] <SteveA> (number of app threads per server * num servers)
[04:44] <kiko> mpt, I think soft timeouts only serve as a warning if we have zero hard timeouts :) 
[04:44] <SteveA> we have a certain amount of concurrency in the db server
[04:44] <jamesh> a long running request affects performance of other concurrent requests
[04:44] <mpt> SteveA, right, that's what I mean by "our hardware and resulting ability to spend time on requests"
[04:44] <SteveA> and that's to do with its number of processors and threads
[04:44] <SteveA> and reads vs writes in the database
[04:44] <SteveA> so, taking all that into account
[04:44] <stub> I think we can afford to increase the hard timeout from a load pov, but we need to do it gradually. Load on jubany is what we need to watch - not load on the appservers.
[04:45] <SteveA> we may actually get less hard timeouts by reducing the hard timeout, depending on exactly what kind of queries are at the root of a problem
[04:45] <SteveA> it's a non-linear problem
[04:45] <jtv> stub: cpu or i/o load?
[04:45] <stub> jtv: both
[04:45] <SteveA> stub: if we increase the timeout time, we should also increase concurrency
[04:45] <SteveA> by adding more threads per app server
[04:46] <jtv> ...which means more cache pressure
[04:46] <stub> I think we have more than enough threads, but I don't think I have an actual metric to back that up
[04:46] <SteveA> yep, checking memory on app servers and jubany
[04:46] <SteveA> stub: think how to get such a metric please
[04:46] <SteveA> anyway
[04:46] <SteveA> we're over time
[04:46] <SteveA> we have one more item
[04:46] <SteveA>  * Blockers
[04:46] <SteveA> please go ahead with team blockers
[04:46] <matsubara> EAM: infrastructure BLOCKED: no
[04:46] <jtv> TEAM: Translations BLOCKED: no
[04:46] <BjornT> TEAM: bug tracker BLOCKED: no
[04:46] <matsubara> TEAM: infrastructure BLOCKED: no
[04:46] <mpt> TEAM: UI BLOCKED: no
[04:46] <bigjools> TEAM Soyuz BLOCKED no
[04:46] <jsk> TEAM: Blueprint BLOCKED: no
[04:46] <stub> requests per second and average time to serve a request will give us that. I don't think we know average request time.
[04:46] <salgado> TEAM: Registry BLOCKED: no
[04:47] <sinzui> TEAM Answer Tracker: BLOCKED no
[04:47] <kiko> nobody blocked on me really?
[04:47] <bac> TEAM: Commercialization: BLOCKED no
[04:47] <ddaa> TEAM: Code BLOCKED: no
[04:47] <SteveA> stub: more like average transaction length
[04:47] <carlos> kiko: well, we are supposed to have a meeting with you since long time ago...
[04:47] <SteveA> stub: of which avg request length is an approximation.  maybe you can get transaction lengths from the db logs?
[04:47] <SteveA> no blockers
[04:47] <SteveA> yay
[04:47] <SteveA> thanks everyone
[04:47] <SteveA> MEETING ENDS
[04:47] <carlos> is that something to note in 'BLOCKED' ?
[04:48] <kiko> carlos, yes
[04:48] <kiko> if you are waiting on something from somebody else
[04:48] <kiko> then yes
[04:48] <carlos> kiko: ok, then we are blocked on agree our 1.1.8 tasks :-P
[04:48] <kiko> carlos, let's do that tomorrow first thing 
[04:48] <SteveA> meeting to discuss how we investigate hard timeout oopses in 12 mins please, on the hour
[04:48] <jtv> SteveA: where?
[04:48] <carlos> kiko: that's fine for me
[04:48] <carlos> danilos, jtv?
[04:48] <SteveA> starting on irc, moving to voice if we need to
[04:49] <jtv> carlos, kiko: what's that in UTC?
[04:49] <danilos> kiko: sure thing, by my standards
[04:49] <kiko> around this time UTC, or up to 2 hours earlier depending on the weather
[04:49] <kiko> oh hang on I might be on vacation tomorrow :)
[04:49] <carlos> kiko: ok, thanks
[04:49] <carlos> oh
[04:49] <danilos> jtv: it should be around 12:00-14:00 UTC, if I am guessing correctly
[04:49] <danilos> oh, I am :)
[04:49] <carlos> then, next week?
[04:50] <jtv> oh great
[04:50] <carlos> danilos: are you on vacation?
[04:50] <danilos> carlos: not that I remember, no
[04:50] <carlos> danilos: ok, so you are guessing well :-P
[04:50] <danilos> :)
[04:51] <jtv> so... when?
[04:51] <danilos> tomorrow around this time ;)
[04:51] <jtv> ah, that's better
[04:52] <kiko> jtv, danilos, carlos: if you will be around in 3h we can do it then
[04:52] <kiko> it may be more guaranteed than tomorrow
[04:52] <jtv> kiko: erm...
[04:53] <carlos> I think I could be around
[04:53] <danilos> kiko: I think I'll already be a mess in 3h
[04:53] <danilos> though, I can be around if everybody else's in
[04:53] <kiko> yeah, I expected so
[04:53] <kiko> danilos, carlos, jtv: tell you what. I'll review and I'll email you about it. how about that?
[04:54] <jtv> kiko: that covers _one_ of our questions...
[04:54] <danilos> kiko: no, no, emailing doesn't work... :)
[04:54] <kiko> is there anything you'd like me to consider specially that won't be self-evident?
[04:54] <kiko> heh
[04:54] <danilos> kiko: we've got several other things... so, in 3 hours time?
[04:54] <kiko> yes.
[04:54] <carlos> kiko: well, we would like to talk also about our next sprint and phase2 optimisations
[04:54] <kiko> if jtv can't make it it's okay
[04:54] <kiko> I realize it's a crack time
[04:54] <jtv> Sigh.  Okay, I'll be there.  Don't expect me to be sober.
[04:55] <kiko> okay, but don't hit the bottle
[04:55] <danilos> ok, great... kiko, don't try to run away, it's scheduled at 18:00 UTC today! :P
[04:56] <jtv> kiko: hah, 's long as the bottle don't hit me
[04:58] <jtv> kiko: "a crack time"?  'sposeta be craick time
[04:59] <kiko> aye
[05:42] <mikmor2> Could anyone tell me how to open up a page like this https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+subscribe for my project?
[05:43] <mikmor2> ie. I want people to be able to subscribe to bugs and answers in my project
[05:43] <mikmor2> Or do i have to create a maintained team...
[05:56] <kiko> mikmor2, what is your project?
[05:58] <mikmor2> kiko: https://launchpad.net/dru/
[05:58] <kiko> mikmor2, okay. 
[05:58] <kiko> mikmor2, you can specify an open team as your bug contact in the bugs tab
[05:58] <kiko> mikmor2, that way anyone can get bug notifications.
[05:59] <kiko> mikmor2, in the answers tab anyone can subscribe as an answer contact.
[05:59] <mikmor2> ok, i'll do that then. thanks!
[05:59] <kiko> you're welcome!
[06:13] <seb128> hi
[06:13] <seb128> is launchpad timeouting a lot on searches for some days a known issue?
[06:14] <Hobbsee> seb128: https://bugs.launchpad.net/bugs/131299
[06:14] <ubotu> Launchpad bug 131299 in malone "Bug searches often time out" [High,In progress]   - Assigned to Bjrn Tillenius (bjornt)
[06:14] <seb128> Hobbsee: thanks
[06:41] <kiko> Hobbsee, seb128: we're working on it -- I'm very concerned
[06:43] <seb128> kiko: thanks
[06:44] <Hobbsee> kiko: great
[06:51] <roshan_s> Can someone help me import my GPG key into my Launchpad account? I've published my key to keyserver.ubuntu.com, and I can query it fine, but entering the fingerprint into Launchpad says it couldn't import the key. I'm somewhat new to GPG, though I understand public-key cryptography
[06:54] <kiko> roshan_s, what's your key id
[06:55] <roshan_s> Is that the LSB of the fingerprint? It's this: 2BDF897D
[06:59] <kiko> roshan_s, yeah. I can see it is in fact there.
[07:00] <kiko> roshan_s, what happens when you go to add that key to your account?
[07:01] <roshan_s> kiko: I get this error: Launchpad could not import your OpenPGP key.     *  Did you enter your complete fingerprint correctly? A fingerprint is a long sequence of numbers and letters. You should use the output produced by the command: ...    * Have you published your key to a public key server? You can do that by by entering in a terminal:
[07:01] <roshan_s>           gpg --keyserver keyserver.ubuntu.com --send-keys 
[07:01] <roshan_s>     * Has your key been automatically mirrored to the Ubuntu key server? Keys sometimes take up to an hour to be synchronized between servers. You can check if it has by querying the Ubuntu key server directly. If it hasn't, you can publish directly to our server by entering in a terminal: ...
[07:03] <kiko> hmmmm
[07:03] <kiko> roshan_s, looks like a negative caching bug.
[07:03] <kiko> gar
[07:03] <kiko> matsubara-lunch, cprov-lunch: do any of you know how to cope with this?
[07:05] <roshan_s> kiko: If it helps, I published the key about 10 hours ago
[07:05] <kiko> cprov, his key /is/ on the keyserver, but I can't get to it from launchpad
[07:06] <cprov> roshan_s: your key ID, please ?
[07:06] <roshan_s> cprov: 2BDF897D
[07:08] <cprov> kiko: this key is not present in our internal keyserver, ping elmo for further debug.
[07:08] <cprov> kiko: or do you want me to do it ?
[07:08] <kiko> cprov, if you could please
[07:08] <kiko> I would like to understand if this is an ongoing problem
[07:08] <cprov> kiko: okay
[07:25] <kiko> roshan_s, can you try again please?
[07:26] <roshan_s> kiko: It worked now. It says it has sent me the email. Thanks!
[07:26] <kiko> roshan_s, rock on!
[07:29] <roshan_s> kiko: ... and the key has been confirmed. I made some packages for REVU, so now I can get on with the rest of the process. Thanks again!
[07:30] <kiko> roshan_s, sorry for the inconvenience, it's a problem with our internal keyserver's syncing. elmo offered to put work into monitoring it automatically, so thank him. 
[07:31] <roshan_s> Thanks elmo, and cprov
[10:46] <mikmor2> Can I create a subproject easily?
[11:12] <mikmor2> Hmm.. could someone tell me how I turn my project into a super-project?
[12:07] <Kmos> some LP admin can remove https://launchpad.net/bugs/bugtrackers/avahi-tracker , there is already https://launchpad.net/bugs/bugtrackers/avahi
[12:13] <Kmos> https://launchpad.net/bugs/bugtrackers/beryl-bugs
[12:13] <Kmos> and this one too