[01:50] wallyworld_: Can you QA r15475 soonish? [02:14] * StevenK stabs Python process handling. [02:15] StevenK: What are you doing and why? [02:16] wgrant: Trying to debug AuditorFixture._stop() [02:16] Ah, that. [02:17] StevenK: SIGPIPE again ? :> [02:17] lifeless: Already SIG_IGN'ing PIPE [02:18] It drops out of _stop() without actually killing the process. [02:36] I've QAed r15480; it has problems which mean the new API isn't usable, which I'll work on tomorrow, but as far as I've been able to determine there are no regressions in existing functionality, so I marked it qa-ok. Feel free to check my reasoning in bug 334858. [02:36] <_mup_> Bug #334858: Require a way to copy [P]PPA packages into Ubuntu

< https://launchpad.net/bugs/334858 > [02:37] cjwatson: Right, sounds good. That usually means a missing commit, indeed. [02:38] Since you can't read back an LFA's content unless it's been committed. [02:38] Too much to hope that I'd get it all right in one go. I wonder how delayed-copy processing manages to get it right, since I can't see a commit there. Maybe it's implicit somewhere. [02:39] Delayed copies have regressed in that respect once or twice [02:39] I forget how it works [02:40] Maybe it works because delayed copies get hold of the changelog manually rather than going through the SPR. [02:41] As in, from the .changes, which PCJs can't do. [02:41] Ah, yes, that would be it. [02:42] But some aspect of delayed copies sometimes tried to read it back [02:42] And died [02:42] Possibly rejection [02:42] Can't quite remember [02:42] Anyway, thanks for QAing [02:42] Clearly means I need to add a test for the PCJ as well as the PackageCopier path, anyway. [02:42] Grumble. [02:45] I suspect also I need to do pocket queue admin permissions before we can kill unembargoing and the ubuntu-security celebrity, since doing it with PCJs means their uploads will all wind up in unapproved. [02:45] Indeed. That's going to be a little awkard on +queue, I suspect, but shouldn't be too much effort. [02:46] Hm, actually. [02:46] How's that going to work at all [02:46] Because they'll still be private.. [02:47] In the queue it'll just be a suspended PCJ [02:47] Yeah [02:48] Hopefully it won't break when it tries to access its attributes. [02:48] Oh, I hope it doesn't need to ... yeah, that [02:50] I think it's OK. The attributes all come from the PCJ's metadata dict or similar. [02:51] Great. [03:05] StevenK: sorry, was at locksmith, qa done now [03:05] wallyworld_: More mailbox trouble? :-) [03:06] StevenK: yes, bloody keys i got didn;t fit, i had to break in and rip off the front flap and tale it all in [03:06] the lock turned out to be a cheap chinese version and there are no key blanks here [03:10] wallyworld_: Ah, so you were so desperate for the phone cover that you broke into the mailbox. :-) [03:10] StevenK: that arrived last week and i had to use a coathander to hook the package and lift it out [03:11] Now that is desperation. [03:12] yep [04:08] lifeless: This is incredibly frustrating. :-( [04:31] Sigh. self.process.wait() returns immediately, but the process isn't dead. [04:32] StevenK: sorry, context switching [04:32] so whats up ? [04:33] lifeless: fixture._stop() is supposed to kill bin/auditor-manage. [04:36] does auditor-manage fork or something ? [04:36] I doubt it [04:37] It's the usual 'python manage.py runserver' which is used for development, so I'd be very surprised if it does. [04:37] ok [04:37] so the code looks reasonable [04:37] server.poll() is None implies has not exited. [04:37] erm [04:37] process.poll() [04:38] StevenK: what do you see happen ? [04:38] StevenK: have you tried using pdb and stepping through it ? [04:39] lifeless: I've tried printf debugging, which hasn't been much help. [04:39] do you want video + debug help? [04:39] right now I don't know what you've learnt. [04:39] so I'm starting cold. [04:40] lifeless: Today I've learnt that 1) I either don't understand process workflow under Unix or this thing is misbehaving, 2) I feel like I've wasted today on it. :-) [04:41] the day isn't over. [04:41] lets free our hands for actual examination: skype or g+ ? [04:41] lifeless: Would you mind looking sans Skype/G+ for 10-15? I've just taken Advil for a headache. [04:41] not at all [04:42] so, tell me a) how to reproduce and b) all that you have learnt. [04:42] is your code up online etc. [04:43] lifeless: Just pushed auditor [04:43] ?win 85 [04:46] lifeless: auditorfixture updated [04:51] lifeless: Easiest way to reproduce is run the testsuite. One test will fail, but if you look at ps aux afterwards you'll see two auditor-manage's hanging around. [04:52] lifeless: What I have learnt is that the _stop() method does get called, and it does call self.process.terminate(), and the next time around the loop self.is_process_up returns False and it exists, but the process is still running. [04:52] s/exists/exits/ [04:53] ok [04:53] so lets get some more details [04:57] StevenK: so, I'm putting a breakpoint in _stop. And running the test suite [04:58] StevenK: so it gets terminated via SIGTERM [04:59] lifeless: Are the processes still running, though? [04:59] StevenK: but nothing is reaping it [04:59] so it sits defunct [05:00] But Python should catch the SIGCHLD and reap it? [05:00] no [05:00] not AFAIK [05:00] also [05:00] you may well be running into a signal handling race condition [05:00] lets see [05:01] I thought the entire point of subprocess was abstract out this mess. :-P [05:01] but let me check the code a bit more [05:05] StevenK: so, its kill the process, reliably. [05:05] StevenK: compare: [05:05] :!bin/test [05:05] Running zope.testrunner.layer.UnitTests tests: [05:05] Set up zope.testrunner.layer.UnitTests in 0.000 seconds. [05:05] 23890 [05:05] thats the pid [05:05] then [05:05] 23890 [05:06] 23894 [05:06] 23894 [05:06] (twice through apparently) [05:06] but [05:06] compare the leaked processes: [05:06] robertc 23895 5.7 0.2 206692 19168 pts/10 Sl+ 17:05 0:00 /usr/bin/python /home/robertc/source/launchpad/auditorfixture/working/auditorfixture/tests/../../bin/auditor-manage runserver 9999 [05:06] robertc 23891 5.7 0.2 206692 19164 pts/10 Sl+ 17:05 0:00 /usr/bin/python /home/robertc/source/launchpad/auditorfixture/working/auditorfixture/tests/../../bin/auditor-manage runserver 51284 [05:06] note the pids are one out [05:06] Which means it probably did fork [05:07] robertc 23918 17.6 0.1 61964 15036 pts/10 S+ 17:06 0:01 \_ /usr/bin/python -S bin/test [05:07] robertc 23919 1.6 0.1 52288 15740 pts/10 S+ 17:06 0:00 \_ /usr/bin/python -S /home/robertc/source/launchpad/auditorfixture/working/auditorfixture/tests/../../bin/auditor-manage runserver 47997 [05:07] robertc 23920 2.8 0.2 206688 19156 pts/10 Sl+ 17:06 0:00 \_ /usr/bin/python /home/robertc/source/launchpad/auditorfixture/working/auditorfixture/tests/../../bin/auditor-manage runserver 47997 [05:07] ^ you need to be way more paranoid. [05:07] It double fork()'s? :-( [05:09] paranoid about assuming I think I mean [05:09] anyhow, yes, it looks like it does. [05:10] well, something does. [05:11] Single fork() should be dealt with fine because it will be the same process group, but a double fork is not, from memory. [05:13] if we signal the process gorup [05:13] by (IIRC) doing -pid [05:19] nah [05:19] the pgroup they are in is the teset servers group [05:19] because we're not making one when we spawn [05:20] should be easy to fix, one sec [05:20] lifeless: I really don't want to call os.setsid() in the fixture ... [05:27] lifeless: It wasn't so easy? [05:29] StevenK: lp:~lifeless/auditorfixture/pgrphandling [05:29] StevenK: it was, Lynne got home [05:30] Ah, heh. [05:30] * StevenK looks. [05:31] lifeless: Bah, and you do end up using os.setsid() :-) [05:32] of course [05:32] but, it works [05:32] and doesn't leak defunct processes like a sieve [05:33] Which was the entire point of the exercise [05:33] it was leaking defunct *and* live ones before [05:33] this is twice as much betterness ;) [05:34] StevenK: HTH, -> dinnery stuff, will ping later to see how you went [05:34] lifeless: Aye [06:47] Hello, I have deployed launchpad. But I can't register new user now. Could anyone give me some hints? [06:49] lifeless: HAH. Now I have to put django into download-cache [06:56] Brooklyn: The testopenid provider that Launchpad dev instances use doesn't support registration. You'll need to point it at a proper OpenID provider. [06:56] lifeless: Bah [07:02] wgrant: Thanks for your reply. [07:06] lifeless: So it turns out that bugsummary queries for source packages are a hundred or so times slower than they need to be. [07:06] lifeless: There's no usable index starting with (distribution, spn). [07:06] lifeless: So eg. the stats portlet falls back to (distribution, status) then filter on that [07:06] etc [07:07] cool [07:08] lifeless: Was this a deliberate decision, do you recall? [07:08] no, oversight [07:08] Great, thanks. [07:08] it was intended to index all the use cases to be fast [07:08] Just wanted to check you didn't find some horrid postgres terribleness [07:09] not that I recall [07:10] Now the rebuild is a little faster :) === matsubara-afk is now known as matsubara [08:01] morning === almaisan-away is now known as al-maisan [09:23] wgrant: is it possible to properly remove a ppa instead of seeing a message ppa is deleted? [09:24] Not at present [09:25] is it possible to re enable it once it's deleted? [09:25] Um [09:25] Sort of [09:25] If they go to +edit and click the Enabled and Publish checkboxes it will mostly work [09:25] ah ok [09:26] But it's best to tell the users to build a time machine and not delete things that they don't want deleted. [09:26] well this is true :) [09:26] but at least I can now asnwer people who have yet to build a tardis :) [09:26] wgrant: cheers [09:38] could someone lp-land https://code.launchpad.net/~lifeless/launchpad/sourcecode-meta/+merge/111527 for me? _still_ haven't sorted my landing story. I know, I suck. [09:39] hi lifeless [09:39] lifeless: lp-land rather than ec2 land? [09:39] have a look at the branch, and make your own mind up :) [09:39] heh, okay.. still waiting for the diff to come up :) [09:39] It won't [09:39] It timed out days ago [09:40] * jelmer grumbles [09:40] lifeless: anyway, I'll land once I manage to extract a diff [09:42] jelmer: :> [09:42] jelmer: thanks, appreciated! [09:47] wgrant: I am not familiar with zope. Is there any document about how to point testopenid to an openid provider? [09:49] Brooklyn: This is all LP-specific stuff, not Zope. It's easiest to set vhost.openid.hostname in the launchpad-lazr.conf of the config that you're using, then change launchpad.openid_provider_vhost from 'testopenid' to 'openid' [09:50] wgrant: Thank you so much :) I will try that [10:01] bac,wgrant: Could you have a quick look over https://code.launchpad.net/~cjwatson/launchpad/pcj-reupload-fix/+merge/111804 for me? Should fix last night's QA failure. [10:01] cjwatson: Looking [10:02] I think the bac is a lie. [10:02] I thought so too, but you never know [10:03] cjwatson: Hmm [10:03] https://dev.launchpad.net/ReviewerSchedule [10:03] cjwatson: I wonder if we can detect if we're in a webapp request and die violently there. [10:03] since committing the in middle of a webapp transaction is a less than good idea. [10:04] Mm, I did wonder what the rules for that were [10:04] "don't" [10:04] I suppose it might also be possible to extract the changes from the restricted file and pass those into notify [10:04] The librarian sometimes makes it challenging, unfortunately. [10:04] Right [10:04] Or you could commit after the copy and before the notify [10:05] There's an argument that that might be safer [10:05] But in the caller. [10:05] I forget where that is. [10:05] Tryue. [10:05] It's only one level up, in do_copy. [10:05] wgrant: I use login.ubuntu.com and finally it works!! Thank you so much! [10:05] Brooklyn: Excellent! [10:05] I didn't think moving it up there would be desperately useful, and it would make it harder to tell whether it's necessary due to unembargoing. [10:06] It's awful either way. [10:07] Extracting the changes content isn't exactly a one-liner right now. [10:08] Awful but possibly necessary :) [10:09] Though we don't need changesfile_content in this case, which helps. [10:16] wgrant: Wait, isn't notification mail queued until the transaction is committed? I could notify first and *then* update privacy. [10:16] cjwatson: Sneaky and mildly evil, but probably quite effective. [10:16] That would still involve a bit of rearrangement but should be way easier. === al-maisan is now known as almaisan-away [10:54] wgrant: Have another look? I think that should be better now ... [11:17] cjwatson: Looks good, thanks. === matsubara is now known as matsubara-lunch [11:47] matsubara-lunch: ping me when you get back, please. [11:52] bac: good morning :) [11:53] hi czajkowski [11:57] night === matsubara-lunch is now known as matsubara [12:02] bac, hi [12:03] hi matsubara. did you want to talk at 1230UTC or 1430? [12:04] bac, hey, just replied to your email. let's do 1430 as I have the team stand up in 40min [12:04] matsubara: works for me. thanks! [12:04] bac, de rien [12:07] jelmer, lifeless: I think the change you did/landed broke buildbot. [12:09] jelmer: I think http://pastebin.ubuntu.com/1058978/ will fix it, can you investigate? [12:12] It broke EC2 too. [12:12] Well, ec2 land. [12:13] Yeah, utilities/update-sourcecode does not like blank lines in sourcedeps.conf [12:13] Which lifeless added [12:14] Maybe http://paste.ubuntu.com/1058982/ to preserve LoC; just as clear I think [12:15] cjwatson: But that doesn't work either [12:15] Er, that's precisely equivalent to your patch [12:15] if line == '\n' or ...: does [12:15] cjwatson: Yes, the patch was untested at that point. :-) [12:16] make worked fine, it took a little longer to realise this step was before it. [12:16] Ah yes. I usually use "line = line.rstrip('\n')" at the start of loops for that kind of thing. [12:17] It's an ugly hack, but let me land it. [12:17] It's clear that sourcedeps is deprecated and lifeless has an eye to remove the whole kit and caboddle at a later date. [12:18] if not line.strip(): continue [12:18] wgrant: Does not deal with comments. [12:18] Bit surprised that failure to strip \n doesn't cause other problems. [12:18] cjwatson: The function calls yield line.strip() after that [12:19] No, it calls yield line.split() [12:19] >>> "foo\tbar\n".split("\t") [12:19] ['foo', 'bar\n'] [12:19] Ah, hmmm [12:19] Oh, but split() with no args is magical [12:19] >>> "foo\tbar\n".split() [12:19] ['foo', 'bar'] [12:19] Fair enough [12:20] I guess it counts \n as whitespace [12:23] lifeless: Your failure to test that comment change in sourcedeps.conf means you owe me a beer. :-P [12:24] cjwatson: Fix landed, ec2 should now be happy again. [12:25] Yay [12:48] StevenK, wgrant: Sorry, we had just headed out to lunch here :( [12:48] Thanks for picking up the pieces === jtv1 is now known as jtv [13:00] wallyworld_: thanks for the reply [13:01] rick_h_: np. did it make sense? [13:01] thanks for taking a look also [13:01] yea, I remember that issue and didn't think about it while reading over [13:02] rick_h_: once we have all the js out of the tal and everything in the combo loader done, it won't be an issue i don't think [13:02] I need to blank out some time to go over the picker stuff at some point. You'd think between your stuff and jcsackett's stuff I'd 'get' it by now [13:02] rick_h_: that stuff is "interesting" to say the least. i'd love to know the thought process behind how it was originally done [13:02] wallyworld_: yea, was going through the YUI3 cookbook and the idea of YUI blocks loading additional modules lazy-loaded seems interesting for stuff like this [13:03] I wonder if some sort of master "UI builder" would help us combine TAL blocks and keep things in one use() block without loading all our JS at once [13:04] not sure. now that we have the core stuff all done, we can tackle these edge cases [13:04] yea [13:04] we still gotta make dev use raw instead of min though [13:05] wallyworld_: ah, yea you know what, I'll try to get something in for that today if I can. I might have some slack time for that [13:06] rick_h_: it's also been on my todo list but too litte spare time :-( [13:09] rick_h_: something i just discovered - if i have an widget attribute eg my_form: {value: Y.Node.create('

