[00:07] <robru> tedg: you're welcome
[00:58] <tedg> robru, With the UAL branch we have a build dep on Mir, which means no more PPC for us. Is there a way to note that? Or just tell QA, etc. when I'm done testing.
[00:59] <robru> tedg: the mir build dep is new?
[00:59] <tedg> robru, Yeah
[01:00] <robru> tedg: k, there's not a great way to "note" this... you need to ask somebody from #ubuntu-release to delete the ppc binaries from the archive. you can build the silo before that happens, but just be aware that the build job will fail due to the ppc failure.
[01:00] <robru> tedg: I don't think qa will care or even need to know. but if you don't get those ppc binaries deleted from the archive, the package will fail to migrate through proposed as wel
[01:00] <tedg> robru, ah, okay. But we don't need to do that until they're being published, right?
[01:01] <robru> tedg: well the sooner the better. without deleting the binaries the silo will just say 'build failed' so it won't show up on qa's radar to test it.
[01:02] <tedg> Ah, I see
[01:02] <robru> tedg: I can manually poke the silo status to say 'Packages built' so it shows up for qa though, just ping me when you're ready for that
[01:02] <tedg> robru, I think it's ready for that, silo 17
[01:02] <tedg> I still need to test it though.
[01:03] <tedg> But the build is complete
[01:03] <robru> tedg: ah I see, the other arches are done but ppc is depwait. yeah ok I can poke the silo status to say it's built
[01:07] <robru> tedg: k, dashboard looks correct. just mark is as tested:yes when you're ready and it should show up for qa.
[01:08] <robru> tedg: also ping me whenever you rebuild it, I'll have to do this manually each time.
[01:16] <tedg> robru, Not sure if you're reading #ubuntu-release, but there's a plan to make PPC work for the other packages to save a library cascading dependency issue.
[01:20] <robru> tedg: just read it. k. if you can make the package build on ppc then there's nothing else on our end. if it builds, it builds, and everything is happy.
[02:05] <imgbot> [03:25] <imgbot> [03:25] <imgbot> [05:45] <bzoltan_> does anybody know what that log means? http://pastebin.ubuntu.com/10535387/ It comes zillions of times when the UITK AP tests started ...
[08:40] <sil2100> ogra_: hey! You have a moment for a packaging ACK? It's for unity7, but looks safe: https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.3.1+15.04.20150227-0ubuntu1.diff
[08:43] <ogra_> sil2100, ACK
[08:43] <sil2100> \o/
[08:53] <sil2100> cihelp: hey! It seems the krillin vivid dashboard again didn't run all the tests - can we get the missing devices re-ran? http://rtm-dashboard.ci.ubuntu.com/smokeng/vivid/touch/krillin/134:20150305:20150210-95b6a9f/381/
[09:51] <robru> sil2100: ^^^ hmmm I'm looking into this
[09:56] <robru> welll allrighty then
[10:01] <ev> sil2100: it's with us. How critical is this? Would it be okay if it waited until Francis, our vanguard for the day, started?
[10:08] <sil2100> Yeah, I suppose it can wait
[10:14] <nerochiaro> sil2100: fginther: psivaa_: i think I have a problem with licensecheck again. According to a previous conversation that we had CI runs licensecheck with this script: http://paste.ubuntu.com/9898679/  When I poked you about this before, licensecheck was getting confused because I had files I copied from QT with multiple licenses. I fixed that but I had not noticed that the script also checks that the copyright is by Ca
[10:14] <nerochiaro> nonical,Android,Digia or Google. Why does it do that ? As long as we are using open source licensed software it should not matter who the author is...
[10:18] <sil2100> huh, it does?
[10:18] <sil2100> Oh, it does
[10:18] <sil2100> Ok, strange, I'm sure there was a reason for that, but I don't have the required info
[10:23] <psivaa_> nerochiaro: I'm not sure how that policy was used, i'll raise it with fginther
[10:24] <nerochiaro> psivaa_: thank you
[10:24] <psivaa_> nerochiaro: for the future, please use 'cihelp' for this type of pings for better handling of them :)
[10:24] <psivaa_> so that there will be more people that will get notified
[10:24] <nerochiaro> psivaa_: i pinged you and the others because you already had background on the issue having helped me before with it
[10:25] <nerochiaro> psivaa_: but i will add cihelp (when it is online)
[10:25] <psivaa_> nerochiaro: cihelp is not a bot, but a word that will highlight our team
[10:25] <psivaa_> and thank you
[10:26] <nerochiaro> oh I see :) thanks
[10:30] <sil2100> robru: btw. aren't you supposed to be sleeping? ;)
[10:57] <nerochiaro> greyback: hi, i have seen you are assigned to bug 1422797 now. I don't understand why it has changed target and what is the status. can you please update me ?
[10:58] <greyback> nerochiaro: the last comment I wrote is my summary so far. What's unclear?
[10:59] <nerochiaro> greyback: what kind of information you need to be able to continue
[11:02] <greyback> nerochiaro: in a nutshell, I need to verify that it's not possible for 2 instances of camera-app to ever run simultaneously with AP
[11:04] <nerochiaro> greyback: I guess also what I don't understand is if Mir is doing the right thing to refuse AP to launch a second instance of camera, and therefore it is AP that has to be fixed so that it does not try to do so
[11:06] <greyback> nerochiaro: indeed. It could be AP, or qtmir/unity8, which is to blame here.
[11:06] <greyback> and I can't quite tell from the unity8 log which is the case
[11:07] <nerochiaro> greyback: and having a CI run with all the other associated logs would help you ?
[11:07] <nerochiaro> greyback: i mean, a CI run where this problem happens
[11:08] <greyback> nerochiaro: I'd need verbose AP logs, perferably printing when it actually launches & fully has killed the camera process
[11:08] <greyback> err it's actually upstart launching/killing, but you see what i mean
[11:09] <nerochiaro> greyback: yes, is that something we can ask the CI people to set up for us
[11:09] <greyback> nerochiaro: I'd also be tempted to add more debug output to qtmir
[11:09] <greyback> nerochiaro: there's no way you can repro this locally?
[11:10] <nerochiaro> greyback: i have not been able to do so so far
[11:14] <greyback> nerochiaro: that makes this hard. What are CI doing that we're not?
[11:17] <nerochiaro> greyback: not sure. are they just running autopilot3 run camera_app ?
[11:17] <nerochiaro> greyback: this is what i did
[11:17] <nerochiaro> greyback: in a loop
[11:17] <greyback> nerochiaro: I always assumed they follow this guide https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests
[11:18] <greyback> nerochiaro: I'll spin up a mako now and see
[11:20] <nerochiaro> greyback: the latest and greatest on how to run tests (from some info Bill sent me) just tell me to ssh into the device and run autopilot3 manually. And I never managed to get phablet-click-test-setup anyway (it fails to download some of the AP emulators for the sdk)
[11:21] <greyback> nerochiaro: okay. it used to work for me, will see how it goes
[11:24] <nerochiaro> greyback: ok. please keep me posted. it is my test-fixing day today so i am trying to get at the bottom of as many issues as i can
[11:24] <nerochiaro> greyback: and if you have ideas on things i can run locally too, please let me know
[11:24] <greyback> nerochiaro: sure thing
[11:35] <sil2100> dbarth_: ping
[11:35] <sil2100> dbarth_: do you have any updates related to the u1 issue on ubuntu-rtm? We'd need it fixed by next week's milestone
[11:37] <dbarth_> sil2100: trying to land a new patch, which is part of silo 010, but having issues with multi-arch support
[11:37] <dbarth_> sil2100: i touched base on that with davmor2 earlier this morning
[11:38] <davmor2> sil2100: beat you to it :)
[11:42] <sil2100> \o/
[11:42] <sil2100> :)
[12:12] <rvr> dbarth_: Silo 13 (ubuntu-rtm) doesn't have any bug linked
[12:19] <dbarth_> rvr: let me fix that
[13:04] <nerochiaro> greyback: i tried running tests via phablet-test-run and I got a MIR failure
[13:04] <nerochiaro> greyback: [1425560625.112570] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.12.0+15.04.20150228/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int)
[13:04] <nerochiaro> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE
[13:04] <nerochiaro> std::exception::what: Attempt to set swap interval on screencast is invalid
[13:04] <greyback> nerochiaro: they can be ignored I think, the tests still pass
[13:04] <nerochiaro> greyback: i see
[13:05] <greyback> may cause camera-app to crash instead of cleanly shut down
[13:10] <nerochiaro> greyback: let me remove all crash files, so i know if it does
[13:10] <greyback> nerochiaro: it doesn't seem to crash here, dunno why
[13:10] <nerochiaro> greyback: what platform ?
[13:10] <nerochiaro> greyback: i am on krilling, will try mako too
[13:10] <greyback> mako
[13:11] <nerochiaro> greyback: ok, mako is next
[13:12] <dbarth_> rvr: you meant 010 /rtm/ ?
[13:12] <rvr> dbarth_: ubuntu-rtm/landing-013 - unity-webapps-qml : alex-abreu, dbarth
[13:13] <greyback> nerochiaro: this is my 4th try at the camera-app tests. I've got 5 tests reliably failing , none due to a crash
[13:15] <nerochiaro> greyback: let me see what I get here on mako,but i am afraid it will not be very different from what you see
[13:16] <greyback> nerochiaro: I'm assuming CI is using mako?
[13:16] <nerochiaro> greyback: both mako and krillin
[13:16] <greyback> oh
[13:16] <nerochiaro> greyback: and both vivid and rtm
[13:17] <greyback> nerochiaro: and does this error pop up on _all_ combinations randomly?
[13:18] <nerochiaro> greyback: good question. not sure
[13:22] <nerochiaro> greyback: both utopic and vivid on krillin for sure
[13:23] <greyback> nerochiaro: ok then I'll switch to testing on kryllin
[14:04] <fginther> nerochiaro, I'll start looking at the licensecheck issue shortly. As I recall, that script was supplied by another team, so I need to do a little research on it
[14:05] <nerochiaro> fginther: thanks
[14:05] <sil2100> fginther: maybe Didier would know something about it?
[14:08] <fginther> sil2100, looks like mzanetti was involved in the original.
[14:09] <fginther> mzanetti, do you remember this: http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/A10checklicenseheaders.in
[14:09] <mzanetti> fginther: yes
[14:11] <mzanetti> fginther, what's the issue?
[14:11] <fginther> mzanetti, there was a question about why allowedlicenses was limited to "(Canonical|Android|Google|Digia)"
[14:12] <fginther> and not just any opensource copyright
[14:13] <mzanetti> fginther, hmm... I guess it could be changed... no real reason for that IIRC. It was useful as it pointed out some badly licensed copied code
[14:14] <fginther> mzanetti, thanks that does help. I guess it was an adequate check at the time
[14:15] <mzanetti> fginther, yeah, it only allowed Canonical and Android in the beginning, Google and Digia were added later
[14:15] <mzanetti> if more are needed I guess it does make sense indeed to allow any... but IANAL, you might want to check back with Didier or Pat if we're ok with importing any sort of license
[14:16] <mzanetti> might be a conflict with the CLA
[14:16] <mzanetti> fginther, ^
[14:16] <fginther> mzanetti, thanks, I will check with Pat
[14:16] <sil2100> hm
[14:16] <sil2100> Yeah, Didier might know as well but he might not have the most up-to-date info
[14:16] <fginther> mzanetti, there's  another check script that appears to be more relaxed: http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/A10checklicense3party.in
[14:17] <mzanetti> fginther, ah right... now I remember, the first one excludes anything in a 3rdParty directory
[14:18] <mzanetti> we probably don't want to mix those things like crazy to be able to tear it apart again if we ever would need to
[14:18] <fginther> nerochiaro, do you have a branch available with the code you are trying to submit so I can test a few things?
[14:19] <nerochiaro> fginther: the code is actually in camera trunk as far as I know
[14:20] <fginther> nerochiaro, ok
[14:21] <fginther> mzanetti, thanks again, that makes sense. I'll follow up further with Pat as he appeared to be involved in the origins of this as well
[14:21] <mzanetti> yw
[14:26] <nerochiaro> mzanetti: fginther: don't confuse the type of license with the copyright holder please. checking for only certain license types is something we must do, but AFAIK there is no reason to do checks on the copyright holder
[14:26] <nerochiaro> mzanetti: fginther: whowever is the original author of some GPL3 code is irrelevant, all we should care about is that it is GPL3.
[14:27] <mzanetti> nerochiaro, well, we do make contributors sign a CLA. copying other's code bypasses that
[14:27] <mzanetti> so... we might want to check on the copyright holder too
[14:29] <fginther> nerochiaro, so as this code is already in trunk, is this check blocking you right now?
[14:30] <nerochiaro> fginther: it blocks every MR, in the sense that CI isn't run on them
[14:30] <fginther> nerochiaro, ack, I see it now
[14:31] <nerochiaro> mzanetti: it is not contributions that someone has written for us, where a CLA would apply. it is open source code we are taking and using according to its license
[14:31] <nerochiaro> mzanetti: different things
[14:37] <bzoltan_> sil2100:  I can reproduce reboot cycle with 100% certainity ... who should I contact ?
[14:37] <sil2100> bzoltan_: ouch, ok, first of all - did you fill in a bug?
[14:37] <sil2100> bzoltan_: once we have a bug we can track it and escallate
[14:37] <bzoltan_> sil2100:  against what?
[14:37] <sil2100> Let me think, does it happen in a specific AP test run?
[14:38] <sil2100> Or what is the trigger for the cycle to start?
[14:43] <bzoltan_> sil2100:  running  the UITK test plan after the dialer app rebooting the device runs inti reboot cycle
[14:45] <sil2100> bzoltan_: so basically dialer-app's AP test causes this trouble - then I would set dialer-app as the current component and then it will change once the root cause is identified
[14:46] <bzoltan_> sil2100:  I try to make a simple script does it... but I am positive that the dialer app's developers would not be able to fix it
[15:04] <sil2100> bzoltan_: yeah, but I suppose it's a good place to start the search
[15:04] <sil2100> bzoltan_: bugs can be easily retargetted
[15:04] <bzoltan_> sil2100:  true
[15:05] <bzoltan_> sil2100:  I wonder if there is a way to get out some logs form the device before it enters the loop
[15:05] <bzoltan_> sil2100:  or more precisly said.. what logs should I back up before I let the device reboot?
[15:06] <bzoltan_> sil2100:  because I can adp pull before each reboot in my script
[15:14] <sil2100> bzoltan_: hard to say, first the most essential ones I suppose - so syslog and the output of autopilot (maybe with verbose debugging enabled)
[15:15] <mterry> Where can I find the pbuilder hook B09qmluitests ?  I want to see what it's doing
[15:16] <sil2100> o/
[15:16] <bzoltan_> sil2100:  OK, I try to capture as much logs as possible
[15:17] <sil2100> bzoltan_: once we have the basic ones maybe we'll know what can cause that, and what additional logs might be useful
[15:17] <sil2100> bzoltan_: thanks!
[15:17] <sil2100> fginther: hey, regarding smoketesting for vivid+krillin, we noticed that some devices seem to have been down and didn't run tests
[15:17] <sil2100> fginther: do you know what happened to those?
[15:18] <fginther> sil2100, so far I've restarted the failed builds and took only a brief glance at the problems.
[15:19] <sil2100> fginther: I'm asking since bzoltan_ reported that he's able to enter a reboot-loop during AP testing, so I wondered if maybe something like that just happened
[15:19] <fginther> sil2100, there were actually 3 different problems, the wifi network failed to come up for one, another the screen unlock never worked, and the third failed to download the image
[15:19] <sil2100> Although bzoltan_ is able to reproduce it since a few images
[15:19] <sil2100> Ah, ok, so unrelated
[15:19] <sil2100> fginther: thanks ;)
[15:19] <fginther> sil2100, hmm, that's something I'll check for though
[15:21] <fginther> mterry, http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/B09qmluitests.in
[15:26] <mterry> fginther, thanks!
[15:32] <om26er> tedg, Hi!
[15:32] <tedg> om26er, Hi!
[15:32] <om26er> tedg, the indicator-messages TestPlan needs to be updated, should atleast contain a testcase for the fixed bug in silo 18
[15:33] <fginther> mterry, hey, I just noticed that we're seeing lots of screen unlock failures during smoke testing on krillin. Do you know of anything that might be causing this?
[15:33] <mterry> fginther, huh...  no?
[15:35] <tedg> om26er, The wiki is out of date: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.15.04/view/head:/tests/manual
[15:35] <fginther> mterry, ack, I'll start with a bug report then
[15:35] <om26er> tedg, aah
[15:41] <nerochiaro> greyback_: when i use phablet-test-run i get this error autopilot.exceptions.ProcessSearchError: Search criteria (pid = 29537, object path = '/com/canonical/Autopilot/Introspection') returned no results , but i don't get it when I run autopiliot3 directly from an ssh shell. do you know what it is ? (i enabled the dbus probe, which is usually the cause for that)
[15:42] <greyback_> nerochiaro: not a clue. I had the same fail. Suspect phablet-test-run broken
[15:42] <ogra_> isnt phablet-test-run deprecated since a while ?
[15:42] <nerochiaro> ogra_: that's what I thought, but isn't CI using it ?
[15:42] <nerochiaro> ogra_: we are trying to run the tests as CI would
[15:42] <ogra_> dunno .... i just know that pitti recently promoted adt-run
[15:43] <ogra_> and complained that people still use phablet-test-run
[15:43]  * ogra_ was doing snappy work for a while, i'm a little out of the loop
[15:43] <nerochiaro> ogra_: i normally just ssh in and use autopilot3 run
[15:44] <ogra_> iirc adt-run prevents you from making the system writable and modifying it in any way
[15:44] <ogra_> which will get you more accurate results
[15:44] <nerochiaro> cihelp: what tool does CI use to run tests ? phablet-test-run ? straight autopilot3 run ? something else ?
[15:45] <fginther> nerochiaro, CI uses a setof scripts that wrap around phablet-test-run: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/
[15:45] <fginther> nerochiaro, that doc should help if you want to recreate the exact testing
[15:45] <ogra_> fginther, wasnt that supposed to be switched to adt-run by now ?
[15:46] <rvr> dbarth_: I took a look to the bug linked to the merge proposal of silo 13. It is not critical nor approved to land in RTM.
[15:46] <ev> fginther: what a perfectly timed question, eh? :)
[15:47] <nerochiaro> fginther: "This is a small wrapper that uses phablet-tools to drive the tests. The script can run one or more autopilot tests. By default it will reboot the device between each test and ensure the device is settled using the system-settle script" << does it really do this on CI ?
[15:47] <fginther> ogra_, that wold have been nice, but the work that was in progress had a lot of missing pieces and got shelved due to higher priority work
[15:47] <ogra_> ah
[15:48] <fginther> nerochiaro, yes, it reboots the device between each test suite (not test case in case that was your question)
[15:48] <ogra_> well, phablet-test-run is rather unmaintained since a while
[15:48] <plars> ogra_: also not everything has adt tests yet
[15:48] <ogra_> i thought pitti said he was done so far
[15:50] <plars> ogra_: adt-run worked fine last I tried it, but several projects didn't have tests that would work with it yet. But it's been a while since I looked at it
[15:50] <plars> ogra_: fairly important ones too, like unity8
[15:58] <sil2100> dbarth_: can I get these merges approved? :)
[15:58] <sil2100> dbarth_: https://code.launchpad.net/~daker/ubuntu-html5-theme/fix.1427729-1427909/+merge/251678 https://code.launchpad.net/~mardy/unity-webapps-qml/app-access/+merge/219321
[16:03] <nerochiaro> fginther: is the test runner script supposed to work even if we run it on a machine that has not been freshly provisioned with the provision script ? it blocks for me on "+ adb-shell sudo apt-get install -yq --force-yes python3-wand python3-mediainfodll"
[16:03] <nerochiaro> fginther: (i had these two packages already installed)
[16:04] <ogra_> nerochiaro, they make sudo NOPASSWD in their /etc/sudoers
[16:04] <ogra_> for the lab
[16:05] <ogra_> you would need the same i guess
[16:05] <nerochiaro> ogra_: so that wiki page is essentially lying ;)
[16:05] <ogra_> which wiki page ?
[16:05] <dbarth_> sil2100: yes
[16:06] <nerochiaro> ogra_: nevermind, bad joke. this one http://ubuntu-test-cases-touch.readthedocs.org/en/latest/
[16:06] <fginther> nerochiaro, I think ogra_ is right, the sudoers file gets setup by provision.sh, let me have alook
[16:06] <nerochiaro> fginther: i just checked, it is setup by provision
[16:07] <nerochiaro> fginther: i don't mind setting up my device once with it, but I would rather not have it wipe all the data. is it possible ?
[16:07] <fginther> nerochiaro, I think there is... provision.sh should honor an env that tells it to skip the actual flash
[16:07] <fginther> an env var
[16:07] <nerochiaro> fginther: i'll look into that, thanks
[16:08] <fginther> nerochiaro, nvm, I was thinking of a different script
[16:09] <nerochiaro> fginther: i think you can pass the arguments to ubuntu-device-flash as a parameter, so probably just omitting --wipe there will do. let me check
[16:10] <fginther> nerochiaro, be default is uses --bootstrap
[16:11] <fginther> nerochiaro, but you are right in that you can override the u-d-f options with $IMAGE_OPT
[16:14] <fginther> nerochiaro, I'll look into adding a 'skip ubuntu-device-flash' option for that script, sounds like it might be useful
[16:14] <nerochiaro> fginther: the wifi files are the NM wifi config files, right ? from /etc/NetworkManager/system-connections/
[16:14] <nerochiaro> fginther: agree
[16:15] <fginther> nerochiaro, yes, the nm config file is passed directly to phablet-network
[16:16] <ogra_> nerochiaro, you can use the -n option if you want to supply a different nm config
[16:16] <nerochiaro> ogra_: got that, it is running already
[16:16] <ogra_> cool
[16:18] <nerochiaro> ogra_: fginther: unfortunately it still needs to wipe, since we need to setup a password with --password and it is not supported without wiping for some reason
[16:18] <ogra_> you can just adb shell and call passwd
[16:19] <nerochiaro> ogra_: i think i will just comment out the call to u-d-f in the script. might as well do that than trying to convince it to run it with the right options
[16:20] <fginther> nerochiaro, also make sure you set the env var PHABLET_PASSWORD if you're not using the default
[16:21] <fginther> nerochiaro, by the way, thanks for test driving the how-to, it's been heavily revised this week :-)
[16:21] <mterry> fginther, I'm debugging a test failure that happens during a qmluitest run (but not during build), which is why I was curious about the hooks.  One thing that would be nice for investigating such things in the future is a logged call to "env" to dump the environment, right before running tests/building.  Just a thought
[16:22] <nerochiaro> fginther: my pleasure. thanks for helping me with this stuff. i find it fairly maddening when i go through it alone and weird errors pop up that I have to figure out on my own
[16:23] <nerochiaro> fginther: for example this one: bzr: ERROR: Requested revision: 'latest' does not exist in branch: bzr+ssh://bazaar.launchpad.net/+branch/camera-app/
[16:23] <fginther> nerochiaro, we're tying to polish this so that we can share it more widely. It helps to have someone involved who didn't help write it
[16:23] <nerochiaro> fginther: why is it even trying to do that ?
[16:24] <nerochiaro> fginther: can i point it to a local branch ?
[16:24] <fginther> phablet-click-test-setup will read the test branch location from the click manifest on the device
[16:25] <fginther> nerochiaro, there a section for overriding this with a local branch "Running Tests for a Modified Click Application"
[16:25] <fginther> nerochiaro, but it sounds like that won't work as the manifest is already pointing to something called "latest"
[16:26] <nerochiaro> fginther: wait, should i run the provision script from within the branch of the app i want to test ?
[16:26] <fginther> nerochiaro, no that won't help
[16:27] <sil2100> bzoltan_: did you fill in the bug :) ?
[16:27] <nerochiaro> fginther: so where is it getting the "latest" from ?
[16:27] <fginther> nerochiaro, what do you get when you run "adb shell click info <app-name>"
[16:28] <nerochiaro> fginther: where does it get <app-name> from in the first place ? I am not passing any app name to the provision script
[16:29] <fginther> nerochiaro, did you manually install a click app?
[16:29] <nerochiaro> fginther: yes
[16:30] <nerochiaro> fginther: does it detect that ?
[16:30] <fginther> nerochiaro, no it doesn't detect that, but phablet-click-test-setup consumes that information
[16:31] <fginther> the location of the test sources for what ever app you installed are defined in the manifest
[16:31] <nerochiaro> fginther: but i am not calling that. i am calling provision.sh, why would provision.sh branch camera-app ?
[16:31] <fginther> it's tryinig to provision the test sources for all installed click apps
[16:31] <nerochiaro> fginther: where is the manifest ?
[16:31] <nerochiaro> fginther: oh i see
[16:32] <nerochiaro> fginther: then it makes sense, since the manifest for camera-app will say "latest" as the version
[16:32] <fginther> you can manually skip that with export SKIP_CLICK=1
[16:32] <nerochiaro> doing that
[16:33] <nerochiaro> better add a note to the document about that
[16:33] <fginther> nerochiaro, that usually works, I don't really understand why the click app you have is using latest
[16:34] <fginther> nerochiaro, ah, I suspect the real revno gets injected when it's built before upload to the store
[16:34] <nerochiaro> i think that's the case
[16:40] <nerochiaro> greyback_: i just got this : 16:39:36.477 ERROR _launcher:206 - Timed out waiting for Application with app_id 'com.ubuntu.camera_camera_3.0.0.latest' to stop.
[16:40] <nerochiaro> greyback_: which i think means i managed to repro the bug
[16:40] <greyback_> nerochiaro: I'm not sure what prints that
[16:41] <greyback_> it's not a mir/qtmir message anyway
[16:42] <nerochiaro> greyback_: i think it is autopilot, but it is one of the messages we get when we encounter the bug from MIR
[16:42] <greyback_> nerochiaro: ok. Do you see a camera-app process running?
[16:43] <nerochiaro> greyback_: no it was gone
[16:43] <greyback_> nerochiaro: is there a "REJECTED" message in the unity8 log?
[16:43] <nerochiaro> let me check that
[16:44] <nerochiaro> greyback_: where do i find that log ?
[16:44] <greyback_> nerochiaro: ~/.cache/upstart/unity8.log
[16:44] <nerochiaro> greyback_: ApplicationManager REJECTED connection from app with pid 6080 as no desktop_file_hint specified
[16:45] <greyback_> nerochiaro: ok. What device and release are you using?
[16:46] <nerochiaro> greyback_: krillin/vivid
[16:46] <greyback_> nerochiaro: and did any of the previous AP test fail?
[16:46] <nerochiaro> greyback_: yes
[16:46] <greyback_> fail due to a crash?
[16:47] <popey> sil2100: meeting clash, so won't be at the landing meeting today, sorry.
[16:47] <sil2100> popey: ACK
[16:47] <greyback_> nerochiaro: output of the camera-app log file in that directory might give a clue maybe
[16:48] <greyback_> nerochiaro: could you confirm for me too, is the camera-app being launched by AP with a --desktop_file_hint switch?
[16:48] <nerochiaro> greyback_: no crash files for camera, so i guess not
[16:48] <nerochiaro> greyback_: i can't tell, but maybe fginther can confirm that ?
[16:51] <greyback_> nerochiaro: so qtmir is the one deciding to block your application. lp:qtmir:/src/modules/Unity/Application/applicationmanager.cpp:authorizeSession
[16:51] <greyback_> exactly why it's made that decision is the puzzle
[16:54] <nerochiaro> greyback_: if it was running the app without desktop file hint it would never be able to run
[16:54] <nerochiaro> greyback_: could it be that mir is not receiving the hint for some reason, and refuses the app ?
[16:54] <sil2100> robru, davmor2, rvr, ogra_: let's skip the meeting today
[16:54] <rvr> sil2100: Ack
[16:54] <greyback_> nerochiaro: the correct way would be for it to be launched by upstart-app-launch
[16:54] <robru> sil2100: let's skip the meeting every day ;-)
[16:55] <greyback_> nerochiaro: as that's using the same code path that users do
[16:55] <sil2100> robru: ssshh! That's the plan ;)
[16:55] <sil2100> But don't tell anyone
[16:55] <nerochiaro> greyback_: let me dive into what the script is doing
[16:56] <greyback_> nerochiaro: qtmir is getting the PID of the process, it opens the /proc/$PID/environ and reads the command line arguments listed there. It checks if desktop_file_hint is set, and opens and verifies the desktop file listed there
[16:57] <greyback_> nerochiaro: this only happens as a fallback when upstart-app-launch isn't used. It's not a good code path
[16:57] <fginther> nerochiaro, sorry, I had stepped away, but it looks like you found the answer?
[16:58] <nerochiaro> fginther: no, we are still trying to figure it out. does AP run the app via upstart-app-launch ?
[16:59] <fginther> nerochiaro, I think that's encoded in the autopilot tests themselves, hopefully this is obvious in the test sources
[16:59] <nerochiaro> fginther: sorry, are you sayign each AP test can choose how to run the app ?
[16:59] <ogra_> sil2100, fine with me
[17:00] <fginther> nerochiaro, I believe that's how it works, see: http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/view/head:/tests/autopilot/camera_app/tests/__init__.py
[17:00] <fginther> launch_test_installed is setting a hint file
[17:01] <nerochiaro> fginther: shouldn't it be launch_click_installed ?
[17:01] <nerochiaro> fginther: sorry, launch_click_package
[17:02] <nerochiaro> which is from autopilot.testcase.AutopilotTestCase
[17:02] <fginther> nerochiaro, that's a question that is outside of my expertise
[17:02] <nerochiaro> fginther: no problem. who should we ask to ?
[17:03] <fginther> nerochiaro, tedg perhaps?
[17:03] <fginther> nerochiaro, you also might try elopio or veebers
[17:03] <Ursinha> sil2100: are you around?
[17:03] <sil2100> Ursinha: hey! What's up?
[17:04] <Ursinha> sil2100: do you have time to join us in a discussion about smoke testing? :)
[17:04] <sil2100> Ursinha: I could drop by for a moment, but I could just give basic insight
[17:04] <Ursinha> sil2100: that's good enough
[17:06] <nerochiaro> greyback_: no problem, thanks for the help so far. i reprod using the CI scrips, so you migth want to go that way too
[17:06] <greyback_> nerochiaro: did you install python3 packages on the device until the CI scripts worked?
[17:07] <greyback_> http://pastebin.ubuntu.com/10538830/ is what I got just using ci scripts
[17:07] <nerochiaro> greyback_: yes, i installed python3-autopilot manually
[17:07] <greyback_> ok
[17:08] <greyback_> will do that so
[17:08] <greyback_> o/
[17:26] <popey> sil2100: & davmor2 Advanced warning, tomorrow morning during the landing call I will request a re-test of reminders - not ready yet, but should be by tomorrow.
[17:28] <sil2100> popey: \o/
[17:28] <sil2100> Wohooo!
[17:41] <sil2100> bzoltan_: ping
[18:17] <nerochiaro> elopio: do you know if it is possible to call methods via AP or if we can just manipulate properties ?
[18:17] <elopio> nerochiaro: it is possible, but discouraged and it's in a file that might get deleted with AP.
[18:17] <nerochiaro> elopio: i don't understand
[18:18] <nerochiaro> elopio: what file do you mean ?
[18:18] <elopio> nerochiaro: generally, when you need something that's not exposed through the user interface, it means that your UI is missing something, or you shouldn't be writing an autopilot test.
[18:18] <elopio> nerochiaro: so we have been thinking about removing autopilot code to inspect beyond properties.
[18:19] <elopio> nerochiaro: what's your problem? maybe we can find an alternative.
[18:19] <nerochiaro> elopio: when setting up a test I need to add something to a model
[18:19] <nerochiaro> elopio: and the way to do it apparently is by calling a method on it
[18:21] <elopio> nerochiaro: I need a bigger picture. What are you trying to set up?
[18:34] <nerochiaro> elopio: in camera app we need to add photo files to the pictures model during a test, so that we can check that the UI element indicating there are no pictures in the photo roll disappears
[18:35] <elopio> nerochiaro: in a user acceptance test, you should do that by putting a file to the pictures directory.
[18:36] <elopio> if you want to test it at a lower level than that, you should do it with qmltestrunner, and then you can hardcode your model.
[18:37] <elopio> nerochiaro: with your quick explanation, I would prefer to make this as a qml test. I might be missing some details though.
[18:37] <elopio> is there a reason why you want to make it with autopilot?
[18:40] <nerochiaro> elopio: i am discussing it with Kaleo, it might even be I am testing something that I really shouldn't. thanks for the advice so far
[18:42] <elopio> nerochiaro: well, it does sound that an automated test is needed :) Please don't land it without tests, but feel free to chose to test it at the level that you consider correct.
[18:43] <elopio> nerochiaro: if you need something else, please go to #ubuntu-quality and ping whoever is mentioned in the topic.
[18:48] <nerochiaro> elopio: thanks
[18:49] <rsalveti> sil2100: robru: should we stop doing daily builds for RTM?
[18:49] <rsalveti> as we don't expect to have many landings anymore
[18:49] <sil2100> rsalveti: hm, we could basically
[18:49] <robru> rsalveti: makes sense, landings have greatly slowed.
[18:50] <sil2100> rsalveti: since we're only waiting for 1-2 more fixes anyway
[18:50] <rsalveti> exactly
[18:50] <sil2100> +1 :)
[18:50] <rsalveti> will disable in cron then
[18:50] <sil2100> Thanks!
[18:50] <rsalveti> don't want qa spending time on something that didn't really change
[18:51] <rsalveti> done
[19:06] <popey> rsalveti: what about store uploaded click packages?
[19:07] <popey> rsalveti: we'll have to spin new images just for those?
[19:15] <rsalveti> popey: depends on which click packages
[19:15] <rsalveti> the pre-installed in the images or the ones provided by custom?
[19:16] <rsalveti> popey: do you think there is a way to coordinate these landings with the image build process?
[19:16] <popey> I dont know how they're installed, but calculator, reminders, clock...
[19:16] <popey> I'll have a chat to sil2100 tomorrow.
[19:16] <popey> at the landing meeting, form a plan
[19:16] <rsalveti> right, those a provided by the rootfs indeed
[19:17] <rsalveti> popey: yeah, just to avoid having QA to spend hours testing something that didn't really change
[19:17] <rsalveti> we don't have a way yet to check for differences before building an image
[19:18] <rsalveti> popey: thanks for following this up with sil
[19:18] <rsalveti> let me know if you want the daily build back and I can re-enable anytime
[19:18] <popey> ok
[19:18] <popey> we dont need it that often
[19:19] <popey> but I know we have a few coming soon, and want to make sure people will get them.
[19:19] <popey> technically users will get it via the store of course.
[19:19] <cjwatson> nothing stopping somebody requesting a manual build for those of course
[19:20] <popey> true.
[19:21] <rsalveti> yeah
[19:45] <dobey> trainguards: who can do a packaging change ack? has to be release team now?
[19:45] <robru> dobey: core devs
[19:46] <dobey> robru: are you a coredev?
[19:46] <Laney> Depends on the package - anyone who can upload it
[19:46] <Laney> MOTU for universe stuff
[19:47] <dobey> silo 24 needs a packaging ack (new python module package added). it's unity-scopes-shell which i think is still in universe
[19:48] <robru> dobey: no I am no, sorry. I usually lean on mterry or kenvandine for that kind of stuff at this time of day
[19:50] <dobey> kenvandine: ^^ can you package ack silo 24? :)
[20:45] <kenvandine> dobey, i'll look
[20:46] <robru> brb, lunch
[20:54] <dobey> kenvandine: thanks
[20:57] <kenvandine> dobey, so adding new binaries, you should really get an archive admin to look at it
[20:57] <kenvandine> for a preNEW review
[20:57] <dobey> that's what i was wondering
[20:58] <dobey> slangasek: ^^ would you mind doing the package ack for silo 24 as it has a new bin pkg?
[21:11] <robru> dobey: ah you didn't mention there was a new binary package when you first asked me who can ack
[21:16] <dobey> ah. there's another silo waiting for qa signoff, which has a new binary package too. hopefully we can get them in quickly, as we need them to enable more testing in other packages
[21:24] <bregma> cihelp vanguard, we frequently get Unity 7 build fails due to timeout on amd64 in CI Jenkins although 4 hours should be more than enough for that, would this be a vanguard-level issue or should I just add it to our wishlist for the QA backlog?
[21:26] <fginther> bregma, vanguard is appropriate
[21:26] <fginther> bregma, I'll take a look
[21:48] <fginther> bregma, it looks like the default memory size for the amd64 build was just a bit too small and was causing swapping during the build. I've moved the both amd64 and i386 builds to a build on larger nodes. so far it looks much happier
[21:48] <fginther> er, the "default node memory size"
[21:48] <bregma> fginther, thanks, we'll see how that pans out in the next few MPs
[21:49]  * bregma cracks the whip on the team
[21:51] <rsalveti> kenvandine: we got 2 system settings landings for rtm
[21:51] <rsalveti> kenvandine: just need to make sure we're in sync with QA here :-)
[21:51] <kenvandine> rsalveti, yeah...
[21:52] <rsalveti> love to see bug 1414762 getting fixed
[21:52] <rsalveti> hate this so much
[21:52] <kenvandine> just make sure there's a rebuild after the first one publishes
[21:52] <rsalveti> yeah
[22:26] <elopio> cihelp: the vms that run dep8 tests in the archive are qemu. Could we use something like kvm/qxl, so we can use mir during dep8 tests, or do we have to make mir work in qemu?
[22:26] <fginther> mterry, I finally opened a report for the unlock problem I mentioned earlier today: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1428875
[22:27] <fginther> elopio, are you specifically asking about the proposed-migration tests such as http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-qtmir/ ?
[22:29] <fginther> elopio, if so, work is in progress this sprint to move that testing to nova kvm instances
[22:30] <elopio> fginther: I'm talking in general. I want to write a dep8 test for the dialer app that launches the messaging app. That requires mir running, and they tell me that mir requires qxl.
[22:30] <elopio> so I don't know what to request, for mir to not require kvm+qxl, or for the tests to not be run on qemu.
[22:31] <mterry> fginther, that does seem like just a more frequent version of bug 1428875, yeah
[22:31] <mterry> fginther, er..  I mean bug 1421009
[22:32] <fginther> elopio, one moment, pondering this for a moment
[22:33] <fginther> mterry, thanks for taking a look at that
[22:34] <mterry> fginther, I'm still not sure even where to start.  Seems like there's a whole collection of similar dbus freeze bugs
[22:36] <fginther> elopio, it sounds like the best route is to make sure the test is restricted to only run on a testbed that can adequately run mir as is. If a nova kvm instance works for this, then you're in luck.
[22:37] <fginther> elopio, but I have no idea what qxl is, googling
[22:37] <slangasek> dobey: having a look at ubuntu silo 024 now
[22:38] <slangasek> I thought we'd fixed the problem of silo packages bypassing NEW? am I misremembering?
[22:40] <fginther> elopio, hmm. I think this requires more investigation to understand what is needed and if the current path is going to work. I'm not familiar with how graphics operate on these nova kvms.
[22:41] <mterry> fginther, I put a birds-eye-view comment on bug 1428875, but I'm EOD and off tomorrow -- you might want to poke kgunn to get someone else to look at this shorter term (and I'm guessing kgunn will probably re-assign to someone lower in the stack)
[22:42] <mterry> fginther, actually, let me assign to kgunn myself and leave a comment
[22:42] <fginther> elopio, I'll create a placeholder story for this for now.
[22:42] <fginther> mterry, thanks
[23:04] <slangasek> dobey: I have objections to some of the packaging changes on this silo; how do you want these submitted?
[23:05] <slangasek> dobey, robru: (i.e., this is a nack of the package as currently uploaded)
[23:05] <robru> slangasek: no worries on my end.
[23:06] <robru> slangasek: oh, in terms of bypassing NEW, what we fixed was diffs failing to be generated causing packaging changes to fly through unreviewed. as far as I know train uploads have always bypassed NEW.
[23:07] <tedg> robru, Can you publish silo 18 please?
[23:07] <slangasek> robru: well, when I say "we" I mean "launchpad", since it was a bug on the LP side that they went through without review
[23:07]  * tedg doesn't have packaging changes
[23:07] <tedg> Well, in this silo.
[23:07] <robru> slangasek: ah no idea
[23:07] <slangasek> wgrant: ^^ any chance you can refresh my memory on where we stand on that bugfix (silos bypassing binary NEW)?
[23:08] <robru> tedg: done
[23:08] <tedg> robru, Awesome, thanks!
[23:08] <robru> tedg: you're welcome
[23:10] <wgrant> slangasek: Bypassing binary NEW is fairly easily fixed, actually being able to be overridden before acceptance is a good bit harder.
[23:10] <slangasek> wgrant: so the binary-new-bypass bug is still outstanding, then - ok, thanks
[23:12] <wgrant> slangasek: Yep, but my derived distro rewrites of all that code make the actual skipping bit very easy to fix.
[23:12] <wgrant> slangasek: https://bugs.launchpad.net/launchpad/+bug/993120
[23:13] <robru> wgrant: cool, would be nice to fix
[23:13] <slangasek> wgrant: yep well maybe one of these days it'll be a priority to put it into the launchpad backlog... but not before ddebs ;)
[23:13] <wgrant> slangasek, infinity: Well, you should put it in your priorities on the wikipage. They're an ordered list after all.
[23:14] <wgrant> And this is fixable without the rest of the larger redesign that Adam already listed.
[23:16] <slangasek> infinity: ^^ yeah, let's go ahead and put bug #993120 on the list (at the bottom)
[23:17] <slangasek> dobey: fwiw the biggest blocker on this package is the lack of .symbols files for the library, which I believe is a standard requirement for all libraries that go through the train.  I won't sign off on a library package coming through the train that doesn't have ABI checking at the packaging level