=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:50] marche pas [07:50] oops [08:03] jibel, didn't get to internal yet :)? [08:03] brendand_, no, do you? [08:06] jibel, you need to change the password as notified by email [08:06] brendand_, I know [08:06] brendand_, but it doesn't work [08:07] jibel, did you copy everything or only after the colon? [08:07] brendand_, I tried both [08:07] brendand_, I can still connect with the old creds, something is obviously wrong [08:07] jibel, mine looks like brendand:******** [08:08] jibel, you can connect with old password? [08:08] brendand_, yes [08:08] jibel, that's odd. but if it works it works. so until it doesn't work... [08:08] jibel, then at least you can ask IS what's going on [08:09] brendand_, no because IS channel is almost empty [08:09] brendand_, I contacted support [08:19] jibel, did you join #canonical-sysadmin here? [08:20] brendand_, no, I didn't know this channel [08:20] jibel, Spads is there [08:20] jibel, he's the Vanguard [08:21] brendand_, thanks, I'll ping him [08:26] brendand_, I am not alone one this channel :) [08:27] jibel, i would say not [08:54] jibel: I just connected to internal IRC with the new password. You cannot? === bladernr_ is now known as bladernr-malta [10:58] I don't know if I'm here at the right place, but how do I suggest edits to immutable wiki pages? [10:59] mrquincle, how have you logged in? [11:04] I'm trying :) It's waiting for wiki.ubuntu.com [11:04] I'd like only to "suggest", not to actually edit something [11:04] Is that possible? [11:05] there isn't really a process for suggesting [11:05] i would encourage you to simply update the page [11:08] It's just about https://wiki.ubuntu.com/Kernel/MainlineBuilds. From what I see you build the http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ branch from git://kernel.ubuntu.com/virgin/linux-stable.git crack-tip--drm-intel-next--2015-04-24 and not from Keith's http://cgit.freedesktop.org/~keithp/linux/log/?h=drm-intel-next which has last been updated in 2012 [11:11] It's a immutable page anyway, so can't change it, even if I'd like to :) [11:11] can you edit other pages? [11:11] i'm pretty sure it's a login issue [11:11] how did you log in? [11:12] Ah, it was. I'm so sorry! [11:12] no problem [11:12] we've been having these problems lately, so... === willcooke_ is now known as willcooke [12:53] can we make a law for the ubuntu-quality mailing list AGAINST the use of emoji? [12:54] Alberto constantly uses it and it shows up as hex, not useful images/items in Ubuntu (even Thunderbird, 14.04)... and we've had that discussion about emoji before. [13:21] teward, we have had that discussion. It shouldn't be appearing anymore actually; everything should be forced plain text [13:22] balloons: it's sending Unicode. see ALberto's latest message [13:22] balloons: and we need to have the discussion again. [13:24] balloons: not sure if my last messages got through - internet blip. [13:24] but he's not abiding by that rule. [13:24] it's sending 0x###### characters through. [13:24] let me show you screenshots/proof [13:24] balloons: http://i.imgur.com/RJtAX1u.png <-- iPhone render. http://i.imgur.com/rFcHGKb.png <-- Thunderbird. [13:25] my last response reiterates that this discussion has been said before, and he needs to actually *stop*. [13:27] but it's coming up again [13:29] * balloons looks [13:29] * balloons checks settings [13:31] yea, the filters should be removing everything and converting to plain text. I guess emoji escapes that [13:40] I wonder if I can do more against them. [13:47] moderate the user doing it [13:52] at least the text conversion makes it way less obnoxious [13:58] balloons: ban Alberto from posting and moderate them? === chihchun is now known as chihchun_afk === ara is now known as Guest54483 [15:05] balloons: ping [15:05] elfy, if you're quick, pong :-) [15:06] good morning. [15:07] balloons: where do ubuntu's automatic image test get reported? is it still jenkins? [15:08] elfy, which one? the autopilot tests or smoke tests? [15:08] both I guess [15:09] both are in jenkins, but the autopilot test box was removed and CI was working on setting it back up. I'm not sure where it's at atm [15:09] I'd have to go find the link [15:09] ok - no rush - we can speak later sometime [15:45] ping vila: I now more or less understand the X11 Mouse on Touch error. [15:45] elopio_: \o/ tell me more [15:45] but I'm not closer to a solution. === elopio_ is now known as elopio [15:46] vila: here a Keyboard is instantiated in the base test case: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L165 [15:47] here, the keyboard is going to pick a backend, with a preferrence for X11: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L125 [15:47] as python3-xlib is installed, the imports in this module succeed: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py [15:48] so we hit this statement: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py#L283 [15:48] class Mouse(MouseBase): [15:49] MouseBase is an alias for http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L243 [15:49] class Mouse(CleanupRegistered): [15:50] CleanupRegistered does a little black magic to put a clean up in the test case when the class is defined, not when it is instantiated. [15:50] elopio: so, this confirms installing python3-xlib is the culprit [15:50] elopio: urgh, black magic... [15:50] in the Mouse case, it tries to move the mouse on cleanup. [15:50] so even if we don't instantiate Mouse, the cleanup gets registered. [15:51] indeed, urgh black magic ? [15:51] vila: yes, without python3-xlib the _X11 imports will fail, so we won't hit the class definintion statement. [15:52] http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/utilities.py#L330 [15:52] CleanupRegistered = _TestCleanupMeta('CleanupRegistered', (object,), {}) [16:06] elopio: trying to reformulate: the bug is that a useless package triggers an unexpected AP behavior because of ... internal reasons ? [16:08] vila: the bug is that having installed python3-xlib triggers an xlib cleanup which fails on touch. [16:09] the immediate cause I think is that we are instantiating a keyboard on the testcase, which makes no sense to be, but we need to confirm with veebers. [16:09] elopio: right, xlib shouldn't be installlled on touch. But what if it for other reasons ? As long as AP is not told to care about X11, it shouldn't. No ? [16:09] s/to be/to me [16:10] right [16:10] vila: if xlib is installed but we don't instantiate anything from that backend, we are ok. [16:11] then there's the underlying problem, that's autopilot doing extra stuff on class declarations instead of during __init__. [16:11] elopio: ok, so you're saying adding the keyboard is what trigger the x11 code (what happens if x11 is not there again ?) [16:11] if x11 is not there, the import will fail, and a evdev keyboard will be instantiated instead. [16:11] we will never hit the class declaration of Mouse. [16:12] right [16:12] elopio: my kbd is acting [16:12] can't type long sentences :-/ [16:14] elopio: is there a way to make these input devices declarations more explicit (instead of relying on installed packages) ? [16:15] vila: you can choose the backend, and make an explicit if, like we are doing almost everywhere: [16:15] http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L45 [16:16] this is one more case where autopilot was designed to be (IMO) unnecessarily smart [16:16] elopio: /me nods [16:18] vila: but what I'm wondering is about removing these mouse and keyboard properties: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L186 [16:19] we have been instantiating the keyboard and mouse on the custom proxy objects for UI widgets that need them. In the apps tests we are never using these properties, so I would deprecate them. [16:19] the problem is that we instantiate many keyboards and mouses, but it's not too bad as the backend is a singleton. [16:19] elopio: hmpf. I can't say with my limited knowledge... But somehow, if that's where those are created implicitly... That seems to match what we've been talking about [16:35] ubuntu-qa: mako CI jobs for webbrowser-app are consistently failing for the past 2-3 days with a build timeout [16:36] see e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2132/console [16:36] is that a known issue? === essembe is now known as sbeattie [16:40] oSoMoN: I don't think it's known. [16:40] It shows the results of only one autopilot test, which is weird. It seems to have finished that one test, but we need more logging on the test to confirm that. [16:41] but then autopilot is not reporting the OK for that test. Maybe we lost connection with the phone? I'll ping CI to see if they have ideas. [16:42] elopio, thanks [17:01] oSoMoN: I can reproduce it in my vivid desktop. When we kill the webapp container process, it gets stuck. [17:01] did you change anything related to that? [17:02] elopio, the only thing that comes to mind would be the recent oxide update, although it shouldn’t affect desktop as it hit only the overlay PPA [17:03] there is a bug in autopilot, because the timeout is not in the right place. I'll report that. [17:03] I still don't know what's causing this issue. nuclearbob, want to start your vanguard shift with an issue funny to debug? [17:12] oSoMoN: after killing it with SIGKILL and SIGTERM, it is: [17:12] elopio 6850 0.1 0.0 0 0 ? Zs 10:59 0:00 [webapp-containe] [17:12] that doesn’t look good [17:15] oSoMoN: http://paste.ubuntu.com/10913801/ anything in there makes sense to you? [17:17] elopio, I reformatted the relevant bit: http://paste.ubuntu.com/10913814/, this is definitely not right [17:18] alex-abreu, see http://paste.ubuntu.com/10913814/ , this is happening in CI when running the webapp_container testsuite on mako [17:19] oSoMoN: where does that log come from? I want to tail it to see if it's when it receives the kill -15 [17:20] elopio, that’s the log from the webapp container [17:21] oSoMoN, mmmh not sure how it can be related to the tests themselves ... did the renderer crash or something? [17:21] oSoMoN, do you have more log? ... [17:21] I have no idea where to see that in my desktop. [17:32] alex-abreu: oSoMoN: fwiw, I have the phablet-team ppa which gives me [17:32] liboxideqt-qmlplugin: [17:32] Instalita: 1.7.3-0ubuntu0.15.04.1~ppa1 [17:33] elopio, oSoMoN you dont see that w/ the webbrowser app tests? [17:33] alex-abreu: no, only webapp_container tests. [17:48] also, bug reported for autopilot timeout: [17:48] https://bugs.launchpad.net/autopilot/+bug/1449153 [17:48] Ubuntu bug 1449153 in Autopilot "Autopilot can hang while killing a process" [Undecided,New] === oSoMoN__ is now known as oSoMoN [20:32] hey Letozaf_ [20:32] balloons, hi :D [20:32] Thanks for having a look at calendar :-) [20:32] balloons, yw [20:37] Letozaf_, so it sounds like you have a plan to fix the issue via the calendar devs adding a qml property? [22:54] oSoMoN, btw I am able to repro the issue ... (AP tests blocking) [22:54] on the desktop [22:56] alex-abreu, which version of oxide ? [22:58] oSoMoN, 1.7.3 , I'll backtrack to 1.6. see if if it is oxide related [22:58] I am not sure yet [22:58] might be AP or something [22:58] alex-abreu, thx [22:59] oSoMoN, there are no specific reasons why it works w/ webbrowser and not the container tests [22:59] from the oxide perspective