[12:57] <brendand> pitti, hi - hope you had a nice holidays!
[13:00] <pitti> hey brendand, how are you? I did, thanks!
[13:00] <brendand> pitti, i'm good. i had a quick question about the step adt-run does to update the apparmor rules
[13:00] <brendand> pitti, do you know if it will be skipped if that was already done?
[13:03] <pitti> brendand: no, right now it doesn't check the current state, it just applies the update and reverts it at the end
[13:41] <balloons> dkessel, if you've not seen this: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/autopilot/README.md
[15:22] <gQuigs> looks like the wily build isn't being promoted again - sudo issue? - https://jenkins.qa.ubuntu.com/view/wily/view/Smoke%20Testing/job/wily-desktop-amd64-smoke-default/112/console
[15:23] <gQuigs> (promoted from pending -> current on cdimage)
[16:09] <dkessel> balloons: oh, nice! That will surely help once we have the system.
[16:09] <balloons> dkessel. you should be able to use that to give it a go now
[16:10] <balloons> gQuigs, interesting. Sudo hasn't changed: http://changelogs.ubuntu.com/changelogs/pool/main/s/sudo/sudo_1.8.12-1ubuntu2/changelog
[16:11] <dkessel> Right. Will try that when I have the time.
[16:11] <balloons> awesome
[17:44] <dkessel> balloons: running the tests is indeed working. we get a test failure though :p i am searching for the bug now...
[17:45] <balloons> dkessel :-) I know DanChapman knows of a few issues, but it would be good to have them as proper bugs
[17:45] <dkessel> balloons: the logs also look like it is downloading packages, which i think is strange: http://paste.ubuntu.com/11954772/
[17:46] <balloons> dkessel, the installer will grab newer packages if a network connection is present. I believe this is the case, even if you don't tell it to download updates
[17:46] <balloons> In that case it may only grab lang stuff
[17:46] <dkessel> so the test really is "iso image + any available updates"
[17:46] <dkessel> which makes it non-reproducible, but nice to test any possible fixes
[17:47] <balloons> dkessel, ohh, I was speaking about ubiquity only
[17:47] <balloons> if the test is grabbing packages then, yea, it could lead to more of a point in time test
[17:47] <balloons> and not as nice for reproducibility
[17:50] <dkessel> balloons: okay, i could be wrong. it could also be that the environment for the tests is being updated to all latest packages
[17:56] <dkessel> balloons, DanChapman: FYI, there is bug 1479064 now
[17:58] <balloons> looks good
[18:10]  * DanChapman closes qtcreator otherwise he will forget to reply *again*
[18:11] <DanChapman> balloons: dkessel o/ sorry, my time has been some what limited recently. Especially with dekko now chalked in for OTA-6
[18:11]  * DanChapman reads bug report
[18:16] <dkessel> if you need any more logs... they are there until the next reboot ;)
[18:16] <balloons> DanChapman :-) I know OTA-6 is going to be a big deal for dekko. So what we really need at the moment is a server. Did you get anywhere in thinking about how to host such a thing?
[18:17] <balloons> what I haven't done is confirm that indeed a cloud server won't work. But assuming it won't, it makes it a little tougher and more expensive to find a company
[18:17] <balloons> alternatively, someone could self-host I guess
[18:19] <dkessel> reading the README on the autopilot jenkins setup... are two seperate physical machines needed? i am reading "jenkins machine" and "slave"...
[18:22] <balloons> dkessel, good point. It's a bit odd as we need a phsyical machine to be the slave. And thus it cannot be the master either due to it's nature
[18:22] <balloons> normally you could use a single machine setup for this, but presumably these tests don't run under kvm, hence the need for a machine
[18:22] <dkessel> mhh couldn't jenkins be run as a vm ?
[18:22] <balloons> sure.. but on the same machine?
[18:23] <dkessel> i don't know how much ram/cpu jenkins really eats... why not?
[18:24]  * dkessel uses "homebrew" build servers at work, where jenkins would normally be a natural fit for all the java projects... ;)
[18:24] <balloons> well right. on a single machine you would install jenkins master, then create multiple slaves via kvm
[18:25] <balloons> dkessel, what if we started out by having you self-host this? We can get you some hardware for it
[18:26] <balloons> the trouble with the kvm approach is a kvm slave doesn't work in this case. So jenkins master imho can't run on a slave node
[18:27] <DanChapman> balloons, dkessel commented on bug
[18:27] <balloons> honestly the jenkins master could be on a raspberry pi or beagle bone, heh. The slave would be doing all the work
[18:27] <dkessel> yay, another pi for me :)
[18:28]  * balloons starts thinking about multiple machines for parallel builds.. ugh
[18:28] <DanChapman> balloons: are you wanting to run these tests on real hardware then? Previously they were just run using kvm
[18:28] <balloons> DanChapman, based on feedback from CI, they suggest real hw.
[18:29] <balloons> But I'm keen to know if it's needed or not
[18:29] <balloons> I assume there is a way to make it work without; even if we have to cheat a little in testing
[18:30] <DanChapman> ah now that changes things. I was about to say a cloud server should do the job
[18:30] <balloons> if we don't need real hw, this easily goes in the cloud and we pick our favorite provider and go
[18:31] <dkessel> balloons: i will be moving to "the countryside" in about one month. and i am still unsure about how good and reliable the internet connection will be there. but other than that, i would be fine with running the box from home ;)
[18:31] <dkessel> if CI suggest real hardware because they have had bad experiences with virtualization breaking stuff a lot, then i would understand.
[18:35] <DanChapman> balloons: didn't the previous runs of these use kvm of jenkins.qa.u.c? If so there was never any real issue in regards of the test environment and they used to run great
[18:35] <balloons> DanChapman, yes as far as I know. hmm
[18:35] <balloons> perhaps the issue here is cloud kvm vs real hw kcm?
[18:36] <balloons> regardless, we can certainly try in a cloud environment
[18:51] <DanChapman> balloons: I think it's definately worth a shot, before commiting to real hw.
[18:52] <DanChapman> man I forgot how *little* you can easily identify object with gtk apps in vis :S
[18:53] <balloons> heh.. yea, the dark ages
[18:57] <dkessel> DanChapman: mhh i am struggling to even get autopilot to show the ubiquity instance...
[18:58] <dkessel> okay, so let's first try the cloud option
[18:58] <balloons> sounds good to me. Who's up for it?
[19:01] <dkessel> o/
[19:05] <balloons> awesome..
[19:08] <DanChapman> dkessel: are you getting to the live desktop and ubiquity just doesn't start?
[19:09] <dkessel> DanChapman: it starts, and stays open, but running "autopilot vis" (after installing python-autopilot) won't show any ubiquity instance
[19:12] <DanChapman> ahh right. so what you need is to use a config file. Take a look at http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/autopilot/ubiquity-autopilot-runner/config/testrunner.cfg as an example then you can  pass it to the runner with the -T --testconfig options
[19:12] <DanChapman> setting SHUTDOWN=0 will keep the runner live after a failed test which you can then launch autopilot vis
[19:14] <dkessel> DanChapman: i used that exact same file :) and it left the runner open with ubiquity. but autopilot vis still waits "for the first valid dbus connection"
[19:14] <DanChapman> don't forget you need to use the launch_vis script in the ubiquity/autopilot/* dirctory
[19:14] <dkessel> ahhhh
[19:16] <DanChapman> unfortunately it doesnt work with the python3 AP vis so you don't get all the nice goodies like search :-(
[19:19] <dkessel> this is truly horrible. someone should at least have put object names into the glade file for ubiquity
[19:22] <dkessel> omg i think i have found the item finally
[19:24] <DanChapman> dkessel: ubiquity is probably the best gtk app out there to actually find object id's. You should checkout some of the other gtk apps, you won't find any, apart from a helpful toplevel name like NautilusWindow or some such
[19:24] <dkessel> DanChapman: i found the item here: http://i.imgur.com/3xg07SE.png
[19:25] <dkessel> DanChapman: yeah, i had to bug one of xubuntu's developers to include object names there, too :p i can understand that these are never important to developers, because you can interact with stuff by reference, not by object name....
[19:25] <DanChapman> balloons: this brings back memories :-)
[19:26] <dkessel> DanChapman: i could do a merge request to fix the coordinates
[19:26] <balloons> nice work
[19:27]  * balloons shudders at the sight of those gtk objects
[19:27] <balloons> indeed this brings back memories! And people say autopilot is hard for qml apps! sheesh!
[19:27] <dkessel> ... if that is all it needs, that is ;)
[19:28] <dkessel> i am wondering why "accessible_name" is not used
[19:32] <DanChapman> dkessel, it doesn't use accessible_name because of non english installs may not display it as "English" or "German" all the test does is check it is unicode as there has been previous bugs where it just displayed black squares etc
[19:33] <dkessel> DanChapman: oh... ok *reads test code to look for a possible fix*
[19:35] <DanChapman> dkessel: does the parent GtkTreeViewAccessible of that cell have valid rect co-ordinates and is it visible? those are the two things the _get_gail_treeview code will looks for
[19:36] <DanChapman> balloons: yeah I did always wonder what they had to moan about :-)
[19:37] <dkessel> DanChapman: it has valid coords and is visible
[19:38] <DanChapman> now jot those coords down. And go looking for the matching GtkTreeView and see if the coords match.
[19:41] <DanChapman> it should be the only GtkTreeView beneath a GtkBox with name "stepLanguage"
[19:45] <dkessel> phew.... *searches*
[19:47] <dkessel> hah
[19:48] <dkessel> DanChapman: the coords don't match. accessible: 225,269,120,21 , treeview: 225,270,122,242
[19:51] <dkessel> the treeview has a BuilderName... "language_treeview"
[19:51] <DanChapman> :-( that's not such good news. IIRC there wasn't another way to identify between them.
[19:57] <dkessel> DanChapman: wait, the treeview's accessible isn't that far off.... it is at 224,269,122,242 . so only off one pixel off at x and y
[20:00] <dkessel> ugly, but making that comparison less strict might be a way.... after all, there shouldn't be too many controls with coordinates one off of the treeview, and the same height and width
[20:03] <DanChapman> dkessel yeah making it less strict sounds reasonable to me. autopilot-gtk is ugly so i'm cool with ugly workarounds :-D It's a nightmare they are on seperate tree's to anyway
[20:03] <dkessel> DanChapman: I got to leave. Left my results on the bug.
[20:04] <dkessel> once i understand the syntax to create a "off-by-one clone" of the globalrect, i can propose a fix
[20:05] <dkessel> or wait... i think i know a way.
[20:05] <dkessel> see you another day :)))
[20:06] <DanChapman> dkessel ok great :-) enjoy your evening!
[20:09] <balloons> thanks guys!