[00:00] StevenK, thumper, mwhudson, wgrant, lifeless: meeting ping [00:05] hi [00:32] oh FFS [00:33] something worked in make harness [00:33] I changed something unrelated [00:33] and now it doesn't [00:33] stupid effing python [00:39] ah... [00:39] stupid flush [00:39] object created, but not in DB [00:58] man, I hate presentation software [01:03] * wgrant tends to use beamer. [01:03] I don't write latex enough to be very efficient in it [01:03] I've done a few pressies in it [01:05] wgrant: did you see stubs comments on archive:+index? [01:05] presentation s/w is a classic case of (over)features over what you actually need. a *good* presentation will use the barest minimum of the feature set provided by the software. [01:06] text in font/size on a page; add pictures. have > 1 pages. fin. [01:06] lifeless: I did. [01:06] I've got a few other things to do today, but I will hopefully be able to look at it later. [01:06] spm: yes yes; you saw my epic talk yeah? [01:06] SO MANY SLIDES [01:07] only your drafts of the presenattion; not the delivery [01:07] still, minimal text on a slide [01:07] yup [01:07] sadly the subject matter was huge ;( [01:07] :-) [01:08] wgrant: # of slides isn't a problem per-se. so long as you have 1 to 2 messages you want to communicate. the slides are there to reinforce what you're saying. [01:08] Sure. [01:08] it's when someone uses the sides as the key part of their speech, that they're sunk. [01:08] spm, lifeless: console-presenter! [01:08] snort [01:08] but yes, agreed :-) [01:09] I'm trying to remember what I used to give a talk at Debconf5 [01:10] mwhudson: still haven't gotten around to looking at it [01:10] mwhudson: whats the learning curve? [01:10] .. dialog, I think [01:10] lifeless: very short, but setting up a background image is a bit of a fiddle [01:10] it's probably a bit too minimal to be useful, in all honesty [01:10] Nice transitions. [01:11] :-) [01:11] i wrote it during a rage at the first epic [01:12] My eyes... [01:12] ah yes [01:13] The pure uncommented evil at the end of present.py is delicious. [01:19] poolie: if you want to talk, now would be best [01:20] now is great [01:40] * thumper kicks off an ec2 test before moving laptop [02:08] poolie: grabbing a drink [02:13] === Top 10 Time Out Counts by Page ID === [02:13] Hard / Soft Page ID [02:13] 108 / 5131 Archive:+index [02:13] 79 / 307 BugTask:+index [02:13] 52 / 291 Distribution:+bugs [02:13] 15 / 121 ProjectGroupSet:CollectionResource:#project_groups [02:13] 13 / 349 Distribution:+bugtarget-portlet-bugfilters-stats [02:13] 13 / 5 ProjectGroup:+milestones [02:13] 11 / 1 Distribution:+builds [02:13] 8 / 33 MailingListApplication:MailingListAPIView [02:13] 8 / 18 DistroSeriesLanguage:+index [02:13] 6 / 12 NullBugTask:+index [03:24] StevenK: Are you still on maverick? [03:48] wgrant: Yes [03:49] poolie: that https://code.launchpad.net/ubuntu/+activereviews is a 404 [03:51] StevenK: Could you see if the buildbot failure is reproducible? [03:52] StevenK: It explodes anyway on natty, so I can't really. [03:55] https://bugs.edge.launchpad.net/launchpad/+bug/697962 [03:55] <_mup_> Bug #697962: want view/feed/subscription of all distro mps < https://launchpad.net/bugs/697962 > [03:55] thanks [04:00] http://pastebin.ubuntu.com/550931/ [04:00] Wha? I'm confused [04:08] StevenK: Same here. [04:09] jsbuild was changed yesterday, I believe. [04:09] Seems relevant. [04:14] StevenK: It seems to work once I blow away lazr-js/build. [04:14] Must have had an old YUI. [04:39] lifeless: Do we have a reasonable strategy for HA-poppy? [04:40] wgrant: I can't even see how to run launchpadlib's doctests ... [04:41] StevenK: "bin/test -1cvvvt introduction.txt" should do it. [04:41] wgrant: yes, you and I sketched one out [04:41] I don't know if it was rt'd [04:41] wgrant: I do know I filed bugs on the race condition [04:42] lifeless: The race condition makes that strategy unreasonable :( [04:42] And I don't think fixing it is easy. [04:42] wgrant: things that are worth doing are often not easy [04:43] if you want to discuss this again, hop onto skype; I can make time to talk about it, but am a bit over my keyboard at this time of night [04:43] the price would be that you write up what we come up with somewhere :) [04:47] wgrant: introduction.txt passed. In 31 seconds :-( [04:49] wgrant: yes/no ? [04:50] lifeless: I should probably discuss with Julian first. [04:50] StevenK: Hmm. A forced build may be in order. [04:50] Yay... [04:51] wgrant: up to you; I have a couple of missing bits of knowledge to describe a solution; you could fill them in for me if you wanted. [04:56] wgrant: ok, taking that as 'no' ;) [04:57] wgrant: fwiw I don't see why our strategy wouldn't work even with the race. We catered for it in our design IIRC. === almaisan-away is now known as al-maisan [07:33] Good morning ! [07:42] Anyone happen to know offhand how I land an approved change to launchpadlib? https://code.launchpad.net/~stub/launchpadlib/dynamiclibrarian/+merge/44657 [07:45] stub: It's pretty boring. Grab trunk, merge into it, update NEWS if relevant, and commit with the right [r=*] etc in the message. [07:45] No PQM nastiness. [07:51] wgrant: ta [07:53] Actually, it's probably even documented. [07:53] Indeed, on https://dev.launchpad.net/HackingLazrLibraries [08:34] Hrmph. [08:34] buildbot failed again. [08:34] Maybe this is lucid-specific :/ [08:34] good morning [08:35] Does anybody still have a Lucid machine which runs LP? [09:08] Hello [09:44] stub: \o/ librarian landed thank you! [09:45] Cool. Was the only thing left the launchpadlib fix? [09:46] I don't know, I just saw it toggle to merged... [09:47] or I may be fundamentally confused [09:47] confused it most liskely ;) [09:47] good morning [09:47] stub: ah I was confused; its the launchpadlib fix I just saw [09:47] stub: which is great to land, but I don't know if its the be-all [09:48] Its near the end anyway [11:10] wgrant, you wouldn't still be on, would you? [11:11] jcsackett: I am, unfortunately. [11:11] What's up? [11:12] any chance you could qa your branch related to bug 45270? [11:12] <_mup_> Bug #45270: Publisher configuration needs redesign

