[00:08] <LPCIBot> Yippie, build fixed!
[00:08] <LPCIBot> Project db-devel build (263): FIXED in 4 hr 47 min: https://hudson.wedontsleep.org/job/db-devel/263/
[00:31] <huwshimi> Hi. I need someone to review a fix for bug #367877 if anyone is available.
[00:31] <_mup_> Bug #367877: Tabbing between links does not highlight them <confusing-ui> <css> <lp-web> <Launchpad itself:Triaged> <kde4libs (Ubuntu):Invalid> < https://launchpad.net/bugs/367877 >
[00:33] <jml> anyone doing Launchpad development in natty?
[00:33] <wgrant> jml: Yes.
[00:33] <jelmer> jml: yep
[00:33] <wgrant> jml: It mostly works.
[00:33] <wgrant> There are a couple of easy ways to make it work a little more, too.
[00:33] <wgrant> But it
[00:33] <wgrant> 's not perfect.
[00:33] <jml> cool. ec2 land just errored on me.
[00:34] <wgrant> Sure that's not the launchpadlib issue?
[00:34] <jml> it is a launchpadlib issue. not sure about "the"
[00:34] <wgrant> A NameError?
[00:34] <jml> yeah
[00:34] <jml> NameError: global name 'AuthorizeRequestTokenWithBrowser' is not defined
[00:34] <wgrant> The.
[00:34] <jelmer> same here
[00:34] <jml> bugger.
[00:34] <wgrant> Well, 'The' as in the original.
[00:34] <wgrant> Pull devel.
[00:34] <wgrant> Is fixed.
[00:34] <wgrant> That doesn't mean it will work, though.
[00:34] <jml> sweet.
[00:34] <jml> well, baby steps.
[00:35] <wgrant> Because the new launchpadlib has some... other issues.
[00:35] <wgrant> You'll need to remake once you pull.
[00:35] <jml> :(
[00:35] <wgrant> But if your system is untainted by KDE you should be OK.
[00:36] <jml> I have a lot of Qt stuff installed.
[00:36] <jml> I guess the worse that can happen is that it fails.
[00:36] <jml> beautiful
[00:36] <jml> it oopsed
[00:36] <jml> AttributeError: 'NoneType' object has no attribute 'is_reviewed'<br />
[00:38] <jml> huwshimi: what's the MP url?
[00:38] <wgrant> jml: Traceback?
[00:38] <wgrant> That sounds almost like a celebrity issue.
[00:38] <jml> wgrant: http://paste.ubuntu.com/553026/
[00:38] <wgrant> Oh.
[00:38] <wgrant> That is_reviewed.
[00:39] <huwshimi> jml: Sorry, what's a MP?
[00:39] <wgrant> Which test? There are some odd natty failures like that.
[00:39] <jml> huwshimi: a merge proposal
[00:39] <jml> huwshimi: after you've created a branch, you should create a merge proposal, which is a place to discuss the patch and the changes. there's a link on the branch page.
[00:40] <jml> wgrant: uhh, there's no test involved.
[00:40] <jml> wgrant: that was when I authorized my laptop
[00:40] <wgrant> jml: Well, that is awesome.
[00:40] <jml> wgrant: yeah, I'm going to file a bug.
[00:40] <wgrant> jml: You might want to talk to relevant people first.
[00:41] <wgrant> launchpadlib in LP hasn't really worked for a week or so now.
[00:41] <wgrant> It may be known.
[00:41] <huwshimi> jml: Yeah, I haven't created one yet... I didn't have a reviewer, but I can create it without filling that in if it helps.
[00:41] <jml> wgrant: hmm.
[00:41] <wgrant> I haven't seen that particular error before.
[00:41] <jml> huwshimi: yeah. do that. there's a default reviewer which is the whole LP team
[00:41] <jml> or the canonical part of it anyway
[00:41] <huwshimi> jml: OK thanks.
[00:41] <jml> wgrant: it's easy enough to mark bugs as invalid
[00:41] <jml> wgrant: it also appeared to actually authorize
[00:42] <huwshimi> jml: Target branch should just be lp:launchpad right?
[00:42] <jml> huwshimi: yep
[00:43] <jml> hmm
[00:44] <wgrant> jml: Do any of your Product Strategies happen to include making Soyuz less broken, or deleting it or something?
[00:44] <jml> wgrant: yes. derivative distributions.
[00:44] <wgrant> They just stack more brokenness on the perilously stacked brokenness.
[00:45] <jml> wgrant: that's an implementation approach
[00:45] <jml> wgrant: an alternative approach is to use it as an opportunity to clean stuff before you add new things
[00:45] <jml> which is entirely cromulent
[00:45] <wgrant> jml: But there is no time :(
[00:45] <jml> sod that
[00:45] <jml> it's not true
[00:46] <jml> there's no deadline
[00:46] <wgrant> Perhaps this will change on Monday :)
[00:46] <jml> and doing some cleanup will make the dev go faster
[00:46] <wgrant> Long-term, sure.
[00:46] <jml> even in the shorter term
[00:46] <wgrant> But it's clear that nobody in Soyuz has ever though about long-term before :)
[00:46] <huwshimi> jml: Here is the MP: https://code.launchpad.net/~huwshimi/launchpad/highlight-links-367877/+merge/45947
[00:46] <wgrant> The rest of LP, I don't know.
[00:46] <jml> if you're working on a feature for three or so months with even two or three people, that's long enough to make cleanup worthwhile
[00:47] <jml> and it's not like Soyuz is going away
[00:47] <wgrant> :(
[00:47] <jml> I'm not saying that it should be made perfect before we add anything, but there's always time to do things right.
[00:48] <jml> sinzui: you've done a lot of stuff w/ our CSS before, interested in reviewing huwshimi's change? https://code.launchpad.net/~huwshimi/launchpad/highlight-links-367877/+merge/45947
[00:49] <jml> huwshimi: oh, I forgot about #launchpad-reviews
[00:49] <jml> huwshimi: that's another place to ask for reviews
[00:49] <huwshimi> jml: ok should I head over there and ask now then?
[00:49] <jml> huwshimi: although I personally prefer here, because I'm not sure what a dev channel is for other than discussing code changes :)
[00:49] <jml> huwshimi: sure.
[00:50] <wgrant> jml: How goes the rally?
[00:50] <jml> wgrant: pretty well.
[00:51] <jml> wgrant: it's not as talk-y as UDS, so less of me doing the listening part of my job, but it's still good to be here.
[00:52] <thumper> jml: I don't suppose you can see bigjools
[00:52] <huwshimi> jml: When asking for a review is the MP the most important bit of information to provide?
[00:52] <jml> thumper: not from here. I think he's in the UK.
[00:52] <jml> huwshimi: yeah.
[00:53] <thumper> huwshimi: as long as the MP has a decent description
[00:53] <wgrant> thumper: bigjools is asleep.
[00:53] <thumper> wgrant: ah
[00:53] <thumper> ok
[00:53] <wgrant> thumper: What's up?
[00:53] <thumper> wgrant: I was going to get him to look at my changes for the builds' urls
[00:53] <thumper> wgrant: I implemented his suggestion
[00:54] <thumper> so it seems only fair that he reviews it :)
[00:54]  * thumper goes to add him on the MP
[00:54] <jml> thumper: while you're here, can I interest you in reviewing huwshimi's branch?
[00:55] <thumper> the css one above?
[00:55] <wgrant> thumper: Ah, right.
[00:55]  * jml really needs to go get food
[00:55] <jml> thumper: yeah.
[00:55] <wgrant> thumper: He disappeared about an hour ago.
[00:55] <thumper> I'm not a ui reviewer
[00:55] <huwshimi> thumper: OK thanks
[00:55] <jml> thumper: does that still matter?
[00:55] <thumper> for UI stuff?
[00:55] <thumper> perhaps not
[00:55]  * jml doesn't know
[00:56] <lifeless> wgrant: cleanup++
[00:56] <jml> thumper: if there's no UI reviewer in asiapac, and we're going to block UI branches on UI reviewers, then I guess I have a new problem to solve :)
[00:56] <lifeless> I would like to unblock that
[00:56] <jml> crisistunity!
[00:57]  * thumper recommends one or two aussies do it
[00:58] <wgrant> There are lots of us now!
[00:59]  * jml reviews
[01:00] <wgrant> lifeless: The problem is that there is so much cleanup that needs doing, and a lot of it isn't a drive-by sort of thing. :(
[01:00] <jml> huwshimi: did you make some whitespace changes?
[01:02] <jml> huwshimi: anyway, it's good to land as far as I'm concerned.
[01:03] <jml> huwshimi: I've got to head, but if you need help figuring out how to land it, I'm sure either your fellow Aussie colleagues or our fine friends across the Tasman will be able to help.
[01:03] <huwshimi> jml: No I just noticed those in the diff too. The strange thing is the CSS is not indented in those files.
[01:03] <huwshimi> jml: Thanks, have a good night
[01:04] <jml> will do.
[01:04]  * jml out
[01:52] <huwshimi> Hi. Is anyone around who can explain how I land a branch for Launchpad? I have an approved MP.
[01:55] <wgrant> huwshimi: Because the test suite takes so long, we normally run it on Amazon EC2. See https://dev.launchpad.net/EC2Test for setup and usage details.
[01:55] <wgrant> huwshimi: ec2test automatically lands the branch when it's done.
[01:55] <wgrant> Although you might not have PQM access yet.
[01:55] <wgrant> Do you know if you do?
[01:55] <huwshimi> wgrant: Thanks. I don't know.
[01:56] <spm> he does not
[01:56] <lifeless> there is / was a starter document that explained what you need to do to get that
[01:56] <lifeless> oh hai
[01:56] <spm> lifeless: while you're here - how does the qastaging DB get updated? is that a manual only thing? or is it wrapped up in a place I've not yet looked?
[01:57] <lifeless> spm: should happen when staging is updated
[01:57] <spm> ahh. I assumed it wasn't. ta.
[01:57] <wgrant> Note that the last full staging restore failed, so it's been a while.
[01:57] <lifeless> spm: original concept was - copy over, restore to one, run patches, restore to other.
[01:57] <lifeless> spm: as to what scripts etc - I have -no- idea, no visibility at all.
[01:58] <spm> https://code.edge.launchpad.net/~canonical-losas/lp-staging-scripts/trunk
[01:59] <spm> be ware. eyeballs may explode.
[01:59] <lifeless> spm: s/edge.// in your history, plox.
[02:00] <lifeless> spm: also, when doth that redirect kick in?
[02:00] <spm> yeah. just old urls in quick search :-)
[02:00] <spm> I was hoping to get it done yesterday, but dragged awy. likewise today. :-/
[02:00]  * lifeless offers superglue for the fingers
[02:01] <lifeless> spm: bug 457026
[02:01] <_mup_> Bug #457026: bzrsyncd on loganberry using unnecessary amounts of /tmp space <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/457026 >
[02:01] <lifeless> is that still happening?
[02:01] <wgrant> StevenK: The WTFery may be continuing. http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ shows that the .debs are gone, but some of the .udebs remain. p-d-r logs say they were removed, and it finished before the mirroring started... can you check if pool/main/l/linux/acpi-modules-2.6.24-28-386-di_2.6.24-28.83_i386.udeb is still on cocoplum?
[02:02] <spm> lifeless: yes
[02:02] <lifeless> spm: even though we've removed the mirrored area?
[02:03] <spm> lifeless: ? isn't the mirrored area on crowberry?
[02:03] <lifeless> we got rid of having a mirrored area
[02:03] <lifeless> oh right
[02:03] <lifeless> I gets it
[02:03] <spm> https://pastebin.canonical.com/41796/
[02:04] <spm> just an extract. not the full thing.
[02:04] <lifeless> bumped to high
[02:05] <spm> ta
[02:06] <lifeless> flacoste: hi
[02:06] <lifeless> flacoste: if you're still around, who wrote trac-launchpad-migrator ?
[02:07] <wgrant> Wasn't it Fluendo?
[02:08] <lifeless> gmb
[02:08] <lifeless> https://code.launchpad.net/~launchpad/trac-launchpad-migrator/trunk
[02:09] <wgrant> The VCS history isn't reliable.
[02:09] <wgrant> It wasn't originally in that branch.
[02:09] <wgrant> Although the copyright headers could be useful.
[02:09]  * wgrant checks.
[02:09] <wgrant> http://bazaar.launchpad.net/~launchpad/trac-launchpad-migrator/trunk/annotate/head:/migrate.py
[02:09] <wgrant> Fluendo.
[02:09] <lifeless> ah
[02:09] <lifeless> thanks
[02:11] <lifeless> wgrant: perhaps you have an opinion on https://bugs.launchpad.net/trac-launchpad-migrator/+bug/461669, since you seem to know some history
[02:11] <_mup_> Bug #461669: Attachments are looked for in the wrong directory <trac-launchpad-migrator:Triaged> < https://launchpad.net/bugs/461669 >
[02:11] <lifeless> jelmer: ^
[02:13] <huwshimi> wgrant: Just setting up ec2test and at this part https://dev.launchpad.net/EC2Test#setup it talks about setting up my own developer account etc. I assume that's all relevant to me?
[02:13] <wgrant> lifeless: I think that might require some Trac knowledge, and I haven't admin'd a Trac instance in like 5 years. I'm probably not the best person to ask.
[02:13] <wgrant> huwshimi: Yeah.
[02:14] <wgrant> huwshimi: You need an AWS account.
[02:15] <huwshimi> wgrant: Thanks
[02:17] <lifeless> wgrant: can you expand on whats up in bug 438336 ?
[02:17] <_mup_> Bug #438336: Packages still show up on builders page after they are done <lp-soyuz> <soyuz-build> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/438336 >
[02:19] <wgrant> lifeless: Bug #438336
[02:19] <_mup_> Bug #438336: Packages still show up on builders page after they are done <lp-soyuz> <soyuz-build> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/438336 >
[02:19] <lifeless> thanks
[02:20] <lifeless> spm: in bug 431235 - we're now running HA loggerhead, do you know if its single-source-tree or not ?
[02:20] <_mup_> Bug #431235: Allow us to run multiple loggerhead instances from the same codetree <canonical-losa-lp> <launchpad-loggerhead:New> < https://launchpad.net/bugs/431235 >
[02:20] <spm> separate tree
[02:20] <spm> trees
[02:27] <maxb> I can't see bug 431235 :-/
[02:27] <_mup_> Bug #431235: Allow us to run concurrent loggerhead instances from the same codetree <canonical-losa-lp> <launchpad-loggerhead:Triaged> < https://launchpad.net/bugs/431235 >
[02:27] <maxb> probably because it's bugtask is targetted to a deactivated project
[02:28]  * cody-somerville hugs lifeless 
[02:28] <lifeless> maxb: fixed
[02:31] <lifeless> maxb: and the 5 other ones similarly
[02:31] <lifeless> cody-somerville: thanks?
[02:31] <cody-somerville> lifeless, You're welcome. :-)
[02:33] <lifeless> james_w: bug 395200
[02:33] <_mup_> Bug #395200: Allow linking a package upload to a bzr revision <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/395200 >
[02:36] <lifeless> jml: ping
[02:36] <lifeless> spm: hi
[02:37] <spm> yo
[02:37] <lifeless> spm: can you please change the maintainer of https://launchpad.net/qa-tagger to be ~launchpad ?
[02:38] <spm> lifeless: done
[02:38] <lifeless> thanks
[02:40] <lifeless> matsubara-afk: https://bugs.launchpad.net/oops-tools/+bug/701762
[02:40] <_mup_> Bug #701762: "No Production OOPSes found for 2011-01-11. " <OOPS Tools:New> < https://launchpad.net/bugs/701762 >
[02:48] <lifeless> .
[03:03] <lifeless> spm: is bug 660854 still present?
[03:03] <_mup_> Bug #660854: importds are spamming log messages <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/660854 >
[03:04] <lifeless> that was in the early days of the new logging stuff, it may be good now? /me hopes
[03:08] <poolie> is bug 556132 now available for testing on staging or qastaging?
[03:08] <_mup_> Bug #556132: bzr: ERROR: paramiko.SSHException:  Key-exchange timed out; consistent after sending 1GB data <lp-code> <paramiko> <qa-ok> <Bazaar:Invalid> <Launchpad itself:Fix Committed by mwhudson> <Twisted:Fix Released> < https://launchpad.net/bugs/556132 >
[03:08] <lifeless> you can check by looking at the MP to see what rev in devel it got, and at the revno on the qastaging pages
[03:14] <wgrant> lifeless: Hi.
[03:15] <lifeless> hi
[03:15] <wgrant> lifeless: I need a memoization decorator. Do we have one that I'm missing, or should I create a PropertyCache-based one?
[03:16] <lifeless> what for
[03:16] <wgrant> lifeless: Archive.getComponentsForSeries.
[03:16] <lifeless> and how is that different to just @cachedproperty
[03:16] <wgrant> @cachedproperty doesn't do arguments.
[03:16] <lifeless> ah
[03:17] <lifeless> you could fix that
[03:18] <wgrant> It turns a method into a property, though.
[03:18] <lifeless> true that
[03:18] <lifeless> refactor and reuse
[03:18] <wgrant> That was my plan.
[03:18] <lifeless> no, I don't think we have a canned one
[03:18] <wgrant> Thanks.
[03:18] <wgrant> Seems odd.
[03:19] <lifeless> and we'd want cache clearing so using PC is appropriate
[03:19] <wgrant> But I guess performance wasn't much of a concern until recently.
[03:19] <wgrant> Yep.
[03:19] <lifeless> we have a list-memoiser and odd bespoke bits like that
[03:19] <lifeless> wgrant: I'm curious why you need to memoise gCFS
[03:19] <lifeless> but am too tired and buggered to understand the answer today.
[03:20] <wgrant> lifeless: We want to do a component check during copies.
[03:20] <wgrant> To make sure we're not creating invalid publications.
[03:20] <lifeless> sure
[03:21] <lifeless> I've found previously that making the whole thing more set based is generally a bigger win than caching at points
[03:21] <wgrant> Possibly, yes.
[03:21] <lifeless> see e.g. the stuff I did to Archive:+index
[03:21] <wgrant> But it's not clear how best to encapsulate this in a set-based approach.
[03:21] <lifeless> I encourage you to examine the changes I did there for inspiration
[03:22] <wgrant> Set-based would be nice.
[03:22] <wgrant> But it requires a restructure of the publisher and copiers.
[03:22] <wgrant> All the way up.
[03:24] <wgrant> Mmm, I suppose I could see how just setifying the lower parts works.
[03:24] <wgrant> It's not going to be great, though :/
[03:41] <lifeless> wgrant: well thats how we get set based in the entire stack
[03:41] <lifeless> wgrant: one little bit, then add more, then more etc
[03:41] <lifeless> wgrant: otherwise the *best* we can achieve is that we only do one just-in-time lookup per left-hand object
[03:41] <lifeless> wgrant: which frankly still sucks
[03:45] <huwshimi> wgrant: Before you were saying about needing PQM access. Any ideas about how to get it? I couldn't find anything (also apologies for all the hassling).
[03:45] <wgrant> lifeless: You have convinced me to rework most of it :(
[03:46] <wgrant> huwshimi: "all the"? You exaggerate.
[03:46] <wgrant> huwshimi: But as for PQM access, an RT ticket to the Launchpad queue should do it.
[03:46] <wgrant> Let me find the email address...
[03:46] <huwshimi> wgrant: Thanks mate :)
[03:48] <wgrant> huwshimi: A signed email to launchpad@rt.canonical.com  with your public OpenPGP key attached.
[03:48] <wgrant> And then possibly a couple of pokes thrown in spm's direction to expedite processing :P
[03:48] <lifeless> don't forget to use the magic words
[03:48] <huwshimi> wgrant: Ah well I've already sent one of them... I guess on to the poking.
[03:52] <huwshimi> Oh actually I haven't sent one to that address
[03:53] <wgrant> Just ask to be added to the LP PQM keyring.
[03:53] <lifeless> and config file
[03:53] <lifeless> it should be all documented on rocketfuel setup in the internal wiki
[04:01] <lifeless> poolie: https://bugs.launchpad.net/launchpad/+bug/701186
[04:29] <spm> yeah. use the magic word. I don't do nuffin without the magic word.
[04:30] <lifeless> jml: please refine the importance on https://bugs.launchpad.net/launchpad/+bug/695606
[04:30] <_mup_> Bug #695606: recipes shouldn't build if a build was triggered by hand for the set PPA and nothing has changed <Launchpad itself:New> < https://launchpad.net/bugs/695606 >
 spm: is bug 660854 still present? <== yes
