[00:00] <sinzui> wallyworld_, wgrant. yes it is my fault https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1647/steps/shell_6/logs/summary
[00:01] <wallyworld_> sinzui: np. i'll fix
[00:01] <wgrant> Were the two branches landed in the wrong order?
[00:01] <sinzui> wgrant, bingo
[00:01] <wallyworld_> so no fix required, just restat bb?
[00:01] <wallyworld_> restart
[00:01] <sinzui> but they are both in place I  think, but they were landed independent too
[00:01] <wallyworld_> so it's my fault for messing up the dependencies :-)
[00:02] <wgrant> I guess run the tests locally to confirm.
[00:02] <wallyworld_> i had to resubmit both mps due to the first failure
[00:02] <wallyworld_> and something messed up i guess
[00:02] <sinzui> wallyworld_, we want to move account status to IPersonPublic...
[00:03] <wallyworld_> sinzui: from iPersonRestrictedView from memory
[00:03] <sinzui> this is another case were I considered placing it there since teams do not have accounts, then thought no, I do not want to clutter the interface
[00:03] <wallyworld_> oh for person and team to be separated properly
[00:05] <sinzui> wallyworld_, iPersonRestrictedView probably work, I was thinking public based on a from a discussion with flacoste. Public are attrs that are obvious from the knowledge that the team exists. It is as team, it is valid, and it does not have accounts (in this case)
[00:05] <wallyworld_> sinzui: just looked at the stdout - ec2 did indeed flag the tests as failing i think
[00:06] <wallyworld_> sinzui: i agree with the rationale you just outlined. IPersonPublic seems thebest place i think
[00:06] <sinzui> yep, I was watching buildbot independent of wgrant since I believed the issue was a cause by the branch landing before its dep
[00:07] <wgrant> sinzui, wallyworld_: It needs to public.
[00:07] <wgrant> Otherwise traversal to a private team will 403 instead of 404.
[00:08] <wallyworld_> sinzui: so given there's a code change, can i just to a testfix and lp-land, or do i need to rollback and do the ec2 dance again?
[00:08] <sinzui> land it as a testfix, but you need to do it after the failure
[00:08] <wallyworld_> please don't make me rollback again :-)
[00:08] <wallyworld_> sure
[00:09] <sinzui> buildbot does not notice a pre-emptive testfix :(
[00:09] <wallyworld_> understood. the wait will give me time to get it prepared
[00:09] <wgrant> sinzui: It should notice it.
[00:09] <sinzui> wallyworld_, and pqm-submit it
[00:09] <wallyworld_> sinzui: yes, i just do a bzr lp-land in such cases
[00:09] <wgrant> Even if it doesn't, you can just force.
[00:09] <sinzui> wgrant, I tried a preemptive fix a few months ago and it did not work
[00:10] <wgrant> sinzui: Hmm.
[00:10] <wallyworld_> wgrant: aren't you meant to be awol?
[00:10] <wgrant> sinzui: You have to add [no-qa], but it should work.
[00:10] <sinzui> wgrant, noted
[00:10] <mwhudson> wallyworld_: i don't think it's possible to be meant to be awol :)
[00:11] <wallyworld_> mwhudson: semantics!
[00:11] <mwhudson> wallyworld_: yes!
[00:11] <mwhudson> (sorry)
[00:11] <wallyworld_> i was being very lose with my use of the english language :-)
[00:11] <wallyworld_> no need to apologise, i'm normally a stickler for that sort of thing
[00:12] <wallyworld_> eg i HATE how the word "decimate" is misused all the time
[00:13] <sinzui> wallyworld_, once the tests are fixed, you can do this to skip the 4-6 hours in ec2: http://pastebin.ubuntu.com/768498/
[00:13] <wallyworld_> sinzui: bzr lp-land does the same thing :-)
[00:13] <sinzui> I did not know
[00:13] <mwhudson> wallyworld_: you are an epicentre of linguistic correctness!
[00:13]  * mwhudson hides
[00:14]  * wallyworld_ lols
[00:14] <sinzui> anything else I need to know wgrant, wallyworld_. Perhaps something about how to make buildbot complete in 1 hour?
[00:14] <wallyworld_> mwhudson: i bet you can't say that last sentence you just typed 10 times quickly :-D
[00:15] <wallyworld_> sinzui: the parallelisation of the test suite should help :-P
[00:15] <sinzui> PS. when I say awesome, Id not not mean as in hotdogs with mustard, I mean god-fearing awe
[00:18] <wallyworld_> noted :-)
[00:18] <StevenK> sinzui: Removing 80% of the test suite would get buildbot to an hour.
[00:19] <wallyworld_> i reckon the layer startup/teardown times contribute to a large slice of the time taken too, no?
[00:20] <lifeless> over the whole test suite, not so much
[00:20] <StevenK> Like 6 minutes of 4+ hours?
[00:20] <lifeless> the per-test setup/teardown overheads are pretty large though
[00:20] <wallyworld_> yes :-(
[00:23] <wallyworld_> sinzui: i think account_status_comment should also move, just to keep it with account_status. agree?
[00:23] <wgrant> "Total duration of profiled methods 3152.6 seconds."
[00:24] <wgrant> So there's only a little under an hour of layer (test)?{setup,teardown}
[00:24] <wgrant> DatabaseLayer.testTearDown                    13721 calls taking 2051.7s.
[00:24] <StevenK> An hour of setup and teardown? Faaaark
[00:25] <StevenK> 35 minutes removing and creating databases. Thanks lifeless.
[00:25] <wgrant> Not lifeless' fault.
[00:25] <wgrant> He only changed the names.
[00:25] <StevenK> Aw
[00:25] <wgrant> And added an extra template.
[00:25] <wallyworld_> StevenK: that setp/teardown is what i was alluding to earlier
[00:46] <huwshimi> erm http://blog.launchpad.net/
[02:55] <wallyworld_> lifeless: private team. i am the owner. i make someone else the owner, but in so doing i cannot see the team anymore. so at the end of the process, the owner has changed but i see a "you are not authorised" page. should we display a one-off "this has succeeded but you cannot see the team anymore" page?
[02:57] <wallyworld_> btw, this is after a change to allow owners to view the private team even if they are not members
[03:00] <lifeless> wallyworld_: just show the page normally; same as for bugs
[03:00] <lifeless> wallyworld_: erm, or actually, just redirect to launchpad.net/
[03:00] <lifeless> wallyworld_: perhaps with a notification explaining why
[03:00] <wallyworld_> lifeless: right. good idea. thanks
[03:06] <StevenK> So I have a private team. I have invited a public team to be a member. That should show up as a pending invitation, should it not?
[03:12] <wallyworld_> StevenK: i would have thought so
[03:13] <wallyworld_> what does it do in actuality?
[03:13] <wallyworld_> bear in mind i've discovered a few things today about team behaviour by reading to code so my knowledge is patchy
[03:14] <StevenK> wallyworld_: It doesn't seem to show it at all
[03:15] <StevenK> I'm wondering if that is expected before I dive into our security adapter
[03:15] <wgrant> It's expected.
[03:15] <lifeless> if the private team invites a public team, the private team should be listed on the public teams invitations list.
[03:15] <wgrant> Only members, private PPA subscribers and Launchpad admins can see private teams.
[03:15] <wgrant> That's changing.
[03:16] <lifeless> it won't be showing today, but it it should. :)
[03:16] <lifeless> there is a bug for this
[03:16] <wgrant> lifeless: But only shown to the public team's admins?
[03:16] <lifeless> right
[03:16] <lifeless> optional the public teams members too
[03:17] <lifeless> but not to the general public
[03:17] <wgrant> Right, which is not what you said :)
[03:17] <lifeless> (by optionally, I mean whatever falls out of the code cleanest)
[03:17] <lifeless> wgrant: EBRAINISTOAST
[03:17] <wgrant> Yeah.
[03:17] <lifeless> my config change has landed
[03:18] <lifeless> \o./
[03:18] <wallyworld_> ii thought when StevenK said "pending invitation" it mean that the private team would see a list of invitees who had not accepted yet. but is it the other way around?
[03:18] <wgrant> But you've seen what happens when one doesn't make completely unambiguous statements about privacy.
[03:18] <lifeless> hilarity?
[03:18] <wgrant> Pretty much.
[03:18] <lifeless> wallyworld_: both directions gain visibility
[03:19] <wallyworld_> ok
[03:20] <lifeless> slightly different rules about who sees what
[03:20] <lifeless> members can see superteams
[03:20] <lifeless> admins can see subteams
[03:20] <lifeless> something mumble mumble
[03:20] <lifeless> there is a bug
[03:23] <wallyworld_> several perhaps
[03:27] <StevenK> wgrant: Okay, so I'm seeing expecting behaviour -- I can test for it, or I can fix it.
[03:31] <StevenK> lifeless: ^
[03:32] <lifeless> EPARSE
[03:33] <wgrant> lifeless =1
[03:33] <wgrant> +1
[03:34] <nigelb> wgrant: Did you just reassign lifeless? :P
[03:34] <nigelb> Also, Morning!
[03:34] <wgrant> A regrettable mistake.
[03:34] <wgrant> Afternoon.
[03:34] <StevenK> wgrant: So, fix it?
[03:34] <wgrant> StevenK: I don't understand what you mean.
[03:35] <StevenK> wgrant: So, I have two choices. I can test that the current behaviour is correct. Or, I can fix it so that pending private teams are shown to the team admins and write tests for that case.
[03:36] <wgrant> Or you can leave the behaviour undefined until we finish defining the complete set of new private team behaviours.
[03:36] <StevenK> No test at all?
[03:36] <StevenK> Fair enough.
[03:37] <StevenK> This branch should fix the Person:+index MixedVisibilityErrors as it stands.
[03:43] <StevenK> Guido van Rossum  -  11:05 AM (edited)  -  Public
[03:43] <StevenK> Why do Python classes have both _mro_ and mro() ? What was I thinking at the time? Does anyone remember?
[03:43]  * StevenK laughs.
[04:35]  * StevenK breaks buildbot into small pieces
[05:00] <StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/person-index-mixed-visibility/+merge/85427
[05:36] <wallyworld_> StevenK: looking now
[05:38] <wallyworld_> StevenK: you should use  "if check_permission('launchpad.LimitedView', team)" in your super_teams method
[05:39] <wallyworld_> since this by default delegates to launchpad.View
[05:39] <wallyworld_> and is the required permission to know of a team's existence
[05:39] <StevenK> Why LimitedView?
[05:39] <wallyworld_> with LimitedView, a user can know of a team's existence and name, displayname etc
[05:39] <wallyworld_> but not any other private details
[05:40] <wallyworld_> so for bug subscribers etc, i precache launchpad.LimitedView permissions
[05:40] <StevenK> But these are super teams -- teams that the team in question is a member of
[05:40] <wallyworld_> ah, ok
[05:40] <StevenK> If you can see the team, you can see everything, so .View is the right choice
[05:40] <wallyworld_> yes, sorry. i think you are right
[05:41] <wallyworld_> so what was the issue before your branch?
[05:42] <StevenK> wallyworld_: People would see <public team>, <hidden>, <hidden>, <public team>
[05:42] <StevenK> When I added MixedVisibilityError, those <hidden> started raising them
[05:42] <wallyworld_> if the team in question (the one being viewed) is a member of those <hidden> teams, why weren't they visible?
[05:43] <StevenK> The person viewing the team page may not have permission to see the team
[05:43] <StevenK> But members of the team view their own page do.
[05:44] <wallyworld_> ok, so the user is viewing a public team that may be a member of a private team?
[05:44] <wallyworld_> and the user may not be able to see that private team
[05:44] <wallyworld_> ?
[05:44] <wallyworld_> so in that case we would render <hidden>?
[05:45] <StevenK> And raise a MixedVisibilityError, yes.
[05:45] <wallyworld_> if my assertions above are correct, i do think we should be using LimitedView permissions then
[05:45] <StevenK> The formatter uses View, and gives a link
[05:46] <wallyworld_> since moving forward, we will be looking to allow a user to view the existence of a private team that is in any public relationship the user can see
[05:46] <wallyworld_> the formatter should change to use limitedview
[05:46] <StevenK> And not link them?
[05:47] <wallyworld_> limitedview by default just delegates to view, so it's the same net effect
[05:47] <wallyworld_> they should still be linked
[05:47] <StevenK> And the user gets a 404 when they click the link?
[05:47] <wallyworld_> but for now, if a user with just limitedview clicks on the links, they get a 404
[05:47] <StevenK> That's what I'm trying to prevent
[05:47] <wallyworld_> we are yet to solve that one
[05:48] <wallyworld_> there's 2 issues - not rendering <hidden>, and making the link work
[05:48] <StevenK> Besides, the private team isn't in a public position
[05:48] <StevenK> It just has a public team as a member
[05:48] <StevenK> It doesn't have to be disclosed by that action
[05:48]  * wallyworld_ thinks
[05:49] <wallyworld_> which is different to a private team subscribing to a bug? yes, perhaps?
[05:49] <wallyworld_> or maybe not, since members of the public team should be able to know who the parent team is?
[05:49] <StevenK> It is, yes
[05:50] <wallyworld_> ok, so let's leave it as view for now and we can revisit later if required?
[05:51] <StevenK> I'm happy with that
[05:51] <wallyworld_> thought you'd say that :-)
[05:51] <wallyworld_> i thought it better to ask the question though just in case....
[05:51] <lifeless> or clarity 'disclosed' is -always- contextual
[05:52] <lifeless> you can disclose to the public, disclose to a team, disclose to project etc
[05:52] <wallyworld_> so here we are possibly disclosing to a team i guess
[05:54] <lifeless> anytime in a discussion if someone says 'disclose' unconditionally, you all have to drink.
[05:54]  * StevenK finishes his glass of water
[05:54] <StevenK> Is that what you had in mind?
[05:54] <StevenK> lifeless: What time is your flight, out of interest?
[05:55] <lifeless> StevenK: tomorrow?
[05:55] <StevenK> lifeless: Yah
[05:56] <lifeless> 0955 departure
[05:56] <lifeless> but I route via akl
[05:56] <lifeless> I arrive 1430
[05:56] <StevenK> It's what, 30 minutes to AKL?
[05:56] <lifeless> at which point I will be tearing vodafone a new hole amongst other .au business
[05:56] <StevenK> ... why?
[05:57] <lifeless> because, a year after I closed my postpay account with them and moved countries, they started emailing me invoices
[05:57] <StevenK> Haha
[05:57] <lifeless> now, 1 month after, I could understand, and would have paid without much thought.
[05:57] <lifeless> a year later? WTF.
[05:57] <lifeless> actually 14 months or some odd number.
[05:57] <lifeless> Anyhow, lots.
[05:58]  * lifeless is extremely unimpressed
[05:58] <lifeless> I woul dhave rung from here, but their phone system is worse than loading a 3d game on a 16Kb spectrum
[05:58] <lifeless> I didn't want to use all my skypeout credit for a year while on hold
[05:59] <wallyworld_> StevenK: with the test_private_superteams_shown() test, i'd like to see another team created that would be <hidden> but is filtered out, since the other tests simply check if the portlet is there or not
[06:00] <wallyworld_> i guess the tales does that though
[06:00] <wallyworld_> ie indirectly tests that code path
[06:00] <StevenK> lifeless: When I moved to Parramatta, I called Telstra and cancelled the landline service, as well as getting a new service for the new place. Fast forward two months, and I get a bill for the landline at the old place, filled with calls after I moved out.
[06:00] <lifeless> StevenK: win
[06:01] <StevenK> lifeless: I rang up and said "Please explain" and was told that they "forgot" to action my cancelation
[06:01] <StevenK> As way of apology, they wrote off the entire bill, which had one charge for the new landline on it.
[06:02] <StevenK> wallyworld_: So the TALES won't even show the portlet if there are no visible super teams
[06:02] <wallyworld_> StevenK: yes, i came to that conclusion too so i think it's ok
[06:03] <wallyworld_> StevenK: for a "proper" unit test, the super_teams() property on the view object really should be tested
[06:04] <wallyworld_> rather than relying on the template logic to indirectly test it
[06:04] <StevenK> wallyworld_: I'm happy to add an assert for that
[06:04] <StevenK> self.assertEqual([], view.super_teams) effectivelty
[06:04] <StevenK> *effectively
[06:04] <wallyworld_> StevenK: that would be great; hopefully there's an existing unit test for the view object you can add to simply
[06:05] <wallyworld_> ah, yes, that works too
[06:06] <wallyworld_> StevenK: r=me
[08:41] <cjwatson> wgrant: P-a-s> ah, OK, thanks.  Maybe if I get some time over the holidays ...
[08:42] <wgrant> cjwatson: That's likely the only way it's going to get fixed unless I get bored, yeah.
[08:42] <wgrant> :/
[08:57] <adeuring> good morning
[09:10] <mrevell> Mornin;
[09:11] <mrevell> oh, I fail at typing
[10:14] <jtv> allenap: ndt deployment request underway.  Liam is on it.  Thanks for dealing with that branch.
[10:15] <allenap> jtv: Tip top, ta :)
[11:36] <cjwatson> oh my, I didn't realise that maintenance-check.py relied on http://people.canonical.com/~ubuntu-archive/germinate-output/
[11:37] <cjwatson> I think I'll need to convert that to python-germinate as well for sanity and testability
[12:30] <cjwatson> bigjools: is it possible that r11088 fixed bug 599412?  It looks as though it ought to have done
[12:30] <_mup_> Bug #599412: populate-archive --component main doesn't work <derivation> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/599412 >
[12:35] <bigjools> cjwatson: yes, the commit msg says so :)
[12:35]  * bigjools fixorates
[12:36] <cjwatson> refers to bug 600165 instead, actually, so unnoticed dup
[12:36] <_mup_> Bug #600165: COPY archive creation ignores the specified component <derivation> <lp-soyuz> <qa-ok> <Launchpad itself:Fix Released by julian-edwards> < https://launchpad.net/bugs/600165 >
[12:37] <bigjools> yeah
[12:37] <bigjools> thanks for noticing
[12:37]  * cjwatson has been looking through soyuz bugs for things that might improve Ubuntu's life that are accessible to me to fix
[12:38] <bigjools> sounds like you need a rotation :)
[12:39] <cjwatson> the thought has crossed my mind, but I think I want to remain focused on things specifically beneficial to Ubuntu rather than LP as a whole; plus Steve might object :)
[12:39] <cjwatson> might consider it in a year or so
[12:48] <StevenK> cjwatson: I won't object, but I know you don't mean me. :-)
[13:11] <jtv> StevenK: actually I was wondering why you would ever object!
[13:11] <jtv> So a good thing you said it.
[13:18]  * cjwatson tests germinate 2.3 on mawson and confirms that the only differences are as expected
[13:19] <cjwatson> so I've followed up to that ticket to say that it's OK to upgrade cocoplum/germanium
[13:20] <cjwatson> jtv: can https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 be Status: Approved as well as having your Approved review?  It's still waiting on a buildbot upgrade before we can land it, but apart from that ...
[13:24] <jtv> cjwatson: coming
[13:25] <jtv> cjwatson: done
[13:29] <sinzui> I think I need to rollback 3 non-sequential revisions :(
[13:30] <cjwatson> jtv: ta
[13:33] <jtv> bigjools, wgrant: care to review?  https://code.launchpad.net/~jtv/launchpad/bug-903688/+merge/85485
[13:40] <bigjools> jtv: I can
[13:40] <jtv> That'd be great, thanks
[13:59] <jtv> Anyone know why I would get this error during "make schema" on a db-devel branch?  duplicate key value violates unique constraint "launchpaddatabaseupdatelog_pkey"
[14:03] <nigelb> someone broke something?
[14:03] <nigelb> I hope no one broke sampledata.
[14:04] <jtv> nigelb: maybe I did — don't know.
[14:04] <jtv> But I re-generated the updated sampledata based on db-devel sampledata, and it doesn't help.
[14:06] <jelmer> benji: hi
[14:06] <benji> hi jelmer
[14:07] <jelmer> benji: Are you still working on bug 808930 ?
[14:07] <_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/808930 >
[14:07] <jelmer> I've got a bug fix in that area, and I'd like to make sure our changes don't clash.
[14:07] <benji> jelmer: gmb has taken the helm of that one
[14:07]  * benji goes to fix the assignee in LP.
[14:07] <jelmer> gmb: Hey!
[14:07] <jelmer> benji: thanks
[14:08] <benji> np
[14:08] <gmb> jelmer: Hi. I'm only just getting up to speed on this bug, so it may well be that I have to tap on benji's shoulder a couple of times. But anyway.
[14:09] <jelmer> gmb: ok
[14:09] <jelmer> gmb: I've got a fix for the branch scanner which should at least make the bzr part of things no longer O(size-of-branch-history)
[14:10] <jelmer> gmb: that should help with the bug, but it will also likely clash with any changes you've already made
[14:10] <gmb> jelmer: Okay. So, I'd be inclined to tell you to get your branch landed; I'm not ready to land anythign yet, so I'm happy to clean up any clashes.
[14:11] <jelmer> gmb: Great, thanks.
[14:11] <jtv> Anyone know what would make a "make schema" on a db-devel branch violate unique constraint launchpaddatabaseupdatelog_pkey?
[14:13] <abentley> deryck: Do you think now is the right time to generalize ListingNavigator as we discussed with wallyworld?
[14:14] <deryck> abentley, jumping on call…. give me a minute to think about that.
[14:14] <abentley> deryck: sure.
[14:21] <deryck> abentley, I'm sorry, but I'm blanking on remembering the discussion with wallyworld_.  is this an email discussion?
[14:22] <abentley> deryck: Yes.  Let me see if I can dig up the subject.
[14:22] <abentley> deryck: "batch navigation question"
[14:23]  * deryck is looking at email
[14:24] <deryck> abentley, ok, right.  I absolutely think now is the time to do that work.
[14:24] <abentley> deryck: cool.
[14:26] <deryck> there are a couple minor bugs we still need to fix, but these are fairly shallow.  I may see if rick_h_ can be enlisted for this, to keep you free for this.
[14:27] <stub> (21:21:48) stub: jtv: Hmm... might need to add a step to reset the sequence.
[14:27] <stub> (21:22:19) stub: jtv: The value of the sequence would have been set from production with the new baseline?
[14:27] <stub> (21:24:45) stub: jtv: Although 'make schema' shouldn't care because the table will be empty...
[14:27] <stub> (21:25:24) stub: jtv: Have you rebuilt sample data and ended up with the contents of launchpaddatabaseupdatelog in it? That would make it explode (and would be a bug - need to exclude that table from sampledata too, along with launchpaddatabaserevision)
[14:28] <nigelb> wow. I did guess right. sampledata has some brokeness.
[14:30] <jtv> stub: yes, on two occasions I did “make newsampledata” and both times got 1 record for launchpaddatabaseupdatelog per database.
[14:30] <jtv> I'm about to try it with an unmodified db-devel schema.
[14:31] <stub> thought the sequence reset magic would take care of it?
[14:32] <jtv> Frankly I can't even find where the table gets created.
[14:32] <jtv> Whoops — the sampledata I build from db-devel is broken.
[14:33] <stub> jtv: The table is in the db baseline - launchpad-2209-00-0.sql
[14:34] <jtv> Looked there.  It's basically empty.
[14:34] <jtv> I figured the guts had moved somewhere else.
[14:36] <jtv> stub: broken baseline?
[14:36] <jtv> I thought the baseline used to be in that patch — but now I don't see that for 2208 either.
[14:37] <jtv> Ah wait — launchpad-2209-00-0.sql.  I was looking at patch-2209-00-0.sql.
[14:37] <stub> If you are on db-devel, 2208 shouldn't exist
[14:37] <stub> yer
[14:39] <jtv> I was just cross-checking with devel.
[14:42] <jtv> stub: fwiw I also looked for launchapddatabaseupdatelog in the sample data for devel & db-devel and did not find any mention.
[14:44]  * stub waits for trees to sync
[14:53] <jtv> bigjools: my buildfarm fix has passed soyuz & buildmaster tests.  Think that's enough for a landing?
[14:53] <bigjools> jtv: yes
[14:53] <jtv> Yee-haw.
[14:53] <bigjools> well - code perhaps
[14:54] <jtv> OK, running that too.
[15:01] <stub> jtv: So with a fresh tree and make schema, I get LaunchpadDatabaseUpdateLog with one entry with id 1 (from patch-2209-00-2.sql) and nextval('launchpaddatabaseupdatelog_id_seq') is 2.
[15:02] <jtv> I get the entry; haven't tried the sequence.
[15:02] <jtv> Presumably that's the part that's wrong.
[15:02] <jtv> But didn't you say that the table shouldn't be in the sample data at all?
[15:04] <stub> jtv: There is no need for it to be there.
[15:04] <jtv> Then how did it get there?
[15:05] <stub> jtv: I neglected to add it to the blacklist filter in database/schema/Makefile.
[15:05] <jtv> Is that something you could fix at the moment?
[15:05] <stub> sure
[15:06] <stub> jtv: So patches get applied, then we load sampledata. And if the sampledata contains rows they will conflict with any created by upgrade.py
[15:06] <sinzui> bac: gary_poster is it time to discuss milestones?
[15:07] <bac> sinzui: yes, sorry, our call ran long.  i'll skype you now
[15:07] <jtv> stub: thanks for working it out.  Got branches blocked on this, and tomorrow's my last day for the year.
[15:09] <stub> http://paste.ubuntu.com/769038/ should be the fix
[15:09] <stub> jtv: Want me to land that?
[15:10] <jelmer> gmb: actually, looking at the only OOPS for bug 808930 that I can find, it seems like that is in the access of the bzr graph
[15:10] <_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/808930 >
[15:10] <jtv> stub: yes please, assuming it's correct.  :)
[15:10] <jtv> stub: is the whitespace you removed significant?
[15:10] <gmb> jelmer: benji's theory, AIUI, is that the OOPS is a death-by-SQL problem.
[15:11] <stub> jtv: You can apply that locally and rebuild your sampledata while waiting to confirm (and even revert the change afterwards - the problem with your branch is the generated sampledata and you can land it without the makefile fix)
[15:11] <jtv> Right.  I'll try that.
[15:11] <gmb> jelmer: So I'm not sure whether your fix will help or not...
[15:11] <jelmer> gmb: yeah, that seems like the most likely cause indeed.. storing a giant (HUUUUGE) graph in a SQL table seems like a bad idea
[15:11] <stub> jtv: Seems to be working. I'll do a self approved landing now.
[15:12] <gmb> jelmer: Ssssh, you'll make whoever came up with that idea feel silly....
[15:12] <sinzui> bac: https://launchpad.net/glade/3.10
[15:12] <sinzui> bac: https://launchpad.net/grub/grub2
[15:13] <jelmer> gmb: IIUC it's that way because that's how bzr originally behaved
[15:14] <gmb> Yeah, I think that's the case.
[15:15] <jelmer> gmb: I'm sure you've seen https://dev.launchpad.net/Code/BranchRevisions ?
[15:16] <gmb> jelmer: Yes, I had. (I had repressed it)
[15:16] <jelmer> hehe
[15:16] <sinzui> bac: lifeless reported this https://bugs.launchpad.net/launchpad/+bug/644977
[15:16] <_mup_> Bug #644977: ProjectMilestone is inconsistent, confusing ui, can we just delete it? <confusing-ui> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/644977 >
[15:18] <rick_h_> benji: ping, have some time to do a voice chat on an api bug: https://bugs.launchpad.net/launchpad/+bug/808952
[15:18] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
[15:18] <allenap> gmb: Got time for a tiny review? https://code.launchpad.net/~allenap/launchpad/bugnomination-timeout-bug-874250-heat-death/+merge/85497
[15:18] <gmb> allenap: Sure thing
[15:18] <allenap> Ta
[15:18] <benji> rick_h_: sure.  Skype?
[15:19] <rick_h_> benji: sure, mitechie is my username
[15:19] <benji> rick_h_: calling
[15:24] <jelmer> gmb: Do you have time to review that avoid-revision-history branch? It should now be up at https://code.launchpad.net/~jelmer/launchpad/avoid-revision-history-2/+merge/85501
[15:25] <gmb> jelmer: I'll take a look once I've finished with allenap's.
[15:29] <jtv> stub: I seem to have working sample data now, thanks
[15:30] <stub> np. by branch has landed too.
[15:56] <sinzui> bac: https://launchpad.net/launchpad-project/+milestones is a mess
[15:56] <sinzui> while your idea is about declaring them to prevent the cruft from appears
[16:05] <jelmer> gmb: Merci
[16:06] <gmb> jelmer: De rien.
[16:26] <jtv> bigjools: lot of blockers on the deployment report tonight.  If we're going to get my fix out, looks like we'll have to cowboy.
[16:26] <bac> sinzui: regarding vouchers, the API they provide is not showing you having anything, which is consistent with the db dump neil provided.  so it looks like a problem between the shop and salesforce
[16:27] <sinzui> bac: I was replying to that. I was even going to take a screencap of a check out, but I cannot do that at the moment.
[16:27] <bac> sinzui: i'll buy some too and see if they materialize
[16:28] <sinzui> Maybe the ridiculous free gift has broken checkout for users that redeem vouchers
[16:47] <jtv> bigjools: arrrrgh.  Broken test in archiveuploader.  The ordering of a two-item recipients list on a notification email has changed.  :(
[16:47] <bigjools> hmmm
[16:47] <bigjools> sounds spurious, which is worse
[16:48] <jtv> Oh, yes it is worse: I was accidentally running that one on devel!
[16:48] <jtv> lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadToFrozenDistro
[16:53] <bigjools> yay?
[16:56] <jtv> bigjools: is that the sort of yay that conveys no joy at all?
[16:56] <bigjools> jtv: Archeryay
[16:57] <jtv> Ah, _that_ yay
[16:57] <jtv> Absolutely correct.
[17:02] <rick_h_> deryck: I've gotten this the last two times I tried to land the inline editor stuff: +bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
[17:03] <rick_h_> deryck: the test email comes back success, but that's the PQM test email?
[17:03] <rick_h_> deryck: sorry, bad paste https://pastebin.canonical.com/57048/
[17:03] <deryck> rick_h_, you need to look at the log file attached to the email from pqm.
[17:04] <deryck> rick_h_, either testfix or merge conflict most likely.
[17:04] <rick_h_> deryck: my bad, totally missed the attachments
[17:04] <deryck> given buildnot's record, you can guess what you'll get ;)
[17:05] <rick_h_> ah, actually getting that it doesn't like my commit message. Will check it out then. Thanks, blind today
[17:15] <deryck> rick_h_, can you look into bug 894726?  Should be trivial to linkify the tags listed.
[17:15] <_mup_> Bug #894726: Tags not linked on bug listing <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894726 >
[17:16] <rick_h_> deryck: sure thing
[17:17] <deryck> mrevell, for that bug ^^ do you care if we just link to the tag list from the new feature lists?
[17:17] <deryck> rick_h_, that's what I'm thinking, a simple link, rather than all the fancy filtering talk in the bug.
[17:17] <rick_h_> deryck: ah ok. Yea I was thinking that it's a bit more to do that.
[17:18] <sinzui> bac, did you succeed in checking out?
[17:19] <cjwatson> jtv: oh!  good, it's yay for me, it means that it isn't the fault of my new-python-apt branch
[17:19] <deryck> rick_h_, the link is just "?field.tag=$TAGNAME" -- though we *may* have some helper method to get you the link.
[17:19] <rick_h_> deryck: ok, I'm finishing getting my notes together for this bug report and I'll peek at it in a few
[17:20] <cjwatson> jtv: soyuz-set-of-uploads and xx-queue-pages fail for the same reason, and are harder to work around since they're doctests.
[17:20] <deryck> rick_h_, ok, thanks!
[17:20] <jtv> cjwatson: I fixed the test that broke for me.  With doctests I usually just sort to get deterministic output.
[17:23] <jtv> bigjools: I also ran tests for translations and archiveuploader, since they had (mentions of) BuildFarmJob.  Still, having that one test fail made me nervous about landing without waiting for the outcome of the full test run.
[17:23] <deryck> rick_h_, I'm also going to assign bug 894740 to you.  Should be a shallow js error fix.
[17:23] <_mup_> Bug #894740: bug heat contextual help opens in a new tab in chromium <bug-columns> <exploratory-testing> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894740 >
[17:24] <rick_h_> deryck: sounds good
[17:31] <cjwatson> jtv: yeah, it's just awkward in this case since the doctests are testing the entire formatted e-mail
[17:31] <deryck> adeuring, do we have a bug yet for the "only showing one order by button" bug?
[17:31] <bac> sinzui: trying now
[17:33] <rick_h_> deryck: benji just fyi, summary of the findings: https://bugs.launchpad.net/launchpad/+bug/808952
[17:33] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/808952 >
[17:35] <mrevell> deryck, re tags: Yeah, that seems like a good solution.
[17:35] <deryck> mrevell, thanks!
[17:40] <bac> sinzui: did you report the broken checkout?  mine broke too
[17:46] <adeuring> deryck: no, not yet, but I'll file one
[17:50] <deryck> adeuring, thanks!
[17:56] <cr3> is it supposed to take a while, like hours, after stopping emails for a subscription to actually stop receiving mail from that subscription?
[18:05] <lifeless> cr3: it could, under exceptional circumstances. More likely is that you have multiple subscription paths to the mails you are getting
[18:05] <jtv> cjwatson: got another spurious failure — archivesubscription-views.txt.  What happened?
[18:06] <cr3> lifeless: I've been cross checking with the Launchpad-Rationale in the email header, so I think I have the multiple subscription problem down. I'll be a bit more patient and check again tomorrow
[18:07] <cjwatson> jtv: that's odd, I don't think I got that failure and I ran all the soyuz tests
[18:09] <deryck> abentley, adeuring, rick_h_ -- FWIW, I'm done with looking over the bugs again (boy, did that take longer than expected!)
[18:09] <deryck> abentley, adeuring, rick_h_ -- and short of a few little UI issues that are easy to fix, we're in pretty good shape.
[18:09] <abentley> deryck: Yes, I agree.  Looked over them yesterday myself.
[18:09] <jtv> cjwatson: I'm not getting it on my local system either, or running just the soyuz tests in EC2.  Sounds like isolation problem.
[18:10] <abentley> deryck: A lot of the bugs are $foo is not linked.  Do we know if we actually want to link everything?
[18:12] <deryck> abentley, I don't think we know, so those are all marked low, except the tags one.  I don't think we should worry about them, unless mrevell and company have design ideas.
[18:12] <deryck> abentley, as I understand it, product team pushed back on linking everything, not knowing how to style the links.
[18:16] <benji> rick_h_: was eating lunch, looking now
[18:18] <rick_h_> benji: np, let me know if you think I should add anything else. Basically the type of object going in there was just Message and nothing else like I had hoped
[18:19] <jtv> bigjools: I landed my fix on devel as revision 14499.  But there's some real weirdness going on: a test that shouldn't have been affected failed for me once in EC2, and I can't seem to reproduce it.  I'll need to pack it in for the night though.
[18:19] <benji> rick_h_: so which branch in message_to_canonical_url_data is taken?
[18:19] <rick_h_> benji: it's the bugs.count() branch
[18:20] <rick_h_> benji: IMessage has a bugs property
[18:20] <bigjools> jtv: ok, get some sleep, rest well
[18:21] <jtv> thanks, see you tomorrow!
[18:22] <benji> rick_h_: so... the message isn't associated with a bug?  That seems strange.
[18:22] <sinzui> benji, that is historic cruft I think
[18:23] <rick_h_> benji: right, most messages are extended and assiciated through a tying table, bugmessage, butattachment do the tying to a bug
[18:23] <rick_h_> benji: but these are just plain messages created for the record it appears
[18:25] <benji> hmm, if we can figure out a way for message_to_canonical_url_data to figure out which bug is related then it could return an BugMessageCanonicalUrlData instance and all would be right with the world
[18:36] <abentley> benji: these messages aren't bug comments.  Are you sure they have (or should have) URLs?
[18:37] <benji> abentley: they don't now, but exposing them to the REST API may be the thing to do to fix this bug
[18:38] <rick_h_> abentley: benji yea, I mean they are messages viewable via the web and while not bug comments, might be useful/might expose kind of things
[18:38] <abentley> benji: I don't think we really want to track all the notifications that e.g. a bug status changed in the API.
[18:39] <benji> abentley: you might be right; in that case we'll have to figure out how to hide the notifications from the part of the API that can "see" them now (which is the source of the bug rick_h_ is working on)
[19:23] <bigjools> webops: when qastaging updates, does the bzr server restart? I already established that the librarian does not ...
[19:23] <bigjools> echan
[19:24] <thedac> bigjools: I will check
[19:49] <rick_h_> what's the right replacement for dir() on an object instance I can use to interrogate things?
[19:55] <abentley> rick_h_: dir(zope.security.proxy.removeSecurityProxy())
[19:56] <rick_h_> abentley: cool thanks
[20:00] <abentley> deryck: I'm thinking of switching "var namespace = Y.namespace('lp.app.listing_navigator');" to "var module =…" for consistency with the test code.  Thoughts?
[20:08] <rick_h_> abentley: does the server side mustache stuff allow for the {{#field}}{{.}}{{/field}} syntax?
[20:09] <abentley> rick_h_: Yes, AIUI, the dot is supported.
[20:11] <deryck> abentley, yeah, I like module better than namespace.
[20:12] <lifeless> abentley: deryck: so, after using moustache for a bit; do you like it? has it saved time / costed time but added features / <other> ?
[20:14] <deryck> lifeless, I find it tremendously easier to edit than tal. that seems time saving to me.
[20:15] <deryck> lifeless, it has it's own syntax oddities to me.  but generally, I've liked using it a lot.
[20:15] <abentley> lifeless: Like JavaScript, I like the capability it gives, without being a big fan of the language itself.  Both the JavaScript and Python implementations have bugs that entail pretty gross hacks, and the JavaScript implementation is noticeably slow.
[20:16] <lifeless> abentley: do we need to fix those before we advocate for wider use; or should we look for a better alternative with the same capabilities?
[20:18] <rick_h_> the nice thing is that handlebars (mustache improved) will be included in YUI 3.5 as Y.handlebar and the 3.5 PR1 was released today
[20:18] <abentley> lifeless: The JavaScript slowness is potentially a dealbreaker.  Other than that, I'd cautiously recommend it.
[20:18] <rick_h_> I'm not sure though on a pure python implementation
[20:18] <abentley> rick_h_: There's no pure Python implementation, AFAICT.
[20:18] <lifeless> of handlebars ?
[20:18] <abentley> rick_h_: I would be very reluctant to use handlebars on the client side while using mustache on the server side.
[20:19] <abentley> lifeless: right.
[20:19] <rick_h_> abentley: agree
[20:19] <lifeless> how big is the delta? could we sensibly tweak moustache (python) into handlebars (python) ?
[20:19] <deryck> I thought handlebars was the same as mustache,  but more performant.  that compatibility-wise they were the same.
[20:20] <abentley> lifeless: handlebars is a superset of moustache, if what I've read was true.
[20:20] <abentley> lifeless: So the risk would be accidentally using handlebar-specific features.
[20:20] <abentley> lifeless: And then having them break server-side.
[20:20] <lifeless> http://thinkvitamin.com/code/getting-started-with-handlebars-js/ is a post from the handlebars author
[20:22] <lifeless> it appears to be totally separate but inspired by
[20:23] <rick_h_> lifeless: well the front page of handlebars says "Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars, and start taking advantage of the extra Handlebars features."
[20:23] <rick_h_> but yea, you'd get used to all the good bits of handlebars and then lose them on the server side
[20:23] <lifeless> intruiging
[20:23] <lifeless> so the question to me, is how big is that delta
[20:23] <rick_h_> so might not work out after all, I had secretly hoped there was something server side for it
[20:23] <rick_h_> lifeless: I'm going to guess a bit since handlebars allows things like moving up/down the call stack
[20:24] <lifeless> we could use node.js on the server
[20:25] <rick_h_> just skip the server side initial rendering ;-)
[20:25] <lifeless> thats harder to swallow
[20:25] <lifeless> per code.google.com/web/ajaxcrawling/docs/getting-started.html which flacoste dug up the other day
[20:26] <lifeless> one thing we could do is dev/test with moustache.js but use handlebars as an accelerator in [qa]staging+prod
[20:26] <lifeless> that has its own risks, of course
[20:26] <rick_h_> I still think the answer isn't to get the bug listings crawled, but the bugs themselves and that there should be a way to get that information to a crawler without being visible
[20:26] <rick_h_> a paginated list of bugs is going to change around over short periods of time and not be a good landing/search page result anyway
[20:27] <lifeless> yes and no
[20:27] <lifeless>  /+bugs is reasonably constant
[20:27] <lifeless> and we want its changes to be indexed anyhow because of 'heat'
[20:27] <lifeless> other arbitrary searches - yeah, 'meh'. OTOH they don't have much juice today.
[20:27] <rick_h_> I thought that was going away/getting altered though
[20:28] <lifeless> what is a concern though is ensuring that the bugs get indexed
[20:28] <lifeless> rick_h_: its been less special cased.
[20:28] <lifeless> rick_h_: but as a page its not going away
[20:28] <lifeless> gotta run. great chatting - sounds like fun stuff to play with. Ciao.
[20:28] <rick_h_> ic, I'll have to look sometime though. I wonder if there's a better way to note/point the robot to something like a canonicalurl for all bugs on the page
[20:28] <rick_h_> have fun lifeless
[20:43] <deryck> gah!  I just want to run tests in lazr.batchnavigator and have no clue how to build it.  it hates me.
[20:44] <deryck> gary_poster, perhaps you can help here ^^ ?
[20:44] <deryck> just looking for simple build instructions for a lazr package.
[20:45] <benji> deryck: I think it's buildout-based, you'll want to bootstrap it and then run bin/buildout and then bin/test will run the tests
[20:45] <gary_poster> deryck, I dunno that package.  we used to have instructions to put a file on how to build the package
[20:45] <gary_poster> deryck, and it would link to this wiki page:
[20:46] <deryck> benji, yeah, I tried that.  both with symlnks to download-cache and eggs and not.  it blows up regularly and angrily :)
[20:46] <gary_poster> deryck, https://dev.launchpad.net/HackingLazrLibraries
[20:46] <deryck> benji, I think it's expecting something installed system wide and I can't work out what.
[20:46] <gary_poster> deryck, I think the file was HACKING.txt
[20:46] <deryck> gary_poster, thanks for the link.  looking....
[20:46] <gary_poster> Dunno if that is there
[20:46] <gary_poster> welcome
[20:47] <benji> deryck: it may actually be the opposite, it may be assuming that you're using a clean Python (or virtualenv)
[20:47] <deryck> ah hmmmm
[20:50] <rick_h_> abentley: doesn't appear that it supports the {{.}}, had to convert things to a dict and use the key and that works
[20:53] <wallyworld_> sinzui: jcsackett: can we make the standup 30 minutes earlier today? i have a denist appt with the kids i need to get to
[21:07] <sinzui> wallyworld_, sure
[21:07] <sinzui> wallyworld_, 1. the nasty rollback is in build bot
[21:08] <sinzui> wallyworld_, 2. I have sent of the non-feature test refactoring to ec2
[21:08] <sinzui> wallyworld_, 3. i have reproduced the traversal issue I saw in qastaging
[21:09] <sinzui> wallyworld_, do you have time to mumble now about how we want to test this non-obvious issue in the future
[21:10] <deryck> benji, that was it!  Had to use virtualenv for clean env, and all is well.  Thanks!
[21:11] <benji> deryck: cool; many buildout-based projects are like that, depending on a clean environment for sane reproducable builds
[21:26] <wallyworld_> sinzui: sorry, just was having breakfast. we can discuss on the call
[21:27] <sinzui> okay
[22:01] <sinzui> jcsackett, mumble?
[22:02] <jcsackett> sinzui: oh, right. be on in just a moment.