=== wallyworld changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 4*10^2 [00:46] where did the ec2 script go? [00:47] i'm guessing lp-dev-utils [00:47] Yes, in there [00:51] * poolie is trying to finish https://code.launchpad.net/~mbp/launchpad/925597-dkim-from/+merge/98976 [01:02] have a good weekend y'all [01:20] wallyworld: Can I borrow your eyes for a moment? [01:21] StevenK: sure, so long as you return them, and it depends on what you use them to look at [01:21] wallyworld: http://pastebin.ubuntu.com/927290/ is one of my JS files, make lint reports "59: Expected ';' and instead saw '}'." [01:22] StevenK: you need to terminate the } with a ; [01:22] since that block is a statement and all statements need to be terminated with a ; in js [01:22] Ah. [01:23] one of the reasons to prefer python :-) [01:24] Oh, bah. Y.one('[name="field.information_type"]'); is only matching the first radio button with that name. :-( [01:24] do you want all of them or a specific one? [01:24] StevenK: that's what .one does :) [01:25] rick_h: Silence! :-P [01:25] /one/all [01:25] what he said [01:25] rick_h: s/one/all/ # perhaps? :-) [01:25] sorry, was this in vimscript or something else :P [01:25] rick_h, wallyworld: .all returns an array? [01:25] rick_h: ignore the pedant :-) [01:25] hey, 'pseudocode' is legit [01:25] a NodeList [01:26] which you can call .each() on etc [01:26] nodelists are nice, act like nodes [01:26] Can I say .on('change', ) on it? [01:26] i'd use event delegation [01:26] instead [01:26] you can say that on the nodelist, but yea, delegate ftw [01:27] attach a handler to the containing div or whatever and use a selector in the delegate() to choose what to listen to [01:27] assuming they're all from a common parent node [01:27] StevenK: look at examples in shareetable.js [01:27] The radio button list is coming from Zope's form handling [01:28] there should be a parent node you can use [01:28] * wallyworld has to run away to drop the kid at the occupational therapist. back in ~30 [01:29] wallyworld: It's in a table, so the parent node is ... difficult to get. [01:29] Oh, wait a sec, there's a table inside another. [01:37] rick_h: Hmmm, maybe I'm going about this all wrong [01:42] how so? [01:43] rick_h: If I put the change function on all nodes, I'm not sure how to reach in and get which radio button is selected [01:43] wallyworld: fancy a liquid lunch today? [01:43] so when you delegate you tell it you only care about 'input[name...]' nodes that change [01:43] StevenK: and then when your callback is called, 'this' is the node that changed [01:44] StevenK: http://yuilibrary.com/yui/docs/event/#delegation [01:48] is there an easy way to get a person by email, requiring that the email be verified? [01:50] poolie: there's 'admin = getUtility(IPersonSet).getByEmail(ADMIN_EMAIL)' usage [01:50] I don't think that validates. [01:50] but you'll have to check the validated status of the email after you get hte person back I think [01:51] in my test for bug 925597 my current (not live) code is accepting mail from unverified addresses [01:51] <_mup_> Bug #925597: From address is ignored if DKIM is supported < https://launchpad.net/bugs/925597 > [01:51] which what a simple getPrincipalByLogin(addr) does [01:51] mm i think i should just check it [01:51] thanks [01:58] rick_h: I'm not doing delegation yet. [02:11] wallyworld, could i get an incremental review on https://code.launchpad.net/~mbp/launchpad/925597-dkim-from/+merge/98976 ? [02:16] poolie: sure [02:17] bigjools: i ate on the way back from dropping lachie off at the dr :-( [02:17] wallyworld: what part of liquid didn't you understand? :) [02:18] lol [02:18] :) [02:18] yay bne [02:18] bigjools: i have to play soccer tonight but i could be persuaded to have one or two or three [02:19] btw i'm probably going to be up there on about the 11th of june [02:20] poolie: excellent. make sure you keep some time free to come over for dinner or something [02:20] I trust we'll see you for a wee drinkie [02:20] :) please keep some beer for me [02:20] Dan Murphy's is going to get more custom [02:20] Hmmm [02:20] We have a lot of old private bugs that probably shouldn't be private. [02:24] poolie: 2 comments 1. preload_dns_response. i'd prefer response_type to default to 'valid' instead of None [02:24] good idea [02:25] poolie: 2. i'd like to see tests for all the new code paths introduced for checking the email address [02:25] not just the 'this is not active'' case [02:25] oh, person with no account, etc [02:25] yeah [02:25] mm [02:25] fair point [02:25] bigjools: when you going to Dan's? [02:26] poolie: sorry to be picky on your last day [02:26] when I run out of OSH [02:26] i'm surprised you have any left [02:26] you Mosh ? [02:26] war rationing [02:27] hm [02:27] i wonder if those can actually be hit or if i'm just over cautios [02:27] poolie: i'm not sure tbh [02:28] poolie: you could always put in asserts if we think those conditions should be impossible to hit [02:29] plain 'assert' or if/raise pseudo assert? [02:29] if raise [02:29] is what our style guide says [02:29] OTOH the odds of running with -O are < 0. [02:29] lifeless: What time is your flight? [02:30] 1510 [02:30] i'm guessing he's in the lounge [02:30] don't ask when I started work this morning :) [02:30] poolie: Given the airnz.co.nz hostname ... [02:30] I have a package waiting to build on staging in 59 seconds for about 4 hours [02:31] are there live builders for it ? [02:31] can anyone tell me off hand if address.person = None or person.account = None is likely to happen? [02:31] address.person = None is impossible [02:31] ahh :) [02:31] person.account = None is likely [02:31] this is a special area of hell reserved for conflated services [02:31] which we're trying to untangle [02:32] timrc: staging doesn't do builds [02:32] poolie: a valid person has an account [02:32] No Soyuz services on staging at all, in fact. [02:32] poolie: (which may not help you) [02:32] StevenK: buildd-manager runs, for TTBJs [02:32] wallyworld: css-selector should be what? [02:32] the question is should i add tests for getting mail from an address corresponding to a person with no account [02:32] $?@! [02:32] k [02:32] at the moment it will just basically reject it but it's not tested [02:33] wallyworld: You've got span in there [02:33] well [02:33] StevenK: should be what you need to capture clicks from the nodes you want [02:33] if it's not tested, perhaps i should say the behaviour is undefined :) [02:33] poolie: that will happen in real life, so I'd say yes. [02:33] auntil we fix up the cruft [02:33] wallyworld: Right, but I've not used them before, so how do I match the radio buttons? [02:33] so test for person with no account, not for an address with no person? [02:33] k [02:34] poolie: EmailAddress.person is NOT NULL since January [02:34] StevenK: something like "input[name='field.foo']" [02:34] ah ok [02:34] You may still see some code that assumes it can be null. I didn't catch everything. [02:34] the interface still says required=False [02:34] Like that. [02:34] shall i change it in this branch? [02:34] Please. [02:34] There were about 10 branches in that series; there was a *lot* to change.; [02:34] required=True may have some test fallout [02:35] or maybe separately? [02:35] StevenK: should be no need to further qualify with type=radio [02:36] poolie: i'd do it separately given the unknown test fallout [02:36] and since it's your last day and ideally we want this to land first time :-) [02:37] poolie: I'm a little annoyed at this UI branch I'm working on, I'm happy to cowboy a branch that changes it and toss it at ec2 [02:37] indeed [02:37] k [02:38] StevenK: let me know if you want me to look at anything with your ui stuff [02:38] poolie: This is in EmailAddress ? [02:39] yes IEmailAddress.person (required=False) [02:39] in my branch [02:39] it may just be out of date [02:39] wgrant said he missed it accidently [02:42] mm [02:42] I'd be realised surprised if there was test fallout [02:42] But maybe [02:47] well the DB requires it [02:47] so the only fallout could be of the form construct; assign; flush [02:47] Exactly [02:47] And I doubt anything uses the interface [02:47] We don't use formlib on EmailAddresses [02:49] uhm [02:49] r15086 is odd [02:49] I think someone mistakenly commented out bouncer.start() [02:49] wahuh [02:50] The revision was an attempt to make the test more reliable [02:50] But I think it made it always fail instead :) [02:51] * wgrant fixes [02:53] That works a bit better [02:56] wallyworld, ok, i added a test for a person with no account [02:56] * wallyworld looks [02:59] wallyworld: Ah ha, it doesn't work because Y.one('#radio-button-widget'); is null [03:00] StevenK: sounds plausible depending on how the ui is set up [03:00] I hope this is a YUI test :) [03:01] wallyworld: # is for class? [03:01] StevenK: # is for id [03:01] . is for class [03:04] poolie: looks pretty good i think. 2 nitpics. imports need to be alphabetical, person = self.factory.makePerson(...) - person is not used so you don't need to make the assignment [03:04] k [03:05] thanks for making all the requested changes [03:07] which import is wrong? [03:08] +from lp.services.mail.incoming import ( [03:08] + InactiveAccount, [03:08] + authenticateEmail, [03:08] + ) [03:08] ah, case-insensitive sort is required? [03:09] i thought so but now i am doubting myself [03:09] there is a tool that will do it [03:09] and yes, case insensitive [03:09] utilities/format-imports [03:09] Also utilities/format-new-and-modified-imports [03:09] they should be in lp-dev-utils [03:15] which machine runs incoming.py again? [03:15] loganberry [03:28] wallyworld, ok, i'll send it up [03:28] poolie: i was just about to mark it approved in anticipation of the last few changes being made :-) [03:29] poolie: i've approved it. did you want me to land it so that i can follow up if there's any issues? [03:29] that'd be good, thanks! [03:29] i have one more mail thing in progress so i'll go on to that [03:29] gl [03:30] np. i'll wait for your changes to be pushed and then throw it at ec2 [03:31] ok, pushed [03:33] * wallyworld lands [05:20] Getting distribution for 'storm==0.19.0.99-lpwithnodatetime-r406'. [05:20] An error occurred when trying to install storm 0.19.0.99-lpwithnodatetime-r406. Look above this message for any errors that were output by easy_install. [05:20] does this mean something? [05:21] poolie: Is your download-cache up to date? [05:22] i did just update it.. [05:22] i have an r406 tarball [05:22] ah it's ok [05:22] i made a new chroot and it didn't have ccache, and my $CC points to it [05:23] Ah [05:23] That would do it indeed. [05:28] wgrant: just to double check - i got 3 ec2 runs rejected because of a pgbouncer error - that's fixed right? [05:30] wallyworld: Yup [05:30] thanks, will lp-land the fuckers [05:30] Why does each test in test_bugtask_search execute more than 400 queries :/ [05:35] * StevenK stabs TAL, and then twists the knife. [06:36] wallyworld, my attempted landings of that branch get errors connecting to postfix [06:36] OperationalError: could not connect to server: Connection refused [06:36] Is the server running on host "localhost" (127.0.0.1) and accepting [06:36] TCP/IP connections on port 52425? [06:36] maybe it's just transient [06:37] poolie: There should be a single failure like that [06:37] I fixed it a couple of hours ago [06:37] poolie: there was a bad commit by someone which commented out the startup of pgbouncer [06:37] poolie: that has been fixed now [06:37] i launched these a couple of hours ago [06:37] ok [06:37] but probably before your fix [06:37] thanks [06:37] poolie: if that's the only error then you are good to lp-land [06:37] i'll leave it with you [06:38] 23m to go :) [06:38] :( [06:38] poolie: np. what's the url? this is a different one than the mp i landed earlier? [06:39] it's the one you sent earlier [06:39] depending when you launched, you may have already caught the fix [06:39] i fired off an ec2 test earlier in parallel with your reviews [06:39] oh right, i haven't got the email from ec2 yet [06:40] still 1 hour to go before i get the failure email [06:41] you can look on its web server [06:42] poolie: sure, i was just saying out loud why i didn't realise about the failure yet :-) [06:43] wgrant: sorry, just noticed your branch, looking now [07:00] wgrant: did you know the current storm egg has the Row function? [07:00] Oh, does it? [07:00] That's handy. [07:00] yeah :-) [07:06] wgrant: perhaps it would be better, in searchClause() in TestBugTaskTagSearchClauses, to only call convert_storm_clause_to_string if the thing in not None and return None otherwise and then test_empty() can just assertIsNone which seems more natural and doesn't need the explanatory text [07:06] wallyworld: Possibly, yeah [07:06] poolie: goodbye and good luck [07:06] thanks, same to you [07:06] poolie: hopefully see you around 11th June :-) [07:07] yep :) [07:08] good morning [07:10] poolie: Likewise, good luck and hopefully I'll run into you at some point! [07:11] yep [07:12] poolie: It's a bit sad that I'm tied up for the next two weekends. :-( [07:12] one more critical bugfix for the road https://code.launchpad.net/~mbp/launchpad/893612-mail-too-big/+merge/101865 [07:12] yeah it would have been nice to see you too [07:12] poolie: But, have a great time on your travels, and have fun storming the Googleplex. [07:12] but, someone else will need to land it [07:12] thanks [07:13] * wallyworld looks at poolie's one for the road [07:13] wallyworld: Right next to the poolie's one for the kerb? [07:13] lol [07:14] And then another one for the other kerb? [07:14] And then you still have two nature strips, footpaths, street lights ... [07:15] poolie: with incoming size check, shouldn't there be a place where the check is not done anymore and so some code should be cut out? [07:16] mm good point [07:17] poolie: i'd understand if you didn;t want to do it. i can pick it up if you like [07:17] i added a comment apologizing for doing it twice [07:17] but we should just delete it [07:18] i think so. so long as all mail processing goes through the code path that now does the check [07:19] ok fixed [07:19] * wallyworld hit refresh and taps fingers waiting for the new diff [07:21] as the blackboard said to mr squiggle - "hurry up" [07:21] upside down! [07:22] now that would be a nice april fools hack [07:22] at least for aussies [07:22] i wonder if you can get there in css [07:22] wgrant is too young to get that reference :-) [07:25] poolie: r=me, i will land. thank you. [07:26] thanks mate [07:26] good night and good luck [07:26] see you in a while [07:26] yes, will do === wallyworld changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [07:29] wallyworld: I just get it :) === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 4*10^2 abgeändert === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:10] jml: No QA? :-) [09:10] :-( , rather [09:11] StevenK: sorry, no. I got caught up in other things. === al-maisan is now known as almaisan-away === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugtasks: 4*10^2 abgeändert [11:16] morning adeuring ... much reviewing today? [11:17] adeuring, it is the first friday we've both been here in a very long time [11:25] morning bac, not much to review today. ANd I must admit that simply forgot to add myself to the topic the last weeks... [11:51] benji: I decided to take the nuclear option on ThreadsafeForwardingResult: testing it so hard that the bugs glow. See https://code.launchpad.net/~jml/testtools/tsfr-fixup/+merge/10189 [12:04] jml: interesting, looking at it now === almaisan-away is now known as al-maisan [12:32] jml: the branch looks good, the comment at the top of test_only_one_test_at_a_time is probably the single most valuable thing in the branch and would have saved me many hours, perhaps even a day of flailing [12:32] benji: :) [12:32] jml: the other test methods could really use similar descriptions of why the test is important and what it demonstrates [12:33] benji: I tried to tell you that thing on IRC yesterday. [12:33] or in the MP or somewhere [12:33] jml: you succeeded :) the day of flail preceded that [12:33] having it in the code ++ [12:33] heh, good to know [12:46] benji: have just pushed some documentation and comment tweaks: r263 [12:46] I'll take a look. [12:46] benji: you might also be interested in https://code.launchpad.net/~jml/testtools/wrap-result-in-concurrent-suite/+merge/101902 and https://code.launchpad.net/~jml/testtools/tagger/+merge/101904 [12:49] anyway, now all of that is out of my head, I will return to my irregularly programmed schedule. [12:49] jml: is there any reason not to always tag tests run concurrently? [12:50] benji: I don't know, to be honest. [12:50] benji: I thought about it. [12:50] hmm, I don't know if subclassing will work for us because we don't controll the code running subunit (it's testr) [12:51] benji: well, I don't think there's a reason for testr not to always tag tests that run concurrently :) [12:52] benji: the reason (to give it too grand a name) I didn't tag tests automatically is because this approach felt more like "here's a bunch of components that you can assemble at will", which is more in keeping with some internal, vague, design aesthetic I have [12:53] jml: I suppose we could do it that way. When do you expect these three branches to land? [12:53] benji: testtools has a 24hr timeout on code reviews. [12:54] jml: meaning that if they aren't reviewed in 24 hours they are assumed approved? [12:54] benji: so, I guess some time tomorrow, unless lifeless responds with deep objections. [12:54] benji: right. [12:54] k [12:55] benji: obviously we allow for post-merge reviews, and I'd certainly like to get a second opinion from lifeless before a release. [12:55] makes sense [13:00] Morning, folks. [13:01] morning [13:02] hmm. [13:02] I guess this leaves a natural opening for a subunit tool that takes multiple input streams and generates one output stream. [13:32] abentley, ping for standup [13:33] I'm getting tracebacks running webservice tests, to do with the google service [13:33] http://pastebin.ubuntu.com/927931/ [13:36] ah, maybe that's because I didn't update my /etc/hosts file [13:37] (wow, the things you forget!) [13:40] the things we forget are the things we shouldn't be expected to remember <0.2 wink> === al-maisan is now known as almaisan-away [13:46] https://code.launchpad.net/~jml/launchpad/expose-commercial-on-create-ppa/+merge/101907 [13:46] 1 line patch. [13:46] flacoste: hello [13:46] hi jml [13:46] flacoste: may I please have a LoC exception for https://code.launchpad.net/~jml/launchpad/expose-commercial-on-create-ppa/+merge/101907 [13:46] flacoste: also, if you could review & land it, that'd be great too. [13:49] jml: i'm kind of swamped today, so i may look for the exception, but review and land will have to be delegated [13:50] flacoste: no worries. it's a one-line patch, if that helps. [13:53] abentley: you moved ec2test to lp-dev-utils, right? how do I run the tests there? [13:53] jml: I was using nosetests. [13:56] abentley: any PYTHONPATH mangling required? (it seems to depend on 'lp'?) [13:57] jml, no. I run "nosetests ec2test" and it seems happy. I think there are two failing tests. [13:58] abentley: oh, there are failing tests in trunk? What failures do you get? [13:58] jml: https://pastebin.canonical.com/64277/ [13:59] abentley: cool. those are the ones I get. thanks. [13:59] jml: IIRC, fakemethod is also provided by bzr-pqm. [14:00] abentley: ta. [14:18] abentley: different API, it seems. [14:19] FakeMethod in bzr-pqm (at least the version on the system that comes via rocketfuel-setup) doesn't have call_count. [14:19] jml: doh. I guess we should have been more aggressive about switching this code to bzr-pqm originally. [14:20] abentley: well this particular thing is just about using a home-rolled mocking library, right? [14:20] jml: Yes. [14:22] * jml is tempted to re-implement [14:22] brb [14:40] abentley: https://code.launchpad.net/~jml/lp-dev-utils/fix-tests/+merge/101916 [14:41] jml: I said earlier that PYTHONPATH does not need to be set. What makes you say it does? [14:41] abentley: because setting it makes the test pass. [14:41] jml: Which tests does it make pass? [14:42] abentley: ec2test.tests.test_remote.TestDaemonizationInteraction.test_daemonization [14:42] abentley: the error indicates that it can't find ec2test.remote [14:42] abentley: but of course, ec2test.remote exists and is perfectly easy to find, if you have PYTHONPATH set so that the 'ec2test' package is discoverable. [14:46] jml: When I want subprocesses to have the same pythonpath as the current process, I usually set it in the code that invokes the subprocess. [14:47] abentley: well, not when you're hacking on Launchpad you don't. You use ./bin/py. [14:47] jml: I can use bin/py when I'm hacking on Launchpad. [14:48] abentley: so you suggest converting turning sys.path into an env var and passing that through in the code that spawns the subprocess? [14:48] jml: Yes. [14:49] abentley: got a shell quoting function handy? [14:50] jml: I don't understand why I would need one. Are you saying that python shell-expands the contents of PYTHONPATH? [14:50] deryck: ping, do you have a sec? I'm not seeing tests for any of these cases and I'm feeling like I must be missing something [14:50] I'm wearing grep out I think [14:52] jml: Testing shows python does not shell-expand PYTHONPATH. It does not expand $PETER in this example: http://pastebin.ubuntu.com/928037/ [14:53] oh man, nvm...having a monday for a friday. limiting to .py files won't find a bunch of tests :/ [14:53] deryck: ^ [14:56] abentley: what if sys.path has paths that have a space or a colon. [14:58] space seems to work [14:58] shell quoting when spawning subprocesses is a really bad idea [14:58] use the functions that don't require shell quoting instead ... [14:58] cjwatson: agreed. [14:59] OEK [14:59] OK [14:59] e.g. subprocess.Popen and friends let you pass env=, so you copy os.environ and replace the keys you want directly [14:59] Pretend I didn't say shell quoting. How do you safely turn sys.path into a value for PYTHONPATH that works regardless of what crazy paths are in sys.path? [14:59] cjwatson: Sure. [15:01] rick_h, sorry, was on call. [15:02] rick_h, I'm just about to step in another call. can we chat after that? [15:02] deryck: I think I'm ok now. Sorry for the ping [15:02] jml: I don't know how to escape colons in a PATH. Looking into it. [15:02] rick_h, dude, no worries. always ping when in doubt. sorry it took me so long to reply. [15:02] AFAICS there's no way to wedge an entry containing os.pathsep into PYTHONPATH. [15:03] The good news is that, since it can't have got into sys.path via PYTHONPATH, the only way such a directory would be on sys.path is if you put it there yourself. [15:08] fsvo 'you' [15:08] cjwatson: Exception: https://pastebin.canonical.com/64293/ [15:09] is it still impossible to rename teams with PPAs that have been deleted, but were published in the past? [15:10] anyway, I've pushed up an os.pathsep.join(sys.path) version and updated the docs. [15:11] jml: I think you can also update testr.conf [15:12] abentley: I tried. It fails when cwd isn't in PYTHONPATH [15:13] abentley: I can't speak for nosetests, but I'm pretty sure trial adds '.' to the sys.path as a convenience. [15:13] jml: I saw 123 tests. Are you seeing only 84? [15:13] abentley: trial shows 88 [15:14] * jml runs w/ nosetests [15:15] abentley: 125 w/ nosetests [15:17] abentley: I think that's because nosetests incorrectly discovers the TestRequest tests (from test_remote) inside remote_daemonization_test.py [15:18] abentley: which imports TestRequest in order to get at a helper function. [15:18] jml: Okay, cool. So long as we know why it happens. [15:19] abentley: it's a little fiddly to extract, because the helper relies on bzrlib.TestCase*'s make_branch_and_tree [15:19] I really should have pushed harder to get that stuff extracted out of the TestCase inheritance hierarchy. [15:21] brb === salgado is now known as salgado-lunch [15:28] jml: r=me [15:28] abentley: thanks. How do I land it? [15:28] jml: We just push to that branch. [15:29] \o/ [15:29] abentley: I don't have commit access to that branch. [15:29] jml: I will do it, then. [15:29] abentley: thanks. [15:31] jml: I am going to add .testrepository to the list of ignored files. [15:31] abentley: good call. I think I have it in my global ignore [15:32] oh that reminds me [15:32] bac: thanks for the review. can you please submit my branch to ec2 test? [15:34] jml: landed. [15:35] abentley: thanks. [15:40] 362877 [15:41] rick_h: 32568 [15:42] abentley: bah, my secret it out [15:45] adeuring: chat? [15:45] abentley: sure. mumble? [15:46] adeuring: sure. === matsubara is now known as matsubara-lunch [15:55] deryck: sanity check time, I'm not seeing the sendmail.simple_sendmail work through the IMailer and so stub.test_emails no longer works. [15:55] deryck: in checking out how the sendmail it seems to be straight monkey patching/revert? http://paste.mitechie.com/show/616/ [15:56] deryck: so I should be doing this in the doctest for checking the notification emails? or am I not seeing the magic pretty way to do it like stub.test_emails? [15:59] * deryck is readying back, thinking..... [16:02] rick_h, stub.test_emails is how we normally inspect mail in doctest. and that doesn't work when calling sendmail in process. I get that problem right? [16:03] deryck: right, sendmail.simple_sendmail doesn't hit the stub.test_mails bit [16:04] deryck: and it looks like it's because it doesn't use/implement the IMailer interface that stub is working against [16:04] rick_h, right. it's just a function that calls sendmail directly, IIRC. [16:04] deryck: basically updating hte doctest to monkey patch and restore sendmail.simple_sendmail is ugly as can be and tossing out a last ditch effort I'm missing something [16:05] deryck: right, looks like it [16:05] rick_h, yeah, 1) I wouldn't monkey patch in doctest. I'd create a doctest helper if needed, and 2) we have to have something for this already, let me look more.... [16:06] deryck: rgr on 1, figured I'd need to do that since I'm updating several doctests to get this tested for each notification [16:15] rick_h, so I really thought when someone is subscribed to a bug, that we send them a notification in process in this same way.... [16:15] rick_h, kind of a wart I'm recalling that we sent mail in process. [16:16] rick_h, and the testing is the same it seems. see: lib/lp/bugs/stories/bugs/bug-add-subscriber.txt [16:16] rick_h, so either, I'm wrong and we don't do it in process, or you can look there and work out what is different about that test that it works. [16:17] deryck: ok, will look there. Probably using a different method of sending the emails than the simple_sendmail [16:17] deryck: thanks [16:22] rick_h, so the subscription stuff does use the event system to trigger sending mail, but it still just wraps a callback that calls sendmail directly, which is at heart the same thing you're doing.... [16:23] rick_h, see lp.bugs.subscribers.bug.send_bug_details_to_new_bug_subscribers to see how the mail is sent.... [16:23] rick_h, and the stub mailer works fine there. [16:23] deryck: looking [16:29] rick_h, should we high bandwidth this in a hangout? [16:29] deryck: sorry, trying to pdb to see if I'm actually hitting the email code like I think I am and so is stub emails blank because simple_sendmail doesn't hit it, or my code isn't working like I think it should [16:30] except in doctest having a hard time seeing if I'm hitting pdb because of hte block of code I think I am [16:30] pdb doensn't show me the line num of the doctest in the path so not sure if it's a test before/after the one I'm trying to see [16:30] rick_h, yeah, that's why I was thinking hangout.... we could step though the paths together. [16:30] deryck: sorry, long way of saying give me a few min [16:31] deryck: k, hangout is ok then [16:31] rick_h, yeah, let's do, just to possibly save you some frustration. [16:31] deryck: ok, we can try :) === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugtasks: 4*10^2 [16:55] ok, if in doubt, transaction.commit! === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado [17:54] hi abentley , i'm finding when i run out tests within an lxc that many (perhaps all) of the celery tests fail with a timeout. can you give me some advice on tracking this down? [17:54] s/out/our [17:54] bac: with you in a minute. [17:55] bac: Okay. [17:56] bac: So, the timeout is emitted from a line that says something like responses[0].wait ? [17:56] http://paste.ubuntu.com/927046/ [17:56] abentley, yeppers [17:57] abentley, ignore the 'whoami' errors, those have been resolved [17:57] only interested in the timeouts [17:58] bac: So this means that rabbitmq did not send a message saying the job was processed in 30 seconds. [17:58] bac: possible causes: celeryd did not start correctly [17:58] bac: celeryd was not listening to the correct rabbitmq instance [17:59] bac: Not sure what else. [17:59] abentley, should celeryd be running outside of the tests? [18:00] bac: No, the tests that need it will start it. lp.services.job.tests.celeryd is a context manager that starts and stops celeryd. [18:00] ok [18:01] bac: does this happen if you restrict the tests to just ones using celery (e.g. "-t Celery") ? [18:03] abentley, let me try [18:04] bac: I am guessing that if all the celery tests run on process, they work, but if they run on different processes they don't. [18:04] s/run on process/run on one process/ [18:05] bac: rebooting. Back in a sec. [18:09] bac: My best guess is that celeryd will be using the RabbitMQ config associated with another process. [18:11] bac: To test this, we could print celeryd's Popen.stderr. That will indicate the broker config. The Popen object is yielded by lp.services.job.tests.celeryd. [18:11] ok [18:11] bac: in some tests, it's referred to as "proc". [18:12] abentley: Total: 12 tests, 2 failures, 5 errors in 5 minutes 25.011 seconds. [18:12] bac: Okay, cool. We can reproduce it, then. [18:15] bac: lp.code.model.tests.test_branch.TestBranchJobViaCelery.test_branchChanged_via_celery show a "Function not implemented" OS error. [18:15] bac: That may be the root cause of all of this. [18:17] abentley, where do you see that FNI error? [18:18] bac: line 279 of your paste. [18:18] bac: reconstructed: http://pastebin.ubuntu.com/928292/ [18:19] abentley, hey, that makes sense as there is a problem with lxc and semaphores [18:19] bac: yay? [18:20] abentley, cool, thanks for the pointer [18:20] bac: np. [18:23] bac: if celeryd is incompatible with lxc, I guess the options are 1. fix lxc, 2. fix celeryd, 3. run celery tests outside lxc. [18:24] 4. run celeryd outside lxc, run tests that use it inside lxc. [18:44] Hey we're getting ready to bump the 'charms' distribution from oneiric->precise .. which means a LOSA running the script that does that. I forget who I need to ping to get that done. [18:44] flacoste: any ideas? ^^ [18:45] SpamapS, copying branches, or just setting the precise as the default release? [18:45] james_w: he probably wants to copy branches also [18:45] or rebase them [18:46] SpamapS, either way saying "webops ping" will get you a friendly webops (neé LOSA) to help when it is time [18:46] I want to do both [18:46] (sorry webops) [18:47] we need to shift dev focus to precise, and copy all the oneiric branches to precise. [18:47] so they'll know the script to do it? [18:47] also will the mass copy process just ignore anything that has already diverged in precise? [18:47] I asssume yes [18:54] SpamapS, https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/BranchUbuntu?highlight=%28branch%29|%28distro%29 [18:54] that's the script we use for Ubuntu [18:54] I don't know how it handles existing branches though [18:56] it looks like it might not handle it all that well [20:10] abentley, i just saw this commit message of yours and had to laugh: "There's no j in Launchpad." [20:10] bac: :-) === gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 === matsubara is now known as matsubara-afk === lan3y is now known as Laney === Laney is now known as Guest91745 === Guest91745 is now known as Laney