')}, the attr is only inited once and all new Y.mywidget() instances have the same attr value [13:10] i have to construct the attribute vale in the initialiser [13:11] wallyworld_: right, you need to use a valueFn [13:11] it's like using a mutable default for a method in python [13:11] ah of course. i forgot that. i've used a valuefn previously. thanks [13:11] np [13:11] yea, been bit myself with that sometimes. You want to do it, but makes sense as it's only created once on JS parse stage [13:12] yeah. i just plain forgot. my brain is too full with everything === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 3.47*10^2 [13:35] bac: Are you still looking at https://code.launchpad.net/~cjwatson/launchpad/copy-custom-uploads/+merge/111653 ? It looks like you claimed a review there a few days ago [13:36] cjwatson: i did claim it but then signaled my intent to give it up by adding the review team back [13:36] cjwatson: i guess i should have voted abstain [13:37] Ah, I missed that subtlety [13:37] cjwatson: abstained now. sorry i was able to get to it. [13:39] No problem. [13:40] benji: ^- Do you think you might be able to pick up that one? I'm trying to make gradual progress on a sort of semi-overlapping chain of stuff, and that one would be nice to get out of the way both to unblock other things and on its own merits. [13:41] I know it's a pretty soyuz-heavy branch [13:41] cjwatson: sure [13:50] cjwatson: your branch looks good [13:58] benji: Thanks! If I may have Status: Approved then I can land that [13:59] And hopefully delete a swathe of ugly documentation [14:00] cjwatson: you can (and IMO) should do that yourself as it is the signal that everything about the MP that needs to be approved has been and only you know that. I approved the code, but there may be UI elements or other things that need review (like back in the day when we had seperate JavaScript reviews). [14:01] benji: I can't, because I'm not in launchpad-reviewers. [14:01] cjwatson: then I suck ;) [14:01] I understand the model, but I break it by being !~launchpad-reviewers but having PQM access. :-) [14:02] cjwatson: done [14:02] I believe lifeless thinks it ought to be possible to add non-Launchpadders to that team ... [14:02] So yeah, right now I just have to ask, sorry. Thanks [14:03] (Maybe I mean ~canonical-launchpad-committers) [14:08] * cjwatson finds the mail about that and goes to reply, to see if he can sort this out more permanently [14:30] hi matsubara. is now good? if so i'll create a hangout [14:31] bac, yep. let me grab my headset and something to drink [14:32] bac, ready whenever you are. just send me the link please. [14:32] matsubara: sent you an invite [14:58] sinzui, i have a couple of questions about what's left in LP: #210821 [14:58] <_mup_> Bug #210821: bug tracker list shows inactive projects <404>