[04:32] <_mup_> Bug #660854: importds are spamming log messages <canonical-losa-lp> <lp-code> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/660854 >
[04:34] <spm> ugh. we're not compressing/rotating the spew log that's collecting those.
[04:43] <lifeless> sinzui: hi
[04:43] <lifeless> actually
[04:43] <lifeless> yeah sinzui - https://bugs.launchpad.net/launchpad/+bug/697364 - maybe you have a hunch ?
[04:43] <_mup_> Bug #697364: pop up diff display (e.g. in bug pages) of merge proposal exceeds entire window and is not scrollable (css brain damage) <code-review> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697364 >
[04:52] <wgrant> lifeless: Timing suggests the YUI upgrade.
[04:52] <lifeless> Would not suprise me
[04:53] <wgrant> I think the tag autocompleter glitch is also that.
[04:53] <wgrant> But it may just be a Chromium dev build thing.
[04:53] <lifeless> the bug above I can reproduce
[04:53] <lifeless> tag autcompleter on mav chrome is -fine-
[04:58] <lifeless> spm: please change the maintainer on https://launchpad.net/lp-qa-tools too
[04:59] <spm> done
[04:59] <lifeless> thanks!
[05:03] <lifeless> maxb: is bug 663195 common ?
[05:03] <_mup_> Bug #663195: CVS import fails for b2evolution project: cscvs.cmds.totla.ValidationFailed: directories differ <Launchpad CSCVS:Triaged> < https://launchpad.net/bugs/663195 >
[05:11] <lifeless> \o/ no NEW bugs
[05:11] <lifeless> bah, 2 NEW bugs.
[05:11] <lifeless> nearly-no.
[05:14] <maxb> lifeless: no idea, I'm afraid - generally I try to avoid looking at cscvs :-)
[05:17] <lifeless> :)
[05:36]  * huwshimi is done for the day
[08:31] <adeuring> good morning
[11:17] <matsubara> lifeless, thanks. I'll look into it
[13:06] <gmb> deryck: Do you have a second to run a query on staging for me?
[13:12] <deryck> gmb, definitely
[13:13] <gmb> deryck: https://pastebin.canonical.com/41807/, please. I'm trying to get to the bottom of bug 700490
[13:13] <_mup_> Bug #700490: Incorrect email address presented when merging accounts <Launchpad itself:Incomplete> < https://launchpad.net/bugs/700490 >
[13:23] <deryck> gmb, no results.
[13:28] <gmb> deryck: Probably the staging db was too out of date. Okay, thanks.
[13:28] <deryck> gmb, np.  sorry it wasn't much help.
[13:29] <gmb> deryck: Out of interest, can you just try https://pastebin.canonical.com/41808/.
[13:30] <deryck> sure
[13:30] <deryck> gmb, 3278 rows.  Would you like to see them?
[13:31] <gmb> deryck: Sure.
[13:33] <deryck> gmb, https://pastebin.canonical.com/41809/
[13:34] <gmb> deryck: Ta
[13:34] <deryck> np
[14:27] <henninge> jtv: what's up with your system/connection?
[14:27] <jtv> Something with the wireless router, I think.
[15:01] <bac> abentley, adeuring, allenap , bac, benji, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jcsackett, jtv, bigjools, leonard, mars, mrevell
[15:01] <bac> : meeting ping
[15:01] <jtv> ack thx
[15:01] <adeuring> thanks
[15:01] <gary_poster> thanks
[15:01] <mrevell> me
[15:01] <mrevell> heh
[15:07] <jml> hmm
[15:07] <jml> the ec2 land run I submitted last night passed, but did not submit to PQM
[15:08] <jml> mrevell: good morning :)
[15:08] <mrevell> Hey there jml
[15:08] <bigjools> jml: pqm is borked, I'm discussing it with mthaddon
[15:08] <bigjools> you might be able to help, it's failing when importing testtools
[15:08] <jml> bigjools: oh, that sucks. but that doesn't explain why ec2 land didn't even *try* to send to PQM
[15:09] <bigjools> oh, seems awfully coincident, are you sure?
[15:09] <jml> oh, no, my bad.
[15:09] <jml> SUBMITTED TO PQM:
[15:09] <jml> [r=jml][ui=none][no-qa] Upgrade to testtools 0.9.8 final
[15:09] <jml> however, that might be even more co-incident.
[15:10] <bigjools> haq
[15:10] <jml> bigjools: where are the details of the current PQM issue
[15:10] <bigjools> jml: https://pastebin.canonical.com/41803/
[15:11] <lifeless> needs losa intervention
[15:12] <mthaddon> lifeless: of what kind? I installed python-testtools (why is it suddenly needed?) and then we got a subunit import error
[15:12] <lifeless> mthaddon: will need subunit as well
[15:12] <lifeless> mthaddon: spm upgraded the pqm version on prase last week
[15:12] <mthaddon> lifeless: but we've had successful submissions since then, no?
[15:13] <mthaddon> lifeless: python-subunit ?
[15:13] <lifeless> mthaddon: I wouldn't expect so
[15:13] <mthaddon> lifeless: logs suggest we had one about 12 hours ago, but anyway... I can install python-subunit
[15:14] <sinzui> rockstar: make me an admin so that I can add new members https://launchpad.net/~launchpad-ui-reviewers/+members
[15:14] <mthaddon> lifeless, bigjools: ok, python-subunit installed - bigjools, can you try a resubmit?
[15:14] <lifeless> mthaddon: thanks
[15:15] <bigjools> ok
[15:16] <bigjools> iz sent
[15:20] <lifeless> flacoste: we're triaged https://bugs.launchpad.net/launchpad-project/+bugs?search=Search&field.status=New !
[15:20] <lifeless> flacoste: should I update the bug triage wiki page per my proposal ?
[15:20] <flacoste> lifeless: thanks a lot!
[15:20] <lifeless> flacoste: or do you want to wait for the epic? It didn't seem to be as hot a topic as you thought it might be
[15:21] <flacoste> lifeless: yeah, i was surprised by that
[15:21] <lifeless> deryck: would love your input on bug 120357
[15:21] <_mup_> Bug #120357: Improve the accept/decline/nochange column on +nominations <lp-bugs> <Launchpad itself:New> < https://launchpad.net/bugs/120357 >
[15:21] <flacoste> i wonder if it's because people are in agreement
[15:22] <flacoste> lifeless: but do update it, we can always refine it later
[15:22] <lifeless> kk
[15:23] <deryck> lifeless, ok, I'll take a look.
[15:23] <lifeless> deryck: thanks!
[15:29] <mars> bac, so this is what you were talking about for the Thunderdome? http://www.theweathernetwork.com/your_weather/details/620/2190343/4/ustx0327/plpcities/
[15:30] <mars> bac, oops, that was posted in March! nevermind
[15:31] <bac> mars: i'm sure you'll not even think it is chilly
[15:32] <mars> According to the Weather Network the forecast is 19F with 9F after windchill - that is not fun for a sweater
[15:33] <mars> I didn't know you even had weather like that so far south
[15:33]  * gary_poster knew someone who (my wife reports, as roommate) used to open the bathroom window in January after a shower, living in Rochester NY.  She was from Minnesota.  *She* wouldn't think it was chilly.
[15:34] <jcsackett> mars: it's a shorter winter, but it's still a nasty one in dallas. dallas is in the more northern, wetter part of texas.
[15:35] <sinzui> mars: Some of us believe the planners of the platform assumed Texas is always hot
[15:35] <mars> lol
[15:35] <mars> sinzui, it appears I am guilty of such as well
[15:35]  * sinzui was hoping for Cancun.
[15:36] <flacoste> sinzui: you need to bribe marianna
[15:36] <sinzui> she can come
[15:36] <flacoste> for next year
[15:36] <flacoste> oh, she's there all right
[15:43] <lifeless> flacoste: NZ! :)
[15:43] <flacoste> lifeless: getting 300 people to NZ isn't very cost effective :-/
[15:44] <lifeless> flacoste: depends on hotel rates surely ;P
[15:46] <sinzui> Hawaii (big island) is nice
[15:55] <deryck> lifeless, so that bug is still relevant.  quite an ugly page and set of controls.
[15:55] <deryck> lifeless, you just want an ack from me, or some other ideas, or something else?
[15:56] <lifeless> deryck: if you could triage it (following the shiny new https://dev.launchpad.net/BugTriage) that would be awesome
[15:56] <deryck> lifeless, ah, ok.  sure.
[15:56] <lifeless> deryck: I didn't know enough to assess it
[15:56] <deryck> gotchas
[15:56] <lifeless> gmb: hey
[15:57] <gmb> lifeless: Hi.
[15:57] <lifeless> gmb: curtis and I have pinged for your input in a few bugs recently
[15:57] <lifeless> I'm wondering if you could make some time to help us out
[15:57] <gmb> lifeless: I've only seen yours today, to which I've responded (and I'm trying to write a test for it).
[15:57] <gmb> lifeless: Which other ones did you need input on?
[15:58] <lifeless> flacoste: will you do the defn-of-critical -> defn-of-incident stuff ?
[15:58] <lifeless> gmb: I will have a squiz through the incomplete bugs to find them for you
[15:59] <gmb> lifeless: Thanks. I'll check that my mail filters haven't been swallowing things they shouldn't whilst you look.
[15:59] <lifeless> gmb: it may be the grey filter
[15:59] <sinzui> gmb: you responded to the bug about @users.sourceforge.net. Since I confirmed the address does not exist in staging, we do not know how this could happen
[16:00] <leonardr> james_w, quick question
[16:00] <leonardr> as you know, we'd like to put launchpadlib 1.9.2 into natty
[16:00] <leonardr> 1.9.2 depends on python-keyring 0.5
[16:00] <gmb> sinzui: Yeah, I've no clue. I do wonder if we've not got an entirely accurate story here, but I so far haven't been able to reproduce it by mucking about locally.
[16:01] <leonardr> the current version is 0.2. it's a debian package, and debian is frozen right now
[16:01] <benji> (leonardr: actually it'd be best if it were launchpadlib 1.9.3 and keyring 0.5.1, but that's just a detail)
[16:01] <leonardr> if we got python-keyring 0.5 into debian experimental, would we then be able to get it imported into ubuntu?
[16:02] <flacoste> lifeless: sure, i can do that
[16:03] <gmb> sinzui, lifeless: Just found the message about bug 257940. My filters obviously didn't deem it important enough to bother me with ;)
[16:03] <_mup_> Bug #257940: Bug description doesn't get checked for remote bug links <bridging-the-gap> <bugwatch> <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/257940 >
[16:03] <lifeless> gary_poster: have you seen anything like bug 696134 ?
[16:03] <_mup_> Bug #696134: python-lazr.delegates causes 'No module named restfulclient.errors' from apport-bug <lucid> <Apport:New> <lazr.delegates:Incomplete> <lazr.delegates (Ubuntu):New> < https://launchpad.net/bugs/696134 >
[16:04] <sinzui> gmb: I mark all bug mail generated by myself as waste. I don't blame you.
[16:09] <flacoste> lifeless: should we work on a query to upgrade all timeout/oops/regression bugs to 'Critical'?
[16:10] <gmb> sinzui, lifeless: I need to step out for a bit to collect my wife from work; ping me with any more bug IDs that I might have missed and I'll take a look when I get back.
[16:10] <lifeless> flacoste: I was just going to JFDI it
[16:10] <lifeless> flacoste: act as a mini-audit at the same time
[16:10] <flacoste> lifeless: fine by me
[16:10] <lifeless> gmb: have a look at the 'incomplete' list
[16:10] <gmb> lifeless: Okay, will do.
[16:10] <lifeless> gmb: its ~ 60 bugs and worth an eyeball
[16:11] <gmb> lifeless: Sounds like a good way to end my day.
[16:11] <gmb> Anyway; bbiaw.
[16:11]  * gmb -> exeunt in pursuit of a redhead.
[16:13] <lifeless> ooo
[16:25] <gary_poster> lifeless, I haven't seen that before, and don't have an immediate idea after looking at the logs for that and the related bug.
[16:25] <gary_poster> if it truly is lazr.restfulclient.errors with the problem, and not merely lazr.restfulclient, then that might indicate a packaging problem (not including __init__.py, say; otherwise, if it is a problem with lazr.restfulclient, it might be another namespace-packages-are-fragile bug.
[16:25] <gary_poster> both of those are just random guesses though
[16:26] <lifeless> Ursinha: do my comments in bug 701966 make sense to you ?
[16:26] <_mup_> Bug #701966: None: None OOPS with various scripts <oops> <Launchpad itself:Invalid> < https://launchpad.net/bugs/701966 >
[16:26] <Ursinha> whoa, let me see
[16:28] <lifeless> Ursinha: also, I've just mailed the list saying that the new triage rules are in effect - we can all triage when filing bugs now
[16:28] <Ursinha> right, ok, makes sense
[16:30] <james_w> leonardr, that would be one way. We could go directly to Ubuntu as well.
[16:30] <james_w> leonardr, I just realised that we should talk to barry about this, as he maintains the launchpadlib packages in Debian now
[16:30] <james_w> leonardr, I can find him later to discuss it if you like
[16:31] <leonardr> james_w, that would be great
[16:31]  * leonardr also needs to talk to barry for an unrelated reason
[16:32] <Ursinha> lifeless, I'm not triaging while I'm filing because I don't know the severity of the oopses or if they're false alarms. I'm filing bugs for all oopses I found and asking people about them, trying not to lose track of the oopses in a first moment
[16:32] <lifeless> Ursinha: per zero-oops-policy they are critical
[16:32] <james_w> lifeless, I'm going to discuss having estimation on blueprints as well with mounir later, so don't worry about it in the LEP for now
[16:32] <lifeless> flacoste: I've updated z-o-p for squads, could you check I got it as you would have put it?
[16:32] <lifeless> james_w: ok
[16:32] <lifeless> james_w: thanks for letting me know
[16:33] <flacoste> lifeless: z-o-p?
[16:33] <lifeless> flacoste: zero oops policy
[16:33] <lifeless> https://dev.launchpad.net/PolicyAndProcess/ZeroOOPSPolicy
[16:33] <flacoste> yeah, just got that
[16:37] <flacoste> lifeless: fine, i brought back the respecting the w-i-p limit note, but worded it for the new context
[16:38] <lifeless> flacoste: cool thanks
[16:40] <lifeless> flacoste: I wasn't sure how to put it, appreciate you doing htat
[16:41] <flacoste> lifeless: i'll make the relevant updates to the Kanban itself, since Critical bugs aren't 'Expedite' class-of-service anymore
[16:41] <lifeless> cool
[16:41] <lifeless> Thanks
[16:42] <lifeless> I think I have a TODO of writing up done-is-when-deployed
[16:42] <lifeless> that we were waiting for something to unblock/do. Do you remember what that was?
[16:48] <gary_poster> lifeless: could you please take a look at my last comment in https://bugs.launchpad.net/lazr.restfulclient/+bug/380504 and add your suggestion/clarification as appropriate?  No rush, and if you'd prefer an email just ask.
[16:48] <_mup_> Bug #380504: Handle HTTP Error 502: Bad Gateway automatically <canonical-losa-lp> <lp-foundations> <Launchpad itself:Invalid> <lazr.restfulclient:Fix Released by leonardr> < https://launchpad.net/bugs/380504 >
[16:49]  * gary_poster should have searched for HAProxy in LP bugs
[16:49] <gary_poster> doing that now
[16:50] <gary_poster> lifeless: nm
[16:51] <lifeless> gary_poster: I hope my reply is helpful
[16:51] <gary_poster> lifeless: thanks.  So, actually...
[16:51] <gary_poster> https://bugs.launchpad.net/launchpad/+bug/636713
[16:51] <_mup_> Bug #636713: during sustained overload situation replies are truncated in production <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/636713 >
[16:52] <gary_poster> which is similar
[16:52] <gary_poster> and bug 640065
[16:52] <_mup_> Bug #640065: appserver deployment must not interrupt live requests <lp-foundations> <rfwtad> <Launchpad itself:Triaged> < https://launchpad.net/bugs/640065 >
[16:52] <lifeless> yeah
[16:52] <lifeless> the 065 one is the one I split out
[16:52] <gary_poster> but neither of those describe/explain the symptoms in that bug--daily 502s
[16:53] <gary_poster> the HAproxy hypothesis might explain that
[16:53] <gary_poster> you object to another bug?
[16:54]  * gary_poster needs to get on another call but will be back
[16:55] <lifeless> gary_poster: I'm fine with another bug; personally I think its the rollouts still : interrupted live requests show up as 502's
[16:55] <gary_poster> daily 502s back before continuous deployment though?
[16:55] <gary_poster> ok, will file
[16:55] <lifeless> yes
[16:55] <gary_poster> thanks
[16:55] <lifeless> on *edge*
[16:55] <gary_poster> no,
[16:56] <gary_poster> bryce reports on prod
[16:56] <lifeless> ah
[16:56] <lifeless> actually yes
[16:56] <lifeless> we do log rotation daily
[16:56] <lifeless> IIRC that involves a stop-start sequence
[16:56] <lifeless> lets talk when you're not also on a call
[16:57] <jml> "Installing Twisted 10.2.0-4395fix Caused installation of a distribution: Twisted 10.2.0 with a different version."
[16:57] <jml> What am I doing wrong?
[16:58] <lifeless> the setup.py version does not match the one lp's setup.py/versions.cfg expects
[16:58] <lifeless> same issue we had with testtools snapshots
[17:02] <jml> mwhudson: did you have to change something in the Twisted tarball for the 4395 fix, other than applying the patch
[17:02] <jml> mwhudson: because I can't see an obvious version change
[17:06] <lifeless> gary_poster: ah, its sigusr2; now I need to read up on what that does.
[17:06] <gary_poster> does not restart pretty sure
[17:06] <mwhudson> jml: i hacked the setup.py :/
[17:07] <gary_poster> theres a distribute or setuptools approach to that; can download after call if desired
[17:09] <gary_poster> lifeless, also I believe bryce reported that times were not consistent
[17:09] <lifeless> gary_poster: ok, given those two things we definitely need to keep looking
[17:10] <gary_poster> cool, will file bug after call
[17:10] <lifeless> gary_poster: we have been overcapacity routinely - its yet another reason I want to get the single threaded appserver stuff done
[17:10] <gary_poster> ack, yeah
[17:14] <lifeless> gary_poster: is bug 438802 perhaps fix released in lazr.restful ?
[17:14] <_mup_> Bug #438802: UnicodeDecodeError changing 'Assigned to' field when summary contains non-ascii <lp-bugs> <oops> <post-3-ui-cleanup> <ui> <Launchpad itself:Fix Released by intellectronica> <lazr.restful:Fix Committed by intellectronica> < https://launchpad.net/bugs/438802 >
[17:15] <gary_poster> lifeless: yes, changes, thanks
[17:15] <gary_poster> changed
[17:20] <lifeless> poolie: bug 585126 - if we could reduce memory on that that would be very helpful
[17:20] <_mup_> Bug #585126: sendbranchmail with lp:~vcs-imports/linux/trunk is eating memory <canonical-losa-lp> <lp-code> <oops> <Bazaar:Confirmed> <Launchpad itself:Triaged by thumper> < https://launchpad.net/bugs/585126 >
[17:26] <lifeless> gary_poster: what about bug 488762
[17:26] <_mup_> Bug #488762: SnapShot OOPS editing team with 13000 members <lp-foundations> <lp-registry> <oops> <Launchpad itself:Invalid by bac> <lazr.lifecycle:Fix Committed by bac> < https://launchpad.net/bugs/488762 >
[17:29] <gary_poster> released, changed, lifeless
[17:30] <lifeless> thanks
[17:33] <lifeless> bigjools: what machine does bug 694004 need to be deployed to ?
[17:33] <_mup_> Bug #694004: PPA Apache log parser needs to exclude error logs <lp-soyuz> <oops> <qa-ok> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/694004 >
[17:35] <StevenK> lifeless: germanium
[17:36] <lifeless> thanks
[17:36] <StevenK> PPA == germanium always
[17:42] <poolie> lifeless, heh I read that as <Launchpad eating itself:...>
[17:43] <lifeless> \o/
[17:50] <jml> mwhudson: ok, thanks.
[17:50] <mwhudson> jml: are you upgrading to 10.2?
[17:50] <jml> mwhudson: indeed.
[17:51] <mwhudson> jml: \o/
[17:51] <mwhudson> jml: sorry for making your life more difficult
[17:51] <jml> mwhudson: that's ok. :)
[17:52] <bigjools> lifeless: sorry missed your msg, but I see it was answered
[17:53] <lifeless> bigjools: de nada
[17:53] <StevenK> I'm helpful. Sometimes.
[17:53] <bigjools> lifeless: the lack of nodowntime for germanium prevented that fix going out quicker :/
[17:53] <lifeless> bigjools: yeah
[17:53] <bigjools> my oopses are swamped until it's landed
[17:54] <bigjools> anyway I have to go, g'night all
[17:54] <lifeless> bigjools: I think we're < 24 hours away now, but it should be simple: mail mrevell to get a downtime slot, and request a deploy to match
[17:54] <bigjools> lifeless: it was hardly worth it with the release coming up otherwise I would have
[17:55] <bigjools> anyway.... gone
[17:55] <lifeless> ciao!
[17:56] <StevenK> lifeless: So, are you available for an idea?
[17:56] <lifeless> yes
[17:56] <StevenK> lifeless: Which room are you in?
[17:56] <lifeless> hallway
[17:57] <StevenK> Which floor?
[17:57] <lifeless> 3
[17:57] <StevenK> Okay
[18:21] <lifeless> gary_poster: were you aware of bug 416268 ?
[18:21] <_mup_> Bug #416268: application server core dump <canonical-losa-lp> <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/416268 >
[18:22] <gary_poster> lifeless: had seen.  did not repeat.
[18:32] <lifeless> righto, oops + timeout + regressions rescored to critical
[18:32] <StevenK> Yes, you amused kees
[18:43] <lifeless> pcjc2: hi
[18:43] <lifeless> pcjc2: are you interested in doing a patch for that tag issue?
[18:43] <lifeless> pcjc2: also, have we grabbed a contributor agreement from you ?
[19:07] <jml> poolie: https://dev.launchpad.net/LEP/WebservicePerformance ; https://dev.launchpad.net/LEP/WebservicePerformance/ClientSyntax ; https://dev.launchpad.net/Foundations/Webservice/ProposalQnA
[19:14] <leonardr> sinzui, i need some xslt help
[19:14] <sinzui> hi
[19:14] <leonardr> i'm trying to modify this expression:
[19:14] <leonardr>  <xsl:for-each select="key('id', 'service-root-json')/wadl:param/wadl:link">
[19:15] <leonardr> (this is in wadl-to-refhtml.xsl in case you didn't guess)
[19:16] <leonardr> that select is getting an object i want to leave out. my two questions are 1) how do i avoid processing it or change the select to say "only get links with property x"
[19:16] <leonardr> and 2) how do i implement a check for property x in xslt
[19:17]  * sinzui thinks
[19:19]  * sinzui still thinking
[19:23] <pcjc2> @ lifeless - yes I'll do the patch, and I've already signed the contrib agreement
[19:24] <sinzui> leonardr I see we have an xsl:if and xsl:choose constructs in some of these uses. Which use or object are your trying to avoid
[19:25] <leonardr> sinzui: i'd like to avoid param/link tags unless param['name'] ends with '_collection_link'
[19:25] <sinzui> leonardr: okay, that helps
[19:25] <sinzui> damn
[19:26] <sinzui> leonardr: I just lost my history. please repeat the path and the rule to exlude :(
[19:27] <leonardr> sinzui: sure
[19:27] <leonardr> <xsl:for-each select="key('id', 'service-root-json')/wadl:param/wadl:link">
[19:28] <leonardr> i want to include only those where the wadl:param tag has a name attribute ending in '_collection_link'
[19:28] <sinzui> thanks
[19:44] <sinzui> leonardr: are we using sn EXSLT enabled engine?
[19:45] <leonardr> sinzui: i'll check. i think we are using xsltproc
[19:45] <leonardr> sinzui: if push comes to shove we can explicitly exclude a single item
[19:45] <sinzui> yes we are thanks.
[19:45]  * sinzui thinks more
[19:46] <sinzui> leonardr: we have several examples in foreach that use xsl:if or xsl:choose to exclude output. But I do not see how to exclude by a fragment of an attribute name
[19:47] <sinzui> leonardr: we might do this if the attr's content is easy to test. I do not think collection links (urls) look different from entry objects though
[19:47] <leonardr> sinzui: the urls themselves don't look different, no
[19:50] <jml> gmb: may I join ~malone-alpha?
[19:51] <jcsackett> leonardr, can i get you to take a quick look at a branch with an eye towards seeing if it breaks API compatability?
[19:51] <leonardr> jcsackett, sure
[19:52] <jcsackett> thanks, leonardr: https://code.launchpad.net/~jcsackett/launchpad/shortlist-696913
[20:01] <thumper> lifeless: oops 1837REPORTIFSEEN381
[20:01] <StevenK> What prefix is that for?
[20:04] <gmb> jml: I think it can be arranged, yes.
[20:05] <leonardr> jcsackett: when an entry is changed, we take a snapshot before making the change, and send the snapshot along with the new object in an ObjectModifiedEvent
[20:05] <thumper> StevenK: something that shouldn't be running I think
[20:05] <leonardr> so that anyone who cares about the change can see what changed
[20:05] <leonardr> afaik that's the only place where lazr.restful uses snapshots
[20:05] <thumper> StevenK: I saw lifeless update the oops prefixes in a config branch at the end of last week
[20:05] <leonardr> and you can't change a collection field
[20:05] <leonardr> so unless i'm missing something, this should not change the behavior of the web service
[20:06] <jcsackett> leonardr: that's what i thought. a review on that branch raised the question though, and i wasn't sure. thanks.
[20:06] <gmb> jml: Done
[20:08] <lifeless> StevenK: see the production launchpad-lazr.conf for an answer
[20:08] <flacoste> jml: why did you remove the link to the bug tags from the LEP template?%
[20:08] <sinzui> leonardr: jcsackett: I am thinking something like this, yet valid: <xsl:for-each
[20:08] <sinzui>   select="key('id', 'service-root-json')/wadl:Param/wadl:link[
[20:09] <sinzui>     contains(local-name(@*), '_collection_link']">
[20:09] <lifeless> flacoste: there were two links
[20:09] <leonardr> sinzui: ok, why is that invalid?
[20:09] <sinzui> leonardr: local-name() can return the name of an attr
[20:09] <flacoste> lifeless: i see, the 'On Launchpad' bit
[20:10] <sinzui> leonardr: I do not think I can pass a node-set to local-name()
[20:11] <leonardr> sinzui: as a possible punt, can you give me a syntax for excluding wadl:link[not contains(resource_type, 'person')]?
[20:11] <lifeless> jml: https://dev.launchpad.net/LEP/EffortEstimation
[20:11] <sinzui> leonardr: I see local-name does except a node-set
[20:11] <sinzui> it might be valid
[20:12] <leonardr> ok, let me try it
[20:13] <lifeless> james_w: ^
[20:14] <leonardr> sinzui: that filters out every single top-level object
[20:14] <sinzui> :(
[20:14] <jml> gmb: thanks
[20:15] <jml> gmb: btw, maybe make it a moderated team?
[20:15] <gmb> jml: I just clicked save as you pinged me.
[20:15] <gmb> Great minds
[20:16] <gmb> (and mine)
[20:16] <gmb> Occasionally think alike
[20:17] <jcsackett> leonardr, sinzui: are we using xslt 1.0 or 2.0?
[20:18] <leonardr> jcsackett: the stylesheet says 1.0
[20:18] <jcsackett> damn. 2.0 gives us fn:ends-with.
[20:18] <jcsackett> which seemed perfect.
[20:19] <leonardr> the problem is less ends-with and more identifying the part of the tag that needs to be filtered
[20:20] <pcjc2> lifeless?
[20:22] <jcsackett> leonardr: right, but if you can assert name() ended with _collection_link, that would be your filter expression, wouldn't it?
[20:23] <leonardr> jcsackett: you mean something like this?
[20:23] <leonardr>  /wadl:param[endswith(@name, "_collection_link")]/wadl:link?
[20:23] <leonardr> would that work?
[20:25] <jcsackett> if we had xslt 2.0 available--i don't think we do. but i think maybe substring could work?
[20:26] <jcsackett> wald:param[substring(name(), string-length(name()) - 15) = '_collection_link'] ?
[20:26] <jcsackett> leonardr ^
[20:26] <jcsackett> farfetched, but maybe?
[20:26] <leonardr> my question is whether we can stuff a conditional in the middle of the select
[20:26] <leonardr> i'll try it
[20:29] <sinzui> jcsackett: leonardr: can either of you fix this syntax to ensure we call contains for every attribute [@*/contains(local-name(), '_collection_link']
[20:31] <leonardr> sinzui: i need to see the whole expression in context. what is that being applied to? the wadl:link?
[20:32] <jml> hey
[20:32] <sinzui> key('id', 'service-root-json')/wadl:Param/wadl:link[@*/contains(local-name(), '_collection_link']
[20:32] <jml> the build is broken, could someone please fix it? I'm not available right now
[20:33] <StevenK> jml: In devel? Lookerating
[20:33] <jml> StevenK: thanks.
[20:38] <lifeless> pcjc2: hi
[20:38] <lifeless> pcjc2: sorry, lots of interrupts here, was just talking SANs
[20:38] <leonardr> sinzui: no idea. do you know why this doesn't select anything?
[20:38] <pcjc2> hi - just coding up the patch for tags
[20:38] <lifeless> pcjc2: cool
[20:38] <leonardr> select="key('id', 'service-root-json')/wadl:param[contains(@resource_type, '_collection_link')]/wadl:link
[20:39] <leonardr> can i just not put the filter there?
[20:39] <pcjc2> I'm not sure what value the "DISTINCT" buys us if the EXISTS cause doesn't shortcut the query
[20:39] <pcjc2> Does DISTINCT shortcut the lookup? It would seem that it couldn't know to do that - or does it infer that from the WHERE clause?
[20:40] <pcjc2> Might seem to me that the * and -* clauses could be shortcut by LIMIT ing the return of the SELECT statement to at most one row
[20:40] <lifeless> pcjc2: it does
[20:40] <pcjc2> I've added similar speed-ups to the other tag searches too
[20:40] <thumper> sinzui: ping
[20:41] <lifeless> pcjc2: the DISTINCT means that if there are 1000 tags on that bug, the subquery only returns one row
[20:41] <sinzui> leonardr: I read that to mean select all param elements that have a resource_type attribute that contains '_collection_link'
[20:41] <lifeless> pcjc2: we've got concrete data for this
[20:41] <lifeless> pcjc2: the precise change I proposed makes the query take 7ms
[20:41] <lifeless> pcjc2: basically, pgsql is weird :)
[20:41] <pcjc2> as compared to the case where it was only "SELECT ... WHERE BugTag.bug = Bug.id"
[20:42] <leonardr> sinzui: ah, the name is wrong. it should be name, not resource_type
[20:42] <pcjc2> As you noted in the bug, the EXIST function should have far more power to short-circuit row lookups
[20:42] <lifeless> well, we've had other more complex cases
[20:42] <pcjc2> I would have presumed DISTINCT had to process every row, as well as remove duplicates
[20:42] <lifeless> it seems to be sensible
[20:43] <sinzui> leonardr: you many need local-name() to avoid namespace issues
[20:43] <lifeless> I can ask a losa to test with/without, but as distinct works well enough I propose just doing it :)
[20:43] <pcjc2> It just looked odd to have it in the clauses for the -* lookups, but not for other tags
[20:43] <leonardr> sinzui: /wadl:param[contains(@name, '_collection_link')]/wadl:link selects the param whose @name is "me_link". what should i do with local-name?
[20:43] <pcjc2> (They will be distinct anyway, assuming duplicated tags are not allowed)
[20:44] <pcjc2> I've put " SELECT DISTINCT TRUE FROM BugTag WHERE BugTag.bug=Bug.id"
[20:44] <pcjc2> Since we don't care about the data returned from the table
[20:44] <sinzui> leonardr: sorry. I thought you were referring to the function name(). you are correct to use @name
[20:44] <pcjc2> The clauses are combined along the lines of "(EXISTS (%s) %s NOT EXISTS (%s))" % (include_clause, combine_with, exclude_clause)
[20:44] <sinzui> leonardr: or name for an element named name
[20:44] <lifeless> pcjc2: the ids aren't
[20:45] <leonardr> sinzui: do you know why that expression would select a param with name="me_link"?
[20:45] <pcjc2> Bug IDs aren't.. but then we are querying tags for a particular bug here, right?
[20:45] <lifeless> mbarnett: are you online again ?
[20:45] <mbarnett> lifeless: i am back,
[20:45] <pcjc2> how is the test-coverage for tag searches?
[20:45] <lifeless> up for profiling a query on prod? (data for it isn't on staging yet)
[20:46] <mbarnett> lifeless: sure.
[20:46] <lifeless> gimme a minute to whip it up
[20:46] <mbarnett> lifeless: give me the competing bits
[20:46] <mbarnett> kk
[20:47] <jcsackett> sinzui: leonardr: i've got to run for a few. sorry i've been no help.
[20:47] <sinzui> leonardr: I do not think you need local-name since the '_collection_link' is in an attr value
[20:49] <pcjc2> gah - the test-suite tests based in expected SQL generation, not results
[20:49] <leonardr> sinzui: ok. my problem is that i have a seemingly comprehensible expression that doesn't filter anything out
[20:53] <sinzui> leonardr: Is this a sample of wadl:link elements that you want to match http://pastebin.ubuntu.com/553336/
[20:53] <leonardr> sinzui: yes, exactly
[20:54] <sinzui> :( I just wrote a select for that and then saw it was identical to what you just said did not work
[20:55] <sinzui> leonardr: this does not work? <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
[20:55] <sinzui>     contains(@name, '_collection_link']/wadl:link">
[20:55] <leonardr> sinzui: maybe the expression shows up again later in the document, and it must be changed there as well
[20:57] <leonardr> yeah, i think that's it
[20:57] <sinzui> yes 2 times
[21:01] <LPCIBot> Project devel build (351): FAILURE in 4 hr 48 min: https://hudson.wedontsleep.org/job/devel/351/
[21:01] <lifeless> mbarnett: http://pastebin.com/KmzJ7YpL
[21:02] <lifeless> bah
[21:05] <leonardr> sinzui: ok, there's another place where it's slightly different
[21:06] <huwshimi> Morning everyone
[21:06] <jml> hey huwshimi
[21:06] <leonardr> <xsl:variable name="top_level_collections" select="key('id', 'service-root-json')//@resource_type[substring-after(., '#') = $id]" />
[21:07] <lifeless> mbarnett: http://pastebin.com/raw.php?i=kcwvmWqb
[21:07] <lifeless> mbarnett: should be able to just run that
[21:07] <lifeless> in psql
[21:08] <leonardr> i changed that to:
[21:08] <leonardr> select="key('id', 'service-root-json')/wadl:param[contains(@name, '_collection_link')]/wadl:link/@resource_type[substring-after(., '#') = $id]"
[21:08] <mbarnett> lifeless: thanks, was trying to sort out the "#"s that the original was introducing
[21:08] <leonardr> but either that had no effect, or i'm missing something else
[21:08] <lifeless> mbarnett: I had a brain fart
[21:09] <sinzui> leonardr: maybe <xsl:variable name="top_level_collections"
[21:09] <sinzui>   select="key('id', 'service-root-json')/wadl:param[
[21:09] <sinzui>     contains(@name, '_collection_link']//@resource_type[
[21:09] <sinzui>     substring-after(., '#') = $id]" />
[21:10] <leonardr> did you just add a slash?
[21:11] <leonardr> you removed wadl:link
[21:11] <leonardr> that doesn't help me
[21:11] <sinzui> leonardr: you want the wadl:link element
[21:11] <sinzui> ?
[21:11] <leonardr> no, i don't care
[21:11] <leonardr> but getting rid of it doesn't change what happens
[21:12] <leonardr> 'person' does not show up in the list of reosurce types, presumably because it was found in top_level_Collections
[21:12] <jml> huwshimi: how'd it go landing that branch?
[21:13] <huwshimi> jml: Getting there, but ran into an issue. Still trying to sort it out
[21:13] <mbarnett> lifeless: the results with no # of results all returned 33: http://pastebin.ubuntu.com/553340/
[21:13] <sinzui> leonardr <xsl:variable name="top_level_collections"
[21:13] <sinzui>   select="key('id', 'service-root-json')/wadl:param[
[21:13] <sinzui>     contains(@name, '_collection_link']/wadl:link[
[21:13] <sinzui>     substring-after(@resource_type, '#') = $id]" />
[21:13] <jml> huwshimi: what's the issue?
[21:13] <sinzui> leonardr: is person also effected by the dual nature of team?
[21:14] <huwshimi> jml: The land script was having issues. Just about to try again and see
[21:14] <lifeless> mbarnett: the explain analyzes seem to be missing ;)
[21:14] <leonardr> sinzui: no, i eliminated that possibility pretty early
[21:15] <leonardr> in the wadl, person and team are two different but largely duplicated tags
[21:15] <mbarnett> lifeless: bah
[21:15] <lifeless> pcjc2: select true, no distinct, appears to be the fastest result we got
[21:15] <lifeless> pcjc2: can't tell if thats algorithmic or load (because the analyzes are awol :P)
[21:15] <lifeless> mbarnett: no worries
[21:16] <pcjc2> so drop the DISTINCT from the SQL - cool, that makes things more consistent
[21:16] <lifeless> mbarnett: my intent was that you could just capture stdout and not need to fiddle with copy n paste
[21:16] <pcjc2> The test-suite here is not very nice / good
[21:16] <jml> huwshimi: btw, paste.ubuntu.com and paste.canonical.com are good places to dump error messages to share with others
[21:17] <pcjc2> the test-suite is based on the expected SQL for a given tag query, not expected _results_ for a given ....
[21:17] <huwshimi> jml: ok thanks.
[21:18] <leonardr> sinzui: i don't think this expression is the problem. if i flip the conditional on $top_level_collections, i don't get person--i get nothing
[21:18] <leonardr> i guess that doesn't prove what i was saying
[21:19] <lifeless> pcjc2: heh; a bit ugly, but in some ways reasponable
[21:19] <pcjc2> doesn't let me verify my new SQL produces valid results though
[21:20] <pcjc2> definately drop "DISTINCT" ?
[21:20] <lifeless> yes
[21:20] <huwshimi> jml: I feel like I'm probably doing something dumb, but this is what I get: https://pastebin.canonical.com/41843/
[21:21] <lifeless> huwshimi: btw if its not confidential, pastebin.ubuntu.com is better than .canonical.com
[21:21] <lifeless> lets more folk help
[21:21] <jml> huwshimi: you need to update your download-cache and rebuild
[21:21] <huwshimi> lifeless: Oh right, thanks.
[21:21] <jml> bzr up download-cache; make compile
[21:21] <jml> huwshimi: it was a bug in our dev tree that has since been fixed.
[21:21] <huwshimi> jml: Ok, thanks
[21:22] <mbarnett> lifeless: http://pastebin.ubuntu.com/553345/ might help more
[21:22] <lifeless> thanks
[21:23] <lifeless> pcjc2: theres only 1ms in it in the plan, but yeah drop the distinct
[21:23] <lifeless> thanks
[21:24] <gmb> gary_poster: Around?
[21:24] <sinzui> leonardr: I have assumed for a long time that the person collection/entry is broken by the flawed implementation of team.
[21:24] <gary_poster> gmb, hi, yes
[21:25] <sinzui> leonardr: is people_collection_link the item that is missin?
[21:25]  * gary_poster still wants to set up a call with gmb before Thunderdome
[21:26] <gmb> gary_poster: Hi. I was just wondered if you still wanted to have our long-delayed catch up call before Thunderdome. It would seem I suddenly have tomorrow and Friday as normal work days as the result of a travel snafu.
[21:26] <gary_poster> though days are few
[21:26] <gmb> Hah
[21:26] <leonardr> sinzui: it may be, but that has nothing to do with this problem--this problem is caused by the fact that we have a link to a person at the top-level, and the xslt assumes there are only collections at the top-level
[21:26] <leonardr> no, #person is the item that's missing in my hacked file
[21:26] <leonardr> in the file as is, #person is created but it's not properly fleshed out and it's treated as a collection
[21:26] <gmb> gary_poster: I can do any time tomorrow or Friday.
[21:26] <gmb> (and I can be TZ flexible too, if that helps)
[21:27] <gary_poster> gmb :-) awesome.  Lemme go look at a calendar, and remind myself what my TZ offset is...
[21:27] <gary_poster> (-5 I think, but I never trust my memory of it)
[21:27] <gmb> gary_poster: If you're in EST you're -5.
[21:28] <gmb> (Hurrah for all those days of having to do conference calls with the Lexington office)
[21:28] <sinzui> leonardr: okay, I found it. it does not have a @name. I think I can propose a solution
[21:28] <gary_poster> heh.  that's it, then.  go, go memory.  Wait, I didn't mean for you to leave...
[21:28] <gmb> :)
[21:29]  * leonardr awaits
[21:30] <gary_poster> gmb: tomorrow at 1600 UTC ?
[21:30] <sinzui> leonardr: the me_link is unique in th xml, so
[21:30] <sinzui> <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
[21:30] <sinzui>     contains(@name, '_collection_link') or @path="$['me_link']"]/wadl:link">
[21:30] <gmb> gary_poster: Works for me. Send me an invite and I'll ack presently.
[21:30] <gary_poster> awesome will do.  thank you!
[21:30] <gmb> np
[21:31]  * gmb realises it's way past EOD, disconnects for the sake of his sanity
[21:31] <sinzui> leonardr: well the quotes need fixing, but the trick is to use OR
[21:32] <sinzui> leonardr: <xsl:for-each select="key('id', 'service-root-json')/wadl:param[
[21:32] <sinzui>     contains(@name, '_collection_link') or contains(@path, 'me_link')]/wadl:link">
[21:36] <leonardr> sinzui: my problem is that me_link is being counted as a top-level collection and i don't want it to be
[21:36] <jml> huwshimi: maybe try running ./bin/buildout if 'make compile' doesn't work?
[21:37] <leonardr> that seems to guarantee it will be counted as one
[21:37] <sinzui> oh
[21:37] <sinzui> so we neet a not() condition on it? I would have thought that was unneeded since it does not have @name
[21:38] <huwshimi> jml: That didn't fix it either
[21:38] <leonardr> sinzui: i have no idea why it's not working as is, and i've fried my brain looking at it
[21:38] <jml> huwshimi: still getting the same error?
[21:39] <jml> oh
[21:39] <jml> silly me
[21:39] <jml> huwshimi: you'll need to merge in the latest devel
[21:40] <huwshimi> jml: ok I'll try that
[21:42] <micahg> hi lifeless
[21:43] <lifeless> hi
[21:43] <sinzui> leonardr: so this does not work: http://pastebin.ubuntu.com/553356/
[21:44] <leonardr> sinzui: that works
[21:44] <jml> mwhudson: fwiw, Launchpad tests fail w/ Twisted 10.2
[21:44] <leonardr> i can stop me_link from being considered in the big list of <h2>top-level objects</h2>
[21:44] <micahg> lifeless: so regarding bug 702031, this affects developers applying for upload rights in that it makes it harder to find their contributions, don't know if that should increase the priority, but didn't know if that needs another tag
[21:44] <_mup_> Bug #702031: Packages pocket copied from a Security PPA to the archive should appear in +uploaded-packages <soyuz-security> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702031 >
[21:45] <leonardr> but when it comes to generating the entry tags
[21:45] <mwhudson> jml: !
[21:45] <mwhudson> jml: which?
[21:45] <leonardr> we check each one to make sure it's not in some list of "top-level objects" generated some other way
[21:45] <jml> mwhudson: http://paste.ubuntu.com/553358/
[21:45] <leonardr> and although 'me_link' doesn't seem to show up in that list, 'person' is not being considered an entry for some reason
[21:46] <thumper> I HATE database identifiers in doctest results
[21:46] <mwhudson> jml: at least they're faintly plausible tests to fail
[21:46] <lifeless> micahg: I'm inclined to leave it low; but you can raise it through the stakeholder process (once Ubuntu decides on a representative)
[21:46] <mwhudson> jml: is the problem clear from the traceback?
[21:47] <StevenK> thumper: Agreed, rargh!
[21:47] <micahg> lifeless: ok, are there other tags for tracking stakeholder bugs?
[21:47] <mwhudson> (i also like the way lp.archiveuploader.tests.test_uploadprocessor.TestBuildUploadProcessor.testBinaryPackageBuild_fail both fails and errors)
[21:47] <StevenK> mwhudson: On buildbot or hudson?
[21:47] <lifeless> micahg: ones that we've accepted get a tag, but not simply ones that stakeholders care about AFAIK
[21:47] <jml> mwhudson: they seem librarian related
[21:47] <StevenK> Or twisted related
[21:47] <mwhudson> jml: ok
[21:47] <jml> mwhudson: the errors are obscured a bit by the librarian logs
[21:48] <lifeless> whats up with this:
[21:48] <micahg> lifeless: ok, thanks, will keep an eye on the stakeholder stuff
[21:48] <lifeless> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
[21:48] <lifeless> Using filter: min
[21:48] <jml> mwhudson: when is poolie going to start working on tribunal full time
[21:48] <mwhudson> jml: deprecation warnings on startup?
[21:48] <jml> mwhudson: ooh, there's a thought.
[21:48] <mwhudson> jml: what the what?
[21:48] <spiv> lifeless: jam saw that yesterday
[21:48] <StevenK> lifeless: I think that's an out of date jsbuild?
[21:48] <poolie> ooh that'd be nice
[21:48] <poolie> for a change
[21:48] <jml> mwhudson: it would make it easier to read these errors
[21:48] <mwhudson> jml: 'make start_librarian' or whatever i guess?
[21:48] <jml> mwhudson: yeah, looking into it.
[21:49] <spiv> lifeless: (but I think he hacked around it rather than digging into why)
[21:49] <jml> mwhudson: actually, I might gate-crash your room. too much talk here for this kind of work.
[21:49] <mwhudson> jml: are we going to make tachandler less vomitous at some point?
[21:49] <mwhudson> jml: it's quiet here
[21:49] <mwhudson> (cause there's a linaro meeting happening somewhere else)
[21:49] <spiv> mwhudson: ReadyService is a thing of beauty :P
[21:49] <lifeless> spiv: he 'rm -rf'
[21:50] <lifeless> its lean now
[21:50] <lifeless> I cleaned it up
[21:50] <sinzui> leonardr: okay I think I understand now. Maybe you should stop working on this today. clear you mind. I will look at this my my tree and see if I come to a solution
[21:51] <leonardr> sinzui: thanks a lot
[21:55] <mwhudson> spiv: i guess you could say that
[21:59] <lifeless>   File "/home/robertc/launchpad/lp-sourcedeps/eggs/lazr_js-1.5DEV_r191-py2.6.egg/lazr/js/build.py", line 74, in needs_update
[21:59] <lifeless>     if os.stat(src_file).st_mtime > target_mtime:
[21:59] <lifeless> OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js'
[21:59] <lifeless> Using filter: min
[21:59] <lifeless> any more suggestions ?
[22:01] <huwshimi> jml: Have gotten past that error now. Thanks!
[22:03] <mwhudson> lifeless: rm -rf something i think
[22:03] <lifeless> nope
[22:03] <lifeless> jam deleted his whole tree
[22:04] <mwhudson> oh
[22:04] <lifeless> check utilities/yui-deps.py
[22:04] <lifeless> and die a little
[22:05] <jam> mwhudson, lifeless: technically I used "bzr clean-tree --detritus --ignored --unknown", but yeah, pretty much
[22:05] <jam> the code that does os.stat() should check that the file already exists
[22:05] <jam> or handle the ENOENT
[22:05] <lifeless> its a dep listing
[22:06] <lifeless> its just buuuugy
[22:06] <mwhudson> joy
[22:06] <jam> if the file doesn't exist, I think it is safe to say it isn't new enough :)
[22:07] <lifeless> mwhudson: you looked ? :)
[22:07] <mwhudson> lifeless: no
[22:07] <mwhudson> i believe you though
[22:08] <lifeless> :)
[22:08] <lifeless> bug 702160
[22:08] <_mup_> Bug #702160: utilities/yui-deps.py manually lists dependencies <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702160 >
[22:09] <pcjc2> Lifeless, a cursory search suggests this "problem" exists for CVEs and possibly other things
[22:10] <lifeless> pcjc2: you may find existing bugs in https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
[22:10] <pcjc2> "BugTask.bug IN (SELECT DISTINCT bug FROM BugCve)" rather than "EXISTS SELECT TRUE FROM BugCve WHERE BugCve.bug = BugTask.bug"
[22:10] <lifeless> pcjc2: I can well  believe this
[22:10] <pcjc2> ok, I'll see what I can get through
[22:10] <lifeless> pcjc2: I suggest doing fixes for them in separate branches
[22:10] <lifeless> fits better with our qa process
[22:10] <pcjc2> I'm a little nervous that there isn't a test-suite test which tests functioanlity based on real queries though
[22:10] <pcjc2> I'll have to be sure I test it properly here
[22:11] <lifeless> pcjc2: most of our stuff is tested end to end (and thats a problem in various ways) - there are tests and tests though.
[22:11] <lifeless> what specific tests are you looking at ?
[22:11] <pcjc2> (I don't think I've got the spare time to re-write such an extensive bunch of tests)
[22:11] <pcjc2> class TestBugTaskTagSearchClauses(TestCase):
[22:11] <pcjc2> Tests emission of "correct" SQL, not whether the SQL produces the correct result or not
[22:12] <pcjc2> so when I change the query in model/bugtask.py
[22:12] <pcjc2> I have to change the expected SQL in the test results
[22:12] <lifeless> yes, this is testing what is queried for
[22:12] <lifeless> there are other tests :)
[22:12] <pcjc2> and this doesn't help me verify I've not broken anything
[22:12] <pcjc2> ah - fair enough
[22:13] <pcjc2> I had wondered if it would be more efficient to phrase the tag search as a single SELECT
[22:13] <pcjc2> and combine the logic in the WHERE statements - rather than doing boolean operations on various separate SELECT statements with a single WHERE clause each
[22:14] <pcjc2> Anyway - this is probably just bike-shedding - 7ms vs. 17secs seems "good enough" for the case I originally reported ;)
[22:15] <lifeless> pgsql traverses the btree separately per id anyhow
[22:15] <lifeless> so I don't think its a significant issue
[22:16] <pcjc2> stupid question - any idea of which tests to run?
[22:17] <lifeless> :!find . -name "*bug*search*"
[22:17] <lifeless> suggests
[22:17] <pcjc2> thanks
[22:17] <lifeless> bugtask-search-views.txt bugtask-searches /xx-bugs-advanced-search-upstream-status.txt bugtask-search.txt
[22:17] <lifeless> ./lib/lp/bugs/tests/test_bugtask_search.py
[22:19] <pcjc2> KeyError: 'STORM_CEXTENSIONS'
[22:19] <pcjc2> grr bin/test not working here - what did I break... (checks)
[22:24] <lifeless> pcjc2: run 'make'
[22:25] <pcjc2> Error: Couldn't find a distribution for 'Twisted==10.1.0-4395fix'.
[22:25] <pcjc2> some rocketfuel command I need to call?
[22:25] <jml> uhhh
[22:25] <thumper> pcjc2: update the download cache?
[22:25] <jml> do you have a download-cache
[22:25] <jml> is it up to date
[22:26] <pcjc2> not sure.. -> probably not
[22:27] <lifeless> who knows about the yui build stuff?
[22:27] <jml> I don't :)
[22:28] <jml> hmm. hmm. hmm.
[22:28] <jml> the librarian log seems to accumulate during a test run
[22:29] <jml> I guess that makes sense, because it's the same librarian.
[22:29] <jml> but it makes the log in the details less useful for longer runs
[22:29] <lifeless> jml: yes
[22:30] <lifeless> jml: it would be nice for the fixture to note the file length and only copy new stuff
[22:30] <lifeless> jml: but! we need to fix the 1MB-and-it-rotates thing first
[22:38]  * pcjc2 tries make clean.. otherwise not working still
[22:39] <lifeless> pcjc2: you nede to run 'bzr update' in the download-cache directory
[22:40] <pcjc2> I tried bzr pull
[22:40] <pcjc2> Tree is up to date at revision 227 of branch bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-source-dependencies
[22:40] <lifeless> if you have the default setup, its bzr update
[22:41] <pcjc2> error is in bin/compile_templates
[22:41] <pcjc2> will pastebin
[22:43]  * pcjc2 fixes error in his patch ;)
[22:43] <pcjc2> The download-cache update did help though, but the make error was my fault
[22:44] <pcjc2> is there an approved coding style for line-continuations?
[22:44] <pcjc2>             include_clause = \
[22:44] <pcjc2>                 "SELECT TRUE FROM BugTag WHERE BugTag.bug=Bug.id"
[22:44] <pcjc2> Is that ok?
[22:47] <lifeless> dev.launchpad.net/PythonStyleGuide
[22:47] <lifeless> uhm
[22:47] <lifeless> that looks like it will fit on one line in 78 charsa
[22:47] <lifeless> if it won't
[22:47] <lifeless> include_clause = (
[22:47] <lifeless>     "SELECT ...")
[22:48] <lifeless> is our preference
[22:49] <bac> pcjc2: as lifeless points out, we prefer the style he quotes.  continuing a line by using \ is not used.
[22:50] <lifeless> bac: not used would be an exaggeration :)
[22:50] <bac> lifeless: really?  i don't recall seeing it.
[22:50] <lifeless> it's around
[22:50] <lifeless> personally I think we shouldn't specify stuff like this
[22:51] <bac> lifeless: luckily we have a forum coming up for you to express that opinion.  :)
[22:51] <lifeless> bac: bigger fish to fry
[22:52] <pcjc2> thanks
[23:00] <pcjc2> I can't seem to make it run some tests
[23:00] <pcjc2> ./lib/lp/bugs/stories/bugtask-searches/xx-searching-by-tags.txt
[23:02] <pcjc2> ./bin/test -t xx-searching-by-tags.tx
[23:02] <wgrant> pcjc2: doctests are a bit odd. Try just asking for xx-searching-by-tags.txt, not the full path.
[23:02] <pcjc2> thanks
[23:02] <pcjc2> some tests fail with bug heat changes - even after "make schema"
[23:09] <lifeless> interesting
[23:11] <pcjc2> tests are _slow_
[23:12] <lifeless> yes!
[23:12] <lifeless> flacoste: hi
[23:17] <jml> pcjc2: lifeless has a plan to make it all better.
[23:23]  * pcjc2 wishes you guys used git instead of bzr - that would be nicer
[23:23] <pcjc2> probably mostly because I'm quite familiar with git, but not so with bzr
[23:24] <lifeless> pcjc2: how would it be nicer?
[23:24] <pcjc2> I'd love to see LP support code-review and branches with git as well as you do for bzr
[23:24] <pcjc2> we use git for our project - so supporting git workflows would be really handy
[23:24] <pcjc2> I was wondering if it would be accepted should I volunteer to work on it
[23:25] <lifeless> mmm
[23:25] <pcjc2> but have been told (here IIRC), that it would not likely be wanted, even it it was coded
[23:25] <lifeless> theres a bunch of concerns around it
[23:25] <lifeless> we'd like to make users of git happy
[23:25] <pcjc2> any written down?
[23:25] <lifeless> how that looks is a whole other question
[23:25] <lifeless> on the technical side I wouldn't want a parallel infrastructure for git & bzr throughout the system
[23:26] <pcjc2> no - need some SCM abstraction
[23:26] <lifeless> jml: can speak to the social and product constraints
[23:26] <lifeless> pcjc2: we have one - bzrlib :)
[23:26] <pcjc2> bzr and git backends
[23:26] <lifeless> pcjc2: no, I'm serious - bzrlib *is* a SCM abstraction
[23:26] <pcjc2> ok
[23:27]  * pcjc2 wishes he had an index, and "git stash" whilst working on branches in bzr
[23:27] <lifeless> it can talk natively to git, svn, hg, bzr
[23:27] <lifeless> bzr shelve
[23:27] <lifeless> bzr unshelve
[23:27] <pcjc2> thanks - I knew it was probably me not being familiar enough with bzr
[23:28] <pcjc2> I think the problem is I'm so used to git's internal model - and I don't "get" bzr's - I'll make an effort to look it up some time
[23:28] <jcsackett> pcjc2: bzr shelve/unshelve has some really nice features. i've come to prefer it to git stash.
[23:30] <lifeless> gary_poster: is it intentional that WebservicePerformance isn't linked on LEP ?
[23:30] <gary_poster> I think so, lifeless; lemme review
[23:31] <gary_poster> lifeless: yeah, it is, we were building it.  That said, putting it in the Drafting section probably wouldn't hurt anything.  Would you like me to do so?
[23:32] <lifeless> that would be cool
[23:33] <poolie> did someone tweet it's back up?
[23:33] <poolie> gary_poster, i did that
[23:33] <poolie> gary_poster, it looks nice
[23:33] <poolie> i will add some comments
[23:33] <gary_poster> poolie, thank you.  it's not internally consistent yet, but appreciated
[23:34] <gary_poster> night all
[23:37] <poolie> gary_poster, it would be interesting to look at the super-slow hottest100 measurement script
[23:38] <poolie> and see what the code would look like, and what round-trips it would do,
[23:38] <poolie> under this new approach
[23:41] <jml> StevenK: hi
[23:41] <jml> StevenK: how's it going with those test failures?
[23:41] <StevenK> Workus Interruptus
[23:41] <jml> StevenK: I ask, because the recent branch to control IBuild.date_finished only from within buildmanager introduces new test failures
[23:42] <StevenK> Being in the kernel room has been not good for interrupts
[23:48] <poolie> mm
[23:48] <poolie> needing to get up and go to the bar all the time
[23:50] <james_w> to examine in 15 minutes: OOPS-1838H5865
[23:50] <jml> StevenK: should I attempt to fix it instead?
[23:50] <james_w> (going to https://code.launchpad.net/~salgado/linaro-image-tools/config-class/+merge/46048)
[23:54] <jml> hmm.
[23:54] <pcjc2> grr... bugtask test fails comparing two notionally identical strings on prefixed as unicode (u"..."), one not ("...")
[23:55] <lifeless> doctests are painful
[23:55] <jml> hmm
[23:55] <lifeless> jml: they are
[23:55] <pcjc2> wasn't a doctest, was lib/lp/bugs/model/tests/test_bugtask.py
[23:55] <lifeless> hmm
[23:55] <lifeless> what line
[23:55] <pcjc2> lost the scrollback in the terminal, so waiting for another test run
[23:56] <pcjc2> SQL was (EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'bob'))
[23:56] <pcjc2> will need to bzr shelve and re-check prior to my changes as a next step I think
[23:56] <lifeless> pcjc2: what line in the test file
[23:56] <jml> for rolling back a revision, I can just do it and email the list.
[23:56] <jml> right?
[23:57] <lifeless> jml: if you mean commit a new revision reverting the changes with rollback=xxxx, yes
[23:57] <pcjc2> line won't match yours, as I've edited the test
[23:57] <lifeless> jml: you don't even need to email the list if you won't want to
[23:57] <jml> lifeless: ahh ok.
[23:57] <jml> lifeless: is there a doc so I can get this right?
[23:57] <lifeless> jml: if you mean uncommit, noooooooo dooooooinnnnnggggg it
[23:57] <jml> (or better yet, tool support?)
[23:57] <jml> lifeless: I don't mean uncommit.
[23:57] <pcjc2> def test_mixed_tags_all(self): ~= Line 455
[23:58] <lifeless> jml: https://dev.launchpad.net/MergeWorkflow
[23:58] <lifeless> https://dev.launchpad.net/QAProcessContinuousRollouts
[23:58] <StevenK> jml: Sorry, interrupted again. Please do.
[23:59] <jml> StevenK: ta.