[00:09] <lifeless> pqm is open
[00:12] <wgrant> lifeless: Erk
[00:12] <wgrant> garbo-hourly is failing
[00:12] <wgrant>  -> http://launchpadlibrarian.net/63827955/dMm2kkmdygvorvKKvD9t02EQdHa.txt (duplicate key value violates unique constraint "bugmessage__bug__index__key"
[00:13] <lifeless> thanks
[00:13] <lifeless> unindex that bug
[00:13] <wgrant> Hm?
[00:13] <lifeless> a bug message index is being changed
[00:13] <lifeless> if we unindex that bug, it will resume
[00:13] <wgrant> Right.
[00:14] <lifeless> we can tell the bug by running the query it uses
[00:14] <lifeless> -> -ops and nab a losa
[00:14] <wgrant> Ah, possibly, true.
[00:14] <lifeless> alternatively
[00:14] <lifeless> unindex all partly indexed bugs
[00:25] <poolie> where should a developer guide to feature flags live? on the wiki? under the architecture guide?
[00:27] <mhall119> lifeless: the production environment for LD is secure, it's on Canonical's servers and managed by the sysadmins
[00:27] <mhall119> any credentials or anything can be stored there, and even us developers wouldn't know them
[00:27] <poolie> wgrant, i have a patch up for multiply stacked repositories, which is +1
[00:27] <poolie> i will land that, i guess into 2.3
[00:27] <wgrant> poolie: So I saw.
[00:28] <wgrant> Should I patch our egg with it?
[00:28] <poolie> do you know of any other problems related to this?
[00:28] <wgrant> I don't really feel like RCing 2.3 in.
[00:28] <poolie> i thought you had a branch not an egg?
[00:28] <wgrant> We have an egg, not a branch.
[00:28] <poolie> (hm, did that change?)
[00:28] <poolie> anyhow, that seems like a reasonable approach to me, given my understanding of lp deployment
[00:28] <wgrant> Not in my time, I don't think.
[00:29] <lifeless> wgrant: I'll do a branch in the meantime, when reindexing, to set all to NULL, then flush, then assign values.
[00:30] <wgrant> lifeless: Thanks.
[00:32] <wgrant> poolie: Hm, we're running a patched 2.2.2 at the moment.
[00:32] <wgrant> I suppose we should upgrade to at least 2.2.4 soonish.
[00:36] <wgrant> wallyworld_: Hi.
[00:36] <wallyworld_> hello
[00:37] <wgrant> wallyworld_: I am about to apply https://code.launchpad.net/~mbp/bzr/715000-stacking/+merge/48886 to our bzr egg.
[00:37] <wgrant> wallyworld_: This ideally wants to be deployed tomorrow.
[00:37] <wgrant> Will we deploy the latest stable rev, or the one that you blessed?
[00:37]  * wallyworld_ looks
[00:38] <wallyworld_> wgrant: the mp diff has conflict markers in it?
[00:38] <poolie> wgrant, since we just froze 2.3.0 i think we should go straight to that
[00:39] <poolie> wallyworld_, that's because it's targeted to trunk; it should be clean against 2.2
[00:39] <wgrant> poolie: OK, I might do that next week.
[00:39] <poolie> i'd be happy to help
[00:40] <wallyworld_> poolie: wgrant: is there an urgent need to have to rollout the bzr update with this release or can we do it as a nodowntime deployment after release?
[00:40] <wgrant> wallyworld_: crowberry isn't in nodowntime.
[00:40] <wgrant> But I guess this is only realllllly needed on loganberry.
[00:40] <wgrant> I think.
[00:41] <wallyworld_> ah ok
[00:41] <wgrant> This is also a critical issue.
[00:41] <wallyworld_> last time a bzr upgrade went into lp, stuff broke so i'm being cautious
[00:41] <wgrant> It is preventing us from starting the package importer, which blocks UDD.
[00:41] <wgrant> Right.
[00:41] <wgrant> But this is a very small patch :)
[00:41] <wallyworld_> so was the other one :-P
[00:41] <wgrant> Oh?
[00:41] <wgrant> I don't recall it.
[00:42] <wallyworld_> i can't recalls the specifics now
[00:42] <poolie> we can do it separately from the release i think
[00:42] <poolie> in that case, why not do it now and then do the release tomorrow?
[00:42] <wallyworld_> to me, any change close to release time is risky
[00:42] <wgrant> wallyworld_: OK, can I at least get it on stable nowish so we can deploy right after the release?
[00:42] <poolie> i know, but it's always release time
[00:43] <wallyworld_> we need time to do proper qa, considering the potentialimpact if the bzr upgrade breaks things
[00:43] <wallyworld_> poolie: true
[00:43] <lifeless> so
[00:43] <lifeless> this is what I suggest
[00:43] <lifeless> a) land the patch
[00:43] <lifeless> b) qa
[00:43] <lifeless> c) if, at rollout time, a newrev is deployable, great. Do that.
[00:44] <lifeless> d) if the bzr change isn't ready by then, we do scheduled downtime to codehosting to deploy it
[00:44] <wgrant> That was my plan.
[00:44] <wgrant> Except that loganberry runs the scanner, so we probably don't need downtime.
[00:45] <wallyworld_> does bzr 2.3 have the change in it already?
[00:46] <wgrant> No.
[00:46] <wallyworld_> so in that case imho we patch our current bzr egg as suggested
[00:46] <poolie> great
[00:47] <wallyworld_> and rollout 2.3 later once it has had the change and full qa for the other new 2.3 things etc
[00:47] <wallyworld_> qa in terms of lp integration
[00:48] <wallyworld_> poolie: you still ok to help with the forking lp-serve switchover tomorrow?
[00:48] <wallyworld_> do you need to help?
[00:48] <wgrant> wallyworld_: Right, that's what I thought.
[00:49] <wallyworld_> wgrant: great. thanks for doing the work to get it in
[00:51] <poolie> wallyworld_, i shouldn't need to do anything afaik but i'll be on line if you want to talk/ask about it
[00:51] <poolie> i just want to make sure it goes live
[00:51] <poolie> you could perhaps check now whether it's sufficiently documented in the rt etc
[00:51] <poolie> or i guess we can just discover that tomorrow
[00:52] <wallyworld_> poolie: that would be appreciated. just in case.  i've not enough knowledge to know if the doc is good. has a dry run been done using the doco? if not, perhaps we should do one?
[00:53] <poolie> good idea; maybe we should do it with a losa
[00:53] <poolie> i guess spm
[00:55] <wallyworld_> if he is the one doing the work on the day, then that would be my suggestion
[00:55] <poolie> it's not *that* scary of a change
[00:57] <wallyworld_> sure, but doco needs "testing", just like code :-)
[00:57] <wallyworld_> just to ensure that it is correct and when followed on the day, everything goes as expected
[00:58] <wallyworld_> so a dry run often achieves this goal, especially when done by the intended implementer
[01:07] <poolie> sure
[01:07] <poolie> so when spm gets back(?) we could do a walk-through?
[01:08] <wgrant> poolie: Can a 2.3.1 come soon with this fix, or should I prepare a patched 2.3.0?
[01:08] <poolie> wallyworld_, i think of you when i say "treat every gun as loaded" in bug 714043 :)
[01:08] <_mup_> Bug #714043: defaulting to staging is confusing <launchpadlib :Triaged> < https://launchpad.net/bugs/714043 >
[01:08] <poolie> wgrant, it can come soon
[01:08] <poolie> but where are you going to use a patched 2.3?
[01:08] <poolie> i thought you said lp was on 2.2.
[01:09] <wgrant> poolie: I'm patching 2.2.2 for now.
[01:09] <wgrant> But you say we want to be on 2.3.0 soon.
[01:09] <poolie> ah, by the time we get there it will be in 2.3x, and probably in 2.3.1
[01:09] <poolie> i think for conceptual clarity it would be good to keep lp on actual releases as much as we can
[01:09] <wgrant> Definitely.
[01:10] <poolie> huwshimi, oh, interesting re my comment about hover and tablets to see the thread about mobile browsers
[01:11] <wgrant> How do I run bzr tests?
[01:11] <wallyworld_> poolie: watch what you say or else i'll get out my uzi. i know where you live :-)
[01:11] <poolie> ./bzr selftest
[01:12] <wgrant> I tried that.
[01:12] <wgrant> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_WritelnDecorator'
[01:12] <wgrant> :/
[01:12] <wgrant> Maybe it'll work on 2.6.
[01:12] <wgrant> Yes.
 sure, but doco needs "testing", just like code :-) <== /me awards 100 awesome points to wallyworld_ :-)
