[00:20] <lifeless> wallyworld: ok shoot
[00:20] <wallyworld> bang
[00:21] <wallyworld> you mean with the uzi?
[00:21] <lifeless> wgrant: we don't need it for natty
[00:21] <wallyworld> i love the uzi
[00:21] <lifeless> wgrant: vm's for the win
[00:21] <wallyworld> lifeless: you know that wide query taking a long time to run - the daily recipe builds one.....
[00:21] <lifeless> nope, remind me
[00:22]  * wallyworld looks up bug nr
[00:22] <wallyworld> bug 711072
[00:22] <_mup_> Bug #711072: RootObject:+daily-builds times out <timeout> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/711072 >
[00:23] <lifeless> ok
[00:23] <lifeless> how can I help
[00:23] <wallyworld> tables like person, sourcepackagename, archive are only in the query to get data to display
[00:24] <wallyworld> so they could be removed to reduce the nr of joins, and subsequent queries done to look up that data
[00:24] <lifeless> wallyworld: btw has your parameter filling thing had the test failure figured out and landed ?
[00:24] <lifeless> wallyworld: yes, changing from wide to serial is likely to help
[00:25] <wallyworld> not yet. i updated from trunk and can now reproduce locally but it's on the back burner till after rollout. bad rev rolled back
[00:25] <lifeless> kk
[00:25] <wallyworld> but values from those tables are used in thr oder by
[00:25] <lifeless> matsubara has improved lp-oops to group with inferred parameter types
[00:25] <wallyworld> cool.
[00:26] <wallyworld> so if i remove those tables from the query, i will have to load all the values and do an in memory sort
[00:26] <lifeless> wallyworld: huh, no
[00:26] <wallyworld> unless there's another way that storm can help that i don't know about
[00:26] <lifeless> DecoratedResultSet
[00:26] <lifeless> pre_iter_hook
[00:26] <lifeless> done
[00:27] <lifeless> I mean, you do need to load
[00:27] <lifeless> but sorting should always be db
[00:27] <wallyworld> ok. i'll have to look at that hook to see how it fits in
[00:27] <lifeless> otherwise slicing will fail
[00:28] <wallyworld> yeah, that was my problem
[00:28] <lifeless> look in lib/lp/blueprints/model/specification.py
[00:28] <lifeless> for pre_iter_hook
[00:28] <lifeless> this is one I prepared earlier.
[00:28] <wallyworld> excellent, a working example. thanks
[00:28] <lifeless> exact transform we're talking about
[00:28] <wallyworld> i knew that you would be able to help :-)
[00:28] <lifeless> actually, this is more complex
[00:29] <lifeless> but it shows pretty much all that you might want to do, and as I haven't seen the code you're looking at yet.
[00:29] <wallyworld> by "this" you mean the thing i am doing cf the example you gave?
[00:29] <lifeless> the specification hook is doing more than you ma yneed
[00:29] <wallyworld> ah ok
[00:29] <lifeless> its doing eager loading *and* object injection
[00:30] <wallyworld> a useful thing to bookmark for later for when needed
[00:30] <lifeless> so, looking at your query
[00:30] <wallyworld> thanks for the tip, i'll take a look and go from there
[00:30] <lifeless> why are you sorting on the things you're soring on
[00:31] <lifeless> also note the utterly utterly insane group by
[00:31] <lifeless> perhaps we should start with the use case ;)
[00:31] <wallyworld> the group by is needed because of the max()
[00:31] <wallyworld> the sort order was as per the requirements
[00:32] <lifeless> the max means you're bring back too many things
[00:32] <lifeless> which will make it slow
[00:32] <lifeless> (and thus, its slow)
[00:33] <wallyworld> there's several build records and we only want the latest one
[00:33] <lifeless> that sounds a bit delphic, sorry
[00:33] <lifeless> perhaps voice would help; I dunno.
[00:33] <lifeless> the first thing I'd want to do is to grab a bit of paper and map it out
[00:34] <wallyworld> taking out archive, person,sourcepackagename will help the base query look more sane
[00:34] <wallyworld> thumper developed the initial query in straight sql - i adapted it to storm.
[00:35] <wallyworld> it produces the correct results. how about i make the changes we've just discussed and see where that takes us
[00:36] <lifeless> you can't take the things out that you need to sort on
[00:36] <wallyworld> yes, hence my original question :-)
[00:36] <lifeless> ok
[00:36] <lifeless> so, first thing is to ask if we need to sort on all those things
[00:37] <wallyworld> that's why my first thought was to load the result set and do an in memory sort
[00:37] <wallyworld> there's only around 300 records - not sure what that may grow to in the future
[00:38] <lifeless> 16K or more
[00:38] <lifeless> its still in beta.
[00:38] <wallyworld> hmmm. that's too many
[00:38] <wallyworld> so yes, will have to revisit the sort order question then
[00:38] <lifeless> you have 600 ms in late evaluation of Branch
[00:39] <lifeless> looking at https://lp-oops.canonical.com/oops.py/?oopsid=1858D164
[00:39] <lifeless> another 800ms in late evaluation of SourcePackageRecipeData
[00:39] <wallyworld> why doesn't that oops link work?
[00:40] <lifeless> apache-openid brekaage
[00:40] <lifeless> login
[00:40] <lifeless> click again
[00:41] <wallyworld> those late evaluation times can certainly be fixed, but the main query - the count and the select - do swamp the overall number though
[00:42] <lifeless> actually
[00:42] <lifeless> thats 2.3 seconds in late evaluation
[00:42] <lifeless> so the main query is more
[00:42] <lifeless> but not like 90%
[00:42] <lifeless> anyhow
[00:42] <lifeless> first step, define the definitive goals
[00:42] <wallyworld> sure. i guess i'm saying that fixing the late eval stuff is necessary but not sufficient
[00:43] <lifeless> ORDER BY SourcePackageName.name,
[00:43] <lifeless>          Person.name,
[00:43] <lifeless>          Archive.name LIMIT 76
[00:43] <lifeless> wallyworld: all its all necessary and nothing will be sufficient ;)
[00:44] <lifeless> so the source package name is the driving thing
[00:44] <lifeless> its used for pagination
[00:44] <wallyworld> i'd agree with that
[00:44] <lifeless> personally I think that paginated lists are suboptimal
[00:45] <lifeless> I'd rather we presented a query interface
[00:45] <wallyworld> +1
[00:45] <lifeless> and showed the 75 most recent builds the rest of the time
[00:45] <lifeless> or something like that
[00:45] <wallyworld> if we did do that, the count() query would be required
[00:45] <lifeless> well the count can be simplified
[00:45] <wallyworld> and we would shave 1/2 of the most significant execution time off
[00:46] <wallyworld> but that's not how the batch navigator works is it?
[00:46] <wallyworld> the bn simple does a count() on the underlying query
[00:46] <lifeless> its just select count(*) from sourcepackagerecipe where daily_build is true
[00:47] <lifeless> the batch navigator makes some simlifying assumptions
[00:47] <lifeless> we may need to pass in an object with a custom count
[00:47] <wallyworld> not really - we only want the latest, but anyway, unless there's a hook i don't know about, the bn uses the same underlying query to do the count
[00:47] <lifeless> spr is 1:M
[00:47] <lifeless> if you count 1, you don't need the max
[00:48] <wallyworld> let me talk to thumper so see if we can adjust the requirements for what is displayed
[00:48] <lifeless> wallyworld: yes, the bn will need to be given an adapted result set, not a real one.
[00:48] <thumper> hell no!
[00:48] <thumper> sorry what?
[00:49] <wallyworld> thumper: read the last 10000 lines ^^^^^^^^^^^^ :-)
[00:49] <thumper> wallyworld: no
[00:49] <wallyworld> thumper: wanna mumble, may be easier
[00:49] <lifeless> thumper: listing all the source package builds as a collection seems pointless
[00:49] <thumper> wallyworld: I'm in a cafe without headphones
[00:49] <lifeless> thumper: we're saying lets just give users the 75 most recently built daily ones + a search box.
[00:49] <thumper> lifeless: I'm not listing them as a collection
[00:49] <lifeless> thumper: what do you call 'https://code.launchpad.net/+daily-builds'
[00:49] <thumper> what are you talking about?
[00:50] <wallyworld> thumper: we're talking about the +daily-builds sql times
[00:50] <thumper> lifeless: that is really a requirement from the community guys
[00:50] <wallyworld> and the fact that the current sort oder requires a query with a number of joins to get the data to sort on
[00:50] <lifeless> thumper: how was it phrased though?
[00:50] <thumper> they wanted a listing of packages built with recipes
[00:50] <thumper> not search rubbish
[00:51] <lifeless> thumper: search is hardly rubbish; who asked for this, and what did they want to achieve?
[00:51] <wallyworld> but if we are prepared to relax the sort order we can small a smaller more efficient query
[00:51] <wallyworld> s/small/use
[00:51] <thumper> :)
[00:51] <lifeless> wallyworld: so we can make it better as is
[00:52] <lifeless> wallyworld: I'm separately saying that its not actually a brilliant UI as it stands.
[00:52] <thumper> wallyworld: the only sort order I care about is source package name
[00:52] <thumper> wallyworld: everything else is extra
[00:52] <wallyworld> thumper: ok. will do that first up
[00:52] <thumper> wallyworld: most of the results will return only one daily recipe for a source package
[00:52] <thumper> at least for now
[00:52] <lifeless> thumper: that presupposes having a collection though; so can we talk about that seriously?
[00:52] <thumper> there are a few packages where there are more than one
[00:52] <wallyworld> and get some numbers on the improvement
[00:53] <thumper> lifeless: I'd be terribly sad if you took the collection away
[00:53] <lifeless> thumper: why?
[00:53] <wallyworld> can i ask to have a query run on production?? to get some numbers?
[00:53] <lifeless> wallyworld: a losa
[00:53] <lifeless> wallyworld: or stub
[00:53] <wallyworld> sure. just wanted to see if it were a kasha thing to ask for
[00:53] <lifeless> wallyworld: the numbers haven't changed substantially though.
[00:53] <thumper> because I think it looks nice, and validates the work we are doing
[00:54] <wallyworld> lifeless: did you just try it?
[00:54] <lifeless> thumper: I don't think it validates it - uptake will validate it; as far as looking nice, it looks like something where its impossible to find what a user wants to find.
[00:54] <lifeless> thumper: I don't mean to be negative here.
[00:54] <wallyworld> i meant to see what benefit removing person and archive from the sort oder would do
[00:54] <lifeless> wallyworld: for that sort of thing, we use qastaging until we're fairly sure we've got the good stuff
[00:55] <wallyworld> but qastaging has a really old db  :-(
[00:55] <lifeless> wallyworld: if you have a canned query I can run on qastaging, that would be great.
[00:55] <lifeless> wallyworld: it doesn't matter for this; it has 270 recipes
[00:55] <wgrant> lifeless: PQM still executes baz? Seriously?
[00:55] <lifeless> wgrant: probes for it, backend lookup
[00:55] <lifeless> dunno if it has it there.
[00:56] <thumper> lifeless: it should be up to the stakeholders and the strategist, so check with jorge and jml
[00:56] <wallyworld> lifeless:  yes, but what about all the other data (eg in the archive table) that serves to make the query slow
[00:56] <wgrant> lifeless: It uses it to get config-manager.
[00:56] <thumper> lifeless: I see no reason to defend it to you
[00:56] <wgrant> lifeless: That seems to be what takes all the time. It already does a lightweight checkout.
[00:56] <lifeless> thumper: I was asking who was pushing for it to be /like this/ - I wasn't asking you to defend it; I don't know how we got here conversation wise.
[00:56] <lifeless> thumper: I'll be delighted to talk to jorge and jono
[00:57] <lifeless> wgrant: it doesn't spend 30 minutes talk to baz, I assure you
[00:57] <wgrant> lifeless: The logging is a bit crap, then :/
[00:57] <StevenK> No, it spends 30 minutes spinning
[00:58] <lifeless> wallyworld: so the point I was making was that a search interface generates a very specific lookup
[00:58] <thumper> lifeless: https://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds was the justification
[00:58] <wgrant> Feb 03 23:26:09 pqm [140001309406976] INFO: running: baz get /home/pqm/archives/rocketfuel/lp-production-configs/trunk/config-manager /srv/pqm.canonical.com/chroot/home/pqm/pqm-workdir/home/devel
[00:58] <lifeless> wallyworld: so the intermediary tables will be very small
[00:58] <wgrant> Then it disappears for 17 minutes.
[00:58] <wgrant> Every time.
[00:58] <lifeless> thats in bzr land at that point
[00:58] <lifeless> the bzr backend doesn't log such a message
[00:58] <lifeless> thumper: thanks
[00:59] <wgrant> Oh yay, another db-devel conflict.
[00:59] <thumper> lifeless: sorry for being touchy... lots of stuff going on
[00:59] <wallyworld> lifeless: sure
[00:59] <lifeless> thumper: so, looking at that; the goal is to avoid duplicate effort; making it real easy to find dailies of audacity (e.g. search / linking on the source package side) would seem best to me.
[00:59] <lifeless> thumper: no worries; it is friday after all.
[01:00] <thumper> lifeless: perhaps a tag cloud for package names would be better?
[01:00] <thumper> given how much we love tag clouds :)
[01:00] <lifeless> so, I propose to mail jml and jorge, cc thumper and wallyworld and propose a different UI which can give us a much simpler problem to solve
[01:00] <thumper> although determining size / shade would be interesting
[01:00] <lifeless> thumper: thats a cool idea too
[01:00] <lifeless> thumper: search is the cheapest for us to do
[01:00] <lifeless> thumper: I don't know that its the best; tag clouds are pretty interesting too.
[01:01] <lifeless> thumper: I suspect we need discoverability as a primary mechanism though.
[01:02] <lifeless> thumper: is there anything I can help with ? [re lots of stuff going on]
[01:02] <thumper> not unless you want to read CVs and interview people
[01:02] <lifeless> am I allowed to shoot myself first ?
[01:03] <wallyworld> thumper: btw, the guy i mentioned wasn't interested
[01:03] <thumper> sure
[01:03] <StevenK> lifeless: Depends. Where?
[01:05] <lifeless> wallyworld: ok, so lets see what we can do
[01:06] <lifeless> wallyworld: first thing, we *don't* want to return all the previous builds in the intermediary tables
[01:06] <thumper> \0/
[01:06] <lifeless> wallyworld: but the thing before that
[01:06] <thumper> web-link branch of leonard's has landed in devel
[01:06] <lifeless> wallyworld: is to see what the current plan is
[01:06] <lifeless> wallyworld: do you have a query I can run
[01:06]  * wallyworld looks
[01:07] <wallyworld> lifeless: the current implementation uses this query - https://pastebin.canonical.com/42856/
[01:08] <wallyworld> lifeless: but i don't mind working through the issue if you have other stuff to do
[01:09] <lifeless> nothing I can't procrastinate over.
[01:11] <wallyworld> so i'll immediately get a win by removing the person and archive from the sort
[01:11] <lifeless> spm: could you please do an explain analyze on http://pastebin.com/nASE7Tq6 ?
[01:11] <lifeless> spm: on prod
[01:11] <lifeless> wallyworld: getting the explain should tell us a lot about what its doing
[01:12] <wallyworld> then we could get a rs with only the latest builds and use that to filter the main query - so a subselect instead of a big join, not sure how postgres performs for that
[01:12] <lifeless> wallyworld: it depends
[01:13] <wallyworld> jcsackett: ping
[01:13] <lifeless> if its uncorrelated and huge relative to final rows, poorly; if its correlated and about as selective as outer, poorly.
[01:13] <jcsackett> hello wallyworld.
[01:14] <wallyworld> jcsackett: hi. i just need a quick tick and flick on a mp to fix a small layout issue. can i reassign to you?
[01:14] <wallyworld> https://code.launchpad.net/~wallyworld/launchpad/recipe-related-branches-layout/+merge/48463
[01:14] <wallyworld> it's only like 2 lines of pt
[01:15]  * jcsackett realizes he's still listed as OCR.
[01:15] <wallyworld> sorry if you weren't
[01:15] <wgrant> jcsackett: You can't escape.
[01:15] <jcsackett> yeah, i can take a look at it, wallyworld; but you'll need to find someone to follow up, since my mentor is definitely not on shift.
[01:15] <wallyworld> ah ok
[01:16] <jcsackett> wallyworld, you want me to still take a look? i don't mind (need the reviews) but as i said, r=jcsackett isn't enough to land something. :-)
[01:16] <wallyworld> jcsackett: no, it's cool. thanks
[01:16] <jcsackett> wallyworld: dig. sorry for the confusion. i need to be better about removing myself from OCR. :-P
[01:17] <wallyworld> jcsackett: no problem :-)
[01:17] <wgrant> StevenK: Do you have any suggestions for getting a newer archive to gina on mawson?
[01:17] <wallyworld> lifeless: while waiting for that explain, can you quickly approve this 2 line pt change?
[01:18] <wallyworld> https://code.launchpad.net/~wallyworld/launchpad/recipe-related-branches-layout/+merge/48463
[01:18] <spm> wallyworld: lifeless: https://pastebin.canonical.com/42858/
[01:19] <wallyworld> spm: thanks
[01:20] <lifeless> wallyworld: sadly I don't know the css classes we use well enough to say if thats sane or not
[01:20] <lifeless> I seem to recall a lot of discussion about tables vs nontables in this
[01:20] <LPCIBot> Project devel build (416): STILL FAILING in 6 hr 17 min: https://hudson.wedontsleep.org/job/devel/416/
[01:20] <LPCIBot> * Launchpad Patch Queue Manager: [no-qa] [r=allenap][ui=none][bug=707103] Clean-up of lint after
[01:20] <LPCIBot> bugs-with-blueprints-bug-707103.
[01:20] <LPCIBot> * Launchpad Patch Queue Manager: [bug=75976] [r=abentley][ui=none] When someone asks to merge two
[01:20] <LPCIBot> accounts, Launchpad sends an email to the primary account asking for
[01:20] <LPCIBot> confirmation. That email was hard to understand and badly
[01:20] <LPCIBot> written. This branch rewrites that email's text and introduces
[01:20] <LPCIBot> a test that the email is sent with the correct text.
[01:20] <LPCIBot> * Launchpad Patch Queue Manager: [r=mthaddon, stub][bug=712282,
[01:20] <LPCIBot> 712285][no-qa] Improve nightly.sh transparency,
[01:20] <LPCIBot> and remove update-pkgcache.py from it.
[01:20] <lifeless> wallyworld: clearly its trivial textually.
[01:21] <wallyworld> lifeless: the css - should have been there from the start - cut'n.paste error. the other collapsible field sets use it
[01:22] <lifeless> wallyworld: want to mumble on the explain
[01:22] <wallyworld> lifeless: ok
[01:22] <lifeless> well, try mumbling, it may still be epic fail fo rme
[01:22] <wallyworld> or skype
[01:23] <lifeless> I can hear you
[01:53] <lifeless> spm: please analyse this on prod - http://pastebin.com/3ZA20XvA
[01:53] <lifeless> sadly staging/qastaging are not fresh enough
[01:55] <spm> lifeless: https://pastebin.canonical.com/42859/
[01:55] <lifeless> thanks!
[01:55] <lifeless> there will be more
[01:57] <lifeless> wallyworld: http://www.postgresql.org/docs/8.4/static/tutorial-window.html
[01:58] <lifeless> rank() OVER (PARTITION BY BuildFarmJob.date_finished DESC) FROM
[02:12] <jtv> StevenK: pong
[02:17] <lifeless> wgrant: ping
[02:17] <wgrant> lifeless: Hi.
[02:17] <lifeless> wgrant: hi
[02:17] <lifeless> you know wallyworld and I are looking at a slow query
[02:17] <lifeless> its filtering all binary package builds that are recipes
[02:17] <wgrant> The +daily-builds one?
[02:17] <lifeless> in state 1
[02:18] <lifeless> yeah
[02:18] <lifeless> we had an idea
[02:18] <lifeless> what if we narrow this to 'published'
[02:18] <lifeless> it might consider less data?
[02:18] <lifeless> we have binary package build and build farm job already in there
[02:19] <wgrant> So we're finding BPBs that are built from an SPR that has an SPR?
[02:19] <lifeless> have a look at one of the pastebins
[02:20] <lifeless> the goal is 'all source package recipes showing the date of the most recent successful binary build'
[02:21] <lifeless> one thing that isn't clear to me/us is whether fullybuilt in this case means 'the bzr-builder worked' or 'all binaries were build'
[02:22] <wgrant> It's the binary build status.
[02:22] <wgrant> Note that your last pastebin doesn't restrict to builds in the daily archive, so manual builds to other archives will show up.
[02:23] <lifeless> indeed
[02:23] <lifeless> what table was that on - BPB ?
[02:23] <wgrant> PackageBuild
[02:25]  * wgrant silences mirror-prober.sh.
[02:25] <wgrant> These noisy scripts irk me.
[02:26]  * spm gives wgrant 100 awesome points
[02:29] <lifeless> PackageBuild ON (PackageBuild.id = BinaryPackageBuild.package_build and PackageBuild.archive = SourcePackageRecipe.daily_build_archive)
[02:29] <wgrant> lifeless: I think so.
[02:29] <wgrant> I'm not sure which direction is clearer.
[02:30] <wgrant> Should we go from daily recipes to builds, or find builds that have daily recipes?
[02:31] <gary_poster> wallyworld, ping?
[02:31] <wallyworld> gary_poster: hey
[02:31] <gary_poster> hey
[02:31] <gary_poster> I really want ~gary/launchpad/bug548-db-2 to get on db-devel before we close pqm or mark things closed or so on.  Some tests failed, and in order to fix them, I had to make enough changes that they warrant their own separate review.  So...
[02:31] <gary_poster> I'm wondering how to get that to happen/if I can get that to happen
[02:32] <gary_poster> in order for that to work, I'll need a review, and I'll need to land
[02:32] <gary_poster> with tests passing..
[02:32] <wallyworld> gary_poster: just give me a sec : otp
[02:32] <gary_poster> oh, sure
[02:33] <lifeless> whats the mp url ?
[02:33] <wallyworld> gary_poster: well i am talking to lifeless atm :-)
[02:33] <wallyworld> he may want to help
[02:33] <gary_poster> thank you both, getting the mp up now
[02:34] <wallyworld> gary_poster: there's still 9 hours or so before we close :-)
[02:34] <wallyworld> plenty of time!
[02:34] <gary_poster> :-) yes, but I wanted to stop working hours ago :-)
[02:34] <wallyworld> yeah. understood :-)
[02:35] <wallyworld> gary_poster: so i can land it for you once it passed review
[02:35] <gary_poster> thank you!
[02:35] <wallyworld> gary_poster: what about qa? is it clear how to do that?
[02:35] <gary_poster> it is no-qa
[02:35] <wallyworld> even better!
[02:35] <gary_poster> :-)
[02:36] <wallyworld> gary_poster: so i think your work here is done :-)
[02:36] <wallyworld> assuming it passes review :-)
[02:36] <lifeless> gary_poster: whats the mp url ?
[02:36] <gary_poster> lol, thank you.  Well, I need to get the MP done
[02:38] <gary_poster> lifeless: https://code.launchpad.net/~gary/launchpad/bug548-db-2-tests/+merge/48570 but diff is still coming
[02:39] <gary_poster> the mp message is, uh, one of my more hurried :-P
[02:39] <gary_poster> and it shows :-)
[02:40] <gary_poster> ok diff has emerged lifeless
[02:40] <gary_poster> uh?
[02:40] <gary_poster> I did not touch the lib/canonical/widgets thing :-/
[02:42] <wgrant> gary_poster: You're getting a conflict there when merging locally?
[02:42] <wgrant> If so, ignore.
[02:42] <wgrant> Delete the widgets.moved directory.
[02:42] <gary_poster> wgrant, it is something in the MP-generated diff
[02:43] <gary_poster> not in my local diff
[02:43] <wgrant> OK, that's not normal.
[02:43] <gary_poster> I'm trying a local merge of my branch into a up-to-date-db-devel...
[02:45] <gary_poster> wgrant, conflict on my db-devel pull.  I assume this was correct?
[02:45] <gary_poster> rm -rf lib/canonical/widgets.moved
[02:45] <gary_poster> bzr resolved lib/canonical/widgets.moved lib/canonical/widgets lib/canonical/widgets.moved/tests
[02:45] <wgrant> gary_poster: Yes, that's right.
[02:45] <gary_poster> cool
[02:46] <wgrant> I just merged that branch into db-devel.
[02:46] <gary_poster> cool, thanks
[02:46] <wgrant> lib/canonical/widgets is still there...
[02:46] <wgrant> So the LP diff is odd.
[02:46] <wgrant> I resolved that conflict last night.
[02:47] <gary_poster> My branch merges cleanly into db-devel touching only the files I expect, so it looks like it is a diff-generation odity in the MP
[02:47] <lifeless> launchpad_qastaging=> select count(*) from sourcepackagerecipe where build_daily
[02:47] <gary_poster> oddity
[02:47] <lifeless> ;
[02:47] <lifeless> Time: 1.512 ms
[02:50] <gary_poster> lifeless, I never asked explicitly--are you reviewing the branch or should I ask around?
[02:51] <gary_poster> be thar a reviewer in these here parrts?
[02:52] <gary_poster> wallyworld: are you a reviewer, by chance?
[02:52] <lifeless> I will, one sec
[02:52] <gary_poster> oh thanks
[02:53] <wallyworld> gary_poster: no. not yet. soon hopefully
[02:53] <gary_poster> :-) cool
[02:55] <lifeless> gary_poster: hi
[02:55] <gary_poster> hey
[02:55] <lifeless> isn't with logged_in_user() sufficient ?
[02:56] <lifeless> sorry
[02:56] <lifeless> person_loggefd_in
[02:56] <lifeless> *bah* person_logged_in
[02:56] <gary_poster> this is about the dbuser, not the application user, so I don't think so.  Do I misremember my helpers?  looking for it
[02:56] <lifeless> ah right
[02:56] <lifeless> layers ;)
[02:56] <gary_poster> right :-)
[02:57] <gary_poster> and db, rather than application
[02:57] <lifeless> so
[02:57] <lifeless> a few thoughts
[02:57] <lifeless> I'll sketch here
[02:57] <lifeless> the restore_name seems a bit unrelated
[02:57] <gary_poster> to...?
[02:57] <lifeless> the problem you're solving
[02:58] <gary_poster> in the sense that we should always look at _dbuser?
[02:58] <lifeless> run-some-code-as-a-user
[02:58] <lifeless> right
[02:58] <gary_poster> completely agree
[02:58] <lifeless> I'm saying having it do a push/pop and if someone wants to change after that, they can do that separately - would make this code leaner
[02:59] <gary_poster> (it was probably some kind of misthought subliminal reaction to disliking the fact that I was looking at an underpants attribute.)  Yeah push/pop was my only intent really
[02:59] <lifeless> given the lack of tests for the helper, my inclination is to suggest making it as lean as possible
[03:00] <lifeless> I like the helper.
[03:00] <lifeless> I'm curious why your tests failed
[03:00] <gary_poster> a few existing tests failed that were creating things without a dbuser that actually had privileges to do so
[03:01] <lifeless> is it that LaunchpadZopelessLayer runs as an unusual user?
[03:01] <gary_poster> by adding an additional obeject that we were creating
[03:01] <lifeless> gary_poster: so, you're creating a PersonSetting whenever a Person is created?
[03:01] <lifeless> gary_poster: rather than lazy-creating?
[03:02] <gary_poster> unusual user: yeah, it is usually run as the user that a given script needs
[03:02] <gary_poster> which is often not pwerful enough to create stuff
[03:02] <gary_poster> if you tickle the database enough then things will flush
[03:02] <gary_poster> so essentially my change exposed (some) problems that were already existing
[03:03] <gary_poster> (I think there are a lot more like these that have not yet been triggered)
[03:04] <gary_poster> not lazy-creating: yes, I dislike write on read, and didn't want the complexity of look-for-the-underlying-object-and-if-it-is-not-there-look-for-the-interfaces-default.
[03:04] <gary_poster> (that is, write-on-write is ok, but I thought simplicity had a virtue)
[03:05] <lifeless> gary_poster: I dislike write-on-read too; That implies creating a million rows when the db deploy happens though
[03:05] <lifeless> anyhow
[03:05] <lifeless> approved
[03:05] <lifeless> I would like it if you could shrink the helper.
[03:05] <lifeless> more so if you add tests.
[03:05] <gary_poster> yes, I wondered about that but that was the design stub made, so I figured he had thought it through.
[03:06] <gary_poster> I shrunk the helper locally already, after discussion.  lemme run a smoketest...
[03:06] <lifeless> gary_poster: At a guess - I suspect he intended lazy create.
[03:06] <gary_poster> no, he made the trigger
[03:07] <lifeless> heh, ok.
[03:07] <lifeless> anyhoo, all sorted.
[03:09] <gary_poster> ok lifeless, thank you. yeah, the smoke test passed with http://pastebin.ubuntu.com/562319/ .  So, I'll push the non-test change to the helper now and ask Ian to land it, and then promise to make a branch with a test for it tomorrow.  Sound ok?
[03:11] <lifeless> grewat
[03:11] <lifeless> great
[03:11] <lifeless> the commit is a bit sad
[03:11] <lifeless> I wonder if rollback would be better, but thats a separate discussion
[03:13] <gary_poster> :-) I hear you
[03:13] <gary_poster> that's the pattern I saw throughout the tests for this thing
[03:13] <gary_poster> I dunno
[03:13] <gary_poster> I also am not entirely sure why it is a sqlbase commit
[03:13] <gary_poster> rather than a transaction.commit
[03:14] <gary_poster> but I was in a bit of "land the thing" and I felt this was at least an improvement over the status quo
[03:15] <lifeless> sure
[03:15] <gary_poster> wallyworld: ok, here's hoping the tests pass now. :-/
[03:15] <gary_poster> https://code.launchpad.net/~gary/launchpad/bug548-db-2-tests/+merge/48570
[03:15] <gary_poster> Let me do one last paranoid check...
[03:15] <wallyworld> gary_poster: so ready to ec2 land?
[03:19] <gary_poster> wallyworld: yes!  all previously failing tests , and all tests I touched, pass.  Let's give it a whirl.  Thank you so much!
[03:19] <wallyworld> gary_poster: my pleasure. pleased to help.
[03:19] <gary_poster> Thank you all.  Have a good day and ttyl
[03:20] <wgrant> Could someone review https://code.launchpad.net/~wgrant/launchpad/the-silence-of-the-probers/+merge/48571?
[03:23] <wallyworld> thumper: you free to talk about the form submit thing? or you have too much else happening?
[03:24] <thumper> wallyworld: I'm doing expenses, so I can talk to you now :)
[03:24] <wallyworld> :-D
[03:24] <wallyworld> mumble?
[03:34]  * wgrant cries.
[03:34] <thumper> wallyworld: https://code.qastaging.launchpad.net/~wikkid/+recipe/wikkid-daily
[03:35] <lifeless> wgrant: ?
[03:35] <wgrant> lifeless: Fourth stable->db-devel conflict in 24 hours.
[03:44] <thumper> :(
[03:51] <LPCIBot> Yippie, build fixed!
[03:51] <LPCIBot> Project db-devel build (340): FIXED in 5 hr 37 min: https://hudson.wedontsleep.org/job/db-devel/340/
[03:57] <wgrant> lifeless: Do you have a sec to review https://code.launchpad.net/~wgrant/launchpad/the-silence-of-the-probers/+merge/48571?
[04:08] <lifeless> wallyworld: want the review practice?
[04:09] <wallyworld> lifeless: for ^^^^ ?
[04:09] <lifeless> yes
[04:09] <wallyworld> ok
[04:09] <lifeless> man its fugly:)
[04:09] <wallyworld> about time i had a go at one :-)
[04:11] <lifeless>      498 / 7263  Archive:+index
[04:11] <lifeless>      245 /  374  BugTask:+index
[04:11] <lifeless>       91 /  182  Distribution:+bugs
[04:12] <lifeless> huwshimi: please triage when filing!
[04:14] <mwhudson> lifeless: is there/could there be a link to the triage guidelines in the +filebug page?
[04:14] <mwhudson> i guess it's only really intended for devs
[04:14] <huwshimi> lifeless: OK :)
[04:15] <huwshimi> lifeless: Self-triaging suggestions to change things just feels wrong though.
[04:15] <lifeless> huwshimi: you're a dev, you're able to assess importance.
[04:15] <lifeless> huwshimi: if you truely have no idea how relevant this is in the overall scheme of things, thats fine, but I've met very few engineers without such opinions ;)
[04:16] <huwshimi> lifeless: Yeah ok fair point
[04:25] <huwshimi> lifeless: I guess people will tell me if I'm doing it wrong anyway :)
[04:28] <lifeless> for sure
[04:44] <wgrant> wallyworld: Thanks.
[04:44] <wgrant> How are we looking for the release?
[04:45] <wallyworld> wgrant: np. well, i need to finish some qa (just waiting on a qastaging update). there's a mp from gary that fixes some failing tests that i am landing but it just barfed with some rrors :-(
[04:46] <wgrant> :(
[04:46] <wallyworld> many related to nascentupload stuff
[04:46] <wallyworld> i think that stuff was recently changed?
[04:46] <wgrant> What are the errors?
[04:47] <wgrant> Parts of it were refactored a week ago.
[04:47] <wallyworld> cause i had the same issue the other day - tests passed locally
[04:47] <wallyworld> this is a merge into db-devel
[04:48] <wallyworld> wgrant: https://pastebin.canonical.com/42864/
[04:48] <wallyworld> i've not looked at the detail yet, and there's more failing besides just the nascentupload ones
[04:49] <wgrant> Ah, that's interesting.
[04:49] <wgrant> I renamed that DB user yesterday.
[04:49] <wgrant> But it's probably unrelated.
[04:49] <wallyworld> sure? :-)
[04:50] <wgrant> Let's see.
[04:51] <wallyworld> wgrant: i think the purpose of the mp was to specify a db user to use for things to ensure the correct permissions were available and so have not get permission denied errors
[04:51] <wgrant> Yeah, security.cfg needs lots of fixes.
[04:51] <wgrant> This is going to be difficul;t.
[04:51] <wallyworld> and yet the failures had permission issues
[04:53] <wgrant> wallyworld: Anything that creates a Person needs INSERT on personsettings.
[04:53] <wgrant> Lots of things create Persons.
[04:53] <wgrant> But only the webapp has permission to do so.
[04:54] <wallyworld> wgrant: hmmm. the failures seem to be in different tests to what the mp changes
[04:54] <wgrant> wallyworld: Indeed, they will be in various scripts throughout the tree.
[04:55] <wgrant> And they should be fixed by adding permissions, not changing DB users.
[04:55] <wgrant> We could be bad and add personsettings to the 'write' group.
[04:55] <wgrant> That may fix everything.
[04:55] <lifeless> wgrant: why /should/ they be fixed like that?
[04:56] <wallyworld> lifeless: wgrant: i have to go and pick up the kid from school and buy him some cricket whites. be back soonish.
[04:56] <wallyworld> i'll catch up about this mp issue when i return
[04:56] <lifeless> wallyworld: they won't be white long
[04:56] <wgrant> lifeless: Because unless we are going for a single-user model, we have no choice.
[04:56] <wallyworld> not sure if it will make pqm cut off now :-(
[04:57] <wallyworld> hah
[04:57] <lifeless> I don't know why they don't call them cricket greens
[04:57] <wallyworld> :-)
[04:57] <lifeless> wgrant: that doesn't follow; perhaps you can expand your reasoning
[04:57] <wgrant> lifeless: We have special DB users like archiveuploader.
[04:57] <wgrant> They have permissions that other users do not.
[04:57] <lifeless> yes
[04:57] <wgrant> So some scripts must run as those special users.
[04:57] <lifeless> yes
[04:58] <wgrant> So those users need these new permissions.
[04:58] <lifeless> the create PersonSettings permission?
[04:58] <wgrant> That one.
[04:58] <lifeless> certainly things that can create Person need that.
[04:58] <wgrant> Right.
[04:58] <lifeless> but you were saying something rather broader than that.
[04:58] <lifeless> -or-
[04:58] <wgrant> I was saying that would be a quick fix.
[04:58] <lifeless> you were being unclear
[04:59] <wgrant> I thought the "We could be bad" was a big enough hint that the following suggestion was an awful, suboptimal, but effective fix.
[05:00] <lifeless> I thought it was a catholic bad
[05:00] <lifeless> you know, good
[05:02] <wgrant> So, my preferred fix is to grant SELECT, INSERT on PersonSettings to everywhere with INSERT on Person. Including, probably, write.
[05:02] <wgrant> And possibly review the test changes to work out if the DB users really needed to be changed.
[05:03] <lifeless> that sounds fine
[05:07] <wgrant> It looks like we want to revert the test changes. But I might keep those cool context managers :)
[05:07] <huwshimi> Can anyone explain what's going on with the "TREE" and "MERGE-SOURCE" stuff on the diff on this mp? https://code.launchpad.net/~huwshimi/launchpad/tag-label-687546/+merge/48577
[05:07] <wgrant> huwshimi: A conflict occurred during the merge.
[05:08] <huwshimi> wgrant: How do I resolve that?
[05:08] <StevenK> Merge from devel, edit the conflicting files to remove the conflicts, run bzr resolve, bzr ci and push
[05:13] <huwshimi> StevenK: How do I merge from devel? I've done it before, but the instructions got removed from the wiki :9
[05:13] <huwshimi> *:(
[05:13]  * huwshimi is still branching newbie
[05:14] <wgrant> huwshimi: In your branch, 'bzr merge ../devel'
[05:14] <wgrant> Assuming that you have the usual branch layout created by rocketfuel-setup.
[05:14] <huwshimi> wgrant: yeah, thanks
[05:15] <huwshimi> wgrant: I guess I need to update devel to the latest first though right?
[05:15] <wgrant> Right.
[05:15] <wgrant> cd into there, and 'bzr pull'
[05:15] <wgrant> Or probably bzr pull -d ../devel
[05:16] <StevenK> Or rocketfuel-get
[05:16] <wgrant> Or that.
[05:16] <wgrant> But that takes forever from .au.
[05:17] <StevenK> It's only a few minutes for me
[05:17] <wgrant> That is longer than it takes to do a non-parallel branch build.
[05:17] <wgrant> And that is already forever.
[05:18] <StevenK> Kids these days
[05:21] <lifeless> spm: hi
[05:21] <spm> hola
[05:25] <spm> lifeless: ?
[05:25] <lifeless> spm: I have two queries
[05:26] <lifeless> in http://pastebin.com/kwXPWJyT
[05:26] <lifeless> I'd like them both run, and explain analyzed, on prod please
[05:26] <spm> I'm shocked. only 2???? :-P
[05:26] <spm> np
[05:26] <lifeless> its 6:30
[05:26] <StevenK> lifeless: So effectively 4 queries?
[05:26]  * spm cheers StevenK on ;-)
[05:28]  * lifeless throws peanuts
[05:28] <spm> :-)
[05:28] <spm> lifeless: https://pastebin.canonical.com/42865/
[05:29] <lifeless> spm: did you run twice?
[05:29] <lifeless> spm: also I need the actual output of said queries
[05:30] <spm> I didn't run twice, but can; output coming.
[05:30] <lifeless> (I don't need the plan again)
[05:30] <lifeless> just run the queries a couple of times each
[05:30] <StevenK> And query count rises
[05:31] <huwshimi> ok that'll have to be fixed on Monday. Have a good weekend for all those who are about to begin them.
[05:32] <spm> night huwshimi
[05:32] <spm> lifeless: 1st is count 270
[05:32] <lifeless> spm: and how long did it take ?
[05:32] <lifeless> (\timing ftw)
[05:32] <spm> ~ 1.5 secs each
[05:32] <spm> will paste shortly
[05:32] <lifeless> kk
[05:33] <spm> lifeless: https://pastebin.canonical.com/42866/
[05:34] <lifeless> thanks
[05:37] <lifeless> spm: can you change the select count(*) in the first query to just select *
[05:38] <lifeless> spm: run it, and let me know how long
[05:38] <spm> ugh. yes. one sec.
[05:39] <spm> ew. I wish I hadn't done that to console. try #2.
[05:39] <StevenK> Haha
[05:40] <StevenK> lifeless: The mail I just sent to you makes me sad
[05:40] <lifeless> yes
[05:40] <lifeless> me too
[05:40] <lifeless> why is it like that though
[05:40] <lifeless> we should debug
[05:41] <StevenK> Querying Hudson over it's Python API is like pulling teeth
[05:41] <lifeless> how do you know
[05:41] <lifeless> have you pulled teeth ?
[05:41] <StevenK> No, but I've had a molar pulled
[05:42] <lifeless> stub: you might want to land bigjools debversion patch yourself given how close to pqm closure
[05:42] <lifeless> spm: I can prep the query for you if you like
[05:43] <wgrant> wallyworld: lp:~wgrant/launchpad/bug548-db-2-tests
[05:44] <spm> lifeless: https://devpad.canonical.com/~spm/lifeless.out
[05:44] <wgrant> wallyworld: I've run some previously failing tests, and they're OK. Running more now.
[05:44] <lifeless> spm: you missed the *time*
[05:44] <lifeless> spm: and I didn't care about the output :)
[05:45] <lifeless> spm: (sorry for the evident confusion)
[05:45] <spm> oh I see
[05:46] <spm> ~ 1.7 to 2.0 secs. call it 1.9.
[05:46] <lifeless> great
[05:48] <lifeless> wgrant: I'm starting to think that in the second half of this year we're going to have to do a schema refactoring to make soyuz - and things that have followed its lead - actually queryable
[05:49] <wgrant> lifeless: If you have some concrete suggestions I would be glad to hear them.
[05:49] <spm> drop database
[05:49] <lifeless> for starters, collapse the tables where we have 'A if B and B if A'
[05:50] <lifeless> unless you are never filtering on A or B, this sort of split destroys query performance
[05:50] <wgrant> eg?
[05:50] <lifeless> BPB-PB-BFJ
[05:50] <wgrant> That means denormalising everything.
[05:50] <lifeless> if we filtered on BPB rather than BFJ it would be different
[05:50] <lifeless> wgrant: I don't see that it does
[05:50] <lifeless> wgrant: it may mean modelling it differently
[05:50] <wgrant> lifeless: SPRBs? TTBJs?
[05:50] <lifeless> three tables
[05:51] <lifeless> BPB SPRB TTBJ
[05:51] <wgrant> Denormalised, forcing everyone to query against all three.
[05:51] <lifeless> not true
[05:51] <lifeless> some folk will have to query three
[05:51] <lifeless> *most* folk will query one.
[05:54] <wallyworld> wgrant: thanks, looking now
[05:55] <wgrant> lifeless: So, if we are going to move to a denormalised model we can. But that's a big policy change.
[05:55] <wgrant> And it is going to need to have good evidence behind it.
[05:55] <lifeless> wgrant: I haven't proposed denormalised so far.
[05:55] <lifeless> wgrant: as for policy; we have lots of denormalisation, there is no need for a policy change at all.
[05:56] <wgrant> You do not propose redundancy in data, but redundancy in schema.
[05:56] <wgrant> That is almost as bad.
[05:56] <lifeless> uhm
[05:56] <lifeless> not at all
[05:56] <lifeless> totally different
[05:56] <lifeless> *and*
[05:57] <lifeless> in the object model we can still map up to three objects if we want; or base classes.
[05:57] <lifeless> but sql /is not/ an object db, and its query performance /is not/ that of object traversal.
[05:57] <lifeless> approaching things from the wrong end here will give shocking results. (Which btw, we have).
[06:01] <wallyworld> wgrant: those changes look sensible to me. wonder why they were needed now? what's changed?
[06:02] <wgrant> wallyworld: Nothing changed. They've been needed since the new table was introduced.
[06:03] <wallyworld> lifeless: the changes to security.cfg and reverting use of the lp_dbuser cm pretty much make the original mp redundant
[06:03] <wallyworld> wgrant: ah ok. didn't realise it was a new table.
[06:04] <wallyworld> so it the tests need the permissions, how does it work in production ie for the app itself?
[06:04] <wgrant> wallyworld: I reverted the test DB changes, instead granting INSERT on personselection to every DB role that has INSERT on person, since Person.__init__ creates a PersonSelection.
[06:06] <wallyworld> wgrant: yeah i realise that :-) just wondering how this hasn't come up before now, unless the original branch which introduced the new table was very recent
[06:06] <wgrant> wallyworld: The original branch hasn't landed yet...
[06:06] <wgrant> This MP has a prereq.
[06:06] <wgrant> The prereq adds the table, and has not yet landed.
[06:07] <wgrant> That's why this is on db-devel.
[06:07] <wallyworld> ok. now it makes sense
[06:07] <wallyworld> although staging uses db-devel
[06:08] <wallyworld> wgrant: so you are going to put up a mp for your branch?
[06:11] <wgrant> wallyworld: I suppose so.
[06:11] <wgrant> Not sure it really needs one.
[06:11] <wgrant> But I might as well.
[06:11] <wallyworld> wgrant: i'm not sure what sop is in these cases?
[06:12] <wgrant> If it were my branch to start with, I'd just land it without rereview.
[06:13] <wallyworld> wgrant: me too, but in this case, not sure. maybe lifeless can look since he was the original reviewer?
[06:13] <lifeless> wgrant: you're fixing an unlanded mp right?
[06:13] <lifeless> wgrant: throw up a branch with the other one as a predicate
[06:13] <lifeless> I'll have a look in a minute, once I finish this mail.
[06:13] <wgrant> lifeless: Half way there.
[06:16] <wallyworld> wgrant: where do i look to estimate when a particular rev will deploy on qastaging, like you did yesterday
[06:17] <wgrant> wallyworld: Ha ha ha.
[06:17] <wgrant> wallyworld: You need to predict when buildbot will bless it.
[06:18] <wgrant> Once buildbot has blessed it, buildbot-poller will pull it into stable within 15 minutesish.
[06:18] <wallyworld> wgrant: it's green in bt now
[06:18] <wallyworld> /sbt/bb
[06:18] <wgrant> Unless there is a stable->db-devel merge stuck in PQM, in which case it won't pull anything more until that is processed.
[06:19] <wgrant> Once it's in stable, it should be on qastaging in about an hour.
[06:19] <wallyworld> wgrant: ok. bb finished it about maybe 30 minutes ago i think
[06:20] <wgrant> You can check /srv/lp-pqm-logs/pqm_logs/buildbot.log and /srv/launchpad.net-logs/qastaging/asuka/qastaging-update.log to get some progress info.
[06:20] <wallyworld> wgrant: ah. that's what i needed. thanks
[06:20] <wgrant> And you can rsync them manually if they are not syncing frequently enough.
[06:21] <wallyworld> wgrant: i can wait a little longer. once that rev lands in qas, i can qa it
[06:21] <wgrant> lifeless: MP and diff up.
[06:21] <wgrant> https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48579
[06:22] <wgrant> wallyworld: What about bug #670452?
[06:22] <_mup_> Bug #670452: Hard to find related branches when composing recipe <lp-code> <qa-needstesting> <recipe> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/670452 >
[06:22] <wallyworld> wgrant: that's then one i need this latest rev to finish qaing
[06:23] <wgrant> Ah.
[06:23] <wgrant> 12320 is a bit odd.
[06:23] <wallyworld> how so?
[06:23] <wgrant> It has [no-qa], and there are no linked bugs, but it lists two bugs and says it's missing QA tags.
[06:24] <lifeless> check the revisions
[06:24] <lifeless> jus ta thought
[06:24] <wgrant> I am looking.
[06:24] <wgrant> But codebrowse is being disagreeable.
[06:25] <StevenK> wgrant: More than usual?
[06:27] <wgrant> Ah, interesting.
[06:27] <wgrant> One bug is in the branch name.
[06:27] <wgrant> The other linked to the branch.
[06:27] <wgrant> But not in the commit message.
[06:27] <wgrant> I didn't think it looked beyond the commit message :/
[06:29] <wgrant> Ah, it does.
[06:29] <wgrant> It checks the branch nick, extracts bug numbers from that, and then looks up linked bugs on the LP branch with the same name.
[06:29] <wallyworld> wgrant: interesting that the rev is listed twice in the qa report?
[06:31] <wgrant> wallyworld: Because there are two bugs.
[06:31] <wallyworld> doh!
[06:32] <wallyworld> wgrant: but 12317 has 2 bugs too
[06:32] <wgrant> wallyworld: Ahh, I see what's happened.
[06:32] <wgrant> It saw the no-qa.
[06:33] <wgrant> So it tagged both bugs as qa-untestable.
[06:33] <wgrant> But then henninge untagged one of them.
[06:33]  * wgrant retags.
[06:33] <henninge> wgrant: no, why?
[06:33] <henninge> wgrant: it's not the fix for the bug
[06:33] <henninge> oh, hang
[06:33] <henninge> on
[06:34] <wgrant> henninge: It was in the branch name, so qa-tagger thinks it is.
[06:34] <spm> wgrant: did I ever tell you that asuka-wants-to-get-rocked is complete?
[06:34] <wgrant> It needs to retain the qa-untestable tag.
[06:34] <wgrant> Until we deploy r12320.
[06:34] <henninge> ah, ok
[06:34] <wgrant> spm: I think so.
[06:34] <spm> oh cool. just had a moment of doubt there.
[06:35]  * henninge did not know about the branch name
[06:35] <wgrant> henninge: Neither did I.
[06:38]  * wallyworld didn't either
[06:38] <lifeless> spm: you didn't, we knew, query fixed, landed earlier today
[06:38] <lifeless> might even be on qas now
[06:39] <spm> oh cool.
[06:39] <lifeless> wgrant: 477 lines (+127/-96) 5 files modified (has conflicts)
[06:39] <wgrant> lifeless: Huh?
[06:39] <wgrant> Grrr.
[06:40] <wgrant> It does not conflict locally. Perhaps the prereq is breaking things.
[06:41] <wgrant> The number of conflicts visible in that diff is between 0 and 0.
[06:41] <wgrant> Must be in the prereq. yay.
[06:41] <lifeless> heh
[06:42] <lifeless>  where did that copy archive query fix go
[06:43] <lifeless> I shot it at ec2
[06:43] <wgrant> No, that's not it either.
[06:43] <wgrant> Oh.
[06:43] <wgrant> I proposed into devel, not db-devel.
[06:43] <lifeless> ah
[06:43] <lifeless> 12323
[06:45] <wgrant> :( Deployment-Ready has filled up again
[06:46] <lifeless> ok, its on stable
[06:46] <lifeless> waiting for qas to update
[06:46] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48580
[06:46] <lifeless> mars: hi
[06:46] <wgrant> lifeless: The lib/canonical/widgets is a lie.
[06:46] <wgrant> But apart from that it looks OK.
[06:47] <wgrant> Actually, I think the whole thing is a lie.
[06:47] <lifeless> wow that widgets file sure gets around
[06:48] <lifeless> ok, so you've backed out all the stuff, because none of was actually broken.
[06:48] <wgrant> I didn't back it out far enough, though.
[06:48] <lifeless> even though we may have more person.insert than needed, we're not trying to fix that right now.
[06:49] <lifeless> what did you miss?
[06:50] <wgrant> Ah, no, I think it's OK.
[06:50] <wgrant> Just some confusion as to what was there before.
[06:50] <lifeless> doit
[06:51] <wgrant> Thanks.
[06:56] <wgrant> wallyworld, lifeless: Heading off to ec2.
[06:56] <wgrant> I'm out for most of the evening, but I'll check up on it when I return home.
[06:57] <wallyworld> wgrant: \o/ thanks!!!
[06:57] <lifeless> wgrant: ciao
[06:59] <wgrant> wallyworld: You need 12327, right?
[06:59] <poolie> hi all
[06:59] <wallyworld> wgrant: yeah. waiting, waiting
[06:59] <poolie> i hope the oauth change doesn't break anything
[06:59] <wallyworld> hi poolie
[06:59] <wgrant> wallyworld: That's about 5 hours away.
[06:59] <poolie> i guess we shall see
[06:59] <poolie> it would be a shame if there was some weird side effect
[06:59] <wallyworld> wgrant: WTF?
[06:59] <wgrant> wallyworld: The last successful buildbot run was 12324
[07:00] <wgrant> wallyworld: The one in progress is 12328
[07:00] <wgrant> I think tomorrow I will try to write a cron job to automatically report this stuff, because it is too spread out.
[07:01] <lifeless> poolie: oauth change?
[07:01] <wallyworld> wgrant: bollocks. it's cutting it real fine then for pqm closure
[07:01] <wgrant> wallyworld: Hm? It's already past PQM.
[07:01] <wgrant> And if it's broken, then you can r-c the fix yourself :P
[07:01] <wallyworld> wgrant: in case there's something else wrong :-)
[07:02] <wallyworld> true, but i don't want to do that :-)
[07:02] <poolie> lifeless, i deleted the second copy of oauth.py from the tree
[07:02] <lifeless> oh right
[07:02] <lifeless> poolie: did you land via ec2 land?
[07:02] <poolie> there's not much specific benefit, so it would be a shame if there's accidental breakage
[07:02] <poolie> i ran it here
[07:03] <lifeless> the full suite?
[07:03] <poolie> it failed due to something else in the tree being broken
[07:03] <poolie> but with exclusions it passed
[07:03] <wallyworld> poolie: we know where you live if something happens :-)
[07:03] <poolie> i'd be more concerned there's something about deployment that causes it to not find the right external oauth
[07:03] <poolie> but, we shall see
[07:03] <poolie> it was still waiting for hudson
[07:03] <wgrant> poolie: It'll be fine if it works on ec2.
[07:04] <lifeless> deployment matches test environment quite closely
[07:04] <wgrant> Except for sourcecode.
[07:04] <wgrant> But this isn't sourcecode.
[07:04] <wgrant> I know it's OK egg-wise, because that's what makes it take so. damn. log.
[07:04] <poolie> this is making it depend on sourcecode for something where it previously did not
[07:04] <wgrant> +n
[07:04] <wgrant> poolie: This is an egg, not sourcecode.
[07:04] <poolie> ok
[07:34] <LPCIBot> Project devel build (417): STILL FAILING in 6 hr 13 min: https://hudson.wedontsleep.org/job/devel/417/
[07:34] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][bug=316694] Add a web_link property to the JSON
[07:34] <LPCIBot> representation of all web service entries that correspond to
[07:34] <LPCIBot> some page on the Launchpad website.
[07:34] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=709717] Remove an unnecessary join to
[07:34] <LPCIBot> sourcepackagerelease when counting packages that are being
[07:34] <LPCIBot> built/waiting to be built in ArchiveView.num_pkgs_building
[07:34] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=705342] Fail nonvirtual builders in the ABORTED
[07:34] <LPCIBot> state rather than cleaning them,
[07:34] <LPCIBot> since we can't guarantee that there's no active build.
[07:34] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=705652] Log warnings in the remove_translations script if
[07:34] <LPCIBot> current translations are removed. Removed the theoretically
[07:34] <LPCIBot> impossible case of finding a diverged translation being current
[07:34] <LPCIBot> in upstream which is linked to a POTemplate having a diverged
[07:34] <LPCIBot> translation being current in Ubuntu.
[07:34] <LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][ui=none][no-qa] Provide translation sharing information.
[09:08] <mrevell> Hey up 'padders
[09:11] <jtv> hi mrevell!
[09:13] <bigjools> helleau
[09:16] <jtv> hi bigjools
[09:16] <jtv> Which reminds me of coffee
[09:16] <jtv> brainzzz
[09:19] <bigjools> yay PG vuln
[09:23] <jtv> integer overflow—a type of vuln I suspect we haven't even begun to make a dent in, as an engineering discipline.
[09:23] <jtv> Well okay, in this case, buffer overflow from large integers I suspect
[09:23] <bigjools> interesting
[09:24] <jtv> hi al-maisan!
[09:24] <al-maisan> hello jtv, how are things?
[09:25] <jtv> al-maisan: they are bloody cold, thank you. ☺  You?
[09:25] <al-maisan> jtv: ha-ha .. you must be in good, old Europe then :)
[09:26] <al-maisan> jtv: doing well, thanks, the weather in Zürich is "mild" in comparison with the previous days
[09:27] <jtv> So… ice but no penguins?
[09:36] <Ursinha> morning
[09:47] <jtv> Hi Ursinha!
[09:52] <al-maisan> jtv: penguins .. in the zoo maybe ;)
[09:52] <jtv> allenap: http://pqxx.org/development/libpqxx/wiki/AllSoftwareIsBroken
[09:52] <allenap> jtv: Cheers :)
[09:53] <lifeless> jtv: typo
[09:53] <lifeless> 'that what' should be 'than what'
[09:53] <jtv> allenap: still needs work, and Maris had some useful feedback on it.  If you have any ideas (maybe I should open a discussion page) I can forward them.
[09:53] <jtv> thanks lifeless!  Will fix right away.
[09:53] <Ursinha> hi jtv :)
[09:54] <lifeless> jtv: actually, I think I misparsed.
[09:54] <lifeless> jtv: either way :)
[09:55] <jtv> lifeless: did you misread the "That was"?
[09:55] <lifeless> I think so
[09:55] <jtv> OK, then it stays unchanged.
[09:57] <lifeless> mars: hi
[09:58] <lifeless> actually
[09:58] <lifeless> gnight
[10:00] <bigjools> jtv: remind me where your MF branch is and I'll re-test
[10:02] <jtv> bigjools: I thought my MF branch was already on dogfood.  But it's also at lp:~jtv/launchpad/bug-181368-parallelize
[10:02] <jtv> Why do I have so much trouble spelling that word lately?
[10:03] <bigjools> jtv: for some reason DF has a diff in test_ftparchive.py but not in the publisher code
[10:03] <jtv> ough
[10:03] <bigjools> "pilfering_puppy" ....?!
[10:03] <jtv> Yes, doesn't that make sense?
[10:04] <jtv> I think it's a wonderful release name.
[10:04]  * bigjools wonders what Q will be
[10:04] <jtv> querulous quopossum?
[10:04] <bigjools> reaching
[10:04] <jtv> very
[10:24] <adeuring> good morning
[10:27] <jtv> morning adeuring!
[10:27] <adeuring> hi jtv!
[10:29] <jelmer> jcsackett: hi
[10:31] <jtv> and hello jelmer, hello jcsackett :)
[10:31] <jelmer> Jeroen!
[10:32] <al-maisan> Good morning adeuring
[10:33] <adeuring> hi al-maisan!
[10:33] <jelmer> hi Abel, Muharem
[10:33] <al-maisan> hello jelmer :)
[10:33] <adeuring> hey jelmer!
[10:34] <jtv> jelmer: you strike me as a likely chap to be able to improve this documentation: https://dev.launchpad.net/LaunchpadPpa?highlight=%28launchpad%5C-dependencies%29#launchpad-dependencies
[10:34] <jtv> "Edit debian/control to add or change the dependencies. Your name + email address must match an identity in your GPG key exactly."
[10:34] <jelmer> jtv: maybe :)
[10:34] <jtv> As an amateur, I would've thought the name and email address went into changelog.
[10:35] <jtv> Also, I don't suppose there's any way to add a dependency for lucid?
[10:36] <jelmer> jtv: That comment doesn't seem like it belongs on the line about debian/control
[10:36] <jtv> Right.
[10:36]  * jelmer does the wiki editing thing
[10:37] <bigjools> jtv: we need a separate lucid package, *unless* the new a-f version is larger than lucid and less than maverick's
[10:38] <bigjools> you can add "apt >= <new version>" in that case
[10:38] <jtv> It's inbetween.  I'm just wondering: if I say "maverick" in the changelog, will the change still go into lucid machines?
[10:38] <bigjools> jtv: when I changed them recently, I uploaded to maverick, and then package-copied w/binaries to lucid
[10:38] <jtv> I have a >> dependency to be precise, for complicated reasons.
[10:38] <bigjools> and natty
[10:39] <bigjools> why?
[10:39] <jtv> Complicated reasons.
[10:39] <jtv> gmb added a "lucid" entry to the changelog last month.
[10:40] <jtv> bigjools: I guess the binaries don't amount to much for this stuff.
[10:40] <bigjools> no
[10:40] <jtv> So the same copy would work for me as well.
[10:40] <bigjools> but you need to select that option or it won't copy
[10:41] <jtv> It'll detect the maverick entries in the changelog and refuse to build for lucid?
[10:42] <bigjools> no, you can't copy intra-archive without binaries
[10:44] <jtv> ah
[10:47] <jtv> jelmer: thanks for the fix :)
[11:07] <henninge> jtv: Hi!
[11:07] <jtv> hi henninge!
[11:08] <henninge> jtv: Can you have a look at this mp, please and possibly review it?
[11:08] <henninge> https://code.launchpad.net/~henninge/launchpad/devel-710591-setcurrenttranslation-extension/+merge/48594
[11:08] <jtv> henninge: yes on the former, maybe on the latter :-P
[11:08] <henninge> I know, I know ...
[11:08] <henninge> ;)
[11:08] <jtv> Joking—I'll review.
[11:08] <jtv> For a price^H^H^H^H^H^H^H^C
[11:09]  * henninge might fall asleep though
[11:15] <jtv> and jtv might eat a bit—won't take long.
[11:29] <jtv> henninge: typo in ITranslationMessage.acceptAsImported: sold_style_import
[11:30] <jtv> henninge: also, please move the "real" docstring from the model class to the interface.
[11:30] <jtv> Oh, the big one is on POTMsgSet, not TranslationMessage.
[11:30] <henninge> jtv: right, that is modeled after approve.
[11:31] <jtv> Sorry about that.
[11:34] <henninge> jtv: I just saw that "lib/lp/app/widgets/__init__.py" appears in the diff. I had a conflict when pulling the latest devel.
[11:35] <jtv> I was wondering about that but decided not to whinge. :)
[11:35] <henninge> That is not supposed to be in my brnach.
[11:36] <jtv> henninge: I see that the design discussion opened up another can of worms about imports as well.
[11:37] <henninge> which design discussion?
[11:37] <jtv> The design discussion for your branch.
[11:38] <jtv> "What to do about Ubuntu packaged/published/imported/upstream imports."
[11:38] <henninge> ah, that.
[11:39] <henninge> Well, I realized when doing this that using "approve" in the importer is just not The Right Thing.
[11:39] <jtv> If I read the docstring correctly, this means that messages that get made current during import aren't marked as reviewed.  I thought they were, actually.
[11:39] <henninge> jtv: btw, the next branch will actually update the importer.
[11:40] <henninge> No, they were not,
[11:40] <henninge> I checked the old code.
[11:40] <jtv> That explains why I can't look up the answer to that question in the diff.  :)
[11:40] <jtv> So we were getting is_current messages without a review date?
[11:41] <henninge> Obviously yes, since ever.
[11:42] <henninge> David and Robert were pretty confused when all translations uploaded by Robert were marked as being reviewed by him.
[11:44] <jtv> When you update the import code, will we keep the implicit support for non-reviewer uploads?
[11:44] <jtv> "if is_reviewer: acceptAsImported(...)"?
[11:44] <jtv> Because I thought that was very nice in your existing code.
[11:45] <henninge> Hm
[11:45] <bigjools> jtv: what did you change in the a-f stuff?
[11:45] <bigjools> jtv: it works for the package I uploaded but there's loads of new warnings in the log
[11:45] <jtv> bigjools: ah
[11:46] <jtv> that was a bonus
[11:46] <jtv> I logged stderr from the sub-process at a higher level.
[11:46] <jtv> It was previously DEBUG, which seemed inappropriate.
[11:46] <bigjools> hmmm ok
[11:46] <jtv> Want me to change that?
[11:46] <bigjools> no, let's roll with it
[11:46] <jtv> I was about to haggle down to INFO.  :)
[11:47] <jtv> But stderr is meant to be for error stuff, after all.
[11:47] <bigjools> the DF warnings are genuine, just annoying
[11:47] <jtv> Then maybe the real lesson is that we should fix them.
[11:47] <bigjools> it's basically because we've not got an intact archive on there due to lack of space
[11:47] <henninge> jtv: I had not planned on that. I was going to use "old_style_imports" only if the upload is by_maintainer and to a source package and no upstream template eixists.
[11:47] <bigjools> jtv: nothing to fix
[11:47] <henninge> jtv: but I don't plan to use approve for anything.
[11:47] <bigjools> other than to publish with the "careful" option - but we'd run out of disk space pretty quick
[11:48] <jtv> henninge: is this related to it being old-style though?  I would have thought you were going to replace the approve call with an acceptAsImported one.
[11:48] <henninge> exactly
[11:49] <henninge> but the "old_style" parmeter is only True when those three conditions are met
[11:49] <henninge> s/is/will be/
[11:49] <jtv> henninge: then this isn't really "old style" (especially since AFAIK we have no plans to change it), more a kind of "upstream-by-proxy style" import.
[11:50] <henninge> well, I called it old_style because it uses "is_current_upstream" like the old "is_imported"
[11:50] <henninge> when importing to a source package
[11:50] <jtv> henninge: yes, but think from the perspective of an engineer who's not familiar with Translations as it was before Recife, who now has to work on the codebase.
[11:50] <jtv> Unlikely, I know.  :-)
[11:51] <bigjools> is anyone already fixing devel?
[11:51] <henninge> oh, I have a few engineers here in my squad that are having fun with the codebase...
[11:51] <jtv> henninge: that engineer won't have "old style" as a reference base, and won't be interested in it, and will interpret it as legacy stuff, to be grandfathered in eternally and then removed.
[11:51] <jtv> So can you come up with a more descriptive name?
[11:51] <henninge> jtv: ok, renaming is fine by me.
[11:52] <jtv> "Two things are hard…"
[11:52] <henninge> Not when I am this tired ... ;)
[11:52] <henninge> what was the other one?
[11:52] <bigjools> is anyone even bothered about devel?
[11:53] <henninge> What's wrong with it?
[11:53] <henninge> jtv: upstreamless_imports ?
[11:54] <henninge> one_sided ?
[11:54] <jtv> bigjools: is it buildbot?
[11:54] <bigjools> it fails locally too
[11:54] <jtv> We may have grown too accustomed.
[11:54] <jtv> whoops
[11:55] <jtv> henninge: deliberately taking the distraction to give the brain time to percolate. :)
[11:55] <jtv> bigjools: what test?
[11:56] <bigjools> Failure in test canonical.launchpad.webapp.tests.test_authentication.TestOAuthParsing.test_split_oauth
[11:56] <bigjools> see my email
[11:57] <jtv> argh not oauth
[11:57] <wallyworld> bigjools: i just logged on the check how things were going. build failure :-(
[11:58] <bigjools> wallyworld: yeah, see the email I sent
[11:58] <wallyworld> jtv: bigjools: poolie landed a branch which deleted a "duplicate" oauth.py or something like that
[11:59] <wallyworld> perhaps we rollback that branch?
[11:59] <bigjools> that was my thought unless someone knows how to fix it
[11:59] <wallyworld> i'm not across fully the reason for making the change that was made
[11:59] <bigjools> I know pretty much bugger all about oauth :/
[12:00] <wallyworld> well that makes at least 2 of us
[12:00] <wallyworld> i'm waiting on rev 12327 to get to qastaging so i can complete qa of one of my bugs too
[12:01] <wallyworld> but with the build failure, that ain't gonna happen anytime soon
[12:01] <jtv> Passes for me locally.
[12:02] <deryck> Morning, all.
[12:02] <jtv> Few hours old all.
[12:02] <bigjools> jtv: the failing test?
[12:02] <jtv> Hi deryck
[12:02] <jtv> Few hours old *though* :)
[12:02] <jtv> bigjools: yes, test_launchpad_login_source
[12:02] <bigjools> you have latest devel?
[12:02] <jtv> Few hours old.
[12:02] <jtv> I'm not sure about updating it now!
[12:02] <bigjools> test_split_oauth is the test
[12:03] <jtv> Ah that one—passed as well.
[12:03] <bigjools> ?!
[12:03] <bigjools> you have latest sourcedeps etc?
[12:08] <jtv> Guess not.
[12:11] <jtv> henninge: how about calling the new behaviour "upstream for package"?  POTMsgSet.acceptAsImported is really two methods dressed up as one horse though, so I'd advocate splitting it up and putting the "if" all the way in the calling code.
[12:22] <wallyworld> bigjools: the oauth.py removed from lib/contrib is different to the one from the oauth egg
[12:22] <bigjools> AWESOME :)
[12:22] <wallyworld> so that's likely the reason that test fails
[12:22] <wallyworld> the one removed could well be the old, buggy version but.......
[12:23] <wallyworld> and maybe all we need to do is update the failing test, but i don;t have enough knowledge about all this to do that
[12:23] <bigjools> me neither
[12:23] <wallyworld> anyone else likely to know?
[12:24] <bigjools> we probably need to wait for our friends in North Carolina to wake up
[12:24] <wallyworld> we could ask one of the reviewers but they're not here atm
[12:25] <wallyworld> bigjools: so pqm should close as scheduled in 30 minutes and we land a rc fix after that?
[12:25] <wallyworld> or we want to land a rollback now?
[12:25] <wallyworld> or something else?
[12:25] <bigjools> wallyworld: I thought PQM was closing in another 3.5 hours
[12:25] <wallyworld> oh have i got the tz wrong?
[12:25] <bigjools> it was 1600 UTC right?
[12:25] <wallyworld> 14:00UTC
[12:25] <wallyworld> but it can be 16:00 :-)
[12:26] <bigjools> argh
[12:26] <bigjools> seems an odd time :)
[12:26] <wallyworld> i just copied from what happened last release :-)
[12:26] <bigjools> make it 23:00, go on :)
[12:26] <bigjools> you can do whatever you like, you're the RM
[12:26] <wallyworld> well, i vote that we make it 16:00 to fix this issue :-)
[12:26] <bigjools> typically we close it when the US guys finish on a Friday
[12:27] <bigjools> which is 2300
[12:27] <wallyworld> which tz?
[12:27] <bigjools> there is Only One TZ
[12:27] <bigjools> :)
[12:28] <bigjools> my db-devel branch is in ec2 right now as well, if it doesn't land I'll probably have to kill kittens
[12:29] <wallyworld> bigjools: just to be sure, so you saying to close pqm in 3.5 hours
[12:30] <bigjools> wallyworld: in 11.5 hours
[12:30] <wallyworld> bigjools: cool, even better. it's late here and i'm easily confused
[12:30] <bigjools> you'll allmost certainly catch people off guard closing at 1600!
[12:31] <bigjools> wallyworld: actually I meant 10.5 hours :)
[12:31] <wallyworld> ok. i should check in with a losa to make sure the closing time is clear
[12:31] <bigjools> probably a good idea
[12:32] <wallyworld> bigjools: so that will allow your db-devel branch to land and the us guys time to look at the oauth issue
[12:32] <bigjools> yup
[12:32] <wallyworld> ok
[12:32] <bigjools> awesome - go get some sleep, enjoy your weekend
[12:32] <wallyworld> are you able to ping someone from across the pond to follow up?
[12:33] <bigjools> yeah I'll chase
[12:33] <wallyworld> awesome. thanks
[12:33] <bigjools> nae prob
[12:33] <wallyworld> gary_poster: that branch i submitted to ec2 failed tests
[12:34] <wallyworld> so as a quick fix, wgrant added the required insert/update permissions to security.cfg for the personsettings table
[12:34] <wallyworld> and the use of the db_user context manager was rolled back
[12:35] <wallyworld> gary_poster: just as an fyi in case you were wondering what happened ^^^^^^
[12:40] <wallyworld> bigjools: i'll send mbarnett an email about the altered pqm closing time but if he appears before your eod, if you could irc him also that would be great. tia :-)
[12:40] <bigjools> sure thing
[12:53] <adeuring>  /topic https://dev.launchpad.net/| PQM is open | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews
[13:01] <gary_poster> wallyworld: thank you!  so, the main branch landed
[13:02] <gary_poster> ?
[13:02] <gary_poster> and I should clean up the insert/update bits ?
[13:03] <wallyworld> gary_poster: i think instead your branch was branched and the changes i alluded to made and that one was landed
[13:03] <gary_poster> awesome
[13:03] <gary_poster> looking for db-devel
[13:03] <wallyworld> i had to go and get the kid from school so missed the main action
[13:03] <gary_poster> I assume I should fix that up now
[13:03] <gary_poster> :-)
[13:04] <wallyworld> gary_poster: i think the concensus was that the lack of permissions on the personsettings table was the true root cause issue that needed fixing
[13:04] <wallyworld> so not sure there's too much to fix
[13:05] <wallyworld> in other words, perhaps the db_user context manager was not needed
[13:05] <gary_poster> hm.  I didn't think that was actually necessary, especially for the files I touched for instancer
[13:05] <gary_poster> that is, the tests needed the enhanced permissions
[13:05] <wallyworld> ceratinly it's still there but the tests have been reverted not to ust it i believe
[13:05] <gary_poster> for stup
[13:05] <gary_poster> gotcha
[13:05] <gary_poster> for setup I meant
[13:06] <gary_poster> I don't see it on https://code.launchpad.net/~launchpad-pqm/launchpad/db-devel
[13:06]  * wallyworld looks
[13:07] <wallyworld> gary_poster: here's the branch https://code.edge.launchpad.net/~wgrant/launchpad/bug548-db-2-tests
[13:07] <gary_poster> yes I found, thank you
[13:08] <gary_poster> What does status "Superseded" mean I wonder
[13:08] <gary_poster> never seen that one before
[13:08] <wallyworld> me either :-)
[13:08] <gary_poster> oh there it is
[13:08] <gary_poster> https://code.launchpad.net/~wgrant/launchpad/bug548-db-2-tests/+merge/48580
[13:08] <wallyworld> i thought it was submitted to ec2
[13:09] <gary_poster> maybe it failed some more :-/
[13:09] <wallyworld> there's a buildbot failure atm which may be holding things up
[13:09] <gary_poster> ah
[13:09] <wallyworld> you don't know about oauth per chance?
[13:10] <gary_poster> foundations was in charge of it but I barely knew much of anything.  lessee...benji is still sick...stub also worked on it
[13:10] <gary_poster> and then salgado is on another team
[13:10] <gary_poster> so we have no experts :-(
[13:10] <gary_poster> I can stare at it too
[13:10] <wallyworld> :-(
[13:11] <gary_poster> there's no visibility into the test output of my branch
[13:11] <wallyworld> the oauth.py frob lib/contrib was removed sinces there's a version in the oauth egg
[13:11] <gary_poster> which is a shame
[13:11] <wallyworld> but the 2 versions are different and now there's a test failure
[13:11] <gary_poster> so I guess I'll dig into this a bit
[13:11] <gary_poster> can we simply revery?
[13:11] <gary_poster> revert
[13:11] <salgado> gary_poster, I'm happy to have a look at that, if you'd like
[13:11] <wallyworld> gary_poster: you mean the one that i landed?
[13:12] <gary_poster> salgado: thank you!
[13:12] <wallyworld> the test output from that ec2 run i did for you?
[13:12] <gary_poster> wallyworld: I got that.  I meant the one from wgrant
[13:12] <wallyworld> oh.
[13:13] <gary_poster> the changes in wgrant's branch do look good, but actually, I still think what I had will be necessary
[13:13] <wallyworld> gary_poster: btw, bigjools is going to follow up with someone in the usa about the oauth thing. i asked you because i had your attention :-)
[13:13] <gary_poster> there are some dbusers who don't have person access at all
[13:13] <gary_poster> :-)
[13:14] <bigjools> I was going to be asking gary anyway :)
[13:14] <gary_poster> :-P :-)
[13:14] <jtv> bigjools: another thing that should become faster with my "view" branch is finding binary package files on a distribution.  The soyuz queue and sync-source seem to make use of that.
[13:14] <gary_poster> Since salgado has volunteered I think we're officially saved
[13:14] <gary_poster> bigjools, wallyworld ^^^
[13:14] <wallyworld> \o/
[13:15] <bigjools> gary_poster: sorry I'm a bit behind on this conversation, is he fixing the issue or reverting it?
[13:15] <gary_poster> yes bigjools :-P  I never got around to seeing what the issue was
[13:15] <bigjools> jtv: great!
[13:15] <wallyworld> gary_poster: also as an fyi, i got the pqm closing time wrong so it's now 23:00UTC not 14:00UTC
[13:15] <wallyworld> so there's time to get stuff sorted
[13:15] <jtv> bigjools: the more positive you are, the more I feel we must be ignoring some major screwup on my part.  :-)
[13:16] <wallyworld> there's a db-devel rev which needs qa but i'm sure curtis will do that before eod :-)
[13:16] <bigjools> jtv: I'm sure you'll be fine :)
[13:16] <gary_poster> yay!  so now we are at...13:16 UTC?  I forget if I am -5 or -4 .  looking
[13:16] <bigjools> wallyworld: I have a db-devel that will land soon when ec2 finishes it
[13:16] <gary_poster> yeah
[13:16] <jtv> bigjools: I guess you just found my "be more careful" button.  :-)
[13:17] <wallyworld> i've got one to but need 12327 to land on qastaging first >:-(
[13:17] <gary_poster> so we have 9:40-ish, yeah wallyworld?  That's awesome.  Thanks for the heads up
[13:17] <bigjools> wallyworld: mine's already QAed
[13:18] <wallyworld> gary_poster: yeah. i thought i copied from what happened last release but clearly was smiking something that day to get the time so wrong
[13:18] <gary_poster> :-)
[13:18] <wallyworld> bigjools: thanks!
[13:22] <wallyworld> night guys, have a good day. good luck with the oauth thing. email if you need me to do anything for the release
[13:27] <gary_poster> thank you wallyworld !
[13:36] <wgrant> gary_poster: Hi.
[13:36] <salgado> so, this is what happened
[13:36] <gary_poster> wgrant: hi, and thank you too.  1 sec finishing call
[13:37] <salgado> mbp fixed bug 314507 by changing contrib/oauth.py, and in the process of that he wrote a test for the fix
[13:37] <_mup_> Bug #314507: OAUTH server ignores ignores first element in header (rather than realm key) <api> <lp-foundations> <qa-ok> <Launchpad itself:Fix Released by mbp> <python-oauth (Ubuntu):Invalid> < https://launchpad.net/bugs/314507 >
[13:37] <wgrant> gary_poster: My changes are fine. But webservice tests fail because snapshotting hits "Teams do not support this attribute.
[13:38] <salgado> he then noticed we didn't need contrib/oauth.py because we already have a python-oauth egg new enough, which has a fix similar to the one he did to contrib/oauth.py
[13:38] <wgrant> ImmutableVisibilityError: This team cannot be converted to Private since it is referenced by a personsettings.
[13:38] <wgrant> That also.
[13:38] <wgrant> gary_poster: Those are the only two failure modes. But I'll forward you the email.
[13:38] <salgado> but the upstream fix is not really compatible with his fix, so the test fails
[13:39] <gary_poster> wgrant, yeah the email would be perfect
[13:39] <gary_poster> thank you again wgrant
[13:40] <wgrant> No worries.
[13:40] <wgrant> Email sending...
[13:42] <LPCIBot> Project devel build (418): STILL FAILING in 6 hr 8 min: https://hudson.wedontsleep.org/job/devel/418/
[13:42] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
[13:42] <LPCIBot> wallyworld][bug=712882][no-qa] Silence non-error output from
[13:42] <LPCIBot> mirror-prober.sh.
[13:42] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=670452] Fix layout of related branches collapsible
[13:42] <LPCIBot> fieldset
[13:42] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Remove duplicated urgencymap in gina.
[13:42] <LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett,
[13:42] <LPCIBot> sinzui][ui=none][bug=701545][no-qa] remove extra copy of oauth.py
[13:54] <salgado> gary_poster, I've replied to bigjools' email.  bottom line is, I think the change should be reverted until we get a python-oauth with a fix that makes the test pass
[13:55] <gary_poster> salgado: makes sense.  thank you very much!
[13:56] <jtv> adeuring: I'm about to head off for FOSDEM, but was wondering if you could review this one: https://code.launchpad.net/~jtv/launchpad/bug-181368-view/+merge/48609
[13:56] <gary_poster> bigjools: are you available to (find someone on a bug rotation to) do that?
[13:57] <adeuring> jtv: sure, I'll look
[13:57] <jtv> adeuring: and thanks for that other review, very discreet!
[13:58] <jtv> bigjools: any luck on dogfood?
[13:58] <salgado> gary_poster, np
[13:59] <gmb> deryck: YUI JS tests are run as part of our harness, True or False?
[13:59] <deryck> gmb, True
[13:59] <gmb> deryck: Thanks.
[14:00] <deryck> abentley, hey, hey.  standup ping.
[14:00] <deryck> gmb, and YUI tests should be preferred to Windmill
[14:16] <bac> deryck: so how does one run a YUI test from the command line?
[14:18] <jtv> bigjools, adeuring: I'm not long for this login.  If there's anything you need me for, speak now or for the weekend hold your peace.
[14:20] <wgrant> gary_poster: Did my email make it?
[14:20] <gary_poster> yes, thank you much wgrant.
[14:21] <deryck> bac, firefox path/to/test/file.html
[14:21] <wgrant> Great.
[14:21] <wgrant> gary_poster: They look easy enough to fix.
[14:21]  * wgrant sleeps.
[14:21] <gary_poster> wgrant, agreed.  night
[14:21] <deryck> bac, and currently, they are not pretty and easy to read unless you set fetchCSS: true in the test.
[14:21] <bac> deryck: that's not command line.  how are they run by our test harness?
[14:22] <deryck> bac, ah, sorry. xvfb-run ./bin/test -cvvt test_yuitests
[14:22] <deryck> bac, that will run *every* YUI test.  You can limit by adding --layer=BugsWindmillLayer (or whatever app layer you need)
[14:22] <bac> deryck: thanks!
[14:23] <deryck> bac, also, there is no way to run a single YUI file via bin/test.
[14:23] <bac> deryck: gotcha
[14:23] <bac> deryck: i'll add that to the wiki
[14:24] <deryck> but if you TDD with YUI test it makes sense to keep the browser open.  so using firefox path/to/test makes sense there, I think.
[14:24] <deryck> or whatever browser you prefer, obviously.
[14:25] <bac> deryck: right
[14:25] <jtv> henninge: I gave you a conditional approval, by the way, on the points we discussed.
[14:27] <bigjools> jtv: it worked ok
[14:27] <bigjools> thought I'd already said that :)
[14:29] <bigjools> gary_poster: I can revert it
[14:29] <jtv> bigjools: maybe I just missed it.  All I remember seeing is the bit about the warnings.  So the files were produced correctly, not one architecture overwriting the rest or anything?
[14:30] <gary_poster> thanks bigjools
[14:30] <jtv> bigjools: and also, what did it do to performance?
[14:30] <bigjools> jtv: hard to say about that, DF only has one builder
[14:30] <bigjools> but the Package file I looked at was updated ok
[14:30] <jtv> bigjools: well for this purpose, "source" is an architecture.
[14:31] <bigjools> jtv: the Sources file was also ok
[14:31] <bigjools> no idea with performance
[14:31] <bigjools> the longest part by far is where we generate the files for a-f
[14:31] <jtv> bigjools: I've been assuming that the outputs for different architectures never write to the same files, based on wgrant's note that it could be parallelized.
[14:31] <bigjools> correct
[14:31] <jtv> Phew.
[14:33] <jtv> Got a branch in review that'll hopefully speed that part up a bit, but had to stop myself from trying to fix everything.
[14:33] <bigjools> there's one file per suite-arch
[14:33] <jtv> What I thought/hoped.
[14:34] <jtv> I think we could probably ditch the batch processing now, since it's trying to force the StupidCache's hand but we now have GenerationalCache.
[14:35] <jtv> One thing it _could_ still be useful for is prejoining.  Can't do that with those get-all-packages queries, but can with a reasonably-sized batch of rows.
[14:37] <jtv> That'd apply nicely to practically the entire BinaryPackageFilePublishing view: select BPPHs and BinaryPackageFiles, batch them, then batch-fetch the stuff that pulls in the other tables.
[14:38] <jtv> That could save us something like half the tables in the join.
[14:39] <jtv> Anyway, I have to run now!
[14:41] <danilos> bac, adeuring: hi, anyone eager to take on a pretty simple branch?
[14:42] <adeuring> danilos: I'm currently reviewing a branch from jtv... bac?
[14:42] <bac> danilos: ok
[14:42] <danilos> bac, thanks, it's up at https://code.launchpad.net/~danilo/launchpad/bug-548-use-preference/+merge/48616
[14:42] <danilos> bac, fwiw, I am not sure where exactly does the change in app/widgets/__init__.py come from in there
[14:43] <danilos> bac, probably one of merging artifacts (I've based in on as of yet unlanded gary_poster's branch)
[14:43] <gary_poster> yeah
[14:43] <gary_poster> it was an artifact on mine too, starting yesterday
[14:44] <danilos> gary_poster, ah, interesting
[14:48]  * bigjools just sent a testfix to PQM
[14:52] <allenap> gmb, deryck: Would one or both of you have time to review https://devpad.canonical.com/~gavin/howto-import-bugs-into-launchpad.html?
[14:52] <deryck> allenap, sure, I can look.
[14:53] <allenap> Thanks :)
[14:55] <salgado> where's sinzui?  he's replying to lp questions but is not around here?
[14:57] <deryck> allenap, it's very nice.  very thorough.
[14:57] <deryck> allenap, The only "gotcha" I've had that wasn't covered, was importing bugs into a private project on staging.  Thinking the bugs didn't import, when it was just that I couldn't see them.
[14:57] <deryck> not sure if that should be covered or not, but otherwise, it's very well done and accurate.
[14:58] <allenap> deryck: Cool. I've never done an import into a private project. Is it just that the bugs are not visible unless you've got the right puppy powers?
[14:59] <deryck> allenap, exactly.  so you completely have to depend on the person to followup and check them completely themselves.
[14:59] <danilos> allenap, gmb: hi guys, do you know if it's possible to set a direct subscription to LIFECYCLE through UI already (on qastaging)?
[14:59] <allenap> deryck: Okay.
[14:59] <gmb> danilos: It isn't.
[14:59] <allenap> deryck: Thank you :)
[14:59] <deryck> allenap, private is the exception, obviously.  but commercial customer imports will be this way.
[14:59] <deryck> allenap, np! :-)
[15:00] <gmb> danilos: Oh, wait.
[15:00] <gmb> I tell a lie
[15:00] <danilos> gmb, ok, thanks... ok, no thanks for you then! :)
[15:00] <gmb> danilos: Yes, it can be done (sorry, I saw LIFECYCLE and read NOTHING for some reason)
[15:01] <danilos> gmb, is it just +subscribe on the bug?
[15:01] <gmb> danilos: if you go to bug/+subscribe you can choose it there.
[15:01] <danilos> gmb, I assume I need malone-alpha membership?
[15:01] <danilos> gmb, because I don't see it on https://bugs.qastaging.launchpad.net/malone/+bug/548/+subscribe
[15:01] <_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
[15:02] <gmb> danilos: You're not a member of malone-alpha on qastaging. I've added you.
[15:03] <danilos> gmb, excellent, thanks
[15:05] <danilos> I keep getting timeouts on qastaging trying to subscribe to a bug... let me try modifying an existing subscription isntead
[15:08] <mars> bac, ping
[15:10] <bac> hi mars
[15:26] <bigjools> testfix landed 10 mins ago
[15:48] <bac> hi danilos, i'm looking at your branch.
[15:48] <bac> danilos: i'm confused by bugnotification.py
[15:49] <bac> danilos: why do you test not person.selfgenerated_bugnotifications instead of not recipient.selfgenerated_bugnotifications
[15:50] <bac> danilos: why do you test "not person.selfgenerated_bugnotifications" instead of "not recipient.selfgenerated_bugnotifications" ? (redone for clarity)
[15:51] <bac> nm
[15:53] <danilos> bac, ok :) (fwiw, it's because recipient might be including the person transitively, so this is the cheapest check)
[15:54] <bac> danilos: for the list of bugnotifications, the first_notification.message.owner is the person who performed the action that is generating the message?
[15:54] <danilos> bac, that's right
[15:54] <bac> for all bugnofitications
[15:54] <danilos> bac, in that method, all notifications that are passed in are caused by the same person and for the same bug (look at asserts below)
[15:54] <bac> perhaps changing 'person' to something more descriptive, like 'instigator'
[15:55] <danilos> bac, sure, makes sense
[16:17] <danilos> bac, btw, how do you feel about: 1) 'originator', 2) 'person_causing_change', 3) 'changed_by', 4) 'change_caused_by' or something like that?
[16:18] <bac> 2
[16:18] <bac> it's wordy but unambiguous
[16:18] <sinzui> I suspect the worst. gedit and gvim go belly up seconds after they launch. I think I should restart before natty's desktop session ends the same way
[16:19] <danilos> bac, cool, thanks
[16:22] <bigjools> how had I not noticed before that the branch page shows what branch was merged in each revision and the bug - that's awesome
[16:41] <jml> allenap: do you want to give my branch a spin again, see if it builds now?
[16:41] <jml> bzr+ssh://bazaar.launchpad.net/~jml/launchpad/sphinx-it-up
[16:41] <allenap> jml: Cool, yeah.
[16:49] <sinzui> bac: do you have time for a trivial branch: https://code.launchpad.net/~sinzui/launchpad/reg-docs-1/+merge/48627
[16:49] <bac> sinzui: sure
[16:51] <allenap> jml: Works nicely :) security.txt had a "severe" error, which can be fixed with http://paste.ubuntu.com/562626/. I'll go and update the mp.
[16:51] <jml> allenap: ta
[17:40] <bac> sinzui: sorry, i was overcome by hunger and had to grab some lunch
[17:40] <sinzui> bac: np. I an struggling to bring some stability to natty
[17:46] <bac> sinzui: do we need to specify the hkp port since the value you list is the default?  it's kind of like saying http://www.foo.com:80, no?
[17:46] <sinzui> I do not know
[17:47] <sinzui> google is not forthcoming on this question
[17:55] <bac> sinzui: the bug report seemed to indicate the port was not necessary, unless i misread
[17:55] <sinzui> bac: I agree
[17:55] <sinzui> I am very disappointed by the lack of documentation about this
[17:58] <sinzui> bac: I will remove the port because we know the default port is being used by ubuntu's keyservers
[17:58] <bac> sinzui: great.
[18:00] <bac> hi abentley, there is a question about code imports failing.  could you look at it?  https://answers.launchpad.net/launchpad/+question/143861
[18:11] <sinzui> bac: ping
[18:11] <bac> hi sinzui
[18:12] <sinzui> bac: can you add open-cat-team so that I can veryify the membership is proposed: https://staging.launchpad.net/~delegated-team/+add-my-teams
[18:12] <bac> done
[18:12] <sinzui> \o/
[18:57] <abentley> henninge, I am updating the template precedence rules so that we can merge productseries templates with sourcepackage templates.
[18:57] <henninge> abentley: wie bitte?
[18:57] <abentley> henninge, I'm guessing that a product translation focus should take precedence over a package translation focus.  What do you think?
[18:58] <abentley> henninge, ja
[18:58]  * henninge has to think about this for a moment
[19:00] <henninge> abentley: I never really touched that, I think that's Jeroen's making.
[19:00] <henninge> abentley: where is this precedence applied?
[19:00] <bac> hi henninge and abentley.   there were questions related to your expertise that i assigned to you.  hope that is ok.
[19:01] <henninge> bac: I answered mine ;)
[19:01] <abentley> henninge, it's used by the message sharing migration script, which I have now refactored to be used from the job.
[19:01] <bac> cool, thanks henninge
[19:02] <henninge> abentley: I figured but where exactly? Is it about chosing which POTMsgSet to keep and which to throw away?
[19:02] <abentley> bac, alright.
[19:03] <abentley> henninge, it's used to decide which is the most "representative" POTMsgSet, which yes, I believe affects which ones get deleted.
[19:05] <henninge> abentley: yes, I assume we'd want to favor the upstream template here.
[19:05] <henninge> otoh, I don't think it makes a huge difference.
[19:06] <abentley> henninge, in case of clashes, the subordinate is "saved" by diverging it.
[19:06] <henninge> abentley: hang on, but now you are talking about translation messages.
[19:08] <abentley> henninge, you're right, it's diverging translationmessages.
[19:08] <henninge> abentley: in that case it might be smarter to do it the other way round.
[19:08] <henninge> because of the 1:n relationship
[19:09] <henninge> scratch that
[19:09] <abentley> henninge, I think it's a question of whether you want to favour diverging upstream or ubuntu translations.
[19:10] <henninge> abentley: a clash between upstream and Ubuntu should be solved by keeping both and setting is_current_upstream and is_current_ubuntu on each of them respectively.
[19:10] <henninge> so that's not really a clash.
[19:11] <abentley> henninge, would you have to mark one of them diverged?
[19:11] <henninge> no
[19:11] <henninge> the one will be shared on the product side, the other on the ubuntu side
[19:12] <henninge> A clash is when you have different translations within different series of the same product or source package.
[19:12] <henninge> Then diverging is the only solution.
[19:13] <abentley> henninge, okay.
[19:15] <henninge> abentley: the question here is, will the job deal with both kinds of merging: The old kind within a prouduct/sourcepackage and the new kind between a product and a sourcepackage.
[19:16] <henninge> or will it assume that all products and sourcepackages it encounters are already sharing within themselves?
[19:16] <abentley> henninge, the answer is "kinda".
[19:16] <henninge> I think that might be okay.
[19:17] <abentley> henninge, the laziest solution is to perform the merge within the product and all linked sourcepackage/distroseries.
[19:17] <abentley> henninge, because we already have ways of getting that list.
[19:18] <henninge> abentley: sounds right
[19:18] <abentley> henninge, but we could query for just the templates within the productseries and sourcepackage that were just linked.
[19:19] <abentley> Presumably, that's more efficient if we assume that the product and sourcepackage are already sharing maximally.
[19:19] <abentley> (in their separate domains)
[19:20] <henninge> oh, now I see your point
[19:20] <henninge> officially, the message sharing migration has finished.
[19:20] <henninge> (the old one)
[19:21] <henninge> so the script should rightfully assume that each are sharing within themselves.
[19:22] <henninge> abentley: I have to go afk for a while.
[19:22] <abentley> henninge, okay.  Ping when back.
[19:22] <henninge> sure
[19:52] <henninge> abentley: ping (back for a little while)
[20:02] <abentley> henninge, why do we limit potmsgsets to templates with the same name?  Why not share all translations of the same phrase within a piece of software?
[20:03] <henninge> abentley: wow, that is a very fundamental question you are raising there!
[20:05] <henninge> abentley: but I guess one easy anser might be that one of the reasons to partition the translatable strings of a piece of software into different templates is to keep domains appart.
[20:05] <henninge> e.g. the UI and the backend, where the same term might be used differently.
[20:06] <henninge> Also, without that, we'd have to re-define divergence a little although that already points to individual templates.
[20:06] <abentley> henninge, If we really did want different translations of the same term, we could use divergence.
[20:07] <abentley> henninge, it's just that I'm reimplementing that restriction, so I had to wonder how much sense it makes.
[20:08] <henninge> otoh the overlap between different templates should be small.
[20:08] <henninge> abentley: yes but that is not the only place in the code were that restriction is used/enforced.
[20:08] <abentley> henninge, I think this restriction means that if one template splits into two, or two combine into one, we'll lose an opportunity to carry translations across.
[20:10] <henninge> that is true
[20:11] <henninge> abentley: I'd say that is something to think about but it would be an extra branch to introduce it.
[20:11] <abentley> henninge, cool.
[20:11] <henninge> But it shows how spreading the domain knowledge bring in new views and ideas. ;-)
[20:12] <henninge> (or possibly an extra feature)
[20:13]  * henninge has to lunch now
[20:22] <maxb> Is someone doing something to the sourceforge code imports right now?
[20:23] <maxb> Because I'm seeing what looks like an import that got dispatched to an import slave despite being in suspended status
[20:24] <lifeless> maxb: theres no chatter in -ops about such a change
[20:24] <maxb> lifeless: They're failing to present the intermediate cert in their change
[20:24] <maxb> *chain
[20:24] <maxb> This means that tolerant things like firefox are happy. Stricter things like gnutls and java are very much not
[20:24] <lifeless> maxb: yes, so they all failed
[20:26] <maxb> Someone has evidently set the imports to Suspended status, but I don't understand why they are still apparently being dispatched to the importds
[20:27] <lifeless> mm
[20:27] <maxb> https://code.launchpad.net/~vcs-imports/emesene/trunk for example
[20:27] <lifeless> perhaps they were already queued
[20:27] <lifeless> mwhudson: ^ you were involved...
[20:28] <deryck> heh.  I just completed the Thunderdome survey.
[20:29] <deryck> it's not exactly rick rolling.  But it's nice. :-)
[20:29] <lifeless> maxb: I've toggled that one into failed and back to suspended
[20:29] <lifeless> maxb: we'll see if that sorts it out
[20:30] <maxb> we need code imports exposed in the api :-/
[20:30] <maxb> oh for a tuit :-)
[20:37] <lifeless> maxb: that would be great.
[20:38] <maxb> Maybe after I finish off my in-progress bzr work :-)
[20:39] <james_w> code imports are exposed to some extent
[20:44] <jam> lifeless: maybe you can point me to someone else. I'm trying to write a launchpad test that asserts when something fails we *do* create an oops
[20:44] <jam> but the test infrastructure seems to say "getting an oops == the test failed"
[20:44] <lifeless> jam: in what context are you doing htat
[20:44] <lifeless> jam: the different layers will impact this
[20:45] <jam> lifeless: the oops_middlewear for the loggerhead test suite isn't yet tested
[20:45] <jam> so I wanted a test that it creates an oops normally
[20:45] <jam> and then doesn't create one for socket exceptions
[20:45] <jam> like EPIPE
[20:45] <lifeless> cool
[20:45] <jam> I tracked into the stack, and we *are* suppressing the exception in the WSGIHandler, but that is above the application
[20:45] <jam> and the oops logic is an app that traps it underneath that
[20:45] <lifeless> yah, I saw your mail on that
[20:46] <lifeless> so
[20:46] <lifeless> what method is treating oops=test fail
[20:49] <lifeless> jam: or are you not sure?
[20:49] <jam> I'm not sure
[20:49] <lifeless> pastebin the failure ?
[20:50] <jam> lifeless: https://pastebin.canonical.com/42908
[20:50] <jam> It may be that the oops is only reported because the test failed?
[20:51] <jam> Obviously RuntimeError was raised, but maybe it doesn't propagate all the way up the stack
[20:51] <lifeless> right
[20:51] <lifeless> that oops is just accumulated via addDetails
[20:51] <lifeless> your line 186 is the actual failure
[20:51] <lifeless> File "/home/jameinel/dev/launchpad/work/lib/launchpad_loggerhead/tests.py", line 186, in test_exception_triggers_oops
[20:51] <lifeless>     self.runtime_failing_app)
[20:53] <jam> ahh, oops_middleware has "if error_page_sent: return" rather than raise
[20:53] <jam> so if it can get to the point it can report the error, then it *doesn't* re raise the exception
[20:53] <jam> I'm not entirely sure why, but I can live with it
[20:54] <lifeless> well
[20:55] <lifeless> we want to show a page describing the oops
[20:55] <lifeless> if we raise the user gets a INTERNAL SERVER ERROR page
[20:55] <jam> lifeless: which they'll get if we get an internal error after starting the response body
[20:55] <jam> but... meh
[20:55] <jam> not something I have to fix for what I'm working on
[20:55] <lifeless> right
[20:56] <lifeless> in lp proper we buffer until we know we'll succeed
[20:56] <lifeless> for a few reasons, this being one of them.
[21:23] <jam> mwhudson: if you're around. When I run 'make run_codebrowse' it fails when trying to access the xmlrpc server. It seems to work with 'make run_codehosting'. Should we get rid of the 'make run_codebrowse' target entirely?
[21:25] <jam> ah, nm, we can't
[21:25] <jam> because 'bin/run codewbrowse' actually calls back into 'make run_codebrowse'
[22:02] <LPCIBot> Yippie, build fixed!
[22:02] <LPCIBot> Project devel build (419): FIXED in 6 hr 34 min: https://hudson.wedontsleep.org/job/devel/419/
[22:16] <lifeless> sinzui: hi
[22:33] <sinzui> hi lifeless
[22:34] <lifeless> I was wondering
[22:34] <lifeless> bug 712698
[22:34] <_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
[22:34] <lifeless> may be pretty - or even very - shallow
[22:35] <lifeless> its outside our direct remit, but as a team we'd gain a lot if we can increase the openid nonce timeout
[22:36] <sinzui> wgrant: was looking at this code two weeks ago
[22:36] <lifeless> yeah
[22:36] <lifeless> so it might be easy for him to eyeball and write up /how/ sysadmins can reset nonces
[22:36] <lifeless> I imagine there is a non-coding solution.
[22:40] <sinzui> mailman polls to keep this information synced. I am not sure if it is viable to do a push scenario since there are a lot of sites to push too
[22:41] <lifeless> sinzui: well, this is for our microsites
[22:41] <sinzui> getMembershipInformation(team) is the very method I refactored last week
[22:42] <lifeless> sinzui: the goal is some means for the losas to ensure that folk which have left the company do not retain access
[22:42] <lifeless> sinzui: e.g. its a very rare event
[22:43] <sinzui> That is a special case in leaveTeam() admins (losas) can force the leave to be silent
[22:43] <lifeless> sinzui: at the moment the only mechanism is doing a new openid handshake, which is very slow and annoying
[22:43] <lifeless> sinzui: perhaps we're talking at cross purposes?
[22:44] <sinzui> No
[22:44] <sinzui> I understand what you are asking, but there is a massive gap between what we do now and what we are asking in therms of Lp integration
[22:44] <lifeless> sure; this is why I was talking low tech
[22:45] <lifeless> just a 'reset all the nonces for a given microsite'
[22:45] <sinzui> bridging that gap requires understand what we do now, why and asking if we want to extend the behaviour or replace everything with a more comprehensive solution
[22:45] <lifeless> there are only a few such sites - devpad, lpstats, lp-oops
[22:45] <lifeless> sinzui: fair enough, I am rather jumping the gun :)
[22:46] <lifeless> sinzui: however, sadly, I have to pop out for a while; it would be cool to make this better in any regard
[22:57] <henninge> Hi! Is this a known failure? http://paste.ubuntu.com/562802/
[23:43] <wgrant> lifeless, sinzui: I think we can probably just tell people to purge the OpenID session cache.
[23:43] <wgrant> It would be nice if the server could rerun check_authentication behind the scenes, but it can't :/
[23:45] <sinzui> wgrant: if we recorded which sites asked for which teams, and see a removal from such as team, we should push. That does require co-ordinated work of course
[23:46] <wgrant> s/OpenID/mod_python/
[23:46] <wgrant> sinzui: We could.
[23:46] <wgrant> But that is probably going to require OpenID extensions and stuff.
[23:53] <wgrant> bac: Why did you assign me to that Google Code import question?
[23:58] <henninge> wallyworld: Hi, are you available to grant r-c's?
[23:59] <henninge> Hm, is PQM really still open or is the subject lying?
[23:59]  * henninge tries