[09:01] <Mirv> ok, now everything should be properly compiled, I can start device testing + try to get also unity8 stack cu2d tests to run
[09:08] <didrocks> Mirv: excellent! :)
[09:08] <didrocks> still not sil2100. I'm starting to be worry
[09:10]  * didrocks sent a mup sms
[09:31] <didrocks> popey: joining?
[09:31] <popey> is that the time!
[09:31] <popey> sorry
[09:31] <didrocks> it definitively is :)
[09:37] <popey> bug 1262607 really is quite annoying
[09:46] <Mirv> ok finally I have the right bugs bookmarked..
[10:54] <ogra_> didrocks, do we know if the proposed Mir branch will have the fix for bug 1258056 ? else i have to postpone the nested Mir migration for the session stuff
[10:54] <didrocks> ogra_: I know there are something for nested Mir
[10:55] <ogra_> ah, great
[10:55] <ogra_> it is really annoying that these bugs have no distro task at all so one can see if it landed in the archive or not
[10:56] <didrocks> ogra_: I just bzr branch lp:mir, bzr merge that associated branch and:
[10:56] <didrocks> Nothing to do.
[10:56] <didrocks> so it will be there
[10:56] <ogra_> great
[10:56] <didrocks> ogra_: if it landed in the archive and is associated to a branch, it should have a distro task
[10:56] <didrocks> cu2d opens it to track
[10:56] <didrocks> so it's not in yet :)
[10:56] <ogra_> took 30min of my workday to dig through several different branches where a simple bug task would just have told me
[10:57] <didrocks> well, talk to upstream ;)
[10:57] <ogra_> yeah, i guess i should
[11:05] <psivaa> ogra_: didrocks: reverting apport and whoopsie-preferences did not help make the mako connected tests pass.
[11:05] <psivaa> but i am having trouble reverting lxc-android-config
[11:05] <ogra_> what is the issue ?
[11:05] <psivaa> getting 'unable to make backup link of `./lib/udev/rules.d/70-android.rules' before installing new version: Invalid cross-device link' when installing the previous version of that
[11:06] <ogra_> aww
[11:06] <ogra_> yeah, that wont work then, dpkg uses hardlinks ... hardlinks dont work across partition boundaries iirc
[11:06] <ogra_> you should be able to manually hack the files it changed though
[11:06] <psivaa> ogra_: http://pastebin.ubuntu.com/6714223/ for more info..
[11:06] <ogra_> without reverting the package
[11:07] <psivaa> ok, i'll try that then. thanks
[11:08] <ogra_> http://launchpadlibrarian.net/161740340/lxc-android-config_0.125_0.126.diff.gz
[11:08] <ogra_> /etc/system-image/writable-paths
[11:13] <cjwatson> hard links> yes, this is another reason why attempting to make individual files writable is fundamentally doomed
[11:13] <cjwatson> this *has* to be done at the directory level only
[11:47] <psivaa> ogra_: didrocks: reverting lxc-android-config does not help either.. i am now installing on a different mako to see if there is any improvement
[11:48] <didrocks> psivaa: yeah, and meanwhile I would suggest as well trying to flash the failing mako with the previous image as well
[11:48] <ogra_> well, apport was only a straw ... since the changelogs didnt show anything else that could be at fault
[11:48] <ogra_> was there an android change ?
[11:48] <ogra_> iirc the last upload didnt make it out of proposed (at least when i looked last night)
[11:49] <didrocks> ogra_: the android change AFAIK was in 117
[11:49] <ogra_> i thought it was still sitting in proposed
[11:49] <didrocks> 116:20140107:20131223.2
[11:49] <didrocks> 117:20140107.1:20140107.1
[11:50] <didrocks>          ^ it's the last bug, right?
[11:50] <didrocks> bit*
[11:50] <didrocks> :20140107.1
[11:50] <ogra_> https://launchpad.net/ubuntu/trusty/+source/android/20131202-2236-0ubuntu7
[11:50] <ogra_> sigh
[11:50] <ogra_> i wish these numbers would be connected in any way
[11:50] <ogra_> but yeah, looks like it has the new android
[11:51] <didrocks> ok, so it's not part of what failed on 117
[11:52] <Mirv> Saviq: didrocks: it currently looks like I'm getting a crash with Unity8 with the new Mir 0.1.3 repeatedly when running phablet-test-run -n unity8. backtraced it https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1267065
[11:52] <didrocks> kgunn: as well, FYI ^
[11:52] <didrocks> Mirv: ok, concentrate on the other landings then
[11:53] <Saviq> Mirv, can you attach your unity8.log please?
[11:53] <Mirv> didrocks: I mostly concentrate on Qt but I try to get powerd also on the side
[11:53] <didrocks> Mirv: would be nice to have powerd released today
[11:53] <Mirv> Saviq: isn't the upstart log there automatically already?
[11:54] <Mirv> Saviq: the threadstack trace mentions Mir in there
[11:54] <Mirv> didrocks: ok, I'll update on it later
[11:54] <didrocks> thx!
[11:54] <Saviq> Mirv, it is, sorry
[11:55] <Saviq> Mirv, did you keep your screen on?
[11:55] <Saviq>   what():  could not activate surface with eglMakeCurrent
[11:55] <Saviq> greyback, that's↑happening when display is off, right?
[11:56] <greyback> Saviq: yes. I think if screen off, you start unity8, then try to turn on screen, that happens too
[11:57] <Saviq> Mirv, it's best if you go "powerd-cli display on bright" when running the test suites
[11:57]  * Saviq tries
[11:57] <Mirv> Saviq: just screen on & unlocked + phablet-test-run -n unity8. of course eventually the screen is black, I guess after the crash and when the rest of the tests then fail.
[11:57] <Saviq> Mirv, yeah, but that crash is a result, not the cause
[11:58]  * Saviq tests
[12:02] <Saviq> Mirv, basically what happens: unity8 gets stopped, but takes a long time to exit (that's something we still need to investigate - either it's a crash and apport collects data or it's just unity8 taking a long time to exit)
[12:02] <Saviq> Mirv, long enough that screen suspends
[12:03] <Saviq> Mirv, subsequent tests crash due to screen being off - and that's the .crash file you got
[12:20] <Mirv> Saviq: I guess a crash is something that shouldn't happen anyhow, but yes thanks for the powerd-cli tip I'll add it to my testing plan. currently testing powerd from a clean slate + trying to get that %=!"$ qtdeclarative snapshot problem understood.
[12:20] <Saviq> Mirv, of course, unity8/mir should start fine with screen off, that's a known bug
[12:21] <Saviq> and it has a nice round number - bug #1235000
[12:39] <Saviq> Mirv, yeah, 25 unity8 tests passed with screen on
[12:39] <Saviq> and no crash
[12:42]  * kgunn is doing morning house duties but reading scrollback on mir testing
[12:50] <Mirv> didrocks: packaging ack http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_powerd_0.13+14.04.20140108.1-0ubuntu1.diff
[12:51] <Mirv> Saviq: I didn't need that last year, but yes I could retest after reflashing, I just fear I don't have time to run all tests today anymore but I should be able to upgrade Mir again and run unity8 at least
[12:52] <Mirv> Saviq: that = powerd-cli
[12:52] <didrocks> Mirv: +1
[12:54] <Mirv> thanks
[12:57] <Saviq> Mirv, that's because we (upstart) killed unity8 after 5s before - no time for screen to suspend
[12:57] <Saviq> Mirv, i.e. bug #1260379
[12:57] <Saviq> Mirv, but also bug #1262879
[12:58] <Saviq> Mirv, i.e. smoke testing keeps the screen on throughout the whole suite
[12:59] <xnox> Saviq: one can raise kill timouts on per job basis.
[13:00] <xnox> (or via .override file during tests)
[13:00] <Saviq> xnox, that is per-job
[13:00] <Saviq> xnox, https://code.launchpad.net/~nicolas-doffay/unity8/upstart-kill-fix/+merge/198931
[13:01] <xnox> cool =)
[13:01] <xnox> Saviq: why not simply adjust the stock unity8.conf, if you are changing that by default anyway.
[13:03] <xnox> Saviq: since that .override will not be used btw in the default testing, since a different .override is dropped in the user directory. And upstart only applies "one best .override" on top of "one best .conf"
[13:03] <Saviq> xnox, we don't want people actually *using* the phone to have to wait 30s
[13:04] <Saviq> xnox, what "different .override"?
[13:06] <xnox> Saviq: but that's  what you did anyway =)
[13:06] <xnox> Saviq: so user-session jobs are loaded from: ~/.config/upstart/ , $XDG_CONFIG_DIRS/upstart, /usr/share/upstart/session/. Whichever first one is found.
[13:07] <xnox> Saviq: then a second pass is searched in all the same locations for $name.override, and is applied on top.
[13:08] <xnox> Saviq: so a default install, at the moment, will have /usr/share/upstart/session/unity8.conf and /usr/share/upstart/session/unity8.override, which are merged together in memory and then the job is started with _all_ those parameters.
[13:08] <xnox> Saviq: so your change did make 30s timeout across the board, always.
[13:09] <Saviq> xnox, we only install it with the unity8-autopilot package
[13:09] <xnox> Saviq: if you look into lp:ubuntu-test-cases/touch however, it drops an unity8 overrides to start unity in testability mode. Since, as far as I remember, it uses .override file and thus overrides the global one you created.
[13:09] <xnox> Saviq: and unity8-autopilot is not on the default image?
[13:09] <Saviq> xnox, nope
[13:11] <Saviq> xnox, I didn't know about the other override, that should include the kill timeout change, too, then
[13:11] <Saviq> let me mention bug #1262879 again...
[13:11] <xnox> Saviq: let me first find for sure where it is.
[13:12] <xnox> Saviq: utils/target/unlock_screen.py:    os.system('echo "exec unity8 -testability" > ~/.config/upstart/unity8.override')
[13:13] <xnox> Saviq: in lp:ubuntu-test-cases/touch
[13:13] <xnox> Saviq: I think it's best for lp:unity8 to add "exec unity8 -testability" to unity8.override (now that you are shipping an override file) and drop unity8.override from any/all test-harnesses.
[13:14] <xnox> Saviq: is -testability actually at all needed / supported these days?
[13:15] <xnox> Saviq: i get a lot of:
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'e'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 's'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'a'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'b'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'i'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'l'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'i'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 't'
[13:15] <xnox> /usr/bin/system-settings: invalid option -- 'y'
[13:15] <xnox> and then "Testability driver loaded"
[13:15] <ogra_> xnox, pastebinit !
[13:15] <ogra_> (and thats normal)
[13:15] <xnox> ogra_: why is that normal to specify option, which doesn't exist?
[13:16] <ogra_> i mean the output is
[13:17] <xnox> ogra_: no that is not normal, to self-induce invalid  / obsolete options. Just wait for qmlscene or any app use one of those single letter options and explode.
[13:17] <ogra_> xnox, it is in all test logs since day one like that
[13:17] <ogra_> which makes it a "normal" output for me since it does not affect anything
[13:18] <ogra_> (i agree it is crap, but it shouldnt cause any issues, all test logs have it since forever)
[13:19] <Saviq> xnox, the preferred way is to export QT_LOAD_TESTABILITY=1
[13:33] <Mirv> didrocks: Saviq: kgunn: ok I've resumed Mir 0.1.3 testing with Saviq's tip and everything seems ok so far. I look if I get the remaining tests done and/or update the chart for others to continue from where I left off.
[13:33] <Saviq> Mirv, thanks!
[13:35] <didrocks> excellent!
[13:41] <balloons> cprov, can you look at why this is failing to autoland? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906. We had to re-run yesterday before it would work, but I'm not sure why
[13:41] <cprov> balloons: will do
[13:49] <cjohnston> balloons: it has failing tests
[13:49] <cprov> balloons: testing are failling
[13:49] <fginther> morning
[13:50] <balloons> cjohnston, cprov I see that, but tim was thinking something wasn't right.. And nothing has changed since yesterday. Anyways, I'll send it back to him, thanks
[13:52] <Mirv> didrocks: in case all fine, could you pre-ack packaging changes? http://www.multiurl.com/l/gHX (couldn't find better for clickable links)
[13:52] <Mirv> I see dialer-app and messaging-app are also broken in image 118, which is "good" in the sense that the failures I saw were not from Mir
[13:53] <Mirv> (image 118 test results)
[13:56] <timp> cprov: hello
[13:56] <timp> cprov: I understand you were talking to balloons about https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/ ?
[13:56] <cprov> balloons: we found a problem in the testing env, apparently qmlscene crashed
[13:56] <timp> epaste, I mean this one: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/
[13:56] <balloons> cprov, :-p
[13:56] <balloons> gl
[13:56] <cprov> hi timp
[13:56] <ogra_> cprov, !!!
[13:56] <timp> cprov: ah. I guessed something like that :) all tests failed on a missing dbus
[13:57]  * ogra_ hugs cprov 
[13:57] <cprov> ogra_: hey hey, good to see you again!
[13:57] <ogra_> yeah, same :)
[13:57] <cprov> timp, balloons: bear with me while the experts look at a solution.
[13:58] <timp> cprov: sure, thanks
[14:07] <cprov> timp: do you remember a similar problem in the past ? related, possibly, to a Mir regression ?
[14:08] <timp> cprov: I remember that we had this problem a lot in the past
[14:08] <timp> let me think if I remember what caused it; may be mir-related
[14:08] <cprov> timp: right, fginther is investigating it
[14:08] <timp> cprov: perhaps the screen was not activated?
[14:09] <timp> kalikiana_: ^ do you remember what was causing this kind of failures for us? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/
[14:09] <fginther> cprov, timp here's the bug I was thinking of: https://bugs.launchpad.net/qtubuntu/+bug/1243665
[14:09] <timp> elopio_: ^ perhaps you worked on these kind of failures? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/testReport/junit/ubuntuuitoolkit.tests.test_emulators/TabsTestCase/test_swith_to_tab_by_index_out_of_range/
[14:10] <psivaa> didrocks: ogra_: "base-passwd from 3.5.29 to 3.5.30" appears to be the reason for the mako connected test failures
[14:11] <timp> fginther: I'm not sure. I saw the failures a lot and if I recall correctly they were happening at random. But I didn't investigate it further. I guess that was kalikiana_ or elopio_ , or someone in the CI team
[14:11] <cjwatson> psivaa: *perks up*
[14:11] <cjwatson> psivaa: log?
[14:11] <fginther> timp, my IRC logs show that I was discussing this with kalikiana_ last month
[14:11] <kalikiana_> timp: yes I think this is the qubuntu bug. the error is in the logs before the python error
[14:12] <ogra_> psivaa, wow
[14:12] <ogra_> thats curious
[14:12] <cjwatson> ogra_: it was a fairly substantial change
[14:12] <psivaa> cjwatson: i dont have specific logs.. but reverting that make the test pass
[14:12] <cjwatson> though this is the first problem I've heard of from it and I've been watching
[14:12] <timp> kalikiana_: so the bug came back today..
[14:12] <cjwatson> psivaa: I'm going to need some kind of log of the failure
[14:13] <psivaa> cjwatson: i know it wont be helpful but it's http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-messaging-app-autopilot/15/console vs http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-messaging-app-autopilot/16/console
[14:13] <psivaa> but let me check if there is anything in the auth.log
[14:13] <fginther> kalikiana_, timp any idea why it's still showing up? has it not been fixed?
[14:15] <kalikiana_> timp: fginther I recall it was "fixed" when fginther and I were looking at it and https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1262982 is still open because only part of the problem was addressed
[14:16] <cjwatson> right, so assuming base-passwd was upgraded successfully, the difference is that a bunch of system users that never should have had valid login shells (a long-standing security issue) now really don't have valid login shells
[14:16] <kalikiana_> greyback was offering to try to reproduce, that's the last I remember
[14:19]  * cprov leaves for a quick lunch and will brb
[14:19] <cjwatson> psivaa: auth.log might well be helpful, indeed
[14:19] <greyback> kalikiana_: could you log a bug with unity-mir, giving me steps to try to reproduce it? Just for my records (as I forgot about this)
[14:19] <greyback> timp: ^^
[14:20] <timp> greyback: I don't know how to reproduce it, I only saw the failing tests in an MR that I was reviewing
[14:21] <fginther> greyback, we have another qmlscene crash here: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/
[14:21] <timp> fginther: do you know if it is an existing bug or do we need a new one?
[14:21] <greyback> fginther: the output from unity8 in those cases is valuable. Is it possible to get that?
[14:22] <greyback> as unity8 usually will say why it rejects the connections in it's own logs
[14:22] <timp> greyback: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/artifact/results/log/unity8.log ?
[14:22] <kalikiana_> greyback: this is there https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1262982
[14:22] <fginther> timp, I don't know if this relates to the prior bug, could someone trace the crash file?
[14:23] <fginther> (someon who might know what to look for :-) )
[14:24] <timp> fginther: I don't know what you mean with that. Is there some specific log file that jenkins gives us that someone needs to have a look at?
[14:24] <fginther> timp, the qmlscene crash file
[14:24] <greyback> kalikiana_: ah, thanks
[14:24] <fginther> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4469/artifact/results/crash/_usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash
[14:24] <fginther> there's also a unity8 crash
[14:25] <timp> fginther: that's a job for someone in the unity8 or mir team?
[14:25] <timp> fginther: I'm looking at it but it doesn't mean much to me
[14:26] <greyback> timp: there's no "REJECTED" error messages, meaning unity8 isn't explicitly rejecting any applications, so that's not the cause of the crash
[14:26] <greyback> timp: but that log has lots of unity8/mir crashes, which doesn't look right not me at all
[14:26] <greyback> s/not/to/
[14:27] <greyback> fginther: for that case, I'm suspecting a mir failure causing clients to crash
[14:28] <greyback> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
[14:28] <greyback>   what():  compositor_acquire would block; probably too many clients.
[14:28] <greyback> never seen that before anyway. Will need Mir team help
[14:30] <fginther> greyback or timp, can you file a bug if one doesn't already exist?
[14:34] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715060/ is the auth.log with v30
[14:34] <psivaa> http://pastebin.ubuntu.com/6715062/ is with v29 (passing one)
[14:35] <cjwatson> ok, so what's trying to su to nobody?
[14:35] <timp> greyback: ^ can you report the bug if needed? I don't really know what's going on
[14:35] <kalikiana_> but there is a bug…
[14:36] <cjwatson> psivaa: where would I find the top-level test scripts being run here?
[14:37] <greyback> timp: I'm extending that bug
[14:37] <timp> kalikiana_: that's why I said "if needed" :)
[14:37] <timp> greyback: ok, thanks
[14:38] <psivaa> cjwatson: http://bazaar.launchpad.net/~phablet-team/messaging-app/trunk/view/head:/tests/autopilot/messaging_app/tests/test_messaging.py contains the tests
[14:39] <cjwatson> hm, that's not the cause ...
[14:40] <cjwatson> could be utah, but utah seems to use sudo to get at the "nobody" user and sudo apparently doesn't care that the target user doesn't have a login shell
[14:40] <psivaa> cjwatson: utah is not involved here
[14:41] <psivaa> hmm probably it does.. not sure :)
[14:42] <cjwatson> psivaa: where does generic-mediumtests-runner-mako live
[14:42] <cjwatson> ?
[14:43] <psivaa> cjwatson: http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-runner-mako/
[14:43] <cjwatson> psivaa: I mean the code
[14:43] <cjwatson> the actual test runner itself
[14:44] <greyback> fginther: timp can either of you tell me, is unity8 restarted for each and every test?
[14:45] <psivaa> cjwatson: http://bazaar.launchpad.net/~canonical-ci-engineering/jenkins-launchpad-plugin/autopilot-testrunner-touch-saucy/files
[14:45] <psivaa> i think that's where it is. and if that's what you're looking for :)
[14:49] <cjwatson> psivaa: maybe ... it would be useful if you happened to have a jenkins console log that matches your auth.log dump, so that I can compare timestamps usefully between them
[14:49] <cjwatson> I'm flailing
[14:50] <cjwatson> I guess I know it comes before the unlock_screen.py call in run_all_autopilot.sh
[14:52]  * cjwatson tries grepping his oldish emulator tree
[14:54] <dobey> didrocks: https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736
[14:55] <didrocks> dobey: did you try it with SRU mode, dest ppa and so on?
[14:55] <didrocks> (I don't see tests for those cases)
[14:57] <dobey> didrocks: didn't know there were extra tests for those. i can add them if they are necessary. what is "SRU mode" though?
[14:57] <didrocks> dobey: there is a dest ppa but it's not reflected in versioning (the +series is different, that's it)
[14:58] <didrocks> dobey: should be transparent for you, just look at the test cases, I'm sure there is one for dest ppa at least, not sure for SRU mode (there is none if it's transparent to it)
[14:58] <cjwatson> psivaa: or failing that, perhaps I could have a tarball of all of /var/log/ ?  Ideally from the failing case, but the successful case would be better than nothing
[14:59] <dobey> didrocks: ok
[14:59] <cjwatson> I've grepped all the source I can think of and can't find this su call
[15:00] <didrocks> dobey: with that, I'm happy to approve your merge, will count on you to support it if further issues are involved though :)
[15:00] <psivaa> cjwatson: just a reboot prints this in auth.log without any tests being run.
[15:00] <psivaa> http://pastebin.ubuntu.com/6715183/
[15:00] <didrocks> (I still don't like we are introducing inconsistencies but if some upstream are puzzled about the packaging, they will talk to you I guess)
[15:00] <psivaa> but i'll get the tarball
[15:00] <cjwatson> psivaa: ok, that usefully rules out a bunch of stuff
[15:01] <didrocks> dobey: I guess you need to test for a second release the same day as well
[15:01] <dobey> didrocks: ok
[15:01] <rsalveti> didrocks: Saviq: not sure if a regression, just moved bug 1267076 to unity8
[15:02] <didrocks> rsalveti: oh indeed, not sure either. Will try to flash an older one
[15:02] <didrocks> Saviq: tell us if you have any idea
[15:04] <didrocks> psivaa: cjwatson: what do you think about, if we can't find the reason (which is probably in the testing tool with invalid usage) in 1 or 2 hours to revert the change and take some quiet time to continue the investigation? Does it makes sense Colin?
[15:05] <Saviq> didrocks, not a regression
[15:06] <Saviq> didrocks, bug #1240408
[15:06] <didrocks> Saviq: I never had enough music icons to create the carroussel. I should add more I guess :)
[15:06] <didrocks> ok, thanks Saviq, rsalveti ^
[15:06] <Saviq> didrocks, yeah I know
[15:06] <didrocks> Saviq: I'll let you dupe it?
[15:06] <Saviq> didrocks, already done
[15:06] <didrocks> sooo quick :)
[15:08] <fginther> greyback, unity8 is restarted and the phone is rebooted between test suites, but not between individual test cases
[15:10] <rsalveti> awesome, thanks!
[15:10] <greyback> fginther: thanks for the clarification.
[15:13] <psivaa> cjwatson: just sent an email with the logs
[15:18] <psivaa> cjwatson: also, http://ci.ubuntu.com/smokeng/trusty/touch/mako/118:20140108:20140107.1/5941/messaging-app-autopilot/ has some logs attached at the bottom
[15:19] <cjwatson> didrocks: ETA 20min to upgrade my device to a vaguely recent devel, after which I should stand a better chance
[15:19] <cjwatson> psivaa: thanks
[15:20] <didrocks> thanks, keep us posted
[15:21]  * ogra_ finds the discovery that we have anything su'ing to nobody worrying enough :)
[15:22] <didrocks> ogra_: nobody isn't a friend of yours? :)
[15:22] <cjwatson> ogra_: quite
[15:22] <ogra_> didrocks, i dont like perfect people ... :P
[15:22] <cjwatson> the trivial workaround is to pass "-s /bin/sh" to su, once we find the call
[15:23] <didrocks> ahah
[15:23] <cjwatson> assuming we don't find that it's better to use a different user
[15:23] <ogra_> yeah, i would prefer the latter
[15:23] <cjwatson> well
[15:23] <cjwatson> running things as nobody isn't necessarily wrong - what would be wrong is if it ended up using any files
[15:23] <cjwatson> but we'll see
[15:23] <cjwatson> sorry, I mean owning any files
[15:24] <ogra_> yeah
[15:24] <cjwatson> hopefully it's reproducible on grouper
[15:29] <psivaa> cjwatson: assume you are not running the test to reproduce the issue. phonesim is needed to run that particular failing test
[15:33] <cjwatson> psivaa: no need since you established that the su call is visible on a simple reboot
[15:34] <psivaa> cjwatson: ack, confirmed that again
[15:50] <cjwatson> bah, there's no indication of that su call in auth.log on grouper
[15:50]  * cjwatson tries devel-proposed
[15:50] <ogra_> on what device do you see that su call ?
[15:51] <cjwatson> ogra_: mako
[15:51] <cjwatson> (apparently)
[15:51] <cjwatson> ogra_: can you see if you have it?
[15:51] <ogra_> maguros pvrsrv thing that runs on the android side does weird stuff to get the graphics driver up ...
[15:51] <ogra_> ah, mako, k
[15:51] <cjwatson> this doesn't look like android-side
[15:51] <ogra_> right
[15:51] <cjwatson> if it were, it surely wouldn't have been affected by a base-passwd change
[15:52] <ogra_> root@ubuntu-phablet:/# grep su /var/log/auth.log
[15:52] <ogra_> root@ubuntu-phablet:/#
[15:52] <ogra_> thats my mako, recent promoted image, upgraded today
[15:53] <ogra_> (note my mako is my actual phone, i wont run tests on it, but popey has a test device he could run tests on)
[15:53] <cjwatson> I suppose it could be due to some set of installed test packages
[15:54] <cjwatson> psivaa: any chance you could run "grep -wr nobody /" on a device exhibiting this, and show me the result?
[15:54] <psivaa> cjwatson: sure 1 sec
[15:55] <cjwatson> I can partially revert if I have to, but I'd really rather chase this down as the change made all trusty systems more secure
[15:56] <popey> cjwatson: happy to run whatever tests on my phone
[15:56] <cjwatson> popey: do you see "Successful su for nobody by root" in /var/log/auth.log?
[15:58] <dobey> didrocks: more tests added on https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736 ; i didn't see any existing stuff for "sru mode" and i'm not sure how it would apply in this case (i think it would be transparent since the series is different anyway, as you said)
[15:59] <popey> cjwatson: under what circumstances?
[15:59] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715504/ is the output of that.
[15:59] <cjwatson> popey: to start with, just as it is
[15:59] <popey> no
[16:00] <popey> i see no reference to "nobody" in that log
[16:00] <cjwatson> popey: then after running the messaging-app tests and rebooting
[16:00] <psivaa> cjohnston: please note that the lines with Documents are copied old auth.logs
[16:00] <didrocks> dobey: looking good. Mind if I have a deeper look my tomorrow morning? Want to finish some stuff tonight
[16:00] <cjwatson> yeah, I know
[16:00] <popey> ok
[16:01] <cjwatson> psivaa: I think it might have got stuck at /proc or /sys
[16:01] <cjwatson> psivaa: could you try "grep -wr nobody /usr /var"?
[16:04] <dobey> didrocks: sure
[16:06] <psivaa> cjwatson: http://pastebin.ubuntu.com/6715544/
[16:07] <cjwatson> /usr/bin/with-ofono-phonesim:su nobody > /etc/ofono/phonesim.log <<EOF 2>&1 &
[16:07] <cjwatson> bing
[16:07] <didrocks> dobey: thanks for the patch!
[16:08] <dobey> didrocks: sure. i just wanted proper support for native daily release versions :)
[16:10] <cjwatson> psivaa: Please try http://paste.ubuntu.com/6715569/ - the latter part should apply to /usr/bin/with-ofono-phonesim
[16:11] <cjwatson> popey: I think you can stand down now, thanks
[16:11] <popey> ok
[16:22] <cjwatson> psivaa: any luck?
[16:23] <psivaa> cjwatson: running the test.
[16:23] <cjwatson> psivaa: I should have mentioned that you probably need to reboot after applying that patch
[16:23] <psivaa> cjwatson: the tests do that already
[16:23] <cjwatson> ok
[16:24] <didrocks> psivaa: the change is in the test runner?
[16:24] <cjwatson> the change is in ofono-phonesim, see above
[16:24] <psivaa> cjwatson: and it fixes. the test pass :)
[16:24] <cjwatson> yay
[16:24] <didrocks> ok, thanks
[16:24] <cjwatson> uploaded
[16:24] <didrocks> excellent :)
[16:25] <cjwatson> https://launchpad.net/ubuntu/+source/ofono-phonesim/1.19-0ubuntu7
[16:26] <cjwatson> urgh, competing with the test rebuild
[16:27] <cjwatson> if only we had more arm64 hardware ...
[16:44] <cjwatson> didrocks: I think maybe I should cancel one of the test rebuilds to make room here - I assume you want to get back to green this evening?
[16:45] <didrocks> cjwatson: if possible, so that we have an image kicked soon
[16:45] <didrocks> cjwatson: otherwise, the cronjob at 2 am UTC will kick it
[16:45] <ogra_> 3am
[16:45] <ogra_> :)
[16:48]  * didrocks is lost in time
[16:50] <ogra_> if it is only one of time ans space thats still ok ... both is bad though
[16:50] <ogra_> s/ans/and/
[16:53] <didrocks> ;)
[16:53] <didrocks> space is ok
[16:53] <didrocks> well… I guess
[17:00] <balloons> fginther, ping
[17:00] <fginther> balloons, pong
[17:01] <balloons> fginther, can you help me rebuild konsole-qml-plugin in https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily?
[17:02] <balloons> we don't have a trusty build for it
[17:02] <fginther> balloons, actually there is one, but it has saucy in the name
[17:03] <didrocks> ogra_: joining?
[17:03] <ogra_> didrocks, no :P
[17:03] <balloons> fginther, hehe.. so the 10-30 is the name eh? anyways, we need a build against the newer libs in trusty
[17:04] <fginther> balloons, ack, I'll try a fresh build
[17:10] <fginther> balloons, is this the correct branch? lp:ubuntu-terminal-app/plugin
[17:10] <balloons> fginther, yes I believe so
[17:12] <didrocks> ogra_: tsssss
[17:12] <ogra_> heh
[17:14] <balloons> didrocks, I did notice you have dialer app assigned to me.. it's not a core app
[17:15] <didrocks> balloons: oh sorry, yeah I know, typo :)
[17:15] <didrocks> balloons: will fix in next one, thanks!
[17:15] <balloons> which is to say, I've not handled issues in the past, heh :-)
[17:15] <didrocks> balloons: no worry, I pinged directly Bill on that one in fact
[17:15] <didrocks> the typo was just on the email
[17:22] <balloons> :-)
[17:30] <timp> what's wrong here? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-amd64/2113/console
[17:31] <timp> ERROR: No artifacts found that match the file pattern "work/output/*.deb". Configuration error?
[17:31] <timp> ERROR: 'work/output/*.deb' doesn't match anything, but 'output/*.deb' does. Perhaps that's what you mean?
[17:31] <timp> it seems to fail when installing packages before running tests?
[17:49] <balloons> cprov, what happened with this? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
[17:52] <cjohnston> timp: looks like there is a dbus issue
[17:53] <cjohnston> balloons: isn't that the same one as earlier?
[17:54] <balloons> cjohnston, yes.. I just don't know what happened with it. I see it's still failing
[17:55] <cjohnston> balloons: it hasn't run again since last we talked has it?
[17:55] <balloons> cjohnston, I'm not sure.. I had to hit some meetings and left it with timp
[17:55] <cjohnston> PS Jenkins bot (ps-jenkins) wrote 4 hours ago:
[17:55] <balloons> was something wrong on the ci end?
[17:56] <balloons> that's the question
[17:56] <cjohnston> no..
[17:56] <balloons> kk, so it is test failures then..
[17:56] <cjohnston> _usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash <--
[17:56] <cjohnston> balloons: my understanding is that crash is the issue
[18:00] <balloons> I see the pending build btw fginther for konsole-qml-plugin, ty
[18:18] <kenvandine> robru, can you review https://code.launchpad.net/~ken-vandine/ubuntu-html5-theme/0.1+13.10.20130916-0ubuntu2/+merge/200722
[18:19] <kenvandine> alesage, can you look at this failure, gcov related
[18:19] <kenvandine> https://jenkins.qa.ubuntu.com/job/unity-trusty-amd64-autolanding/67/console
[18:19] <alesage> kenvandine, willdo
[18:20] <kenvandine> alesage, thx
[18:23] <robru> kenvandine, done
[18:24] <kenvandine> oh... you did it last night... since mine :)
[18:24] <kenvandine> i proposed branches for all of the out of sync packages yesterday :)
[18:24] <kenvandine> most are merged already though
[18:24] <robru> kenvandine, oh ok
[18:26] <kenvandine> alesage, i have another one that is failing because it finds lcov 1.10 and gcov.m4 doesn't list 1.10 as a valid version
[18:26] <kenvandine> alesage, should i just update the gcov.m4 file?
[18:26] <kenvandine> alesage, or is there more to it than just adding the version?
[18:26] <alesage> kenvandine, yes I think just update the version
[18:27] <kenvandine> cool, thx
[18:28] <kenvandine> robru, humm... you did dee as well
[18:28] <kenvandine> but dee ftbfs in ci tests
[18:28] <kenvandine> because of the lcov version
[18:29] <robru> kenvandine, oops, yeah, I didn't realize you'd done any. so I just did a couple that i saw
[18:29] <alesage> kenvandine, yes that's going to be a problem all over :/
[18:29] <kenvandine> haha... we did discuss it in the meeting yesterday :)
[18:29] <alesage> kenvandine, need to upstream that gcov.m4 file somewhere
[18:29] <kenvandine> https://code.launchpad.net/~ken-vandine/dee/1.2.7+13.10.20130924.1-0ubuntu2/+merge/200719
[18:29] <kenvandine> robru, can you review that one?
[18:29] <kenvandine> i merged trunk so it won't conflict with your change
[18:29] <kenvandine> but hopefully will build in CI now
[18:30] <robru> kenvandine, done
[18:30] <kenvandine> thx
[18:30]  * kenvandine hopes it passes
[18:31] <kenvandine> alesage, let me know what you figure out on with the unity build
[18:31] <kenvandine> that one looks weird, unrecognized gcovr format
[18:31] <robru> kenvandine, https://code.launchpad.net/~unity-team/libqtdbusmock/trunk/+activereviews is this the same scenario as libqtdbustest? pete-woods says only the changelog changes were necessary, but didn't comment for this project (which is an identical change)
[18:31] <kenvandine> yeah
[18:31] <kenvandine> i saw that too
[18:31] <kenvandine> i'll revert the rules change there too
[18:31] <robru> kenvandine, ok, ping me and i'll approve the changelog change then.
[18:31] <alesage> kenvandine looking at, will report
[18:33] <kenvandine> robru, pushed
[18:33] <robru> kenvandine, done
[18:36] <kenvandine> ok, bamf needed the gcov.m4 change too
[18:37] <kenvandine> https://code.launchpad.net/~ken-vandine/bamf/0.5.1+14.04.20131125-0ubuntu2/+merge/200723
[18:37] <kenvandine> robru, ^^
[18:42] <robru> kenvandine, done
[18:42] <kenvandine> thx
[18:45] <timp> 18:52:54 < cjohnston> timp: looks like there is a dbus issue
[18:45] <timp> cjohnston: yes, but the code changes don't touch dbus. is it an issue with jenkins?
[18:46] <timp> cjohnston: why dbus? It says some deb files are missing. I don't see any failed tests
[18:47] <cjohnston> timp: I'm wondering if there is a crash like the other one?
[18:48] <alesage> kenvandine gcovr log items may be red herring: last successful build (65) also had gcovr complaints; `mkdir` operation failure at the very end appears to be the culprit
[18:49] <alesage> fginther, does this look at all familiar?  https://jenkins.qa.ubuntu.com/job/unity-trusty-amd64-autolanding/67/console
[19:11] <fginther> alesage, I think I know what's happening here, give me a few minutes to get it fixed
[19:12] <balloons> sergiusens, ping
[19:12] <alesage> fginther, thanks kenvandine ^^
[19:13] <cjohnston> fginther: can you take a look at https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-amd64/2113/console please
[19:19] <kenvandine> alesage, fginther: thx
[19:19] <fginther> cjohnston, I can fix that, thanks for the info
[19:20] <cjohnston> timp: ^
[19:22] <timp> fginther: you'll fix the ERROR: No artifacts found that match the file pattern "work/output/*.deb". Configuration error?
[19:22] <timp> fginther: cool. do you know what caused it?
[19:24] <fginther> timp, it's fixed (at least this case, I have some others to correct). One of the CI tools was automatically updated and it resulted in a mismatch in behavior
[19:24] <timp> ok, thanks
[19:55] <sergiusens> balloons, pong
[20:00] <balloons> sergiusens, solved it myself heh. I swear everytime I ping to ask you something I end up figuring it out.. :-p
[20:00] <sergiusens> balloons, hey, that's how I operate as well :-)
[20:01] <cyphermox> robru: kenvandine: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/apps-test-packages/+merge/200900 ?
[20:24] <kenvandine> cyphermox, looking
[20:24] <kenvandine> cyphermox, approved
[20:30] <cyphermox> thanks
[22:08] <sergiusens> fginther, can we get lp:goget-ubuntu-touch under ci now?
[22:08] <fginther> sergiusens, sure
[22:11] <sergiusens> fginther, let me get greedy and ask for lp:usensord too :-)
[22:11] <fginther> sergiusens, what are these used for (so I know what cu2d stack to use)?
[22:11] <sergiusens> fginther, usensord should go in the same place platform-api is
[22:12] <sergiusens> fginther, goget-ubuntu-touch where phablet-tools lives
[22:15] <fginther> sergiusens, are these ready for daily-release?
[22:19] <sergiusens> fginther, they'd need packaging review; but they are fairly ready
[22:19] <sergiusens> fginther, as in from the team
[22:20] <fginther> sergiusens, in that case I'll prep them for upstream merger now so as not to wait on a packaging review
[22:20] <sergiusens> fginther, sounds good
[22:32] <kgunn> fginther: just curious...can we determine/backtrack like which exact device (mako) a test was run on ?
[22:33] <kgunn> just curious we saw one mako we were suspect of prior to break...took it out, but put it back
[22:33] <kgunn> just wondering if it might be biting us again
[22:33] <kgunn> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/226/console
[22:33] <fginther> kgunn, yes, the device name is in the console log, one of the first few lines
[22:33] <fginther> mako-04cb53b598546534
[22:34] <kgunn> yep found it...thanks fginther
[22:35] <fginther> kgunn, if you suspect a bad device, we can remove it from the main pool and attempt some focused tests
[22:36] <kgunn> fginther: thanks...i'll just keep an eye on this mp...see if it fails again and monitor the device...if "he" remains a prob...i might ping you tomorrow
[22:36] <fginther> kgunn, ack