[00:02] lifeless: I believe so. [00:03] [there's a few untriaged bugs in launchpad-project] [00:03] Ah. [00:20] lifeless: We need to delete gandwana and potassium. [00:20] So many OOPSes with impossibly high non-SQL time on them. [00:23] wgrant: oh, thanks for triaging bug #737327... I forgot to change the status. [00:23] <_mup_> Bug #737327: django should not be running in debug mode on production, it will eat all the RAM < https://launchpad.net/bugs/737327 > [00:24] Also palladium [00:26] wgrant: they are on the list [00:29] Hi there. If I click on any merge request on staging I get either a timeout or an oops. Have you seen this before? [00:30] the testing librarian does not forward appserver requests to the prod one [00:30] so you need to make a new merge proposal to test merge proposal stuff on staging [00:31] Well, it's more that the staging librarian can't see restricted files from prod. [00:31] And all MP diffs are restricted. [00:32] wgrant: its not a token issue, it could forward [00:32] its just a bug [00:32] Right, but it's specific to restricted files. [00:32] Not proxying. [00:32] same thing [00:32] I'd like to play with merge requests from launchpadlib. What would you suggest? [00:33] make new ones on staging :) [00:33] (actually, qastaging, its a better testbed) [00:33] That should work, ta. [00:42] what does branchrevision.sequence is NULL imply ? [00:44] lifeless: off mainline [00:45] Whoever named compiz should have thought about how much it would crash. [00:45] It's very hard to start again when it dies and there is no z in your terminal buffer. [00:48] wgrant: Alt-F1 ; DISPLAY=:0.0 compiz & ? [00:48] StevenK: That breaks envvars when you're using unity. [00:48] Since it appears to be a Compiz plugin now. [00:48] There is no pleasing you. [00:49] mwhudson: thanks [00:57] wgrant: kill unity, and start it again [00:57] wgrant: it'll bring up a new compiz instance [00:57] (from the terminal, I mean, i.e. the Alt-F1 scenario) [00:59] elmo: With a real environment? [00:59] So dbus apps won't cry? [01:00] wgrant: *shrug*, it WFM on natty without a real environemnt (just DISPLAY) - I just had to do it just now when unity suicided on me [01:00] elmo: hm, OK, will try that in future. Thanks. [01:00] Mine dies a few times a day at the moment... but I'm using r600g, so that's not too surprising. [01:00] I'm using Intel :( [01:01] My Intel laptop is still safely on maverick. [01:08] hi all [01:08] Afternoon poolie. [01:09] ... [01:10] Archive.sources_size and binaries_size. [01:10] ... [01:11] wgrant: What about them? [01:11] Look at them. [01:11] I don't want my eyes to bleed? [01:11] It grabs every LFA and LFC in the archive. [01:12] Ah, actually, just the filesizes. But all of them. Into python. [01:12] Then sums them. [01:12] In Python. [01:13] It's probably not *that* slow. But it's stupid. [01:13] Er, yeah. Now you that mention it, SQL can do the entire heavy lifting [01:22] Hm. I think I can see the bug [01:22] (Pdb) print spr.changelog.read() [01:22] (1.0-1derived1) unstable; urgency=low [01:23] Er, what? [01:24] I'm missing a .name [01:24] Is this for tests? [01:24] Yes [01:24] Ah, good. [01:24] Haha, I'm not that evil. [01:34] man, so many soyuz bugs in 'incomplete wasused to clarify something and never changed' state [01:34] lets see [01:35] bugtask, dsitribution, cve all as much under control as they will be [01:35] i guess its productset time [01:35] bugs don't auto switchout of incomplete status after any additional info added do they? perhaps they could? [01:36] pehraps [01:36] expiry has had a difficult birth [01:36] its not really battle tested [01:36] I don't mean to indicate doubt about the idea; just that there are several ways to tackle it [01:36] revamping status is bigger but perhaps worth it [01:37] solve a bunch of headaches at once [01:39] sure. I guess I've always viewed (anywhere) that bug status fields are project management fields - in my case, I'll update a bug, but typically won't change the status. [01:40] indeed [01:40] it can be frustrating for folk that identify with a project, when 'users' or bug filers change metadata [01:50] wgrant: qa time I think [01:50] wallyworld_: you too :) [01:51] * wallyworld_ want to finish some debugging first [01:51] lifeless: A good point. [01:52] wallyworld_: thats a priority inversion: unqaed stuff on trunk is a -blocker- and comes before all other work except production-is-down situations [01:52] wgrant: I'm looking at sinzuis thing [01:53] lifeless: ok. but it means a context switch. i'll get onto it though.... [01:53] wallyworld_: it does, and thats why I want us to drive the latency way down so a context switch is less often needed. [01:54] wallyworld_: nevertheless, trunk is a critical section :( [01:54] np. [01:54] Baah [02:07] lifeless: how do we test something that needs to access a diff when the data is not available via qastaging? [02:07] mute is still behind a ff right ? [02:07] Yes. [02:07] wallyworld_: you need to make a new merge proposal or whatever [02:07] ok [02:11] wallyworld_: if you're very confident things will be better not worse, you can punt and go 'qa-untestable' [02:12] the goal is to make a good tradeoff between time invested and risk of breaking stuff [02:12] I don't think it's worth QAing that one. [02:12] It's going to take a while. [02:12] Apart from that we're OK to deploy. [02:12] lifeless: np [02:13] wgrant: do you need me to fire up evo and look at the mailbox ? [02:14] lifeless: No, I got what I needed. [02:14] Thunderbird just took a long time to download all few hundred thousand headers. [02:14] wgrant: clear it out [02:15] Just delete them? [02:15] yeah [02:15] its a test environment, not gmail :) [02:15] Heh. [02:15] hmm [02:15] the tagger seems to be missing bugs :( [02:15] see rev 12629 [02:16] The syntax in that commit message is invalid. [02:16] wgrant: they are also linked to the MP [02:16] Hmm. [02:17] 411 exceptions [02:17] nice [02:17] Not really. [02:17] It was less yesterday. [02:17] down from 20K :P [02:17] Shh. [02:17] POFile:+translate is still in trouble [02:17] wgrant: I think I may have thought of the only case we want to delete DSDs. [02:18] wgrant: If the source is removed from both the child and parent distroseries. [02:19] StevenK: Even then it's questionable. But maybe. [02:19] wgrant: Questionable why? [02:20] StevenK: There are situations in which the package could be deleted from both for a while and then restored. But the diff is unlikely to be important in that case, I guess. [02:21] huwshimi: ping [02:21] wallyworld_: Hello [02:21] wgrant: It's just a thought. I'm going to add two test cases to my end to end testing to see if the DSD gets updated on package deletion too. [02:21] huwshimi: bug 580404 [02:21] <_mup_> Bug #580404: pressing enter in tags field doesn't save them

< https://launchpad.net/bugs/580404 > [02:22] lifeless: You're requesting a deploy? [02:22] wgrant: in about 75 minutes [02:22] i qa-oked it but it doesn't seem to properly fix the issue [02:22] wallyworld_: do we need to roll it back ? [02:22] lifeless: The portlet fix? [02:22] wallyworld_: or is it ok to deploy, just incomplete? [02:22] wgrant: yes [02:22] huwshimi: no, since it doesn't break anything, but it doesn't seem to properly fix it [02:23] wallyworld_: then its qa-ok [02:23] lifeless: i know that [02:23] Here Comes The Rain (to the tune of Slayer's Here Comes The Pain) [02:23] wallyworld_: ok :) - was unsure what you're saying then [02:23] i just wanted to see if i was testing proerly [02:23] in case we needed to raise a new bug [02:24] wallyworld_: In this sort of case I add a comment to the bug saying 'does not fix' and whoever does the deploy will put it back to in-progress [02:24] wallyworld_: It isn't testable until we release a new version of lazr-js with Launchpad. Which I've been distracted from doing [02:25] lifeless: thanks for the tip [02:26] thumper: bug 615647 - I've played around for a more efficient query, and it seems to work ok to me; could you eyeball it and check I haven't missed anything? [02:26] <_mup_> Bug #615647: BranchMergeProposal:+index timeout < https://launchpad.net/bugs/615647 > [02:27] huwshimi: i have uploaded rev 206 of lazrjs to the download cache. still getting the branch that needs it fully debugged [02:27] huwshimi: are your changes done prior to rev 206? if so, they [02:27] will get rolled out when 206 goes in [02:28] wallyworld_: yeah they're in 204 [02:28] wallyworld_: Thanks [02:29] huwshimi: np. i'll try and get my branch through today. gotta fix some failing tests [02:39] Is there any way to add a class with a condition using TAL. More specifically I want to add the class 'hidden' to a div under a certain condition. The div already has other classes, just to complicate things. [02:40] huwshimi: probably best to do that in the view [02:42] lifeless: Really? It seems like the sort of thing that should be done in a template? [02:43] It belongs in the template. But it's difficult and ugly to do it there. [02:43] huwshimi: if you want to do conditional logic you want a real programming language [02:43] huwshimi: either js, or python, not -ever- tal [02:44] lifeless: Oh, but we have heaps of conditional stuff in our templates. [02:44] huwshimi: which has a bunch of poor sideeffects [02:44] such as: [02:45] - timeouts (tal:when used on a collection that triggers an additional count(*) of an expensive query) [02:45] - complex templates that can't be used in multiple contexts [02:46] - expensive tests (need to test complete rendering - and rendering uses the whole stack- for more code paths) [02:47] huwshimi: I'm exaggerating a /little/ for effect, but templates are really not suitable for anything but the simplest of conditionals, and tal inparticular, with its obsession on document structure as a pun for program logic makes this substantially worse when you're not dealing with a dom subtree [02:51] wgrant: btw - high nonsql time is (IME) correlated with repeated lookups; I suspect storm GIL handling exacerbates high load situations (e.g. too many handoffs) [02:52] lifeless: Quite possibly, yes. [02:53] (so fixing such timeouts is easily possible via code :P) [02:53] hmm [02:53] makeCodeImport() doesn't create the branch ? [02:53] or... not scanned I guess === Ursinha is now known as Ursinha-afk [02:58] lifeless: What I'm doing is purely to do with presentation (and handling broken situations with no javascript). If from what I understand you mean we should be returning css classes from the python view (which I've seen elsewhere in Launchpad) which I think is a bad idea (it tightly couples CSS to views, which makes things less re-usable and a lot harder to change), if anything we should be returning boolean flags wh [02:58] ich we can check against to modify the template accordingly (which is what we have already in this case). [03:11] lifeless: At this point it looks like my best bet is to duplicated a chunk of HTML under 'condition' and 'condition not:' [03:14] huwshimi: I suspect thats more of a maintenance burden than I was suggesting. [03:14] huwshimi: in terms of reuse and change, I haven't seen anything in tal that makes it easier to change than a view, and we have nearly universally a 1:1 view->template mapping anyway. [03:15] huwshimi: which, I admit, may be because we have things all funky at the moment. [03:16] lifeless: So really we have this limitation of having views return classes due to limitations with our templating language? [03:16] huwshimi: I think we have different perspectives. [03:16] huwshimi: you say you are working on presentation, right ? [03:17] lifeless: Correct [03:17] huwshimi: view objects *are* the presentation layer [03:17] huwshimi: templates are bound to a view for convenient editing of the html [03:17] huwshimi: but its not a limitation, bug or defect to do html in the view. [03:19] including complex logic for deciding on things - like initial visibility [03:19] huwshimi: I'll note that duplicating a section of html in the TAL will have a negative impact on performance [03:20] lifeless: OK I see where our opinion differs. [03:20] lifeless: Although I would say that it is a limitation of our templating language that we can't properly manipulate the HTML it ouputs. [03:21] huwshimi: TAL is in some ways /extremely/ primitive; the implementation we use is also very slow - the work gary and others have done to make chameleon available will, when complete, help with performance a lot [03:21] in other ways TAL is pretty nice [03:23] lifeless: So for this I should move all my classes on this div into the view and return them depending on conditions there? [03:24] huwshimi: both wgrant and I reacted that way, without having seen the exact situation [03:25] Except I say it's a necessary evil, and lifeless says it's good. [03:26] Hm, I wonder how far chameleon is off [03:27] wgrant: I think it's particularly evil cause you can't separate out the classes that should be returned on the condition to the ones that should always be applied :( [03:28] huwshimi: Yup. [03:29] you could do tal:attributes="class string: always ${view/optional}" or something? [03:29] True. [03:31] mwhudson: Can you explain that to me? [03:32] huwshimi: which bit? [03:32] lifeless: public holiday here today :) [03:32] * thumper is off all week [03:32] Thunderbird has managed to use 6.5GiB of RAM. [03:32] I am impressed. [03:33] huwshimi: maybe this bit? http://docs.zope.org/zope2/zope2book/AppendixC.html#tales-string-expressions [03:33] thumper: orly ? [03:33] thumper: I wants :P [03:34] mwhudson: Thanks I'll take a look [03:35] huwshimi: the word always would be a class you want present no matter what [03:38] lifeless: Do you have any thoughts on extending BrowsesWithQueryLimit to help with scaling tests? [03:39] ie. I want to specify a maximum baseline, test the baseline, then test that it doesn't scale above that. [03:44] wgrant: do you mean 'allow it to do LessThan' ? [03:44] typos in URLs make me sad. [03:45] lifeless: I guess I want the matcher to remember the last value it checked, and use that as the max for future calls. [03:46] wgrant: so, this would permit accidental increases in baseline [03:46] wgrant: but be more tolerant of deliberate increases in core infrastructure [03:46] lifeless: It would still have an initial value. [03:47] But would use the last checked value in preference. [03:47] wgrant: so it would ratchet down [03:47] Right. [03:47] so the failure you are preventing is 'someone set the initial value way to high' [03:48] More "someone improved other stuff, so the initial value is now way too high and nobody noticed because we use LessThan instead of Equals" [03:48] wgrant: you can do this if you want, should be a small matter of code; I don't have a strong opinion any which way. [03:48] wgrant: as an alternative, perhaps error if the query count is *too low* [03:49] lifeless: That's what I suggested last week, but you seemed neutral/negative. [03:49] wgrant: did I? sorry. [03:49] Quite reasonably, because it's more sensitive to widespread query reductions. [03:50] I'm not sure which concern should win. [03:50] wgrant: did you suggest users supplying a minimum, switching to Equals, or having a heuristic ? [03:51] lifeless: Switching to Equals. [03:51] Users supplying a minimum is silly. [03:51] wgrant: ah [03:51] And a heuristic is a heuristic. [03:51] wgrant: so I'm suggesting using a heuristic, not switching to equals [03:51] wgrant: one such heuristic would be 'allow off by 1' [03:51] another would be [03:51] 'alllow a 10% margin below the count given' [03:52] wgrant: I'm still neutral/negative on using equals. I think we need some slack. [03:53] thumper: whats the holiday? [03:54] I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-734751/+merge/54146 [03:55] lifeless: "allow off by 1" rots, "allow a 10% margin below the count given" is going to miss scaling issues. [03:56] Unless the 10% margin only applies to the first time. [04:03] wgrant: i like the idea of combing a heuristic and an observed cap [04:03] combining* [04:19] 5 second portlets still suck, but at least its less suck [04:36] anyone feel like reviewing https://code.edge.launchpad.net/~wallyworld/launchpad/unassign-private-bug/+merge/53945 [04:37] * StevenK slaps wallyworld_ for pasting edge URLs [04:37] ouch [04:37] stupid browser cache [04:39] wallyworld_: Why do you have a return at the end of _cacheViewPermission()? [04:39] StevenK: cause i'm stupid. it's a typo [04:40] StevenK: actually no [04:40] it's to exit the loop as soon as a match is found [04:40] Ah, right [04:41] StevenK: notice how my first reaction was to think how dumb i am :-) [04:43] wgrant: wallyworld_: StevenK: I'm tired of my merge proposals timing out. So have fixed. Could one of you eyeball this please: https://code.launchpad.net/~lifeless/launchpad/bug-615647/+merge/54150 [04:43] * wallyworld_ looks [04:43] if you're not a full reviewer thats ok - I'm going to self review, this thing is going down ;) [04:43] No diff yet [04:44] wallyworld_: If you can confirm self.bug in the context of those two tests is private, r=me [04:44] * wallyworld_ looks [04:45] wallyworld_: reviewed. [04:45] thanks. [04:46] StevenK: self.bug is created in the test setup [04:47] wallyworld_: I'm abstaining, due to lifeless' review of your MP [04:48] WTF, how hard can it be to switch DB users [04:49] lifeless: do we really know that the current user has permission? what if they were removed from a team after they had already opened the page? [04:50] self.layer.switchDbUser() insists that LaunchpadFunctionalLayer doesn't have that method, and LaunchpadZopelessLayer.switchDbUser() gives ZopelessTransactionManager not installed [04:50] wallyworld_: then how do they reach the code to call unassign? [04:51] lifeless: might they have the page open and before they go to unassign, they are removed from the team by someone else. on their browser, they are still assigned [04:52] so they could concievably stil lmake the api request to the back end [04:52] wallyworld_: then the publishing code will return a 404 to the POST [04:52] ok [04:53] so i'll take away the checks and just add the user to the cache [04:53] wallyworld_: and move the code [04:54] to? [04:55] wallyworld_: in fact, this is a self inflicted bug :) [04:55] wallyworld_: have you got transitionToAssignee open ? [04:56] lifeless: no [04:56] but i can [04:56] grab it now [04:56] open [04:56] look at the last line of the third if block [04:57] you mean clearing the cahce? [04:57] it explicitly enforces cache coherency on the viewers, *discarding* the fact that the active user can see the bugtask. [04:58] this is in conflict with the intent of your change which is to 'permit the user to view stuff that they *could* even if they *can't now* [04:58] yeah, i didn't really know this bit of the code base that well. just found what looked like would work [04:59] * StevenK glares at the apartment above him [04:59] wallyworld_: http://pastebin.com/iwLt6zhw [04:59] Some ingrateful muppet is using a hammer drill [04:59] wallyworld_: seems to be all that is needed to me - + a test that tests the launchpadlib call works [05:00] lifeless: i think it's more than just changing the assignee though. from memory, the same issue cam up when unsubscribing oneself [05:00] and the change i did sorted out that issue too [05:00] but that was last week. i may have misremembered [05:01] i'll look into it [05:01] wallyworld_: there is a separate method for unsubscribe [05:01] looks like an identical bug [05:01] yeah, probs [05:01] the reason I think the lifecycle change, while elegant, is a problem, is because we have direct cache management - and the two will stomp on each other. [05:02] the first like of unsubscribe needs to either be more selective about what it clears, or to keep the known viewers list. [05:02] https://code.launchpad.net/~lifeless/launchpad/bug-615647/+merge/54150 has a diff up [05:03] lifeless: your unmerged revisisions change - is the order by BranchRevision.branch desc necessary? [05:04] lifeless: i'm late to pick up the kid from school. back soon [05:04] it selects the right index [05:04] wallyworld_: the index is on (branch, sequence) [05:04] wallyworld_: it /may/ work without it. It /does/ work with it - see the various test plans in the bug [05:28] Anyone want to review https://code.launchpad.net/~wgrant/launchpad/trim-asp/+merge/54152? [05:29] wgrant: r=me [05:29] StevenK: Thanks. [05:29] wgrant: Can haz help switching db user? [05:30] StevenK: Use LaunchpadZopelessLayer. [05:30] Call LaunchpadZopelessLayer.switchDbUser [05:30] wgrant: Does that allow me to upload to the librarian? [05:30] StevenK: Yes. [05:30] "Launchpad" generally means that the librarian is up. [06:22] bah, no stubs [06:22] He was here [06:22] yes [06:22] was [06:22] timed out 2 minutes back [06:30] StevenK: can you do a review for me ?https://code.launchpad.net/~lifeless/launchpad/bug-734751/+merge/54146 [06:33] lifeless: rme [06:33] StevenK: thanks [06:33] Sprinkle = to taste [06:39] wgrant, re the mail mangling [06:40] i have to say tim's thing a while ago that spam causes the headers to be inserted into the body gives me a queasy feeling about lp mail handling [06:40] poolie: Yes. [06:41] poolie: This is a good excuse to examine those configs and unbreak it. [06:43] I don't entirely know what the incoming mail path is :/ [06:49] wgrant: Ask a friendly* sysadmin? [06:53] is that a Kleen star? :-) [06:53] lifeless, it's not top of my list (nor i dare say yours) but i was wondering after friday's mail what your actual thoughts on triaged vs confirmed were [06:54] are you also hoping to merge them? === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews/ [07:53] henninge: O hai! I have one for you :-) [07:53] Hi StevenK! Let me see it ;-) [07:54] henninge: https://code.launchpad.net/~stevenk/launchpad/dsdj-runner/+merge/54159 [08:29] poolie: that 3 page bug update is about as far as my thinking has advanced [08:31] poolie: I think that 'triaged' as it stands is entirely redundant, but that piecemeal solutions probably aren't [solutions] [08:46] good morning === almaisan-away is now known as al-maisan [08:53] henninge: No news means "It's terrible, redo from start" ? :-) [08:54] StevenK: no, it looks good [08:54] StevenK: Still a lot to read ... [08:58] henninge: Hi, once you're finished with StevenK's branch, I'd appreciate if you could take a look at https://code.launchpad.net/~rvb/launchpad/dds-sampledata/+merge/53988 [09:01] rvba: Julian approved that MP? [09:01] StevenK: yes [09:07] rvba: why would you want another review if it has already been approved? [09:08] henninge: well ... I thought the procedure was to have it reviewed by someone outside the circle of people who discussed the branch in question [09:09] rvba: good point [09:09] henninge: but in this case, it's really tiny and does not involve code change (only sql in current-dev.sql) so it might not be worth you time [09:10] s/you/your/ [09:10] rvba: yeah, there is really not much I can review here. [09:10] henninge: all right then [09:10] rvba: how did you create the sample data? [09:11] henninge: I confess I did that manually (fiddling with the database), then I ran make newsampledata [09:11] probably not the most clever way to do this I know [09:12] rvba: well yeah, usually it's better to do that through the normal procedures (i.e. UI and scripts) [09:12] rvba: actualy it's *best* to avoid creating new sample data at all. [09:12] well, actually it's more about using it in tests, I guess. [09:12] henninge: yes but the scripts to create those objects are in the works now [09:12] which is not the case here, of course. [09:13] I figured [09:13] yes, I only modified the sampledata for local instances [09:13] oh, right [09:13] rvba: r=me in that case ;-) [09:14] the goal is to populate a form on which I'll have some js work to do pretty soon, before the scripts to populate this with real data exist [09:14] henninge: thx [09:19] StevenK: Isn't there some existing infrastructure to test scripts so you don't have to do the subprocess dance? [09:22] StevenK: what about "from canonical.launchpad.scripts.tests import run_script" [09:30] henninge, good morning, one very complex branch for you when you can find 10 minutes: https://code.launchpad.net/~danilo/launchpad/mail-header-discrepancy/+merge/54172 :) [09:31] Hi danilos! [09:31] and "No" :-P [09:31] (which means "Yes", of course) [09:31] henninge: Hm, wasn't sure about that. I can certainly look at changing it. [09:31] StevenK: I'll give you an example in the review. [09:31] see if that works for you [09:32] henninge: Awesome. [09:32] henninge, excellent, I prefer "no" meaning "yes" than the other way around :) [09:32] ;) [09:32] henninge, and I love you :) [09:33] * henninge blushes [09:41] StevenK: review sent [09:44] danilos: sorry, too complex to do in one OCR shift, you will hear back from me tomorrow night. [09:44] henninge, I understand, thank you for trying anyway! [10:47] Erm. [10:47] Why is ~registry not a member of ~vcs-imports any more? [10:48] it was via launchpad-chr, which matsubara deleted for some reason a couple of weeks back [10:48] Ah. Can you readd? [10:48] ALthough I guess we then need a ~launchpad admin :( [10:49] doesn't ~canonical-bazaar own it now for some reason? [10:50] lifeless is an admin. [10:50] But adding a team to another requires confirmation from both ends. [10:50] sure, one sec [10:51] hangon, ~registry or ~launchpad into vcs-imports ? [10:52] wgrant: ^ [10:52]