[00:40] * thomi is back [00:46] thomi: Oook. [01:21] RAOF: No luck with libdrm_radeon/mesa? [01:22] Hmm, tho it hasn't tried to build since the 24th [01:33] duflu: Do you want to hit the rebuild button? Should work now. [01:35] RAOF: I hit /a? rebuild button. Not sure if it was the right one. Thanks [01:35] "a" [01:55] * duflu thinks it's awesome that he can click 3 build buttons and all 3 builds start immediately [01:56] kdub: Jenkins marked this done. Is it really? https://bugs.launchpad.net/mir/+bug/1130553 [01:56] Launchpad bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix committed] [02:11] does anyone remember the secret key you need to push to stop grub booting? [02:11] thomi: Madly mash shift. [02:12] * thomi is still trying to un-brick his laptop :( [02:12] thomi: Although we *should* be marking your boot as failed, and automatically bringing up the grub prompt. [02:12] Mashing escape works too [02:12] doesnt seem to be shift.... [02:12] and technically speaking, the boot works [02:12] time to try Escape [02:13] But you have to be fast with escape. Start mashing at the end of POST [02:13] thomi: I believe that we decided that “has logged in to a session, or does a controlled shutdown” are the two criteria for determining whether a boot is successful. [02:14] oh, well that's not workng [02:14] RAOF: seems you need to hold the shift key, not just press it 0.O [02:22] robert_ancell: what should I do to disable u-s-c in lightdm.conf? [02:22] thomi, uninstall u-s-c or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.config and quote out type=unity [02:23] thomi, also check you don't have an old setting in /etc/lightdm/lightdm.conf - if so just remove it [02:24] * thomi crosses fingers and reboots [02:25] * kgunn waits with anticipation [02:35] well, I got my laptop back [02:35] but xmir totally breaks it for me [02:35] laptop \o/ [02:35] also, I realise that the mir stress tests break the server again. every time we get closer to enabling them for CI, something else breaks :-/ [02:39] * duflu thought lightdm was meant to "fall back to xlocal" if things don't work [02:39] olli: i notice you say reboot your system vs restart lightdm....did you experience issues w lightdm restart ? [02:40] duflu, it did work, then it locked up and lightdm tried to get to failsafe X, but it was locked up by that point [02:41] robert_ancell: ^ restart lightdm vs reboot ? [02:41] kgunn, same difference [02:41] robert_ancell: i thot so...just noticed olli referenced it today on irc & in his blog [02:42] Hey, what's our idiom on server-side event-callbacks? [02:42] RAOF: Server side doesn't get callbacks ... ?? [02:43] duflu: I mean: an event occurs, and some server code needs to react to it. Do we not currently have any of that? [02:44] RAOF: It will be buried in the server classes (because they do have support for turning events into messages already). But I think what you mean by "server side callback" will be a virtual method to be overridden [02:44] * duflu is not helpful yet; goes to get coffee [02:46] argh, C++! I copy the demo shell input handling code into u-s-c and it gives me obscure error messages [02:48] ?? [02:49] Looks like other parts of our code use a set_foo_callback() idiom. [02:56] i just updated to the latest....and verified https://bugs.launchpad.net/mir/+bug/1194039 [02:56] Launchpad bug 1194039 in Mir "Cannot start any Mir server ... std::exception::what: Failed to set DRM crtc" [High,New] [02:57] mir_stress causes the mir_demo_server to crash: https://bugs.launchpad.net/mir/+bug/1195089 [02:57] Launchpad bug 1195089 in Mir "mir_stress suite causes mir_demo_server to crash" [Undecided,New] [03:38] Reboot. Wish me luck [04:06] RAOF: Ta. Mir is functional on raring again [04:06] via staging [05:13] hey robert_ancell! around? [05:14] good morning all :) [05:15] hey tvoss_ [05:18] didrocks, yep [05:19] robert_ancell: was my email I sent yesterday understandable? [05:20] didrocks, the big ol list of things to be done? [05:20] robert_ancell: yep, and particularly the pending questions :) [05:21] morning tvoss_ [05:21] morning didrocks [05:21] hey thomi! [05:21] thomi: moving house? [05:22] didrocks: yeah... have moved. Well, most things are still in boxes [05:22] I imagine :) [05:22] so you are working from a coffee shop or anything? [05:23] didrocks: no, working from home, I managed to un-pack my office. But I cannot find anything, so I end up buying new things, then find the box that I was looking for in the first place [05:23] like, I have no cups.... [05:23] I'm sure they'll turn up somewhere [05:24] didrocks, can you send me details on how you do integration tests with the unity stack [05:24] thomi: argh, but no cups was a priority :-) Anyway, you never have enough of them :) [05:24] yeah [05:24] robert_ancell: doing that now [05:25] robert_ancell: on lightdm and ABI, any idea? (meanwhile I'm writing you that) [05:25] ABI for? [05:25] robert_ancell: see, RAOF told that the client ABI is stable, so platform-api and xmir will use that stable ABI, right? [05:25] we don't need to worry too much about ABI stability, right? [05:25] didrocks, yes [05:26] so we can put everything in the same stack finally, I guess [05:26] didrocks, though we want the integration tests to pick up if we stuff that up :) [05:26] robert_ancell: sure ;) [05:26] platform-api will dep on mir at some near point in the future, right? [05:27] didrocks, as I understand it, it will depend on libmirclient [05:27] racarr, correct? [05:27] yeah, so, the stacks will be dependant as a whole :) [05:27] though he's probably asleep :) [05:27] robert_ancell: for lightdm/unity-greeter, in that case, do you want them in the mir stack or in another stack? [05:27] I guess so :) [05:28] RAOF, good morning :) [05:28] didrocks, I don't have a strong preference on the stacks. From my perspective you could lump them all into one stack and I'd be happy with that. As long as we don't slow down important bug fixes for one component [05:28] tvoss_: Good morning. [05:28] I have to go, but I'll be back in 2.5-3 hours [05:28] robert_ancell: it doesn't slow down anything as long as any of them FTBFS or fail tests :) [05:29] robert_ancell: ok, I'll send you about the integration tests then [05:29] ta [06:13] robert_ancell, duflu what are the remaining open vt bugs? [06:14] tvoss: Might be inaccurate, but https://bugs.launchpad.net/mir/+bugs?field.tag=vt [06:15] I think the medium one is actually the most annoying right now [06:17] duflu, hmmm, I think that's the one making it difficult to fallback easily [06:18] tvoss: Well not having a terminal to log in to is a risk too [06:18] duflu, that's what I mean [06:19] Right. So "expert fallback" = terminal. As opposed to fallback mode, which is X (when it works?) [06:19] duflu, right [06:19] duflu, that's what I mean [06:28] alf: Good morning. Bad news... https://bugs.launchpad.net/bugs/1195105 [06:28] Launchpad bug 1195105 in Mir "[regression] mir_demo_standalone_render_surfaces no longer works (blank green screen)" [Medium,New] [06:29] duflu: Yeah, I saw that late yesterday, but thankfully it's a simple fix [06:29] alf: Cool. You saw it before the bug was logged? [06:34] duflu: assigned it to myself [06:35] duflu: (disconnected, may have lost some messages) [06:35] alf: No nothing missed. Thanks. What's the cause? [06:37] duflu: Surface::flag_for_render() internals changed, so now one call to it is not enough to mark the surface as valid for rendering. [06:38] duflu: if you need a temporary workaround just call it twice in render_surfaces [06:39] Oh. Server internals... [06:59] RAOF, https://github.com/whot/libevdev [07:00] Yah. [07:00] Also in my G+ stream :) [07:00] * RAOF still needs to check about the libsynaptics situation. [07:00] I don't think we're _particularly_ interested in libevdev, right? The Android stack already handles that. [07:00] But we *are* interested in having touchpad support ☺ [07:05] Man, I wish C++ had a builtin string class. [07:06] Strike that; I wish it had a builtin string *type*. [07:06] RAOF: You're asking for the C++ spec to grow further? :) [07:07] Actually I'm basically asking for typeof("foo") == std::string. [07:07] :) [07:11] RAOF: You can go: char foo[] = "foo"; int len = sizeof(foo) - 1; :) [07:12] What more can you want from a string? ;) [07:12] utf-8 [07:12] mlankhorst: Yeah fair point [07:13] Though unicode is easier to deal with most of the time... wchat_t foo[] = L"foo"; [07:14] *wchar_t [07:14] wcat_t whiskers[]! [07:15] int longcat = (sizeof(whiskers) / sizeof(whiskers[0])) - 1 [07:17] Peppa pig! [07:18] robert_ancell: once you are back: https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup/+merge/171722 [07:22] Ah, wchar_t can still be multibyte. But C++11 also has char32_t to rule them all [07:23] (except longcat who cannot be ruled) [07:35] robert_ancell, hey there :) searching for the command line that invokes usc from lightdm [07:35] src/seat-unity.c is what you want to be looking in. [07:39] RAOF, that's lightdm, right? [07:39] Right. [07:40] RAOF, hey [07:40] seb128: Ho! [07:40] RAOF, how are you? [07:41] I'm well. Hows about you? [07:41] I'm good thanks [07:41] RAOF, quick question for your ... did you guy test the new xorg which is getting ready for upload in saucy? does it has an possible impact on XMir or on work you are doing? [07:41] it seems like that stack is mostly ready for landing in saucy [07:42] but I want to make sure it's not going to create issues for you guys first [07:43] It shouldn't, although I should check whether the input ABI changed. [07:44] RAOF, can you check tomorrow and give us a ack/nack? [07:44] RAOF: just some repacking [07:44] mlankhorst: Urgh, again? [07:44] yeah someone loves their bitfields [07:45] Ok. So I'll need to throw xf86-input-* into the Mir PPA until that's moved to 1.14. [07:45] but a rebuild is enough for that [07:45] Right [07:46] Or, I guess, move xserver in the Mir PPA to 1.14; that should be fast. [07:46] indeed :p [07:46] and then just bump the video drivers to rebuild them [07:47] Exactly. [07:47] mlankhorst: I guess xf86-input-* built against 1.14 are in a PPA somewhere, right? [07:48] * duflu wonders how the Apple Magic Trackpad would go with Mir [07:49] RAOF: canonical-x/x-staging is whats going to land [07:50] duflu: Reasonably, but no tap-to-click etc. [07:50] mlankhorst: Ta. [07:50] RAOF: I mean Mir android input, not X [07:50] duflu: So did I. [07:51] Oh [07:51] I recall trying it on a Honeycomb tablet a while ago. Kind of worked... [07:51] seb128: I'll move our PPA on to 1.14 tomorrow and give you the goahead. [07:51] RAOF, thanks [08:13] RAOF, I put a work item for the 1.14 update in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-system-compositor [08:17] robert_ancell, hey, looking at src/seat-unity.c. I would like to add options to enable reporting of the different mir components [08:17] robert_ancell, question is: how do I access the settings as read from the per-seat config file? [08:18] tvoss, not 100% sure what you mean, but you just need to call seat_get_*_property to get a property of a seat as set in the config [08:20] robert_ancell, ah cool, so the usc executable has command line options to enable logging of internal operations, either to a log file or to lttng [08:20] robert_ancell, for debugging purposes, it would be great if we could enable that functionality via the unity-seat config file, passing over the cl options to usc [08:20] tvoss, I added "unity-compositor-command" which you can set to "unity-system-compositor --do-blah-blah-blah" to do stuff like that temporarily [08:21] robert_ancell, ah cool, even better then :) [08:21] tvoss, Ideally we should just set u-s-c to log stuff to stderr by default so we have baseline debugging [08:22] robert_ancell, and stderr ends up in the usc.log, right? [08:22] tvoss, ack [08:28] robert_ancell, so something like unity-compositor-command="unity-system-compositor --glog --glog-stderrthreshold=0 --display_report_opt=log" [08:28] in 10-unity-... .conf should work ... [08:31] tvoss, yes [08:31] robert_ancell, cool, trying now :) [08:42] robert_ancell: so, I guess before daily releasing mir and unity-greeter to a PPA (so not blocking on integration tests nor the duplicated libraries in Mir), I just need your lightdm review, did I miss anything? [08:43] robert_ancell: then, we can continue discussing with jibel if needed to clear up how to do the integration tests [08:44] alf, I think the link is too flaky :( [08:45] didrocks, otp, I'll get back to you.. which is the review? I thought I just did them all [08:46] robert_ancell: https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup/+merge/171722 [08:46] robert_ancell: fresh new one! :) [08:51] RAOF, ping [08:53] tvoss: pongity pong. [09:02] robert_ancell, adding the command line makes the server not start, executable not found [09:03] tvoss, can you paste me your config? [09:04] tvoss, there is a nice regression test that tests this case, so it *should* work... [09:04] didrocks, approved [09:05] robert_ancell: thanks! I'm prepping the daily release machinery through the next ppa then! [09:05] didrocks, I take it the man page change was intentional? [09:05] You probably know groff better than me :) [09:05] robert_ancell: yeah, it was an empty stenza (I saw it through lintian TBH :p) [09:05] robert_ancell, unity-compositor-command="unity-system-compositor --glog --glog-stderrthreshold=0 --display_report_opt=log" [09:06] hah! Your secret is out! [09:06] I tried without ", too [09:06] it is :) [09:06] tvoss, no quotes [09:06] robert_ancell, tried that, without luck :/ [09:06] tvoss, can I see the lightdm.log? [09:07] robert_ancell: tell jibel and I when you want to discuss integration testing, we can do that at a time not too late for you :) [09:07] didrocks, will do [09:07] robert_ancell, don't have it handy, but it said that it tries to invoke the command line and then command not found [09:08] didrocks, I still can't see where the tests are for unity - can you point me at what files actually do the tests? [09:09] robert_ancell: lp:unity tests/autopilot/unity/* [09:09] didrocks, ta [09:09] yw :) [09:10] tvoss, hmf. I'll try here [09:11] that was fast === Debolaz is now known as Guest24640 [09:18] tvoss, works for me - config http://paste.ubuntu.com/5804162/, lightdm log http://paste.ubuntu.com/5804163/ [09:20] robert_ancell, cool, sorry for the noise then :) mind pasting the usc.log, too? [09:20] tvoss, there's nothing new in it, but I didn't set --display_report_opt=log - does it need that? [09:21] robert_ancell, yup, that allows us to log anything going on with vt's inside the gbm module [09:21] iirc [09:21] tvoss, brb [09:31] robert_ancell, win? [09:32] tvoss, you gave me an invalid command line :) [09:32] unity-compositor-command=unity-system-compositor --glog --glog-stderrthreshold=0 --display-report=log [09:32] works [09:32] ups :) [09:32] log output - http://paste.ubuntu.com/5804187/ [09:32] then my VTs went crazy so I was sshing from my phone - real pain to try and type on those keyboards :) [09:32] yeah [09:33] tvoss, that what you expected to see? [09:35] looks good, trying to tune the output to get information back to us in case of issues [09:40] robert_ancell, [09:40] robert_ancell, ^ [09:41] yep, we should have this stuff on by default [09:43] robert_ancell, do you think we should enable it in the ppa by default? [09:44] tvoss, yes, change the defaults in u-s-c to log things that wont affect performance by default [09:44] robert_ancell, yup, I think we want display reporting enabled, including info. We can lower that over time [09:46] yep [09:47] tvoss, bug 1195227 [09:47] bug 1195227 in Unity System Compositor "Turn on logging by default" [Medium,Triaged] https://launchpad.net/bugs/1195227 [09:48] robert_ancell, thx [09:59] ah, mir trunk FTBFS on the ppa [09:59] https://launchpadlibrarian.net/143539491/buildlog_ubuntu-saucy-i386.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz [10:00] hum, hard to read with -j8 [10:01] (can be the parallel build making it failing as well) [10:01] didrocks, yup [10:01] tvoss: did you see anything else than parallel build which can be the cause here? I don't see any hint in the trace :/ [10:02] didrocks, the error seems to be "cp: cannot create regular file '/build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/obj-i686-linux-gnu/doc/html/cppguide/styleguide.css': No such file or directory" [10:02] seb128: waow, you have good eyes, couldn't see that one :p [10:02] seb128, o/ [10:02] ;-) [10:02] tvoss, hey ;-) [10:03] /usr/bin/cmake -E cmake_progress_report /build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/obj-i686-linux-gnu/CMakeFiles [10:03] Generating ../doc/html/cppguide/styleguide.css [10:03] cp /build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/guides/styleguide.css [10:03] [10:03] seems to have a path mismatch there [10:04] indeed [10:04] * seb128 let you guys debug the build system ;-) [10:08] passing on other archs, I think it's a --parallel mismatch, I'll disable it for now unless some cmake gurus wants to ensure that it works, tvoss, do you know if Satoris would be interested? [10:10] didrocks, might be :) [10:12] tvoss, mpt do we have anything to discuss today? [10:13] tvoss, everything on my list was covered yesterday [10:17] tvoss: seb128: it passed with this rebuild FYI [10:17] didrocks, ok, so some sort of race in the build system [10:17] yep, let's see once Satoris is around [10:41] katie, likewise :) [10:48] * duflu -> dinner [10:50] katie, ping [11:01] hah! [11:02] tvoss, pong [11:12] tvoss: ah, more annoying tests failed on powerpc: https://launchpadlibrarian.net/143542002/buildlog_ubuntu-saucy-powerpc.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz [11:12] tvoss: do you mind having a look? [11:16] didrocks, C++ exception with description "GLPixelBuffer doesn't support big endian architectures" thrown in the test body. [11:16] tvoss: so this test should be disable on powerpc I guess [11:17] or we can declare no Mir on powerpc, but that will make the inclusion by default difficult… [11:18] didrocks, can you file a bug please? [11:19] tvoss: sure [11:21] tvoss: https://bugs.launchpad.net/mir/+bug/1195260 [11:21] Launchpad bug 1195260 in Mir "Mir tests failed on powerpc" [Undecided,New] [11:30] tvoss: other tests failure on armhf: https://launchpadlibrarian.net/143544949/buildlog_ubuntu-saucy-armhf.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz [11:30] * didrocks opens a bug [11:31] it seems no valgrind? [11:32] didrocks, why is this passing in the ppa? [11:32] tvoss: passing? [11:33] didrocks, building [11:33] tvoss: daily release? [11:33] as it's our goal [11:34] and as we don't have integration tests for everything yet, we are using the next ppa first [11:34] (and rightly as we need to settle down those issues first) [11:34] tvoss: https://bugs.launchpad.net/mir/+bug/1195265 FYI [11:34] Launchpad bug 1195265 in Mir "no valgrind makes tests failing on armhf" [Undecided,New] [11:43] didrocks, quick check: isn't valgrind in the build-deps? [11:44] tvoss: no, I just added it and dput to the ppa [11:44] didrocks, thx [11:44] for a test build [11:44] tvoss: I wonder what is pulling it for the other archs TBH [11:44] but anyway, it's needed to be in the build-dep :p [11:44] will see this build result === Guest24640 is now known as Debolaz [12:35] * 6JTAAX1W6 is incognite === 6JTAAX1W6 is now known as tvoss [12:35] not anymore :) [13:16] hello all [13:47] tvoss: do you have a minute? I think we need to check with the launchpad guys. It seems to me that the armhf build is blocked: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4751091 [13:47] (it's like that for 15 minutes) [13:48] seems it's taking 0.04 sec on amd64 to pass :p === francisco is now known as Guest25330 [14:05] alf, ping [14:05] tvoss: pong [14:06] alf, pm [15:04] good morning [15:08] ssh: Could not resolve hostname bazaar.launchpad.net: No such file or directory [15:08] i am getting this error :s [15:08] does anyone has problems to push? [15:12] fixed [15:15] reviews piling up! [17:25] Howdy [17:30] racarr, hey there :) [17:30] how goes? [17:30] kdub, you should have edit rights btw [17:31] ah, thanks [17:37] tvoss_: Root canalled about 20 minutes ago [17:37] so it goes pretty...ow [17:37] im assuming as some point thoughts will resume [17:38] man, root canal is ouch [17:40] tvoss_: S'ok. I'll distract myself XD [17:40] How goes on your end? [17:48] racarr, pretty good, got some stuff to finish for end of month [17:48] racarr, but all good [17:51] racarr, preparing some vegetarian chili :) [17:51] I should try making that... [18:01] racarr: owww, root canal, nasty [18:06] it really is pretty nasty business. I considered just waiting it out until little nano robots could clean my teeth with lasers [18:06] :p [18:07] greyback: How goes? [18:07] racarr: fine. No real time for Mir stuff today. But tomorrow will [18:07] be on it fully [18:08] racarr: any update for me? [18:08] greyback: Not really. will finish the session stuff today [18:08] land my other branches [18:08] err, session authorier stuff [18:08] I realized today [18:08] racarr: ok cool. Yep I'd like to see that [18:09] missed the sync up with Katie. [18:09] but you should start talking to Katie [18:09] she did the surface management design [18:09] and there is lots there, including functional tests (some of which are in mir now) [18:09] racarr: yep, I've been reading her documents recently [18:09] which hypothetically one day should run on [18:09] unity/mir and that would be [18:09] awesome [18:09] +1 [18:09] where are the functional tests? [18:09] letsseee [18:10] on a page that crashes firefox [18:10] *waits* [18:11] greyback: https://docs.google.com/a/canonical.com/document/d/1GtXBxUo1M2ya5-6Um-pJ2bhLM-tXYMXDaZvEgr6edMg/edit [18:11] I guess they might be out of date to some of the recent [18:11] design refactoring [18:11] XD [18:13] racarr: then we'd best get them updated. These look very useful, and I'll automate them asap [18:13] there is [18:14] some cucumber code hanging around in mir...weeeeeeeeeeeeeeeeeeeeee [18:14] yeah [18:14] we should both talk to katie next week [18:14] and then figure out how to get some of them running on unity/mir combined [18:15] racarr: cucumber? When did ppl start using that? [18:16] +1 [18:16] greyback: Me and Katie did! in december [18:16] :p [18:16] Katie and I *italics* [18:16] uh [18:16] stop taking all the credit :) [18:17] I'm not a big fan of the abstraction of cucumber in general, but for specific use-cases it will do I guess [18:17] it does make it easier for non-coders to write tests for us [18:17] I have [18:17] mixed opinions [18:18] Cucumber definitely isn't ideal [18:18] lots of sort of things are difficult to express [18:18] I havent thought about cucumber in probably 2 months so it's a little difficult to recall exactly which ones :p [18:19] :) [18:19] no worries, I was just curious [18:19] racarr: It's well past my EOD, gotta go [18:19] hope you have plenty of pain-killers and have a nice easy day :) [18:20] cya [20:01] morning all [20:04] Morning [20:16] racarr, regarding #1194075 (the, uh, embedded cucumber problem), would be be possible to just rewrite the session_manager_steps.cpp tests to use GTest directly instead, so we could simply drop the cucumber? [20:20] while running xmir, is anyone noticing ~20-30 seconds where everything hangs? Usually brought on by compiling...but sometimes not [20:32] bregma: There are grand plans for cucumber I guess, the single tet could be rewritten but there is not much point [20:32] if it is actually blocking anyone I think just remove it from the tree [20:33] racarr, it's blocking landing in Ubuntu [20:34] Really? [20:34] Why can't we land in ubuntu with cucumber-cpp embedded [20:34] as long as we are following the licensing [20:42] kdub: Ok I see it is failing, will look around for a bit [20:42] thanks [20:43] kdub: Why all this file synchronization stuff [20:43] isn't it satisfied by [20:43] InputTestingServerConfiguration::wait_until_client_appearas [20:43] ? [20:44] well, that will look on the server side for the client creation [20:44] but we need to wait until after the client has registered its handler [20:44] no [20:44] you can register the handler in the connected callback [20:45] and the client input thread wont be started until after this finishes [20:45] the server will send the first event over the pipe, and wait for this to happen before sending any more [20:45] the thing is the way the handler is being registered now [20:45] the thread can be started and read an event [20:45] before the handler is registered, so it just discards it [20:45] the problem in this test though is on the server side ( [20:45]