[11:23] <elfy> jibel: hey - any reason why lookiing at jenkins the last result for ubiquity appears to be 3rd December?
[11:23] <elfy> https://jenkins.qa.ubuntu.com/view/Ubiquity/view/All/?
[11:24] <jibel> elfy, the tests have been dropped by mistake, they'll be back soon (before Beta 2) Sorry about that.
[11:25] <elfy> jibel: ok - thanks :)
[11:25] <elfy> I don't often look tbh - only when we appear to have boot issues
[11:25] <elfy> which of course we've got right now :)
[11:26] <jibel> I start looking around 1st beta, when things start to calm down and false positives are rare.
[11:26] <elfy> oh this is a real positive - boot 32 bit with vbox and it doesn't :)
[11:27] <elfy> waiting for today's builds and I'll check again and try it on hardware as well
=== pgraner-hol is now known as pgraner
=== josepht_ is now known as josepht
[15:08] <elopio> good morning
[15:08] <brendand> elopio, fgimenez - a branch i'd really like to merge before i start working on the camera test - https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/launch_app_base_class/+merge/250017
[15:09] <dobey> pitti: hey. could we get the ubuntu-touch-session script in autopkgtest changed to use a resolution that matches an actual phone (like 540x960, 720x1280, 1080x1920 or such), and have a window manager running (so that --maximize and --fullscreen work properly with qml/qt)?
[15:10] <elopio> brendand: I would prefer it as a fixture instead of a base class.
[15:10] <pitti> dobey: that sounds like a nice idea; would you mind filing a bug? (can't do it right now, sorry)
[15:10] <pitti> dobey: I'll get that done tomorrow
[15:10] <dobey> pitti: sure
[15:11] <elopio> brendand: also, that bug link seems wrong.
[15:12] <elopio> takes me to page not found.
[15:13] <brendand> elopio, mm, there's a small typo
[15:13] <brendand> elopio, i'm not so sure about it being a fixture
[15:13] <elopio> pitti: ping. fgimenez found that dpkg-architecture, when installed in a read-only phone, gives an error because it can't find the perl libraries. Shouldn't adt-run set the env var for perl libraries path too?
[15:15] <dobey> elopio: that's weird
[15:15] <dobey> elopio: i don't buy that, because we use dpkg-architecture in the store scope to get the architecture to query for
[15:16] <dobey> elopio: so either that's just a new bug, or something else is wrong
[15:16] <elopio> brendand: I think it will be clearer. Call it OpenAppFromDash, and then it's also clear that the click scope will be opened.
[15:17] <brendand> elopio, but i don't want it to open the app immediately
[15:17] <brendand> elopio, the test author needs to control that part
[15:17] <brendand> elopio, whether to run some code before actually launching the app
[15:18] <fgimenez> dobey: in our case the dpkg-architecture script was complaining about the Dpkg.pm module, it wasn't able to find it
[15:18] <brendand> elopio, so then the launch_app part will have to be a seperate helper
[15:18] <elopio> dobey: I think that in jenkins, that dependency is installed making the partition writable. I'm not sure about that.
[15:19] <brendand> elopio, i'll have a look at it though to see how it works
[15:19] <elopio> brendand: then you could make a method launch_app that's not called from the fixture setup. Or do not open the click scope on the fixture, just launch the app.
[15:20] <elopio> we can make a fixture that opens the scope and launches the app. And one that only launches the app.
[15:20] <fgimenez> dobey: dpkg-architecture is installed through dpkg-dev and is located under the writable /tmp dir where the dependencies are installed
[15:20] <elopio> but do we have a test that needs to do something between opening the scope and launching the app?
[15:21] <pitti> elopio: yes, it does set $PERLPATH
[15:21] <pitti> elopio: but you really don't want dpkg-architecture; dpkg-dev has a *huuuge* dependency list
[15:21] <pitti> elopio: you want dpkg --print-architecture
[15:21] <pitti> (which requires no dependencies)
[15:22] <pitti> dobey: really? you don't use dpkg --print-architecture?
[15:22] <pitti> (most of the time that's all that an app wants/needs to know)
[15:22] <elopio> pitti: what we need is dpkg-architecture -qDEB_HOST_MULTIARCH
[15:22] <dobey> pitti: oh maybe
[15:22] <elopio> is there a way to get that string without dpkg-architecture?
[15:23] <dobey> i thought we were using DEB_HOST_MULTIARCH though
[15:23] <elopio> pitti: and the envvar that we need to set is $PERL5LIB
[15:24] <pitti> elopio: right, that's what it actually sets
[15:24] <pitti> so, feel free to open a bug about dpkg-archtiecture not working
[15:24] <dobey> oh no, right
[15:24] <pitti> but keep in mind: this is a r/o phone; tests can't pull in a gazillion debs :)
[15:25] <dobey> whenever i used ro-apt with qemu, it just hangs :-/
[15:26] <elopio> pitti: yes, it's taking a long time. I would like not to install dpkg-architecture, but I know no other way to get the path to the installed libraries.
[15:27] <pitti> elopio: which libs?
[15:27] <pitti> (ldd is a nice tool for that)
[15:27] <elfy> balloons: you got any idea why vivid dailies have stopped for some of us?
[15:28] <elopio> pitti: /usr/lib/{}/oxide-qt/chromedriver'.format(architecture)
[15:28] <pitti> or dpkg -L even
[15:28] <pitti> anyway, sorry guys; I need to run early today
[15:28] <pitti> TTY tomorrow!
[15:28] <elopio> bye, thanks pitti.
[15:29] <pitti> elopio: installing 50 MB of dependencies just for that seems excessive; dpkg -L might be a lot ligher?
[15:29] <pitti> lighter
[15:29] <pitti> elopio: or some globbing perhaps?
[15:30] <elopio> fgimenez: what do you think? dpkg -L sounds good to me.
[15:31] <fgimenez> elopio: pitti: of course, we can give it a try and remove a lot of download time
[15:33] <elopio> fgimenez: could you please file the bug about dpkg-architecture not working on r-o?
[15:33] <elopio> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/
[15:35] <dobey> dpkg-architecture requires installing 50 MB of deps?
[15:35] <fgimenez> elopio: ok thanks
[15:40] <balloons> elfy, I see nothing today for xubuntu
[15:41] <balloons> ubuntu gnome and lubuntu also seem affected
[15:41] <balloons> but no I don't have an answer
[15:43] <paulliu> elopio: https://code.launchpad.net/~paulliu/unity8/notification_helper/+merge/249211
[15:43] <paulliu> elopio: just fix all the issues you mentioned. Also run flake8. I didn't fix the errors not related to this commit.
[15:52] <elopio> paulliu: +1
[15:52] <elopio> thank you.
[15:54] <elfy> balloons: ok
[15:56] <elfy> balloons: seems kylin and studio as well
[15:57] <brendand> elopio, we don't run --dbus-probe-enable in the sanity tests at the moment right?
[15:57] <elopio> brendand: yes we do
[15:57] <brendand> elopio, hmm i wonder why autopilot can't introspect the camera-app then?
[15:57] <brendand> maybe it didn't load properly
[15:58] <elopio> brendand: do you have a screenshot?
[15:58] <elopio> I was talking with the camera guys some minutes ago, and on their test they are launching with upstart.
[15:58] <elopio> if it works for them, should work for us.
[16:15] <brendand> elopio, nope the app is launched but still nothing
[16:15] <brendand> hmmm
[16:19]  * brendand afk for a bit
[16:28] <paulliu> alesage: https://code.launchpad.net/~paulliu/unity8/notification_helper/+merge/249211
[16:28] <alesage> paulliu, ok will get to today
[17:07] <elopio> jibel: the last question for today, for when you return from your meeting
[17:08] <elopio> jibel: there is a QML element that takes care of blurring the camera screen when the controls are open. To do that check, the easy solution is to check for the presence of that QML element.
[17:09] <elopio> then we are not really checking that things are blurred. We leave that to lower level of testing, probably qml tests.
[17:09] <elopio> is that ok for you?
[17:15] <jibel> elopio, that's fine. I don't think we check it manually either :)
[17:17] <elopio> ubuntu-qa: we need to think a sustainable way to say: this high level test assumes that all these low level tests exist and are green.
[17:17] <elopio> if the low level tests don't exist, are not running, or are not passing, somebody has to suffer.
[17:17] <balloons> oO, a lovely whole and not the first or last I suspect
[17:18] <davmor2> Test All the Tests
[17:18] <elopio> the problem is, how to notice about that without reading all code.
[17:19] <alesage> elopio presumably a software wouldn't make it onto the phone if its low-level tests were failing?
[17:19]  * alesage notes that it's necessary to put a question mark there
[17:19] <alesage> elopio, or maybe I'm not following
[17:20] <alesage> elopio, we can't take on the responsibility of running those tests *again*, correct?
[17:22]  * alesage taps microphone
[17:22] <alesage> an audit of some kind?
[17:27] <elopio> alesage: I think it's not often that we release something with low level tests failing or skipped, you are right there.
[17:27] <elopio> but we often releasea things with low coverage.
[17:29] <alesage> elopio, so you're proposing a way for ops to see the "testing health check" for the release or silo
[17:30] <elopio> alesage: yes, maybe. It will help if they see test coverage and test results.
[17:31] <elopio> I also think it would be useful if they inspect the branches that are landing, to get a feeling of the new tests being added.
[17:31] <elopio> but maybe that's too much.
[17:34] <alesage> elopio, would those stories split like: "a review of lower-level relevant tests for ops", "lower-level tests added", "test coverage total for project"
[17:34] <elopio> I don't follow.
[17:35] <alesage> elopio just trying to split up what you're proposing into specific stories, with the ops team as the user
[17:36] <elopio> alesage: ok, I think it should have a historic view of number of tests run, passed and skipped.
[17:36] <elopio> it shouldn't arrive to silo testing if there are failed tests, at any level.
[17:37] <elopio> and a silo must come with links to bug reports and MPs, so we can take a look at specific code details that seem important.
[17:37] <alesage> elopio, right, would be good to trace back to the relevant CI builds and validate that they happened, etc.
[17:38] <alesage> (as a first step toward other coverage, tests introduced, etc.)
[17:41] <alesage> the edges demo changed, eh?
=== roadmr is now known as roadmr_afk
[20:06] <elopio> ping veebers: there is this bug: https://bugs.launchpad.net/autopilot/+bug/1422797
[20:06] <ubot5> Launchpad bug 1422797 in Autopilot "MIR refuses the app to connect" [Undecided,New]
[20:07] <elopio> which I think it's either the camera app taking too long to start, or unity failing to see it, or ubuntu-app-launch doing something wrong.
[20:07] <elopio> that is, I think it's not an autopilot bug.
[20:08] <elopio> veebers: if you have some time, could you take a quick look at it and tell us if you notice something useful for the tests?
[20:08] <veebers> elopio: right, I don't think it's an autopilot bug (unless something has changed and we weren't told and launch isn't doing the right thing any more)
[20:08] <elopio> but only if it's quick. If it will take more time, we'll have to schedule it for next week.
[20:09] <veebers> elopio: I'm not sure I follow your request? Ah you mean take a look at the issue and see if I can find out anything?
[20:09] <elopio> veebers: yes. As far as I can see, it can't be autopilot's fault because I read the code for launching and stoping and it looks correct to me.
[20:09] <veebers> brendand: do you think the issue you're seeing in your test is related to the bug elopio linked? ^^
[20:09] <elopio> like, it can't fail if ual is behaving correctly. But I might be missing something.
[20:13] <veebers> brendand: if you're seeing a testability load error I don't think this bug is what you're seeing :-)
=== roadmr_afk is now known as roadmr
[20:30] <elopio> ugh.
[20:30] <elopio> the new error in the wizard test it's because we have a class also called LanguagePage in system settings.
[20:30] <elopio> we need to improve this autopilot cache. I have no idea how.
[20:31] <balloons> ubuntu-qa, Letozaf_ has an interesting problem to work on I suspect a solution already exists for. She needs to test mounting and unmounting an sdcard inside file manager
[20:32] <elopio> balloons: we haven't solved that yet. We talked about calling the mount and umount to fake the insertion of the card.
[20:33] <veebers> elopio: yeah it's becoming more an issue
[20:33] <elopio> Letozaf_: we haven't tried that yet, and we don't know if there's a better solution than that either.
[20:33] <elopio> oh, and there's the issue that the lab will need to have a phone with a card.
[20:33] <dobey> elopio: mount/unmount won't simulate insertion of the card. you'd need to do some fake thing through udev i think
[20:34] <elopio> for our case, we are assuming that. For a general case, the sdcard itself needs to be faked.
[20:34] <Letozaf_> elopio, ah, ok
[20:34] <dobey> because, really, 'insertion' would normally result in automounting
[20:34] <elopio> dobey: yes, that sounds right.
[20:35] <elopio> balloons: do you know who worked on the sdcard? He needs to provide a fake for us.
[20:35] <dobey> or permanently affix an sd card to an arm, attached to a stepper motor, and use an arduino to insert/remove it physically in a slot
[20:36] <balloons> elopio, ohh good point. No idea, but here is pitti's thoughts on the specific bug. I was curious about what he had done with mocking anyway, looks like umockdev isn't enough: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1406988/comments/1
[20:36] <ubot5> Launchpad bug 1406988 in Ubuntu File Manager App "Autopilot tests for SDCard support" [High,New]
[20:36] <dobey> may damage the sd card or slot though
[20:36] <elopio> veebers: do you know if autopilot has a bug for that thing in the registry?
[20:37] <veebers> elopio: let me check
[20:42] <veebers> elopio: no there isn't a bug for it
[20:42] <elopio> veebers: I'll make one.
[20:44] <veebers> elopio: awesome, thanks
[20:45] <balloons> dobey, indeed, but the test fails on the desktop then :-)
[20:46] <balloons> elopio, so is there an open bug / issue for this? I guess if not we'll need a meta bug for it, assuming you think there should be a helper / provider for this
[20:46] <dobey> balloons: not if the device is present and being used :)
[20:46] <dobey> but will fail for many other reasons
[20:48] <elopio> balloons: no bug that I know of.
[20:48] <elopio> veebers: how did you workaround the MRO issue?
[20:49] <elopio> I'm looking for a quick fix for this LanguagePage problem, hitting funnier problems on every try.
[20:49] <veebers> elopio: By doing the import at the top of the file and not within the method
[20:49] <elopio> oh, I know what to do 8-)
[20:56] <veebers> elopio: oh?
=== pgraner is now known as pgraner-afk
[21:26] <veebers> elopio: hey, follow up, is this MP ready for review (was going through cards)? https://code.launchpad.net/~canonical-platform-qa/ubuntu-sanity-tests/fix1422568-wizard/+merge/250071
[21:26] <veebers> I ask because it's not in the review lane ;-)
[21:31] <ianorlin> uh 14.04.2 download info for ubuntu server generates a 404 error and zsync fails