[07:50] <jibel> marche pas
[07:50] <jibel> oops
[08:03] <brendand_> jibel, didn't get to internal yet :)?
[08:03] <jibel> brendand_, no, do you?
[08:06] <brendand_> jibel, you need to change the password as notified by email
[08:06] <jibel> brendand_, I know
[08:06] <jibel> brendand_, but it doesn't work
[08:07] <brendand_> jibel, did you copy everything or only after the colon?
[08:07] <jibel> brendand_, I tried both
[08:07] <jibel> brendand_, I can still connect with the old creds, something is obviously wrong
[08:07] <brendand_> jibel, mine looks like brendand:********
[08:08] <brendand_> jibel, you can connect with old password?
[08:08] <jibel> brendand_, yes
[08:08] <brendand_> jibel, that's odd. but if it works it works. so until it doesn't work...
[08:08] <brendand_> jibel, then at least you can ask IS what's going on
[08:09] <jibel> brendand_, no because IS channel is almost empty
[08:09] <jibel> brendand_, I contacted support
[08:19] <brendand_> jibel, did you join #canonical-sysadmin here?
[08:20] <jibel> brendand_, no, I didn't know this channel
[08:20] <brendand_> jibel, Spads is there
[08:20] <brendand_> jibel, he's the Vanguard
[08:21] <jibel> brendand_, thanks, I'll ping him
[08:26] <jibel> brendand_, I am not alone one this channel :)
[08:27] <brendand_> jibel, i would say not
[08:54] <rvr> jibel: I just connected to internal IRC with the new password. You cannot?
[10:58] <mrquincle> I don't know if I'm here at the right place, but how do I suggest edits to immutable wiki pages?
[10:59] <knome> mrquincle, how have you logged in?
[11:04] <mrquincle> I'm trying :) It's waiting for wiki.ubuntu.com
[11:04] <mrquincle> I'd like only to "suggest", not to actually edit something
[11:04] <mrquincle> Is that possible?
[11:05] <knome> there isn't really a process for suggesting
[11:05] <knome> i would encourage you to simply update the page
[11:08] <mrquincle> 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] <mrquincle> It's a immutable page anyway, so can't change it, even if I'd like to :)
[11:11] <knome> can you edit other pages?
[11:11] <knome> i'm pretty sure it's a login issue
[11:11] <knome> how did you log in?
[11:12] <mrquincle> Ah, it was. I'm so sorry!
[11:12] <knome> no problem
[11:12] <knome> we've been having these problems lately, so...
[12:53] <teward> can we make a law for the ubuntu-quality mailing list AGAINST the use of emoji?
[12:54] <teward> 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] <balloons> teward, we have had that discussion. It shouldn't be appearing anymore actually; everything should be forced plain text
[13:22] <teward> balloons: it's sending Unicode.  see ALberto's latest message
[13:22] <teward> balloons: and we need to have the discussion again.
[13:24] <teward> balloons: not sure if my last messages got through - internet blip.
[13:24] <teward> but he's not abiding by that rule.
[13:24] <teward> it's sending 0x###### characters through.
[13:24] <teward> let me show you screenshots/proof
[13:24] <teward> balloons: http://i.imgur.com/RJtAX1u.png <-- iPhone render.   http://i.imgur.com/rFcHGKb.png <-- Thunderbird.
[13:25] <teward> my last response reiterates that this discussion has been said before, and he needs to actually *stop*.
[13:27] <teward> but it's coming up again
[13:29]  * balloons looks
[13:29]  * balloons checks settings
[13:31] <balloons> yea, the filters should be removing everything and converting to plain text. I guess emoji escapes that
[13:40] <balloons> I wonder if I can do more against them.
[13:47] <elfy> moderate the user doing it
[13:52] <balloons> at least the text conversion makes it way less obnoxious
[13:58] <teward> balloons: ban Alberto from posting and moderate them?
[15:05] <elfy> balloons: ping
[15:05] <balloons> elfy, if you're quick, pong :-)
[15:06] <elopio_> good morning.
[15:07] <elfy> balloons: where do ubuntu's automatic image test get reported?  is it still jenkins?
[15:08] <balloons> elfy, which one? the autopilot tests or smoke tests?
[15:08] <elfy> both I guess
[15:09] <balloons> 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] <balloons> I'd have to go find the link
[15:09] <elfy> ok - no rush - we can speak later sometime
[15:45] <elopio_> ping vila: I now more or less understand the X11 Mouse on Touch error.
[15:45] <vila> elopio_: \o/ tell me more
[15:45] <elopio_> but I'm not closer to a solution.
[15:46] <elopio> 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] <elopio> 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] <elopio> 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] <elopio> so we hit this statement: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py#L283
[15:48] <elopio> class Mouse(MouseBase):
[15:49] <elopio> MouseBase is an alias for http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L243
[15:49] <elopio> class Mouse(CleanupRegistered):
[15:50] <elopio> 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] <vila> elopio: so, this confirms installing python3-xlib is the culprit
[15:50] <vila> elopio: urgh, black magic...
[15:50] <elopio> in the Mouse case, it tries to move the mouse on cleanup.
[15:50] <elopio> so even if we don't instantiate Mouse, the cleanup gets registered.
[15:51] <vila> indeed, urgh black magic ?
[15:51] <elopio> vila: yes, without python3-xlib the _X11 imports will fail, so we won't hit the class definintion statement.
[15:52] <elopio> http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/utilities.py#L330
[15:52] <elopio> CleanupRegistered = _TestCleanupMeta('CleanupRegistered', (object,), {})
[16:06] <vila> elopio: trying to reformulate: the bug is that a useless package triggers an unexpected AP behavior because of ... internal reasons ?
[16:08] <elopio> vila: the bug is that having installed python3-xlib triggers an xlib cleanup which fails on touch.
[16:09] <elopio> 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] <vila> 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] <elopio> s/to be/to me
[16:10] <vila> right
[16:10] <elopio> vila: if xlib is installed but we don't instantiate anything from that backend, we are ok.
[16:11] <elopio> then there's the underlying problem, that's autopilot doing extra stuff on class declarations instead of during __init__.
[16:11] <vila> 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] <elopio> if x11 is not there, the import will fail, and a evdev keyboard will be instantiated instead.
[16:11] <elopio> we will never hit the class declaration of Mouse.
[16:12] <vila> right
[16:12] <vila> elopio: my kbd is acting
[16:12] <vila> can't type long sentences :-/
[16:14] <vila> elopio: is there a way to make these input devices declarations more explicit (instead of relying on installed packages) ?
[16:15] <elopio> vila: you can choose the backend, and make an explicit if, like we are doing almost everywhere:
[16:15] <elopio> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L45
[16:16] <elopio> this is one more case where autopilot was designed to be (IMO) unnecessarily smart
[16:16] <vila> elopio: /me nods
[16:18] <elopio> 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] <elopio> 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] <elopio> the problem is that we instantiate many keyboards and mouses, but it's not too bad as the backend is a singleton.
[16:19] <vila> 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] <oSoMoN> ubuntu-qa: mako CI jobs for webbrowser-app are consistently failing for the past 2-3 days with a build timeout
[16:36] <oSoMoN> see e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2132/console
[16:36] <oSoMoN> is that a known issue?
[16:40] <elopio> oSoMoN: I don't think it's known.
[16:40] <elopio> 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] <elopio> 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] <oSoMoN> elopio, thanks
[17:01] <elopio> oSoMoN: I can reproduce it in my vivid desktop. When we kill the webapp container process, it gets stuck.
[17:01] <elopio> did you change anything related to that?
[17:02] <oSoMoN> 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] <elopio> there is a bug in autopilot, because the timeout is not in the right place. I'll report that.
[17:03] <elopio> 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] <elopio> oSoMoN: after killing it with SIGKILL and SIGTERM, it is:
[17:12] <elopio> elopio    6850  0.1  0.0      0     0 ?        Zs   10:59   0:00 [webapp-containe] <defunct>
[17:12] <oSoMoN> that doesn’t look good
[17:15] <elopio> oSoMoN: http://paste.ubuntu.com/10913801/ anything in there makes sense to you?
[17:17] <oSoMoN> elopio, I reformatted the relevant bit: http://paste.ubuntu.com/10913814/, this is definitely not right
[17:18] <oSoMoN> alex-abreu, see http://paste.ubuntu.com/10913814/ , this is happening in CI when running the webapp_container testsuite on mako
[17:19] <elopio> 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] <oSoMoN> elopio, that’s the log from the webapp container
[17:21] <alex-abreu> oSoMoN, mmmh not sure how it can be related to the tests themselves ... did the renderer crash or something?
[17:21] <alex-abreu> oSoMoN, do you have more log? ...
[17:21] <elopio> I have no idea where to see that in my desktop.
[17:32] <elopio> alex-abreu: oSoMoN: fwiw, I have the phablet-team ppa which gives me
[17:32] <elopio> liboxideqt-qmlplugin:
[17:32] <elopio>   Instalita: 1.7.3-0ubuntu0.15.04.1~ppa1
[17:33] <alex-abreu> elopio, oSoMoN you dont see that w/ the webbrowser app tests?
[17:33] <elopio> alex-abreu: no, only webapp_container tests.
[17:48] <elopio> also, bug reported for autopilot timeout:
[17:48] <elopio> https://bugs.launchpad.net/autopilot/+bug/1449153
[20:32] <balloons> hey Letozaf_
[20:32] <Letozaf_> balloons, hi :D
[20:32] <balloons> Thanks for having a look at calendar :-)
[20:32] <Letozaf_> balloons, yw
[20:37] <balloons> Letozaf_, so it sounds like you have a plan to fix the issue via the calendar devs adding a qml property?
[22:54] <alex-abreu> oSoMoN, btw I am able to repro the issue ... (AP tests blocking)
[22:54] <alex-abreu> on the desktop
[22:56] <oSoMoN> alex-abreu, which version of oxide ?
[22:58] <alex-abreu> oSoMoN, 1.7.3 , I'll backtrack to 1.6. see if if it is oxide related
[22:58] <alex-abreu> I am not sure yet
[22:58] <alex-abreu> might be AP or something
[22:58] <oSoMoN> alex-abreu, thx
[22:59] <alex-abreu> oSoMoN, there are no specific reasons why it works w/ webbrowser and not the container tests
[22:59] <alex-abreu> from the oxide perspective