[00:03] <wallyworld_> lifeless: there's a mp to remove person location stuff. just double checking that you've approved that?
[00:06] <lifeless> I haven't reviewed it
[00:06] <wallyworld_> lifeless: i don't mean a review, just that you are ok with the work item?
[00:06] <lifeless> I'm aware of it; I wouldn't expect approval to be needed
[00:07] <wallyworld_> i assume no one uses the location stuff then
[00:08] <wgrant> Actually, someone generated images from it just a couple of weeks back.
[00:08] <wgrant> But it's not possible to set it any more; I agree it should be removed.
[00:10] <lifeless> maps were nuked way back
[00:10] <lifeless> this is hangover; we need tz and should keep that
[00:10] <wgrant> Damn. Missed buildbot by 90s.
[00:10] <wallyworld_> ok. just wanted to check, thanks
[00:13] <jcsackett> sinzui: it would appear changing my login email on kanban deleted all my cards.
[00:14] <lifeless> \o/
[00:22] <jcsackett> oh hurray! it just changed my icon to the same one wgrant uses, so my eye slid over them.
[00:22] <wgrant> Oh, I wondered why I had so many cards.
[00:22] <wgrant> Didn't think about that.
[00:23] <jcsackett> yeah, i updated gravatar and now all is well.
[00:24] <jcsackett> wgrant: we need to get you a gravatar acocunt, if only so i stop seeing bastardized power button symbols everywhere. :-P
[00:24] <wgrant> Heh
[00:24] <wgrant> jcsackett: btw, https://code.launchpad.net/~wgrant/launchpad/multipolicy-3 is the WIP branch for the new AccessPolicy model.
[00:25] <wgrant> Should be pretty much stable by the end of today.
[00:26] <jcsackett> wgrant: awesome! thanks.
[00:27] <jcsackett> i look forwards to adding actual data to the sharing elements soon. :-)
[00:57] <rick_h> StevenK: ping, have a sec?
[00:58] <StevenK> rick_h: Hmmmmm?
[00:58] <rick_h> StevenK: bit OT, I'm curious about the packaging of something
[00:58] <rick_h> StevenK: I see the convoy stuff seems to have branches that are just the debian dir?
[00:58] <StevenK> The packaging stuff we use is everything
[00:59] <rick_h> ok, yea I couldn't figure out how to see ours
[00:59] <rick_h> StevenK: so do you just have a packaging branch then with the debian dir?
[00:59] <StevenK> rick_h: https://code.launchpad.net/~launchpad/+recipe/launchpad-convoy
[00:59] <rick_h> and pull trunk, merge over, etc?
[01:00] <StevenK> rick_h: That recipe builds into the LP PPA.
[01:00] <StevenK> rick_h: Our packaging is in lp:~launchpad/convoy/trunk; but it contains everything
[01:01] <rick_h> ok, I've got to hit up the recipe docs then. So does that recipe merge in the main convoy into ours then to build?
[01:01] <StevenK> rick_h: The recipe checks out lp:convoy
[01:01] <StevenK> rick_h: It then merges lp:~launchpad/convoy/trunk into it
[01:02] <rick_h> ok, and the recipe updates changelog/etc then in some generic sense?
[01:02] <StevenK> Right
[01:02] <rick_h> ok
[01:02] <StevenK> It generates a version, sets the message to Auto build
[01:02] <rick_h> gotcha, ok makes sense
[01:03] <rick_h> I'm tinkering with a pyinotify driven JS build script and trying to package up the js minification stuff out of tree
[01:03] <rick_h> and wanted to see if I could figure out how to package it up in some way in ppa first
[01:03] <StevenK> Heh, okay
[01:03] <StevenK> Packaging is ... fun to learn
[01:03] <rick_h> yea, I've tinkered and done a few things
[01:04] <rick_h> but I've never used the recipe stuff and was surprised to see the landscape branches that were pure debian dir files
[01:04] <rick_h> StevenK: any word on the RT?
[01:04] <StevenK> Nope
[01:05] <rick_h> all the test branches landed so starting to peek at actually looking at opening up, finding/fixing bugs, and optimizing
[01:05] <StevenK> If we want a higher priority on it, we can ask lifeless to raise it at the meeting
[01:05] <rick_h> thanks a ton for all the help with it
[01:05] <rick_h> meh, I know there's some discussion up the chain started which is why I wondered if you'd heard anything
[01:06] <StevenK> rick_h: I've gotten most of the pieces ready for webops when they want it
[01:06] <rick_h> cool
[01:06] <rick_h> now I'm tried of doing make jsbuild so want it to auto build :)
[01:06] <StevenK> Two configs diffs are in my home directory on carob
[01:08] <StevenK> rick_h: sinzui mentioned an issue with it too -- not all of our views are under LaunchpadView
[01:08] <StevenK> rick_h: I'm looking at that today
[01:08] <rick_h> ??
[01:09] <rick_h> Ah, like the graph that was broken?
[01:09] <rick_h> or don't use base-layout-macro?
[01:09] <StevenK> rick_h: We added a property to LaunchpadView that constructs the combo loader URL.
[01:09] <rick_h> ah
[01:09] <StevenK> If the main page view doesn't have LaunchpadView as a parent, it will oops
[01:11]  * StevenK hugs /usr/bin/sponge
[01:51]  * wallyworld_ stabs X - hard to work with all this rubbish being left behind on the screen
[02:07] <huwshimi> wallyworld_: Are you talking about the window shadows?
[02:07] <wallyworld_> huwshimi: yeah
[02:07] <huwshimi> wallyworld_: The compiz update that's supposed to fix it just came through
[02:07] <huwshimi> I'm just about to restart to make sure
[02:07] <wallyworld_> huwshimi: awesome! thanks! will look
[02:07] <huwshimi> brb
[02:10] <huwshimi> wallyworld_: All fixed for me :)
[02:10] <wallyworld_> huwshimi: excellent. will update
[02:11] <huwshimi> ugh, but something killed thunderbird :(
[02:19] <wallyworld_> huwshimi: you mean it won't start?
[02:21] <huwshimi> wallyworld_: It starts, I just get blank panels
[02:21] <wallyworld_> noooooooooooooooooooo
[02:22] <huwshimi> wallyworld_: Like this: http://ubuntuforums.org/attachment.php?attachmentid=212818&d=1329440555
[02:22] <huwshimi> oh, you'll have to login to see that image
[02:22] <wallyworld_> yeah
[02:22] <wallyworld_> no login
[02:23] <wallyworld_> oh well, might need to revert to previous tb version
[02:50] <huwshimi> wallyworld: How do you revert a version these (post synaptic) days?
[02:51] <wallyworld> huwshimi: install synaptic :-)
[02:51] <wallyworld> that's what i used
[02:51] <huwshimi> wallyworld: haha
[02:51] <wallyworld> huwshimi: i wasn't joking :-)
[02:51] <huwshimi> wallyworld: I know, it's just funny
[02:51] <wallyworld> :-)
[02:51] <mwhudson> command line is pretty easy too :)
[02:52] <mwhudson> apt-get install mozilla-thunderbird=$VERSION
[02:52] <mwhudson> err maybe ==
[02:52] <huwshimi> mwhudson: How do I find out the previous version? :)
[02:52] <wallyworld> i use synaptic to see what the previous versions are
[02:53] <mwhudson> not sure :)
[02:53] <huwshimi> mwhudson: It's ok :)
[02:53] <StevenK> apt-cache policy
[02:53] <lifeless> huwshimi: apt and dpkg log updates
[02:53] <lifeless> huwshimi: in /var/log/
[02:54] <huwshimi> lifeless: cheers
[02:56] <wallyworld> StevenK: want a small +22/-6 review? https://code.launchpad.net/~wallyworld/launchpad/optional-extended-choice-popup-933743/+merge/93518
[03:27] <lifeless> stub: oh hai
[03:27] <stub> yo
[03:27] <lifeless> encaffeinated?
[03:29] <stub> lifeless: yup
[03:31] <lifeless> shall we call/sykpe/hangout/mumble/voip/smoke signal/...
[03:35] <lifeless> stub: ^
[03:36] <stub> lifeless: whatever. skype is up, hangout virgin
[03:36] <stub> Just try and ignore the hedge trimmer outside my window :-/
[03:36] <wgrant> Hangouts should really take an s/out//
[03:37] <wgrant> The plugin seems to be even shittier than Flash.
[03:39] <StevenK> stub: I guess your stats patch needs an FDT?
[03:39] <wgrant> No
[03:39] <wgrant> It was live
[03:39] <wgrant> So Monday is workitems.
[03:39] <wgrant> Tuesday is my -0, Wednesday hopefully my -2
[03:40] <StevenK> Ah, so I should request DB r11382?
[03:40] <wgrant> Doesn't really matter.
[03:40] <wgrant> But you could, yes.
[03:41] <StevenK> Well, either I do it tonight, or you do your rev which includes it all on Monday
[03:41] <wgrant> "it all" is the null set.
[03:41] <wgrant> So it makes little difference :)
[03:42] <StevenK> It includes another patch that isn't in devel
[03:42] <StevenK> So it changes the merge into devel a little
[03:42] <wgrant> True, but it affects nothing.
[03:46] <StevenK> wgrant: How about a NDT of r14820?
[03:47] <wgrant> There's nothing interesting.
[03:47] <wgrant> Apart from your rev, but that's just one rev.
[03:47] <StevenK> I was about to say :-)
[03:47] <StevenK> Where is wallyworld's work ...
[03:48]  * StevenK kicks buildbot
[03:48] <wgrant> 10 hours away
[03:48] <wgrant> ie. next week
[03:48] <StevenK> The death of lp/contrib is interesting. To me.
[03:49] <wgrant> The death of lp/contrib in this manner is a mistake.
[03:49] <wgrant> I nearly reverted it.
[03:50] <StevenK> Nearly?
[03:51] <wgrant> I entirely object to the principle of it, but not quite enough that I will revert it.
[03:52] <lifeless> stub: https://launchpad.net/launchpad-results
[04:08] <StevenK> Is utilites/on-edge even useful anymore?
[04:09] <wgrant> s/edge/qastaging/
[04:14] <StevenK> wgrant: But it's disgusting
[04:15] <StevenK> And probably mostly deprecated by the deployment reports.
[04:17] <StevenK> wallyworld: How do you feel about a 470 line diff?
[04:17] <wallyworld> StevenK: already on it
[04:26] <wallyworld> StevenK: r=me. can we delete those old bug redirection views?
[04:27] <StevenK> I'm not sure. I thought about it, and figured it was just easier and less risky to bring them into line.
[04:27] <wallyworld> sure
[04:28] <wallyworld> brad's comment on one of them seems to indicate it can be gone.
[04:29] <StevenK> It's still mentioned in bug's ZCML
[04:31] <wallyworld> i think that is also obsolete, but not sure
[04:32] <wallyworld> since the redirection is done elsewhere
[04:32] <StevenK> The fact that it deals with IBug:+index in the ZCML makes me worry that it isn't
[04:33] <wallyworld> yeah, safest to leave as is i guess
[04:43] <wallyworld> StevenK: after you land your branch, feel like a small +22/-6 review for me?
[04:45] <StevenK> wallyworld: Sure.
[04:45] <wallyworld> thanks!
[04:46] <StevenK> https://code.launchpad.net/~wallyworld/launchpad/optional-extended-choice-popup-933743/+merge/93518 ?
[04:46] <wallyworld> StevenK: yeah
[04:46] <StevenK> That's +22/-10 :-P
[04:46]  * wallyworld gets out a birch branch
[04:47]  * StevenK deals wallyworld a penalty card for 'Lying'
[04:47]  * wallyworld accepts the punishment
[04:48]  * StevenK peers at the removal of the math imports
[04:50] <StevenK> wallyworld: ^ That was lint cleanup?
[04:50] <wallyworld> StevenK: yeah
[04:50] <wallyworld> lint said they were not used
[04:51]  * wgrant implements multirow and subselect inserts in Storm
[04:52] <StevenK> wallyworld: r=me
[04:52] <wallyworld> StevenK: thanks :-)
[04:52]  * wallyworld lands
[05:02] <StevenK> And utilities/qa-ready has a copy-and-paste job from on-edge
[05:02]  * StevenK deletes them both for being useless
[05:03] <wgrant> lifeless: I guess you're the Stormiest around. Could you glance at a small branch to vaguely implement bug #411556 and bug #61300?
[05:03] <_mup_> Bug #411556: Storm should support multi-row inserts <Storm:New> < https://launchpad.net/bugs/411556 >
[05:03] <_mup_> Bug #61300: Missing files in lout-doc <lout (Ubuntu):Fix Released> < https://launchpad.net/bugs/61300 >
[05:03] <wgrant> Bug #613300
[05:03] <_mup_> Bug #613300: Storm needs to support INSERT INTO ... SELECT <Storm:New> < https://launchpad.net/bugs/613300 >
[05:16] <wgrant> stub: Thanks. Can you please apply it?
[05:16] <stub> Yup. On it.
[05:16] <StevenK> wallyworld: One more
[05:17] <wgrant> stub: Thanks.
[05:19] <stub> wgrant: Done except for _prod_2, which is blocked on the backups completing.
[05:20] <StevenK> Which will take hours?
[05:20] <wgrant> stub: Thanks.
[05:21] <stub> Could be another hour or two
[05:21] <wgrant> 3.5 hours, but yes.
[05:21] <stub> seems to normally be finished before 3pm my time, which is the fdt window
[05:22] <wgrant> nightly.sh completed Thu Feb 16 08:51:20 UTC 2012
[05:22] <wgrant> nightly.sh completed Wed Feb 15 09:15:18 UTC 2012
[05:26] <stub> Need to reschedule that if it is overrunning the fdt window
[05:26] <StevenK> FDT is 1000UTC
[05:27] <stub> oh right - changed that to avoid webops shift change
[05:29]  * wgrant hopes that archive will now completely drop off the list
[05:30] <wgrant> Bah. #6 -> #27 :(
[05:30] <wgrant> Must be another evil query.
[05:32] <lifeless> wgrant: did stub review it ?
[05:32] <wgrant> lifeless: No, that was an index.
[05:32] <wgrant> https://code.launchpad.net/~wgrant/storm/bulk-insert/+merge/93527
[05:33] <wgrant> I'm probably missing something, but it seems to work so I might use it anyway.
[05:35] <lifeless> the first hunk is confusing
[05:35] <lifeless> I will write it in the review
[05:40] <lifeless> you can get stub or jkakar or whoever is around to land; I'm well past EOW
[05:40] <lifeless> (we're about to enter phase 2 of operation put-cynthia-to-sleep
[05:40] <lifeless> )
[05:42] <wgrant> Heh
[05:42] <wgrant> Good luck
[05:42] <wgrant> Thanks
[05:54] <wgrant> Heh
[05:54] <wgrant> I think abentley is trying to work around Storm's disability in another way
[05:54] <wgrant> http://bazaar.launchpad.net/~abentley/storm/executemany
[06:02] <wallyworld> StevenK: sorry was picking up kid from school and buying dinner food
[06:06] <StevenK> wallyworld: Too late, self reviewed
[06:28] <stub> wgrant: I can do the second review, but would be better if jkakar or jamesh or gustavo does the second review - someone who understands the internals and trade offs better (but to me, the patch looks good)
[06:30] <wgrant> stub: Yep, that's why I didn't ask you.
[06:30] <wgrant> Was waiting for one of the trinity.
[07:14] <wgrant> yay
[07:22] <wgrant> lolz
[07:22] <wgrant> The main scriptactivity query is unindexed.
[07:22] <wgrant> And bugbranch
[07:24] <wgrant> That leaves BPPH as the only table with unexplained completely insane read volumes.
[07:35] <StevenK> Haha
[07:36] <StevenK> wgrant: I think BPPH can be explained with one word: Publication
[08:38] <stub> wgrant: I think I wanted scriptactivity trimmed so indexes would be unnecessary :-/
[08:38] <stub> Seems to have become an audit trail though.
[08:39] <wgrant> stub: Heh
[09:10] <czajkowski> aloha
[09:13] <mrevell> Hello
[09:45] <czajkowski> morning is there a reason as to why people cannot remove their opengpg keys ?  a user wants to add a new one and delete their old one ?
[09:49] <maxb> Well, there are some data integrity concerns, in terms of keys being used to track who uploaded packages
[10:23] <czajkowski> maxb: thanks for your help
[12:34] <salgado> I don't think we can QA bug 933592 (it's only about adding some model classes); should I just mark it as qa-untestable?
[12:39] <wgrant> erk
[12:39] <wgrant> That's illegal
[12:39] <wgrant> Code changes aren't meant to land on db-devel.
[12:40] <wgrant> salgado: ^^
[12:40] <salgado> oh, perfect
[12:41] <salgado> wgrant, how does it work? we need to get the schema changes deployed first and then land the code changes?
[12:41] <wgrant> salgado: Right.
[12:41] <salgado> shall we revert that landing, then?
[12:43] <wgrant> Hm, didn't that DB patch already get deployed early in the week?
[12:43] <wgrant> Last friday, in fact.
[12:43] <wgrant> This branch should have landed on devel instead.
[12:44] <wgrant> So it's not harmful, just illegal. You probably want to land on devel and pretend that the db-devel landing never happened.
[12:45] <salgado> oh, could be. how can I tell when a db patch has been deployed?
[12:46] <wgrant> https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus logs deployments, and I normally comment in the linked bug.
[12:46] <wgrant> But it looks like this time there was no bug.
[12:46] <salgado> yep, there wasn't one for the schema changes
[12:46] <wgrant> Anyway, it was deployed just over a week ago.
[12:46] <wgrant> DB patches tend to be deployed within a couple of working days.
[12:47] <salgado> ok, sorry about that. I'll create a new MP against devel and ask somebody to land it for me
[12:47] <salgado> mabac, ^
[12:47] <wgrant> Far easier for me to just pqm-submit it now :)
[12:47] <mabac> salgado, hi there. just a sec while I catch up
[12:48] <mabac> oh...
[12:48] <salgado> wgrant, oh, that works too :)
[12:49] <salgado> wgrant, although if there are schema-related changes the merge will fail, right?
[12:49] <salgado> I mean, if one of our merges from db-devel into our branch included any changes in database/schema
[12:50] <wgrant> Those checks are no longer enforced, but are generally done manually.
[12:50] <mabac> wgrant, sorry about that. :) now I know what to do next time
[12:50] <wgrant> But it only checks the delta between devel and your branch
[12:50] <wgrant> So anything that's already in devel doesn't violate the check.
[12:50] <salgado> mabac, yeah, just so you're aware of the policy, I didn't know about it either
[12:50] <mabac> salgado, thanks. learning new stuff every day
[12:51] <mabac> salgado, wgrant let's see. the entire schema change is included in the models branch. I didn't quite get if that's going to be a problem
[12:52] <wgrant> mabac: It's not a problem, since I merged that into devel a week ago.
[12:52] <mabac> wgrant, ok, makes sense since it didn't show up in the mp diff
[12:52] <salgado> wgrant, right, but I merged db-devel into our branch a couple days ago and that brought in a bunch of new db patches.  I can't seem to find whether those patches have been deployed or not
[12:52] <mabac> wgrant, scratch that. the diff was from db-devel of course
[12:53] <wgrant> salgado: There's one unmerged DB patch ahead of your branch, but that was applied live. I'm merging that into devel separately now.
[12:53] <wgrant> Then I'll merge yours in a sec.
[12:54] <salgado> wgrant, ok, thanks a lot for taking care of this
[12:54] <wgrant> I have three patches in the queue -- cleaning it up is entirely selfish :)
[12:54] <salgado> heh :)
[12:55] <mabac> wgrant, thanks
[12:57] <wgrant> The reason we're able to do DB patches with so little downtime is that they are kept separated from code changes. If we let normal code changes also land to db-devel, the DB patches are no longer necessarily passing the test suite with the deployed code.
[12:57] <wgrant> That's why this restriction is in place.
[13:00] <wgrant> OK, submitted.
[13:02] <salgado> wgrant, ah, makes sense
[13:02] <wgrant> Landed on devel and bug marked untestable.
[13:03] <salgado> yay!
[13:05] <mabac> great! thank you
[13:06] <wgrant> So, you can land any further branches on devel at your leisure.
[13:29] <mabac> salgado, I have added some code according to your email: lp:~linaro-infrastructure/launchpad/workitems-widget mostly hunting for references to whiteboard and mimicking that.
[13:33] <salgado> mabac, cool, are you going to be around a little longer? we can talk about that after I review your l-i-t branch?
[13:34] <mabac> salgado, sure, I have a couple of hours left of today. thanks for picking up that review!
[14:30] <deryck> abentley, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:40] <salgado> on bug 933910 I've just deleted unused code. should I mark it qa-untestable?
[15:02] <matsubara> bac, hey there, could you do a review for me?
[15:03] <matsubara> bac, https://code.launchpad.net/~matsubara/lp-devops-dashboard/932768-lplib-credential/+merge/93207
[15:10] <bac> matsubara: sure
[15:17] <matsubara> thanks bac
[15:25] <salgado> bac, hi there.  on bug 933910 I've just deleted unused code. should I mark it qa-untestable?
[15:25] <_mup_> Bug #933910: Remove TranslatableMessage & co <qa-untestable> <tech-debt> <Launchpad itself:Fix Committed by salgado> < https://launchpad.net/bugs/933910 >
[15:27] <bac> salgado: both of your reviewers mentioned some uneasiness with the branch pending a thorough QA.  so can you exercise translations functionality to see if anything breaks?
[15:29] <salgado> oh, sure, I'll do that
[15:34] <bac> matsubara: in the environment where the devops dashboard is run, does it have access to the Gnome keyring?  it looks like your update to download-cache got a new version of launchpadlib which now (and for some time, actually) prefers to store credentials in the gnome keyring.
[15:35] <bac> matsubara: if you have strong preference to use your existing credentials file then your changes look good.  but i wonder why you cannot use the keyring.
[15:38] <matsubara> bac, it's run on devpad
[15:38] <matsubara> not sure if we have a gnome-keyring there. I wonder if is there a way to update the keyring with the existing credentials
[15:39] <matsubara> it's run by a cronjob under the lpqateam user
[15:39] <bac> matsubara: it it possible to just reauthenticate?
[15:39] <matsubara> I think so. not sure which user that token belongs to but it should be easy to find out or create a new token
[15:42] <bac> matsubara: actually, you're going to have a hard time given the restricted nature of devpad.  i think the code changes you've made are probably the right way to go.
[15:42] <bac> matsubara-lunch: actually, you're going to have a hard time given the restricted nature of devpad.  i think the code changes you've made are probably the right way to go.
[15:44] <bac> matsubara-lunch: i've approved the merge proposal but cannot mark it as such since i'm not in the QA team.
[16:22] <james_w> would someone please push https://code.launchpad.net/~james-w/python-oops-datedir-repo/bson-compat/+merge/92560 through for us please?
[16:28] <rick_h> james_w: pulling down
[16:28] <james_w> \o/ rick_h
[16:28] <rick_h> james_w: oh, this isn't lp
[16:28] <rick_h> heh, need to read better
[16:42] <bac> rick_h: are you doing the push for james_w?  if not, i will.
[16:43] <rick_h> bac: working on it, tring to get the branches pulled/rnu tests on it
[16:43] <bac> rick_h: oh, ok.  thanks.
[16:43] <bac> just didn't want to duplicate effort
[16:43] <rick_h> bac: thanks
[17:03] <rick_h> bac: ok, can you push it, evidently I've got something wrong in my setup for this setup.py and it hates me
[17:03] <rick_h> along with the buildout, and time sinking like no tomorrow
[17:04] <bac> rick_h: ok.  will do so after lunch.  <-- james_w
[17:04] <james_w> thanks
[17:04] <rick_h> bac: ty
[17:17] <sinzui> bac: will you have time to review a branch that fixes some stupid team links https://code.launchpad.net/~sinzui/launchpad/usless-team-links/+merge/93616
[17:46] <rick_h> bac: if you get a second please: https://code.launchpad.net/~rharding/launchpad/fix_yui_934225/+merge/93622
[18:02] <matsubara> bac, thanks!
[18:26] <lifeless> flacoste: I think you underestimate the frequency, and depth, of confusion caused :)
[18:32] <lifeless> flacoste: I seem to have put the cat amongst the pigeons with that thread; I think due to my comment in brackets; oops!
[18:33] <rick_h> lifeless: think of the kittens you meany :)
[18:34] <lifeless> every time you disable a feature flag, yaweh kills a kitten?
[18:34] <rick_h> lifeless: I'm pulling out the jsmin stuff out of utilites into a separate package, is it enough for it to be a python package or would a .deb be the one true way?
[18:34] <lifeless> rick_h: AFAICT we have to keep two deps systems - .deb and buildout - indefinitely.
[18:35] <rick_h> lifeless: ok, so as long as I can get the python package on pypi, just a python package is good enogh?
[18:35] <lifeless> rick_h: we can't do seamless upgrades of .deb's on appservers, so yeah a python package is fine
[18:36] <lifeless> (by seamless upgrades I mean that when a deb version X is upgraded to Y, any appservers still consulting X are now out on a limb and not safe if they do late imports or try to restart;
[18:36] <lifeless> this /shouldn't/ matter if the thing is api compatible, but its still a risk (and how often are things 100% compat)
[18:36] <lifeless> rick_h: yes, pypi is good enough
[18:36] <rick_h> lifeless: ok, thx. Sounds like a plan
[18:36] <lifeless> rick_h: have you seen the CreatingNewProjects wiki page ?
[18:36] <rick_h> lifeless: no, haven't looked
[18:36] <rick_h> will now
[18:42] <salgado> lifeless, hey there.  I didn't quite understand your suggestion for updating the work items... it's not clear to me whether you're saying it's fine to just update all objects normally and flush() at the end or something else?
[18:43] <lifeless> salgado: you raised a concern about race conditions between sequence changes and other changes
[18:43] <rick_h> lifeless: wrt the longpoll discussion, I've not peeked at it a ton, but would moving the longpoll to only pages that need it help at all? prevent all lp urls from making lp connections?
[18:43] <lifeless> salgado: I was noting that using a flush() to well, flush, the other changes, and then doing sequence changes, would give you some safety
[18:43] <rick_h> lifeless: from seeing the JS it looks like it's started on every page in base-layout-macros?
[18:44] <lifeless> rick_h: well, that would probably reduce the impact, but consider that we'd like every page to be able to update in realtime...
[18:44] <salgado> lifeless, did I? I was just pointing out that even if we manage to update all the sequences with a single update we could still end up issuing multiple updates for the status column
[18:44] <rick_h> lifeless: yea, reaching for quick/dirty helpers
[18:44] <lifeless> rick_h: I mean, if LP:
[18:44] <lifeless>  - was fast
[18:45] <lifeless>  - had a built in dashboard / notification list
[18:45] <lifeless>  - easy to navigate
[18:45] <lifeless>  - fast search
[18:45] <lifeless> folk might open less tabs
[18:45] <lifeless> -> virtuous circle
[18:45] <lifeless> salgado: ah, well I read it wrongly then :P
[18:45] <lifeless> not unheard of :>
[18:46] <flacoste> rick_h: unless i'm mistaken, we actually only opens the connection on page that requires it now
[18:46] <rick_h> lifeless: definitely agree, but since things a bug page doesn't use LP that I recall if the issue is 6 tabs and we can get it to 6 MP pages or what not might make a sig. impact on usability
[18:46] <lifeless> rick_h: we wouldn't want it to be a timebomb though
[18:46] <salgado> lifeless, ah, that explains things, then ;)
[18:46] <lifeless> rick_h: consider that a bugs page that shows new comments is bug desired
[18:46] <lifeless> rick_h: bug searches that update when someone adds/removes a bug to the resultset
[18:47] <rick_h> flacoste: ah, yea I see in the comment that it checks for a lp.cache.longpoll, missed that
[18:47] <lifeless> rick_h: longpoll is a gateway to a -really- wonderful UI
[18:47] <rick_h> lifeless: ok so nvm, it's more prevelent than I've realized
[18:47] <lifeless> rick_h: also remember the desire to move to one domain for the appservers
[18:47] <lifeless> rick_h: if there is no code., then the impact would be less isolated
[18:48] <lifeless> so, I don't think we need to panic; if flacoste can find resources to finish it, we can disable the flag until a scheduled rotation to do the work, and then we'll be all good.
[18:48] <lifeless> I *really* want this working, but I don't want us paying interest we can avoid in the meantime.
[18:49] <lifeless> flacoste: (did you see what I did there :P)
[18:49] <rick_h> lifeless: yea, I can imagine 6tabs being a pita to work around
[18:49] <lifeless> rick_h: the thing is that even wgrant, who a) knew about the issue, and b) isn't exactly clueless, got confused and spent 5-10 minutes asking webops questions about operational status, only to realise it was this foot-gun.
[18:50] <flacoste> lifeless: first, let's agree on what finished means
[18:51] <lifeless> flacoste: good point
[18:51] <flacoste> lifeless: and if finished means it requires a 'rotation', then let's scrap this here and now
[18:52] <flacoste> we finish this on maintenance or we scrap it
[18:52] <lifeless> so, lets look at https://bugs.launchpad.net/launchpad/+bugs?field.tag=longpoll
[18:52] <lifeless> 876325 is small but fiddly
[18:52] <lifeless> 906482 is the key user facing thing, and wildcard polling domains are probably sufficient to address it
[18:53] <lifeless> its not perfect (but I'm not arguing for perfect)
[18:53] <lifeless> bug 850790 we may be able downgrade
[18:53] <_mup_> Bug #850790: Enable dynamically allocated development services to communicate their configuration to other processes <longpoll> <Launchpad itself:Triaged> < https://launchpad.net/bugs/850790 >
[18:54] <lifeless> bug 809139 just needs some examination of how rabbit reports its zomg's in its logs and either nagios or oops glue for that
[18:54] <_mup_> Bug #809139: rabbit deployment lacking automated error gathering <longpoll> <Launchpad itself:Triaged> < https://launchpad.net/bugs/809139 >
[18:55] <lifeless> bug 903186 looks shallow - a normal operation (race condition probably) generates an oops that we don't want, we should filter on the longpoll server
[18:55] <_mup_> Bug #903186: Closed: Method(name=close, id=40) (404, "NOT_FOUND - no queue 'longpoll.subscribe.091adf46-9097-4d50-97bc-8d20e8c18417' in vhost 'launchpad.net'", 60, 20) content = None  <longpoll> <oops> <Launchpad itself:Triaged by redsquad> < https://launchpad.net/bugs/903186 >
[18:55] <flacoste> lifeless: right, like i said 906482 is what was the killer
[18:55] <lifeless> 902117 may be unactionable
[18:56] <flacoste> at the time, Julian thought that implementing Bayeux was the solution
[18:56] <flacoste> and that would have taken too much time
[18:56] <lifeless> or it may be a precursor to 903186
[18:56] <flacoste> (not to say useless in the end)
[18:56] <lifeless> 901844 will be fiddly but isn't hard

[19:00] <lifeless> flacoste: so, I don't know if that needs a rotation or not
[19:00] <flacoste> it doesn't
[19:00] <lifeless> flacoste: it -may- have a long tail, but I don't see a lot of reason to expect one.
[19:00] <flacoste> we don't have LP rotation available anyway
[19:01] <flacoste> so it will have to be done on maintenance
[19:01] <flacoste> and 4 bugs is definitively maintenance turf
[19:03] <lifeless> flacoste: I missed some
[19:03] <lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=longpoll
[19:03] <lifeless> flacoste: nothing major though
[19:04] <lifeless> flacoste: fiddly integrate-with-ops for the most part
[19:04] <flacoste> yep
[19:04] <lifeless> important to do before going live
[19:04]  * lifeless is sssstubborn on that
[19:04] <flacoste> agreed
[19:04] <flacoste> agrees
[19:04] <lifeless> flacoste: so, I'd still like to disable the flag for now
[19:05] <lifeless> flacoste: because it is causing confusion and taking up time, even in our tiny pool of users
[19:05] <lifeless> flacoste: (and, we should generally have the same experience of LP as our users)
[19:06] <flacoste> lifeless: i'm +0 here really, my only concern was about the 'we need to schedule a squad to finish this' part :-)
[19:06] <lifeless> heh :>
[19:06] <flacoste> we could probably have a notification-service-beta team
[19:07] <flacoste> for those who really want the feature, or develop it
[19:07] <lifeless> that just adds permutations for debugging headaches
[19:07] <flacoste> and are not confused or serial tabs opener ;-)
[19:07] <lifeless> I'd be totally happy with the feature being back on for devs when the connections issue is resolved
[19:08] <rick_h> bac and if you get another sec pls https://code.launchpad.net/~rharding/launchpad/standardize_js_934401/+merge/93637
[19:09] <bac> rick_h:  ok
[19:09] <bac> sinzui: working on yours now
[19:10] <sinzui> fab
[19:10] <deryck> flacoste, I'm -1 on disabling this. if only because tabs are the drug and lifeless is the junkie. I love him too much to see him drown in his own multitasking.
[19:10] <deryck> :)
[19:10] <flacoste> lol
[19:10] <rick_h> dr deryck with the presciption of "quit doig that crap to yourself!" :)
[19:11] <deryck> :)
[19:11]  * sinzui waits for quote page update
[19:13] <lifeless> deryck: lol :P
[19:13] <lifeless> deryck: not that I'm not the one running into issues and getting confused :>
[19:13] <deryck> lifeless, heh, I know. Just having some fun.
[19:56] <bac> hi rick_h, why do you cp the yui2 stuff instead of creating a symlink as done for yui3?
[19:57] <rick_h> bac: the yui3 one is a symlink from build/js/yui -> build/js/yui3.3.0
[19:58] <rick_h> bac: the cp is a copy of what we're doing in bin/combo-rootdir
[19:58] <bac> rick_h: ok, thanks
[19:58] <rick_h> I'm reloading to see if the yui3.3.0 is a symlink or a copy, it might be able to be a symlink, not compared
[22:09] <wgrant> abentley: Hi, https://code.launchpad.net/~wgrant/storm/bulk-insert may be of interest.
[22:12] <abentley> wgrant: You're still using execute, so this looks complementary to executemany.
[22:12] <wgrant> abentley: It does it in a single statement.
[22:12] <wgrant> So executemany is not required.
[22:13] <abentley> wgrant: In my tests, a single insert statement via execute took 3x as long as via executemany.
[22:13] <wgrant> abentley: That's a bit of a worry.
[22:17] <wgrant> Because executemany indeed just calls execute lots of times, so there's even more statement parsing overhead.
[22:18] <abentley> wgrant: I can repeat my tests on monday, but at one point I had something much like your code and the branch scanner too 10 minutes.  Then I changed it to use executemany, and it took 3 minutes.
[22:19] <wgrant> abentley: Did you use execute directly with a string, or did you use storm?
[22:19] <abentley> wgrant: Directly with a string.
[22:19] <wgrant> Huh
[22:22] <abentley> wgrant: executemany is intended for bulk operations, so it doesn't surprise me that it's more efficient.  It does surprise me that you say it just repeatedly executes the statement.
[22:22] <wgrant>     if (!PyArg_ParseTupleAndKeywords(args, kwargs, "OO", kwlist,
[22:22] <wgrant>                                      &operation, &vars)) {
[22:23] <wgrant>     while ((v = PyIter_Next(vars)) != NULL) {
[22:23] <wgrant>         if (_psyco_curs_execute(self, operation, v, 0) == 0) {
[22:23] <wgrant> It just parses the Python argument structures and then throws them into execute :/
[22:23] <wgrant> Not preparing the statement or anything.
[22:23] <wgrant> INSERT INTO ... VALUES is also intended for bulk operations, and should win because it's only parsed once... I shall attempt to reproduce your results.
[22:25] <abentley> wgrant: The branch I was scanning was bzr+ssh://bazaar.launchpad.net/~irar/gcc-linaro/slp-for-any-nops-4.6/
[22:26] <abentley> wgrant: I'm scanning it with ~abentley/launchpad/branchscanner-timeout-bug-808930
[22:33] <wgrant> abentley: Oh, real code, even better. Thanks.
[22:33]  * wgrant tries.
[22:42] <wgrant> abentley: How big's that branch?
[23:02] <wgrant> Huh
[23:02] <wgrant> Do people really survive with <6 Launchpad tabs open?
[23:04] <jelmer> what's the issue with having multiple tabs over
[23:04] <jelmer> *open?
[23:04] <wgrant> abentley: my way (ie. insert_many == store.execute(Insert(columns, table=[table], expr=rows))) looks to be maybe 10% faster, but I haven't tried on gcc-linaro yet.
[23:05] <wgrant> jelmer: The current longpoll implementation means that each MP page (and hopefully eventually more than just MP pages) keeps a persistent HTTP connection
[23:05] <jelmer> I'm in the lp team, but I haven't seen any issues with longpoll IIRC
[23:05] <wgrant> Apparently it's exceptional to have lots of LP tabs open.
[23:06] <wgrant> (since firefox limits concurrent connections to each hostname to 6)
[23:16] <cody-somerville> hmm... I think my test run has hung on setting up something in the functional layer :(
[23:40] <wgrant> abentley: Scanning lp:launchpad (deleting the branch and truncating branchrevision cascade each time) takes 2:15 with your insert_many, and 1:55 with Storm bulk Insert.
[23:42] <wgrant> http://paste.ubuntu.com/846588/ is the diff
[23:42] <wgrant> That Storm rev is just lp:~wgrant/storm/bulk-insert merged into the normal LP storm branch.
[23:43] <abentley> wgrant: well, I'll certainly look into that on my next workday.  Which is actually Tuesday.
[23:44] <wgrant> abentley: Oh, Canada has Monday off too?
[23:44] <wgrant> Thought that was just the US.
[23:44] <wgrant> k
[23:44] <wgrant> The difference may be more pronounced on prod, where there's greater DB latency than a UNIX socket.
[23:44] <abentley> wgrant: Yeah, Family Day.
[23:44] <wgrant> ... intriguing.
[23:45] <wgrant> (er, truncating revision, not branchrevision, obviously)
[23:45] <abentley> wgrant: Well, Ontario has it, anyway.  This stuff varies by province.
[23:45] <wgrant> Ah
[23:59] <cody-somerville> \o/ yay Family day.