< https://launchpad.net/bugs/45270 > [11:13] henninge has encountered a problem on a branch of his earlier in the queue, but now i need to clear out everything else so his fix can land too when we deploy. [11:13] jcsackett: oh, sorry. Forgot about the db-stable deployment report. [11:13] wgrant: no worries. it's an easy one to forget if you're not doing the release. :-P [11:14] However, that rev is fine. [11:14] * wgrant qa-ok's. [11:15] jcsackett: Sorry about that. It's fixed now. === matsubara-afk is now known as matsubara [11:17] wgrant: thanks! === yofel_ is now known as yofel [11:23] henninge: how are things going? [11:24] jcsackett: it's a bit complex but getting there [11:24] i'm guessing your earlier estimate of qa by today is shot? how likely does before we need to merge db into devel sound? [11:26] henninge ^ [11:30] jcsackett: not sure but there won't be any db changes, so that would not really be a problem for us. [11:31] henninge: well, but the recife revision needs to be known deployable by then. [11:31] right [11:32] henninge: i guess i'm asking, will recife be qa-ok in some form by then, or do we need to start talking other options? [11:33] jcsackett: it will be "qa-ok" in some form, partly because we don't really have any other options. [11:33] henninge: well, there's roll-back and re-land after, but i think we'd both really rather not go down that road. :-) [11:33] jcsackett: we landed quite a few revisions in db-stable this cycle that depend on recife. Having to back them out would be a greater mess, I expect. [11:34] jcsackett: no, we don't [11:34] ;) [11:34] henninge: i see the later bugs on db-stable. do you think someone else can qa those so you can focus on the fix branch you're working on? i'm happy to try qa-ing them if that would help you out. [11:35] jcsackett: jtv can probably qa those but mostly they will be qa-ok together with recife as it's all the same story. [11:35] henninge: ah. i see. okay. mind if i ping you again at the end of your day to see where things stand? [11:35] jcsackett: sure [11:36] jcsackett: thanks for pinging [11:36] henninge: thanks for the update. :-) [11:36] ;) === Ursinha is now known as Ursinha-afk [12:05] Morning, all. === Ursinha-afk is now known as Ursinha [13:19] jml, i'm figuring out what to say about the buildbot failure, but after that i'd like to talk to you about the web service demo for thunderdome [13:20] bigjools: Do you know if this is worth pursuing? https://code.launchpad.net/~dhillon-v10/launchpad/fix-bug-410331/+merge/19766 [13:27] allenap: not really, it was too much like hard work for a tiny gain [13:28] bigjools: Shall I comment and mark it rejected? [13:28] yeah, he didn't reply to the last comment requesting tests === gary-afk is now known as gary_poster === matsubara is now known as matsubara-lunch [14:44] jml, buildbot failure is hopefully resolved. let me know when you have time to talk demo === salgado is now known as salgado-lunch === matsubara-lunch is now known as matsubara [15:43] gary_poster, I'm trying to write a unit test for the TargetBranchWidget and having trouble creating an instance of the widget. Do you know what widgets are supposed to take as their input? [15:44] abentley: on calls === beuno is now known as beuno-lunch [15:56] abentley: I'm looking into your question. [15:56] benji, I've answered that one with a little pdb. [15:56] cool [16:03] What's the easiest way to see the query that storm has composed? [16:06] LP_DEBUG_SQL === Ursinha is now known as Ursinha-lunch === salgado-lunch is now known as salgado [16:43] henninge: it's near your EOD, right? have just a sec for an update on recife? [16:43] jcsackett: it is but I will be working a little longer. [16:44] jcsackett: The fix is almost complete. ;) [16:44] henninge: that's what i was hoping. :-) [16:44] henninge: aside from that issue, is recife looking good? [16:45] jcsackett: always has! ;) [16:45] jcsackett: it is a very complex change and we are aware that we won't catch all issues beforehand. [16:47] henninge: dig. in the db-stable report i'm seeing what looks like the recife merge holding up revisions. https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html [16:48] the bug 611668 is the relevant one; can we mark that qa-ok? [16:48] <_mup_> Bug #611668: getPOTMsgSetWithNewSuggestions upstream

