[00:02] <wgrant> poolie: Indeed.
[00:02] <wgrant> Looks fixed.
[00:21] <poolie> i'm going to update the bug then
[00:27] <wgrant> poolie: Thanks.
[00:30] <poolie> thank you very much
[00:36] <wgrant> Huh.
[00:37] <wgrant> We are now in the longest downward Critical bug trend since May.
[00:40] <poolie> stop the line
[00:40] <poolie> i am curious how many i have personally fixed, caused, and filed
[00:41] <poolie> not quite enough to search right now though
[00:46] <huwshimi> wgrant: wow, is our bug submission form broken or something?
[00:46] <StevenK> Either that, or lifeless has stopped esclating for some reason.
[00:48] <huwshimi> StevenK: Quick, someone land a branch with the critical status removed
[02:22] <lifeless> wow
[02:22] <lifeless> 53 cleanups in an LP test case.
[02:22] <lifeless> anyone spot something a little wonky there?
[02:22] <wgrant> Where?
[02:23] <lifeless> self.case._cleanups
[02:23] <lifeless> my call to sync barfed
[02:23] <lifeless> I'm investigating why
[02:23] <lifeless> there are 53 cleanups registered, but only 14 unique functions amongst them
[02:23] <wgrant> "only"
[02:23] <lifeless> 14 is a reasonable number
[02:24] <lifeless> 53 less so
[02:25] <lifeless> ahha
[02:25] <lifeless> setUp is being called twice.
[02:28] <lifeless>  https://bugs.launchpad.net/testtools/+bug/882884 about the lack of alerting
[02:28] <_mup_> Bug #882884: setUp being called twice is not an error <testtools:Triaged> < https://launchpad.net/bugs/882884 >
[02:29] <lifeless> test run time was 1912->2326 or 4h10, so the sync() isn't a perf issue
[02:30] <wgrant> Great.
[02:30] <lifeless> the reason I noticed this setUp twice thing was the sync() failing due to queue not existing
[02:31] <lifeless> which should make you scratch your head :)
[02:33] <StevenK> wgrant: So all I did was add 'with person_logged_in(team.teamowner):' before create_initialized_view(), and it blows up :-(
[02:33] <lifeless> aieee
[02:33] <lifeless> check out PullerBranchTestCase.setUp()
[02:34] <lifeless> this is what super() is for
[02:36] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2126BZR113161
[02:36] <wgrant> Most useful OOPS ever :)
[02:36] <wgrant> lifeless: Hah
[02:47] <lifeless> that oops isn't rendering for me
[02:49] <wgrant> It takes about 15 minutes.
[02:49] <lifeless> wow
[02:49] <wgrant> It's also empty.
[02:49] <lifeless>  /o\
[02:50] <lifeless> ugh, rosetta_branches_script_oopses still sees too many.
[02:50] <lifeless> wtf is going on there
[03:10] <lifeless> I think I found a wabbit bug
[03:10] <wgrant> Uhoh.
[03:10] <lifeless> CaptureOops uses an autodelete exchange
[03:11] <lifeless> it uses Receiver() to suck messages out of a queue bound to that exchange, also autodelete.
[03:11] <lifeless> the Receiver is given a brand spancing new connection
[03:11] <lifeless> unless amqplib has die die die hidden connection pooling (I'm about to check this)
[03:12] <lifeless> then when the Receiver closses its connection, the queue and exchange should be untouched
[03:12] <wgrant> You're relying on autodelete to take effect immediately?
[03:12] <wgrant> I'm not sure that immediate reaping is guaranteed by the spec.
[03:13] <lifeless> no
[03:13] <lifeless> I'm being fucked by it taking effect when a different connection is closed
[03:13] <wgrant> Ah
[03:13] <lifeless> so connection A:
[03:13] <lifeless>  declare exchange
[03:13] <lifeless>  declare queue
[03:13] <lifeless>  bind
[03:13] <lifeless> connection B
[03:14] <lifeless>  send
[03:14] <lifeless> connection C
[03:14] <lifeless>  send sentinel
[03:14] <lifeless> connection D
[03:14] <lifeless>  consume from queue
[03:14] <lifeless> connection E
[03:14] <lifeless>  send sentinel - 404 no such exchange
[03:14] <lifeless> connection A is still open at this point
[03:15] <lifeless> sound like a bug to you ?
[03:17] <wgrant> "auto-delete: the queue will get deleted as soon as no more subscriptions are active on it."
[03:17] <lifeless> ugh
[03:17] <lifeless> ok, fail-to-understand
[03:17] <lifeless> fair enough
[03:18]  * lifeless reworks that part, again.
[03:21] <lifeless> wgrant: that was in the amqplib docstring I guess? a quick google hadn't found that for me
[03:23] <wgrant> lifeless: Wikipedia.
[03:23] <lifeless> *blink*
[03:25] <wgrant> I know, the canonical protocol reference.
[03:32] <wallyworld_> wgrant: StevenK: buildbot weirdness. you seen that failure mode before?
[03:33] <wgrant> wallyworld_: Someone or something turned off postgres.
[03:33] <wgrant> See #-ops
[03:33] <wallyworld_> ah ok thanks
[03:47] <wgrant> Hmm.
[03:48] <wgrant> Librarian 500s locally :(
[04:17] <StevenK> I guess create_initialized_view doesn't like with person_logged_in
[04:18] <StevenK> bzr grep doesn't support -{A,B,C} :-(
[04:56] <StevenK> Ah ha, I was right.
[04:56] <StevenK> create_initialized_view() returns anonymous views
[04:58] <wgrant> Doesn't it take a user kwarg?
[04:59] <StevenK> create_initialized_view()'s docstring sucks
[04:59]  * StevenK tries user
[05:00] <StevenK> wgrant: It does not
[05:00] <mwhudson> the whole area is confusing
[05:01] <mwhudson> StevenK: you want the principal argument though
[05:02] <StevenK> But that didn't work either
[05:09] <lifeless> wgrant: oops still hasn't rendered
[05:10] <StevenK> mwhudson: principal should be a IPerson or something else?
[05:12] <mwhudson> StevenK: yes
[05:12] <mwhudson> StevenK: sorry, have to run -- i think maybe IParticipation(person) works?
[05:12] <wgrant> lifeless: Heh
[05:25]  * lifeless throws useoops at ec2 again
[05:25] <lifeless> and EOW
[05:26] <StevenK> AH
[05:29] <mwhudson> IPrincipal, rather
[05:30] <StevenK> mwhudson: Thank you for the principal hint -- you need *both* with person_logged_in and principal specified in c_i_v()
[05:44] <wgrant> wallyworld_: Around?
[05:44] <wallyworld_> yes
[05:45] <wgrant> You know how you added the feature-flagged pillar role private bug visibility rules?
[05:45] <wallyworld_> yes
[05:45] <wgrant> Those only apply to the task search stuff. Bug.userCanView has its separate implementation.
[05:45] <wgrant> Not behind a flag.
[05:45] <wgrant> And slightly different.
[05:45] <wgrant> I'm reimplementing userCanView in terms of the task search query.
[05:45] <wallyworld_> was the bug usercanview done separately
[05:45] <wgrant> Which will drop the non-flagged owner visibility rule.
[05:46] <wgrant> Yes, it was done a yearish ago.
[05:46] <wgrant> Currently the bug pages are pretty useless, because all the tasks are invisible.
[05:46] <wgrant> So I don't think removing this is going to be much of a loss.
[05:46] <wgrant> But I wonder if you have any thoughts on the matter.
[05:46] <StevenK> Oooh, if they're invisible, can we ignore them?
[05:47] <wallyworld_> so you are looking to remove the current bug usercanview?
[05:47] <wallyworld_> and replace with something that matches the bug task role visibility rules
[05:47] <wallyworld_> ?
[05:48] <wallyworld_> it would have to be a union of those task rules?
[05:48] <wgrant> Yes.
[05:48] <wgrant> Hm?
[05:48] <wallyworld_> so if the user can see any task, they can see the bug
[05:48] <wgrant> I'm just using get_bug_privacy_filter.
[05:48] <wgrant> Right.
[05:48] <wgrant> The privacy filter already just looks at Bug.
[05:48] <wgrant> because tasks don't have separate visibility.
[05:48] <wgrant> (ignoring the fact that we exclude tasks for inactive products normally)
[05:49] <wallyworld_> i can't recall the details of get_bug_privacy_filter - let me just check the code
[05:49] <wgrant> It takes a user and produces a condition that restricts Bug to those visible to the user.
[05:50] <nigelb> I wish launchpad was less noisy about expiring memberships. Or I could go click "Hey, I understand. Stop warning me!"
[05:50] <wallyworld_> you going to keep the feature flag protection?
[05:50] <wgrant> wallyworld_: I'm not changing that bit of get_bug_privacy_filter. The first branch will not change it at all.
[05:50] <wgrant> It will just reuse the task search rules for Bug.userCanView.
[05:50] <wgrant> So yes, the flag protection will be preserved.
[05:51] <wallyworld_> it all sounds good to me. it doesn't make sense if the use can see an empty bug which is what i think you are saying happens now
[05:52] <wallyworld_> and it makes sense when you consider we are going to only single pillar private bugs
[05:52] <wallyworld_> i guess i should have done this change within the original branch
[05:54] <wgrant> Well, this should have been done years ago :)
[05:55] <wallyworld_> better late than never
[05:55] <wgrant> Indeed.
[05:56] <wallyworld_> wgrant: so when you do this, the fflag can be turned on i assume
[05:56] <wallyworld_> ah, it's on for !launchpad
[05:57] <wgrant> It's on for ~launchpad.
[05:57] <wgrant> And can only be on for trusted people.
[06:03] <wgrant> wallyworld_: Several tests rely on it, unfortunately :(
[06:03]  * wgrant hacks around.
[06:04] <wallyworld_> wgrant: ah, yes. not surprising. i had similar issues yesterday. drove me crazy
[06:05] <wallyworld_> at least there are tests :-)
[06:05] <wgrant> Indeed.
[06:05] <wgrant> Most of these tests aren't too ugly, either.
[06:05] <wgrant> Just a bit awkward in the transitional period.
[06:08]  * wgrant stabs LaunchBag.
[06:37] <wallyworld_> StevenK: i'd prefer it if your tests iterated over the policies in OPEN/CLOSED_TEAM_POLICY and did the checks
[06:38] <wallyworld_> btw, it only ended up being a few lines to fix c i v for Person+index ?
[06:40] <StevenK> wallyworld_: So it would seem, yes. And I'll look into that.
[06:41] <wallyworld_> StevenK: thanks. you should just add a for loop to you current tests
[06:42] <StevenK>  Right.
[06:49] <wallyworld_> StevenK: i think the tests should be beefed up to test that the edit link is a) there and b) has the expected url.
[06:49] <wallyworld_> this can be easily done by giving the link an id and doing a find_tag_by_id() in the test
[06:50] <wallyworld_> the same could be done for the message text. give the text node an id and check for that rather than the actual text wording
[06:50] <wallyworld_> this allows the wording to be changed and the test still passes
[07:14] <StevenK> wallyworld_: Do you want to put all of that on the MP and I'll sort it all out on Monday morning?
[07:14] <wallyworld_> StevenK: will do. have a good weekend
[07:14] <StevenK> wallyworld_: You too :-)
[07:15] <wallyworld_> i would if we had a better ajax story around partial page refreshes :-(
[07:15] <nigelb> Australia is EOD already? *jealous*
[07:15] <wallyworld_> haha
[07:36] <proyvind> hello, dear launchpad developers! long time launchpad user, first time "caller" here..
[07:36] <proyvind> I'm currently wondering about plans for git support in bazaar
[07:37] <proyvind> how are the actual plans for this, has any specific plans been made? has any work taken place? what's the state? will there be any priority given to focus on adding any of this upstream? :)
[07:38] <proyvind> (and just to be clear, yes, I am asking about support for git in place of bazaar, not support for external git branches ;)
[07:56] <adeuring> good morning
[12:10] <bac> hi adeuring
[12:11] <adeuring> hi bac
[12:11] <bac> adeuring: i'll take wgrant's MP...confirming you aren't working it
[12:11] <adeuring> bac: no , I did not look at it
[12:12] <bac> adeuring: it is the only one outstanding.  cool.
[12:19] <bigjools> I just added another :)
[12:23] <bigjools> I am going for lunch though, so no rush, back later
[13:31] <deryck> adeuring, ping for standup
[13:31] <danhg> flacoste
[13:31] <adeuring> deryck: oops, sorry
[13:31] <deryck> np
[14:40] <adeuring> abentley: I think "this.current_batch.mustache_model.bugtasks.length + 1" in line 113 is wrong. Shouldn't that be "... -1"?
[14:40] <adeuring> (line 113 of the diff)
[14:41] <adeuring> abentley: no, that should be "+0"...
[14:41] <abentley> adeuring: So, the +1 is trying to compensate for start being 0-indexed.
[14:41] <adeuring> abentley: right. But for 5 results and start = 0, we want to show "results 1-> 5"
[14:41] <adeuring> while we get "1 to 6"
[14:42] <adeuring> abentley: just click on any of the links ;)
[14:42] <abentley> Hmm, so why does it look right in use?
[14:42] <adeuring> and compare the number in "n->m of k" with the real number of results ;)
[14:42] <abentley> adeuring: that's an estimate, though.
[14:43] <adeuring> abentley: well, k is an estimate (at least for StormRangeFactory), but we known the number of results in the batch precisely
[14:44] <abentley> adeuring: You're right, I'll fix it.
[14:44] <adeuring> abentley: cool, thanks
[14:46] <adeuring> abentley: another quirk: For the first batch, the "first" and "previous" links are gray, but still active. "unlinking" them is something for antother branch, I assume?
[14:46] <adeuring> (same for the last batch and the last/next links)
[14:47] <abentley> adeuring: I would prefer if the CSS was fixed so that inactive links don't show as links.
[14:48] <adeuring> abentley: right, makes sense. So, r=me, and file a bug about the links?
[14:49] <abentley> adeuring: Thanks.  I'll file a bug.
[15:05] <abentley> deryck: could you please ec2land https://code.launchpad.net/~abentley/launchpad/display-cleanup/+merge/80621 ?
[15:05] <deryck> abentley, sure
[15:06] <abentley> deryck: thanks.
[15:06] <deryck> abentley, np!
[15:10] <flacoste> when running make (after a make clean) on latest devel, i get the following error:
[15:10] <flacoste> awk: (FILENAME=lib/lp/contrib/javascript/yui3-gallery/gallery-accordion/gallery-accordion.js FNR=2916) fatal: cannot open file `lib/lp/contrib/javascript/mustache.js' for reading (No such file or directory)
[15:11] <flacoste> ah
[15:11] <flacoste> nm
[15:11] <flacoste> it's a symlink
[15:11] <flacoste> i need to update sourcecode...
[15:11] <flacoste> though
[15:11] <flacoste> doh
[16:26] <flacoste> is it just me or make run-testapp is broken?
[18:14] <abentley> deryck: sorry I've been invisible.  I went home because my ISP wasn't reporting an outage anymore, but it turns out the outage is now my problem.
[18:14] <deryck> abentley, no worries.
[18:14] <abentley> deryck: did you want to chat?
[18:48] <deryck> flacoste, I don't get any errors doing make run-testapp, but the test in the browser hangs for me, seeming to never connect.
[18:48] <flacoste> deryck: well, that's a step beyond me :-)
[18:48] <flacoste> deryck: do you remember doing anything special for the pgbouncer change?
[18:49] <deryck> flacoste, yeah. :)  I didn't do anything special at all.  Update devel.  make and then make run-testapp.
[18:49] <flacoste> deryck: i mean more like a month ago when pgbouncer landed
[18:49] <deryck> I usually do a make by itself first out of habit, just to see if I hit any errors.
[18:49] <deryck> oh
[18:50] <deryck> flacoste, hmmmm, no I don't think so.  I don't recall anything special.
[18:58] <deryck> bac, hi.  I've got a pretty easy js branch if you have time to review it.
[18:58] <bac> deryck: i'd be happy to
[18:58] <deryck> bac, awsome, thanks!  https://code.launchpad.net/~deryck/launchpad/orderbybar-integration-fixes/+merge/80704
[18:59] <bac> deryck: 3600+ lines?
[18:59] <deryck> bac, hmmm, no.
[18:59] <deryck> bac, wonder what I did.  let me see.
[19:00] <bac> good, b/c 3500 is my absolute limit on JS or soyuz branches
[19:01] <deryck> bac, hmmm, the MP is trying to merge into lp:~deryck/launchpad/devel.  I don't know what I did wrong.
[19:01] <nigelb> bac: what happens for longer? stack overflow? :)
[19:01] <deryck> I didn't even know I had my own devel. ;)
[19:01] <deryck> bac, let me try to sort out the mp.
[19:01] <bac> deryck: cool.  ping me
[19:02] <danhg> flacoste
[19:06] <deryck> bac, try this one:  https://code.launchpad.net/~deryck/launchpad/orderbybar-integration-fixes/+merge/80705
[19:09] <bac> deryck: did you run the linter?
[19:09] <deryck> bac, I thought I did.  Let me check.
[19:09] <bac> deryck: i see some things that jtv just fixed up in a huge branch.  he'd cry if you introduce more.
[19:11] <deryck> bac, yeah I see 4 or 5 CSS lint errors.  I can fix those, assuming I understand them.
[19:11] <bac> thx
[19:12] <bac> deryck: nothing uses this yet, correct?  so there is no way for me to see it working?
[19:12] <deryck> bac, no, nothing uses it.  Just the test file to run, but it moves quick, so you never really see the widget.
[19:13] <deryck> bac, ok, bzr push'ed the CSS fixes.
[19:14] <bac> deryck: looks good
[19:15] <deryck> bac, awesome, thanks!
[20:53] <nigelb> flacoste: Hey, around?
[20:54] <nigelb> flacoste: I've subscribed you and mrevell to https://blueprints.launchpad.net/ubuntu/+spec/community-p-summit.  We'd really like to have smoeone from lp in that session :)
[21:01] <flacoste> nigelb: great, we should be there
[21:03] <nigelb> \o/
[21:03] <nigelb> flacoste: Thanks :)
[21:32] <flacoste> test_clashingPOFileTranslatorEntries: benji that sounds like something you touched recentely no?
[21:33] <benji> flacoste: sounds like it, but I don't think I actually have; let me look to be sure
[21:34] <benji> flacoste: right, I haven't been in that region of translations
[21:39] <flacoste> benji: ok, was wondering about allenap latest email
[21:40] <allenap> flacoste, benji: I'm about to disable it. Want me to hold off?
[21:40] <flacoste> allenap: not from me
[21:51] <benji> allenap: I don't have enough context to have an informed opinion, so I don't object
[21:52] <allenap> benji: Cool, okay. I've just disabled it, and bug 883274 exists to track it. Fingers crossed that buildbot gets through this time.
[21:52] <_mup_> Bug #883274: test_clashingPOFileTranslatorEntries failing in buildbot, okay locally <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/883274 >
[21:52] <allenap> Cheerio everyone, have a good weekend.