[00:05] thumper: did you really mean to link to bug 240067 ? [00:05] <_mup_> Bug #240067: Launchpad projects need wikis [00:09] lifeless: no [00:09] lifeless: I've fixed it [00:09] I had two bugs open [00:09] and I linked to the wrong one :( [00:09] * thumper heading afk for hair cut and lunch :) [00:14] Project devel build (109): STILL FAILING in 1 hr 28 min: https://hudson.wedontsleep.org/job/devel/109/ [00:14] * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=656759] It's now possible to subscribe with, [00:14] and filter direct subscriptions by, a BugNotificationLevel. [00:14] * Launchpad Patch Queue Manager: [r=adeuring][ui=none][bug=651240] The Bug:+subscribe functionality [00:14] has been moved into its own view class. [00:35] * wgrant deletes lucilleconfig. [01:15] james_w: around? does that develop= line work to use regular non-buildout projects ? [01:19] dunno [01:19] lifeless, I believe the result is to run "setup.py develop" in those dirs, and then add a .egg-link to them [01:19] and I don't think that requires them to use buildout [01:19] it wouldn't really surprise me if it didn't work though [01:20] develop isn't in standard setup.py [01:21] hmm, it may work, something funny with the iport thought [01:22] \o/ [01:22] >>> fixtures.PopenFixture [01:22] [01:25] depends what you mean by "standard", it's in setuptools, so a fair number of projects will support it, and they don't have to use buildout to have it [01:27] distutils 4 eva [01:27] anyhow, develop= worked with python-fixtures [01:27] which is nice === Ursinha is now known as Ursinha-afk [01:44] Project devel build (110): STILL FAILING in 1 hr 29 min: https://hudson.wedontsleep.org/job/devel/110/ [01:44] * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=650343] Add X-Launchpad-Original-To to [01:44] recipient lists; [01:44] move some related files from c/l/mail to lp/services/mail. [01:44] * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=656213] Allow .lpconfig to be honored if [01:44] initial configuration is "development" [01:45] """Manage a publisher configuration from the database. (Read Only) [01:45] This class provides a useful abstraction so that if we change [01:45] how the database stores configuration then the publisher will not [01:45] need to be re-coded to cope""" [01:45] What an *awesome* idea. [01:45] uhm [01:45] yagni [01:45] Yes. [01:46] We haven't needed it in more than five years, so I'm deleting it. [02:20] wallyworld, hey. [02:20] rockstar: hiho [02:21] see my email? [02:21] wallyworld, just out of curiosity, could you `make clean build` and then run the windmill test? [02:21] that's what i did :-( [02:22] wallyworld, hm. [02:23] rockstar: any thought's? looks like YUI() is borked in windmill [02:24] wallyworld, this is the Y.io() thing, right? [02:24] yeah [02:24] and also any other YUI eg Y.all() [02:24] or maybe not Y.all - it may have been run on the wrong instance. i need to check that [02:25] but Y.io is definitely broken [02:25] wallyworld, what happens if you -D, wait for it to fail, and then try and look up the url being requested in the url bar? [02:26] rockstar: good question. hold that thought and i'll get back to you [02:27] wallyworld, I'm also curious to know whether or not a YUI 3.2 update would make it work. [02:28] rockstar: i'm not yet familiar enough with the failure mode nor what's new in 3.2 to know if it will help or not. can't hurt to try i guess [02:28] wallyworld, well, as I upgraded, I found that lots of bugs were hidden in our javascript that YUI 3.2 doesn't pass silently. Maybe that might help as well. [02:28] wallyworld, I don't know, we're at a weird impass now. [02:29] rockstar: i'll check this one other thing. perhaps you could grab my branch and try it with 3.2? [02:30] wallyworld, sure. One sec. [02:30] rockstar: bin/test -vvt test_branch_broken_links <--- for when you have the branch pulled [02:30] rockstar: hey [02:30] lifeless, hi sir. [02:31] rockstar: I have a question about windmill [02:31] rockstar: what will happen if I run two windmill tests concurrently? [02:31] lifeless, I SEVERELY doubt I have the answer, but I can probably get as close as anyone... [02:32] lifeless, I think, were you to do that, you'd want them running in separate processes at least. They'll need their own instances of the browser they fire up. [02:32] rockstar: will doing xvfb-run be enough to do that ? [02:32] lifeless, no idea. [02:33] I'll ask on twitter :) [02:34] lifeless, :) [02:34] lifeless, mikeal may have a good answer for you. [02:34] I wish I knew more about windmill, so I could actually fix it. [02:54] rockstar: the client call to the server side endpoint works fine from a console on the test browser, where the Y.io call fails [02:55] rockstar: ie window.open('http://code.launchpad.dev:8085/+check-links?link_hrefs={}') [02:55] wallyworld, what if you use the actual browser that it brings up? The Firefox instance? [02:55] yes, that's what i'm using [02:56] i open the firebug light console [02:56] Is that the exact url that is getting requested? [02:57] almost: i have cut out the actual json guts between the {}. with an empty {} it just returns {} so the end-end works [02:58] i can open a new tab and type the url directly or use the firebug console and do a window.open() [02:59] do our tests for windmill go through apache?! [02:59] lifeless, no. [02:59] whew [02:59] so the 8085 is just a daft default? [02:59] Yeah. [03:00] a default that's typed in many, many places in the code [03:00] wallyworld, where? [03:01] wallyworld: it shouldn't be; but if it is replace it with a config lookup please [03:01] * wallyworld looks at the code [03:01] wallyworld, canonical_url should just give it to you correctly. [03:02] * rockstar wrote that patch... [03:03] lots of tests (doc and py) have code like browser.open('http://launchpad.dev:8085/+login') [03:04] ugh [03:04] wallyworld: care to file a bug? [03:04] (or better yet, just fix) [03:04] lifeless: will do. [03:05] lifeless: after rockstar and i get this @!^#@#@@& YUI and windmill issue fixed [03:05] naturally [03:08] rockstar: i'm hungry. i'll grab a bite to eat and check back after that on the progess using YUI 3.2 to see if it sheds more light on the ajax breakage [03:09] wallyworld, windmill tests are running now. [03:09] rockstar: ok. i'll wait a bit. did you try the specific one i mentioned? [03:10] wallyworld, no, because I'm also trying to fix my test. :) [03:10] np [03:10] wallyworld, I'm testing lifeless' query right now... [03:11] My laptop is not happy. [03:11] rockstar: from our discussions, the root cause of the ajax issue for your and my tests is likely the same anyways i think? [03:12] wallyworld, I'm not so sure. [03:13] rockstar: ok. i'll wait for a progress report from your side of things. in the meantime, food awaits [03:13] rockstar: about parallel testing? [03:13] lifeless, yes. [03:13] rockstar: I'd expect things to blow up hugely [03:14] rockstar: but not because of windmill [03:14] lifeless, no, it was windmill. [03:14] rockstar: is there some way to identify windmill tests a priori? [03:14] lifeless, so, the second instance of bin/test died because port 8085 was in use. [03:15] rockstar: right, thats not a windmill issue [03:15] lifeless, I think that means that we might be able to run it fine once everything is set up. [03:15] rockstar: theres a long chain of things to fix ;) [03:15] rockstar: the testdb, all the external helpers, the oops dir, the log dir [03:16] lifeless, but there's also probably a huge penalty in starting another firefox instance. [03:18] poolie: I htink its a bad idea to link the code style giude from the front page [03:19] poolie: but I'd like to know why before rolling your change back [03:19] i'd like to know why too :) [03:19] I think its a bad idea because really all the guides need to be read, to write patches for LP [03:20] special casing that one makes it feel like that element on the front page is a nested table of contents [03:20] which its not [03:20] poolie: your turn :) [03:20] it's the one i've found myself linking to or looking at most [03:21] obviously other people may care more about js style [03:21] feel free to revert [03:21] I'd be happy to list them all there and delete the list-page of the guides [03:21] there's no content on the indirection page [03:21] what do you think? [03:22] you could make 'Style guides' a new blue-ish section [03:22] also 'architecture guideline' is not really a style guide [03:22] blue section ? [03:22] heh, doubly so because it does not exist :) [03:23] like 'process', 'tools', [03:23] an h2 or h3 or whatever [03:23] 'does not exist' meaning the first link on https://dev.launchpad.net/StyleGuides is bronke [03:24] * rockstar suspects the js style guide needs some updating. [03:27] lifeless: so that's settled? [03:27] inlined it on the front page [03:27] great [03:27] glad i could push it into a better direction :) [03:43] how much memory does a bin/test process need [03:44] poolie: we can hope it is better :) [03:44] lifeless, I guess it depends on what tests it's running. [03:44] rockstar: peak memory is what I need [03:44] like, if the machine has 2 GB [03:44] and 16 procs [03:44] should I start 16 test runners [03:44] or 4 [03:45] 16 cores [04:27] bac: is that the threading thing [04:27] ? [04:27] lifeless: yes [04:27] test_network [04:28] lifeless: do you have a sec to talk about the metric in the ArchitectureGuide wrt 2 second tests? [04:29] sure [04:29] so i have a branch that adds a new test, it runs four tests and the test case is instantiated for five different pillars [04:29] do you mean irc or voice when you say talk [04:29] lifeless: here is good and my voice is gone today [04:29] sure [04:29] so it runs 20 tests and was taking 42 seconds with the straightforward (naive) implmentation [04:29] so, new test, 4 cases, parameterised over 5 pillars [04:30] the first question I have is why it needs parameterisation (can things actually vary) [04:30] i started playing around with it yesterday and got it down to <11 seconds with the same coverage [04:30] good, yeah? [04:30] bac: thats excellent. [04:30] bac: I presume thats not including the layer setup time. [04:31] well, in order to do that i had to collapse the four tests into one so the expensive setup was not called multiple times, violating our guideline to only test one thing at a time [04:31] what makes the setup expensive? [04:31] that was the bulk of it, caching some properties accounted for the rest, which jtv objected to [04:31] lifeless: creating objects [04:31] bac: if caching properties makes the test suite faster, it doesn't necessarily follow that prod will be faster - but it may well. [04:32] bac: if its noticably faster, it probably will make prod faster. [04:32] anyhow, back to your question. [04:33] well, this is not really a production issue. the test is just to verify that the correct anti-robot meta is included in the rendered templates based on LP usage [04:33] so the speed or slowness of the test really has nothing to do with performance in production [04:33] 2 seconds is a statement of where we'd like to be. If we can't reach it right now, I suggest analying *why* far enough to be confident that we know what to fix, file a XXX bug on that (e.g. creating DB test objects is slow) and move on. [04:33] however I'd be utterly delighted if you were to keep driving it down to a sensible figure [04:34] bac: I have to disagree about its relevance for production [04:34] lifeless: my question is this: what do we value more: test readability and separation or speed? [04:34] bac: all three [04:35] bac: in this case, for instance, you can use a layer (ugh, but thats the current tool) to provide the same expensive setup for all 20 tests, and have separate clear test code per case [04:35] and it should perform identically [04:35] except that you'll need to intercept the db layer rollback (and there is a flag for that to let you do so) [04:37] so in your layer setUp to set the 'do not rollback' flag, and in your layer tearDown you restore it. [04:38] lifeless: here is the original: http://pastebin.ubuntu.com/513562 [04:38] bac: I'm still staggered that setUp is so slow for your test [04:39] and here is the restructured one http://pastebin.ubuntu.com/513561 [04:40] lifeless: i make the argument about no effect on production b/c all i have done is make changes to the structure of the test not any of the production code [04:40] so you're saying that canonical_url and getUserBrowser are sufficiently slow [04:40] bac, I'm happy to do reviewer meeting duty next week. [04:40] we use canonical_url in prod [04:41] bac: I agree, seeing that, but its data we should gather for where prod performance issues are [04:41] lifeless: right. but i haven't sped them up, i've avoided them [04:41] rockstar rocks [04:41] the getUserBrowser cachedproperty looks like it will get no hits, FWIW [04:42] how's that? getRenderedContents is called four times [04:43] oh, I see [04:43] thanks [04:43] so, I think that that test is fine [04:43] personally I'd structure it as a matcher [04:43] then you wouldn't need a mixin [04:44] but doing multiple similar checks on one fixture are fine [04:44] totally readable [04:44] lifeless: i guess my main point is i'm dissatisfied b/c i find the explicitness of the original appealing [04:44] but dog slow [04:44] i did not know about using a new layer to accomplish what you suggest [04:45] i may pursue that and if it works send out an email as a case study [04:45] bac: I wouldn't in this case, its nice and clean, not at all what I envisioned [04:45] bac: please don't, layers are on the way out [04:45] oh, good [04:46] ok, well maybe i'll just send an email with what i've done and the four-fold increase in speed [04:46] I'd suggest you look into testresources or similar, but thats conflicts with layers, so its not a good learning point just yet. [04:46] anyhow, If you were testing many different things in those cases, I'd understand and agree with it being better to have 4 cases [04:46] lifeless would you mind putting your stamp on the MP for these changes [04:46] but I think you're really testing a single contract [04:47] the contract being the 4 cases where robots are blocked. [04:47] whats the MP ? [04:47] https://code.edge.launchpad.net/~bac/launchpad/bug-652280-pg-trans/+merge/38195 [04:48] you couldn't use cached property here anyway, you need to reload the browser each time, you could if you called .open(), but the thing you were measuring was probably the open and render time anyhow. [04:48] (looking at the diff in the MP I see that you're not caching) [04:50] lifeless: i do reload the browser each time [04:50] cool [04:51] lifeless: the MP is not yet updated [04:51] bac: I've stamped my opinion on the bits in question. [04:51] I haven't dug really deep, but I see you've had a thorough discussion anyhow ;) [04:51] yeah,thanks [04:53] lifeless, just saw your tweet. I think you need to at least have two separate firefox instances. [04:54] rockstar: why? [04:54] I mean, if we need it, we need it [04:54] but its going to suck having 8 concurrent firefoxes doing their thing [04:55] or 16 on serious desktops [04:55] e.g. [04:55] robertc 15152 2.9 4.2 412104 86656 pts/1 Sl+ 14:56 0:01 | \_ /usr/bin/python -S bin/test -vt test_parallel --parallel --subunit [04:55] robertc 15167 7.4 6.5 399240 134248 pts/1 S+ 14:56 0:03 | \_ /usr/bin/python -S bin/test -vt test_parallel --subunit --load-list /tmp/tmpSbVCl6 [04:55] robertc 15168 7.5 6.5 399320 134244 pts/1 S+ 14:56 0:03 | \_ /usr/bin/python -S bin/test -vt test_parallel --subunit --load-list /tmp/tmpsNzicF [04:55] lifeless, I think the interface to remotely control firefox is per browser. I remember mikeal's pycon talk about it. [04:56] ah [04:56] still, out of scope for me -just yet- [04:58] jml: I'm sad; someone fucked with list-tests and now it prints test descriptions not ids, and prints other guff too. [05:01] jml: either that or it never really existed. [05:11] ooooh yeah [05:11] parallel testing working. |o| [05:11] of course, it'll blow up trivially on stuff like rockstars experiment [05:13] Or, say, database access? [05:14] that will be the height of hilarity. [05:24] StevenK: does your hudson have resources to run a parallel version of launchpad tests? [05:24] StevenK: one that I expect to fail massively. [05:57] wgrant: https://code.edge.launchpad.net/~lifeless/launchpad/paralleltests if you want to play [05:57] can anyone tell me the difference between zope.app.pagetemplate and zope.pagetemplate? [06:00] generally zope.app stuff is more tightly tied to the application server environment [06:00] often it is glue between generic and specific stuff [06:00] Lots of things from zope.app.* are being moved into zope.* as part of the ZTK rework. [06:00] So zope.app.pagetemplate could just be a deprecated alias now, or it could still have some functionality of its own. [06:01] i have a patch for zope.pagetemplate.engine.py - is the best course of action to ask on the zope dev list. i assume htere is one? [06:02] wgrant: excellent! [06:02] bah [06:02] wallyworld: ^ [06:02] https://mail.zope.org/mailman/listinfo/zope3-dev is the list. [06:02] But you might be better off talking to some of our Zopeish people... [06:03] lifeless: it's a simple one. i've replaced if getattr(object, '__class__', None) == dict: with if zope_isinstance(object, dict): [06:03] yay [06:03] so, find the project in lp and propose a merge proposal [06:03] they are usin gLP [06:03] it restores the short circuit for menu links when used with the branch i just did for performance improvements [06:03] lifeless: They're even using LP for MPs? [06:03] wgrant: yes [06:03] Because they still use zope.org svn. [06:03] what's gLP? [06:03] incoherently [06:04] wallyworld: using LP [06:04] ok. i had a quick look at lp. there's a few zope projects there. i wasn't sure if we were just mirroring their stuff or not [06:04] or if i had to wander over to zope.org [06:04] either, AFAIK [06:05] ok. thanks [06:05] wgrant: thanks also for the info [06:05] perhaps both is best [06:06] wgrant: this is what you'll get: [06:06] psycopg2.ProgrammingError: database "launchpad_ftest" already exists [06:06] :) [06:06] with --parallel on db tests [06:07] lifeless: Ah, I see. [06:07] Still, that should be reasonably easy to fix. [06:09] wgrant: like I say, there's a list of things to fix ;) [06:10] * wgrant is demolishing lucilleconfig while trying to avoid finishing assignments. [06:11] lifeless: I'm not sure how to get Hudson to run arbitary branches [06:12] TBH, I'd just throw it at ec2 and see what happens [06:12] StevenK: set up a new job, also of trunk [06:12] StevenK: you misunderstand me [06:12] StevenK: I've added a new bin/test option, --parallel. [06:13] StevenK: due to our test suite making many inappropriate assumptions, this won't work for all tests yet. [06:13] StevenK: I want a ratchet, a visible progress marker. [06:14] StevenK: so I want it run, with as many cores at once, to find unknown issues [06:14] https://hudson.wedontsleep.org/job/parallel-test/ [06:14] and when it starts to pass most tests, we can organise a dedicated burn-down window for it [06:15] StevenK: awesome; you'll need --parallel in the job options (I can't see the config can I?) and my branch to land. [06:15] bbs [06:15] lifeless: I can add an account for you and you can fix the tests [06:16] fix the tests? [06:16] Er, fix the config [06:18] its just --parallel on bin/test :) [06:18] verry simple. [06:18] I don't run bin/test, I call make check [06:18] you can validate it using lp:~lifeless/launchpad/paralleltests [06:18] ah [06:18] ok account me up [06:18] we should have openid sometime soon [06:21] lifeless: I've added the ACLs, now how do I actually create an account for you? [06:21] depends [06:22] oh, you've made a warthogs user already ? [06:22] Yes [06:22] has it got write? [06:22] No, but it can [06:22] lifeless: You just want to use warthogs? [06:22] ok, I can login as that [06:23] yeah, why not.. simples [06:23] lifeless: Okay, you should be able to configure parellel-test [06:23] yea [06:24] lifeless: You can turn off IRC notification if you wish, but e-mail notification isn't set up [06:26] running a test build [06:27] Hm, that should start another executor, not block on devel [06:29] Ah, there it is [06:42] Bleh, how are people landing things when PQM tells me we're in testfix? === almaisan-away is now known as al-maisan [06:56] StevenK: failures? [06:57] lifeless: On db-devel [06:59] right [06:59] file a bug :) [06:59] And the failures look strange [06:59] a librarian process is probably still runnning [07:00] *or* was interrupted so violently that the pid wasn't removed. [07:00] we need to figure out which [07:00] and file a bug to prevent it happening again [07:00] Whoops. [07:00] Yes, I thought so too, so I suspect the next step is stab buildbot? [07:00] 2400 line branch. [07:00] StevenK: no [07:00] we should never stab [07:00] we should analyse the cause [07:00] gather data [07:00] and make sure we have enough info to fix [07:00] lifeless: Even when the failure is 'slave lost'? :-) [07:01] *then* stab [07:01] StevenK: yes. [07:01] why was it lost? [07:01] where did it go? [07:01] what happened? was it manually rebooted? did the machine crash? [07:01] slave lost is usually buildbot going gaga [07:01] its the lack of analysis and debugging that has us in this situation. [07:02] (Cough, hudson) [07:02] right [07:02] Speaking of, there's a new one, apparently [07:02] but we'll have issues with hudson that need similar care and detailed attention to fix, too. [07:03] Project parallel-test build (1): FAILURE in 26 min: https://hudson.wedontsleep.org/job/parallel-test/1/ [07:11] Project parallel-test build (2): STILL FAILING in 1 min 39 sec: https://hudson.wedontsleep.org/job/parallel-test/2/ [07:12] StevenK: can you kill the executor ? [07:13] lifeless: Done [07:22] lifeless: Just thinking about it, I didn't think anyone had access to the buildbot slaves? [07:23] they don't [07:23] so someone needs to work with the losas to diagnose. [07:23] its way past EOD for me, but I'll swing my irc every hour or two till I sleep [07:24] So, spm is off sick, and Tom turns up in ~ 2 hours, and I have branches to land. :-( [07:24] ugh [07:24] you could ask a gsa [07:24] but its really important to understand whats gone on. [07:25] I don't know enough about the buildbot infrastructure to know which machines are involved [07:25] * StevenK will wait for Tom [07:30] anyhow, I'm off for a while [07:30] jml: I've asked for your review on this parallel tests branch; to help you I reviewed all the testtools MP's. [08:28] hello jml, StevenK [08:28] lifeless: that's great new about parallelization [08:31] poolie: Hi [08:45] lifeless: I'm sorry to hear about list-tests. [08:46] lifeless: and thanks for the reviews, I'll look at your parallel tests branch soon. [08:48] Hm, that's odd. [08:49] Looks like a stale pid file [08:56] good morning [09:09] Hello [09:18] poolie: thanks, yes. [09:18] jml: \o/ [09:18] jml: yeah to get a listing its --list-tests --subunit | subunit-ls, which is a bit grotty [09:22] lifeless: oh, I think what I did there is deleted our own hack in favour of the upstream support... iirc. [09:22] gotta run, late for an appointment [09:22] ciao [09:29] Project parallel-test build (3): STILL FAILING in 2 hr 4 min: https://hudson.wedontsleep.org/job/parallel-test/3/ [09:30] bigjools: You're not particularly attached to lucilleconfig, are you? [09:31] wgrant: I'm not sure which part of "must die in fire" was ambiguous, no. [09:31] Haha [09:31] bigjools: Well, I accidentally slipped and deleted it today. [09:31] that's quite a slip [09:32] 2400 lines or so. [09:32] ! [09:33] Although some of that is a sampledata rebuild. [09:33] * bigjools otp [09:37] hahah https://hudson.wedontsleep.org/job/parallel-test/3/testReport/? [09:37] *boom* [09:38] and meh, something did a 'print' and mangled the stream [09:38] I'll look more closely monday. [09:38]