< https://launchpad.net/bugs/611668 > [16:49] jcsackett: done ;) [16:50] henninge: excellent. thanks a lot, and have a good evening. :-) [16:52] jcsackett: ah sorry, I had to revert that :( [16:52] jcsackett: I just saw that that revision is linked to the wrong bug. [16:53] jcsackett: that revision is the main recife merge and that is currently qa-bad until the bug is fixed that I am working on. [16:54] henninge: okay. but you think the bug you are working on will be ready to for review/land soon? i would like this all to make the deadline for when db-stable gets merged. [16:55] otherwise we cannot deploy it, or anything after it. [16:55] jcsackett: yes, it will be ready for review soon. [16:55] henninge: excellent. :-) [16:57] the real master bug is bug 681930, I don't know why the revision was tagged with the wrong bug. Probably copy-and-paste error on my side. [16:57] <_mup_> Bug #681930: Share translations between Ubuntu and upstream projects

< https://launchpad.net/bugs/681930 > [16:58] that is weird. [17:02] henninge: it's linking to that revision because the revision connected to 681930 was rolled back, i think. [17:05] henninge: honestly, i am not sure how some of the revisions are being determined in the report. very odd. [17:06] jcsackett: Well, in this case it looks like the wrong bug is mentioned in the commit message. [17:07] I wrote that message out manually because of all the reviewers and I must have pasted the wrong bug id. [17:09] henninge: ah, okay. [17:09] so even though the actual bug listed in the report is qa-ok, we're marking qa-bad so we don't mark recife as qa-ok. i wonder if there's a way to sort that out... [17:14] okay, i see, we also have the fixes for the actually linked bugs included in that revision. so while the report is misleading, we're basically okay once your fix is landed and we can mark recife and your fix qa-ok. === beuno-lunch is now known as beuno === benji is now known as benji-lunch === Ursinha-lunch is now known as Ursinha === al-maisan is now known as almaisan-away === benji-lunch is now known as benji === matsubara is now known as matsubara-afk [20:27] gary_poster: do you know how to add OOPS prefixes? [20:28] lifeless: vaguely. I could wing it. I thought matsubara-afk had done some for you in the past day or two? [20:28] gary_poster: he may have, I haven't corresponded with him specifically though [20:29] * lifeless really wants to eliminate all this manual friction [20:30] ah you mean friction of having to specify prefixes [20:30] yes, would be nice [20:31] both specifying them in configs for appservers and in the oops reporting toolchain [20:32] gary_poster: anyhow [20:32] https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1832CBB446 [20:32] lifeless, matsubara-afk reported in team calls that he had added some prefixes for you. I don't know anything else--how he knew you needed them, or anything else. Is there a bug for this? [20:32] isn't showing up [20:32] I'm guessing CBA isn't either [20:32] gary_poster: there is a bug that nothing audits to check we have them all covered [20:32] gary_poster: I don't know which are covered, so I can't sensibly file a bug asking for specific prefixes [20:33] gary_poster: and I don't know where to check to see which are covered ;) [20:37] lifeless: a Django tool named "South" populates the DB. [20:37] https://bazaar.launchpad.net/%7Elaunchpad-pqm/oops-tools/trunk/files/head%3A/src/oopstools/oops/migrations/ has the updates and https://bazaar.launchpad.net/%7Elaunchpad-pqm/oops-tools/trunk/annotate/head%3A/src/oopstools/oops/migrations/0015_populate_prefix_groups.py is the most recent pertinent data AFAIK. [20:37] I see neither CBB nor CBA. [20:38] give me a sec and I'll generate a list of what we have in use [20:39] I have calls and other tasks for the rest of the day and I don't know if we have fixed the "only Diogo can deploy" bug filed just before Christmas break. I suggest making a bug, and I'll ask Diogo to treat it as his top priority tomorrow morning. [20:39] ok [20:39] thanks for the help [20:39] np [20:47] jcsackett: hi, can I chat with you about bug 697685? [20:47] <_mup_> Bug #697685: People with PPAs should not be allowed to merge accounts < https://launchpad.net/bugs/697685 > [20:48] micahg: sure. [20:49] what's up? [20:49] jcsackett: I was wondering, I assume the issue is due to unique paths for the PPAs, right? would it be possible to alias both sets of PPAs to both accounts? [20:49] assuming no name collision === salgado is now known as salgado-afk [20:50] gary_poster: https://bugs.launchpad.net/oops-tools/+bug/698300 [20:50] <_mup_> Bug #698300: refresh oops prefixes / reports < https://launchpad.net/bugs/698300 > [20:51] micahg: there are several reasons [20:51] micahg: one is that we don't have code to handle renames of the archives on germanium [20:51] micahg: another is that the ppa model isn't amenable to merging of content in any trivial fashion [20:53] lifeless: ok, I'm guessing those bugs have already been filed in some fashion? [20:53] I don't know that they have [20:53] some of this stuff was envisioned as too-hard and requests marked WONTFIX [20:54] I'd be fine having a wishlist item to address the, [20:54] but it is a significant chunk of work in various ways - but someone that wanted to make it work would be welcome to contribute patches [20:55] lifeless: ok, just thought I'd mention it, I can look for a bug later I guess [20:55] please do [20:57] lifeless: thanks [21:03] flacoste: ping [21:03] hi lifeless [21:03] flacoste: whats the protocol for asking mkanat to do stuff [21:03] https://bugs.launchpad.net/loggerhead/+bug/698305 [21:03] <_mup_> Bug #698305: no such revision triggers an OOPS < https://launchpad.net/bugs/698305 > [21:04] lifeless: talk to poolie [21:05] flacoste: cool, will do - thanks [21:05] poolie: ^ [21:09] flacoste: do you know whats up with bug 547036 ? [21:09] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree

