[00:06] <sinzui> StevenK: mumble?
[00:13] <sinzui> sorry.
[00:47] <StevenK> sinzui: http://pastebin.ubuntu.com/626955/
[01:38] <sinzui> I think I have isolated the cause of several X session crashes. Typing certain number sequences in email and my editor causes me to drop into the console
[01:39] <sinzui> I am going to test this now in IRC by typing my phone number, which I cannot do in email.
[01:39] <sinzui> 301.346.9229
[01:39] <sinzui> okay. I can type it here.
[01:40] <LPCIBot> Project parallel-test build #38: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/38/
[02:14] <wgrant> So can't test/release the pickers further :(
[02:14] <wgrant> Bad buildbot.
[02:14] <wgrant> Blocking codeimport QA :(
[02:31] <lifeless> *blink* 1209 Time Outs
[02:32] <wgrant> I would tend to doubt that.
[02:32] <wgrant> But I guess.
[02:32] <lifeless> yesterday was ndt-fail was't it
[02:33] <StevenK> It was
[02:34] <wgrant> It was. I'd expected more.
[02:34] <wgrant> I guess it was a quiet time.
[02:41]  * wgrant cleans up dogfood's shelf.
[02:41] <LPCIBot> Project windmill-devel build #222: STILL FAILING in 14 min: https://lpci.wedontsleep.org/job/windmill-devel/222/
[02:47] <StevenK> Uh oh
[02:48] <StevenK> bzrlib.errors.ConnectionError: Connection error: while sending GET /~launchpad-pqm/bzr-git/devel/.bzr/repository/packs/8dff80eb7a417959127398ef4268cdd3.pack: [Errno 110] Connection timed out
[02:48] <StevenK> Whee!
[02:49] <LPCIBot> Project windmill-devel build #223: STILL FAILING in 7.1 sec: https://lpci.wedontsleep.org/job/windmill-devel/223/
[02:49] <StevenK> Sigh
[02:50]  * StevenK shoots the builder in the face
[03:01] <wgrant> sinzui: Have you updated buildbot and convinced StevenK to fix jenkins?
[03:01] <wgrant> (although jenkins might fix itself if you've fixed launchpad-dependencies)
[03:01] <StevenK> It ought to
[03:03] <spiv> StevenK: incidentally the package importer got some timeouts from Launchpad a few minutes before you said that.
[03:03] <wgrant> spiv: Is it OK now?
[03:07] <spiv> wgrant: yes, it just had a few at 01:41 (jubany time)
[03:08] <wgrant> Erk.
[03:08] <spiv> wgrant: see the most recent failures on http://package-import.ubuntu.com/status/
[03:10] <wgrant> http://package-import.ubuntu.com/status/libgit-ruby.html
[03:10] <wgrant>         <h1>Sorry</h1>
[03:10] <wgrant>         <p>
[03:10] <wgrant>           Launchpad is offline for scheduled maintenance.
[03:10] <wgrant>           We should be back soon.
[03:10] <wgrant> What.
[03:10] <wgrant> LOSA ping.
[03:11] <hloeung> wgrant: hi
[03:11] <wgrant> hloeung: Did something happen to the network/haproxy/something at 11:41?
[03:12] <hloeung> I don't think so
[03:13] <hloeung> what's the problem?
[03:13] <wgrant> hloeung: jubany got a scheduled maintenance 503 from haproxy.
[03:13] <wgrant> And jenkins (on canonicloud) got a connection timeout to crowberry.
[04:01] <wgrant> huwshimi: Hi.
[04:02] <huwshimi> wgrant: Hey there
[04:03] <wgrant> huwshimi: Have ytou looked at the new person picker?
[04:03] <wgrant> huwshimi: Try searching in the assignee picker on https://bugs.qastaging.launchpad.net/launchpad/+bug/1234
[04:03] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[04:03] <wgrant> huwshimi: I'm wondering about the "Details..." link... it seems less than ideal.
[04:03] <huwshimi> wgrant: No I haven't. I'll take a look
[04:05] <huwshimi> wgrant: Is it supposed to open in a new window?
[04:06] <wgrant> huwshimi: I believe that is the intention. I'm not convinced it's the ideal solution, but it was the easiest at the time.
[04:06] <huwshimi> wgrant: It shouldn't be a green link then
[04:06] <wgrant> That's what I said.
[04:06] <wgrant> huwshimi: But it also doesn't navigate away from the current page.
[04:07] <wgrant> So it might not be blue either.
[04:08] <huwshimi> wgrant: I believe green links are for doing an action that will affect the current page.
[04:12] <huwshimi> wgrant: Also the ellipsis would imply that it's going to an action on the page too
[04:17] <huwshimi> wgrant: So this is to help people get some further information about who the person and to know they are selecting the correct person?
[04:26] <wgrant> huwshimi: I believe so.
[04:26] <wgrant> huwshimi: I think it should really expand the picker entry inline.
[04:26] <wgrant> But that's a bit difficult, AIUI.
[04:27] <huwshimi> wgrant: What's the difficulty?
[04:27] <wallyworld___> wgrant: huwshimi: sinzui wants to navigate to the person page since we can't pre-guess the info they will need to make their decision
[04:28] <wgrant> Jumping out of an inline picker into a new page seems... questionable.
[04:28] <wallyworld___> green was chosen as the colour because the action of clicking does not navigate away from the current page - that's what was communicated to me anyway
[04:28] <wallyworld___> questionable maybe, but how else do we do it?
[04:29] <wallyworld___> it's not that uncommon a paradigm
[04:29] <wallyworld___> a lot of the web pages i visit do that
[04:30] <wgrant> Popups that spawn new pages? Odd.
[04:30] <wgrant> I mean, these popups exist just to return data to the original page.
[04:31] <wallyworld___> yes, but you need to be able to tell you are picking the correct thing - that's one of the tenants of the disclosure work
[04:31] <jtv> Not quite the same, but doesn't the help system already face this problem?  Any ideas that could be cribbed from there?
[04:31] <jtv> wallyworld___: tenets, I hope.  :)
[04:32]  * wallyworld___ can't spell
[04:32]  * jtv was worried about LCP for a moment
[04:32] <LPCIBot> Project windmill-devel build #224: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/224/
[04:33] <wallyworld> jtv: i haven't used the help system. that would be RTFM and men don't read instructions :-)
[04:34] <jtv> wallyworld: eerie how you identify the reason for my uncertainty there
[04:34] <jtv> But still
[04:34] <jtv> I think it also pops up a window with text that may have links, which may open new browser windows.
[04:34] <jtv> In which case, crib copy & steal!
[04:35] <wallyworld> jtv: well the picker does that now so there's no need to steal anything
[04:36] <jtv> What I mean is, doing whatever it does would technically make it a UI pattern.  :)
[04:37] <wallyworld> ah right
[04:41] <huwshimi> Opening a new window is certainly suboptimal. Can someone can give me some more information on why we can't guess what info might be useful for making this descision?
[04:44] <wallyworld> huwshimi: what info is needed depends on the context of what is being picked and what it is being picked for, and also the user's prior knowledge
[04:45] <wallyworld> there's no easy 2 or 3 lines of info what can be displayed in every case that is guaranteed to be what the current user wants to see
[04:46] <wallyworld> so we have to take them to the indx page of the thing they think they want to pick so they can poke around and see if it's what they want
[04:46] <huwshimi> wallyworld: Can you give me an example?
[04:47] <wallyworld> picking an assignee for a bug task
[04:47] <wallyworld> or a source package for ....
[04:47] <wallyworld> i haven't got a good example of the latter one
[04:48] <huwshimi> wallyworld: And what is the difference in information that might be required between those two?
[04:48] <wallyworld> so picking an assignee, you may want to check what other bugs they've worked on before giveng them the new one
[04:48] <wallyworld> huwshimi: i know little about source packages in lp so can't really given a good example
[04:49] <wallyworld> huwshimi: i'm more or less paraphrasing what was told to me when i asked these questions
[04:49] <huwshimi> wallyworld: No problems, I'm just trying to understand the problem.
[04:49] <wallyworld> sure, that's offering additional info :-)
[04:50] <wallyworld> /that's/just
[04:50] <wallyworld> huwshimi: you maybe want to join our standup tomorrow and we can discuss :-)
[04:51] <huwshimi> So really this is more about a convenient link to the person's profile rather than just providing additional info for the picker
[04:51] <huwshimi> Which is outside the scope of what you'd want to accomplish with the picker
[04:52] <wallyworld> yes
[04:52] <huwshimi> As in, it's not the job of the picker to provide that level of information about the user. That's additional work you might want to do to figure out who this person is.
[04:52] <wallyworld> because there's no one size fits all solution for what extra info could or should be displayed in the picker for each context
[04:53] <wallyworld> yes
[04:53] <wallyworld> i think you have it :-)
[04:53] <wallyworld> the picker should try and provide as much as it can so the user doesn't have to click the link :-)
[04:54] <wallyworld> and we do that with the newly added work to show the nicks and correct ordering and badges etc
[04:54] <wallyworld> but we also need to offer a way to get extra info if what's there doesn't suffice
[04:55] <huwshimi> OK, I think the "Details..." link implies that you're going to get a little bit more information and what might need to happen is just to rename the link and drop the ellipses and change the colour. I'm not sure what our pattern should be for external links.
[04:57] <wallyworld> huwshimi: we can implement whatever is deemed necessary, just let us know what is needed in terms of styling :-)
[04:57] <huwshimi> So that link could be something like "View profile"
[04:57] <wallyworld> and get agreement from the stakeholders
[04:57] <wallyworld> sounds reasonable for a person picker
[04:57] <huwshimi> And make the link blue
[04:57] <wallyworld> perhaps different wording is needed for other vocabularies
[04:58] <huwshimi> wallyworld: Sure.
[04:58] <StevenK> huwshimi: But not pink with purple polka dots? :-)
[04:58] <wallyworld> huwshimi: i was told not to make the link blue, so that would need to be a discussion point :-)
[04:58] <huwshimi> StevenK: Only under a feature flag just for you.
[04:58] <StevenK> I don't know about that :-)
[04:58] <StevenK> But nice comeback :-P
[04:58] <wallyworld> what's wrong with pink and purple?
[04:58] <huwshimi> wallyworld: I think it does need to be blue because it _does_ take you to a new page
[04:59] <huwshimi> wallyworld: It just doesn't change the url of the current page
[04:59] <wallyworld> huwshimi: but it *doesn't* trash the current page
[04:59] <huwshimi> wallyworld: Unless you have your browser set up to not open new window links in new windows
[04:59] <wallyworld> huwshimi: yes, but even if you do (why anyone would nowadays with tabbed browsing is beyond me), your current page is still there
[05:00] <huwshimi> wallyworld: And I think that breaks the "do something to the current page" which is what the green links are supposed to represent
[05:00] <wallyworld> huwshimi: that was my argument initially too.
[05:00] <StevenK> wallyworld: Er. So, we still support IE6. And IE6 has no tabs.
[05:01] <wallyworld> StevenK: and why anyone still uses IE6...... (i know, i know brain dead corporates)
[05:02] <wallyworld> huwshimi: anyways, it's just a css attribute. i'm sure we will do whatever the stakeholders say we need to :-)
[05:02] <huwshimi> wallyworld: I think it needs a wording change too
[05:02] <wallyworld> ok
[05:05] <wallyworld> huwshimi: so you watching SOO tonight? I know StevenK and wgrant aren't man enough to enjoy it :-P
[05:08] <StevenK> Meh, SoO
[05:08] <StevenK> wallyworld: http://www.theie6countdown.com/default.aspx is telling, but I suspect you've seen it.
[05:08] <huwshimi> wallyworld: I'm catching up with some friends and then probably catch the end of it... if seeing friends doesn't mean watching SOO with them
[05:08]  * wallyworld looks
[05:09] <StevenK> Putting the banner on would make me happy, but only if it links to getfirefox or so
[05:10] <wallyworld> StevenK: wow, china and india surprise me
[05:10] <StevenK> wallyworld: And South Korea
[05:11] <wallyworld> StevenK: that's because south koreas has a propriatary encryption solution for online banking that *requires* IE6 and is incompatible with every standard
[05:11] <wallyworld> AFAIUI
[05:11] <wgrant> Most South Korean bank sites use ActiveX, yeah :/
[05:12] <StevenK> Then I'd expect a higher percentage, TBH
[05:12] <wallyworld> or maybe it's just *requires* IEx
[05:12] <StevenK> wallyworld: If you want to know the funniest thing -- that website was written by the IE team themselves
[05:13] <wallyworld> well, i think even they realise now what they did :-)
[05:14] <LPCIBot> Project windmill-devel build #225: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/225/
[05:14] <StevenK> IE6 was during Microsoft 3-E approach to the Internet, wasn't it?
[05:14] <StevenK> (Embrace. Extend. Extingush.)
[05:15] <wallyworld> yep
[05:16] <wallyworld> i think of it as s/Extinguish/Exterminate (said with a Darlec accent)
[05:16] <lifeless> SoO ?
[05:16] <wallyworld> State Of Origin
[05:16] <wallyworld> QLD vs NSW
[05:16] <wallyworld> the ultimate battle :-)
[05:18] <StevenK> lifeless lived in NSW for a number of years, he probably got quite good at filtering it out.
[05:18] <huwshimi> wallyworld: Well not really. It would have to be a little more evenly matched to be the ultimate battle.
[05:18] <wallyworld> :-D
[05:18] <StevenK> And not be based on thugby
[05:18] <wallyworld> i can watch NSW get beaten anytime. I don't care if it's even or not :-)
[05:19] <huwshimi> wallyworld: haha
[05:19] <wallyworld> what's wrong with Rugby League|Union
[05:19] <wallyworld> does StevenK prefer watching soccer? or netball? perhaps synchronised swimming?
[05:19] <lifeless> wallyworld: oh, league. Not union :>
[05:20] <wallyworld> lifeless: yes, SOO is League
[05:20] <StevenK> wallyworld: AFL
[05:20] <mwhudson> it's even more slabs of beef running into each other than most league afaict
[05:20] <wallyworld> ah, the game of tight shorts
[05:20] <wallyworld> mwhudson: you mean AFL?
[05:21] <mwhudson> wallyworld: state of origin
[05:21] <wallyworld> mwhudson: ah yes, the intensity is pretty high. and they hit *hard*
[05:53] <wallyworld> lifeless: i may have found a bug with the bug subscription portlet - specifically the team membership check. well it's an issue in dev, but not production perhaps due to the really small batch size in dev
[05:54] <wallyworld> the client makes an ajx call to a team's member_details property via the web service
[05:54] <wallyworld> but this only returns the first batch of members
[05:54] <wallyworld> and so the membership check may erroneously fail
[05:54] <wallyworld> if the person being checked is not in the first batch of results
[05:55] <wallyworld> that's what's happening on my dev setup anyway
[05:55] <LPCIBot> Project windmill-devel build #226: STILL FAILING in 39 min: https://lpci.wedontsleep.org/job/windmill-devel/226/
[05:57] <wallyworld> the membership check is done in javascript by loading the team members. not sure why it was implemented that was instead of asking the server "is this person a member". it's still an RPC either way
[05:58] <wallyworld> has something changed recently to limit gets to web service CollectionField attributes to return only one batch at a time? or is this a long standing issue that we have avoided hitting in prod?
[06:01] <wgrant> wallyworld: Don't go near that code.
[06:01] <wgrant> wallyworld: Yellow is still rewriting it.
[06:01] <wgrant> I fixed it myself a couple of weeks ago, but set the branch aside once Danilo informed me that it was being completely reworked.
[06:01] <wallyworld> shit. i've based the blueprint subscription stuff on it. that's where i've found the bug
[06:01] <wgrant> wallyworld: CollectionFields have always been batched.
[06:02] <wallyworld> wgrant: so the code was broekn to begin with :-(
[06:02] <wgrant> Of course.
[06:02] <wgrant> That code is nauseating and buggy.
[06:02] <wallyworld> bollocks
[06:02] <wgrant> eg. you can't AJAX-subscribe someone with the same displayname as an existing subscriber.
[06:03] <wallyworld> my version is very much trimmed down to the bare essentials since there's no direct vs indirect subscriptions etc
[06:03] <wgrant> And it spends longer working out where to place the spinner (three HTTP requests, IIRC) than it does between showing the spinner and finishing the operation (one HTTP request).
[06:03] <wallyworld> yes, all true :-(
[06:03] <lifeless> Gary and I both had doubts about that spinner stuff
[06:04] <lifeless> if its the one I think it is ;)
[06:04] <wallyworld> i didn't realise the code i was reusing was so new :-(
[06:04] <wgrant> wallyworld: Hm, it's not new.
[06:04] <wgrant> wallyworld: It's just yet to be reworked as part of the... completed and released feature.
[06:05] <wallyworld> well, i may just clean up this issue in my new blueprints stuff then and revisit it later when bugs is done
[06:06] <wallyworld> it's also impossible to fully test without resorting to windmill
[06:19] <LPCIBot> Project windmill-db-devel build #391: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/391/
[06:20] <StevenK> Windmill, you make me sad.
[06:43] <lifeless> gmb: yo
[06:43] <lifeless> gmb: in https://code.launchpad.net/~gmb/launchpad/bug-61531/+merge/63672 I had a question for you; can has answer?
[06:53] <lifeless> wallyworld: is https://code.launchpad.net/~wallyworld/launchpad/blueprint-subscriptions-tales-refactor/+merge/63949 or needs-another-review ?
[06:59] <poolie> lifeless, hi
[06:59] <poolie> thanks for resolving those mps, that's so great
[06:59] <poolie> \heart
[07:01] <lifeless> np
[07:08] <poolie> i don't know if you saw the conversation on bzr recently
[07:08] <poolie> but i think wip mps are a graveyard
[07:09] <poolie> you might as well just reject community contributions than put them there
[07:09] <lifeless> I saw it
[07:09] <lifeless> I don't agree
[07:09] <lifeless> :)
[07:09] <poolie> therefore, specifically, i would flip nigelb's mp back to needsreview
[07:09] <poolie> ok :)
[07:09] <lifeless> that said, even if I ungreed unreservedly, we are not yet in a patch-pilotable position
[07:10] <lifeless> so for now, I would still move stuff to WIP, to get a clean slate so we can get a drive-to-zero thats approachable, and bring up a patch pilot model.
[07:10] <wgrant> Hmm, I've always seen WIP as coming before Needs Review. And it's something that I think should be toggled by the owner.
[07:10] <lifeless> wgrant: did you see the discussion poolie is referencing ?
[07:11] <wgrant> No.
[07:11] <poolie> https://lists.ubuntu.com/archives/bazaar/2011q2/073028.html
[07:11] <lifeless> so for bzr, with a patch pilot, WIP conflates 'can be piloted' and 'someone is hacking on this'
[07:11] <poolie> yes
[07:11] <poolie> ideally lp would separate these
[07:11] <lifeless> with apilot working through proposals that were nearly-there this conflation is arguably a problem
[07:12] <poolie> by, hypothetically, having assignment on mps
[07:12] <poolie> yes
[07:12] <wgrant> lifeless: Regarding launchpad-reviewers' contact address, isn't that necessary to stop all review mail from going to everyone (since it's the default reviewer, and reviewers always get mailed)?
[07:12] <lifeless> I say that I don't agree; its more nuanced than disagreement, but not something I want to drill into today.
[07:12] <poolie> it's ok
[07:12] <lifeless> wgrant: I don't believe so
[07:13] <wgrant> lifeless: What stops the mail?
[07:13] <poolie> i'm confident enough that it's worth trying in bzr, but not so much i'd advocate it to every one else yet
[07:13] <lifeless> wgrant: not being subscribed. IMBW
[07:13] <poolie> we can see if it changes things
[07:13] <wgrant> --
[07:13] <wgrant> https://code.launchpad.net/~cr3/launchpad/hwsubmissionset_search/+merge/63768
[07:13] <lifeless> wgrant: we can see how bzr's experiment turns out before changing anything in LP; I believe it is done.
[07:13] <wgrant> Your team Canonical Launchpad Engineering is requested to review the proposed merge of lp:~cr3/launchpad/hwsubmissionset_search into lp:launchpad/db-devel.
[07:14] <lifeless> wgrant: anyhow, we need to figure something out. the backscatter is pissing folk off ;)
[07:14] <wgrant> lifeless: Yes. We should stop working around our bugs :/
[07:18] <poolie> which one is done?
[07:19] <poolie> fwiw i think removing that list along the lines you describe makes sense
[07:19] <lifeless> poolie: the bazaar codereviewers thing
[07:19] <lifeless> poolie: wgrant is saying that you may still find all new MP's trigger mail to ~bzr
[07:20] <lifeless> darn, where is that bug about pushing-to-make-releases gone
[07:21] <poolie> it would be hard for me to tell
[07:22] <poolie> that change has been made, anyhow
[07:30] <lifeless> wgrant: I had the wrong team
[07:30] <lifeless> wgrant: its launchpad-canonical-reviewers I want to contact-ectomy
[07:31] <wgrant> Oh, those are separate lists.
[07:31] <wgrant> "WTF kill it kill it" is the answer that comes to mind.
[07:32] <wgrant> lifeless: I no longer think you are crazy :)
[07:33] <lifeless> wgrant: I'm so glad ;)
[07:35] <poolie> just curious why you say "not yet in a patch-pilotable position"
[07:35] <lifeless> https://code.launchpad.net/launchpad-project/+activereviews
[07:35] <lifeless> just the size of the queue vs the time allotted to reviews
[07:38] <LPCIBot> Project windmill-db-devel build #392: STILL FAILING in 14 min: https://lpci.wedontsleep.org/job/windmill-db-devel/392/
[07:39] <StevenK> And another redirect.
[07:39] <StevenK> bzrlib.errors.RedirectRequested: http://bazaar.launchpad.net/~launchpad-pqm/bzr-builder/trunk/.bzr/repository/indices/aa01e422f8699f10641354d6fa588e29.cix is redirected to https://launchpad.net
[07:42] <lifeless> I think there is a bug on that
[07:43] <lifeless> it *should* 404
[07:43] <lifeless> someone needs to tweak the apache rules
[07:43] <lifeless> stub: hiya
[07:43] <stub> lifeless: Hi
[07:43] <stub> Just looking at 0mq
[07:43] <lifeless> stub: I had a question for you in https://code.launchpad.net/~cr3/launchpad/hwsubmissionset_search/+merge/63768
[07:44] <lifeless> stub: nice
[07:44] <lifeless> stub: http://zguide.zeromq.org/page:all is a pretty good read about it
[07:49] <stub> lifeless: I mentioned in my comment that we could apply the patch live. I didn't want to complicate Marc's life though by splitting patches out of his branch and stuff unless necessary.
[07:50] <stub> lifeless: Although now I've decided to start giving out -1 style patch numbers even if we aren't planning on applying them live, just to make it easier if we change our minds.
[07:50] <lifeless> stub: Right, I'm not suggesting splitting
[07:51] <lifeless> stub: merely to use a -1 :)
[07:51] <stub> Right. I guess it doesn't matter which branch they land on, just as long as they land and don't get lost.
[07:51] <lifeless> stub: I heartily endorse your decision
[07:51] <stub> I'll add a comment and request a renumbering
[08:01] <stub> lifeless: So on initial skim, 0mq might be suitable for an RPC mechanism, but not suitable without effort for our async jobs as we would need to build a queue with it.
[08:01] <stub> lifeless: Kestrel sounded nice. You looked at that yet?
[08:01] <lifeless> stub: huh, It queues
[08:01] <lifeless> stub: it does spill to disk
[08:02] <lifeless> stub: high water thresholds, pub-sub etc
[08:02] <lifeless> stub: I'm not saying we should use it, but a quick skim won't touch its facilities enough to assess
[08:02] <lifeless> I need to reply to gavin
[08:02] <lifeless> yes, I've looked at kestrel
[08:02] <lifeless> and its also very interesting
[08:02] <lifeless> simple api
[08:02] <stub> lifeless: I thought it queued at the receiver or client, which assumes the receiver is up, and the client doesn't go down.
[08:03] <stub> lifeless: So for the 'fire and forget reliable messages' story, we would need a persistent queue in the middle.
[08:04] <stub> (But maybe that is trivial with the spill-to-disk behaviour)
[08:04] <lifeless> stub: right, I haven't finished getting to grips with it
[08:05] <lifeless> elliot has got me in contact with some rabbit staff
[08:05] <lifeless> to pull on rabbits ha story
[08:05] <lifeless> and gavin has landed a new stab at the test fixture
[08:07] <stub> I'll still vote for an API for implementation agnostic messaging so we can run with whatever-works-with-the-testsuite first for potentially unreliable delivery and move up from there.
[08:07] <lifeless> I'm not objection to that, but there are risks
[08:07] <lifeless> they centre around the definition of agnostic messaging :)
[08:08] <stub> getUtility(IMessageQueue, 'logging').send(python_object)
[08:10] <lifeless> if its that minimal its low risk; getting into priorities, persistence, etc - thats where I was worrying :)
[08:12] <stub> Right. Stuff priorities for now, and persistence is hidden by 'implementation agnostic' and irrelevant anyway because of 'potentially unreliable'
[08:15] <rvba> lifeless: Hi ... Thanks for the review!
[08:16] <lifeless> and, we're done: approximately all reviews done
[08:16] <lifeless> https://code.launchpad.net/launchpad-project/+activereviews
[08:17] <rvba> wgrant: Hi William, what did you think about my replies/code changes for https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676 ?
[08:30] <LPCIBot> Project parallel-test build #39: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/parallel-test/39/
[08:32] <wgrant> rvba: Looking now.
[08:37] <wgrant> rvba: Re-reviewed. Much better, but there are still a few issues.
[08:40] <rvba> wgrant: Thanks a lot, I'll address your issues today.
[08:40] <wgrant> rvba: Thanks!
[08:44] <wgrant> Is blog.launchpad.net meant to feature stuff that is only relevant to Launchpad developers?
[08:50] <lifeless> sure
[08:50] <wgrant> Hmm.
[08:50] <lifeless> everyone can be an lp dev :)
[08:50] <wgrant> Why?
[08:50] <lifeless> more seriously
[08:51] <lifeless> stuff for the front page should be more carefully selected
[08:51] <lifeless> most stuff for devs is at least interesting for highly technical folk
[08:51] <wgrant> We could perhaps put them in another category.
[08:52] <lifeless> and most LP-as-host-decision-makers are highly technical
[08:52] <wgrant> "Initializing page JavaScript from the JSONCache" would be nice on a LP planet or something.
[08:52] <wgrant> But it's not useful for users.
[08:52] <wgrant> So it shouldn't drown out other stuff on the blog, IMO.
[08:53] <lifeless> mrevell would be a good person to talk to about this
[08:53] <lifeless> my understanding is that its meant to just get communication out there
[08:53] <lifeless> breaking the code of silence we got into for a few years ;)
[08:53] <wgrant> This sounds like blogging every day for the sake of blogging.
[08:54] <lifeless> I don't think thats very useful
[08:54] <lifeless> OTOH we have 20ish folk
[08:54] <wgrant> It was a serious proposal two months ago.
[08:54] <lifeless> I think we have interesting things to say; one per person per month at least
[08:58] <LPCIBot> Project devel build #806: FAILURE in 6 hr 3 min: https://lpci.wedontsleep.org/job/devel/806/
[08:59] <adeuring> good morning
[09:02] <bigjools> morning all
[09:09] <lifeless> hi bigjools
[09:09] <bigjools> wotcher
[09:09] <lifeless> bigjools: is there anything you'd like from me at the moment ?
[09:09] <bigjools> all your base
[09:10] <lifeless> belong to me!
[09:10] <bigjools> you can fix all my bugs so I can just go to the beach?
[09:11] <lifeless> do I look like miracle max ?
[09:11] <lifeless>  :)
[09:11] <bigjools> also, it's very disconcerting to find a load of earwigs in my keyboard today
[09:11] <lifeless> ugh
[09:11] <lifeless> seen khan recently ?
[09:11] <bigjools> heh
[09:12] <lifeless> 8 days to my new desktop. shiiiiny
[09:12] <bigjools> I shall feed them to the 5cm-across spider who's made a nest just above me
[09:15] <wgrant> bigjools: Only 5cm?
[09:23] <nigelb> lifeless: Its on my list, just that life took a bigger priority :)
[09:23] <nigelb> I'll make the change today and request merge again
[09:23] <bigjools> wgrant: yes, it's a small one
[10:05] <lifeless> stub: my ec2 land failed to start up for https://code.launchpad.net/~stub/launchpad/bugsummary/+merge/64583
[10:05] <lifeless> stub: so you probably want to do that yourself
[10:33] <LPCIBot> Project windmill-devel build #227: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-devel/227/
[10:36] <cjwatson> Could somebody be reviewer for https://code.launchpad.net/~cjwatson/launchpad/germinate-lubuntu?  Fairly trivial change ...
[10:36] <bigjools> cjwatson: you need a merge proposal
[10:37] <cjwatson> yup, creating now
[10:42] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/germinate-lubuntu/+merge/64650
[10:44] <wgrant> cjwatson: Approved. Want it landed now?
[10:47] <cjwatson> that would be good, thanks
[10:47] <cjwatson> I can't start building CDs right away because I'm blocked on disk space, but that's supposed to get sorted out this week
[10:48] <wgrant> cjwatson: cocoplum updates still require downtime.
[10:48] <cjwatson> when's the next one due?
[10:48] <wgrant> Probably 3 weeks.
[10:48] <wgrant> The last was a week ago today.
[10:48] <wgrant> But we can do cocoplum separately in a few minutes of poppy downtime.
[10:49] <cjwatson> Hmm.  Lubuntu wants to be building CDs in time for Alpha 2; three weeks would blow that, I think
[10:49] <cjwatson> (my fault for not getting this trivial tweak in earlier)
[10:50] <wgrant> July 13 is the next scheduled downtime. I'll get a downtime window for cocoplum for probably Fri/Mon and deploy then.
[10:51] <stub> lifeless: k
[10:51] <wgrant> cjwatson: It has landed (r13238)
[10:54] <lifeless> stub: are my estimates for getting the (disable access, do a single schema patch, restore db access) realistic (I'm thinking if we go down -fast- [e.g. pg_cancel_backend all backends in parallel and don't restart pg itself], we should be down to sub-minute of overhead
[10:55] <stub> lifeless: So one thing I realized - it takes about 7 seconds to startup one of our scripts. So overhead due to zcml cruft is 21 seconds to start with.
[10:55] <lifeless> stub: one of the admin scripts?
[10:56] <stub> lifeless: update.py, fti.py, security.py
[10:56] <lifeless> stub: lets kick zcml out of them
[10:56] <stub> Yes, so we need to restructure that stuff.
[10:57] <stub> Otherwise I think we are fine for subminute, assuming negligable time to run the actual DDL.
[10:57] <rvba> wgrant: Just so you know, I've replied to your comments on https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676.
[10:57] <rvba> (I'm a little bit pushy with this because I have two branches that depends on this one ... but let me say that I really appreciate your detailed reviews on this rather complicated (at least to me) matter).
[11:00] <cjwatson> wgrant: great, thanks
[11:07] <wgrant> rvba: Thanks, I've replied.
[11:08] <rvba> wgrant: Thanks.
[11:08] <lifeless> still, 21 seconds in the first round is tolerable, it still leaves 4 minutes for the schema + disable + enable + kill backends
[11:08] <henninge> when did we remove Blog information from a user's profile page?
[11:08] <lifeless> stub: perhaps we should make up a tag for things to make this better, and/or things that we need to get started
[11:08] <wgrant> henninge: It was never there, AFAICR...
[11:08] <wgrant> henninge: Wiki information was removed a week or two ago.
[11:09] <henninge> wgrant: maybe that is what I remember.
[11:09] <henninge> I am aware that it can easily be included in the description.
[11:09] <stub> lifeless: Sounds sane.
[11:11] <rvba> wgrant: About the 1-based counter: the only problem I see is that the db column defaults to 1.
[11:11] <lifeless> gmb: oh hai
[11:11] <henninge> wgrant: was spam the reason to remove it?
[11:11] <gmb> lifeless: Hi.
[11:11] <wgrant> henninge: No. Bug #186660
[11:11] <_mup_> Bug #186660: Launchpad shouldn't store wiki names <lp-registry> <qa-ok> <users> <Launchpad itself:Fix Committed by bac> < https://launchpad.net/bugs/186660 >
[11:12] <rvba> wgrant: But of course, if I explicitly set it, I can make it start with 0 and everything is good (apart for the sql comments that says the counter starts at 1 :( )
[11:13] <henninge> wgrant: thanks, I wonder why it is not "Fixed Released", though.
[11:13] <wgrant> henninge: I have avoided closing it because they are not entirely gone.
[11:13] <rvba> wgrant: My only argument is that to fix that properly, a db-patch will be needed.
[11:13] <wgrant> henninge: They are merely hidden from the UI.
[11:14] <wgrant> I hope bac will garden it soon :)
[11:15] <henninge> ok
[11:18] <bigjools> lifeless: something I'd like to discuss is script startup time
[11:26] <henninge> Could somebody with bugs foo please have a look at this question? I don't think I understand what the problem is.
[11:26] <lifeless> gmb: yeah, that branch - do you agree with my point about unintention explicit subscriptions
[11:26] <henninge> https://answers.launchpad.net/launchpad/+question/161503
[11:27] <lifeless> bigjools: I'd love to discuss that; not right now (TL meeting tomorrow)
[11:27] <bigjools> lifeless: ok.  AIUI it's to do with zcml parsing but I think we can fix that
[11:28] <gmb> lifeless: You mean "is it a no-op if you're subscribed via a team?" Yes - good call. I'm updating it now to make sure that being in a subscribed team means you won't be subscribed directly.
[11:28] <lifeless> gmb: ah, just saw your mail
[11:28] <lifeless> gmb: cool
[11:28] <lifeless> bigjools: feel free to fix it ;)
[11:29] <bigjools> lifeless: well it's not trivial :)
[11:29] <bigjools> but the basic problem is that why should a script need to worry about browser zcml for example
[11:36] <danilos> jtv, hi, do you think you'd have time to review https://code.launchpad.net/~danilo/launchpad/bug-772754-other-subscribers-actions/+merge/64187 (it's slightly over-sized, but mostly due to JS tests)
[11:40] <bigjools> lifeless: still around?
[11:40] <lifeless> bigjools: barely; whats up?
[11:41] <bigjools> I'm looking at this rabbit test failure
[11:41] <bigjools>         self.useFixture(EnvironmentVariableFixture('HOME', '/nonsense/value'))
[11:41] <bigjools> wtf?
[11:41] <LPCIBot> Project windmill-devel build #228: STILL FAILING in 40 min: https://lpci.wedontsleep.org/job/windmill-devel/228/
[11:41] <bigjools> given that the test is failing trying to write cookies, that looks very suspect :)
[11:41] <lifeless> bigjools: see the 3 line comment before that
[11:42] <lifeless> bigjools: the fixture is meant to self isolate and export HOME itself whenever it runs erlang stuff
[11:42] <lifeless> bigjools: this makes it fail-fast if the fixture doesn't do that.
[11:42] <lifeless> bigjools: the test fails intermittently, so that isn't the issue.
[11:42] <bigjools> ah ok
[11:42] <bigjools> the comment didn't say that
[11:42] <lifeless> bigjools: I added that in after I found that the soyuz test fixtures chdired
[11:42] <bigjools> yay for soyuz
[11:43] <lifeless> nn
[11:43] <bigjools> thanks lifeless, nn
[11:43] <lifeless> uhm
[11:43] <lifeless> I suggest getting it to fail locally :)
[11:43] <lifeless> or getting more data on what goes on when it fails.
[11:44] <lifeless> the current code *can* pass, in a full test run. It can also fail in a full test run : so its not trivially broken or trivially correct.
[11:44] <lifeless> elliot has put me in touch with vmware
[11:44] <lifeless> I will be dropping one of their guys a brain dump tomorrow
[11:45] <lifeless> bigjools: I'm happy that you're looking at it, just noting we have some backup coming in.
[11:45] <lifeless> anyhow, *nn* for reals, I'm hosting tomorrow, so can't sleep through it :>
[11:45] <bigjools> lifeless: yeah well I'm not looking too hard, just curious
[11:45] <bigjools> lifeless: that's ok we'll sleep through it too
[11:50] <bigjools> does our test runner always run tests in the same order?
[11:50] <danilos> bigjools, my experience is that it does
[11:50] <bigjools> ok ta
[11:55] <bigjools> allenap: so in the "daemon" function there's a few print statements that are not in the test output
[11:55] <bigjools> some of them trying to print $HOME
[12:04] <allenap> bigjools: I'm looking but I have to go now.
[12:27] <LPCIBot> Project windmill-devel build #229: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/229/
[13:13] <adeuring> bigjools: do you have time to talk about bug 793630?
[13:13] <_mup_> Bug #793630: better cronscript setup: remove hard-coded paths from cronscripts/publishing/cron.base-ppa <Launchpad itself:Triaged> < https://launchpad.net/bugs/793630 >
[13:13] <bigjools> adeuring: not right now I am heading to lunch, later is ok
[13:13] <adeuring> bigjools: ok; ping me when you have time
[13:13] <bigjools> ok
[13:18] <danilos> jtv, I am going to suppose you are off already since you haven't responded to my review request ;) cheers
[13:39] <Ursinha> good morning launchpadders
[14:07] <danilos> Ursinha, good morning :)
[14:30] <cr3> interesting, some site proxying launchpad but adding its own javascript is being indexed by google: http://www.anticensure.com/?__new_url=aHR0cHM6Ly9idWdzLmxhdW5jaHBhZC5uZXQvbHAtdXBzdHJlYW0tdG9vbHMvK2J1Zy8zMzQ0NTY=
[14:35] <benji> they could use a robots.txt file
[14:38] <dobey> nice; a big red box covering everything up
[14:47] <jcsackett> sinzui: up for mumbling?
[14:47]  * sinzui tries
[14:48] <LPCIBot> Project windmill-devel build #230: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/230/
[14:49] <jcsackett> sinzui: is sip working better for you?
[14:50] <danilos> mrevell, hi
[14:50] <danilos> mrevell, how's it going?
[14:50] <mrevell> Hello danilos
[14:50] <mrevell> I'm okay thanks, how are you danilos?
[14:51] <danilos> mrevell, pretty good as well, thanks :)
[14:51] <mrevell> That is excellent news.
[14:51] <danilos> mrevell, that's all I needed from you, thank you :P
[14:51] <danilos> mrevell, but then again, do you have a minute or two to discuss one nice little branch I've got going
[14:52] <mrevell> Yes, certainly :) Some kind of phone call, or is IRC okay ?
[14:52] <danilos> mrevell, phone call is probably easier for start
[14:52] <danilos> mrevell, you can pick mumble or skype :)
[14:53] <danilos> mrevell, this is about bug 772754, fwiw
[14:53] <_mup_> Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <qa-ok> <story-better-bug-notification> <Launchpad itself:In Progress by gary> < https://launchpad.net/bugs/772754 >
[14:53] <mrevell> I'll strike a blow for freedom and go with Mumble. Just a sec.
[14:54] <mrevell> danilos, What channel are you in?
[14:54] <danilos> mrevell, yellow, but it seems mumble doesn't work for me
[14:55] <mrevell> Skype it is.
[14:55] <danilos> mrevell, yeah :/
[14:59] <LPCIBot> Project devel build #807: STILL FAILING in 6 hr 0 min: https://lpci.wedontsleep.org/job/devel/807/
[15:27] <jml> sinzui: ping
[15:27] <sinzui> hi jml
[15:28] <jml> sinzui: I'm otp atm, but would you be able to have a call w/ me sometime in the next hour and a half?
[15:28] <sinzui> yes
[15:30] <jml> sinzui: cool. ok if I ping you when I'm ready?
[15:30] <sinzui> yep
[15:31] <jml> Ursinha: https://dev.launchpad.net/Projects/Disclosure
[15:37] <jml> bah
[15:42] <cr3> hi folks, I would appreciate if someone could land the branch that was just approved in this merge request: https://code.launchpad.net/~cr3/launchpad/hwsubmissionset_search/+merge/63768
[15:57] <jml> sinzui: https://dev.launchpad.net/PolicyAndProcess/FeatureDevelopmentCheckpoint
[16:13] <bac> hi bigjools -- care to chat/pre-imp about bug 776437
[16:13] <_mup_> Bug #776437: Enable ARM builders for PPA via API <api> <escalated> <not-pie-critical> <oem-services> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/776437 >
[16:13] <bigjools> ok
[16:13] <bac> bigjools: so are you ok with lifeless' suggestion, which is basically to do the thing your first comment said not to do ?  :)
[16:13] <bigjools> heh
[16:14]  * bac needs to review the lp.commercial explosion
[16:14] <bigjools> given the fact they're desperate for this, JFDI
[16:14] <bigjools> lp.commercial is a pox
[16:14]  * bac hopes no one 'bzr blames' that one
[16:15] <bigjools> ;)
[16:15] <bac> well, i created it...i didn't over use it.
[16:15] <bigjools> well I think it's fine for commercial stuff
[16:15] <bigjools> but to use it for anything else is simply crazy
[16:15] <bac> so the basics for this bug should be straightforward, i assume
[16:16] <bigjools> let me see
[16:18] <bigjools> bac: see enabled_restricted_families in the model
[16:18] <bigjools> expose it on the API.  It already has a setter/getter
[16:19] <bigjools> and ensure the usual privileges
[16:19] <bac> bigjools: rt
[16:26] <timrc> I keep running into problems... when I type 'make run' now I get the following error: http://paste.ubuntu.com/627411/
[16:27] <timrc> has anyone seen this?  I think it started when I started running launchpad out of multiple branches on the same system
[16:27] <jml> hmm.
[16:27] <jml> timrc: is there another Launchpad instance running?
[16:28] <timrc> jml, no, and I've rebooted the VM
[16:28] <jml> timrc: I haven't encountered the problem before, so I'm winging it... does /var/tmp/mailman/data/master-qrunner.pid exist? what about /var/tmp/mailman/data/?
[16:29] <timrc> jml, the directory does indeed exist, but not the pid file
[16:29] <jml> ok, so first up that's a lousy error from get_pid, probably bug report worthy
[16:30] <jml> timrc: I guess I don't know why 'make run' is trying to stop mailman.
[16:36] <flacoste> bigjools: i'm trying to fix bug 797088
[16:36] <_mup_> Bug #797088: Launchpad has removed privileges that UDD importer requires to function <regression> <udd> <Launchpad itself:In Progress> <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/797088 >
[16:36] <flacoste> bigjools: and my simple tests isn't reproducing the problem
[16:36] <flacoste> the security uses checkUpload
[16:36] <flacoste> security checker
[16:37] <flacoste> you can see it in security.py:2600
[16:37] <bigjools> flacoste: is this the updates pocket that you need to pass?
[16:38] <flacoste> bigjools: couldn't I just use verifyUpload() and not bother with the pockets check in that case?
[16:38] <flacoste> since i think that's the difference between verifyUpload and checkUpload, no?
[16:38] <flacoste> which is very confusing to be honest
[16:38] <bigjools> upload permissions are confusing generally
[16:39] <bigjools> so yes use verifyUpload
[16:39] <jml> flacoste: sorry about the names. I  was running out of ideas.
[16:39] <jml> timrc: oh sorry, I got distracted. I'm not sure how to help further though :(
[16:40] <timrc> jml, I think mailman is a red herring... the exception is actually occurring w/ /var/tmp/development-librarian.pid
[16:40] <bigjools> flacoste: checkUpload is the same as verifyUpload but with the pocket check
[16:40] <flacoste> i know
[16:41] <jml> timrc: ahh
[16:41] <timrc> the file exists, but it's empty, which is why we get the ValueError and not the IOError
[16:41] <flacoste> bigjools: after reading the implementation code :-)
[16:41] <bigjools> flacoste: shit, we can READ!
[16:41] <jml> timrc: man that's a lousy error
[16:41] <jml> flacoste: fix the docs! change the names! storm the castle!
[16:41] <bigjools> man, the damn air force is dogfighting over my house again
[16:41] <flacoste> bigjools: time to move ;-)
[16:42] <timrc> jml, I'll file the bug on improving the exception to at least include the file name... is there a make command that removes all the pid files?
[16:42] <flacoste> jml: but why two different checks in the first place? why not one with pocket=None for when you don't care about the pocket? or does the client should always care about the pocket
[16:42] <bigjools> flacoste: good idea
[16:43] <timrc> (not that removing the file solved my problem,  argh)
[16:43] <jml> timrc: not that I know of.
[16:43] <bigjools> flacoste: it's a conflict of requirements
[16:43] <jml> flacoste: can't recall, sorry. maybe I was trying to minimize the size of the change
[16:44] <bigjools> some stuff cares deeply about the pocket, other stuff doesn't give a rats
[16:44] <bigjools> and I suspect it's a half-done refactoring
[16:46] <flacoste> 76 references to checkUpload
[16:46] <flacoste> 8 to verifyUpload
[16:46] <flacoste> so I think yeah, it's a minimize changes kind of thing
[16:47] <flacoste> would be better to only use checkUpload with pocket=None for when you want to skip the pocket check
[16:47] <bigjools> checkUpload is more fopr the use of the upload processor
[16:47] <bigjools> and package copier
[16:47] <bigjools> nothing else is going to have a pocket
[16:48] <flacoste> the only client of verifyUpload are bugnomination! and test_branch?
[16:48] <flacoste> !!!
[16:48] <LPCIBot> Project windmill-devel build #231: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/231/
[16:48] <flacoste> and archive.checkUpload
[16:49] <jml> flacoste: ahh, bugnomination
[16:49] <jml> flacoste: yeah, I remember this.
[16:49] <jml> flacoste: it was too hairy to change at the time, and I was already deep in yak shaving by giving soyuz an actual API for checking this stuff.
[16:50] <bigjools> something in the bugs code is using SPPH directly too.  it needs smacking
[16:50] <jml> bigjools: package branches have pockets.
[16:51] <bigjools> oh boy
[16:51] <jml> well, some of them do.
[16:51] <bigjools> I can see the generalised suite work getting bigger and bigger :(
[16:51] <jml> which sort of makes sense because writing to certain package branches is (will be?) equivalent to an upload
[16:51] <bigjools> right
[16:51] <jml> bigjools: I like to think of it as becoming more and more valuable
[16:52] <bigjools> as in costing more? :)
[16:52] <jml> no, that other thnig
[16:52] <jml> benefit.
[16:52] <bigjools> more work is benefit?
[16:52] <flacoste> bigjools: translations is also referencing SPPH direclty
[16:52] <bigjools> flacoste: RARGH
[16:53] <flacoste> jml: how package branches are tied to pockets?
[16:53] <bigjools> we need better APIs between components
[16:53] <jml> flacoste: SeriesSourcePackageBranch
[16:53] <timrc> so odd, make start_librarian and make stop_librarian seem to work just fine :/
[16:53] <jml> flacoste: official branches are tied to a pocket
[16:53] <jml> timrc: check to see if a librarian is running, kill them all, delete the pid files, try again.
[16:53] <jml> bigjools: *sigh*
[16:54] <bigjools> jml: tired? :)
[16:54] <jml> bigjools: having a Suite object would be a good start toward having better APIs between components
[16:54] <bigjools> totally
[16:55] <bigjools> but I was referring to stuff in bugs and translations poking around with publishing records, that's just wrong
[16:56] <jml> yeah. that's often because it's the only way provided by existing APIs to do a thing, and because sometimes it feels easier to use existing APIs than add new ones.
[16:58] <bigjools> we need to better differentiate between internal and external APIs then
[16:59] <matsubara> jml, lunch just arrived. could you give me a few to eat and then we can have our 1-on-1?
[16:59] <jml> matsubara: sure.
[16:59] <matsubara> thanks, brb
[17:00] <jml> bigjools: that'd be nice
[17:00] <bigjools> jml: services-orientated architecture! :)
[17:00] <jml> bigjools: Ooh. I read about those in _Wired_
[17:00] <jml> bigjools: I hear they're really cloudy.
[17:01] <bigjools> lol
[17:08] <flacoste> bigjools: are you -1 on getting rid of verifyUpload and allowing pocket=None to checkUpload for case where you only care about SourcePackage (and not the SuiteSourcePackage)?
[17:09] <flacoste> if you are not, i can shave that yak on my branch
[17:09] <bigjools> flacoste: I'd favour renaming the methods so that the confusion is removed.  I'm a bit wary of someone making a change to the upload processor and forgetting to pass pocket.
[17:09] <bigjools> because it *is* required in that case or trouble will ensue
[17:11] <bigjools> something like verifyIncomingUpload() and the other one could be personCanUpload()
[17:11] <flacoste> bigjools: actually, currently if you pass pocket=None, it works :-)
[17:11] <flacoste> iow, there is no check that pocket is actually a valid one :-)
[17:11] <flacoste> so if the distro isn't in SUPPORTED or CURRENT, it's basically fine :-)
[17:11] <flacoste> (return True)
[17:12] <bigjools>  /o\
[17:12] <bigjools> what a mess
[17:12] <flacoste> there are 800 checkUpload reference
[17:12] <flacoste> not all of them are to IArchive.checkUpload but still
[17:13] <flacoste> i'm not shaving that yak today :-)
[17:13] <bigjools> it's a hairy yak
[17:13] <flacoste> i could be convinced of renaming verifyUpload
[17:13] <flacoste> only 8 references
[17:13] <bigjools> right
[17:13] <flacoste> checkUploadWeDontCareAboutPocket?
[17:13] <flacoste> would make it obviously silly
[17:14] <bigjools> looking at it, that one is called from the upload processor as well.  Hooray.
[17:14] <bigjools> so it needs to be doesPersonHaveUploadRights or similar I think
[17:14] <flacoste> bigjools: indirectly though
[17:15] <bigjools> naming is hard :)
[17:15] <flacoste> bigjools: i don't see references to verifyUpload in lib/lp/archiveuploader
[17:15] <bigjools> but you get my drift I hope
[17:15] <bigjools> yeah it's indirect
[17:15] <flacoste> through checkUpload
[17:15] <flacoste> because checkUpload is verifyUpload + pocket check
[17:15] <bigjools> verifyPersonCanUpload() maybe?
[17:16] <flacoste> i really don't think two APIs here pull their weight to be honest
[17:16] <bigjools> I like that one
[17:16] <flacoste> checkUpload and verifyPersonCanUpload
[17:16] <flacoste> not sure it makes a lot of sense
[17:17] <bigjools> it would if you knew soyuz code more :)
[17:17] <flacoste> especially when you grep
[17:17] <flacoste> and see that everything uses checkUpload apart 3 call sites
[17:17] <flacoste> actually 2
[17:17] <flacoste> bugnomination
[17:17] <bigjools> yeah those are the ones that just need to know that person is an uploader
[17:17] <flacoste> and that new launchpad.Edit permission checker on sourcepackage
[17:17] <timrc> jml, looks like I had to use a big stick approach and just whack everything in /var/tmp
[17:17] <bigjools> which is why I suggested verifyPersonCanUpload
[17:18] <flacoste> but that's also what checkUpload does
[17:18] <bigjools> not exactly
[17:18] <flacoste> verify that the person has upload permission
[17:18] <flacoste> plus a pocket check
[17:18] <flacoste> which is person independant
[17:18] <bigjools> it checks that the person can upload that package at that time
[17:18] <flacoste> the series status representing time here?
[17:18] <bigjools> yes
[17:19] <matsubara> jml, I'm back. voip?
[17:19] <jml> matsubara: sure.
[17:20] <jml> matsubara: 7608
[17:23] <bigjools> flacoste: so for me these are 2 conceptually different things.  One is "is this person an uploader?", the other is "should we let this upload in?"
[17:23] <bigjools> it's just that the parameter list is quite similar
[17:23] <flacoste> bigjools: there is another API for should we let this upload in, it's the checkUpload(upload) method in the archiveuploader
[17:24] <flacoste> which makes more sense as a signature
[17:24] <flacoste> and why the heck are we always passing sourcepackage and suitesourcepackage as tuples?
[17:24] <bigjools> flacoste: no, those are policies
[17:25] <flacoste> (distroseries, sourcepackagename) or (distroseries, sourcepackagename, pocket)
[17:25] <bigjools> policy checks are completely different beasts
[17:25] <bigjools> they are one aspect of the overall check
[17:25] <flacoste> wouldn't the policy check delegate to the archive.checkUpload at some point?
[17:25] <bigjools> the other way around
[17:26] <flacoste> i don't see any call to policy checks in archive.checkUpload
[17:26] <bigjools> you were talking about the one in archiveuploader I thought?
[17:27] <bigjools> the code is in a bit of flux at the moment since we're ripping out a lot of the policy stuff in archiveuploader and replacing it with a more general framework that works with derived distros syncing
[17:28] <LPCIBot> Project parallel-test build #40: STILL FAILING in 1 hr 2 min: https://lpci.wedontsleep.org/job/parallel-test/40/
[17:28] <bigjools> .checkUploadToPocket() is a policy check, it's just hard-coded instead of using the policy framework
[17:29] <flacoste> ah
[17:29] <flacoste> then that's the real fix
[17:29] <flacoste> move checkUploadToPocket to a policy
[17:30] <jml> '<bigjools> flacoste: so for me these are 2 conceptually different things.  One is "is this person an uploader?", the other is "should we let this upload in?"' – that's a really good way of putting it.
[17:30] <flacoste> and at that point IArchive.checkUpload and IArchive.verifyUpload are identical
[17:31] <flacoste> and we can merge them (and possibly rename it)
[17:31] <flacoste> bigjools: does that sound sensible?
[17:32] <flacoste> bigjools, jml: if any of you want to review https://code.launchpad.net/~flacoste/launchpad/bug-797088/+merge/64711
[17:32] <bigjools> flacoste: yes but I think I'd prefer you left it TBH since I want to do more than that
[17:33] <flacoste> bigjools: don't worry, i wasn't goind to tackle it
[17:33] <bigjools> the work to make the uploader use the new policy framework is not trivial
[17:33] <bigjools> flacoste: ok :)
[17:33] <flacoste> just wanted to have a clear conscience by leaving this mess behind :-)
[17:33] <flacoste> i saw the mess, didn't do anything about it
[17:34] <flacoste> but it's because the professionals are coming in to clean it up ;-)
[17:34] <bigjools> ha
[17:34] <bigjools> it's one of the smallest messes in soyuz :)
[17:35] <bigjools> flacoste: failUnless -> assertTrue
[17:36] <flacoste> bigjools: ok, think positive ;-)
[17:36] <bigjools> right :)
[17:36] <flacoste> i can change that
[17:36] <bigjools> I think we deprecated the failXXX methods
[17:37]  * flacoste wasn't aware
[17:37] <flacoste> and fixed
[17:41] <bigjools> flacoste: r=me!
[17:41] <flacoste> bigjools: thanks!
[17:43] <jml> matsubara: https://dev.launchpad.net/Projects/DerivativeDistributions
[17:44] <bigjools> jml: did you see this: https://dev.launchpad.net/Soyuz/DerivativeDistributions
[17:48] <jml> bigjools: no,  I hadn't.
[17:49] <bigjools> mostly written for devs but useful for techy users
[17:49] <jml> cool. I'll look at that soon.
[17:49] <bigjools> ah balls, call in an hour
[17:51] <LPCIBot> Project db-devel build #637: FAILURE in 6 hr 1 min: https://lpci.wedontsleep.org/job/db-devel/637/
[17:52] <LPCIBot> Project windmill-db-devel build #393: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-db-devel/393/
[18:03] <timrc> lifeless, ping
[18:08] <jml> timrc: he's out.
[18:08]  * jml is off for the day.
[18:12] <Ursinha> bye jml
[18:12] <timrc> jml, thanks...
[18:12] <jml> g'bye
[18:12] <timrc> abentley, you there?
[18:17] <abentley> timrc: hi.
[18:21] <timrc> abentley, I'm trying to adapt the archive api to enable setting of the private attribute, this method seems to break a lot of unrelated tests... can you easily identify anything I may be doing wrong?  It's not a lot of code, http://paste.ubuntu.com/627484/
[18:22] <timrc> the tests I'm failing are: http://paste.ubuntu.com/627486/ -- it's odd, I'm able to create ppas from launchpad.dev and I'm able to set them private via the api
[18:23] <abentley> timrc: I'd expect Archive.private is used in composing a lot of Storm expressions, and a python property that's not a Storm column wouldn't work for that.
[18:26] <timrc> abentley, how would it know any differently if I expose private as a getter / setter ?
[18:26] <timrc> would think it would be completely transparent
[18:27] <timrc> but I don't know much of anything about Storm, so... :/
[18:27] <abentley> timrc: It's not at all transparent.  You're dealing with the class of the attribute, not the attribute itself in a Storm expression.
[18:28] <timrc> abentley, let me ask you this, do you know of any other places in launchpad where we try to keep the internal and external interface to an attribute consistent with Python properties?  I originally implemented this with a mutator but lifeless suggested this other approach with the Python property
[18:28] <abentley> timrc: e.g. IStore(Archive).find(Archive, Archive.private == True) is used to find all private archives.
[18:30] <abentley> timrc: generally a property is better than a mutator, and a storm column is better than a property.
[18:31] <abentley> timrc: I've used properties myself, but that was before I found out about storm_validator, which allows columns to be used in many places where properties would otherwise be required.
[18:32] <abentley> timrc: e.g. Job.status used to be a property, but was recently changed to use a storm_validator instead.
[18:35] <cody-somerville> Hey. I'm getting "ProgrammingError: text search configuration "default" does not exist" when my local dev instance attempts to execute sql. Anyone know what I need to do to fix this?
[18:38] <abentley> cody-somerville: perhaps you need to run utilities/launchpad-database-setup
[18:38] <abentley> cody-somerville: beware that this will trash any existing Postgres databases on your system.
[18:39] <cody-somerville> abentley, Yea. It doens't look like there is anything new in there for me to run
[18:39] <cody-somerville> it has to do with the text search stuff I think that lifeless did
[18:40] <abentley> cody-somerville: And have you done "make schema"?
[18:40] <cody-somerville> Yes.
[18:40] <abentley> cody-somerville: Okay, I've never seen the error you describe, so I don't know what the problem is.
[18:41] <abentley> generally, those two are enough to hard-reset your database.
[18:41] <timrc> abentley, so to make this work for Storm expressions I'll need to use storm_validator?  Did you encounter this issue I'm having when you used properties?  Is there a work around?
[18:42] <abentley> timrc: I didn't experience the issue you're having, because I originally implemented Job.status as a property, so there were no existing uses to break.
[18:42] <timrc> abentley, ah hah
[18:43] <abentley> I don't believe there's a work around.
[18:43] <timrc> abentley, I think I'd need to basically rename private to _private
[18:43] <abentley> I don't know whether it's appropriate for a validator to have side-effects.
[18:43] <timrc> abentley, but that seems like a big change
[18:44] <abentley> If it is, then a validator would be the right solution.  If not, then I'd go back to the mutator.
[18:45] <timrc> There are 15 places that need to be updated, I'll try that, re-test and submit a merge proposal and see where that goes :)
[18:48] <abentley> timrc: The motivation for changing Job.status from a property to a column was so that Job.status could be used in storm expressions, instead of Job._status.  It's certainly possible that a branch which introduced Archive._private into Storm expressions would be rejected.
[18:51] <timrc> abentley, ok
[18:51] <timrc> abentley, I will look at Job.status for how to use storm_validator
[18:51] <jcsackett> sinzui: up to chat a bit?
[19:59] <jcsackett> sinzui: time to chat about some package-picker stuff?
[19:59] <sinzui>  I do.
[20:00] <sinzui> is mumble working?
[20:00] <jcsackett> i heard you.
[20:01] <jcsackett> sinzui: i can hear you. it would appear you can't hear me.
[20:02] <sinzui> sip?
[20:02] <sinzui> I have empathy back up
[20:04] <jcsackett> calling now.
[20:06] <jcsackett> sinzui: bug 698020 bug 698022 and bug 698024
[20:09] <sinzui> jcsackett, http://pastebin.ubuntu.com/627558/
[20:20] <jcsackett> sinzui: disconnected. calling you again now.
[20:20] <sinzui> okay
[20:51] <matsubara> danilos, hi
[20:52] <matsubara> danilos, could you review two small oops-tools branch for me?
[20:56] <LPCIBot> Project devel build #808: STILL FAILING in 5 hr 57 min: https://lpci.wedontsleep.org/job/devel/808/
[20:59] <cody-somerville> Does that mean trunk is broken ^^?
[21:01] <lifeless> maybe
[21:08] <matsubara> abentley, hi there, could you review two small oops-tools branch for me?
[21:08] <abentley> matsubara: sure.
[21:08] <matsubara> abentley, first one: https://code.launchpad.net/~matsubara/oops-tools/html-report-urls-broken/+merge/64731
[21:08] <matsubara> abentley, second one: https://code.launchpad.net/~matsubara/oops-tools/update-deprecated-setttings/+merge/64739
[21:11] <abentley> matsubara: Any reason not to use the URL generation stuff in Python?
[21:14] <matsubara> abentley, how do you mean?
[21:16] <abentley> matsubara: get_absolute_url uses string concatenation rather than actual url handling to generate its urls, which makes it more brittle.  Is there a reason why that's a good tradeoff?
[21:18] <matsubara> abentley, just seemed like the easiest thing to do and it seems to be the recommended way in django docs: https://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs#get-absolute-url
[21:21] <abentley> matsubara: in that example, they're dealing with an int, so it's not string concatenation.
[21:21] <matsubara> abentley, I didn't add the get_absolute_url method to the model as suggested in the docs because the dbsummary.py code doesn't use the Oops object itself. It has some optimization to fetch all necessary oopses using a single SQL query and the data structure returned doesn't have the oops object, just the oops id
[21:23] <matsubara> abentley, or you mean I should be using urlparse.urljoin()?
[21:23] <abentley> matsubara: Yes, but ideally you'd be escaping the oops-id.
[21:26] <abentley> matsubara: e.g. with urllib.urlencode
[21:26] <flacoste> what does it mean when i do ec2 land and after
[21:26] <flacoste> Running tests... (output is available on http://ec2-50-19-153-15.compute-1.amazonaws.com/)
[21:26] <flacoste> i get
[21:26] <flacoste>      8kB     1kB/s /
[21:27] <flacoste> like a stalled bzr progress bar
[21:27] <flacoste> that's two run that are stalled like that
[21:28] <bac> ec2 instance is having difficulty talking to LP?
[21:30] <lifeless> yup
[21:33] <flacoste> so i should just kill the run and try again later?
[21:34] <lifeless> or let it continue
[21:48] <flacoste> sinzui: do you recall why you mapped NoSuchSeries exception to 400 on the webservice (i would have expected 404)?
[21:48] <sinzui> flacoste, typo?
[21:48] <flacoste> https://code.launchpad.net/~sinzui/launchpad/api-additions/+merge/6329
[21:49] <flacoste> well, it's spelled BAD_REQUEST
[21:49] <flacoste> so that's a pretty big typo :-)
[21:49] <mwhudson> jelmer: what's the story with lots of large bzr-svn imports failing after the last rollout?
[21:49] <mwhudson> https://code.launchpad.net/~vcs-imports/gcc/trunk failing is bad news for linaro
[21:49] <flacoste> "
[21:49] <flacoste> When calling distribution.getSeries() with an invalid name or version I get
[21:49] <flacoste> an "HTTP Error 500: Internal Server Error". The content of the exception
[21:49] <flacoste> ('NoSuchDistroSeries') is correct about the fact that there is no such
[21:49] <flacoste> distro series but I would have preferred if the method returns [400]
[21:49] <flacoste> "
[21:50] <jelmer> mwhudson: it's the new fetching of tags :-/
[21:50] <mwhudson> jelmer: ah
[21:50] <mwhudson> jelmer: is there a bug for it?
[21:51] <flacoste> sinzui: if you can't recall the justification for this, i'll just file a new bug and change it to 404
[21:51] <flacoste> https://bugs.launchpad.net/launchpad/+bug/358332
[21:51] <_mup_> Bug #358332: [API] OOPS when distribution.getSeries() is called with an invalid name or version <api> <lp-registry> <oops> <story-series-milestones-releases> <Launchpad itself:Fix Released by sinzui> < https://launchpad.net/bugs/358332 >
[21:52] <flacoste> seems that the user suggested 400
[21:52] <flacoste> matsubara suggested NotFound, but you went ahead and took the user suggestion
[21:52] <jelmer> mwhudson, not that I'm aware of, please file one
[21:53] <jelmer> mwhudson, when does a user timeout happen on the import slaves exactly/
[21:53] <jelmer> ?
[21:53] <mwhudson> jelmer: when there is no progress reported for ... the value of some config variable ... seconds
[21:53] <mwhudson> jelmer: i think it's an hour
[21:53] <sinzui> flacoste, I cannot think of reason, so file a new bug
[21:54] <jelmer> oh, wow
[21:54] <mwhudson> jelmer: well, no output on stdout, and we have a special progress bar thing
[21:54] <lifeless> flacoste: +1 on making it 404
[21:54]  * flacoste gets the razor out
[21:55] <mwhudson> jelmer: although, um: http://launchpadlibrarian.net/73372571/vcs-imports-gcc-trunk.log
[21:58] <mwhudson> jelmer: yeah, it's an hour
[21:59] <mwhudson> jelmer: https://bugs.launchpad.net/launchpad/+bug/797915
[21:59] <_mup_> Bug #797915: large bzr-svn imports failing <code-import> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/797915 >
[22:01] <LPCIBot> Project windmill-db-devel build #394: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-db-devel/394/
[22:02] <LPCIBot> Project parallel-test build #41: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/parallel-test/41/
[22:02] <jelmer> mwhudson: thanks
[22:03] <mwhudson> jelmer: i've also seen imports crash with MemoryError -- is that possibly related?
[22:08] <jelmer> mwhudson: possibly - finding the tags requires more history analysis so possibly more memory usage
[22:11] <lifeless> flacoste: I'm planning on splitting my day into two today; there is a sale on in the city for various things we need
[22:19] <flacoste> lifeless: sure, no problem
[22:19] <flacoste> lifeless: changing from 401 to 404 will break backward incompatible change
[22:19] <flacoste> unless we versioned the exception error code, which i suspect we don't
[22:19] <flacoste> do we care?
[22:32]  * flacoste does not
[23:35] <sinzui> wgrant, wallyworld_, StevenK. I am told I am picking up a child. I believe I will more than an hour late. I will make a showing when I return to see if I am needed.
[23:35] <wallyworld_> sinzui: we can delay the call till you return?
[23:36] <thumper> hi hackers
[23:39] <wallyworld_> thumper: how's they hanging?
[23:39] <mwhudson> jelmer: https://code.launchpad.net/~vcs-imports/gcc/trunk seems pretty stuck
[23:39] <jelmer> mwhudson, I'm trying it locally, but it seems to be working here
[23:40] <mwhudson> jelmer: oh good!
[23:40] <jelmer> mwhudson, no :(
[23:40] <mwhudson> yeah
[23:40] <mwhudson> jelmer: tdb vs sqlite or something?
[23:43] <mwhudson> jelmer: it doesn't seem to be using a lot of cpu https://pastebin.canonical.com/48542/
[23:44] <jelmer> mwhudson: hmm
[23:44] <jelmer> mwhudson, swapping a lot perhaps?
[23:44] <mwhudson> yeah
[23:45] <jelmer> mwhudson, the home directories are just on local disk right?
[23:45] <mwhudson> jelmer: yeah
[23:46] <mwhudson> maybe we should be scaling the concurrency down a bit
[23:46] <mwhudson> jelmer: see #launchpad-ops for, well, ops stuff
[23:47] <LPCIBot> Project db-devel build #638: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/638/
[23:50] <thumper> wallyworld_: hanging mostly normally, you?
[23:51] <wallyworld_> thumper: mired in javascript. plus kindle screen just gone bad :-(
[23:51] <thumper> wallyworld_: what's the problem with your kindle?
[23:51] <thumper> wallyworld_: Rachel suggests charging it
[23:51] <wallyworld_> screen is all messed up. about 1/4 of the screen is all corrupt
[23:52] <wallyworld_> displays garbage, random pixels
[23:52] <thumper> wallyworld_: have you tried rebooting?
[23:52] <wallyworld_> holding power button across for 15 seconds before releasing? yes. aything else?
[23:52]  * thumper shrugs
[23:52] <thumper> send it back?
[23:53] <wallyworld_> bit hard since it was bought over the counter in dallas
[23:53] <thumper> wallyworld_: but amazon still handle the warrenty
[23:53] <wallyworld_> i don't think i can find the receipt :-(
[23:53] <thumper> you shouldn't have to find it
[23:53] <thumper> they have serial numbers
[23:54] <wallyworld_> ah right. i'll email them and see what they say
[23:54]  * wallyworld_ wonders if there's a place to stick a paperclip