[00:25] <poolie> jelmer, hi
[00:25] <jelmer> hello again :)
[00:26] <poolie> jelmer, so i think the lep is as far forward as makes sense for something that's just queued up
[00:26] <poolie> if we're going to actually start it, it should be made a bit tighter about requirements
[00:26] <poolie> probably make sure all the issues people raised are addressed
[00:26] <poolie> and then break out some particular bugs
[00:26] <poolie> all with a tag
[00:27] <jelmer> poolie: ah, ok
[00:28] <jelmer> poolie: is it still waiting for anything, or should one or more of us just go over it to make sure all requirements are addressed?
[00:29] <poolie> nothing else
[00:29] <poolie> that would be great
[00:29] <poolie> if you'd like to start on it
[00:30] <jelmer> might as well
[00:36] <LPCIBot> Project windmill build #101: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/101/
[00:37] <jelmer> sleep first though, g'night!
[00:38] <lifeless> wgrant: how much work is sitting unreleased on lh trunk ?
[00:43] <wgrant> lifeless: 11 revs... start/stop-loggerhead are gone (deprecated long ago), a couple of logging changes that seem harmless.
[00:43] <wgrant> Otherwise just optimisations and UI tweaks.
[00:44] <lifeless> wgrant: feel like doing a 1.19 ?
[00:44] <lifeless> wgrant: my thinking is: we have radical stuff in the pipeline
[00:44] <lifeless> be nice to get the incremental stuff 'out there'
[00:44] <wgrant> lifeless: i might talk to jam about that tonight.
[00:44] <lifeless> and you're already fiddling with all the policy etc etc
[00:45] <wgrant> lifeless: Oh, you mean "unreleased" as in everything since 1.18, not since our last rev?
[00:45] <lifeless> wgrant: yes
[00:45] <lifeless> wgrant: the stuff on trunk we should deploy, thats not done because of unfamiliarity with the mechanism for jam
[00:46] <wgrant> There's only a few revs more. 1.18 was 421. There's the new theme, what look like bzr compat fixes, and the HEAD changes.
[00:46] <wgrant> And a favicon change.
[00:46] <wgrant> So all releasable.
[00:46] <wgrant> If we're going to start doing more radical stuff, we should indeed release.
[00:46] <lifeless> historydb is more radical
[00:46] <wgrant> Right, but I'm not sure how close that is.
[00:47] <lifeless> I think it would be nice to have a modern loggerhead equivalentish to our deploy before that tracks forward
[00:47] <lifeless> wgrant: not all that far off
[00:47] <james_w> who did the new theme?
[00:47] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/new-loggerhead/+merge/54803
[00:47] <wgrant> james_w: huwshimi, I believe.
[00:47] <james_w> thanks huwshimi
[00:48] <huwshimi> james_w: Yeah you can blame me :)
[00:48] <james_w> huwshimi, far from it :-) it's a great and sorely needed improvement
[00:49] <huwshimi> james_w: Hopefully it'll be integrated with Launchpad further at some point, but it's a start
[00:49] <james_w> yeah
[00:50] <james_w> huwshimi, two questions, do we need all the duplication of the (i) icons? and can we have the commit message wrap if it's too long?
[00:50] <james_w> e.g. http://bazaar.launchpad.net/~offspring-hackers/offspring/trunk/files
[00:50] <james_w> (for me at least with 1280px width)
[00:51] <huwshimi> james_w: Do you mean the icons for "view revision" and "view branch changes"?
[00:51] <james_w> yeah
[00:52] <james_w> there's more on the file pages
[00:52] <james_w> http://bazaar.launchpad.net/~offspring-hackers/offspring/trunk/view/head:/Makefile
[00:52] <james_w> that's a lot of informative links
[00:55] <huwshimi> james_w: It's not great, but that's the way we do sub navigation elsewhere in Launchpad
[00:55] <huwshimi> james_w: Can you please file a bug about the commit message length?
[00:56] <james_w> huwshimi, fair enough
[00:56] <james_w> sure
[00:56] <huwshimi> james_w: I will be address a lot of things like that soon
[00:56] <huwshimi> *addressing
[00:56] <james_w> huwshimi, do you want a separate one for http://bazaar.launchpad.net/~offspring-hackers/offspring/trunk/changes
[00:56] <james_w> where if you expand the top revision it gets loooooong
[00:57] <james_w> and http://bazaar.launchpad.net/~offspring-hackers/offspring/trunk/revision/60 I guess, which is the worst yet :-)
[00:57] <james_w> also, bugs against loggerhead or launchpad? tags? subscribers?
[00:57] <huwshimi> they should be bugs against loggerhead
[00:58] <huwshimi> just tag them as ui and you can add me as a subscriber
[00:58] <james_w> ok, thanks
[00:58] <huwshimi> james_w: Thank you for noticing (and caring)
[00:59] <james_w> it's great to have someone to raise these with again :-)
[00:59] <huwshimi> james_w: oh and with the lengths you can probably put it all in one bug but link to all those pages
[01:00] <james_w> bug 742178
[01:00] <_mup_> Bug #742178: doesn't handle long commit messages well <ui> <loggerhead:New> < https://launchpad.net/bugs/742178 >
[01:01] <huwshimi> james_w: Thanks heaps
[01:16] <mwhudson> ah it would be good to have someone who knows some css look at those
[01:29] <lifeless> I want a teddy bear
[01:29] <lifeless> to talk webservice collection offset tuning with
[01:29] <lifeless> to the sound of o/~ I need a hero
[01:31] <spm> nothing here but us crickets
[01:32] <lifeless> crickets are good
[01:32] <lifeless> spm: hey, can you explain analyze a query on prod for me - looking for cold cache again
[01:32] <lifeless> https://bugs.launchpad.net/launchpad/+bug/736008/comments/1
[01:32] <_mup_> Bug #736008: Product:+code-index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736008 >
[01:34] <spm> lifeless: https://pastebin.canonical.com/45213/
[01:34] <lifeless> booyah
[01:36] <lifeless> spm: thanks
[01:36] <spm> np
[01:38] <lifeless> spm: could you run the same query, not explained - the actual query - on another server?
[01:38] <spm> sure, one sec.
[01:42] <spm> lifeless: count: 168, Time: 125.128 ms lp_1
[01:46] <lifeless> spm: woo,t hanks.
[01:46] <lifeless> hot shit query
[01:47] <spm> as opposed to warm?
[01:47] <lifeless> run it again :)
[01:47] <spm> Time: 62.076 ms
[01:47] <lifeless> yup
[01:47] <lifeless> I have oopses with it at 700ms
[01:47] <spm> 110; then 3 x 171's.
[01:47] <lifeless> the older version
[01:47] <lifeless> let me grab that
[01:48] <spm> is stabilising at 171ish.
[01:48] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1906G1635#longstatements
[01:49] <lifeless> 1521ms + 589ms
[01:49] <lifeless> http://pastebin.com/8H8tha0g
[01:49] <lifeless> is the original
[01:50] <lifeless> which is 4.6 seconds coldish on qas
[01:50] <spm> ouchy
[01:50] <lifeless> and 650 hot
[01:50] <lifeless> so yeah, I'm pretty happy with the improvment
[01:51] <lifeless> the new plan is missing the sequential scan on branch :)
[01:52] <mwhudson> !
[01:53] <mwhudson> the tuple read rates that stub produced seem to indicate that something was sequential scanning branch about once a second
[01:53] <mwhudson> lifeless: could you have found that?
[01:56] <lifeless> yes
[01:56] <lifeless> code:+index is the page
[01:56] <lifeless> ppr will tell us hits
[01:56] <lifeless> I would expect multiple causes
[01:56] <mwhudson> i guess any branch filtering is similar queries
[01:57] <lifeless> yeah
[01:57] <lifeless> the double subqueries were either too complex or constrained for some corner case - I think the thing was that they were different
[01:57]  * mwhudson wonders what fraction of branches are private... 
[01:57] <lifeless> so pgsql wasn't coalescing them
[01:58] <lifeless> mwhudson: 3 5ths of bugger all
[01:58] <mwhudson> yeah
[01:58] <mwhudson> if they hit 10% of the table or whatever the threshold is i wildly speculate that we'd have the sequential scans back
[01:58] <mwhudson> but that's unlikely
[01:59] <lifeless> problem for another day
[01:59] <mwhudson> ye
[01:59] <lifeless> you'd actually need 10% of the table for *one context*
[01:59] <mwhudson> oh righ t:)
[01:59] <lifeless> mwhudson: I'm so glad you are here though, you can answer something flummoxing me
[01:59] <lifeless> mwhudson: why does the original (and the new one because i kept it) only constraint the source branch to the product
[02:00] <mwhudson> lifeless: don't know
[02:00] <mwhudson> i guess you can end up with the products being different if you move one of the branches after the mp is created
[02:01] <lifeless> right, but why does moving the target not hide the count; but moving the source does ?
[02:01] <mwhudson> constraining the target branch would seem a bit less wrong though ...
[02:01] <lifeless> *hige it from the count*
[02:02] <mwhudson> lifeless: i bet that whoever wrote this (possibly named after a disney rabbit) assumed that source target and target target are always the same and 'optimized' it
[02:02] <mwhudson> lifeless: just a guess though
[02:02] <lifeless> hahaha
[02:02] <lifeless> tactfully put
[02:02] <lifeless> see the thing is
[02:02] <lifeless> if the target was constrained the original query is fine
[02:03] <lifeless> uhm, if 'source and target are constrained'
[02:03] <mwhudson> heh heh heh
[02:03] <lifeless> DistributionSourcePackage:+code-index 540
[02:03] <mwhudson> yes, my guess doesn't make much sense on that level does it?
[02:03] <lifeless> Product:+code-index 4965
[02:04] <mwhudson> more constraints -> faster query (generally)
[02:04] <lifeless> mwhudson: yes
[02:04] <lifeless> mwhudson: so, 5500 hits a day
[02:04] <lifeless> mwhudson: 2 runs of the query each hit
[02:04] <lifeless> 11K query runs a day
[02:05] <lifeless> 710983.85 is pretty high
[02:05] <mwhudson> lifeless: it's one of these slightly horrible things, we /try/ fairly hard to enforce target target == source target, but i don't think we can completely
[02:05] <lifeless> mwhudson: we can choose to just not report the exceptions :>
[02:05] <mwhudson> yeah, i think that would be fine
[02:05] <mwhudson> lifeless: what is 710983.85 ?
[02:05] <lifeless> branch tuples read per second
[02:06] <mwhudson> ah right
[02:06] <lifeless> https://devpad.canonical.com/~lpqateam/dbr/last-15-mins.txt
[02:06] <mwhudson> yes it is
[02:06] <lifeless> > 3 * bugtask reads
[02:06] <lifeless> and bugs are much higher user activity than branches
[02:06] <lifeless> oh
[02:06] <lifeless> I remember one of the branch thoughts
[02:06] <lifeless> 'url -> disk mapping'
[02:07] <lifeless> still several OOM too high
[02:07] <StevenK> You should not import patch_entry_explicit_version from canonical.launchpad.components.apihelpers:
[02:07] <mwhudson> i'm pretty sure that doesn't seqscan...
[02:07] <StevenK> Did that change recently?
[02:07] <lifeless> StevenK: add it to __all__
[02:07] <lifeless> mwhudson: it doesn't
[02:08] <mwhudson> or even read more than a handful of tuples, so yeah, like you said, an OOM out
[02:08] <mwhudson> at least
[02:09] <mwhudson> i wonder how much cpu 396125.47 tuples/sec uses, it must be more than 0.01% though, and 'rewrite' isn't a user on https://devpad.canonical.com/~lpqateam/dbr/last-15-mins.txt
[02:11] <mwhudson> lifeless: the pillarname read count is demented too, but at least it's obviously a table that gets accessed an awful lot
[02:11] <lifeless> remember that foreign keys on updates take locks
[02:12] <lifeless> possibly on reads too,but I'd need to double check that
[02:20] <lifeless> sinzui: ping
[02:21] <lifeless> sinzui: if you're around; how would you and jc feel about my stabbing at CVE:+index; its consitently 2nd or third on the oops report at the moment
[02:26] <wgrant> What is the scanner doing these last few days?
[02:27] <wgrant> 1600 OOPSes...
[02:35] <LPCIBot> Project db-devel build #488: FAILURE in 4 hr 58 min: https://lpci.wedontsleep.org/job/db-devel/488/
[02:37] <lifeless> wgrant: bug is filed ;)
[02:56] <sinzui> lifeless: go ahead on the cve:+index jcsacket and I were to busy to work on it today
[02:56] <huwshimi> lifeless: Just taking a look at the AJAX logging stuff. What's involved in getting the URL into the header?
[02:57] <lifeless> huwshimi: one cheap hack would be to change the publisher to add an X-header unconditionally on every reponse with the url it got
[02:57] <lifeless> huwshimi: e.g. probably not much
[03:00] <huwshimi> lifeless: Is this going to be bad for us in any way?
[03:01] <lifeless> huwshimi: slightly more response overhead
[03:01] <lifeless> huwshimi: if someone sends a 4K request, they'll get 4K more back
[03:01] <lifeless> huwshimi: (4K URL I mean)
[03:02] <huwshimi> lifeless: Will it be enough of an impact for us not to do it?
[03:02] <wgrant> You can't get at the request from the response?
[03:04] <huwshimi> wgrant: Well this is not really the response. It's an event that fires every time an AJAX even completes, with no other knowledge about the request except what is returned
[03:05] <lifeless> huwshimi: I think we can do it, will just want a brief walk-by the usual suspects to look for gotchas
[03:06] <wgrant> huwshimi: :(
[03:07] <huwshimi> lifeless: I may have just thought of a way to do it without the header, thanks to wgrant's question. I'll have a quick try
[03:07] <lifeless> huwshimi: care to file a bug asking for an X-LP-URL header, and mail the -dev list for feedback.
[03:07] <lifeless> huwshimi: if you can't get it, of course
[03:07] <huwshimi> lifeless: Sure
[03:41] <lifeless> grrr
[03:41] <lifeless> Collections may be great for adhoc assembly
[03:41] <lifeless> but they are terrible for optimisation.
[03:41]  * lifeless puts on the wet blanket hat
[03:47]  * StevenK grumbles.
[03:48] <StevenK> I think python-debian has a bug in it's regex to parse valid versions
[03:48] <mwhudson> oof
[03:48] <wgrant> StevenK: Is it meant to only parse valid versions?
[03:49] <wgrant> Also, why is the solution to AJAX being too slow to limit it to only a few bugtasks? :(
[03:49] <StevenK> wgrant: It accepts : in the upstream version all the time, but that's only valid if there is a epoch.
[03:49] <huwshimi> lifeless: OK I can't reliably get it this way. Is the code for managing the headers outside of Launchpad?
[03:49] <StevenK> (Pulling from my memory, so I could be wrong.)
[03:50] <StevenK> wgrant: It has a re_valid_version regex defined, so I doubt it. I think the regex is naive.
[03:50] <wgrant> StevenK: I don't think it's valuable for it to be terribly pedantic, really.
[03:51] <lifeless> huwshimi: we'd put it in lib/canonical/launchpad/(publisher|publication).py I think.
[03:51] <StevenK> wgrant: In this case, the version that sorts the highest is invalid, and so we can't set it in the DB, due to integry rules.
[03:51] <lifeless> huwshimi: there are some interactions with the api, but I'm 99% sure that starting there would get what we need easily enough
[03:52] <StevenK> wgrant: So I'd like to filter invalid versions from the ancestry sets.
[03:52] <wgrant> StevenK: Right.
[03:53] <StevenK> wgrant: And I'm having trouble convincing debian_support.BaseVersion that "a1:1.8.8-070403-1~priv1" really is invalid.
[03:54] <StevenK> Due to it accepting : in upstream version, it thinks epoch is None, and the upstream version is "a1:1.8.8-070403", which is just wrong.
[03:54] <wgrant> Yeah.
[03:54] <wgrant> Er, thinks the epoch is None?
[03:54] <wgrant> That's a bug.
[03:54] <wgrant> Missing epoch is 0.
[03:55] <StevenK> But it isn't missing, it's invalid :-)
[03:57] <StevenK> % bin/py foo
[03:57] <StevenK> Version: a1:1.8.8-070403-1~priv1
[03:57] <StevenK> Epoch: None
[03:57] <wgrant> Ah, true.
[03:58] <StevenK> IIRC, you can only have :'s in the upstream version iff there is an epoch.
[03:58] <wgrant> That's right.
[03:58] <wgrant> Otherwise it's ambiguous.
[03:58] <wgrant> "This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then the upstream_version may not contain any colons."
[03:59] <StevenK> wgrant: Have a look at python-debian in sourcecode, the re_valid_version is wrong, then.
[04:00] <wgrant> StevenK: I can't really fault it on that. Be conservative in what you do, be liberal in what you accept from others, and all that.
[04:01] <StevenK> wgrant: Suggestions on how to filter invalid versions out of ancestry, then?
[04:02] <lifeless> ohdogohdogohdog
[04:02] <wgrant> StevenK: I'm not sure what's best.
[04:02] <wgrant> lifeless: Oh?
[04:02] <wgrant> lifeless: What completely naïve and non-performant code have you found now?
[04:02] <lifeless> wgrant: GenericBranchCollection uses storm expresses to express constraints
[04:03] <lifeless> wgrant: so I have to unwind them to get the clause to regenerate it with class aliases.
[04:03] <lifeless> because it discards the original context
[04:03] <lifeless> in the adapter
[04:03] <wgrant> :(
[04:03] <StevenK> wgrant: I'm struggling to come up with *any* solution that doesn't involve hacking debian_support.BaseVersion
[04:03] <lifeless> wgrant: its Yet Another Compiler.
[04:03] <lifeless> I should suggest a code review rule : no more compilers.
[04:04] <StevenK> gcc 4 lyfe?
[04:04] <lifeless> StevenK: collections are compilers; wadl creation is a compiler, storm is a compiler.
[04:04] <lifeless> StevenK: BugTaskSet.searchTasks is a compiler
[04:05] <lifeless> StevenK: nearly everything that is easy to use and hard to make fast, is a compiler.
[04:05] <StevenK> I didn't need the explanation, I was trolling.
[04:15] <poolie> lifeless, i'm glad you asked for a simple reproduction because i no longer seem to be able to hit it :)
[04:16] <lifeless> poolie: heh
[04:16] <poolie> this is actually astonishingly fast
[04:16] <poolie> i think something must be wrong
[04:17] <StevenK> Haha
[04:21] <poolie> mm i wasn't measuring the hard part
[04:21] <poolie> damn all software that tries to pretend the network is transparent
[04:21] <poolie> i wonder if i was just measuring some transient misbehaviour before
[04:22] <poolie> anyhow, the good thing is that if this works, it may make kanbans much faster
[04:30] <poolie> lifeless, the numbers from that script are just astonishingly good
[04:30] <poolie> 0.96s for some queries
[04:31] <poolie> i never saw sub-second calls from australia before
[04:31] <poolie> (i guess that's on a warm socket)
[04:31] <spiv> Happiness is a warm socket.
[04:31] <poolie> yeah apparently so
[04:31] <wgrant> Maybe gandwana and potassium finally decided to die.
[04:31] <poolie> ?
[04:32] <poolie> what would that mean, wgrant?
[04:32] <wgrant> poolie: Well, it would speed up requests.
[04:32] <wgrant> Since those two are multithreaded, slow, and the source of most of our timeouts.
[04:33] <poolie> because they're slow appservers?
[04:33] <wgrant> Slow and misconfigured.
[04:41] <StevenK> wgrant: Didn't we port some version validator from somewhere in Soyuz?
[04:42] <wgrant> StevenK: You mean the one that's in the database?
[04:43] <StevenK> wgrant: That one feels a little heavyweight for validating versions
[04:45] <StevenK> wgrant: Dpkg::Version::version_check would be nice, but I can't use that
[04:51] <LPCIBot> Project windmill build #102: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/102/
[04:53] <wgrant> wallyworld: Those two Windmill failures look like yours, I think.
[04:53] <wallyworld> wgrant: oh :-(
[04:54] <wallyworld> i'msure they passed locally :-(
[04:54] <wallyworld> wgrant: https://code.launchpad.net/~wallyworld/launchpad/recipe-text-xss/+merge/54638
[04:54] <lifeless> ahhh
[04:54] <lifeless>  1 file changed, 31 insertions(+), 35 deletions(-)
[04:54] <lifeless> \o/
[04:54]  * wallyworld has to go get kid from school
[04:54] <lifeless> deleting code *and* making things faster
[04:57] <huwshimi> lifeless: Any suggestions on how I can break an AJAX request so it returns an exception?
[04:57] <huwshimi> lifeless: I mean returns an oops id
[04:58] <lifeless> break the server side code
[04:58] <lifeless> add
[04:58] <lifeless> raise Exception('zomg')
[04:58] <lifeless> to the code path
[04:58] <huwshimi> lifeless: ok
[04:58] <poolie> lifeless, i think some other change must have fixed it
[04:59] <lifeless> huwshimi: your demo was -really really shiny-
[04:59] <poolie> i'm running the same code i was then and i no longer see the effect
[04:59] <lifeless> poolie: sure
[04:59] <lifeless> poolie: I believe that you saw it
[04:59] <lifeless> poolie: I *suspect* it was doing a full text search for '' or something equally daft
[04:59] <lifeless> (we repacked the fti index for bug recently)
[05:00] <lifeless> [amongst other fixes such as improving component fixes, related bugs yada yada yada]
[05:00] <poolie> i certainly wasn't asking for that
[05:00] <poolie> it's possible that lplib or the server did end up doing it
[05:00] <lifeless> poolie: thats what I'm sketching
[05:00] <poolie> yeah
[05:00] <lifeless> its the only thing I can think of that might vary
[05:00] <poolie> anyhow, the bottom line on performance is actually quite interesting:
[05:00] <lifeless> because the collections are really just function calls to searchTasks
[05:00] <poolie> single calls are quite impressively fast
[05:01] <poolie> however, if you have to do 600 of them, not so much
[05:01] <poolie> thus my braindump
[05:01] <lifeless> poolie: sure; that aspect has been heavily sketched out in the filter+expand API LEP
[05:01] <poolie> yep
[05:24] <huwshimi> lifeless: OK, I don't know enough about Launchpad's internals to break this request. Any clues about where to look?
[05:37] <huwshimi> lifeless: Also are there any time recommendations that we have for AJAX requests? E.g. over 5 seconds is very bad under 2 seconds is good
[05:48] <lifeless> huwshimi: ajax requests are no different than others
[05:48] <lifeless> huwshimi: we're (long term) aiming at subsecond for 99% of requests and under 5 seconds for all
[05:48] <lifeless> huwshimi: current timeout limit is 11 seconds
[05:48] <lifeless> huwshimi: I think colouring anything > 1 second a vivid shade would be sensible ;)
[05:49] <huwshimi> lifeless: OK, I'll do >1 second for now
[05:50] <lifeless> most ajax things should be very targeted operations
[05:50] <lifeless> unlike e.g. a bug listing page
[05:50] <lifeless> at least for now
[05:51] <micahg> hi lifeless
[05:52] <lifeless> hiya
[05:55] <micahg> lifeless: so, several years ago, I wrote some javascript code to output an HTML table that needed to be displayed multiple times on a page (i.e. output with document.write) and that sped up load time tremendously, could something like that work as a stop gap for the repetitive JS code until it can be refactored properly?
[05:56] <lifeless> micahg: that sounds like it would be refactoring it properly
[05:56] <huwshimi> lifeless: so, any clues on how API internals work. Like, where does the API code for bugs live?
[05:57] <lifeless> huwshimi: lib/lp/bugs/model
[05:57] <lifeless> huwshimi: whats the url you are calling ?
[05:57] <micahg> lifeless: well, no this would just output the javascript inline as opposed to using a function w/params and have one copy of the JS code in the rendered page
[05:57] <huwshimi> lifeless: But if I raise the exception there won't it be broken for the normal request as well?
[05:57] <lifeless> huwshimi: yes
[05:57] <lifeless> huwshimi: are you trying to check it works, or write an automated test ?
[05:58] <huwshimi> lifeless: I'm trying to check it works
[05:58] <lifeless> huwshimi: because, for the latter, its a bit complex: we don't want /any/ broken apis in the system, so you have to register a broken one temporarily, use it, then unregister in your test.
[05:58] <wgrant> lifeless: Are you sure your +needs-packaging change is OK?
[05:58] <lifeless> huwshimi: right, so pick something - like mark as duplicate
[05:59] <lifeless> wgrant: if I marked it as such, I tested it on qastaging
[05:59] <lifeless> wgrant: why do you ask ?
[05:59] <wgrant> lifeless: It's not QA'd yet, but it's gone from timing out on lpnet to 0.2s on qas.
[05:59] <wgrant> So I'm a bit suspicious.
[05:59] <lifeless> wgrant: sounds right
[05:59] <wgrant> Seriously?
[06:00] <wgrant> The results look fine.
[06:00] <wgrant> But the time is not plausible.
[06:00] <lifeless> oh ye of little faith
[06:02] <lifeless> https://answers.qastaging.launchpad.net/ubuntu/karmic/+needs-packaging was 2.43 on qastaging
[06:02]  * lifeless looks at a profile
[06:03] <wgrant> natty's first batch is 0.20 to 0.25s.
[06:03] <wgrant> 0.17 just now.
[06:04] <lifeless> 00294-01256 SELECT COUNT(*) FROM SourcePackageName, (SELECT ...
[06:04] <lifeless> 01259-02197@SQL-launchpad-main-slave SELECT DISTINCT ON (score ...
[06:04] <lifeless> it looks plausible to me
[06:04] <lifeless> wgrant: you do realise it has memcache in there
[06:04] <lifeless> wgrant: which I didn't touch
[06:04] <wgrant> Oh.
[06:05] <wgrant> Indeed. a more plausible 1.7s on the next batch..
[06:05] <lifeless> wgrant: 2.5 seconds cold, 0.2 in memcache
[06:05] <lifeless> I think its qa ok indeed
[06:05] <lifeless> marked as such
[06:05] <lifeless> wgrant: I'll whip through and do all mine
[06:06] <wgrant> lifeless: Great. I'm doing the others'.
[06:07] <lifeless> done
[06:16] <micahg> lifeless: so, I commented on bug 735966, but almost instantly regretted it, is that the same bug?
[06:16] <_mup_> Bug #735966: Product:+bugs timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735966 >
[06:16] <micahg> I hit the crash again, so I figured I'd confirm
[06:19]  * StevenK nails wgrant to the channel
[06:19] <wgrant> Huh.
[06:19] <wgrant> Thanks Optus.
[06:20] <wgrant> We were throttled for almost 10 minutes.
[06:20] <wgrant> To 28kbps.
[06:20] <wgrant> Despite being at 70% of our quota...
[06:20] <StevenK> Haha
[06:24] <huwshimi> lifeless: Gotta run in a minute, but this is where I'm leaving it for today: http://people.canonical.com/~huwshimi/ajax_time_log.ogv
[06:29]  * huwshimi is gone
[06:38] <lifeless> micahg: may be, may not be :P
[06:46] <micahg> lifeless: should I file a new bug with my new oops code and you can dupe if appropriate?
[06:46] <lifeless> no need
[06:47] <micahg> ok, do you want the oops?
[06:47] <lifeless> you put it in the comment already
[06:47] <micahg> lifeless: no, I got a new one today
[06:59] <StevenK> wgrant: http://pastebin.ubuntu.com/585234/ makes me sad.
[07:01] <wgrant> StevenK: Doesn't that forbid upstream versions with colons?
[07:03] <StevenK> wgrant: Probably.
[07:04] <StevenK> wgrant: I looked at the check_version sub in Dpkg::Version, and I didn't feel like porting it to Python so I can use it. But I suspect it's the better answer.
[07:05] <wgrant> StevenK: So python-debian doesn't have a useful checker? What about python-apt?
[07:05] <StevenK> wgrant: I couldn't see one in apt_pkg
[07:05] <StevenK> wgrant: python-debian's checker is too lax for our needs, since the DB's own checker is strict.
[07:06] <StevenK> Doing it in one regex is not the way
[07:08] <wgrant> :( qa-bad
[07:08] <StevenK> wgrant: Which rev? :-(
[07:09] <wgrant> StevenK: The Soyuz translations change.
[07:09] <wgrant> Missing DB perms.
[07:10] <StevenK> Which points to missing tests, too.
[07:14] <StevenK> I think the qa-tagger needs to run more often
[07:21] <lifeless> micahg: probably hasn't changed
[07:21] <micahg> lifeless: ok
[07:23] <wgrant> Huh, translations sharing works.
[07:24] <henninge> wgrant: Hi!
[07:24] <wgrant> henninge: Hi.
[07:25] <henninge> wgrant: why did you mark bug 741571 bad?
[07:25] <_mup_> Bug #741571: Translation templates should always be uploaded from soyuz builds. <qa-bad> <regression> <upstream-translations-sharing> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/741571 >
[07:25] <wgrant> Just testing out the Soyuz translations changes on DF.
[07:25] <wgrant> henninge: I'm going to comment in a sec.
[07:25] <henninge> ok
[07:25] <wgrant> But there's a missing DB perm.
[07:25] <wgrant> queued needs SELECT on packaging.
[07:25] <wgrant> Apart from that it seems to be OK.
[07:26] <wgrant> I think I've just got an upstream template in place, so we'll see now if the POs are skipped...
[07:26] <lifeless> wgrant: is it for the jon thats not running et ?
[07:26] <henninge> yeah, it's actually a pretty simple change, so I'd have been surprised if it went wrong.
[07:26] <wgrant> lifeless: It's running.
[07:26] <lifeless> ah
[07:26] <wgrant> lifeless: But on germanium/cocoplum.
[07:26] <wgrant> So we can nodowntime with a little process skipping.
[07:26] <henninge> wgrant: thanks, I was about to try to find out how I could QA this best.
[07:27] <wgrant> henninge: Could you QA your other change? The big cleanup thing?
[07:27] <henninge> wgrant: yes, I am doing that atm.
[07:28] <wgrant> Great.
[07:28] <wgrant> buildbot should finish shortly.
[07:28] <henninge> although it's a lot of refactoring, so this is mostly "see that nothing broke".
[07:28] <wgrant> Yup.
[07:30] <StevenK> How many revs will the buildbot-poller pull in?
[07:30] <wgrant> Success.
[07:30] <wgrant> StevenK: 1
[07:30] <wgrant> henninge: https://translations.dogfood.launchpad.net/ubuntu/maverick/+source/hello/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all
[07:31] <wgrant> No POs.
[07:36] <LPCIBot> Yippie, build fixed!
[07:36] <LPCIBot> Project db-devel build #489: FIXED in 5 hr 0 min: https://lpci.wedontsleep.org/job/db-devel/489/
[07:39] <lifeless> \o/ private branch query on lp with me is still only 500ms
[07:39] <lifeless> we need to redo the privacy queries comprehensively, but this will do for now
[07:56] <henninge> wgrant: cool, thanks!
[07:56] <henninge> wgrant: so, we need a branch for the db permission?
[07:56] <wgrant> henninge: Yeah, ideally with tests.
[07:57] <wgrant> henninge: Can your squad handle that soonish?
[07:57] <henninge> wgrant: yeah, sure
[07:58] <wgrant> henninge: Thanks.
[07:59] <wgrant> lifeless: Should we deploy even with the missing DB perm?
[08:00] <wgrant> win 3
[08:10] <lifeless> wgrant: will it break ?
[08:10] <lifeless> wgrant: can we avoid it breaking ?
[08:11] <wgrant> lifeless: It only affects cocoplum.
[08:11] <wgrant> Which is way outside nodowntime.
[08:12] <lifeless> wgrant: +1
[08:12] <wgrant> lifeless: Thanks.
[08:31] <wgrant> henninge: Should we just qa-untestable that refactor?
[08:32] <henninge> wgrant: yeah, I was thinking about that too. I am busy now with the missing db permissions.
[08:32] <wgrant> henninge: Have you filed a bug?
[08:33] <henninge> wgrant: do I need to? I was going to do it on the existing bug.
[08:33] <henninge> I can, np.
[08:33] <wgrant> henninge: We are going to deploy this broken code, so I'd like a Critical one targetted to 11.04 to make sure we fix it before it's deployed to the relevant machines.
[08:34] <henninge> wgrant: makes sense. I'll file it.
[08:35] <wgrant> henninge: Thanks.
[08:38] <henninge> wgrant: are both cocoplum and germanium production machines?
[08:38] <wgrant> henninge: Yes.
[08:38] <wgrant> henninge: cocoplum = ftpmaster, germanium = ppa
[08:38] <wgrant> Neither is nodowntime.
[08:38] <henninge> ok
[08:39] <henninge> wgrant: bug 742309
[08:39] <_mup_> Bug #742309: Missing db permissions for soyuz translation uploads. <upstream-translations-sharing> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/742309 >
[08:39] <wgrant> henninge: Thanks.
[08:47] <lifeless> right, works
[08:47] <lifeless>  branchcollection.py |   85 +++++++++++++++++++++++-----------------------------
[08:47] <lifeless>  1 file changed, 39 insertions(+), 46 deletions(-)
[08:48] <adeuring> good morning
[08:53] <henninge> Hi adeuring!
[08:54] <adeuring> hi henninge
[08:54] <henninge> adeuring: bug 742309
[08:54] <_mup_> Bug #742309: Missing db permissions for soyuz translation uploads. <upstream-translations-sharing> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/742309 >
[08:54] <adeuring> yes?
[08:54] <lifeless> can has review? https://code.launchpad.net/~lifeless/launchpad/bug-736008/+merge/54820
[08:54] <adeuring> lifeless: sure
[08:55] <henninge> adeuring: just so you know. ;)
[08:55] <adeuring> henninge: ah, thanks, now i understand
[09:03] <lifeless> adeuring: https://bugs.launchpad.net/launchpad/+bug/736008 has all the experimentation for that branch, if you want the backstory
[09:04] <_mup_> Bug #736008: Product:+code-index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736008 >
[09:05] <LPCIBot> Project windmill build #103: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/103/
[09:08] <mrevell> Morning
[09:09] <lifeless> oh god
[09:09] <lifeless> no wonder jc had trouble on cve:+index. its bugtask:+index all over again
[09:13] <henninge> wgrant, adeuring: https://code.launchpad.net/~henninge/launchpad/devel-741571-db-permissions/+merge/54823
[09:13] <henninge> If either of you could be so kind.
[09:14] <henninge> I have to run an errand now but will be back later to land it.
[09:14] <adeuring> henninge: i'll once I've finished robert's mp
[09:14] <henninge> I don't see how this branch would profit from a full test suite run.
[09:14] <henninge> adeuring: thanks
[09:14] <wgrant> henninge: As long as you've run the new test then lp-land it.
[09:14] <henninge> of course ;-)
[09:28] <lifeless> wow
[09:29] <lifeless> https://bugs.launchpad.dev/bugs/cve/1999-8979
[09:29] <lifeless> 262 queries/external actions issued in 6.15 seconds
[09:29] <lifeless> locally
[09:29] <lifeless> oh, rotfl
[09:29] <wgrant> ?
[09:29] <lifeless> I crewated 200 or so tasks for it
[09:30] <StevenK> "crewated"
[09:30] <StevenK> :-P
[09:30] <lifeless> Product-name903534, Product-name903544 etc
[09:30] <wgrant> I'm surprised shortlist didn't slap you.
[09:49] <adeuring> lifeless: r=me
[09:50] <lifeless> adeuring: thanks
[09:52] <lifeless> wow
[09:52] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1904QS73 query 304
[09:54] <spiv> lifeless: at least it's quick!
[09:55] <lifeless> spiv: indeed
[09:56] <adeuring> henninge-afk: r=me, 1 typo spotted
[10:06] <lifeless> stub: ping
[10:07] <stub> lifeless: pong
[10:07] <lifeless> bug 618406
[10:07] <_mup_> Bug #618406: Distribution:+bugs-index time outs <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618406 >
[10:07] <lifeless> stub: I'm wondering if a matching index is better than modifying the query
[10:08] <lifeless> bugheat__id__idx on (Bug.heat DESC, BugTask.id)
[10:09] <stub> looking
[10:11] <stub> lifeless: You would have to denormalize the heat onto bugtask for that index.
[10:12] <lifeless> stub: bwah, of course
[10:12] <lifeless> I'm just tired and forgetting
[10:13] <stub> A (Bug.heat, Bug.id) might help though - join and order in one step
[10:15] <stub> Although we would likely need to change the ordering to (Bug.heat DESC, Bug.id DESC), and get rows ordered inconsistently if there happen to be more than one bug task being matched.
[10:20] <lifeless> stub: (bug.heat desc, bug.id) would work fine
[10:20] <lifeless> stub: the index can sort different columns differently afte rall
[10:20] <stub> Thats new too
[10:20] <lifeless> nah
[10:21] <lifeless> not sure when it was added, but definitely existed in 8.3
[10:21] <stub> You used to have to make the index match. 8.3 is new - This all used to run under 7.4 remember, and I started with PG 7.0 :)
[10:22] <lifeless> you do need it to match
[10:22] <lifeless> you have to tell the index that one column is up and one down
[10:22] <stub> ok. we are on the same page :)
[10:23] <stub> I could rationalise that newer bugs are hotter, all else being equal
[10:23] <lifeless> or older bugs need fixing more ;)
[10:24] <lifeless> http://www.postgresql.org/docs/8.4/static/indexes-ordering.html is the docs
[10:27] <lifeless> why oh why do cve pages show bug editing controls.
[10:38] <henninge> adeuring: thanks
[10:38] <adeuring> welcome
[10:51] <henninge> wgrant: fix has been merged
[10:51]  * henninge relocates.
[10:52] <wgrant> herb: Fantastic. Thanks.
[10:52] <wgrant> Er.
[10:52] <wgrant> henninge.
[10:54] <leonardr> wallyworld_, i'm up if you want to talk (on irc, my wife is asleep)
[11:00] <deryck> Morning, all.
[11:33] <mrevell> Should debhelper be a dependency of bzr-builder?
[11:34] <lifeless> stub: will you add such an index?
[11:35] <stub> lifeless: I will test later - doing my paperwork atm. I think it unlikely to help, but worth giving it a shot anyway.
[11:35] <stub> (This is the bug.head, bug.id index?)
[11:35] <lifeless> bug.heat, bug.id desc
[11:35] <lifeless> yeah
[11:35] <lifeless> sorted by heat alone its a 3ms query
[11:36] <lifeless> or something rad like that
[11:39] <lifeless> stub: thanks
[11:40] <stub> lifeless: I doubt we can improve on that. I guess the results might be more stable if we add more fields, but I think faster queries will be the preference.
[11:42] <lifeless> stub: right, the question is, is heat desc + id fast enough - if it is, its a trivial change, add the index, done.
[11:43] <stub> Agreed.
[11:43] <lifeless> if its not, we have to see if we break the test suite etc etc
[11:43] <lifeless> mmm, I guess we may anyway with bug.id being needed
[11:43] <stub> Heat + Bug.id still can break tests - multiple bug tasks will be returned in arbitrary order
[11:43] <lifeless> yeah
[11:43] <lifeless> on distro I guess
[11:44] <lifeless> should probably only return one task for this search
[11:44] <stub> I think the only thing that really cares is the test suite, so it will be sucky to have worse performance just to keep it happy
[11:44] <lifeless> blah, we have to do a code change regardless
[11:44] <lifeless> agreed
[11:44] <lifeless> I keep forgetting the cross table aspect
[11:56] <leonardr> adeuring: a small branch, https://code.launchpad.net/~leonardr/lazr.restful/449561/+merge/54849
[11:56] <adeuring> leonardr: I'll look
[11:58] <cjwatson> I have two approved branches to land, but I don't have direct landing access (AFAIK).  Can somebody help me with this?
[11:58] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152
[11:58] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/tar-xz
[11:58] <wgrant> cjwatson: Sorry, forgot about those.
[11:58] <wgrant> I'll send them to ec2.
[11:58] <cjwatson> no problem, the first one only just got the IS side done
[11:58] <cjwatson> thanks
[11:58] <wgrant> cjwatson: Which IS side? Getting a new dpkg out?
[11:59] <wgrant> We still probably can't land the first one, unless the new dpkg is also in our ec2 AMIs.
[11:59] <wgrant> And buildbot machines.
[12:00] <wgrant> It's also needed on germanium and cesium.
[12:00] <cjwatson> New dpkg, yes.  Don't the buildbot machines use dpkg from chroots?
[12:00] <wgrant> buildbot != buildd
[12:01] <cjwatson> We don't actually need the new dpkg to pass LP tests, do we?
[12:01] <cjwatson> oh, maybe
[12:02] <wgrant> testXZDebUpload would test that, I hope.
[12:02] <cjwatson> I guess we do, since bar_1.0-1_xz has 'dpkg-deb -Zxz -b debian/tmp ..'.
[12:02] <wgrant> Yeah.
[12:03] <cjwatson> so what's involved in getting a new dpkg into AMIs and buildbots?
[12:03] <wgrant> buildbot needs the new dpkg in CAT, and a LOSA poke.
[12:03] <wgrant> ec2test AMIs need the new dpkg in ppa:launchpad, and a Launchpad engineer poke.
[12:04] <cjwatson> I've reopened the RT ticket asking for germanium and cesium to be upgraded.
[12:04] <cjwatson> new dpkg is already in CAT.
[12:04] <wgrant> Great.
[12:04] <cjwatson> (lucid-cat)
[12:05] <cjwatson> what's the relevant distroseries for ppa:launchpad?
[12:06] <cjwatson> and how should I ask for buildbot to be upgraded?  RT or IRC ping?
[12:06] <wgrant> I've already poked.
[12:06] <wgrant> Do you have a copy of the package handy? I'll upload it to the PPA.
[12:06] <wgrant> I guess I could grab it from cat.
[12:07] <cjwatson> it's in my home directory on chinstrap too
[12:07] <cjwatson> dpkg_1.15.5.6ubuntu4.5.IS.PATCHED.10.04_source.changes (you may want to reversion, of course)
[12:07] <wgrant> Yup.
[12:07] <wgrant> thanks.
[12:08] <wgrant> Could you set a commit message for both?
[12:10] <cjwatson> do I need any r= type runes in it?
[12:10] <wgrant> No, ec2 land will add those.
[12:10] <cjwatson> set for both, then
[12:11] <wgrant> Thanks.
[12:12] <adeuring> leonardr: r=me
[12:15] <wgrant> cjwatson: dpkg_1.15.5.6ubuntu4.5.IS.PATCHED.10.04.tar.bz2 is 600
[12:16] <cjwatson> hah, lamont clearly cheated
[12:16] <cjwatson> fixed
[12:16] <wgrant> Heh.
[12:22] <dpm> hi jml, did you have the chance to look at the AppDeveloperWeek LP session?
[12:23] <jml> dpm: busy right now, sorry.
[12:25] <dpm> jml, no worries. When you've got some time, if you could tell me if you or someone else would be up for it, I'd add it to the timetable. It would be great to have at least a LP session
[12:25] <dpm> thanks
[12:26] <jml> dpm: will do. trust me, it's not forgotten.
[12:29] <dpm> thanks jml :)
[12:31] <wgrant> jam: Hi.
[12:31] <jam> hey wgrant
[12:32] <jam> thanks for your work on loggerhead
[12:32] <wgrant> jam: Bug #742390
[12:32] <_mup_> Bug #742390: page generation problem <codebrowse> <oops> <regression> <Launchpad itself:Triaged> <loggerhead:New> < https://launchpad.net/bugs/742390 >
[12:32] <wgrant> Wondered if you had any ideas on that.
[12:33] <jam> wgrant: mismatch between version of bzrlib and loggerhead
[12:33] <jam> wgrant: that page must have a "tag" in it, that the other pages don't have
[12:34] <jam> wgrant: I'm checking when we introduced it in bzr now
[12:36] <jam> wgrant: looks like it was introduced in bzr 2.3
[12:36] <jam> and I'm guessing LP is still using 2.2?
[12:37] <jam> wgrant: note that "bzr-2.2 selftest -s bp.loggerhead" would have caught this. Is there a reasonable way to integrate that into the LP test suite?
[12:37] <jam> (run the loggerhead test suite from the bzr that is going to be deployed?)
[12:40] <wgrant> jam: We can (and should) probably do that somehow.
[12:40] <jam> wgrant: I think part of the confusion is that loggerhead used to be standalone, and then became a bzr plugin
[12:41] <wgrant> Yeah.
[12:41] <wgrant> (we use 2.2.3dev, apparently. not been updated lately)
[12:41] <jam> wgrant: the really easy fix is to just comment out that line
[12:41] <jam> we don't *have* to sort the tags
[12:41] <jam> I did it to get stable results in the test suite
[12:41] <jam> since otherwise it is 'random'
[12:42] <jam> I thought it would be nice to have a sort order for them anyway
[12:44] <jam> wgrant: https://bugs.launchpad.net/launchpad/+bug/742390/comments/5
[12:44] <_mup_> Bug #742390: page generation problem <codebrowse> <oops> <regression> <Launchpad itself:Triaged> <loggerhead:New> < https://launchpad.net/bugs/742390 >
[12:44] <jam> Possible fix
[12:44] <jam> it will make codebrowse stop OOPSing
[12:44] <jam> though it also fails the test suite
[12:44] <jam> because, you know, it isn't natural sorting :)
[12:47] <wgrant> jam: It's just about midnight here. Can you fix trunk?
[12:49] <jam> wgrant: Pushing a change for review now
[12:49] <jam> what do we need to do to get it rolled out?
[12:50] <wgrant> A buildbot run started 2 minutes ago, so without a cowboy it will be 10 hours, at which point we have no LOSA.
[12:50] <jam> wgrant: buildbot takes 10 hours to run? yeouch
[12:50] <wgrant> jam: Only 4.5 or so.
[12:51] <wgrant> But if we land it now then it will be waiting for the next one.
[12:51] <jam> wgrant: https://code.launchpad.net/~jameinel/loggerhead/sort-742390/+merge/54855
[12:51] <jam> I can land and propose an update to LP, or do we want to 'lp-land' the sourcecode update?
[12:52] <jam> wgrant: I confirmed that the test suite passes on bzr 2.2, 2.3, and dev with that patch
[12:52] <jam> (not that the loggerhead test suite is all that complete at this point, but it is getting better)
[12:52] <wgrant> I think we get this into LH trunk, land the sourcedeps.conf change to LP, pull the new LH rev onto guava, restart codebrowse.
[12:52] <wgrant> Yeah, I noticed it's much better now.
[12:53] <wgrant> Is the LH review policy the same as the LP one?
[12:53] <wgrant> ie. can I not approve it on my own?
[12:53] <jam> wgrant: it is probably closer to the bazaar one, but you certainly can approve it yourself
[12:53] <wgrant> (since I'm not a full reviewer yet)
[12:54] <jam> wgrant: you've got more experience in loggerhead than most of the rest of them :)
[12:54] <wgrant> True.
[12:54] <wgrant> jam: So, looks fine to lend as long as the tests pass with all three bzrs.
[12:55] <jam> wgrant: k, how do we get it landed in LP ,then?
[12:56] <wgrant> jam: Set the revno in utilities/sourcedeps.conf.
[12:56] <jam> sure, I know that
[12:56] <jam> the *landing* is the part for me
[12:57] <wgrant> You mean getting it onto prod right now?
[12:58] <wgrant> Since it's landed no differently than normal...
[12:59] <jam> wgrant: /me => not a lp dev, don't have the tools or authority for stuff like lp-land or ec2land
[12:59] <jam> I happen to play one on tv
[13:00] <jam> I *only* happen to play one on tv
[13:00] <wgrant> Oh, I thought you would by now.
[13:00] <wgrant> OK.
[13:00] <wgrant> So, propose, get it reviewed by a full reviewer, poke them to land it if I'm already asleep.
[13:02] <wgrant> Bah.
[13:03] <wgrant> The last tag on lp:loggerhead was on r421. My quick QA involved only the first page of results for that branch, which only went back to r423 :/
[13:03] <wgrant> So close.
[13:04] <jam> wgrant: so you would have noticed in QA if it had gone back another couple revs. That's life, I think, and why you want a nice stable automated test suite, rather than expecting human QA to find stuff
[13:04] <jam> (they are complimentary, as Human QA detects things that are hard to automate, but is really bad at repeatability and checking all edge cases)
[13:05] <wgrant> jam: Yeah, and the other branches I tested were lp:launchpad and one with crafted filenames, neither of which have any tags.
[13:05] <wgrant> Fail.
[13:05] <wgrant> Anyway, confirmed that fix works on a local instance.
[13:05] <wgrant> (of LP codebrowse)
[13:06] <leonardr> lifeless: quick question on bug 61531 if you're still around. does the behavior i describe fall within the "404-from-lp-action logic" you mention?
[13:06] <_mup_> Bug #61531: Forbidden error when trying to mark a bug as private <lp-bugs> <oops> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/61531 >
[13:07] <jam> wgrant: how *do* you qa loggerhead? Given that you can't actually connect to qastaging?
[13:07] <jam> I think you said something about firewall holes?
[13:07] <wgrant> jam: There are convenient firewall holes.
[13:16] <jam> adeuring: can you have a look at: https://code.launchpad.net/~jameinel/launchpad/loggerhead-oops-742390/+merge/54858
[13:16] <jam> wgrant: ^^
[13:20] <jam> anyone?
[13:27] <jam> wgrant: can you lp-land the fix then? Or you have to wait for a full reviewer?
[13:28] <wgrant> jam: My code* is worth nothing, sadly.
[13:28] <wgrant> Needs a full reviewer.
[13:28] <jam> know anyone who would be up at this time?
[13:28] <jam> jml: ^^
[13:28] <wgrant> Half the team is up at this time :)
[13:29] <jam> wgrant: though apparently not reading IRC :)
[13:29] <jcsackett> jam: looking now.
[13:29] <jam> thanks jcsackett
[13:30] <wallyworld_> leonardr: the latest larz restful mp is showing conflicts but i'm not sure why. none on my system and if i run a merge --preview it's clean
[13:30] <leonardr> wallyworld, give me a url
[13:31] <jcsackett> jam: r=me. not sure about lp-landing instead of ec2ing it. i understand your rationale, but i am a timid man.
[13:31] <wgrant> lp-land is safe because of what allowed this to break (the test suite isn't run). But there's no time benefit at this time of week, so might as well ec2 it.
[13:32] <wallyworld_> leonardr: https://code.launchpad.net/~wallyworld/lazr.restful/propogate-notifications/+merge/54690
[13:32] <jam> jcsackett: up to you, but there are no tests being run for loggerhead at the moment
[13:32] <jam> hopefully will be fixed soon (by me)
[13:32] <jam> bug #742446
[13:32] <_mup_> Bug #742446: Launchpad should include loggerhead's test suite <Launchpad itself:Triaged by jameinel> < https://launchpad.net/bugs/742446 >
[13:33] <jam> jcsackett: if it helps, it was just rolled out in production
[13:33] <deryck> wallyworld_: hi
[13:33] <leonardr> wallyworld: you're conflicting with a change i just landed. have you updated your copy of lazr.restful trunk?
[13:33] <wallyworld_> deryck: hi there
[13:33] <jcsackett> jam: huh. given that and what wgrant just said, i guess there's not much concern.
[13:33] <wallyworld_> yes
[13:33] <wallyworld_> leonardr: and merge into my branch and resolved conflicts and committed and pushed
[13:34] <deryck> wallyworld_: test_multicheckbox is failing in windmill test run....
[13:34] <leonardr> that is weird
[13:34] <deryck> wallyworld_: I think I was horribly wrong about the disappearing console not mattering.
[13:34] <jam> jcsackett: anyway, if you can run ec2land or lpland for me, I would appreciate it.
[13:34] <jam> since the fix is in production, you have all the time you want to do it either way
[13:34] <jcsackett> jam: ah, right, you need someone to land it for you. forgot that bit. i'll get it sent out.
[13:34] <wallyworld_> deryck: yeah :-( i haven't had time to look yet since my plate today has overflowed due to the bug notification incident etc
[13:35] <wgrant> We won't have time this week to deploy, so it's not time-critical.
[13:35] <deryck> wallyworld_: no worries.  I'm debugging it a bit for you.  Looks like it's the activator's fault.  Probably that flash a custom node stuff.
[13:35] <jam> wgrant: I can confirm that http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/revision/421 works
[13:35] <wallyworld_> deryck: i did have a quick look and couldn't figure out how to stop the disappearing stuff
[13:35] <wgrant> jam: I checked the URLs in the bug too.
[13:35] <wgrant> jam: All looks good.
[13:35] <wgrant> jam: Thanks for the very quick fix :)
[13:35] <adeuring1> jam: I'll look
[13:35] <wallyworld_> deryck: you're awesome for doing that. thanks
[13:36] <jam> adeuring1: we got it done, jcsackett handled it, thanks, though
[13:36] <adeuring1> ak, ok. sorry was out for lunch
[13:36] <wallyworld_> deryck: if it is the activator, i guess it's a bug or at least a test environment incompatibility that needs fixing
[13:37] <deryck> wallyworld_: yeah, I think it's a bug in handling custom supplied nodes.  This will fix the test:  http://pastebin.ubuntu.com/585380/
[13:37]  * wallyworld_ looks
[13:37] <deryck> wallyworld_: but I'm not sure how to fix the real  issue yet.
[13:38] <deryck> ah, interesting!  It's not the missing console causing the failure.
[13:38] <deryck> I get real output now though....
[13:38] <wallyworld_> deryck: ah ok. remove those lines and i think it won't flash anymore :-)
[13:38] <deryck> right
[13:38] <wallyworld_> deryck: wonder why we haven't seen this before. maybe not enough js tests
[13:39] <deryck> wallyworld_: I think it's a misdirection.... getting a new paste now that I have a real error
[13:40] <deryck> wallyworld_: here's the real failure now:  http://pastebin.ubuntu.com/585384/.  I guess the console stuff was masking it.
[13:40] <wallyworld_> leonardr: i may just pull another branch and try again. but in the meantime you could look at my latest changes. it's late here now and we can talk in a few hours for our last standup
[13:40]  * wallyworld_ looks at pastebin
[13:41] <leonardr> will do
[13:43] <wallyworld_> deryck: thanks. i'll get it sorted and put up a mp. but not tonight. i'll try and get it done over the w/e
[13:43] <leonardr> wallyworld: i get the conflicts when i check out your branch and merge trunk. i'll resolve them and push for you
[13:43] <jml> qastaging down?
[13:43] <wgrant> jml: It's updating.
[13:43] <jml> wgrant: ok.
[13:44] <wgrant> Hmmmm.
[13:44] <wallyworld_> leonardr: thanks, that's great. not sure why my local copy is clean.
[13:44] <jml> deryck: I'm going to need to have a chat with you today to make further progress on this testing
[13:44] <deryck> wallyworld_: no worries, man.  I'll fix it for you.  It looks easy.
[13:44] <deryck> jml: ok, cool.  progress FTW!  Any particular time?
[13:44] <jml> deryck: but not right now. should clear up a few things locally first.
[13:44] <wallyworld_> deryck: cool. i'll owe you a beer at uds or the next epic
[13:44] <deryck> jml: ok.  just ping when you're ready.
[13:45] <jml> deryck: will do.
[13:45] <deryck> wallyworld_: don't worry about it.  but, of course, I'll not turn down free drink. ;)
[13:45] <wgrant> jml: It's back.
[13:45] <leonardr> wallyworld: lp:~leonardr/lazr.restful/propogate-notifications
[13:46] <wallyworld_> deryck: i am enjoying my forays into yui land etc. just wish there were better debugging tools. firebug is ok but...
[13:46]  * wallyworld_ looks at leonards mp
[13:46] <wallyworld_> i mean branch
[13:47] <deryck> wallyworld_: yeah, debugging is hard.  rockstar was supposed to ask about pro debugging tips at the YUI conf he attended, but I never checked back about that.
[13:47] <deryck> rockstar: anything more than "use firebug" for that ^^ ?
[13:47] <wgrant> jcsackett, jam: I'll land the branch, since sleep is blocked on that.
[13:47] <rockstar> deryck, wallyworld_, generally I've just got used to all the common screw ups, and know what they mean.
[13:48] <jam> wgrant: thanks
[13:48] <jcsackett> wgrant: that would be good, as bzr is not working for me at the moment.
[13:48]  * jcsackett prepares to stab his computer
[13:48] <wgrant> jcsackett: Fun.
[13:48] <deryck> rockstar: yeah, me too.  I suspect what wallyworld_ means is better facility for working out what is wrong when you don't know.
[13:48] <jcsackett> wgrant: always. :-P
[13:49] <wallyworld_> rockstar: i rely  alot on Y.log(). takes be back 15 years ago before there were decent java ide's :-)
[13:49] <wallyworld_> deryck: rockstar: yeah, the ability to step through code and look at variables and evaluate expressions etc
[13:49] <deryck> rockstar, wallyworld_ -- I think filter debug is nice for log noise and working it out.  Liberal Y.log is your friend, etc.  I'm not sure what else to suggest.
[13:49] <deryck> wallyworld_: you can't step through with firebug?
[13:49] <rockstar> deryck, wallyworld_, that sounds unhelpful, I know.  However, I've had some, er, "fun" forays into the bowels of YUI trying to find out what's wrong, and that usually ends up showing me the problem is very simple.
[13:49] <deryck> yeah
[13:49] <rockstar> wallyworld_, do you know how to use the debugger?
[13:50] <deryck> yeah, I do step-wise debugging in firebug often.
[13:50] <wallyworld_> deryck: rockstar: clearly not :-)
[13:50] <rockstar> wallyworld_, through 'debugger;' it at the line where you want the breakpoint, and run the code.
[13:50] <deryck> wallyworld_: add a "debugger;" statement in any line and have fun :-)
[13:50]  * wallyworld_ will have to RTFM
[13:50] <rockstar> Firebug will take care of the rest.
[13:51] <rockstar> wallyworld_, I also prefer chrome's tools to Firebug now, as Firebug's XUL-land code often confuses Firefox greatly.
[13:51] <wallyworld_> if only i had figured that out 1 month ago :-)
[13:51] <rockstar> Like, refreshing while still in the breakpoint causes madness.
[13:51] <wallyworld_> rockstar: cool. i try it. actually i have found firefox 4 to be a huuuuge memory hog :-(
[13:52] <rockstar> wallyworld_, with or without firebug?
[13:52] <deryck> I'm slowly coming over the Chromium, too.  Now that I'm learning the UI differences better, and changing muscle memory.
[13:52] <wallyworld_> rockstar: without. but of course its always just an F12 away
[13:53] <wallyworld_> so it must have stuff loaded all the time etc
[13:53] <wgrant> jam: Landed, thanks.
[13:54] <wallyworld_> deryck: yeah, muscle memory. that's why i can't use another ide besides PyCharm. too much time with Intellij for Java
[13:54] <deryck> heh, understood
[13:56] <wgrant> jam: I'm off to bed now.
[13:56] <wgrant> jam: Hopefully nothing will break!
[13:56] <wallyworld_> leonardr: thanks for fixing branch. talk again in 7 hours :-)
[13:56] <leonardr> k
[13:56] <jam> wgrant: sleep well
[13:57]  * wallyworld_ off to bed too but not same bed as wgrant
[13:57] <rockstar> wallyworld_, indeed it does.  That's a big reason I switched to Chrome for development.
[13:57] <wallyworld_> rockstar: i like chrome but last time i looked their adblocking sucked due to lack of content filtering api
[13:58] <wgrant> wallyworld_: Ad blocking is much better now
[13:58] <wgrant> It used to really suck, though, yes.
[13:58] <rockstar> I just wish they'd block popunders.
[13:58]  * wallyworld_ really going away now :-)
[14:13]  * jcsackett holds breath to see if irc client has stopped misbehaving
[14:14]  * jcsackett exhales, slowly
[14:19] <leonardr> adeuring: https://code.launchpad.net/~leonardr/launchpad/520412-from-thekorn/+merge/54868
[14:26] <adeuring> leonardr: I'll look
[14:34] <deryck> adeuring, abentley, and henninge -- I forgot... we're all on DST next week, right?  Which should put standup back at 1300 UTC?
[14:35] <adeuring> deryck: yes
[14:35] <abentley> deryck: I believe so, and yes.
[14:40] <jam> adeuring: any chance you could look at the follow up patch: https://code.launchpad.net/~jameinel/launchpad/loggerhead-test-suite-742446/+merge/54870
[14:40] <adeuring> jam; sure
[14:41] <adeuring> leonardr: r=me
[14:44] <henninge> deryck: since it won't change the time for us here, I am all for it.
[14:45] <deryck> ok, cool.
[14:54] <rvba> sinzui: Hi ... if you have a few minutes, I'd be happy to have your opinion on the UI side of a branch I'm working on right now.
[14:55] <sinzui> rvba: I can talk in a few minutes
[14:55] <rvba> sinzui: https://pastebin.canonical.com/45240/
[14:55] <jml> deryck: how's now?
[14:55] <rvba> sinzui: I'd be happy to talk about it yes ... just ping me when you're ready
[14:55] <deryck> jml: now's good.  mumble it?
[14:55] <jml> deryck: yep
[14:56] <danilos> deryck, s/chromium inspector/webkit inspector/ (it works in epiphany as well)
[14:56] <deryck> jml: drag me where you like
[14:56] <danilos> deryck, btw, cool tip, I was setting a breakpoint from the inspector directly :)
[14:56] <deryck> danilos: heh, ok :-)
[14:57] <jml> deryck: http://paste.ubuntu.com/585427/
[15:01] <deryck> jml: https://translations.qastaging.launchpad.net/ubuntu/natty/+source/gnuhello
[15:03] <deryck> jml: https://translations.qastaging.launchpad.net/ubuntu/natty/+source/gnuhello/+sharing-details
[15:04] <LPCIBot> Project windmill build #104: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/104/
[15:05] <adeuring> jam: r=me
[15:06] <jam> adeuring: can you 'ec2land' it for me?
[15:06] <adeuring> jam: sure
[15:06] <jam> thanks
[15:27] <sinzui> rvba: why does 2_details.png show the expander arrow, but the computes replaces it with a cog? Cannot I not expand the entry anymore?
[15:28] <rvba> sinzui: the greyed arrow cannot actually be expanded ...
[15:29] <sinzui> Why are we telling users It can be expanded?
[15:29] <sinzui> Is that arrow being used as a bullet?
[15:29] <rvba> yes
[15:29] <sinzui> easy fix
[15:29] <rvba> indeed
[15:30] <sinzui> Should we have a grey cog instead?
[15:30] <rvba> it acts as a placeholder so that when it's replaced by real status icon (processing/failed) the text does not jump
[15:30] <sinzui> good
[15:32] <rvba> if there is a grey cog, it would be very nice ... I've reused existing icons
[15:32] <sinzui> I think a cog with a questionmark emblem might convey we do not know the status yet
[15:32] <rvba> yes
[15:33] <rvba> what's the process for creating new icons?
[15:33] <jml> hah
[15:33] <jml> rvba: ask huwshimi
[15:34] <rvba> jml: ok
[15:34] <sinzui> I have not noticed the cog before. The page title says source package, I think the data is actually a source package release. I do not want to confuse the users about out precise use of terms, BUT I think expect an icon that implies source package. cogs are used for binaries.
[15:35] <rvba> yes, the data is source packages
[15:35] <rvba> (even if there is a remaining 'binary' somewhere)
[15:36] <rvba> the icons would be for packages diff more than source packages
[15:36] <sinzui> rvba: I think the interaction is very good. I think we need to note we want the icon developed for the interaction before the final release
[15:36] <rvba> it's the diff that can be a) not there / b) pending / c) failed
[15:37] <cjwatson> wgrant: apparently the buildbots run hardy-cat, so I'll need to backport this all the way back to hardy
[15:37] <sinzui> rvba: understood. You might want to report a bug to record the requirements for the icons. You can then focus on functional side of your branch
[15:38] <rvba> sinzui: ok
[15:38] <rvba> jml: should I report a bug about the missing icons and assign that to huwshimi?
[15:38] <cjwatson> wgrant: sorry, just the staging buildbot
[15:38] <jml> rvba: sounds good.
[15:38] <cjwatson> wgrant: I'm having a hard time seeing how 3.0 format support works in that case, though ...
[15:39] <rvba> great
[15:39] <cjwatson> wgrant: wouldn't current LP tests fail without 3.0 support in dpkg?
[15:39] <rvba> sinzui: ok, thanks for your time.
[15:49] <sinzui> bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/person-merge-job-2/+merge/54873 today?
[15:50] <bac> sinzui: yes
[15:50] <cjwatson> wgrant: never mind; as far as I can tell, if the staging buildbot is running hardy (and doesn't have a lucid chroot or whatever), then AFAICT it can't be testing LP
[15:52] <sinzui> jcsackett: do you have a few minutes to mumble? We can pretend it is our daily talk
[15:53] <jcsackett> sinzui: sure, one second.
[15:54] <jcsackett> sinzui: i'm on mumble.
[15:57] <bac> sinzui: i made a super-trimmed down test to demonstrate the problem i'm having. it can be run, and fails, in trunk.  would you have a look and see if you spot anything obviously wrong when you have time?  http://pastebin.ubuntu.com/585455/
[15:57] <sinzui> bac: OTP, will look in a few minutes
[16:11] <cjwatson> leonardr: hmm, can I suggest that maybe https://help.launchpad.net/API/Examples shouldn't recommend connecting to edge? :-)
[16:12] <leonardr> cjwatson: yeah, i'll change it
[16:14] <cjwatson> thanks
[16:22] <bac> hi sinzui, your code says membership in a merged team is not transferable.  really?
[16:24] <danilos> jml, hi, did you by any chance change the summary of https://bugs.launchpad.net/bugs/742490 and then change it back? (because if you did, we've got a bug; if you didn't, I am just having trouble reading the differences in the email :)
[16:24] <_mup_> Bug #742490: HTML is constructed using string concatenation in the structural subscription JS. <story-better-bug-notification> <Launchpad itself:New for yellow> < https://launchpad.net/bugs/742490 >
[16:24] <jml> danilos: no, just a spelling correction
[16:24] <jml> concatination => concatenation
[16:24] <danilos> jml, ah, right, concatInation
[16:25] <danilos> jml, it was hard to spot, and I was worried our "do not email about reverted changes" didn't catch it
[16:25] <jml> understandable.
[16:25] <danilos> jml, sorry for interruption, cheers :)
[16:27] <allenap> adeuring, bac: Do you guys fancy any branches to review? :) I have a small one, a medium one, and a large one to choose from.
[16:27] <bac> allenap: i'll be happy to look at them after my lunch
[16:28] <adeuring> allenap: I'll start with the small one :)
[16:28] <allenap> bac: Thank you. I hope you have a delicious lunch that leaves you in an pleasantly accommodating mood :)
[16:29] <allenap> adeuring: Cheers! https://code.launchpad.net/~allenap/launchpad/dd-initseries-bug-727105-feature-flag/+merge/54884
[16:29] <bac> me too
[16:30] <sinzui> hi bac
[16:30] <bac> hi
[16:30] <sinzui> do you want to mumble?
[16:30] <bac> sinzui: ok
[16:34] <sinzui> bac: http://pastebin.ubuntu.com/585467/
[16:35] <adeuring> allenap: there is a merge conflict
[16:38] <cjwatson> wgrant: germanium, cesium, and the buildbots other than staging should all have the new dpkg now, according to lamont
[16:39] <allenap> adeuring: Gah! I'll fix it now.
[16:40] <adeuring> allenap: thanks.
[16:44] <allenap> adeuring: I think it's confused. The correct diff - http://paste.ubuntu.com/585475/ - is actually shorter, and has no conflicts. Mmm :-/
[16:45] <adeuring> allenap: ok, thanks. allenap: r=me.  just one suggestion: I don't like generic names like is_featrue_enabled very much, What about is_derived_series_feature_enabled?
[16:45] <allenap> adeuring: Okay, makes sense. Thank you :)
[16:45] <adeuring> cheers
[16:47] <adeuring> allenap: next mp? (the mid-size one, please. Since my EOD is relatively close, I'd like to pass the big  MP to bac)
[16:47] <allenap> adeuring: https://code.launchpad.net/~allenap/launchpad/dd-initseries-bug-727105-copy-options/+merge/54667 though I'll check the diff on that one now.
[16:49] <bac> bac: +1 adeuring
[16:49]  * bac -> lunch
[17:01] <allenap> adeuring: It seems to be sane.
[17:01] <adeuring> allenap: right
[17:04] <jcsackett> leonardr: sorry to bug you about this on your last day, but is there a way to mark a field readonly on the api that's not read only otherwise?
[17:05] <leonardr> jcsackett: sure, pass readonly=True into export()
[17:09] <jcsackett> leonardr: someday i'm going to learn this all easier than i expect. :-)
[17:09] <leonardr> it's not _that_ tough
[17:10] <jcsackett> leonardr: indeed. i conflate webservice stuff with dealing with the wadl, i think. which as i recall was a major pain.
[17:10] <jcsackett> obviously such conflation is silly.
[17:10] <leonardr> jcsackett, can you elaborate on the pain?
[17:11] <jcsackett> leonardr: remember the issues you, sinzui, and to some extent i had when you were modifying it?
[17:11] <jcsackett> really, i mean that was xsl issues. not wadl per se.
[17:11] <jcsackett> but it set the tone in my head. :-P
[17:11] <leonardr> oh, xsl is the problem there :)
[17:12]  * jcsackett nods.
[17:12] <jcsackett> xsl is always a problem. :-)
[17:16] <jkakar> leonardr: Just noticed "last day" above.  I hope you have fun wherever you end up. :)
[17:18] <leonardr> jkakar: thank you!
[17:34] <adeuring> allenap: r=me
[17:37] <allenap> adeuring: Thanks!
[17:48] <bac> sinzui: i've tested and create_view is setting the BugsLayer properly based on rootsite
[18:06] <sinzui> bac: okay. I am starting my adventures with distros, adaption, and menus
[18:07] <bac> cool, sinzui
[18:40] <sinzui> bac: I see that the menu cannot get the facet, so cannot actually select a menu. We expect  bugs as was set by the rootsite.. facet should be layer, but Lp does not do this right. I think the setup is wrong. I see that path is missing, so I suspect we got another request object.
[18:41] <bac> sinzui: so i need to manually set facet?
[18:42] <bac> and path?
[18:43] <sinzui> That is not really possible, Menu gets it via adaption
[18:44] <sinzui> facet is moneypatched into the view by our ZCML hacks.
[18:48] <bac> sinzui: my battery is dying so i need to relocate.  i'll ping you in 15 minutes.
[18:48] <sinzui> okay
[19:04] <jml> g'night all. have a great weekend.
[19:18] <bac> sinzui: i am resettled and recharging
[19:20] <LPCIBot> Project db-devel build #491: FAILURE in 5 hr 20 min: https://lpci.wedontsleep.org/job/db-devel/491/
[19:22] <sinzui> c
[19:27] <lifeless> moin
[19:27] <lifeless> leonardr: hi
[19:27] <sinzui> bac: create_initialized_view uses getMultiAdapter directly. It bypasses the publisher. The publisher is what monkeypatches the facet into the view. So we will not have a facet...
[19:28] <bac> sinzui: ah.  boo.
[19:28] <sinzui> bac: we are working with an model object of course, but the failover method cannot get a facet...
[19:28] <lifeless> leonardr: I'm not sure what you're asking
[19:28] <lifeless> oh, I think I've figured it out
[19:29] <sinzui> bac: for expediency you might want to use test browser to for the test or...
[19:29] <leonardr> lifeless: you triaged the bug as critical because of a situation in which a 404 caused an oops
[19:29] <leonardr> i'm wondering if the situation i described falls into that category
[19:29] <lifeless> I think so, I just commented on the bug
[19:29] <sinzui> bac: we could finally fix the bug facet/layer bug. eg, Use the layer when we do not get a facet
[19:29] <lifeless> leonardr: the rules for 404 oopsing are:
[19:30] <lifeless>  - its a 404 (duh)
[19:30] <lifeless>  - and the referrer is a launchpad vhost or one of a select number of canonical/ubuntu sites
[19:30] <sinzui> bac: this is the hack I did to fix the test: http://pastebin.ubuntu.com/585562/
[19:31] <cody-somerville> hey. have you guys ever had any problems with chromium thinking lp is TSLv1 intolerant and falling back to SSLv3 or erroring out with non-descriptive SSL error?
[19:31] <sinzui> ^ the comment exposed in the diff mean we really wanted to use layer
[19:31] <lifeless> leonardr: I suspect you have oopses in /var/tmp/lperr/$day
[19:31] <bac> sinzui: but your hack won't work on other layers, right?
[19:31] <lifeless> cody-somerville: other than tls being a little bit broken ;)
[19:32] <lifeless> cody-somerville: anyhow, I saw someone mentioning a tls error with something yesterday in #is
[19:33] <sinzui> No, but I think in your case, the menu is not associated with a layer. I think the menu you are testing is on the default layer overview
[19:33] <sinzui> oh hell, I need to get children
[19:34] <lifeless> cody-somerville: see -ops right now in fact
[19:34] <sinzui> bac: I was going to walk through pdb next to see how to get the correct layer and map it to the selectedfacetname so that we have a final fix
[19:34] <bac> sinzui: the portlet i'm looking for only appears on the bugs page
[19:34] <bac> sinzui: ok, go get your kids
[20:43] <sinzui> bac: I do not think get_current_browser_request does the right thing in this kind of test. I am certain layer is set by create_initialized_view, but it do not set when we work with the menu. I think the menus are getting another request object
[20:43] <bac> ok
[20:44] <bac> sinzui: for now i think i'm going to take your advice and rewrite the test to use a browser
[20:45] <sinzui> I think will continue my distraction to learn what is wrong with some small hope that we will get one step closer to killing facet.
[20:47] <bac> great, sinzui
[21:02] <benji> see ya, leonardr
[21:03] <leonardr> bye, benji
[21:07] <leonardr> wallyworld_, i'm here sporadically, let me know when you're ready for standup
[21:15] <wallyworld_> leonardr: hi. i'm here now
[21:18] <leonardr> wallyworld_: ok, getting on mumble
[21:20] <leonardr> lp:~leonardr/launchpad/520412-from-thekorn
[21:21] <leonardr> wallyworld_: http://pastebin.ubuntu.com/585604/
[21:29] <leonardr> ok, i'm out of here. thanks, everybody. it's been great working with you
[21:46] <bac> sinzui: i have discovered a problem with my test construction
[21:46] <sinzui> current_request=True ?
[21:46] <bac> sinzui: simpler.  for rootsite='bugs' i was using '+index'.  that page renders as the main project page
[21:47] <bac> i should use '+bugs-index'
[21:48] <sinzui> bac: I discovered that the request we pass/make in create_view is not setup for the interaction be default. We need to set current_request=True to ensure the menu gets what is setup
[21:48] <sinzui> I am making a helper function that gets the facet name form the layer
[21:52] <bac> sinzui: i had variously tried setting current_request=True
[21:53] <bac> sinzui: i have to run but feel confident correcting my simple mistake will help greatly
[21:53] <sinzui> fab. I hope to have a spike to remove facets in a hour
[22:53] <wgrant> cjwatson: I'm confused. What staging buildbot?
[22:54] <wgrant> cjwatson: There are staging buildds, but no staging buildbot that i know of.
[23:09] <cjwatson> wgrant: lamont said the machine name was marambio
[23:09] <cjwatson> 16:00 <lamont> drwxr-xr-x 3 importd importd 20480 2011-03-25 00:01 staging-logs
[23:09] <cjwatson> 16:00 <lamont> OTOH, /srv/importd.staging.launchpad.net/staging/launchpad has nothing newer than 60 days ago
[23:09] <cjwatson> 16:00 <lamont> so the cronjobs are running, but no one is home
[23:09] <cjwatson> so I think it can reasonably safely be declared irrelevant for the moment anyway
[23:09] <cjwatson> whatever it is
[23:10] <wgrant> ... oh. That's a code importd. I guess they did run buildbot in like 2006, but I meant the lpbuildbot.canonical.com buildbots.
[23:33] <wgrant> cjwatson: I've sent your branch back to ec2.
[23:34] <cjwatson> ah, right.  thanks