< https://launchpad.net/bugs/547036 > [21:09] I don't understand the issue [21:09] lifeless: buildd code is in launchpad [21:10] but it's deployed independantly [21:10] and really has no relationship to the rest of the code [21:10] lamont wants it out for easier packaging [21:10] and release management [21:11] lifeless: if you were wondering about the discussion about what prevents it from being separate at this time, i don't have any idea [21:19] flacoste: well, I was looking at it and various test fixture glue got in the way [21:20] yep, that's what i read from the bug report [21:21] anyhow, the thing for me is that really the code in question shouldn't be in the buildd tree either [21:21] its common code [21:21] flacoste: what prompted the escalation? [21:21] lifeless: IS call [21:23] flacoste: it would help me understand whats going on if you can add a comment when escalating things like this - it looks uninteresting otherwise ;) [21:23] right [21:23] i will [21:23] that would be awesome! thank you [21:25] flacoste: I would like to know what functional issue they experienced to make this a priority rather than tech-debt [21:26] flacoste: as data for things-we-should-fix [21:26] lifeless: best to ask lamont direcly [21:53] Are there any bug team devs about? [21:55] whats up [21:59] nothing important, was just hoping to get a bug import done [21:59] I've got our SF trackers disabled, so was hoping to get a quick transition [21:59] https://answers.launchpad.net/launchpad/+question/140463 [22:00] There was also https://answers.launchpad.net/launchpad/+question/140410 (got assigned to Deryck as he's team lead, but he's not about) [22:01] On reflection I should probably not have filed two questions which appear identical (apart from the filename)! [22:05] flacoste: who actually /does/ imports ? [22:05] flacoste: losa? [22:06] lifeless: yes, i think so [22:07] lifeless: deryck had details in his latest state of bugs email [22:09] thanks [22:10] flacoste: is that email public / archived, or canonical internal? [22:11] (just curious) [22:11] pjdc: launchpad-dev, so public and archived [22:11] flacoste: actually it doesn't say who does them [22:11] only that its painful [22:11] pcjc2: The State of Malone in the launchpad-dev list archives [22:11] https://lists.launchpad.net/launchpad-dev/msg05983.html ? [22:12] "story" is use-case driven development? [22:13] roughly [22:13] pcjc2: so do you want these imported to staging first, or you're totally ready? [22:14] pcjc2: so the sad news is the dude that knows all had a personal emergency today and isn't around [22:14] I will try to get the knowledge and have these acted on for you [22:15] hmm - if I say "I'm ready", there will be some issue I spot 5 minutes after the import [22:15] If we go via staging... all will be fine.. and we'll spot an issue 5 minutes after the real import ;) [22:16] It "should" be ok. I've had a round on staging before [22:16] Have tested the imports on my local dev instance too [22:17] ok [22:19] pcjc2: so testing locally yo ujust run bug-import.py -p pcb [22:19] yes? [22:19] indeed [22:19] (already contributed a round of patches which should now be on the production servers ;) [22:19] (had to fix that script up a tiny bit [22:20] have we landed your empty comments fix ? [22:20] I think / hope so - bug was marked fix released [22:20] if not, import will have to wait [22:20] do you remember the # ? [22:21] checking [22:23] https://bugs.launchpad.net/launchpad/+bug/692951 [22:23] <_mup_> Bug #692951: Don't show placeholders for imported bug attachments < https://launchpad.net/bugs/692951 > [22:23] yup its live [22:24] apparently your webserver is very slow ;) [22:24] which - the www2.eng.cam.ac.uk one? [22:25] yes [22:25] the sysadmin is having the download from there crawl [22:25] or are the files ginormous [22:26] not huge, 5.8M, 10M [22:26] could be the server is struggling I guess, not sure - its one I have access to [22:27] henninge: I just left a comment on bug 698344 with a workaround for the issue. [22:27] <_mup_> Bug #698344: Storm has no ROW constructor < https://launchpad.net/bugs/698344 > [22:28] hmm - read the email [22:29] ran the rnv validator - got errors [22:29] will have to get back you when I can get to fixing it, sorry for the noise [22:29] oh [22:29] thanks [22:29] the geda_export.xml is fine [22:29] the pcb_export.xml one causes problems - I'll note that in the question [22:31] I have to go for now, might be back in a bit, otherwise tomorrow [22:32] pcjc2: we're about to do the geda one [22:32] I'm curious why you didn't see the errors with pcb in your run on staging ? [22:37] jkakar: wow, cool. thanks! [22:38] jkakar: actually, I had worked around it by using SQL("(t1.c1, t1.c2)") but this is nicer ;) [22:39] henninge: Using "SQL" is almost always a hack. :) [22:39] it is! ;) [22:40] henninge: It'd be nice if you created a branch to add a Row expression to Storm. :) [22:40] jkakar: now that I know how I can do that [22:40] :) [22:40] :) [22:43] pcjc2: https://bugs.launchpad.net/geda - still running [22:51] hey thumper, hows things? === gary_poster is now known as gary-afk [22:52] pcjc2: geda is imported [22:56] lifeless: looks like we really need to increase the batch size for git imports [22:56] lifeless: fetching a branch, doing 30 seconds of work, then pushing it back and trying again 4 hours later is.. suboptimal [22:57] lifeless: argh, nevermind. I thought it was a new import. [22:57] jelmer: it shouldn't wait 4 hours until the build farm is busy [22:57] s/build/import slave/ [22:57] s/until/unless/ [22:57] sigh [22:57] mwhudson: yeah, it's actually an existing import.. [22:57] mwhudson: :-) [22:57] jelmer: ECONTEXT [22:57] lifeless: None [22:58] lifeless: the geda import, but I was wrong [22:58] mwhudson: we should still fix the import batch size, but it's not as bad as I thought. [22:58] jelmer: its a bug import ;) [22:59] jelmer: not a branch import [22:59] jelmer: well /really/ what would be nice is to import revisions for an hour, then checkpoint somehow [22:59] lifeless: argh, so not only did I misinterpret the results, I was looking at the wrong page. [23:00] mwhudson: yeah [23:00] jelmer: yes, you did :) [23:01] mwhudson: I'd really like to move the batch import thing upstream and see mirrors and imports use the same infrastructure. [23:01] jelmer: upstream into bzr you mean? [23:02] and yes, mirrors and imports using the same infrastructure would be nice [23:03] that sounds intruiging [23:04] lifeless: Thanks! [23:04] pcjc2: so how did pcb work on staging if it had errors? [23:04] well, I've done a LOT to the conversion scripts since the staging round [23:04] had a lot of UTF8 encoding issues from the SF backup XML [23:04] ok [23:05] so, when you think its good [23:05] It appeared to work fine on my local instance, but the validate fails [23:05] what validate was used? [23:05] we're updating our docs for this process [23:05] pcb_output.xml:43292:276: error: element https://launchpad.net/xmlns/2006/bugs^milestone not allowed [23:05] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/doc/bug-export.rnc [23:06] as described here: https://help.launchpad.net/Bugs/ImportFormat [23:09] ok, fixed the issue [23:09] duplicated a milestone tag accidentally due to some copy+paste error in my convert script [23:09] uploading new pcb_output.xml now [23:11] I've updated the ImportFormat page [23:11] mbarnett: ^ [23:11] pcjc2: do you want a new staging import, or are you completely happy to go live? [23:11] give me a minute to just quick-check here locally, then lets go live [23:11] pjdc: same location as the last time? [23:12] I suggets a new url [23:12] to avoid possibility of FAIL [23:12] that seems like a sane precaution [23:12] like ...2.xml or something [23:13]