[13:45] <brendand> pitti_, we seem to have a problem where if unity8 is updated in the archive (and therefore adt-run install it in it's tmp directory) then unity8 fails to start
[13:46] <brendand> pitti_, i guess there's no way to prevent it from installing particular packages?
[13:49] <pitti_> brendand: other than dropping the test dependency, not ATM
[13:49] <pitti_> brendand: that's for unity8's own tests presumably?
[13:49] <brendand> pitti_, no for our system tests, but we can't drop the unity8-autopilot dependency
[13:49] <brendand> pitti_, pinning wouldn't work?
[13:51] <pitti_> brendand: it fails because of the LD_LIBRARY etc. stuff?
[13:51] <brendand> pitti_, that would be my guess but i haven't done enough debugging to say for sure
[13:53] <pitti_> brendand: ah, because of
[13:53] <pitti_> Package: unity8-autopilot
[13:53] <pitti_> Depends: unity8 (= 8.10+15.10.20150616.1-0ubuntu1)
[13:53] <pitti_> brendand: no, pinning won't work then :/ you either have an unavailable old unity8-autopilot or an unavailable current unity8, so it'd be uninstallable
[13:55] <pitti_> brendand: so first, what is your goal? Do you want to test the installed unity8 against the latest unity0-autopilot? or against the u8-ap from the time of when the image was built?
[13:58] <brendand> pitti_, i think we want both unity8-autopilot and unity8 to be the same version as when the image was built
[13:58] <brendand> pitti_, as in, we want to install unity8-autopilot as a dependency but not cause unity8 to be updated
[14:03] <pitti_> brendand: then we can't use apt for that at all, as we don't index the old versions
[14:03] <pitti_> brendand: the test could check out an older version from bzr, or download the .deb from Launchpad perhaps
[14:03] <pitti_> (the old problem of "we don't have an archive matching the contents of old images")
[14:04] <brendand> pitti_, ok
[14:05] <brendand> pitti_, that could be done as a setup-command?
[14:11] <brendand> pitti_, do you happen to know if that's the same for ppa's?
[14:11] <brendand> pitti_, it seems unity8 will typically be in the overlay ppa
[14:12] <pitti_> brendand: would be easier in the test itself, I think
[14:12] <pitti_> brendand: PPAs are even worse
[14:12] <pitti_> brendand: for the archive we at least have the old debs in the librarian still
[14:12] <pitti_> brendand: but not for PPAs, they get removed on uploads of newer sources to the PPA
[14:13] <brendand> pitti_, aargh
[14:13] <brendand> might be easier to try and see if the bug can be fixed
[14:15] <pitti_> brendand: oh, if you mean "create a PPA with test dependencies at the time you build an image", then yes, that would work
[14:15] <pitti_> brendand: that would actually be kinda nice -- you could do binary copies to avoid rebuilding, and we can remove them together with deprecating images
[14:15] <pitti_> and we'd always have indexes and apt working
[14:16] <brendand> pitti_, i didn't, but that sounds like goodness :)
[14:16] <pitti_> brendand: unity failing with the tmp unpack dir? yes, I can look into that
[14:16] <pitti_> brendand: but that's not exactly what you want, that's "current u8-ap against old unity8"
[14:19] <brendand> pitti_, would the unity8 version installed this way write it's logs in adt-run's tmp directory or the usual place?
[14:21] <pitti_> brendand: it would use the usual place, $HOME/.cache or whereever
[14:22] <pitti_> brendand: but I seriously doubt that we can make something as complex as unity8 work from a temp unpack dir
[14:22] <pitti_> this involves d-bus activation files and such, which you can't re-point at runtime
[14:22] <pitti_> we could at most fix it to ignore the unity8 in the tmp dir and use the system-installed one
[14:23] <pitti_> bbl
[20:05] <kenvandine> are there any known issues with autopilot on wily and entering text with the OSK?
[20:06] <kenvandine> it's suddenly flaky in system-settings tests on wily, at some point in the test run it stops entering text and never starts working again
[20:06] <kenvandine> it never finishes a full run of the test suite
[20:07] <kenvandine> once it stops working, i can run individual tests and see it never enter text
[20:07] <kenvandine> but after rebooting the device, it'll work again
[20:07] <kenvandine> only rebooting fixes it
[20:07] <kenvandine> the osk does get raised, but no characters entered
[20:10] <alesage> kenvandine, forwarding you a mail that I *think* is related, trying to land fix, maybe ask veebers about when he arrives shortly
[20:16] <svij> balloons: hey
[20:29] <balloons> svij, howdy!
[20:29] <balloons> DanChapman, did you think about the ubiquity tests over the weekend?
[20:29] <balloons> dkessel says he's in for helping :-)
[20:30] <svij> balloons: I'm nearly done with that test from last week, but I can't figure out which objectName the "multipleDeleteAction" is :-/
[20:31] <svij> so, the objectName for the delete-Button in the Actionbar has a objectName "multipleDeleteAction", autopilot can't find it, and when I inspecting the output "print_tree()" I cant find it either
[20:34] <svij> … objectName "multipleDeleteAction" is set in the qml, of course…
[20:37] <balloons> svij, interesting ... Care if I have a look?
[20:37] <balloons> Got a branch I can pull?
[20:37] <svij> not yet
[20:37] <svij> I mean, no branch yet ;)
[20:38] <svij> gimme a few sec
[20:38]  * svij is also new to launchpad/bzr
[20:40] <balloons> svij, :-) no worries.
[20:43] <svij> balloons: that should be right lp:~svij/calculator/delete-multiple-calculation
[20:45] <balloons> on it
[20:47] <balloons> ok, and we're looking at test_delete_multiple_calculation_from_history
[20:47] <svij> yep
[20:47] <balloons> ahh, so I think I know what you are talking about
[20:48] <balloons> so remember, objects don't exist until they are created. make sure you check the dbus tree right before you would before the action
[20:49] <svij> so I need to click on that menu-icon first?
[20:50] <balloons> ahh right.. it's in the action menu. There's a helper to select those I believe
[20:50] <balloons> https://developer.ubuntu.com/api/autopilot/python/1.5.0/ubuntuuitoolkit/#ubuntuuitoolkit.AppHeader.click_action_button
[20:52] <balloons> hmm
[20:53] <svij> AttributeError: Class 'MainView' has no attribute 'open_header'.
[20:54] <balloons> you should grab the header, or do it inline: self.app.main_view.get_header().click_action_button
[20:54] <svij> ah
[20:54] <balloons> that said, still gave me an error. So I'm using vis to have a look
[20:56] <balloons> so the full objectname I see is multiDeleteAction_header_overflow_button. It's an AbstractButton type, and it's in the overflowpanel.
[20:57] <balloons> I found that by loading the menu, and then looking in vis
[20:57] <svij> oh right
[20:58] <balloons> so the helper should work
[20:59] <svij> hm, can you show me your complete line?
[21:00] <svij> this doesn't work: self.app.pointing_device.click_object(self.app.main_view.get_header().click_action_button('multiDeleteAction_header_overflow_button'))
[21:00] <balloons> svij, no you wouldn't want to do it like that. You had the object name correct
[21:01] <balloons> the expanded version is done by the toolkit and the helper already accounts for it.
[21:01] <balloons> self.app.main_view.get_header().click_action_button('multiDeleteAction') should work
[21:01] <svij> oh
[21:01] <balloons> it's interesting it doesn't see the action
[21:02] <svij> still "No actions in overflow"
[21:03] <balloons> yep, checking into why that is
[21:04] <balloons> svij, ahh, as I thought. The action overflow button is set to not visible
[21:05] <svij> so?
[21:07] <balloons> svij, so, the helper implementation checks for that, and gives that message if it's not visible
[21:08] <svij> ah
[21:08] <balloons> now, as to why it's saying it's not visible, I'm not sure. But in the interim if we want to check the test, we can override the helper method where the error occurs
[21:08] <balloons> could be something in the qml
[21:10] <svij> sorry, I don't get it
[21:10] <balloons> yea, I'll show you in a second, and it will make more sense
[21:10] <svij> ok :)
[21:23] <svij> balloons: can I ping you tomorrow for further details?
[21:23]  * svij needs to go to bed
[21:24] <balloons> svij, :-) Basically, I confirmed  self.app.main_view.get_header().click_action_button('multiDeleteAction') works
[21:24] <svij> how?
[21:24] <balloons> however, something to ask the developers again as to why the overflow button is all wonky
[21:25] <svij> that means?
[21:25] <balloons> I think it's another bug in the code to fix
[21:25] <svij> i see, but… in which code?
[21:25] <balloons> svij, the app code. Not your test
[21:25] <svij> I see
[21:26] <balloons> svij, the helper call basically does all this: http://paste.ubuntu.com/11759253/
[21:27] <svij> ah
[21:27] <balloons> that fails because the actions overflow button (which is that little menu button) is a bit weird in the tree. It has weird properties and won't click or show it's actions
[21:27] <svij> ahh, now I understand the problem.
[21:28] <balloons> yea. the helper finds the action button, clicks it, then looks for the action you want. Then it selects it
[21:28] <balloons> it's failing now to find the button to click on because it's properties say it's not there
[21:29] <svij> can you fix that?
[21:29] <balloons> svij, I think that's something fixable in the qml.. Then your test should just work
[21:29] <svij> ok
[21:30] <svij> I'll check tomorrow, I'm nearly sleeping. ;)
[21:30] <balloons> svij, sounds good :-)
[21:30] <balloons> good night!
[21:30] <svij> thx. :)