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