< https://launchpad.net/bugs/210821 > [14:59] sinzui, actually, the duplicated one (which i didn't notice before) LP: #857888 [14:59] <_mup_> Bug #857888: Deactivated projects shown on BugTracker:+index <404> < https://launchpad.net/bugs/857888 > [14:59] sinzui, here's a diff with the fix: http://pastebin.ubuntu.com/1059175/ [15:00] I recall it [15:00] sinzui, my question is that the current code uses projects + products [15:00] while the IBugTrackerSet.getPillarsForBugtrackers returns products + projects [15:01] hmm [15:01] what would be best? to change the current portlet code [15:01] We prefer to return small to large, so product, project-group, distro [15:02] ah [15:02] so i could change the porlet to return that order [15:02] and getPillarsForBugtrackers already does it [15:03] sinzui, my second question is, how do you test that in a functional test? [15:03] +1 for the code fix [15:04] i mean, how do you test the order in the test [15:05] is there any way to get the contents of the testbrowser and say "get me all links in this div"? [15:05] replaceafill, We want a new testcase in lp/bugs/browser/tests/test_bugtracker.py that tests the view's attr. [15:06] ah ok [15:06] i thought i needed to test the returned html :) [15:06] We can either reproduce a similar setup of your previous test... [15:06] sinzui, ah ok [15:07] sinzui, i'll work on that and show it to you later [15:07] or we mock out getPillarsForBugtrackers() in the test and verify it was called [15:07] sinzui, i'll go with copying my previous setup [15:10] replaceafill, make me the reviewer when you are ready since I already understand why the first branch did not fix the UI situation [15:10] sinzui, ah ok, will do === Ursinha` is now known as Ursinha === Ursinha is now known as Guest89684 [15:20] replaceafill, this is a sketch of the test I would have written to verify the view differs to the the tracker set: http://pastebin.ubuntu.com/1059206/ [15:21] ah, mocking :) [15:21] cool, i'll use that then [15:21] I prefer this kind of test because changes to the set's method means I need to update the set's test and the views test [15:22] ah, got it === Guest89684 is now known as Ursula === Ursula is now known as Ursinha === deryck is now known as deryck[dentist] === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [16:50] benji: Oops, I have a test failure in copy-custom-uploads. Does http://paste.ubuntu.com/1059344/ look OK to you on top of that (that's in [initializedistroseries])? That fixes the test here. [16:51] * benji looks. === salgado is now known as salgado-lunch [16:51] cjwatson: yeah, looks fine; DB security has tripped me up on a couple of occasions too [16:55] Right, thanks. I think I'll kill the current test and send this through. === salgado-lunch is now known as salgado === deryck[dentist] is now known as deryck [18:55] gary_poster: do you know off the top of your head what gtk-items are needed for the python-html5-browser for JS tests? [18:55] rick_h_, the standard gtk setup [18:55] gary_poster: sorry, I nmean in LXC that is [18:56] sinzui: ok, was curious of the yellow guys had a shortlist of deps for that since the tests are running in lxc as well [18:56] rick_h_, oh. I think this would be a sinzui question. the lxc aspect should basically mean its like trying to make it work in Ubuntu server [18:57] rick_h_, well...we add the launchpad-deps [18:57] ok, yea I've got those, but getting an error "RuntimeError: Gtk couldn't be initializ" [18:58] for the js tests from the container so assumed the normal setup is expecting some basic gtk packages to be there that steting up an lxc container leaves out [18:58] which ends up adding what we need there. Like I said, there's nothing specific to the LXC story I can think of there. Ah rick_h_ I might have a cure for what ais you. [18:58] ails, even [18:58] rick_h_, first, you are using xvfb-run, right? [18:59] well starting out just by doing: ./bin/test -x -cvv --layer=YUITestLayer [18:59] that's what I've done in the past to run just JS tests. [18:59] rick_h_, no, that's not good enough I'm afraid. That's not an lxc thing, it is a server with no X running thing [18:59] ah ok [18:59] so, if you look in the tree... [19:01] well, all you *have* to use you can find in the current .testr.conf: xvfb-run ./bin/test [other options] [19:01] there's a more "careful" spelling we use for the tests [19:02] xvfb-run --error-file=/var/tmp/xvfb-errors.log --server-args='-screen 0 1024x768x24' -a bin/test blah blah blah [19:02] the --error-file is the least important [19:02] ok cool, yea I see that in the test_merge file [19:03] test_on_merge that is [19:03] rick_h_, that's server specific. there is one lxc bug unfortunately [19:03] that affects this [19:03] lemme get that detail [19:03] StevenK: I asked jelmer to make an informed decision ;) [19:03] ok thanks. I assumed it was a lxc issue [19:03] StevenK: so I will cheerfully a) disclaim all responsibility and b) buy you a beer anyhow. [19:04] (we have a script that sets up all of this for you, but it is not ready for devs yet) [19:04] understood, I really just want to make sure I didn't break the JS test runner atm, so if only a single test can run I'll be happy [19:06] rick_h_, so, here's the pertinent code. http://pastebin.ubuntu.com/1059579/ [19:06] basically it is saying that in the fstab file for the lxc instance, [19:07] you need to add what is in line 7 [19:07] for bug 974584 [19:07] <_mup_> Bug #974584: Semaphores cannot be created in lxc container

< https://launchpad.net/bugs/974584 > [19:07] rick_h_, restart the lxc after you make that change [19:08] orly, ok thanks [19:08] If it doesn't work with xvfb-run and that workaround, I dunno, but you can feel free to ask me again :-) [19:09] I think it's working, at least I've got my first test failures so I think just hte xvfb-run got me started [19:10] ty much [19:10] welcome [19:15] cjwatson: whats your lp username? [19:54] sinzui: you're on a role! [19:55] czajkowski, no, my script is. I need to clean up bug data to tell stakeholders why a squad has work on disclosure for a year and still not delivered sharing or private projects [19:56] sinzui: but you are close and have done a good job it's not an easy task a lot of areas to make happy [19:57] czajkowski, I am not close. [19:58] There is a caustic streak of optimism at Canonical that misleads everyone into thinking we are always a few months away. [19:59]