[03:51] <pitti> Good morning
[04:04] <pitti> thomi: hey Thomi, how are you?
[04:05] <thomi> hey pitti
[04:05] <thomi> pitti: spent all day bashing my head against this: https://bugs.launchpad.net/mir/+bug/1233944
[04:05] <thomi> about to hand it over to the european contingent...
[04:06] <pitti> thomi: ah, I'll have a look today
[04:06] <pitti> thomi: but /dev/input/eventX != uinput
[04:07] <pitti> the latter has its own udev rule for permissions
[04:07] <thomi> pitti: sure, the bug title may be a bit misleading
[04:07] <pitti> thomi: I wanted to ask you for a quick opinion about DanChapman's GTK emulator branch
[04:07] <pitti> thomi: (already pinged yesterday)
[04:07] <thomi> ahh, I saw that go by, I'm a bit conflicted about it TBH
[04:08] <pitti> thomi: my gut feeling is that we should put them into lp:autopilot into some autopilot.emulators.gtk submodule, instead of replicating an entire second python build system and packaging in libautopilot-gtk (that would need another binary package either way, though)
[04:09] <thomi> pitti: my concern isn't where to put them. I worry that we're basically creating two separate APIs, which will be confusing
[04:09] <pitti> thomi: how do you mean?
[04:10] <thomi> I think I'd rather see us improve the existing autopilot API for *all* UI toolkit backends, rather than improve it for Gtk only
[04:10] <thomi> "enter_text" method for text entry widgets... well, why not extend the keyboard instead (we actually already did that, but the example proves my point I think)
[04:11] <pitti> thomi: ah, I didn't even get that far with code review yet
[04:12] <pitti> so, replicating the generic click() methods and the like certainly sounds redundant
[04:12] <pitti> i. e. I don't really understand why we need so many wrappers
[04:13] <thomi> so I think a good thing would be to see what ideas are applicable to all of gtk/qt/unity, and apply those in autopilot 1.4
[04:13] <pitti> I do see why it's useful to have emulators for GtkFileDialog and some standard bits
[04:13] <thomi> pitti: agreed
[04:13] <thomi> indeed
[04:13] <pitti> where it's nontrivial to pick out particular buttons etc.
[04:13] <thomi> and obviously those things are going to be specific to each ui toolkit
[04:14] <pitti> GtkTreeView._item(self, labelText) also seems highly useful
[05:00] <jibel> Good morning
[05:01] <pitti> bonjour jibel, ça va ?
[05:02] <jibel> bonjour pitti, ça va et toi? More manual phone testing for me today :/
[05:03] <pitti> jibel: un peu fatigue, mais j'attends avec impatience le long week-end à Lyon
[05:03] <pitti> (pour le mariage de Didier)
[05:05] <jibel> pitti, ah great! I didn't know you were going. Have you been there already?
[05:08] <pitti> jibel: no, that will be my first tiem
[05:08] <pitti> time
[05:08] <pitti> jibel: last time I stayed at Didier's he still lived in Paris
[05:52] <DanChapman> good morning all
[05:55] <pitti> hey DanChapman, good morning
[05:56] <DanChapman> good morning pitti, thanks for finishing the review I'm just reading through it now :-)
[05:56] <pitti> DanChapman: not quite finished yet
[05:57] <pitti> DanChapman: I had a quick chat with thomi this morning about the structure, I gave a summary in the MP
[05:57] <pitti> once this gets simplified, I think we can put the remaining emulators into ap itself, and generalize the enter_text() bits etc.
[06:58] <DanChapman> pitti, ok cool thanks. I will start trimming it back. Ive left a comment on the MP if you could take a look for me.
[07:05] <pitti> DanChapman: so you are saying the two lines of code that you have for getting the second GtkTreeView would work with your branch, but not with current AP?
[07:05] <pitti> DanChapman: it certainly should work with AP, if not that sounds like a general bug
[07:06] <pitti> DanChapman: I mean, the solution certainly cannot be to duplicate the entire Gtk/Qt API with stub classes for emulators? there must be something better
[07:10] <DanChapman> pitti yeah it will only work if there is a stub class.
[07:11] <pitti> DanChapman: how does it fail without? The class names should be exported by ap-gtk?
[07:15] <DanChapman> pitti, let me get output for with and without so you can see :-) It says something like Class Gtk*  has not attribute * without the stub.
[07:26] <DanChapman> pitti http://paste.ubuntu.com/6182845/
[07:28] <pitti> DanChapman: I'm afraid that's a question for Thomi, i. e. how to make it possible to create an emulator for one particular class only
[07:29] <pitti> DanChapman: so you mostly created those stub classes so that everythign gets an emulator, to work around that bug?
[07:29] <pitti> at least now I understand the motivation :)
[07:30] <pitti> DanChapman: can you please explain this in the MP, so that it doesn't get lost on IRC for thomi?
[07:48] <pitti> elopio: hey, how are you?
[08:55] <DanChapman> pitti, sorry had to take my son to school. Yeah i had to create the stubs to workaround the issue, i didn't realise it was a bug at the time. I'll explain it all in the MP now
[09:05] <pitti> DanChapman: thanks; as I said, I'm not entirely sure how emulators work, whether they should indeed be this "I magically replace this class" thing or whether they need to be wrapped around the AP objects manually
[09:05] <knome> pitti, hey
[09:05] <pitti> hey knome
[09:06] <knome> pitti, i see you're mentioned in bug 1231978, is it possible it's a regression that's related with something you changed lately?
[09:07] <knome> apparently that's not thunar only, but other file managers as well
[09:07] <knome> it's a relatively nasty bug, so if you'd have any idea why that might be happening..
[09:07] <pitti> I saw the bug, yes; there was a new upstream microrelease around that time
[09:07]  * pitti looks at https://git.gnome.org/browse/gvfs/log/
[09:07] <knome> cheers
[09:11] <pitti> knome: replied
[09:12] <knome> ok, cheers, i'll get that test done ASAP
[09:22] <slickymaster> morning all
[09:23] <Noskcaj> hey slickymaster
[09:23] <DanChapman> hey slickymaster
[09:24] <Noskcaj> DanChapman, Any progress on testdrive? Or autopilot for ubiquity
[09:24] <slickymaster> Hey DanChapman, Noskcaj
[09:28] <knome> pitti, i don't seem to be one affected by that bug, so can't confirm if the older version fixes :/
[09:35] <om26er> could anyone confirm bug 1234051?
[09:35] <om26er> bug 1234051
[09:35] <om26er> oops
[09:35] <om26er> jibel, ^
[09:38] <jibel> om26er, sorry, my device is not in a suitable test to verify this bug at the moment. But I'll confirm later if nobody beat me to it
[09:38] <om26er> jibel, ack
[09:38] <jibel> s/test/state
[09:43] <DanChapman> Noskcaj: Hey the ubiquity tests are coming along now. Should have new ones finished later today/tomorrow and should work for any flavor (minus kubuntu) and any locale.
[09:45] <Noskcaj> DanChapman, Awesome, great work.
[09:46] <DanChapman> pitti, so change copyright to "Copyright (C) Canonical Ltd 2013"?
[09:47] <DanChapman> Noskcaj: thanks :-)
[09:55] <pitti> DanChapman: right (but that's more like a finishing touch, don't worry about these small bits too much :) )
[10:03] <davmor2> Morning all
[11:28] <elopio> pitti: hello.
[11:28] <elopio> I'm about to leave to the gym.
[11:29] <elopio> can I help you quickly, or can you wait 1.5 hours?
[11:32] <elopio> oh, sorry. I misread "are you here" instead of "how are you" :D
[11:32] <elopio> I'm great, a little asleep still :)
[11:38] <pitti> elopio: no hurry; enjoy the gym!
[13:24] <elopio> I'm back, but I need to leave again because I'm stupid when I get up this early. I should stop doing it :)
[13:25] <elopio> I forgot I had to take the motorcycle to the mechanic.
[14:30] <jfunk> elopio, ping
[14:30] <jfunk> cgoldberg, ping
[14:37] <cgoldberg> jfunk, pong
[14:57] <jfunk> cgoldberg, how Is testing click GOING?
[14:58] <jfunk> pardon the caps lock
[14:59] <cgoldberg> jfunk, good.  i evaluated what exists for unit tests... and I found some issues in the Autopilot tests (they don't work)
[14:59] <cgoldberg> jfunk, how should I deal with the broken AP tests.  try to implement/fix them myself... or just file a bug?
[15:00] <jfunk> cgoldberg, are they broken with Mir on, or were you testing with Surface Fliger SF?
[15:00] <cgoldberg> jfunk, broken period.  I don't see how they ever ran with the current code
[15:00] <cgoldberg> im referring to click-update-manager
[15:04] <jfunk> cgoldberg, hmm, do you know whether or not the tests are in the CI
[15:05] <jfunk> they must have been removed
[15:05] <cgoldberg> jfunk, i'm not sure.. if they are, they are failing
[15:05] <jfunk> right got that
[15:06] <jfunk> cgoldberg, so, at the moment, all eyes are on mir, click packages, system settings and multi media  (mir should be on for the other 3)
[15:06] <cgoldberg> jfunk, i should prob enter a defect against  click-update-manager.. so at least it's being tracked and we can refer to it
[15:07] <jfunk> cgoldberg, right, and you and elopio need to run the broken AP tests manually with mir on in the meantime :/
[15:07] <cgoldberg> i also MP'ed a branch to  click-update-manager cleaning up the test code a bit
[15:07] <cgoldberg> jfunk, ok.. will do
[15:08] <jfunk> cgoldberg, it is vital that we are detecting the defects for the click apps and related cases often coming toward this release
[15:08] <cgoldberg> ok
[15:09] <jfunk> I know elopio is off getting his bike fixed again :p - perhaps when he returns you can coordinate with him: testing on proposed images with mir on, hit the click apps story
[15:10] <cgoldberg> jfunk, sure thing.. i will coordinate with Leo
[15:10] <jfunk> cgoldberg, elopio - I have a meeting with Ubuntu Engineering leads tomorrow morning, if you could create a report similar to Jean-Baptiste's Mir report - http://goo.gl/JT0ALH
[15:11] <jfunk> including the automated tests that were broken which you ran manually instead
[15:11] <jfunk> (see the bottom)
[15:11] <cgoldberg> kk
[15:14] <smartboyhw> balloons, so, how did your brainstorming go?:P
[15:16] <pitti> doanac: I tried all that with sudo -i etc.
[15:16] <pitti> doanac: I added the DBUS export as it was complaining about not having a session bus
[15:17] <pitti> ah, maybe I screwed up the syntax (I didn't use the double quotes at first), trying again
[15:18] <doanac> pitti: you might look at phablet-test-run. it does those gymnastics :)
[15:19] <balloons> smartboyhw, heh, I'm in firefight mode
[15:19] <smartboyhw> balloons, LOL
[15:20] <pitti> doanac: ooh, got it now, nice!
[15:20] <pitti> doanac: the tests still fail and the dialer doesn't come up, but at least they start running
[15:21] <pitti> fun, I see like a miniature version of the dialer on the bottom edge of the screen
[15:37] <elopio> i'm back, now for real.
[15:39] <elopio> jfunk: not fixing again, fixing finally. Just today the parts arrived, so finally it's going to look like new.
[15:39] <elopio> in the mean time, I'm stuck traveling by bus. I hate life outside the internets.
[15:39] <elopio> cgoldberg: ping.
[15:39] <elopio> there's one thing with our idea of the mock server.
[15:39] <cgoldberg> elopio, hey
[15:40] <elopio> now all our client code is c++. So if we make the mock on python, it will be only called in an easy and direct way from the autopilot tests.
[15:40] <elopio> cgoldberg: but maybe that's not a problem. Maybe the unit tests should mock the server responses on a lower level.
[15:40] <elopio> maybe it's just that I don't like c++ and I'm trying to justify using python :)
[15:41] <cgoldberg> elopio, good idea :)   for a start we could use it for AP tests... but it should be technology agnostic right?  it's just an http server right?
[15:42] <cgoldberg> you just need to hit it with HTTP requests to setup a response, then call the API
[15:43] <elopio> cgoldberg: yes. Maybe if we need it from c++, we write the files for the response, and call a binary.
[15:44] <elopio> if we need it from python, we can set up the responses on the fly, or even write an object that encapsulates all the possible responses and prepares them.
[15:45] <cgoldberg> elopio, also.. read scrollback.. jfunk wants a report on the click testing.  and we need to manually run tests where autopilot is not working
[15:46] <jfunk> cgoldberg, elopio + mir on
[15:46] <elopio> jfunk, cgoldberg: yes, ack to all you said.
[15:47] <elopio> yesterday I ran all the tests again to check the documentation I made on moztrap. I'll do it today with mir enabled.
[15:47] <elopio> jfunk, cgoldberg: the document I sent to you with the notes to set up testing on trunk and the tests to run and the problems found is almost what jibel did on that other doc.
[15:47] <elopio> we just need to clean it a little.
[15:48] <cgoldberg> cool
[15:53] <om26er> nuclearbob, hey got the video ready ?
[15:54] <nuclearbob> om26er: it should be uploaded, I just need to share it
[15:54] <nuclearbob> working on that now
[15:55] <nuclearbob> I can't find it in the interface, unfortunately, but my machine says file sync has completed
[15:55] <nuclearbob> I'll do the manual upload
[15:56] <om26er> yeah could be a bug in UbuntuOne
[15:58] <nuclearbob> om26er: how about this: http://ubuntuone.com/0NOmNJbkg2noc3RAFrojQp
[15:58] <om26er> nuclearbob, yes, its downloading
[16:22] <elopio> jfunk: yesterday I focused on testing the U1 accounts plugin for system settings.
[16:22] <elopio> you are including that as part of "click" right?
[16:24] <jfunk> elopio, I may be mistaken but I believe it should be more focused on the install / upgrade / uninstall
[16:24] <elopio> jfunk: you can't update click packages without an account.
[16:24] <elopio> and I think it's also used for the search.
[16:25] <elopio> I think it's important to get it right, because if people start adding a u1 account on a wrong way, next cycle we will see lots of funny errors.
[16:25] <jfunk> elopio, ah, there's much I don't know about click I defer to your good judgement
[16:25]  * jfunk nods
[18:56] <thomi> morning all
[19:05] <cgoldberg> morning thomi
[19:10] <thomi> hey cgoldberg
[19:18] <cgoldberg> elopio, is there a standard or shared 'UbuntuTouchAppTestCase' that apps are using?  or does each app use it's own?  there's one here inside click-update-manager
[19:35]  * cgoldberg bbiab
[20:25] <balloons> afternoon letozaf
[20:25] <letozaf> balloons, hello
[20:25] <balloons> well buonasera actually
[20:25] <letozaf> balloons, buonasera :)
[20:26] <balloons> so I saw the rssreader got fixed -- did you see my note?
[20:26] <balloons> fixed=merged :-)
[20:26] <letozaf> balloons, yes
[20:26] <letozaf> balloons, great, I made the change you asked me
[20:26] <letozaf> balloons, I am now working on the remove topic part of rssreader app test
[20:26] <letozaf> balloons, nearly finished it
[20:26] <balloons> letozaf, I think you'll have to do another mp.. ahh, right, so you can fix it with that one ;-)
[20:26] <balloons> great thank you!
[20:27] <letozaf> balloons, yw
[20:28] <letozaf> balloons, I also changed the initial part where you check network activity
[20:28] <balloons> I saw, I take it that works a bit better now
[20:28] <letozaf> balloons, it looks like
[20:29] <letozaf> balloons, oh, but wait I changed it again now, you cannot see it until I propose for merge
[20:29] <letozaf> balloons, it's even better
[20:29] <letozaf> balloons, I think :p
[20:30] <elopio> cgoldberg: I've been writing one for ages now.
[20:30] <balloons> thomi, if you get a chance today, can you review the questions on this merge? https://code.launchpad.net/~dpniel/autopilot-gtk/autopilotgtkemulators/+merge/187673
[20:31] <thomi> balloons: sure, I'll add it to my list
[20:31] <balloons> ty :-
[20:31] <elopio> cgoldberg: https://code.launchpad.net/~elopio/qtcreator-plugin-ubuntu/uitk_base_class-2/+merge/188924
[20:31] <elopio> it just occures to me that I can simplify it on just two cases, so it needs a littme more work.
[20:31] <balloons> letozaf, :-) I'm sure it is. Glad rssreader is getting some love again
[20:31] <letozaf> balloons, :-)
[20:36] <cgoldberg> elopio, should we have a common 'ClickAppTestCase' inside ubuntuuitoolkit?
[20:38] <elopio> cgoldberg: I wanted that, but after some reviews it seems it would be too much magic to be launching the application on the base class.
[20:38] <elopio> so, we went jsut with ubuntuuitoolkit.base.UbuntuUIToolkitAppTestCase, that's pretty simple.
[20:39] <elopio> and we will duplicate what I have on my branch up there ^^ on every project.
[20:39] <elopio> it's not as bad as it seems. We will have just two cases, running on the desktop or running on the phone, so the code will be like half of what I currently wrote.
[20:40] <cgoldberg> ok
[20:43] <elopio> cgoldberg: you can see that this new style removes the MainWindow :)
[20:49] <balloons> ohh cgoldberg going to join in hacking on the emulator? We'd love it1
[20:49] <letozaf> balloons, I will push the test so you can see what I did if you want, but I will not propose merge as I have a timing issue just at the end of the test, I put a sleep now, just for debugging
[20:49] <balloons> you can propose a work, and mark it work in progress
[20:49] <balloons> *propose a merge
[20:49] <letozaf> balloons, good so I can finish it tomorrow
[20:51] <balloons> letozaf, right, and at the same time you can easily get a diff, et
[20:53] <letozaf> balloons, should I push this in the same branch as the previous work or create a new one ?
[20:53] <balloons> letozaf, your choice
[20:53] <balloons> i usually go for new I guess
[20:53] <letozaf> balloons, ok I will also go for new
[20:57] <letozaf> balloons, where is it that you mark it WIP ?
[20:57]  * letozaf is looking for WIP
[20:57] <balloons> when you propose uncheck the box "ready for review"
[20:57] <balloons> or, click the exclamation point at the top under ready for review and set it
[20:59] <letozaf> balloons, argh! I had already proposed for merge, the status now is  pending review
[20:59] <balloons> letozaf, yep, just change it at the top
[20:59] <balloons> no worries
[20:59] <letozaf> balloons, there is a need review choice should I select that ?
[21:00] <letozaf> balloons, wait no...
[21:00] <balloons> letozaf, yep, the first one, work in progress
[21:00] <letozaf> balloons, needs fixing sounds goog
[21:00] <letozaf> sorry good
[21:00] <balloons> it's right at top, under status
[21:01] <letozaf> balloons, LOL didn-t see it as it was written in black
[21:01] <letozaf> balloons, lol
[21:01] <letozaf> balloons, I was looking at it but could not see it :p
[21:02] <letozaf> balloons, ok so I'm going to bed now, buona notte :D
[21:02] <balloons> letozaf, ciao!
[21:13] <balloons> elopio, is this going to land? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix_tab_switch/+merge/188774
[21:14] <elopio> balloons: it's waiting for the prerequisite branch.
[21:14] <balloons> elopio, so everything is still broke eh? Well I got one MP in
[21:15] <elopio> balloons: the error that this fixes happens sometimes. So, it's more or less broken.
[21:15] <elopio> what's the URL of your MP?
[21:19] <balloons> elopio, I believe this one is most affected: https://code.launchpad.net/~nskaggs/sudoku-app/convert-ap-tests-to-sdk/+merge/187945
[21:19] <balloons> I realize I can modify it to click tab names instead, and that should work eh
[21:20] <cgoldberg> elopio, just a friendly reminder from julien... make sure you flash with the devel-propsed image for any click testing
[21:23] <elopio> balloons: yes, that's likely to be fixed with that branch.
[21:24] <elopio> I'm not sure clicking by tab names will fix it.
[21:24] <elopio> cgoldberg: ok.
[21:55] <elopio> thomi: once a click package is installed, if we do from the desktop phablet-test-run name_of_the_package, will it work just like it did when we had debs?
[21:57] <thomi> elopio: only if the AP test suite uses launch_click_package rather than launch_test_application
[22:34] <elopio> thomi: can you take a look? https://code.launchpad.net/~elopio/qtcreator-plugin-ubuntu/uitk_base_class-2/+merge/188924
[22:35] <thomi> sure
[22:57] <thomi> elopio: LGTM