[01:12] <poolie> was that on 2.7?
[01:12] <poolie> i think that's fixed in bzr 2.3
[01:13] <wgrant> That was.
[01:13] <wgrant> I forgot that 2.2 was still 2.7-hating.
[01:13] <thumper> FUUUUUUU.....
[01:13] <wallyworld_> spm: i spent 10 years seeing the results of deployment doco used on site without doing a run through first - not pretty :-)
[01:14] <poolie> :)
[01:14] <spm> ha
[01:14] <wallyworld_> poolie knows the project i am referring to :-)
[01:14]  * thumper wants to stab lazr-js in the face
[01:14] <cjohnston> lifeless: if by secured you mean I can't access it yes... we have to submit an RT
[01:15]  * thumper takes a deep breath
[01:24] <poolie> yeah, and i tried to help deploy it after about 6 months working on it
[01:24] <poolie> i felt a bit out of my depth :)
[01:25] <poolie> was kind of fun though
[01:28] <lifeless> wgrant: checkwatches; halted? in progress?
[01:29] <sinzui> huwshimi: wontfix? really? I was hoping for a unification of shades and a fix for the two odd tables I found
[01:30] <wgrant> lifeless: I was going to get back onto it after lunch, which is itself going to happen once I get this bzr thing proposed.
[01:44] <huwshimi> sinzui: I think those are a separate issue. If you file a bug about them I can get to them at some stage.
[01:45] <huwshimi> sinzui: I think there are bigger issues with the readability of the tables, and I'm not sure the hover is the right solution.
[01:46] <sinzui> huwshimi: I think mpt had similar concerns in the past
[01:46] <huwshimi> sinzui: I want to think about the tables a bit more and come up with a plan.
[01:46] <sinzui> huwshimi: The plethora of background shades may be the same issue. I wonder if I never see some of them
[01:47] <huwshimi> sinzui: yeah there is a bit of that.
[01:48] <huwshimi> sinzui: I'm always grepping through the source trying to find weird situations where things show up
[01:49] <sinzui> I new to look at the mirrors listing because I recalled they had an exceptional style
[01:50] <sinzui> s/new/knew/
[01:50] <sinzui> or gnu
[01:52]  * thumper is full of lazr-js sadness
[01:52]  * thumper branches lp:lazr-js again
[01:53] <lifeless> thumper: whats wrong?
[01:54] <thumper> lifeless: I'm hacking a BinaryChoiceWidget based on lazr-js ChoiceEdit
[01:55] <thumper> lifeless: it is just not good, and needs fixing
[01:55] <thumper> I'd be happy to bitch at length, but that doesn't help it get fixed
[01:55] <thumper> also, your use of the ChoiceEdit for the vocabulary choosers is HORRIBLE
[01:55] <thumper> and needs to be widgetized
[01:55] <thumper> s/your/our/
[01:56] <thumper> it is just a whole pile of javascript hurt in our tree
[01:56] <thumper> and the bug use of it is not entirely standard
[01:56] <thumper> which also hurts
[01:57]  * thumper goes to pick up the girls from school
[02:08] <poolie> i'm going out to lunch, maybe we can do the walkthrough after htat
[02:31] <lifeless> I need a quick teddy bear
[02:31] <lifeless> I want to use feature flags in base-layout
[02:31] <lifeless> but base-layout also does +opstats
[02:31] <lifeless> which has a DisallowedStore policy
[02:32] <lifeless> so I'm thinking that catching DisallowedStore in the flag lookup and signalling no-rule, would be ok.
[02:32] <lifeless> anyone see a zomg thing with that ?
[02:32] <thumper> I don't know what the DisallowedStore policy is
[02:32] <lifeless> lib/canonical/launchpad/webapp/dbpolicy.py
[02:32] <lifeless> its used for pages which are nt allowed to use a given store
[02:32] <lifeless> e.g. +opstats isn't allowed DB access at all
[02:32] <wgrant> lifeless: I think that's OK.
[02:33] <thumper> lifeless: when is the exception raised?
[02:33] <lifeless> the alternative is, in the +opstats codepath to inject a different FeatureController
[02:33] <thumper> lifeless: as long as it is not before the query, you should be ok
[02:34] <lifeless> thumper: its raised in IStore
[02:34] <lifeless> theres some nuance around this thing, I'm going to keep looking, but thats the crux of it
[03:08] <wgrant> poolie: I cannot get bzr selftest to pass on the 2.2 branch on either of my machines, parallel or not :(
[03:39] <poolie> wgrant, i'll check
[03:40] <poolie> i'm pretty sure the whole thing passed here last night
[03:42] <poolie> wgrant, did you merge it into any branch, or just run mine as-is?
[03:43] <thumper> lifeless: got a minute to chat?
[03:44] <poolie> spm, hi
[03:46] <wgrant> poolie: I merged it into our 2.2.2-ish branch.
[03:46] <wgrant> But I also tried lp:bzr/2.2.
[03:46] <wgrant> Without your patch.
[03:46] <wgrant> And it fails there too.
[03:46] <wgrant> lp:~launchpad/bzr/2.2-lp is your patch on top of our branch.
[03:48] <poolie> !
[03:48] <lifeless> thumper: sure
[03:48] <thumper> lifeless: skype?
[03:48] <lifeless> also
[03:48] <lifeless> I hate our request timeout tests
[03:49] <spm> poolie: am about to fetch boy from school, I'll ping you on return?
[03:49] <poolie> sure
[03:50] <poolie> wgrant, maybe your branch is old enough that the thread leak bugs i thought were fixed are still present
[03:50] <poolie> but even then it never caused it to actually fail for me, just some warnings
[03:52] <wgrant> poolie: There's nothing in 2.2 to fix them.
[03:52] <wgrant> Since you presumably have a working test setup, could you test our branch?
[03:54] <poolie> yes, i will
[03:56] <poolie> i'm re-running my branch now
[03:56] <poolie> wgrant, i suppose i should test on lucid?
[03:56] <wgrant> poolie: That would be great, if you could.
[03:56] <poolie> yes, i have a schroot
[04:01] <lifeless> bug 707234
[04:01] <_mup_> Bug #707234: multiple redundant copies of person picker make_picker function in view-source:https://bugs.launchpad.net/launchpad-project/+bugs?advanced=1 <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707234 >
[04:04] <poolie> wgrant, ok, i do get some spurious failures due to, i think, testtools version mismatches
[04:04] <poolie> that's on maverick, my branch, my laptop
[04:04] <poolie> will re-run lp's branch under lucid shortly
[04:06] <wgrant> Thanks.
[04:07] <poolie> turns out i need to bootstrap it
[04:09] <poolie> anyhow, my branch, aside from some things i feel safe saying are skew against testtools, passes ok
[04:10] <wgrant> Right, thanks.
[04:10] <wgrant> The changes in lp:bzr/2.2 since we branched are irrelevant, so it seems good.
[04:10] <wgrant> I will push the egg.
[04:11] <poolie> just so i know, what do you actually do to make this happen?
[04:12] <wgrant> python setup.py sdist, copy it into ~/launchpad/lp-branches/download-cache/dist, commit, push.
[04:12] <wgrant> Then create an LP branch updating versions.cfg.
[04:24] <lifeless> ahhha
[04:24] <lifeless> finally got it all figured out
[04:24] <lifeless> so
[04:24] <lifeless> rendering an exception is done with db access turned off
[04:24] <lifeless> the first few lines of handleException
[04:24] <lifeless> and base-layout is used there, so my change to base-layout triggers the flag lookup
[04:41] <poolie> bug expiry just restarted
[04:41] <poolie> or at least, it just got around to projects i'm watching
[04:41] <huwshimi> wgrant: What were you saying the other day about not having a wrapping element on tal conditions?
[04:41] <wgrant> poolie: I thought it was restricted to ubuntu. Maybe that changed in the last few days.
[04:42] <poolie> it just hit bzr
[04:42] <wgrant> poolie: And LP.
[04:42] <wgrant> huwshimi: Any element in the tal: namespace will be omitted from the rendering.
[04:42] <poolie> since we told people about it in http://blog.launchpad.net/general/enabling-automatic-bug-expiry ah about 3 months ago, maybe we should tell them now?
[04:44] <huwshimi> wgrant: ok thanks
[04:45] <wgrant> poolie: Do you know how I create an sdist with pyrex already compiled to C?
[04:46] <poolie> i think so but i'm not sure
[04:47] <wgrant> Oh.
[04:48] <wgrant> The one in download-cache at the moment appears to not be an sdist at all.
[04:48] <wgrant> Perhaps it is a manually created tarball.
[04:48] <wgrant> thumper: Around?
[04:58] <poolie> wgrant, my run under lucid of 2.2-lp completed with some thread leaks, one failure due to not having python-dev installed, and no other problems
[04:58] <poolie> also i sent that branch to pqm for our 2.2
[04:58] <wgrant> Thanks.
[05:05] <wgrant> poolie:
[05:05] <wgrant> -17 04 * * * $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/expire-bugtasks.py -l 200 --ubuntu >> /srv/launchpad.net/production-logs/expire-bugtasks.log 2>&1
[05:05] <lifeless> grr
[05:05] <wgrant> +17 04 * * * $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/expire-bugtasks.py >> /srv/launchpad.net/production-logs/expire-bugtasks.log 2>&1
[05:05] <lifeless> now a DoomedTransaction
[05:05] <wgrant> Last night.
[05:06] <poolie> ?
[05:06] <poolie> they took of the size limit and the limit to ubuntu
[05:06] <poolie> but now it's doomed because it's too big?
[05:07] <spm> poolie: yo
[05:08] <poolie> wgrant, that's lp-production-configs or something?
[05:08] <wgrant> poolie: lp-production-crontabs
[05:08] <wgrant> lifeless' doom is unrelated.
[05:09] <poolie> :)
[05:10] <wgrant> Codehosting tests, please stop messing with my dev branches...
[05:12] <poolie> wgrant, sanity check of http://blog.launchpad.net/?p=1925
[05:12] <poolie> spm, hi, i'm happy to go through the lp-serve rollout dry run whenever you are
[05:12] <spm> poolie: lets make it so
[05:12] <wgrant> poolie: I can't see it.
[05:13] <poolie> wgrant, how about if you click log in?
[05:13] <poolie> in the top right
[05:13] <wgrant> I didn't even know there was a login link.
[05:13] <wgrant> But so there is.
[05:14] <wgrant> No, it still hates me.
[05:14] <wgrant> Doesn't use LP teams.
[05:14] <poolie> huh
[05:14]  * poolie tries
[05:14] <wgrant> I can log in.
[05:14] <wgrant> But I have no privs.
[05:14] <poolie> win
[05:14] <poolie> now you should
[05:15] <wgrant> So I do.
[05:16] <wgrant> poolie: Looks good.
[05:16] <wgrant> Could you do it last night? :)
[05:17] <lifeless> wgrant: no, its very related.
[05:17] <lifeless> wgrant: if a db request expires the transaction is doomed
[05:17] <lifeless> *as well* as requestexpired getting raisde.
[05:17] <poolie> thanks
[05:17] <wgrant> lifeless: This is related to the unchoking of expire-bugtasks.py?
[05:17] <poolie> hahaha
[05:18] <poolie> i can _pretend_ i did it last night, does that help? :-)
[05:18] <poolie> iwbn to have had whoever committed that change do it
[05:18] <lifeless> wgrant: no, getting the render time patch landed
[05:18] <wgrant> Yes.
[05:18] <wgrant> lifeless: Right.
[05:18] <wgrant> lifeless: So it's not related.
[05:19] <lifeless> wgrant: its related to the thing I have been whining about
[05:19] <lifeless> wgrant: when I said 'now a DoomedTransaction' it was following that thread.
[05:20] <wgrant> lifeless: Right, but you said that right after my expire-bugtasks.py diff, which seemed to confuse poolie that it was related.
[05:21] <lifeless> oh
[05:21] <spm> poolie: do you have some docco on the process for the lp-serve rollout lying around somewhere? or is it buried in the losa wiki and I need to search harder?
[05:21] <lifeless> you were not speaking to me in saying it was unrelated
[05:21] <lifeless> gotcha
[05:21] <wgrant> lifeless: Yeah, "'", not ":".
[05:21] <poolie> spm, there's an rt linked from unusual rollout requests
[05:21] <spm> Ahh. ta
[05:22] <poolie> if it's missing anything i'm happy to add it but i'd rather you read it than me just tell you
[05:22] <poolie> so we have docs
[05:22] <spm> wfm
[05:24] <spm> oh. gah. face. palm. for some reason I had it fixed in my head this was the debian import system whatsist on jubany. lalalalalala
[05:31] <poolie> nup
[05:31] <poolie> we're going to do that on the 1st of March
[05:31] <poolie> happy to talk about how that will happen, but this other one is more pressing
[05:31] <wgrant> Where's it moving to?
[05:34] <poolie> we're moving machine from jubany to pepo
[05:34] <poolie> and we're aiming to do all operations through remote losa arms at the same time
[05:34] <wgrant> Excellent.
[05:35] <poolie> rt 39614 if you're curious
[05:35] <poolie> but the ticket's a bit of a saga
[05:37] <spm> the good ones usually are
[05:39] <lifeless> thumper: still around per chance ?
[05:40] <lifeless> wgrant: I'd like to borrow your eyeballs
[05:40] <lifeless> wgrant: can you look at the tip of lp:~lifeless/launchpad/showtimes and see if it makes sense to you
[05:41] <lifeless> 12342
[05:42] <wgrant> lifeless: The tip rev in particular, or all the changes?
[05:42] <lifeless> tip rev
[05:42] <lifeless> you can eyeball more if you want, but thats all reviewed yada yada yada
[05:43] <lifeless> base-layout.pt is (sadly) used in error rendering.
[05:43] <lifeless> so changes there tend to trigger nasty interactions with publication
[05:50] <wgrant> lifeless: You elide the features and scopes because they are now being queried?
[05:50] <lifeless> wgrant: if the request has expired, I return no rules
[05:51] <wgrant> lifeless: Right, I see that.
[05:51] <wgrant> But I'm wondering why you elide them now.
[05:51] <wgrant> Because some show up with None?
[05:52] <wgrant> It looks fine, just want to be sure.
[05:52] <lifeless> oh, in the other tests
[05:52] <lifeless> because the feature visible_render_times shows up now
[05:52] <lifeless> and thats not very interesting to those tests
[05:52] <lifeless> other features in future would also be uninteresting
[05:52] <wgrant> Right.
[05:52] <wgrant> Looks fine, then.
[05:53] <lifeless> thanks for the yeeballs
[05:54] <wgrant> lifeless: I was just going to ask you to do that review.
[05:54] <wgrant> But you are too efficient :(
[05:55] <lifeless> ok, render time on page -> ec2; me -> shops
[06:06] <lifeless> stub: hi
[06:07] <wgrant> lifeless: You fail at shopping.
[06:07] <lifeless> wgrant: EWIFE
[06:07] <wgrant> Or you are exceptionally good.
[06:07] <lifeless> wgrant: I will be shopping soon
[06:07] <wgrant> Ah.
[06:08] <LPCIBot> Yippie, build fixed!
[06:08] <LPCIBot> Project db-devel build (350): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/db-devel/350/
[06:10] <lifeless> woo
[06:10] <lifeless> At least 110 queries/external actions issued in 8.12 seconds
[06:10] <lifeless> for a search for kpassgen on qastaging /ubuntu
[06:10] <wgrant> Excellent.
[06:10] <lifeless> terrible cold cache effects still
[06:10] <lifeless> we're going to need to do something about that eventually
[06:11] <lifeless> wgrant: did bug 709717 make any practical difference ?
[06:11] <_mup_> Bug #709717: Archive:+index timeouts : ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <qa-ok> <timeout> <Launchpad itself:Fix Released by julian-edwards> < https://launchpad.net/bugs/709717 >
[06:13] <stub> lifeless: yo
[06:13] <wgrant> lifeless: Impossible to say without a new copy archive.
[06:14] <lifeless> stub: flacoste has suggested you and I setup a weekly catchup voice call; do you have any sort of preference for when such a call would happen?
[06:15] <stub> later in the week so I might actually remember what I've done, nearing end of your official work day probably best
[06:16] <lifeless> thursday avo?
[06:16] <stub> sure
[06:16] <lifeless> I'll send a calendar thingy in a bit
[06:16] <stub> I'm happy with a flexible time too
[06:16] <stub> So 'thursday arvo' is fine.
[06:17] <lifeless> ok; I'll send a calendar thing anyhow cause that will remind me; we can always fudge it on the day
[06:18] <stub> One day I'll recover that password...
[06:19] <lifeless> heh
[06:19] <lifeless> #is can do that
[06:34] <poolie> wgrant, pass/fail/don't know?
[06:35] <wgrant> poolie: On what?
[06:36] <poolie> the bzr rollout
[06:37] <poolie> the fix for 71500
[06:37] <poolie> 715000
[06:37] <wgrant> It's in ec2. It may not be QA'd in time for the release, but if not we can nodowntime to loganberry later tomorrow.
[06:37] <poolie> ok
[06:38] <poolie> if/once it gets through ec2, will it automatically deploy, or will a losa just deploy it?
[06:38] <wgrant> Once it's QA'd someone will request a deployment.
[06:39] <wgrant> Given the timing I will probably not be awake in time to QA it, so it probably won't make the downtime rollout tomorrow.
[06:39] <lifeless> matsubara-afk is doing deploy requests, wgrant does them, I do them... we all do them.
[06:39] <poolie> sure
[06:40] <wgrant> Hah, the last three have been me.
[06:40] <poolie> i just wondered if/when i should try to test it or request deployment
[06:40] <lifeless> by which I mean it won't hang around long
[06:40] <wgrant> It should be on qastaging in 10 hours.
[06:41] <wgrant> Then it needs somehow to push up an appropriate branch configuration, and a LOSA to run scan_branches.py
[06:41] <wgrant> s/somehow/someone/
[06:42] <wgrant> In the likely even that it's not QA'd before the release, I will QA it during the release and we can release again a couple of hours later :)
[06:42] <wgrant> And then we can switch jubany back on and wait for more explosions, and then work out how to retry all the scan failures.
[06:42] <wgrant> And the import failures.
[06:43] <wgrant> And then resolve the next batch of wheezy-related fun.
[06:44] <lifeless> http://searchengineland.com/google-proposes-to-make-ajax-crawlable-27408
[06:45] <wgrant> lifeless: EAYEARAGO
[06:46] <lifeless> I'm old school
[06:46] <lifeless> wgrant: linked from http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
[06:47] <wgrant> Heh
[06:50] <wgrant> Woah.
[06:52] <wgrant> The universal Gawker redesign is, uh, special.
[07:08] <lifeless> indeed
[07:08] <wgrant> I see that the ui= curse continues.
[07:09] <lifeless> weren't you fixenating?
[07:09] <wgrant> I fixed the commit message thing last week, yes.
[07:09] <poolie> do you know off hand a good branch that's nontrivially doubly stacked?
[07:09] <wgrant> But I refer to the ui reviewer blight, which causes graduated UI reviewers to leave the LP team.
[07:09] <wgrant> poolie: lp:ubuntu/lucid/bzr
[07:10] <lifeless> wgrant: causes?
[07:10] <wgrant> lifeless: Well, all our graduated UI reviewers except one or two have left the LP team.
[07:11] <wgrant> And it just happened again, which is a little sad.
[07:11] <lifeless> correlation != causation
[07:11] <poolie> spm thanks for your mail on rt43743
[07:11] <poolie> do you need anything else?
[07:11] <wgrant> lifeless: I summise otherwise :P
[07:11] <spm> I swaer I only pressed "reply" a couple of microseconds ago....
[07:12] <spm> poolie: if we can get the configs formally landed that'd be a big plus.
[07:25] <wgrant> Can I somehow tell doctest ellipsis to not cross linebreaks?
[07:46]  * huwshimi heads off
[07:50] <lifeless> wgrant: possibly with doctest flags
[07:53] <LPCIBot> Project devel build (426): FAILURE in 6 hr 5 min: https://hudson.wedontsleep.org/job/devel/426/
[07:53] <LPCIBot> * Launchpad Patch Queue Manager: [r=thumper, wallyworld][ui=none] [r=thumper, wallyworld][bug=661988,
[07:53] <LPCIBot> 714312] Reduce the time taken for distro scope bug searches by 50% by
[07:53] <LPCIBot> using sequence-of-sets based eager loading rather than
[07:53] <LPCIBot> wide-query eager loading. As part of making this fit cleanly
[07:53] <LPCIBot> stop loading assignees during bug task search (they are not
[07:53] <LPCIBot> rendered so not needed).
[07:53] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=713392] make the +structural-subscriptions UI correctly
[07:53] <LPCIBot> show the effect of an event filter setting.
[07:53] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][no-qa] Use itertools.tee() to simplify and speed up
[07:53] <LPCIBot> CachingIterator.
[07:53] <LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett, sinzui][ui=none][bug=344125,
[07:53] <LPCIBot> 712012] Remove obsolete method Bug.addChangeNotification().
[07:53] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][no-qa] test, tweak, and exercise the dbuser test helper
[08:27] <lifeless> wgrant: btw, FYI - lp:~lifeless/launchpad/bug-704446 - has the reindex fix
[08:34] <adeuring> good morning
[08:44] <jtv1> hi adeuring
[08:44] <adeuring> hi jtv!
[08:50] <jtv> hi lifeless!
[08:51] <jtv> lifeless: you recommended getting a ++profile++ on qastaging, but the docs still suggest that that's impossible.  Need updating?  https://dev.launchpad.net/Debugging
[08:53] <lifeless> jtv: requires losa intervention to turn it on (and then off)
[08:53] <jtv> lifeless: both staging and qastaging?  (Asking so I can update the wiki)
[08:53] <lifeless> yes; if you want a reference, see some of my early performance tuesday mails
[08:54] <jtv> Thanks.
[09:09] <mrevell> Hello all.
[09:11] <Ursinha> good morning, launchpad
[09:20] <allenap> jtv: Good morning. Ready for a review? https://code.launchpad.net/~allenap/launchpad/use-zope-tb-formatter/+merge/48843 :)
[09:21] <jtv> hi allenap!
[09:21] <jtv> allenap: we do have the call first.  :)
[09:22] <allenap> jtv: Yeah, you've got 8 minutes! ;)
[09:22] <jtv> uh-oh
[09:38] <bigjools> bloody full-stop nazis
[09:45] <wgrant> bigjools: Hey, this isn't in a comment!
[09:45] <bigjools> it's also only a warning banner!
[09:46] <wgrant> And bad punctuation in the UI looks shit.
[09:46] <wgrant> We should try to avoid it :)
[09:47] <bigjools> no, you don't always need to use them
[09:47] <wgrant> All notifications I've seen do. And this one has paragraphs after it, so it's even more convincing.
[09:47] <bigjools> phrases don't need them
[09:47] <bigjools> check the code again
[09:48] <lifeless> night all
[09:48] <bigjools> nn lifeless
[09:49] <wgrant> Night lifeless.
[09:50] <wgrant> bigjools: Ah. So it will occasionally be "Publishing has been disabled for this archive Note: since this archive is private, no builds will be dispatched." (no linebreak, since addNotification wants HTML)
[09:50] <bigjools> le sigh
[09:51] <wgrant> HTML is fun :D
[09:51] <bigjools> fsvo
[09:54] <bigjools> when using ec2 land it's extremely disconcerting for it to pop up a gnome-keyring password dialog when I don't use gnome-keyring
[09:56] <wgrant> fd.o really should standardise keyrings.
[09:57] <bigjools> yes
[09:58] <bigjools> we can just use kwallet
[10:00] <bigjools> ARGH, why does ec2 land amend the commit message on lp, when lp-land doesn't ....
[10:06] <jtv> allenap: in test_logger.py, is the boilerplate at the end of the test still really needed?
[10:06]  * allenap looks
[10:06] <jtv> The test_suite() stuff
[10:07] <allenap> jtv: I think so, for the doctest.
[10:07] <jtv> ahh
[10:07] <jtv> nm then
[10:39] <jtv> allenap: isn't [0, 1, 2, 3, 4] more easily written as range(5)?
[10:40] <jtv> (Serves you right for fixing all that lint :)
[10:40] <jtv> allenap: also, from the diff:
[10:40] <jtv> 213+        # The local variable __traceback_info__ is set by `traceback_info`.
[10:40] <jtv> Easier to avoid passive voice I think.
[10:41] <allenap> jtv: otp, back soon.
[10:54] <allenap> jtv: Regarding range(5). Yeah, it's a bit shorter, but it's slightly less readable, in my mind anyway, and range() returns an iterator in Python 3.
[10:55] <jtv> Fair enough.  Anyway, I had voted already.  :)
[10:56] <allenap> jtv: Thank you :)
[10:56] <allenap> jtv: Fancy another?
[10:56] <jtv> Oh yes, please, make me work!
[10:56] <jtv> :)
[10:56] <allenap> jtv: https://code.launchpad.net/~allenap/launchpad/cw-bugzilla-sniffing-expat-errors/+merge/48985
[10:56] <allenap> :)
[11:08] <jtv> allenap: nice grammar… "because they require that none be in progress."
[11:08] <jtv> Does TestBugzillaSniffing really need DatabaseFunctionalLayer though?
[11:10] <allenap> jtv: I tried it with no layer and it got grumpy. Perhaps there is a lighter layer I could use, but I'm not good at knowing which one. I tend to try them haphazardly until the test works and isn't too slow.
[11:10] <jtv> allenap: sounds about right… I was thinking maybe the ZopelessLayer or something?
[11:11] <allenap> jtv: I'll give that a go.
[11:11] <jtv> thanks
[11:12] <jtv> allenap: also, I'm no expert at python method binding but…
[11:12] <jtv> 280+            response.geturl = lambda: req.get_full_url()
[11:12] <jtv> …looks sort of equivalent to
[11:12] <jtv>         response.geturl = req.get_full_url
[11:13] <allenap> jtv: Ah yes, I noticed that and meant to change it. Will do.
[11:13] <jtv> Excuses, excuses.
[11:15] <jtv> allenap: meanwhile, you have my vote.
[11:15] <allenap> jtv: Thanks :)
[11:25] <allenap> jtv: ZopelessLayer works a treat, thank you.
[11:25] <jtv> Great!
[11:25] <jtv> Anbd for that, I award myself a cup of coffee.
[11:26] <jtv-afk> Damn, can't use ☕ in a nick.
[11:38] <adeuring> henninge: do you have to talk about but 702468?
[11:54] <jtv> adeuring: are you asking him whether he has _time_ to talk about bug 702468?  Or asking him to stop talking about it?  :-)
[11:54] <_mup_> Bug #702468: First upstream translation does not replace Ubuntu-only translation <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702468 >
[11:54] <adeuring> jtv: yeah, that's what I meant ;)
[11:55] <adeuring> but I think I'll start my lunch break first.
[11:58] <deryck> Morning, all.
[12:01] <jtv> hi deryck
[13:35] <henninge> adeuring: Hi. Sorry for replying so slowly.
[13:35] <adeuring> henninge: mo problem,. I think I answered my question myself meanwhile ;)
[13:35] <henninge> adeuring: oh, cool ;-)
[13:36] <henninge> adeuring: how/where are you going to fix it?
[13:36] <henninge> adeuring: Are you touching POTMsgSet.setCurrentTranslation?
[13:36] <henninge> i.e. _setTranslation
[13:36] <adeuring> henninge: right.
[13:37] <adeuring> this bug is just a special case for the '*' option.
[13:37] <henninge> sounds like the right place.
[13:37] <henninge> oh cool, you got into the matrix ... ;)
[13:37] <henninge> jtv: Hi!
[13:38] <henninge> jtv: Did you know that your description of the decision matrix in the comment in _setTranslation is truncated?
[13:38] <henninge> I always thought I should try and figure out what is missing there exactly.
[13:39] <henninge> adeuring: Did you notice that?
[13:39] <adeuring> no...
[13:57] <bac> hi bigjools, can you and i have a 10 minute mumble so i can ask you questions about bug mail subscriptions?  you are rumored to have some strong opinions (shock).
[13:58] <bigjools> bac: scurrilous rumours!  Sure thing.
[13:58] <bac> bigjools: nowish?
[13:58] <bigjools> I'm in yer mumble room
[13:59] <LPCIBot> Yippie, build fixed!
[13:59] <LPCIBot> Project devel build (427): FIXED in 6 hr 6 min: https://hudson.wedontsleep.org/job/devel/427/
[13:59] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=714527] Properly escape labels in suggestion widgets.
[13:59] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=50616] Catch the ValueError while validating
[13:59] <LPCIBot> image file.
[14:07] <jtv> henninge: back from lunch… no, I did not realize that or I would have fixed it!
[14:13] <abentley> jtv, aren't you EOD?
[14:14] <jtv> abentley: different tz
[14:14] <abentley> jtv, Ah, cool.
[14:26] <jtv> henninge: far as I can make out, I never completed that comment!
[14:26] <henninge> oic
[14:47] <leonardr> jcsackett, i'm very confused by the problem about which you sent me email
[14:47] <leonardr> can you tell me what http requests are being sent out?
[14:48] <jcsackett> leonardr: hurray, i can actually use IRC today. one second.
[14:56] <jcsackett> leonardr: https://pastebin.canonical.com/43026/, but that's not showing responses, i believe i set the wrong debuglevel.
[14:57] <leonardr> jcsackett: so it follows the redirect, and then the thing at the other end of the redirect is weird?
[14:58] <bigjools> what's the right place to file a bug on our landing tools? (ec2 land and bzr lp-land)
[15:00] <leonardr> ah, i see the problem. the redirect is not a redirect to the web service
[15:00] <leonardr> it's a website redirect
[15:00] <jcsackett> leonardr: right, it's a redirect from the alias for the product to the actual product.
[15:01] <leonardr> but the redirect switches layers
[15:01] <leonardr> it should send you to api.launchpad.net/1.0/gdp and it sents you to launchpad.net/gdp
[15:01] <jcsackett> ah,yes. okay.
[15:02] <leonardr> i'm not sure how that results in an oops--that looks like a different problem
[15:02] <jcsackett> well, the OOPS that occurs is when you then try to file a bug after that redirect.
[15:02] <jcsackett> and lazr/launchpadlib says "i have no idea what you want me to do here."
[15:03] <leonardr> jcsackett: but the first redirect caused an exception. what are you filing a bug on?
[15:03] <jcsackett> i'm not filing a bug, i'm looking at bug 623099
[15:03] <_mup_> Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/623099 >
[15:04] <jcsackett> oh, you mean via the api.
[15:04]  * jcsackett has not had enough coffee yet.
[15:04] <leonardr> yeah
[15:06] <leonardr> here's what i think is happening
[15:06] <leonardr> you assign lp.projects['geditdevplugins'] to a variable and then try to file a bug on it
[15:06] <bigjools> allenap: did you want another call about the "fail a build" button?
[15:06] <leonardr> there's an exception when launchpadlib tries to resolve the reference, but you catch it or ignore it somehow
[15:07] <leonardr> then you file a bug on the variable
[15:07] <leonardr> so you POST to /1.0/geditdevplugins, or you post to /bugs and reference /1.0/geditdevplugins
[15:07] <leonardr> and when lazr.restful tries to resolve /1.0/geditdevplugins *internally*, you get the oops
[15:08] <jcsackett> leonardr: that makes sense and jives with my thinking.
[15:08] <jcsackett> incidentally, if you just execute "var = lp.projects[alias]" and then don't try to use the alias, nothing happens, exception wise; which might explain the issue with no exception in grabbing the product.
[15:08] <leonardr> jcsackett: yes, you get a shim object
[15:08]  * jcsackett nods.
[15:09] <leonardr> and if you try to use the object on the client side, you get an exception on the client side
[15:09] <leonardr> but you're sending it off to the server side
[15:10] <leonardr> so, we need to force the resolution to happen on the client side, so we send the right url
[15:10] <leonardr> or we need to make the server side capable of understanding the redirect
[15:10] <leonardr> and then there's this *other* problem where /1.0/geditdevplugins redirects you outside the web service
[15:12] <jcsackett> leonardr: dig. and that needs to be fixed server side.
[15:12] <leonardr> yeah, in launchpad
[15:14] <leonardr> i'll summarize in the bug
[15:14] <jcsackett> leonardr: thanks. i'm glad to know i'm dealing with two bugs--i was starting to be slightly confused.
[15:29] <leonardr> jcsackett, bug updated
[15:29] <jcsackett> leonardr: dig. and thanks again.
[15:31] <allenap> bigjools: I'm going to spend a few minutes looking at the code, but I'd love to talk after that.
[15:33] <dobey> so i just got an e-mail from LP with an OOPS id in it
[15:33] <dobey> OOPS-1866MPJ3
[15:33] <dobey> i guess LP doesn't like making a merge proposal against a branch which has 0 revisions :)
[15:43] <bigjools> allenap: ping when when you're ready then
[16:39] <leonardr> i have a stupid question: how can i get my launchpad install to use the non-compressed javascript? i thought it used to do that by default in dev mode, but not anymore?
[16:41] <jml> leonardr: I recall Tim asking something similar on the mailing list.
[16:42] <jml> leonardr: https://lists.launchpad.net/launchpad-dev/msg06358.html -- not that helpful, but it's there.
[16:43] <leonardr> thanks, i remember that message from tim but not any followup
[16:46] <jml> deryck followed up, but it was more along the lines of "here's what we could do to make this better", rather than "Oh, you forgot to flick the 'make it work' switch"
[16:47] <deryck> there is no switch
[16:47] <deryck> jml, leonardr, a not nice but possible solution is find and replace "-min.js" with ".js" in utilities/yui-deps.py or utiltities/lp-deps.py and run make jsbuild again.
[16:48] <deryck> I've trimmed the ginormous load of js files in my recent yui upgrade to make enabling a devmode flag a possibility again.
[16:50] <lifeless> deryck: please no
[16:51] <jcsackett> leonardr: so, in testing, there's no way to get a product via alias. you just get a key error. thoughts?
[16:51] <deryck> lifeless, why not?
[16:51] <jcsackett> this is using launchpadlib_for from lp.testing
[16:51] <lifeless> deryck: or rather, if you do, let me know so I reopen the bugs I had with devmode
[16:51] <lifeless> deryck: with devmode, js wouldn't work for me locally
[16:51] <deryck> lifeless, ah, ok.  interesting.
[16:51] <lifeless> deryck: and all the fragments got redownloaded on every page
[16:51] <leonardr> jcsackett: what code are you running? i can't visualize
[16:51] <Ursinha> allenap, hi, is bug 714820 In Progress/Fix Committed?
[16:51] <_mup_> Bug #714820: Many ExpatErrors from checkwatches <oops> <Launchpad itself:Triaged by allenap> < https://launchpad.net/bugs/714820 >
[16:52] <deryck> lifeless, ok.  And I'm not saying we have to do it this way either.  but we need something in devmode to use non-minified files at least.
[16:52] <deryck> just that with 45 instead of 450 files, it's a bit better to do again ;)
[16:53] <lifeless> can I suggest that such a mode be opt-in
[16:53] <lifeless> that by default we want to be as close to prod as possible
[16:55] <deryck> yes, definitely agree there.
[16:55] <deryck> the current js build is cleaner anyway, since it's not sniffing templates for files, too.
[16:56] <jcsackett> leonardr: https://pastebin.canonical.com/43051/
[16:57] <allenap> Ursinha: I think it's committed.
[16:57] <allenap> Ursinha: Nope, it's not... just a moment.
[16:58] <Ursinha> sure
[16:59] <allenap> Ursinha: Ah, the branch is at the end of the PQM queue.
[16:59] <Ursinha> cool, so it's at least In Progress :)
[16:59] <allenap> Ursinha: Ah yes :) Oops. Thanks
[17:00] <Ursinha> allenap, no problem :) I'm asking because if that wasn't in progress I'd mention it in the TLs meeting
[17:00] <Ursinha> thanks!
[17:10] <leonardr> jtv or abentley, can i get you to review a little javascript? https://code.launchpad.net/~leonardr/launchpad/use-web-link/+merge/48991
[17:10] <jtv> leonardr: sure
[17:10] <jtv> (Last one for the day)
[17:12] <sinzui> jcsackett: Do you have time to discuss a bug I am working after 1:00 PM?
[17:12] <jcsackett> sinzui: sure.
[17:13] <jcsackett> say, 1:15?
[17:13] <sinzui> okay
[17:13] <jtv> leonardr: I suppose there's no legitimate scenario where web_link is not present?
[17:14] <leonardr> jtv: i'm pretty sure not, since the whole point of this thing is that you are at a web page corresponding to some object
[17:14] <leonardr> and that's the scenario under which web_link will be present--if there's some web page corresponding to this object
[17:14] <leonardr> but if it should happen, i put in code to do nothing instead of crash
[17:14] <Ursinha> https://bugs.launchpad.net/loggerhead/+bug/701329
[17:14] <_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
[17:16] <jtv> Ursinha: I looked at that one, and ISTM it's really two bugs in one: dealing better with socket breakage is one, but another is stopping after a HEAD request.  I wonder if sitting around trying to send a body would tie up a connection.
[17:16] <sinzui> jcsackett: Here is the background on the issue: http://pastebin.ubuntu.com/565072/
[17:16] <jcsackett> sinzui: dig.
[17:17] <jcsackett> leonardr: have you had a chance to look at the paste i sent you?
[17:17] <leonardr> jcsackett: sorry, looking now
[17:17] <jcsackett> leonardr: no worries. :-)
[17:18] <jtv> leonardr: done
[17:19] <Ursinha> jtv, as you have deeper knowledge than I do, could you add a comment in that bug mentioning that, please? :)
[17:20] <jtv> Ursinha: me and my big mouth ☺ Will do.
[17:20] <Ursinha> hahahaha
[17:20] <Ursinha> thanks!
[17:24] <leonardr> jcsackett: 1. set httplib2.debuglevel = 1 and see what requests, if any, are being sent
[17:24] <leonardr> 2. does lp.projects['lemur'] work?
[17:24] <jcsackett> lp.projects['lemur'] does work.
[17:24] <jcsackett> debuglevel gets me nothing, just the keyerror.
[17:25] <jcsackett> leonardr, i seem to recall once being told that launchpadlib did some tricks in testing mode rather than always making requests. think this might be running up against that?
[17:25]  * jcsackett is considering just using WebServiceCaller.
[17:25] <leonardr> jcsackett: uh, it may not be going through httplib2, that's true
[17:26] <leonardr> it may be using a webservicecaller or something behind the scenes
[17:26] <jcsackett> leonardr: okay. since for purposes of this issue it's all about the server sending the correct 301, and less about lplib behavior, i guess i can use the caller and check the repsonses instead of the lplib returned objects.
[17:26] <leonardr> jcsackett: that might be easier
[17:27] <jcsackett> leonardr: okay, thanks.
[17:27] <jcsackett> sooner or later i will have asked you so many questions i might actually know how this all works. yay domain knowledge transfers. :-P
[17:46] <lifeless> flacoste: hi
[17:46] <flacoste> hi lifeless
[17:46] <lifeless> flacoste: got time for a brief call on capacity ?
[17:46] <flacoste> (was about to go for lunch)
[17:46] <flacoste> lifeless: i read the update to the ticket
[17:47] <flacoste> lifeless: but we could catch-up later
[17:47] <lifeless> which ticket ?
[17:47] <lifeless> after lunch should be fine; have to take lynne into hospital 4 hours from now
[17:47] <flacoste> lifeless: ok
[18:01] <bigjools> allenap: you have some interesting test data in your tests :)
[18:07] <lifeless> https://qastaging.launchpad.net/ubuntu - 145 queries!
[18:10] <jcsackett> sinzui: i can mumble now, if you like.
[18:11] <sinzui> jcsackett: I will get a drink
[18:11] <jcsackett> sinzui: gid.
[18:11] <jcsackett> er, dig.
[18:28] <Ronnie> is there a short way to get all the admins (which are not teams) of a lp_team recursively. Currently i created http://paste.ubuntu.com/565096/ but it takes a lot of launchpadlib calls
[18:31] <lifeless> get_team_members_r is replacable by the participation call
[18:34] <Ronnie> is participants fully recursive?
[18:36] <lifeless> IIRC yes
[18:37] <lifeless> what do you need to figure the administrators out for though ?
[18:37] <lifeless> as in, whats the use case
[18:44] <Ronnie> in the loco-directory to give the people the rights they need
[18:50] <lifeless> so wouldn't a query 'is foo an admin of bar
[18:50] <lifeless> '
[18:50] <lifeless> be a better thing to have?
[19:02] <leonardr> thumper, i filed bug 715990 because i don't think the other web_link hack is worth removing right now
[19:02] <_mup_> Bug #715990: Remove self_link -> web_link hack in bugtask_index.js <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/715990 >
[19:08] <Ronnie> lifeless: its an regular update script, so we do not have to retrieve info from LP on user page load
[19:09] <lifeless> Ronnie: we should be able to answer a question like that in ~ 40ms
[19:09] <lifeless> Ronnie: so doable on page load if you wanted.
[19:09] <lifeless> I -very much- want to get away from 'nightly updates' - its horribly inefficient
[19:10] <Ronnie> ah, that explains the question ...
[19:12] <Ronnie> lifeless: the thing is, that on most pages, we need info from multiple teams, so that should take too much time i guess
[19:13] <lifeless> well
[19:13] <lifeless> we could answer for multiple teams, if you can clearly describe the check that is needed
[19:13] <Ronnie> lifeless: on each page different :(
[19:13] <lifeless> Ronnie: thats fine, its how we figure things out
[19:14] <lifeless> we don't have to do this now
[19:14] <lifeless> its a long term transition; we need an event system, we need targeted APIs, we need launchpadlib to be concurrency-safe
[19:17] <Ronnie> an event system could indeed be better
[19:17] <Ronnie> or "show changes of teams since"
[19:19] <Ronnie> lifeless: is latter an good idea ^ to brainstorm further?
[19:19] <lifeless> that might be a useful api as well
[19:20] <Ronnie> i think its easier to implement than events (which are realtime)
[19:21] <lifeless> we do have a teammembership datestamp
[19:21] <flacoste> lifeless: skype me when you want to chat capacity
[19:27] <thumper> leonardr: ok
[19:27] <thumper> deryck: I'd like to talk to you about how we do lazr-js releases into LP
[19:28] <deryck> thumper, ok.  I really want to get this current update up for review first.
[19:28] <deryck> thumper, Can we IRC chat it, or wait until I'm done for voice?
[19:29] <deryck> FWIW, I've quit worry about incrementing the version in lazr-js and just rolling a new tarball from trunk, with a revno string.
[19:29] <deryck> if that makes things faster for you.
[19:29] <thumper> deryck: is there a make target for that?
[19:30] <deryck> thumper, for building a tarball from lazr-js trunk?
[19:31] <thumper> yeah, to make sure we get all we need and nothing we don't
[19:32] <deryck> thumper, no, I just do `python setup.py egg_info -b-r202 sdist` to get a new tarball and copy to download-cache
[19:32] <deryck> where -r202 represents the current revno.
[19:32] <thumper> is that documented anywhere in the lazr-js docs?
[19:35] <deryck> thumper, no, I learned this from doc/buildout.txt in the launchpad source.
[19:35] <deryck> but it's really secret knowledge BjornT_ passed on to me, I think. ;)
[19:44] <Ursinha> lifeless, hey, do you know if bug 702819 was released in a nodowntime rollout? I still see oopses
[19:44] <_mup_> Bug #702819: Log parser should skip lines raising InvalidURIError <lp-soyuz> <oops> <qa-ok> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/702819 >
[19:44] <lifeless> no, it needs downtime
[19:45] <Ursinha> lifeless, so why is that marked as Fix Released?
[19:45] <lifeless> Ursinha: it may be a new bug
[19:45] <thumper> deryck: how has the lazr-js updating going?
[19:45] <lifeless> flacoste: https://lpstats.canonical.com/graphs/GandwanaCPU/
[19:46] <deryck> thumper, proposing for merge now.
[19:47] <Ursinha> I'll ask wgrant later, thanks
[19:47] <thumper> deryck: cool
[19:47] <thumper> deryck: if you have a few minutes, I'd like to chat about my upcoming changes for lazr-js
[19:47] <lifeless> flacoste: https://lpstats.canonical.com/graphs/PotassiumCPU/
[19:47] <deryck> thumper, sure.  When I'm done with this.
[19:48] <lifeless> https://lpstats.canonical.com/graphs/PalladiumCPU/
[19:52] <deryck> hmmm, who wants to review a largish lazr-js upgrade? :-)
[19:52] <deryck> flacoste, could you spare the time maybe? ^^
[19:53] <flacoste> deryck: i could
[19:53] <deryck> flacoste, thanks!  https://code.launchpad.net/~deryck/launchpad/update-lazr-js-yui-3-3/+merge/49122
[19:55] <deryck> thumper, voice or irc?
[19:55] <thumper> deryck: voice would be better
[19:55] <thumper> mumble?
[19:55] <deryck> sure
[20:08] <LPCIBot> Project devel build (428): FAILURE in 6 hr 9 min: https://hudson.wedontsleep.org/job/devel/428/
[20:08] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=715000] Upgrade to a bzr with a fix for the graph
[20:08] <LPCIBot> ancestry chained stacking issue.
[20:08] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][bug=715474] Permit showing server side render times in the
[20:08] <LPCIBot> visible page (controlled by feature flag visible_render_time).
[20:08] <maxb> I was thinking I'd try to learn some YUI. deryck's branch makes me think you don't learn YUI, you learn a particular minor version of YUI :-/
[20:09] <deryck> maxb, well dot releases in YUI are major upgrades.  Learn the current YUI. It has value on its own, and now we're current, too. ;)
[20:09] <thumper> maxb: YUI is worth learning I think
[20:12] <maxb> I'm somewhat convinced of that. Just looking for a good place to start _understanding_ more than the surface
[20:18] <mwhudson_> given that yui 2 and 3 are basically separate project, i guess the yui3 team have to have 3.x ->3.x+1 be major
[20:22] <deryck> maxb, the YUI 3 site has excellent docs.  I'd focus on the stuff under "Component Infrastructure"
[20:22] <lifeless> Ursinha: hi, sorry about fading away
[20:23] <deryck> maxb, then read "JavaScript, the good parts" and learn to think like Crockford.  YUI all makes perfect sense then. :-)
[20:23] <lifeless> Ursinha: I would file a new bug, and wgrant can eyeball  and see if its a previously hidden issue or a duple and the other hadn't been rolled out.
[20:25] <maxb> hmm. I think *finding* the bits of the YUI site you want to read is half the battle :-) I've read "JavaScript, the good parts" once, I should go back over it carefully.
[20:26] <deryck> maxb, yeah, that's why I suggested the stuff under the component infrastructure heading on the yui 3 homepage. :-)
[20:27] <maxb> ahhh.... you appear to have given me the magic words leading to the right place to start! thanks :-)
[20:29] <deryck> heh, np!
[20:30] <lifeless> deryck: hi
[20:30] <lifeless> deryck: I've replied to your nodowntime db mail, but if you want to talk more today it should be soon
[20:34] <deryck> lifeless, ok, saw it.  Thanks.  If it's not possible, it's not possible.  I don't think we need much beyond that for now.
[20:52]  * thumper runs to make a coffee before the standup
[20:58] <flacoste> deryck: how did you get the list of deps?
[20:59] <deryck> flacoste, I used the configuration tool on YUI 3's website.
[20:59] <flacoste> deryck: ack
[21:00] <flacoste> deryck: i think your change of root initialization in combine-css is broken
[21:00] <flacoste> deryck: it assumes the script is run for the root directory
[21:00] <flacoste> deryck: what's the problem with the buildout var?
[21:00] <deryck> flacoste, it would add a "./" in the middle of the path
[21:00] <flacoste> deryck: and i think a lazr-js change broke this, btw
[21:00] <flacoste> deryck: normpath would remove it
[21:01] <flacoste> deryck: probable that lazr-js / should call this
[21:01] <flacoste> deryck: but changing calling normpath around the buildout var would also work
[21:01] <flacoste> if you don't want to dig deeper
[21:01] <wallyworld_> thumper: stupid mic again
[21:01] <flacoste> which i would totally understand
[21:02] <deryck> I'll use normpath then, if you really don't care :-)
[21:02] <thumper> leonardr: mumble?
[21:03] <leonardr> thumper, yes
[21:03] <flacoste> deryck: r=me with that
[21:04] <deryck> flacoste, excellent, thanks!
[21:04] <flacoste> deryck: and great job trimming the dep list
[21:04] <deryck> thanks!  I was pretty happy about that, too.
[21:16] <deryck> And she's off to ec2.  Until tomorrow then!  Later, all!
[21:46] <huwshimi> Morning
[21:47] <benji> leonardr: are you aware of any docs about how to use LP.client.Launchpad() to interact with the web service from JavaScript?
[21:53] <leonardr> benji: no, i'm not, but it's been a looong time
[21:53] <benji> :) ok, thanks
[22:10] <wgrant> Ursinha-bbl: It was mistakenly closed. It will not be deployed for another couple of hours.
[22:21] <wgrant> gary_poster: Hi.
[22:40] <LPCIBot> Project db-devel build (353): FAILURE in 5 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/353/
[22:40] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12347
[22:40] <LPCIBot> included.
[22:45] <wgrant> sinzui, huwshimi: The large icons are not there any more.
[22:45] <wgrant> Will have to check history.
[22:47] <wgrant> Yay, nightly.sh now finishes in time.
[22:47] <wgrant> And logs properly.
[22:48] <wgrant> And there were no scriptactivity errors overnight!
[22:56] <poolie> jam: bug 716169 re the multiple mps
[22:56] <_mup_> Bug #716169: does not send mail on superseded proposals <code-review> <confusing-ui> <mail> <Launchpad itself:Triaged> < https://launchpad.net/bugs/716169 >
[22:56] <poolie> wallyworld_, there's no blog post about lp going offline? should there be?
[22:56] <jam> poolie: ?
[22:56] <poolie> re your question of "which of these should i review"
[22:56] <poolie> i think all but one was superseded
[22:56] <jam> ah, ok
[22:56] <poolie> but lp does not mail you to tell you
[22:57] <wallyworld_> poolie: i guess so. i posted to identi.ca. i'm not sure about the blog though
[22:57] <poolie> is there a policy?
[22:57]  * wallyworld_ checks but ssems to recall it only mentions identi.ca
[22:58] <poolie> we seem to have done so in the past
[22:58] <wallyworld_> poolie: wiki says "Re-announce downtime so it serves as a reminder on launchpadstatus account at least 4h before the actual rollout. You can do this yourself with the identi.ca login info. "
[22:58] <wallyworld_> no mention of a blog
[22:59] <wallyworld_> poolie: do you have details of the blog site - i've never been there.
[23:01] <poolie> ok, i posted
[23:02] <wallyworld_> poolie: thanks for that. url?
[23:02] <poolie> see pm
[23:02] <poolie> but, blog.launchpad.net would be a good guess :)
[23:03] <poolie> i posted
[23:03] <poolie> ah, i see mrevell did on http://blog.launchpad.net/notifications/launchpad-read-only-23-00-utc-9th-february-2011
[23:05] <jam> poolie: how often does the kanban board update? It would be a bit more satisfying if closing a bug actually cleared off the board, etc.
[23:06] <wallyworld_> poolie: thanks
[23:06] <poolie> jam, at the moment, from my laptop, ~once per day
[23:06] <poolie> i agree doing it faster or indeed live would be better
[23:06] <poolie> i need to ask for the dependencies to be on devpad or similar
[23:07] <jam> poolie: k. There is a certain amount of needing a queue to go to 0 when you do stuff, so you don't spin thinking you need to fix something that is fixed
[23:07] <poolie> agree
[23:07] <jam> more than just 'feels good' satisfaciton
[23:07] <jam> satisfaction
[23:07] <poolie> once it's there i could probably run it every half hour or so
[23:07] <poolie> absolutely
[23:07] <poolie> i would like to also make it read things a bit faster
[23:07] <wgrant> gary_poster: If you are around again this evening, could you give me any advice on QAing your two pending items? They're blocking a bzr upgrade that is needed ASAP.
[23:07] <poolie> though moving it to the dc would also help with that
[23:08] <poolie> beyond that, we probably need feeds or push notification
[23:08] <jam> poolie: yeah. It is a nice reminder of things for me to push on. I tried to push on everything that was past the first column
[23:09] <poolie> i was going to see if people liked it first
[23:09] <poolie> graphs would be good too
[23:10] <jam> poolie: having it easier to get the one just for me would also be useful. Probably because jelmer does too much, so I get lost in the mix :)
[23:11] <poolie> you know there is one just for you?
[23:11] <poolie> you can bookmark it
[23:11] <poolie> direct navigation wbn
[23:12] <jam> yeah, but it isn't the site that gets linked by you repeatedly :)
[23:16] <poolie> up one level and across
[23:16] <poolie> but i see what you meaon
[23:16] <poolie> i wonder if it will work while lp is readonly?
[23:19] <poolie> no apparently not
[23:19] <poolie> seems like a bug
[23:22] <jam> poolie: "up one level" I don't see any links, but I can url hack
[23:22] <jam> but I can just s/bzr/jameinel/ if I'm going to do that
[23:23] <poolie> https://devpad.canonical.com/~mbp/kanban/jameinel-kanban.html
[23:23] <poolie> perhaps it would be better to have ajax filters
[23:35] <jkakar> poolie, jam: Hi! :)
[23:35] <jkakar> Out of curiousity, are the warning/danger icons useful to you?
[23:36] <poolie> mm
[23:37] <poolie> they're a bit of a reminder we have too much inventory, which is good
[23:37] <poolie> they are maybe a bit alarming
[23:37] <jkakar> poolie: Heh, that's their job. :)
[23:37] <poolie> thanks for fixing the bugs i filed!
[23:37] <poolie> i'm just filing one against lp that it fails api requests while readonly
[23:37] <jkakar> poolie: Anyway, I plan to make the setting configurable.  Perhaps the current defaults are not quite right for Bazaar.
[23:37] <jkakar> poolie: My pleasure!  And thanks, I was just popping in here because of those failures.
[23:38] <poolie> oh, the api calls failing?
[23:38] <poolie> i'll subscribe you when i get the bug number back
[23:39] <jkakar> poolie: Yes, the API calls.  I'll appreciate the subscribe, thanks.
[23:40] <jkakar> poolie: Specifically this kind of failure: http://paste.ubuntu.com/565213/
[23:40] <jkakar> poolie: Okay, it's bedtime here.  Have a good one. :)
[23:41] <poolie> that's what i get too
[23:41] <poolie> sleep well