[00:03] wgrant: I'm not sure -- if I print the information_type in the second line of the test it's USERDATA. So it should be that for everything after, right ... [00:03] StevenK: Not if the factory caused the caching to occur [00:07] wgrant: i think you told me a while ago that ajax changing a bugtask's target for a single-bugtask bug should cause a page refresh [00:08] this appears to not be the case currently [00:08] Hmm [00:08] It was, but perhaps it broke. === wallyworld_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugs: 3.47*10^2 [00:09] * mwhudson grrs at trying to search for a bug containing the string "403" [00:11] wgrant: i should file a bug then? [00:14] mwhudson: Probably. [00:16] /* ChoiceSource doesn't seem to function in IE at present, breaking [00:16] * all of this AJAX except the assignee and product pickers. [00:16] */ [00:16] bet that comment makes sinzui happy [00:18] Nah [00:18] I added that just a couple of months back [00:18] Because we were about to fix ChoiceSource, and it was entirely broken [00:18] wgrant: it looks like there is code to do a refresh around bug task _deletion_ [00:18] So it would have been a major regression to enable it there [00:18] nothing around reassignment [00:19] sinzui: Can that be removed now? [00:19] mwhudson: There's meant to be a hook on the context URL change [00:19] ah [00:20] i'm only looking in bugtask_index.js [00:20] would it be somewhere else? [00:20] It came for free when that was implemented in recipes. [00:20] ah [00:22] Y.on('lp:context:web_link:changed', function(e) { [00:22] window.location = e.new_value; [00:22] }); [00:24] That's the one. [00:24] Perhaps it's not updating the cache somehow. === matsubara-afk is now known as matsubara [00:24] let's see if it works for recipes [00:24] Indeed. [00:25] my survey says no [00:27] yeah [00:27] editing the name isn't updating [00:27] LP.cache.context.web_link [00:27] File a bug, I'll criticalify it [00:46] i think it probably is [00:46] because e.g. the name is not being updated in the cache either [00:46] :( [00:47] wgrant: do you know where the "update the cache on lp_save" stuff is wired up? [00:48] this function called update_cached_object looks promising [00:49] uhhh [00:49] if (cached_object.self_link === full_uri) { [00:49] It matches the cache entry based on URI? [00:49] That's going to work well :) [00:49] yeah [00:50] from the "did this ever work!?" department... [00:53] It looks like it might have been broken for a year [00:53] But surely not [00:55] do you have a suspect change? [00:55] [r=jcsackett][bug=490826, 721064, [00:55] 724004] Keep LP.cache up to date with launchpadlib PATCH changes, [00:55] and raise update events. [00:55] is what i found that touched that area [00:55] but surely that's the basic functionaliy [00:57] 14634 is interesting [00:57] ah yes [00:58] it broke the notification because entry.lp_original_uri is now more correct? [00:58] I assume so [00:59] It's not longer updating the cache [00:59] Because it uses the post-redirect URI [00:59] I suspect [01:00] rings true [01:02] not sure how to fix it though... [01:03] wgrant: It seems visibleByUser is called before the print from the test --how is that possible? [01:05] StevenK: Security proxy in the test, more than likely [01:06] And then that's cached? I'm somewhat confused by this mess. [01:07] StevenK: You access a proxied attribute in the factory [01:07] It calls the security adapter [01:07] Which calls visibleByUser [01:07] The security cache caches the adapter's response [01:10] Bleh, is this failure caused by transitionToInformationType? [01:11] Hm, seems not. [01:14] StevenK: branch.owner [01:14] + removeSecurityProxy(branch).transitionToInformationType( [01:14] + information_type, branch.owner, verify_policy=False) [01:14] That branch.owner call will use the security proxy [01:14] wgrant: I've replaced it with registrant (which I should have done anyway), and it still fails [01:14] StevenK: Huh? [01:14] That doesn't change anything [01:15] It's still using the object's proxy [01:15] rSP [01:15] wgrant: registrant is a Person [01:15] Not a Branch [01:15] - information_type, branch.owner, verify_policy=False) [01:15] + information_type, registrant, verify_policy=False) [01:15] Oh, not branch.registrant [01:16] Possibly branchChanged is doing it [01:16] This case has no stacking [01:16] So no branchChanged [01:20] StevenK: Break in visibleByUser [01:20] So you can see the call stack [01:23] StevenK: s/branch.owner/registrant/ fixes it for me [01:23] Indeed [01:23] Perhaps I hadn't saved [01:33] wgrant: Looks like most of the failures were caused by branch.owner [01:36] wgrant, mwhudson. We want to remove the refresh rule. The We have not worked out how to refresh the state of other things on the page. There is currently a bug where if you retarget a task, the state of the page is broken in subsequent ajax calls [01:36] sinzui: yes [01:36] sinzui: however it should be removed by removing it, not having it accidentally break [01:36] I agree [01:37] sinzui: But I remember fixing that with Tim at the first squad sprint [01:37] Perhaps it was only branches [01:38] StevenK, I remember it fixed as well. [01:38] wgrant, StevenK, mwhudson, once we are certain the JS always works, we can remove the inline task edit form. Non-js can go to task/+edit [01:39] That sounds good [01:39] * sinzui thinks StevenK would like to kill that code and tests [01:40] sinzui: Are we certain the JS always works? [01:40] https://bugs.launchpad.net/launchpad/+bug/1004248/comments/2 fwiw [01:40] <_mup_> Bug #1004248: hook to force page refresh on context url changing is not working < https://launchpad.net/bugs/1004248 > [01:41] sinzui: There's still no other way to retarget -- the AJAX only works between projects. [01:41] I am not surprised. That bug is probably the root cause of... [01:42] bug 919369 [01:42] <_mup_> Bug #919369: acting on a bug task which has been retargeted oopses <404> < https://launchpad.net/bugs/919369 > [01:42] well [01:42] i couldn't tell if _that_ bug was complaining about what happens when someone else has retargeted the bug [01:42] task [01:43] Excellent. I think the bug is a dupe, but this time we got better data [01:43] Not quite [01:43] The refresh will only happen if you change the current context task [01:43] Retargetting a non-current task will still hit bug #919369 [01:43] <_mup_> Bug #919369: acting on a bug task which has been retargeted oopses <404> < https://launchpad.net/bugs/919369 > [01:44] sinzui: shouldn't you be asleep :P [01:45] no. I should be talking to stevenk or wallyworld_ [01:45] sinzui: Oh? Pick your victim [01:46] wgrant: http://pastebin.ubuntu.com/1005775/ [01:46] StevenK, so I made mwhudson's bug the master since it is the root cause. When we fix that bug, we really can remove bug task inline edit forms [01:47] Sadly, the root cause isn't really disclosure. [01:47] StevenK: Looks reasonable. [01:48] Let me finally land this thing then [01:50] lifeless: If I testr load from a subunit stream, shouldn't testr failing --list show me the broken tests? [01:51] StevenK, shall we mumble [01:54] StevenK: absolutely [01:57] steven@undermined:~/launchpad/lp-branches/branch-use-information_type-redux% zgrep -c '^Traceback' ~/Desktop/branch-use-information_type-redux-r15297.subunit.gz [01:57] 14 [01:57] lifeless: ^ [01:57] steven@undermined:~/launchpad/lp-branches/branch-use-information_type-redux% testr failing --list | wc -l [01:57] 0 [02:02] StevenK: they may have not failed [02:02] StevenK: passing tests can have attachments too [02:03] StevenK: oopses have Traceback in them, and don't trigger an implicit failure (perhaps they should) [02:03] StevenK: forward me the .gz ? [02:03] lifeless: Is in my homedir on carob. [02:05] whats your username on carob [02:05] ~stevenk [02:38] wgrant, do you have time to mumble? [02:40] sinzui: Sure [03:03] bloody hell, did someone flick the turbo switch on bug searches? [03:04] Yes [03:04] I rewrote them from scratch a few weeks ago [03:05] bigjools: \d BugTaskFlat [03:05] That reminds me [03:05] I need to coerce stub into GINing [03:06] nice work [03:08] it is pretty cool stuff [03:08] Not fantastic yet. [03:08] GIN should help in-context searches [03:08] But contextless (eg. person) searches still suck [03:08] Just a bit less than they did before. [04:14] wallyworld, are you available to mumble? [04:14] sinzui: sure, let me get my microphone [04:32] StevenK: Do you have plans to test searches with information_type instead of transitively_private early next week? [04:33] wgrant: Branch searches? [04:33] That one [04:33] I hadn't considered that, TBH [04:34] It needs to be done pretty soon [04:36] wgrant: I can look at doing it after the UI work [04:36] wgrant: Or I can drop the UI work and look at it now if you think it's urgent enough [04:37] Hopefully the UI won't take more than a couple of days. [04:38] The backend stuff isn't critical to look at early, as performance is already terrible, but we should get it out of the way soon. [04:40] wgrant: Can you add a card to Next then? [04:42] done [05:01] StevenK: wgrant: i already have a card for branch searches using info type, and a 1/2 done branch [05:01] Hah [05:01] i was waiting on steve's info type work to land before being able to finish it [05:01] Oh, so you do. [05:01] That's cheating. [05:02] we discussed this last week :-) [05:02] or was it this week [05:02] Hm [05:02] It was probably on last Friday's call, which I slept through. [05:02] That would explain it. [05:02] mayben :-) [05:02] Given the timing of the bug [05:02] What? Lies. You don't sleep. [05:03] * wallyworld off to do the school run. traffic will be awesome in the rain, not :-( [05:03] Oh, it's horrid up there too? [05:03] It's been about 8pm all day here [05:04] yep [05:04] Only minor flooding. [05:05] It's bright and sunny here today [05:05] Ah [05:05] The cloud pattern is interesting [05:05] http://www.bom.gov.au/australia/satellite/ [05:05] Haha [05:05] It like just avoids the southern half of NSW's coast. [05:06] pissing it down here [05:06] It's actually almost stopped here [05:06] But been raining and dark all day until now [05:06] wgrant: http://www.bom.gov.au/products/IDR023.loop.shtml is impressive [05:07] Myeees. [05:07] Better than it was. [05:07] And clearing. [05:07] actually only 2.2mm of rain here, although it feels like more [05:08] I think we got ~ 8mm yesterday [05:08] 27.2mm here! [05:08] Since 9am? [05:08] Yeah [05:08] Bloody heck, that would cause a little bit of flooding [05:09] It's the most we've had in a while. [05:58] morning [06:29] Hi there czajkowski [07:30] good morning === wallyworld changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 3.47*10^2 === allenap` is now known as allenap === popey_ is now known as popey [09:57] wgrant: btw, have you seen slow SSO evidence recently? [10:02] lifeless: Not really, no [10:02] lifeless: Bit sad [10:08] wgrant: so it might be fixed? [10:10] lifeless: Ah, I think there are still some timeouts [10:10] Although it may be the pgbouncer thing [10:14] stuartm is following up [10:14] I'd like to let him know if we sitll think its happening === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: 3.47*10^2 [11:56] hi adeuring [11:56] hi bac [11:58] adeuring, nothing in the queue. yay. [11:59] * cjwatson shall try to rectify that :-) [11:59] I'm nuking some doctests from orbit [12:00] cjwatson, and i'll gladly review that! [12:07] mgz [12:08] hey === matsubara-afk is now known as matsubara [12:47] rvba: did you guys have any sass/less discussion on maas? In the wiki it links to a sass test but thought I recall some less emails in -dev before [12:49] Hey rick_h_. Not really, I talked with Huw about using it a while ago but tbh we didn't push the idea further. [12:49] rvba: ok, I noticed you guys didn't use either so curious if there was a talk in there/not. [12:51] rick_h_: I guess the only reason not to use it right now is lack of time to set it up and refactor the existing css. But IIRC Huw was very much in favor of using it. [12:51] ok, cool. I'll bring it up and see about getting it in place from our start. Thanks === elmo_ is now known as elmo [13:49] bac: https://code.launchpad.net/~cjwatson/launchpad/refactor-customupload-tests/+merge/107381 [14:01] cjwatson, looking === mbarnett` is now known as mbarnett === nhandler_ is now known as nhandler === salgado is now known as salgado-lunch === deryck is now known as deryck[lunch] === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck === Noldorin_ is now known as Noldorin [18:56] how do I run a specific doctest file? [18:57] which one james_w ? [18:58] rick_h_, lib/lp/soyuz/stories/webservice/xx-archive.txt [18:58] james_w: think you can do ./bin/test -x -cvvt "xx-archive" [18:59] thanks rick_h_ [19:00] np [19:00] it runs a few more, but it's better than running them all :-) [19:00] yea, you can adjust that, it's a regex to narrow it down [19:00] and stuff like ./bin/test -x -m lp.bugs.model.tests -cvvt "TestBugTaskCreationPackageComponent" [19:01] but that's not for doctests [19:01] I'm still working on my tricks for speeding up test runs [19:03] james_w: you can also pass the full relative path from the top of the branch to test -t, since in the doctest case the regex is matched against the full path [19:04] and if it's a regex I guess I can use "$" to prevent substring matches from running other doctests in the same dir? [19:04] or I guess the .txt in the path will do that [19:07] if I want to reject certain values for a property based on values for other values on the object, do I just raise exceptions in the setter? [19:07] or maybe I should just let the two things vary independently in this case [19:08] we have "suppress_subscription_notifications" on a PPA, and subscription notifications are only generated if the PPA is private [19:08] so it doesn't make sense to have it set to true when the PPA isn't private [19:08] but it's far more code to enforce that than to just let people set a value which has no effect [19:09] what do people think the approach should be? [19:09] and that's not even getting in to having a good UI for setting these things on the web, with dynamically enabled checkboxes and the like