[00:06] <xnox> sergiusens: Saviq: bzoltan: didrocks: you've got mail, requesting a silo reconfiguration =) (and to steal branch from Saviq & bzoltan for sergiusens to land) I hope we can agree to do that =)
[00:25] <ricmm> Saviq: its a lot easier to crash after a while
[02:00] <rsalveti> ricmm: no deal?
[08:47] <sil2100> hm, my thunderbird went nanners
[09:30] <sil2100> Can anyone paste me the hangout link? ;)
[09:30] <sil2100> Ah, nevermind now!
[09:36] <mardy> didrocks: hi! Is it possible to have several branches for the same project in a silo? Will they get automagically merged?
[09:44] <seb128> mardy, yes, they get merged in the order you list them in the request
[09:45] <mardy> seb128: cool, thanks
[09:45] <seb128> yw
[09:46] <dbarth> hi, what's the weather like for the CI train this morning? ie do you think landings may resume today?
[09:47] <didrocks> dbarth: not now, we still have the dashboard failing
[09:48] <dbarth> ok, nw; will land in a ppa for now
[10:13] <psivaa> didrocks: ogra: systemsettle failure on default set is because it was using an identical script but from a different location, which was not changed.
[10:13] <didrocks> psivaa: ahah
[10:13] <didrocks> :)
[10:13] <psivaa> i'll propose a fix with symlinking to the original one
[10:13] <ogra> [10:13] <didrocks> yeah, seems better than duplication :)
[10:14] <didrocks> thanks psivaa
[10:14] <didrocks> and let's see if we can this in time for 209
[10:14] <ogra> funny :)
[10:14] <psivaa> yw :)
[10:14] <ogra> the system-image part takes significantly longer, you have plenty of time :)
[10:21] <sil2100> hmmm
[10:22] <sil2100> I might have some clue on what makes the terminal test fail, just need to figure out what is causing this
[10:37] <Saviq> huh? stable == saucy still?
[10:38] <didrocks> Saviq: yeah, it's been a long debate, not sure we should focus our strength on that today :)
[10:41] <Saviq> didrocks, nah, I just went for ubuntu-device-flash and was surprised it chose image 104 for me :)
[10:42]  * ogra thinks we should drop these channels altogether ... 
[10:42] <ogra> default and proposed is all we should have
[10:42] <didrocks> Saviq: I think we can bring that back on the table once the transition to 4.4 is done
[10:42] <didrocks> ogra: +1
[10:43] <Saviq> yeah, ETOOMANYCHANNELS
[10:44] <ogra> stable was theoretically thought for developers to get a stable base for their apps ...
[10:44] <ogra> but we are moving way to fast for that imho
[10:44] <didrocks> indeed
[10:45] <ogra> oooh
[10:45] <ogra> didrocks, the new logo is beautiful
[10:46]  * ogra sees itfor the first time
[10:46] <didrocks> ogra: heh, thanks ;)
[10:46] <ogra> dancing friends :)
[10:47] <didrocks> thanks to my wife to have detour it (even with the svg, to downscale it and not having weird outer circle "moving"… wasn't that straightforward)
[10:47] <didrocks> heh :)
[10:47] <seb128> what logo?
[10:47] <xnox> seb128: the new recovery, has a spinning ubuntu cof upon bootstrap flash.
[10:47] <ogra> seb128, new recovery mode
[10:48] <seb128> oh ok
[10:48] <ogra> the dead android with rotating guts is gone
[10:48] <didrocks> that was really annoying me \o/
[10:48] <ogra> ++
[10:50] <xnox> didrocks: can we get rid of the choppy progress bar?
[10:50] <ogra> thats harder than replacing the logo
[10:50] <ogra> (needs actual code changes)
[10:50] <xnox> didrocks: or like slow it down? i'm not resurrected robocop to register that it's working properly, instead of looking choppingly fast.
[10:51] <didrocks> xnox: slowing it down is easy, the issue is that we can get a progress bar with the number of steps, but some steps are taking seconds, other minutes :p
[10:58] <ogra> wow
[10:58] <ogra> my device just rebooted in the middle of a unity8 test run
[11:00] <ogra> hmm
[11:00] <ogra> WARNING: in file "/usr/lib/python2.7/dist-packages/unity8/shell/tests/__init__.py", line 148 in setUp
[11:00] <ogra> This function is deprecated. Please use 'the Touch class to instantiate a device object' instead.
[11:00] <ogra> i thought it is python3 now
[11:04] <ogra> hmm, the camera fake thingie in unty8 doesnt fit on the screen on flo
[11:05] <davmor2> Morning all
[11:05] <xnox> ogra: nah, my branch to switch it to python3 is on hold.
[11:06] <ogra> ah, k
[11:06] <xnox> ogra: and it doesn't fix / change classes.
[11:06] <xnox> ogra: something about unity8 crashing, and that being priority to fix.
[11:06] <ogra> yep, i know, i was in the meeting this morning :)
[11:10] <didrocks> sometimes GAS will turn me crazy
[11:12] <sil2100> It's probably poison GAS
[11:12] <sil2100> What's up?
[11:13] <didrocks> oh, I found the fix
[11:13] <didrocks> but using "name" and 'name' is different if you pass that to a function
[11:15] <didrocks> it's because of their internal caching creating bugs
[11:16] <sil2100> ;/
[11:18] <Laney> gas the gnu assembler?
[11:20] <didrocks> google apps scripts
[11:20] <ogra> umm
[11:20] <ogra> sh: 1: gcc: not found
[11:20] <ogra> dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation)
[11:21] <ogra> why does the unity8 test use gcc
[11:21] <didrocks> ogra: it's autopilot
[11:21] <ogra> ah
[11:21] <didrocks> and this is the case for a long time
[11:21] <didrocks> that we have that error
[11:21] <ogra> never noticed it
[11:21] <ogra> (but i also rarely watched the terminal while the tests were running, it probably just scrolled offscreen)
[11:21] <didrocks> sil2100: Mirv: robru-is-dying: cyphermox: ok, so now, when you add more lines to the spreadsheet, it should apply the formatting for you (phew)
[11:22] <didrocks> ogra: yeah, it's at the beginning of a test or testsuite
[11:22] <Mirv> nice..
[11:22] <ogra> right
[11:22] <ogra> Ran 46 tests in 1373.092s
[11:22] <ogra> FAILED (failures=1)
[11:22] <ogra> Restoring shell
[11:22] <ogra> unity8 start/running, process 13586
[11:22] <ogra> not that bad
[11:22] <didrocks> yeah, same than in the dashboard
[11:22] <didrocks> because of the crash
[11:23] <sil2100> \o/
[11:23] <ogra> ERROR: unity8.indicators.tests.test_indicators.IndicatorTestCase.test_indicator_exists(Bluetooth)
[11:23] <ogra> and thats expected ... since flo has no working BT yet
[11:23] <didrocks> sil2100: Mirv: tell me if you find any bug, I had to rewrite some formulas for that
[11:25] <ogra> hmm
[11:25] <ogra> so http://ci.ubuntu.com/smokeng/trusty/touch/flo/208:20140226:20140224/6826/unity8/ looks quite different from ym test
[11:25] <ogra> *my
[11:26] <didrocks> ogra: again those StateNotFoundError: State not found for class 'DefaultIndicatorWidget' and filters {'objectName': 'indicator-bluetooth-widget'}.
[11:26] <didrocks> another one is the crash
[11:26] <ogra> didrocks, well, there is no BT indicator on flo
[11:27] <ogra> i had the crash (which actually caused a reboot) the run after the crash was fine apart from the BT test
[11:27] <didrocks> ogra: ok, so only the crashes
[11:27] <didrocks> the 3 others
[11:27] <didrocks> (no process found with pid…)
[11:27] <ogra> i only had one
[11:27] <ogra> see above
[11:27] <didrocks> yeah, it's random, so you can get lucky
[11:27] <didrocks> talking about the dashboard, seems there were 3
[11:27] <ogra> right
[11:28]  * ogra re-runs
[11:39] <ogra> didrocks, oh, i totally forgot to mention in the meeting ... when we re-added click-update-manager (which had been dropped in 194) inn image 202, we didnt promote 202 which means users cant upgrade their apps at all atm
[11:40] <didrocks> ogra: yeah, one of the issue is that we don't have full test results on 202 nor dogfooding
[11:40] <ogra> i was wondering (sice we're stuck atm anyway) if we should put some effort into gettin 202 late promoted
[11:40] <didrocks> so, if the CI team can maybe rerun 202 in parallel?
[11:40] <didrocks> that makes sense
[11:40] <didrocks> psivaa: will that take you a long time to get 202 running all tests? ^
[11:41] <ogra> might clash with 209 now though :/
[11:41] <didrocks> yeah
[11:41] <didrocks> let's wait for his feedback
[11:41] <ogra> [11:41] <psivaa> didrocks: i get the setup going, it wont take long but for the tests to complete it will take around 4+ hrs.
[11:41] <psivaa> i could run 202 on a different device though
[11:41] <psivaa> but we wont have the results on the dashboard
[11:42] <ogra> that might be good
[11:42] <didrocks> psivaa: if some tests are failing or need rerun…
[11:42] <psivaa> didrocks: that's fine. they will be isolated
[11:42] <didrocks> psivaa: you will still be able to just run the testsuite failing?
[11:42] <didrocks> ok :)
[11:42] <didrocks> so yeah, if you have time, please :)
[11:42] <didrocks> then, if the results are good, we can ask our lovely dogfooders
[11:43] <psivaa> didrocks: ack, will kick one
[11:44] <didrocks> thx!
[11:53] <bregma> hey didrocks, how do I get a project to start using ci-train... just add a MP and it will automatically climb aboard, or is there some manual adjusyment the Landing Team has to make?
[11:53] <didrocks> bregma: is that a new project or something that was under daily release before?
[11:53] <bregma> in this case, it's the unity8-desktop-session project, so, new
[11:54] <bregma> I also need to get geis and libgrip releases out, but I'm pretty sure they need manual reconfiguration
[11:54] <didrocks> ah ok, so a MP is enough to get it (just ensure we can bzr bd)
[11:54] <didrocks> can you please add it as well to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1?
[11:54] <didrocks> that helps tracking
[11:54] <bregma> I don't believe I have edit access, let me try
[11:55] <didrocks> you should have
[11:56] <didrocks> bregma: btw, you probably want to take bamf (and some of the scopes?)
[11:56] <didrocks> as a Lander
[11:57] <didrocks> I see they still don't have any landers
[11:57] <bregma> the scopes should all be mhr3
[11:57] <didrocks> mhr3: taking them? ^
[11:58] <didrocks> thostr_: ^
[11:58] <bregma> OK, I have edit, adding and updating
[11:58] <didrocks> I only see the mediascanner one
[11:58] <didrocks> bregma: thanks!
[11:58] <didrocks> bregma: it will by default collect from rev 0 for the changelog though, if you released one version, ensure it's tagged with the packaging version then
[12:00] <bregma> didrocks, up to now I used standard debrelease techniques, it should be tagged
[12:00] <didrocks> excellent, we should be fine then :)
[12:00] <thostr_> bregma: well, the old scopes is unity7 only that's why I though you'd take those
[12:01] <bregma> didrocks, how about geis, it has pending changes that haven't landed in distro for some time and I have no new MPs at the moment, so it will need a trunk flush, correct?
[12:04] <didrocks> bregma: yeah, just propose an empty MP to flush those
[12:04] <didrocks> Mirv: mind unwiring from daily release and update the items without CI Train "yes" on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1, please?
[12:07] <thostr_> didrocks: do we need to explicitly move all old scopes to ci, or can we rather do that once we have changes?
[12:07] <thostr_> didrocks: ... which I don't expect any time soon
[12:08] <didrocks> thostr_: we can do that once you have change, just be aware that we'll disable everything shortly though
[12:08] <thostr_> didrocks: sure
[12:08] <didrocks> thostr_: however, once you have change, it will take more time to migrate
[12:08] <didrocks> so be aware of that and don't ask the impossible later on :)
[12:09] <thostr_> didrocks: yes, understood
[12:12]  * bregma always expects the impossible from didrocks
[12:12] <didrocks> tssss ;)
[12:16] <psivaa> om26er: hey do you think bug 1276747 could also be a reason why turning the screen on failing in http://pastebin.ubuntu.com/6999455/
[12:17] <psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/3/console is flashing with 202
[12:17] <didrocks> psivaa: excellent, thanks!
[12:19] <mhr3> didrocks, what, what, what?
[12:19] <mhr3> what am i supposed to take?
[12:20] <om26er> psivaa, no, this log seems to show it could not find proxy for unity8, could be unity8 crashed
[12:20] <didrocks> mhr3: backlog just before my hilight :)
[12:20] <psivaa> om26er: unity8 did not crash on those instances
[12:21] <mhr3> didrocks, ok, a sec, in meeting
[12:22] <om26er> psivaa, let me try to reproduce that, not sure if 'com.canonical.Shell.BottomBarVisibilityCommunicator' exists these days
[12:23] <psivaa> om26er: thanks. http://pastebin.ubuntu.com/6999481/ contains some more information indicating unity8 is running
[12:24] <om26er> psivaa, where can i find the unlock screen script ?
[12:24] <psivaa> om26er: and this does not occur all the time: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py
[12:27] <om26er> that code looks familiar
[12:29] <psivaa> om26er: if it helps, this behaviour started only this week and during the weekend we had autopilot, unity and android updates.
[12:30] <om26er> psivaa, i am trying on the very latest image, seems to work for me multiple times. did anyone reproduce the issue locally as well ?
[12:31] <psivaa> om26er: i dont think anyone tried this. and it happens about 1 in 5 times i'd say
[12:32] <Mirv> didrocks: ok, so both updating daily release config for ci train 'yes' if not already plus adding possible entries in configs that are not in the sheet
[12:33] <om26er> psivaa, i have a question is the script running as root in CI ?
[12:33] <didrocks> Mirv: thanks!
[12:33] <psivaa> om26er: i think so, let me confirm
[12:34] <om26er> psivaa, also i want a complete log, seems i have been able to reproduce the issue here
[12:36] <psivaa> om26er: it is being run as root
[12:36] <didrocks> psivaa: hum, default system settle for 209 didn't use your change?
[12:37] <psivaa> om26er: https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-touch-mako-smoke-daily/90/ has the necessary logs
[12:38] <psivaa> om26er: 'adb-shell /home/phablet/bin/unlock_screen.sh' is when it starts for all the app tests
[12:38] <psivaa> didrocks: the MP needs approval and merge. dint want to push it straight
[12:38] <didrocks> psivaa: ah ok
[12:54] <ogra> hmm
[12:54] <ogra> so i can enable BT on the android side of the flo
[12:54] <ogra> and apparently it even comes up ... but the indicator doesnt seem to notice
[12:59] <didrocks> apw: hey, do you think it will be possible to have the same "core up" behavior than in 4.2? (so cores not shutting down)
[12:59] <didrocks> just to run one full test suite with that
[12:59] <didrocks> and see if the flakyness that are revealed is due to that
[13:06]  * ogra files bug 1285146 for cyphermox 
[13:07] <mhr3> didrocks, noone's touching the old scopes, so let's deal with it if/when they need to be touched
[13:09] <didrocks> mhr3: ok, just note my remark on the introduced delay then once you want to land it
[13:10] <Mirv> didrocks: ok sync done. all packages having in CI Train already set were disabled correctly, but I was wary of setting any disabled-in-daily-release-config to be automatically CI Train 'yes'. instead, for you to review: http://pastebin.ubuntu.com/6999661/
[13:10] <mhr3> didrocks, if there's just a simple fix needed or something trivial can't it use no-train?
[13:10] <didrocks> mhr3: no, we are not going to support the old infra anymore
[13:10] <mhr3> didrocks, there's still manual uploads ;)
[13:11] <didrocks> mhr3: well, we don't do that for our projects :p
[13:11] <mhr3> didrocks, clearly i need to become ubuntu developer so i can screw with you ;)
[13:11] <didrocks> mhr3: better to keep one process only
[13:12] <didrocks> mhr3: don't worry, a lot of people are using their time to accomplish this :p
[13:12] <mhr3> didrocks, aaah, so i wouldn't be the only one? that sucks
[13:13] <didrocks> Mirv: ok, I flipped the switch for those having a landers
[13:13] <didrocks> Mirv: but it seems you basically missed the ## Stack oif.cfg ##
[13:14] <didrocks> Mirv: and account-plugins
[13:14] <didrocks> click-apparmor
[13:14] <didrocks> and another click
[13:14] <Mirv> didrocks: hmm?
[13:14] <didrocks> Mirv: basically, everything that has a lander is up to ci train
[13:15] <sil2100> bregma: so, unity7 is tested, right?
[13:15] <Mirv> didrocks: oif is covered as being enabled in daily release config, so covered by pastebin's first line. the rest, I'm probably missing some pass you were wanting? I worked through the daily-release configs and compared those to the spreadsheet, but I didn't go through the spreadsheet by itself as such
[13:16] <sil2100> bregma: do any of those changes there could affect touch?
[13:16] <didrocks> Mirv: yeah, so when there is a lander, we need to disable them from daily-release
[13:16] <didrocks> Mirv: as well as upstream-merger, and then, set the "In CI Train" to yes
[13:16] <Mirv> didrocks: ok, so if lander name is there, it means need to disable, ok
[13:16] <didrocks> yep :)
[13:16] <Mirv> didrocks: that's the pass I'm missing
[13:16] <sil2100> Exactly ;)
[13:17] <didrocks> Mirv: sorry, it seems they are just 6 of them :)
[13:17] <didrocks> fginther: please, when you add projects or change cu2d-config, please reflect the change in the spreadsheet as well: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1
[13:17] <didrocks> fginther: and don't enable upstream-merger :)
[13:22] <Mirv> didrocks: so actually just oif needs disabling in config, I think. click-* were not in daily release, and I now moved accounts-plugins also under the title I created "Other CI Train packages not formerly in daily release system". https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/sync_citrain_disable_oif/+merge/208361
[13:23] <didrocks> Mirv: hum, you need to disable upstream merger as well for them, they were not in it?
[13:23] <om26er> psivaa, i have come to a situation where the unlock script prints that unity8 has been restarted but it is actually not, probably due to a bug somewhere on unity side or our config
[13:23] <didrocks> Mirv: hum, you only changed the daily-release tag, there is more than that, remember at Bluefinn?
[13:23] <bregma> sil2100, yes, tested and FFe acked, all changes are only in Unity7 (the removed config option was never used anywhere) so no Touch effects
[13:23] <didrocks> Mirv: let me find you a commit
[13:24] <Mirv> didrocks: in stacks/head, I find no trace of apparmor/click-apparmor/click in projects:
[13:24] <didrocks> Mirv: you need to add:
[13:24] <om26er> at that time the screen is indeed turned on *but* starting unity with 'initctl start unity8' does not actually show it on my screen
[13:24] <didrocks> +     daily_release: False
[13:24] <didrocks> +     autolanding_template: False
[13:24] <didrocks> +     use_stack_ppa: False
[13:24] <didrocks> Mirv: to every project that you are disabling ^
[13:24] <Mirv> didrocks: right.. adding
[13:24] <didrocks> (so probably account-plugin, click-* as well)
[13:24] <om26er> plars, do you manage the unlock screen script ?
[13:25] <sil2100> didrocks: ^ can I publish unity7 then? :) I'll double check the FFe bits before that
[13:25] <didrocks> om26er: it happens quite often since the android 4.4 switch FYI
[13:25] <didrocks> sil2100: yeah :)
[13:26] <om26er> plars, how important is it to restart unity8 after every test suite ?
[13:26] <Mirv> didrocks: pushed to the branch for oif, still not finding accounts-plugins, click-* in the daily release config with grep
[13:26] <sil2100> didrocks: ok, Laney ACKed the FFe's, so it's indeed all green
[13:26] <didrocks> Mirv: oh nothing? interesting
[13:27] <sil2100> bregma: btw.! Wow! I see you guys come from the future ;D "Unity7 bugfixes 2024.02.24" ;)
[13:27] <didrocks> Mirv: I would still add the 3 lines for "dead" projects
[13:27] <didrocks> Mirv: just in case :p
[13:28] <bregma> geez, one typo and they never let you forget
[13:28] <ogra> sil2100, bregma, oh horror !!!!!
[13:28]  * ogra really doesnt want to see us using unity7 in 2024 still
[13:28] <sil2100> bregma: ;)
[13:28] <om26er> didrocks, plars psivaa we can probably add tests for the unlock script itself
[13:29] <didrocks> people mixing numbers
[13:29] <didrocks> I never do that!
[13:29] <ogra> except in lotteries
[13:29] <didrocks> om26er: yeah, but first, let's get it fixed :)
[13:29] <ogra> :)
[13:29] <didrocks> ogra: ahah
[13:30] <apw> didrocks, the change was not to whether they were up, it was how they are reported in the idle stats; right?
[13:30] <didrocks> Mirv: and hum stacks/head/webcred.cfg:    account-plugins:
[13:30] <Mirv> didrocks: aha, why was I grepping accountS-plugins
[13:30] <Mirv> just a moment
[13:31] <didrocks> apw: not sure, no power management change as you know of?
[13:31] <didrocks> it's only on the reporting side?
[13:31] <om26er> Saviq, hey! unity8 does not start and if i start it from the terminal i see this: http://paste.ubuntu.com/6999748/
[13:31] <om26er> does that mean anything ?
[13:32] <apw> didrocks, i don't have that information without waiting for this stupid thing to charge, but the issue with the test suites was about reporting _only_
[13:32] <ogra> om26er, did you use upstart to start it ?
[13:32] <Mirv> didrocks: ok now the merge request page is updated
[13:33] <didrocks> apw: yeah, but we have other "weird" new races and so on since the switch itself, so I was wondering if they changed something around CPU or scheduling (and if we can proove that theory)
[13:33] <sil2100> didrocks: packaging ACK needed: http://162.213.34.102/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.1.2+14.04.20140225-0ubuntu1.diff <- new dep in main, seems ok
[13:33] <om26er> ogra, with initctl it gave: http://paste.ubuntu.com/6999760/
[13:33] <apw> didrocks, i didn't see a heap of nasty looking change, but presumably we tested these kernels before switching
[13:34] <ogra> om26er, as phablet user ? and is lightdm running (and thus unity-system-compositor)
[13:34] <sil2100> Great, I just broke my unity7, geh ;)
[13:34] <om26er> ogra, yes as phablet user, i ssh'd in
[13:34] <didrocks> apw: ok, false hope then :)
[13:35] <om26er> ogra, lightdm have 2 instances and unity-system-compositor have 1
[13:35] <ogra> ok, thats fine then
[13:36] <ogra> (something seems to hog /tmp/mir_socket or so)
[13:37] <didrocks> sil2100: +1
[13:38] <didrocks> Mirv: hum, seems you missed my remark…
[13:38] <didrocks> 14:27:56 didrocks | Mirv: I would still add the 3 lines for "dead" projects
[13:38] <didrocks> 14:27:59 didrocks | Mirv: just in case :p
[13:38] <om26er> ogra, rm -r /tmp/mir_socket ?
[13:38] <ogra> om26er, no, thats privided by unity-system-compositor ... you would rip the carpet out underneath it
[13:39] <ogra> om26er, rather check if there is another unity8 stuck or so
[13:39] <ogra> it hooks into that socket
[13:40] <Mirv> didrocks: sorry, there are 8 different cases. so add where for which dead projects? I somehow skipped that as being that "yes keep those mentions in the daily-release config proposal that I copied from spreadsheet"
[13:40] <Mirv> didrocks: this syncing is complex :)
[13:41] <om26er> ogra, seems our unlocker tries to remove mir_socket http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py
[13:41] <om26er> line 29
[13:41] <didrocks> Mirv: yeah ;) basically the idea is "disable daily release and upstream merger for the dead projects"
[13:41] <didrocks> Mirv: so adding the same 3 lines in the configuration
[13:41] <didrocks> for them
[13:42] <ogra> om26er, hmm, that feels rather wrong, ask mterry once he comes online ... he designed the nested Mir mode we use today
[13:43] <Mirv> didrocks: ah, adding the three "disabling lines"! great.
[13:43] <ogra> didrocks, ^^^^ that could cause a lot of unity8 test issues actually
[13:43] <didrocks> yep
[13:43] <didrocks> ogra: yeah, that's probably the cause of so many phablet-test-run which don't start
[13:43] <didrocks> psivaa-lunch: right? ^
[13:44] <ogra> i'm not sure if /tmp/mir_socket gets dynamically re-created
[13:44] <ogra> but i doubt it
[13:44] <Mirv> didrocks: pushed and LP is updated
[13:44] <ogra> and unity8 kind of wants to connect to it
[13:44] <jdstrand> didrocks, Mirv: I don't know what this oif stuff is, but apparmor, apparmor-easyprof-ubuntu and click has me as a lander but getting them into the citrain fold is still in progress (I started it but got pulled away)
[13:45] <ogra> jdstrand, you can always dput to a landing PPA
[13:45] <ogra> which i guess is at least hafl a CI train ...
[13:45] <ogra> *half
[13:45] <jdstrand> true, I'll keep that in mind
[13:46] <didrocks> jdstrand: yeah, but we can disabling them from daily-release and automerging :)
[13:46] <jdstrand> I'll get it done-- I just haven't had landings to request yet (things got delayed there)
[13:47] <psivaa-lunch> didrocks: ogra: om26er: 'rm -f /tmp/mir_socket' is there for long time and 'rm: cannot remove '/tmp/mir_socket': Operation not permitted' has also been reported before
[13:47] <jdstrand> didrocks: I'm not sure I understand
[13:47] <psivaa-lunch> without much harm
[13:47] <ogra> psivaa-lunch, yeah, it shouldnt be removed ever with nested mode
[13:47] <didrocks> jdstrand: if you don't, basically don't worry, we just unplug from the old system :)
[13:47] <ogra> but i guess if you run it as phablet user you wont have the permissions
[13:48] <ogra> phablet@ubuntu-phablet:~$ rm /tmp/mir_socket
[13:48] <ogra> rm: cannot remove '/tmp/mir_socket': Operation not permitted
[13:48] <ogra> yeah
[13:48] <jdstrand> didrocks: ok, thanks
[13:48] <ogra> om26er, so you iare safe as long as you dont run it as root
[13:48] <psivaa-lunch> ogra: ack
[13:49]  * om26er back in a few minutes, doctor appointment
[13:54] <bzoltan> something is horrible wrong with my ISP ... I got 0.06MBs upstream
[13:55] <plars> om26er|doc: I had nothing to do with that script, iirc you were the original author of it. :)  I really still think there needs to be some way to call into unity itself where it knows how to do all of that without having to use autopilot externally
[13:55] <plars> om26er|doc: unlock has been occasionally failing to unlock the screen lately though
[13:56] <plars> for the last week or so it seems, before that it was pretty reliable
[13:56] <didrocks> plars: yeah, seems it's since the 4.4 switch
[13:57] <bregma> didrocks, any suggestion what component unity8-desktop-session should go under in the CiTrain spreadsheet? (unity8.cfg makes some sense, but I don't know what these .cfg things are)
[13:57] <rsalveti> didrocks: I got quite a few ascii errors when running tests with flo as well
[13:58] <rsalveti> not with mako though, not sure what causes it
[13:58] <didrocks> bregma: I would say "misc", but you can add to the end, it doesn't make sense anymore as we don't have stack configs
[13:58] <didrocks> rsalveti: ascii errors, like invalid locales?
[13:58] <rsalveti> yeah, usual locale error with python
[14:00] <didrocks> interesting, I guess no langpack difference and we do have utf8 there as well. Apart if we go to some error path and the output isn't correct binary/ascii convertion
[14:00] <rsalveti> but nice that it's part of the dashboard now :-)
[14:00] <rsalveti> right
[14:02] <didrocks> rsalveti: we really see various timeouts
[14:03] <didrocks> so, if the power management changed in the 4.4 kernel… maybe it just reveals some flakyness
[14:03] <didrocks> (that we have in our code)
[14:03] <apw> didrocks, ok ... the old kernel on a very old image i happen to have here ... shows that we run with a single cpu normally also
[14:03] <didrocks> apw: oh, really?
[14:04] <apw> as i said it was just a statistics reporting change
[14:04]  * didrocks doesn't understand "shows that we run with a single
[14:04] <didrocks> cpu normally also"
[14:04] <didrocks> seems it's not reporting change
[14:05] <apw> define reporting change ?
[14:05] <apw> the online cpulist from the kernel is '0' on my phone by defualt, ie a single cpu online called 0
[14:05] <rsalveti> yeah, I got the impression that we're no using 4 cpus
[14:05] <rsalveti> and before we were using 2 the most
[14:05] <rsalveti> *we're now
[14:06] <apw> hard to tell without having some what to make the thing busy i guess
[14:07] <didrocks> rsalveti: at least, that would explain most of the flakyness we are seeing I guess
[14:07] <apw> didrocks, i hate to think we write code which isn't smp aware
[14:07] <apw> its all in go right
[14:08] <rsalveti> didrocks: yeah
[14:08] <rsalveti> we can now run many more threads in parallel :-)
[14:09] <apw> rsalveti, what do you base it only using 2 on ?
[14:09] <fginther> didrocks, ack
[14:09] <rsalveti> apw: when debugging pulse I was only getting cpu1 on/off
[14:09] <rsalveti> with 4.4.2 I was getting cpu 1,2 and 3 on/off events
[14:10] <apw> rsalveti, ok i've got an old installed here, and with a cpu loop i can get all cpus online no problem, so it is possible to use them all
[14:10] <rsalveti> but we can check by flashing the older image
[14:10] <ogra> we should really try to run with 0 CPUs
[14:10] <ogra> saves so much battery
[14:11] <rsalveti> right
[14:11] <apw> my older image deffo can use all 4, and indeed is getting nice and warm doing exactly that
[14:11] <plars> oh nice - flo seems to be getting past the webbrowser tests in 208 and 209
[14:12] <plars> http://ci.ubuntu.com/smokeng/trusty/touch/?show_all=1
[14:13] <rsalveti> maybe the governor is behaving differently now somehow
[14:15] <ogra> rsalveti, is it still using the same governor ?
[14:15] <ogra> (we still force ondemand on the ubuntu side)
[14:20] <om26er> plars, the issue on hand right now is that sometimes unity8 does not start even initctl tells us it did
[14:21] <elopio> asac: can you please comment on what we are missing for https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012 to happen?
[14:21] <plars> om26er: well that could keep us from unlocking it I suppose :)
[14:22] <om26er> plars, yep ;)
[14:23] <didrocks> elopio: hey, have you seen my answer on the nostate error?
[14:24] <elopio> didrocks: not yet. On the bug you mean?
[14:25] <elopio> didrocks: oh, got it. I just marked as incomplete the one in the dialer, because I ran it 5 times on my phone and the dash is now green.
[14:25] <elopio> I've been trying to run the ones in weather app, but something is funny here. I'm reflashing to try again.
[14:26] <didrocks> elopio: see my answers and mostly, look at the dashboard :)
[14:26] <didrocks> elopio: it's our first input source
[14:27] <didrocks> and as you can see, things are really flaky (look at different results in different images)
[14:27] <didrocks> so we'll need your expertise I guess in how those tests are misbehaving
[14:28] <asac> elopio: who from CI team have you been working with on this until now?
[14:28] <elopio> asac: nobody.
[14:29] <elopio> didrocks: yes, I'm trying to reproduce the errors here. I just started with the one that strangely fixed itself :)
[14:29] <elopio> about the clock, I've made a branch that should improve the alarm tests a little: https://code.launchpad.net/~elopio/ubuntu-clock-app/page_object-alarm_tests/+merge/207988
[14:29] <asac> elopio: so i was told this was agreed work with the CI team. not really great to hear today that this wasn't done now.
[14:29] <elopio> I'll ask nik about landing it.
[14:29] <didrocks> elopio: oh nice! balloons, sergiusens ^
[14:30] <elopio> asac: maybe somebody agreed on it, but didn't update the status of the bug.
[14:31] <asac> doanac`: what do you think about https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012?
[14:31] <asac> ev: ^^
[14:32] <popey> Mirv:                         text: "Author: Mike Sheldon <elleo@gnu.org>\n\nReleased
[14:32] <popey> under the GPL, version 3.0 or later.";
[14:32] <popey> it's those \n's that are doing the boxes
[14:33] <asac> elopio: in the future, please dont committ to engineering team that you will make stuff happen that you can't happen alone without aligning engineering work done by other teams. this commitment from QA caused people to believe all is going fine and well, and the CI team is deep in the hot phase of an important customer project right now
[14:33] <asac> anyway, lets see
[14:34] <Mirv> popey: file a bug against ubuntu-ui-toolkit first, maybe they can retarget if it's nothing they can affect
[14:34] <Mirv> popey: I was able to see it now by installing TouchWriter
[14:34] <popey> ok
[14:34] <didrocks> Mirv: did you push your changes? I missed your ping probably
[14:35] <asac> elopio: is this just duplicating the autopilot job or what does this entail?
[14:35] <elopio> asac: as far as I can remember, I never commited to this task. That's why I didn't assign it to myself.
[14:35] <elopio> but well, I suppose I didn't make it clear, I'm sorry.
[14:35] <asac> elopio: right. be careful. thanks.
[14:36] <asac> elopio: so the "in the meanimte" comment ... is that still valid?
[14:36] <elopio> asac: duplicating the job, they also want a view like the dashboard to get a nice view of the errors.
[14:36] <asac> elopio: thats not going to happen i am sure
[14:36] <asac> but guess its not critical
[14:36] <asac> as long as the data is there someone can write a perl script or something
[14:36] <thostr_> sil2100: can I get a silo for line 30?
[14:37] <elopio> and I think we need clear direction of when we can run this job, because I heard somebody saying that it might starve the other jobs that need hardware.
[14:37] <Mirv> didrocks: I was thinking you'd approve https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/sync_citrain_disable_oif/+merge/208361
[14:37] <elopio> asac: yes, we can use the autopilot job whenever they are not trying to make a release.
[14:38] <didrocks> Mirv: approved! remember you need to redeploy on q-jenkins
[14:38] <asac> elopio: sonuds like that could be mitigated through manual coordination for a few days
[14:39] <Mirv> didrocks: yes, redeployed already. thanks!
[14:39] <asac> elopio: so http://q-jenkins:8080/job/autopilot-release-gatekeeper/42/ seems to already show what tests failed
[14:40] <elopio> asac: ok, we can do that. Who should we coordinate with in order to start this job? didrocks? Or we just run it whenever we want?
[14:40] <asac> elopio: guess thats good enough from dashboard point of view
[14:40] <asac> elopio: my understanding is that this autopilot job is something that the qa tools team (thomi/veebers) is using internally, so thjink its coordinating between qt task force and autopilot tools team
[14:41] <asac> and didrocks has no stake in this
[14:41] <asac> didrocks: correct? are we using this job for anything in CI Train?
[14:41] <didrocks> Mirv: thanks to you :)
[14:41] <elopio> I'm just wondering. If this job consumes all the phones we have, and they are trying to release a new image, both jobs will take twice the time.
[14:42] <asac> elopio: yeah, i dont think thats the case. its probably consuming at most one phone at the same time
[14:42] <asac> anyway, we have to wait for doanac`/ev to comment
[14:43] <didrocks> asac: I don't, indeed
[14:43] <asac> good
[14:43] <didrocks> elopio: feel free, the pool is static
[14:43] <asac> plars: there?
[14:43] <elopio> ok, then. Thanks for the clarifications asac. Sorry for the troubles.
[14:43] <plars> asac: yes
[14:43] <asac> plars: is there a need to coordinate running http://q-jenkins:8080/job/autopilot-release-gatekeeper/42/ and image testin?
[14:44] <asac> plars: or do they use separate phones for testing and dont step on each others toe?
[14:44] <asac> (i assume its all fine, just double checking)
[14:44] <didrocks> elopio: it's another incentive to get the base image good again, to know what impacts really Qt 5.2 has :)
[14:44] <plars> asac: I'm not familiar with that job, let me look
[14:44] <asac> elopio: dont worry. if you can help fixing those flaky tests StateNotFound things it would be an amazing contribution to the qt landing effort :)
[14:45] <asac> elopio: my understanding was that you guys understood the bad coding pattern used in those tests... if not check with thomi, i believe he knows exactly what needs to be done
[14:45] <elopio> I'm trying to fix ugly tests one project at a time. There are too many.
[14:46] <elopio> asac: it's pretty obvious. There are many many steps in some of the tests, with only one assertion.
[14:46] <plars> asac: looks like it runs on a specific device, a mako
[14:46] <Saviq> om26er, rm /run/user/32011/mir_socket
[14:48] <om26er> Saviq, removing that every time is fine ?
[14:48] <Saviq> om26er, as long as unity8 isn't running
[14:48] <Saviq> om26er, or well, it might be slightly different now with system compositor, check initctl get-env --global UNITY_MIR_SOCKET
[14:49] <Saviq> om26er, as that one ↑ might be held by unity-system-compositor
[14:49] <plars> asac: that device seems to also be part of the daily smoke runs, and is in the middle of a job right now. It won't interfere with that if someone starts a new one on it, but it will be stuck in the queue until the other job finishes
[14:49] <om26er> Saviq, it directs to /tmp/mir_socket
[14:50] <Saviq> om26er, so yeah, that's the one unity8 tries to create and fails, if it's there
[14:50] <plars> asac: if you'd like, I can take this device out of the pool that runs daily smoke tests, but we're close to the end of the current run, so it would be better not to cancel it unless it's really urgent
[14:50] <om26er> Saviq, whats the solution, should we clear it when we stop unity and expect for it to be recreated when unity8 is started again ?
[14:51] <Saviq> om26er, it happens already, but it's left hanging when unity8 crashes badly
[14:52] <Saviq> om26er, so... we might be nasty and remove it in unity8's pre-start
[14:53] <Saviq> om26er, but I'm not entirely sure that's a good thing to do
[14:53] <Saviq> om26er, mir folk really didn't want that
[14:54] <asac> plars: if we have a way to allocate a separate device for the autopilot/qt job
[14:54] <asac> that would be good
[14:54] <asac> plars: but not sure what the capacity of phones in the lab is
[14:55] <asac> plars: its not urgent for sure.
[14:55] <plars> asac: yeah, I'll take care of it as soon as this current job finishes on that device
[14:55] <asac> plars: just want to ensure that the AP/qt job does not interfere with the image testing
[14:55] <plars> asac: it won't interfere for sure, but it could get delayed if, for instance, someone tried to start it right now
[14:56] <asac> right. at best there are no delays on image testing because of AP/qt job
[14:56] <asac> plars: does that increase risk that we run out of devices for image testing?
[14:56] <plars> asac: no, we have 3 other mako devices in that pool
[14:56] <asac> plars: so we will have 1 hot/spare still for image testing? and in worst case we could easily bring back the AP device, right?
[14:57] <plars> asac: exactly, we are doing pretty good on makos
[14:57] <asac> sound good
[14:57] <plars> asac: and on flo we have 3 for smoke, we only have 2 mantas and rick is working on getting those hooked up. So hopefully that one should be rolling soon too
[15:09] <psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/3/#showFailuresLink has some failures with 202. dint look each of them though
[15:09]  * didrocks needs to go for a run
[15:09] <didrocks> psivaa: do you have time to look at them? ^
[15:09] <didrocks> or plars ^
[15:09] <didrocks> maybe :)
[15:10] <plars> psivaa: what job is that?
[15:10] <didrocks> hum
[15:10] <psivaa> plars: that was a job with image 202
[15:10] <didrocks> all failures seems to be unable to unlock the scren
[15:10] <plars> psivaa: I guess you were trying new/old packages with it by hand?
[15:10] <didrocks> plars: no, only image 202
[15:11] <didrocks> but most of the tests failed
[15:11] <plars> ah, ok
[15:11] <didrocks> because can't unlock the screen
[15:13] <psivaa> didrocks: yea, sorry so that means the actual app tests have been skipped. let me run them again
[15:19] <ChrisTownsend> retoaded: Hi.  I updated the branch for https://code.launchpad.net/~townsend/nux/fix-animation-crash/+merge/208218, but I've yet to see a result from CI and I also don't see any evidence a CI job is running.  IS this because it's in the globally approved state or is there something messed up with Nux CI?
[15:23] <dbarth_> hey again, do you guys mind if i continue stacking merge proposals into an already allocated silo? (silo-005)
[15:23] <dbarth_> i know it's not helping much fix the image, but this way we can continue our tests and copy the silo ppa binaries into the SDK PPA once tests pass
[15:23] <dbarth_> (this, to be ready on time for the app showdown kickoff)
[15:30] <retoaded> ChrisTownsend, checking
[15:30] <ChrisTownsend> retoaded: Thanks
[15:31] <doanac`> asac: the autopilot-release-gatekeeper job should be able to test qt5.2 properly using the code as our daily-image testing. However, it wouldn't show up in the qa-dashboard. If that is really required, i think we need to bring in ev and priortize this effort. its something plars or myself could do.
[15:31] <plars> doanac`: I may have misunderstood, but I didn't think that's what he was asking for
[15:32] <asac> doanac`: i looked at the jenkins job. that seems good enough
[15:32] <plars> doanac`: I think he was just trying to make sure the job wouldn't stomp on daily smoke testing if they both happened at the same time
[15:32] <doanac`> plars: oh - that should be fine. our new pooling should handle things correctly. I mis-read the bug, they want dashboard-like runs. not results
[15:44] <sil2100> thostr_: hi! Is that a touch landing?
[15:45] <sil2100> thostr_: since it says 'mostly desktop' ;)
[15:45] <thostr_> sil2100: mostly, but not all
[15:45] <thostr_> sil2100: it's converged, so applicable to everything in the end
[15:47] <sil2100> didrocks: ^ can I assign a silo for those? It's line 30, it's all indicators
[15:47]  * sil2100 is normally a bit worried about those
[15:50] <Laney> sil2100: (tedg:) we were discussing fixing the OnlyShowIn lines in those yesterday, so i'm not sure they are ready
[15:53] <sil2100> Laney: ok, I'll switch it to 'Ready: No' - once there is a final decision, just switch that back to Yes and we'll see about assigning a silo ;)
[15:54] <seb128> sil2100, thostr_, Laney: changes to upstart jobs could impact on the phone I think
[15:54] <Laney> I think they break !Unity users as is
[15:54] <seb128> Laney, tedg: do we have a summary of what issues we try to address with those changes?
[15:54] <seb128> I don't understand the problem/why we change
[15:54] <Laney> didn't try to understand that part, just pushing back on the OnlyShowIn thing
[15:55] <tedg> We're fixing a couple things, but mostly it's for consistency.  For instance indicator-application is basically broken in XFCE.
[15:55] <tedg> Some indicators didn't have respawn stanzas or limits.
[15:56] <tedg> etc., etc., with that set everyone behaves the same.
[15:56] <psivaa> didrocks: so with 202 the screen unlocking still fails with a number of tests. probably some conflicting packages to what's already in 202 causing this.
[15:57] <tedg> I need to adjust the conf file slightly for the XFCE folks.  I wasn't hurrying because of no-silos.  Can do now.
[15:57] <psivaa> didrocks: because the archive has moved on and during each test we download app, test AP packages from the archive and they might clash with the versions in 202
[15:59] <retoaded> ChrisTownsend yes, the mp is already in an Approved state so will not trigger a  run.
[16:03] <ChrisTownsend> retoaded: Ok, thanks for confirming.
[16:03] <retoaded> np
[16:04] <ChrisTownsend> retoaded: Do you know if setting it back to Needs Review->Approved will trigger a CI job now that Nux is part of the CI train and automerging is disabled?
[16:04] <ogra> cyphermox, https://launchpad.net/bugs/1285146
[16:05] <doanac`> didrocks: FYI - bug 1284226 has been released. we are now doing setup/teardown for each test. this should hopefully help the ofono-simd issue
[16:05] <cyphermox> ogra: thx
[16:05] <retoaded> ChrisTownsend, yes it should.
[16:05] <ogra> cyphermox, if you need any other logs or info, just let me know
[16:06] <ChrisTownsend> retoaded: Ok, thanks.  I'll give it a try.
[16:06] <retoaded> ack
[16:11] <tedg> Laney, sil2100, seb128, Updated with the change requested by the Xubuntu folks.
[16:14] <Laney> tedg: I think you also need to fix the OnlyShowIn conditions in the xdg files (remove it?) for non-upstart folks
[16:14] <Laney> Or OnlyShowIn=GNOME;Unity;XFCE;\nAutostartCondition=GNOME3 unless-session gnome or something
[16:15] <tedg> Laney, I don't think so.  For instance if you installed Kubuntu, you wouldn't want it to launch the indicator services.
[16:15] <tedg> I don't think that GNOME wants indicator services, eh?
[16:15] <Laney> fallback sure does
[16:16] <tedg> Fallback?
[16:16] <Laney> panel
[16:16] <tedg> MATE?
[16:16] <Laney> no
[16:16] <seb128> tedg, "Ubuntu classic" if you prefer :p gnome-panel + indicators + compiz (or other wm if you prefer)
[16:17] <tedg> seb128, Laney, what does that set as its desktop session?
[16:18] <dbarth_> sil2100 or an EU guy, can i get a reconfig on silo-005?
[16:18] <dbarth_> we won't land but will use that for final tests and upload to public ppa
[16:19] <dbarth_> sil2100: that was silo-001 sorry
[16:21] <Laney> tedg: XDG_CURRENT_DESKTOP=GNOME; I think what I listed up there ought to work
[16:21] <tedg> Laney, Won't that screw Gnome Shell then?
[16:21] <seb128> tedg, GNOME atm I think, but they are talking about changing to Unity
[16:22] <tedg> Ha, I'm in the future already :-)
[16:22] <Laney> why?
[16:22] <Laney> See the AutostartCondition
[16:22] <ogra> bug 1285234
[16:23] <tedg> Laney, Doesn't that just check the desktop session to see if it's "gnome" ?
[16:23] <Laney> what more do you want to do?
[16:23] <tedg> I think you need to distinguish between not-gnome and gnome.
[16:24] <tedg> Or I guess, was-gnome
[16:24] <Laney> 'gnome' means gnome-shell
[16:24] <tedg> Yes, which is why the gnome-fallback shouldn't say that it's gnome.  It's not.
[16:24] <Laney> I'm not sure what you're talking about, I'm afraid
[16:25] <sil2100> dbarth_: looking
[16:25] <Laney> XDG_CURRENT_DESKTOP is what OnlyShowIn looks at and DESKTOP_SESSION is what the unless-session is considering
[16:25] <Laney> It's basically exactly what we're doing for gnome-screensaver already
[16:26] <sil2100> dbarth_: ok, so silo 001, right?
[16:26] <tedg> Uhg, okay.  I think that's kinda a hack.  But if it makes fallback work I don't care.
[16:27] <Laney> It's all worse than dbus activation. :)
[16:27] <tedg> DBus activation is a hack, it's hard to rank them though.
[16:28] <sil2100> dbarth_: ok, reconfiguring 001 and setting to Testing to No
[16:28] <didrocks> doanac`: excellent! so next run? :)
[16:29] <didrocks> sil2100: ask them to rerun the tests on the phone as well (unity8 in particular)
[16:29] <didrocks> sil2100: if so, ok
[16:29] <didrocks> psivaa: argh, so only click apps failed?
[16:30] <didrocks> asac: ogra: so, we can't have results on 202 either :/
[16:30] <ogra> didrocks, sad :(
[16:32] <bregma> sil2100, I can has silos for line 44 and line 45 pretty please?
[16:32] <dbarth_> sil2100: thank you
[16:35] <asac> didrocks: 202? i see results
[16:35] <asac> also its in the past
[16:37] <ogra> asac, ignore the dashboard
[16:37] <didrocks> asac: the results were partials
[16:37] <ogra> this 202 test was running on a device that isnt attached to it
[16:37] <psivaa> didrocks: not only them but also the the apps whose tests download some deps from the archive
[16:37] <ogra> asac, we were hoping we can get a gree 202 to fix the click upgrader issue
[16:37] <didrocks> psivaa: I doubt we had imcompatible changes here
[16:37] <ogra> *green
[16:37] <didrocks> asac: we wanted full results because latest image we promoted doesn't have the click upgrade UI
[16:38] <asac> didrocks: is there a way at all to get those results still?
[16:38] <didrocks> asac: that's what I was asking psivaa for, but seems not
[16:38] <ogra> asac, the original tests fell over heavily
[16:38] <ogra> so we wanted it re-tested ... but that was not a dashboard capable setup
[16:39] <ogra> and it seems it didnt work nyway
[16:39] <ogra> *anyway
[16:39] <ogra> because the click apps and autopilot are out of sync now
[16:39] <asac> psivaa: plars: can we get a rerun of 202?
[16:39] <psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/4/testReport/junit/%28root%29/camera_app/setup/ is one example
[16:39] <ogra> asac, it wont help
[16:39] <plars> asac: I think psivaa was already having one in progress
[16:40] <ogra> asac, we would have to roll back the archive ....
[16:40] <didrocks> psivaa: why can't it fetch python-gi?
[16:40] <psivaa> asac: the version that image 202 looks for is not in the archive.
[16:40] <psivaa> didrocks: ^
[16:40] <didrocks> psivaa: ah, you don't apt-get update before installing
[16:41] <psivaa> i guess we could probably force fix like apt-get update and stuff.. but that will take time
[16:41] <sil2100> bregma: looking
[16:41] <didrocks> doanac`: can you look at that? it's a valid case ^
[16:41] <didrocks> even if we still have the initial flaw, the autopilot are potentially not matching the version we have on the device
[16:41] <ogra> right
[16:42] <tedg> Laney, Updated
[16:42] <Laney> tedg: cheers, LGTM
[16:42] <Laney> I only checked the diff for bluetooth, assuming the rest are the same
[16:43] <Laney> no, wait, the second one hasn't been updated
[16:43] <sil2100> bregma: 44 assigned
[16:45] <psivaa> didrocks: i could run apt-get update and rerun the tests to see if there is any improvement but i think then the results wont exactly be that of 202
[16:46] <ogra> heh, on 209 the flo results are actually better than mako
[16:46] <ogra> (one crash less)
[16:46] <bregma> sil2100, that's the priority one, thanks
[16:47] <sil2100> bregma: 45 assigned as well o/
[16:47] <bregma> ta
[16:49] <doanac`> didrocks: catching backscroll. so we want to call: apt-get update; apt-get install <pkg> instead of just calling apt-get install <pkg>, correct?
[16:50] <didrocks> doanac`: exactly
[16:50] <ogra> but only for re-running tests
[16:50] <didrocks> psivaa: well, will still be better than no results, I don't think as long as we don't dist-upgrade that we'll have different apps
[16:50] <didrocks> yeah
[16:50] <doanac`> didrocks: sure. that's a simple change
[16:53] <plars> didrocks: asac: I thought we said before that we never want to do apt-get update during a test run, because we could pull in newer versions of things than what we want from the archive
[16:53] <plars> doanac`: ^
[16:53] <ogra> plars, right ... but this one test is a special case
[16:54] <plars> so we are talking about a one-off here, not in general
[16:54] <ogra> since it cant find a version at all for this old image if you dont run apt-get update
[16:54] <ogra> yeah, please dont apt-get update on normal tests :)
[16:54] <doanac`> ah - so we *only* do apt-get update for a "re-run"
[16:54] <ogra> yes
[16:54] <doanac`> ogra: k, thanks for the clarification. sorry i misunderstood at first
[16:55] <ogra> since for that the version in the archive can have moved forward ... so the Packages file is out of sync with the actual archive and you will get 404s
[16:55] <plars> doanac`: psivaa: I think for this one, it would be easier to just go onto the device, apt-get update, upgrade/install those specific packages, and restart the test without reinstallation
[16:55] <psivaa> ogra: doanac`: we could leave that out and may be add as a manual step not as part of the test
[16:55] <psivaa> plars: yea
[16:56] <ogra> right. or a switch or whatever
[16:56] <elopio> didrocks: now this makes more sense: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/ubuntu_clock_app/819490/
[16:56] <elopio> we are starting with no alarms, so we can't delete any of them.
[16:56] <elopio> ultimately, that's because of bug https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1275060 I'll try to fix it today.
[16:57] <ogra> the best would actually be if we could do a snapshot of the archive when we build an image and always have the test point at that
[16:57] <ogra> but thats quite some effort
[16:57] <sil2100> balloons: ping
[16:57] <sil2100> balloons: did you see my comment on the terminal-app flaky test bug?
[16:58] <didrocks> elopio: ah ok, so clock-app understood :)
[16:58] <didrocks> elopio: just all the others to understand now :p
[16:58] <didrocks> elopio: good luck, do not hesitate to answer on the phone ML
[17:00] <didrocks> asac: doanac`: hum, however, setup and teardown are counted as tests on the dashboard, is that expected?
[17:00] <elopio> :) everything - 1 to go
[17:00] <didrocks> asac: doanac`: for instance, if we can't run any application test, we have 80% of tests passing: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/ubuntu_filemanager_app/
[17:00] <doanac`> didrocks: yeah. i needed to report them now, as they could fail and we'd need to know
[17:00] <didrocks> doanac`: ok, but the count is puzzling then ;)
[17:01] <balloons> sil2100, no, I can look
[17:01] <didrocks> like 80% "not that bad", oh no test were run :p
[17:01] <sil2100> didrocks: be right there
[17:01] <doanac`> didrocks: yeah. that's a good point.
[17:01] <sil2100> Had a prank call to the door just now
[17:02] <sil2100> balloons: your theory with input events might be right according to that ;)
[17:02] <doanac`> didrocks: not sure the best way to fix that. i'll open a bug and discuss with team
[17:03] <didrocks> doanac`: thanks!
[17:03]  * balloons reads
[17:04] <balloons> sil2100, where did you find the logs you looked at? And yes I think your questions are quite valid
[17:05] <sil2100> balloons: in the smoketesting test results, the ubuntu-terminal-app application logs are attached to the AP result
[17:06] <balloons> ahh, ok
[17:11] <ogra> rsalveti, did you knwo that 4.4 changed the oomkiller ?
[17:11] <ogra> who knows, probably the breakage is related
[17:11] <rsalveti> shouldn't
[17:12] <ogra> didrocks seems ot have more info, seems to have been mentioned in some android podcast today
[17:12] <rsalveti> interesting
[17:12] <rsalveti> well, not for every kernel
[17:13] <psivaa> didrocks: so running the tests after apt-get update resolves the package mismatches but the screen unlocking still fails
[17:13] <rsalveti> on another call now, but we're still debugging the crash
[17:13] <rsalveti> it happens with SF as well, so easier to debug
[17:13] <ogra> rsalveti, yeah
[17:13] <psivaa> didrocks: ogra: i see that happened after unity 8 test runs on 202 but dont see any packages being installed just before untiy8 tests
[17:14] <ogra> weird
[17:15] <ogra> rsalveti, did you get anywhere with the non working calls on second call ?
[17:15] <ogra> or is that on hold for unity ?
[17:16] <rsalveti> ogra: fully focued on unity8, but will get to that later today for sure
[17:16] <ogra> ok
[17:16] <psivaa> and i checked unity8_7.84+14.04.20140221.orig.tar.gz was the version when we originally ran unity8 and that is the same version that the test uses now as well
[17:16] <ogra> (just was asked in the meeting)
[17:16] <rsalveti> always the feeling we're getting closer to know what is wrong
[17:16] <doanac`> psivaa, plars, didrocks: as per the misleading pass-rate calculations: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1285266
[17:17] <sil2100> rsalveti: we're keeping our fingers crossed o/
[17:17] <rsalveti> yeah :-)
[17:20] <didrocks> doanac`: thanks
[17:28] <didrocks> rsalveti: ok, so, what I mentionned during the meeting is that in the android 4.4 kitkat developer podcast (from google), they mentionned they have made adjustement to their oom killer
[17:28] <didrocks> rsalveti: (yeah, I'm listening to it while exercising)
[17:29] <didrocks> rsalveti: so, they told they are way more aggressive in killing cached applications
[17:29] <rsalveti> interesting
[17:29] <didrocks> not sure how our apps are seen on the android side as there is no onstage/cached applications notion
[17:29] <didrocks> that would map with other failures we see
[17:29] <didrocks> (no crash though)
[17:30] <didrocks> like some applications don't have any pid and the tests failed
[17:30] <didrocks> or .service don't respond
[17:30] <didrocks> asac: FYI as well ^
[17:41] <rsalveti> no pid and no crash?
[17:41] <rsalveti> but I'd guess dmesg to say something
[17:41] <rsalveti> *expect
[17:42]  * didrocks tries to refind one test
[17:44] <didrocks> rsalveti: hum, actually, maybe the dashboard was slow to update the artefacts, but I found one crash on that one
[17:44] <didrocks> let me look at other
[17:44] <didrocks> (I was looking at http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/818684/)
[17:44] <rsalveti> yeah, I'd expect at least one crash
[17:44] <didrocks> no dmesg though in artefacts :/
[17:44] <didrocks> to see if oomkiller entered into action
[17:45] <didrocks> yeah, nothing without crash in 229 or 228
[17:45] <didrocks> 209* 208*
[17:46] <ogra> 2009 2008 ?
[17:46] <ogra> :P
[17:49] <didrocks> ogra: you start trolling me again! :)
[17:49] <ogra> lol
[17:49] <didrocks> ogra: do you have a window dedicated to g+ btw? :)
[17:49] <didrocks> or even a monitor/device
[17:50] <ogra> well i read G+ before going downstairs after the meeting :)
[17:50] <didrocks> ahah :)
[17:51] <ogra> since google accounts dont really work for hangouts anymore i cant really keep a dedicated window for it anymore ... i used to do that though
[17:52] <didrocks> rsalveti: btw, finally found an official (written) source: https://source.android.com/devices/low-ram.html:
[17:52] <didrocks> "Tuned memory use of low-RAM devices: tighter out-of-memory (OOM) adjustment levels, smaller graphics caches, etc.
[17:52] <didrocks> "
[17:52] <didrocks> ogra: use 2 profiles on your browser
[17:52] <didrocks> and:
[17:52] <didrocks> "Kill processes (even ordinarily unkillable ones such as the current IME) that get too large in idle maintenance."
[17:52] <ogra> hmm, never tried that
[17:53] <ogra> didrocks, you should point ricmm and tvoss at that
[17:53] <didrocks> I think they are pinged now :)
[17:53] <ogra> might actually have impact on our app lifecycle
[17:53] <ogra> yeah :)
[17:53] <didrocks> ricmm: tvoss: backlog the last 30 lines. Basically, oomkiller changed in 4.4, so that can explain all the flakyness we start to see ^
[17:53] <rsalveti> yeah, so it's not on the kernel side
[17:53] <didrocks> it's another process we are not using?
[17:53] <rsalveti> they just changed the threshold
[17:54] <ogra> well, probably also the defaults in kernel
[17:54] <ogra> we should at least take a look
[17:54] <rsalveti> not so sure, as it's not needed
[17:54] <rsalveti> grouper kernel for example is the same old
[17:54] <rsalveti> one
[17:54] <ogra> i doubt it would affect testing
[17:54] <rsalveti> emulator as well, nothing changed
[17:54] <tvoss> rsalveti, yup, the default thresholds are adjusted
[17:54] <ogra> if it affects anything it is long running apps
[17:54] <tvoss> ogra, well, that depends on us to mark long-running correctly
[17:55] <didrocks> Don’t allow large services to put themselves back into A Services (so they can’t cause the launcher to be killed).
[17:55] <ogra> tvoss, well, if we dont change it but the kernel default does it doesnt depend on us :)
[17:55] <didrocks> not sure if we try to do that (or if it's another way of marking, only on dalvik side)
[17:56] <tvoss> didrocks, nothing about dalvik here. can you check in logcat if you see anything suspicious?
[17:56] <tvoss> ogra, ^
[18:00] <om26er> retoaded, hey! can we disable apport 'report a problem' in otto ? it comes up during our tests and causes failures
[18:19] <ogra> tvoss, http://paste.ubuntu.com/7001147/
[18:20] <ogra> (thats a flo (new N7)
[18:20] <ogra> nothing that strikes me
[18:21] <ogra> cyphermox, yay ... i got a BT indicator after the echo
[18:24] <tvoss> ogra, I see an egl context creation issue
[18:24] <tvoss> ogra, E/libEGL  ( 1762): eglMakeCurrent:775 error 3009 (EGL_BAD_MATCH)
[18:25] <plars> bfiller: any ideas on why https://jenkins.qa.ubuntu.com/job/trusty-touch-flo-smoke-daily/4/consoleFull seemed to fail out early? This was on flo
[18:26] <ogra> tvoss, hmm
[18:26] <tvoss> ogra, which process is 1762
[18:26] <ogra> tvoss, dunno, i rebooted already
[18:28] <bfiller> plars: which issue is this one?
[18:28] <bfiller> plars: hard to tell what's wrong in that massive log :)
[18:28] <plars> bfiller: I'm trying to get complete results on flo, and there were a few tests that didn't run to completion
[18:29] <plars> bfiller: ah, sorry about that - search for "testing messaging" and it should get you to the right section
[18:29] <plars> bfiller: messaging app
[18:29] <balloons> popey, davmor2, do you notice that apps tend to end white-screened after closing on the latest images?
[18:29] <bfiller> plars: ok
[18:30] <davmor2> balloons: ah so maybe not just a qt5.2.1 issue then
[18:30] <balloons> davmor2, yes, perhaps something else if you've noticed it
[18:31] <popey> balloons: davmor2 yes
[18:32] <balloons> davmor2, popey any bug, if not I guess I'll file
[18:32] <davmor2> balloons: it seems to happen on qt.5.2.1 on  209  notably on ap tests
[18:32] <balloons> I'm going to assume qmlscene
[18:32] <popey> no, i thought it was an AP "feature"
[18:32] <balloons> haha
[18:32] <davmor2> popey: I'll set thomi on you
[18:33] <bfiller> plars: do they fail if you run them manually on the device?
[18:33] <ogra> tvoss, so next boot ... http://paste.ubuntu.com/7001213/ ... pid 1734 is unity8 ... probably something for either Saviq, ricmm or the Mir team to look at
[18:33] <plars> bfiller: no idea, I don't have a flo, and my mako is tied up at the moment trying to reproduce the unlock screen errors
[18:33] <davmor2> popey: and you know he is from the mordor side of New Zealand
[18:34] <ogra> oooh intresting ...
[18:34] <ogra> pid 1759 is actually maliit-server
[18:34] <balloons> ok, so I'll check and see what it looks like
[18:34] <ogra> why does that talk directly to the driver ?
[18:35] <davmor2> balloons, popey: is one of you writing a bug for that one?
[18:35] <tvoss> ogra, it talks to libEGL
[18:35] <ogra> why ?
[18:35] <balloons> davmor2, I am.. However, it doesn't seem like the app is still running
[18:35] <ogra> shouldnt it all go through the shell ?
[18:36] <balloons> looking at the process list
[18:36] <popey> yeah, the app is finished
[18:36] <balloons> that makes sense, but ...
[18:36] <popey> it just leaves white behind
[18:36] <balloons> right.. why the white?
[18:36] <tvoss> ogra, nope, apps use egl
[18:36] <tvoss> ogra, it's not a driver in the classical sense
[18:37] <ogra> ah, k
[18:37] <bfiller> plars: I can ask osomon tomorrow to try it on flo, he's the only one on our team who has one
[18:37] <tvoss> ricmm, Saviq I see an an eglMakeCurrent failing in Unity8
[18:37] <seb128> cyphermox, hey
[18:38] <davmor2> balloons: it looks to me like the window that opens first and then you have the second or 2 wait for the app to open on it
[18:38] <plars> bfiller: thanks!
[18:39] <balloons> davmor2, popey do you only see this with autopilot?
[18:39] <davmor2> balloons: pass I've only been running ap tests
[18:39] <davmor2> let me try an app noramlly
[18:41] <popey> ditto
[18:43] <davmor2> balloons: okay so taking a quick look at the browser, if I swipe the app out of the way then close via the dash I get no issues, however if I open the hud and hit quit I briefly get a black screen in place.  So I wonder if it is the way that ap is closing the app?
[18:43] <balloons> davmor2, I assume yes. The app launch for ap changed very recently
[18:43] <balloons> I assume this is fallout, but not limited to ap
[18:45] <balloons> davmor2, popey https://bugs.launchpad.net/autopilot/+bug/1285305
[18:47] <davmor2> confirmededed
[18:48] <ogra> dededed ?
[18:48] <popey> → food
[18:58] <om26er> fginther, hello :)
[18:58] <om26er> fginther, did you get a chance to look into 'report a problem' issue in otto ?
[19:00] <fginther> om26er, can you give me some more context? I'm not sure what you are referring to
[19:01] <bfiller> om26er: hey, any idea what would cause this failure? do we need an eventually somewhere? http://paste.ubuntu.com/6993735/
[19:01] <cyphermox> seb128: hey?
[19:02] <om26er> fginther, sorry about that, in some of the cases our tests fail because the apport 'report a problem' window comes on screen, so autopilot have a way to check the before-after of the system and it sees a new window being started and not closed
[19:02] <om26er> fginther, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3116/testReport/junit/ubuntu_system_settings.tests.test_datetime/TimeDateTestCase/test_searching_tz_not_found_with_mouse_/
[19:03] <bfiller> om26er: it's timing out just trying to switch tabs, seems pretty fundamental (gallery-app)
[19:03] <fginther> om26er, I remember now. I have not had a chance to investigate yet. how often do you see this problem?
[19:03] <om26er> bfiller, i am trying to figure out, is there a way to reproduce the issue ?
[19:04] <om26er> fginther, almost everytime for ubuntu-system-settings tests
[19:04] <bfiller> om26er: I haven't been able to reproduce yet, but very reproducible on smoketests
[19:05] <om26er> bfiller, looks like tab switching went bad indeed
[19:06] <om26er> fginther, wouldn't 'sudo service apport stop' do it for us ?
[19:06] <om26er> bfiller, let me try to reproduce it on my phone
[19:07] <fginther> om26er, that should work, I just need to make sure that doesn't impact actual crash collection. I'll give this a test today
[19:07] <retoaded> om26er, fginther: sorry, I forgot to respond to the issue but I was looking into it. only one of the nodes that are specifically marked as otto nodes had apport installed/running.
[19:09] <fginther> retoaded, interesting... It's still possible that when the otto lxc container loads it re-enables apport. I'm not very familiar with how services are treated
[19:09] <fginther> retoaded, thanks for checking
[19:11] <retoaded> np
[19:12] <bfiller> om26er: weird when running the test manually it first switches to the Photos tab, then to the Albums tab
[19:13] <om26er> bfiller, thats how its supposed to work with autopilot, the tabs are switched one after the other
[19:13] <bfiller> om26er: oh
[19:13] <bfiller> om26er: thought it would swtich directly to the requested tab
[19:14] <om26er> bfiller, i am running the test, its working fine for me. going to run the suite in a loop
[19:17] <cgoldberg> robru, cyphermox, Hi.. I've got a landing for Autopilot, just added to spreadsheet (line 48) .. can i get a silo allocated today for that?
[19:17] <cyphermox> cgoldberg: IIRC only if it fixed current known regressions
[19:17] <cyphermox> *fixes
[19:18] <thomi> cyphermox: we have a FFE, and it contains bug fixes - is that enough, or...?
[19:18] <cyphermox> it's slightly unclear to me, is this the fix for the state not found thing?
[19:18] <thomi> cyphermox: no
[19:19] <cyphermox> thomi: as I recall, didrocks mentioned we were mostly looking at fixing the things that are currently broken in the image
[19:19] <cyphermox> I can allocate, but we won't publish it
[19:20] <thomi> cyphermox: thanks. Hopefully by the time we're done with the testing the image will be fixed.
[19:20] <cyphermox> hmm
[19:20] <cgoldberg> cyphermox, cool.. that would help
[19:20] <cyphermox> checking, perhaps it's even "don't allocate" from the message I had yesterday
[19:20] <cyphermox> the problem is, if you have that assigned and then you want to land the fix for the state thing, then we won't be able to
[19:21] <cyphermox> robru: what do you think?
[19:21] <thomi> cyphermox: why not? Can't we just add additional MPs to the silo and re-spin?
[19:21] <thomi> err, re-allocate.. or whatever it is you guys do :)
[19:23] <ogra> cyphermox, https://code.launchpad.net/~ogra/ubuntu/trusty/bluetooth-touch/add-flo/+merge/208461 for you
[19:25] <asac> cyphermox: thomi: think adding new MPs for components is fine. just remember that there is risk that as part of getting image fixed we might to invalidate silos as we have to shovel a cherry pick in or land something that makes you need to retest everything.
[19:25] <thomi> asac: sure, thanks.
[19:25] <asac> thomi: anyway, please get the state not found thing sorted. seems that elopio didnt know what to do to fix things
[19:25] <cyphermox> that's what I meant
[19:25] <ogra> cyphermox, note that this MP also fixes a test failure on flo (BT indicator in unity8) so it should be fine to land it at any time
[19:26] <thomi> asac: elopio just told me that it's fixed already
[19:26] <asac> thomi: or has a different order of fixing bad tests than the ones that show problems
[19:26] <asac> oh
[19:26] <thomi> asac: elopio is the guy you want to talk to about that :)
[19:26] <asac> thomi: where is it :)
[19:26] <cyphermox> ogra: actually, no
[19:26] <asac> thomi: i talked today and the above is what i last heard
[19:26] <ogra> cyphermox, why no ?
[19:26] <asac> elopio: there :)?
[19:26] <ogra> cyphermox, works fine here
[19:26] <asac> elopio: gimme MPs that have the fixes
[19:27] <cyphermox> ogra: we discussed dropping any device-specific jobs, there is a better way to do this that should work on all devices just the same
[19:27] <ogra> cyphermox, the chipset is the same as on mako and uses the same way of initialization
[19:27] <elopio> thomi: asac, I said that I'm not able to reproduce the StateNotFound errors that we got on image 206, and more recent images don't show StateNotFound errors.
[19:27] <cyphermox> yes
[19:27] <elopio> so whatever was causing it, seems to be fixed now.
[19:27] <cyphermox> ogra: but you shouldn't have to poke hci_smd_set yourself either
[19:27] <ogra> cyphermox, and we try to get to green images again
[19:27]  * asac checks
[19:27] <cyphermox> ogra: gosh, I hadn't thought of this
[19:27] <cyphermox> ogra: give me a minute
[19:27] <ogra> if you want to rework the whole way of starting thats fine
[19:27] <elopio> asac: the errors we are getting now make more sense, and I'm slowly working on them. First, the clock needs to create an alarm before deleting it.
[19:28] <ogra> my MP is good as an interim fix to get one failure down
[19:28] <asac> elopio: here is what didrocks sent around a bit earlier: "Work is going on. Leo wasn't able to reproduce it, some back and force on the mail comments shed some lights (with a whole list of tests that failed on #206, #207 and #208."
[19:29] <cyphermox> ogra: then don't bother sending an MP and just push it if that's what you'd prefer...
[19:29] <asac> elopio: ok you rock. sorry for making unqualified commments.
[19:29] <ogra> cyphermox, well, its your baby, i'd like you to nod it off :)
[19:29] <ogra> and its in CI, isnt it ?
[19:31] <cyphermox> ogra: I don't remember
[19:31] <ogra> heh, k
[19:31] <cyphermox> heh, whatever
[19:31] <ogra> root@ubuntu-phablet:/# grep hcismd_set /var/lib/lxc/android/rootfs/* 2>/dev/null
[19:31] <ogra> root@ubuntu-phablet:/#
[19:31] <ogra> cyphermox, ^^^
[19:32] <ogra> i fear there is nothing on the android side touching that
[19:32] <ogra> guessing there is some UI tool that does the echoing
[19:32] <cyphermox> ogra: there should have been
[19:32] <cyphermox> but I guess for that particular device bludroid does it now
[19:32] <ogra> well, not in the init.*.rc files
[19:32] <cyphermox> >.<
[19:32] <cyphermox> I can read
[19:33] <cyphermox> approved
[19:33] <ogra> well, i wonder if bludroid does it for all 4.4 devices now ...
[19:33] <cyphermox> I don't really want to mess with this right now
[19:33] <ogra> then we would have that issue on all of the,
[19:33] <ogra> ok, i'll just uplaod then
[19:33] <cyphermox> yeah
[19:34] <cyphermox> apparently it's hard for android to decide how they want to do stuff
[19:34] <ogra> :)
[19:35] <seb128> cyphermox, hey!
[19:35] <cyphermox> ogra: the end result will have to be that we make the bluetooth.status job or whatever seems to be the "standard" on 4.4 do the /sys/module poking and just start the *.bt.sh job and then that one
[19:35] <seb128> cyphermox, can I haz slots?!
[19:35] <seb128> ;-)
[19:35] <cyphermox> ogra: but I guess that will be for laterz
[19:35] <seb128> cyphermox, l46&47
[19:36] <ogra> cyphermox, yeah
[19:36] <cyphermox> seb128: shouldn't this stuff be blocked by beta?
[19:36] <seb128> cyphermox, there is no such thing as proposed block
[19:37] <seb128> cyphermox, we stopped blocking upload, we just block britney/transitions to trusty
[19:37] <cyphermox> yes, I know
[19:37] <cyphermox> just saying
[19:38] <ogra> bt-touch uploaded
[19:39] <ogra> one failure down on flo :)
[19:39] <ogra> only 3164323 left
[19:39] <ogra> :P
[19:40] <rsalveti> ogra: at least we just found out that the unity8 crash is not only happening with unity8
[19:40] <rsalveti> it seems to be qt related somehow
[19:40] <rsalveti> the crash we got with unity8, gallery-app and weather-app (qmlscene) are all the same
[19:40] <ogra> rsalveti, well, did you see my discussion with tvoss above
[19:40] <ogra> there seem to be EGL issues too
[19:41] <cyphermox> ogra: cool
[19:41] <rsalveti> ogra: which issues?
[19:41] <ogra> rsalveti, http://paste.ubuntu.com/7001213/ EGL_BAD_MATCH ...
[19:41] <rsalveti> we always had one error
[19:41] <ogra> rsalveti, pid 1734 is unity8 ... 1759 is maliit--server
[19:41] <ogra> ah, k
[19:41] <rsalveti> but don't know which one :-)
[19:41] <ogra> heh
[19:41] <rsalveti> ogra: check your mako
[19:42] <rsalveti> ogra: should happen for every app you load
[19:43]  * ogra notices that he cant fing his mako 
[19:43] <ogra> argh !
[19:44] <ogra> damned ... that slippery thing always slides down where i put it ... and then vanishes between some papers or so
[19:44] <ogra> grrr
[19:44] <rsalveti> hahah
[19:55] <Saviq> tvoss, there *was* a bug I believe
[19:55] <tvoss> Saviq, hmmm ... worth investigating?
[19:55] <ralsina_> robru: can I get a reconfigure for silo 14? I added a new branch https://code.launchpad.net/~dobey/unity-scope-click/post-method/+merge/208210
[19:55] <ralsina_>  to the spreadsheet
[19:56] <robru> ralsina_, sure
[19:56] <Saviq> tvoss, isn't it the one when your screen was off?
[19:56] <robru> ralsina_, please just space-separate the URLs though
[19:56] <ralsina_> robru: ok
[19:57] <tvoss> Saviq, hmmm, good point
[19:57] <tvoss> Saviq, what about the egl swap interval thingy?
[19:57] <ralsina_> robru: fixed
[19:57] <tvoss> Saviq, also: you might want to spin a build of u8 with address sanitizer enabled
[19:57] <Saviq> tvoss, https://bugs.launchpad.net/unity8/+bug/1261466
[19:57] <tvoss> Saviq, haven't come to it, yet
[19:58] <robru> ralsina_, ok, please build
[19:58] <Saviq> tvoss, what about the swap interval thingy?
[19:59] <tvoss> Saviq, there is an error reported here: http://paste.ubuntu.com/7001147/
[19:59] <ralsina_> robru: started, thanks
[19:59] <robru> ralsina_, you're welcome
[20:01] <tvoss> Saviq, line 427ff
[20:01] <Saviq> ETOOMANYLINES
[20:02] <Saviq> tvoss, not sure what to do about that, is that happening at the same time the eglMakeCurrent, or?
[20:02] <tvoss> Saviq, might well be ...  hang on, got a theory
[20:08] <rsalveti> ogra: the unicode error http://paste.ubuntu.com/7001623/
[20:08] <rsalveti> this is when running tests with flo
[20:09] <ogra> rsalveti, yeap, seen that
[20:09] <ogra> (and i have seen that before too ... like months ago ... and i know someone fixed it ... but cant remember when or who)
[20:09] <ogra> (or where even)
[20:09] <rsalveti> right
[20:09] <rsalveti> was happening a few weeks ago
[20:10] <ogra> yep
[20:19] <cgoldberg> cyphermox, line 16, windowmocker.. is that landing today?
[20:22] <bfiller> om26er: any luck reproducing?
[20:22] <om26er> bfiller, not in a reproducible fashion, I ran the whole suite and one one of the tests failed with a similar error message from dbus
[20:23] <asac> cyphermox: can you easily see how many silos are currently loaded?
[20:23] <asac> kgunn: how many silos do you have in theory ready for landing?
[20:23] <om26er> bfiller, let me inspect the test code, I might find something there
[20:24] <cyphermox> asac yes
[20:24] <cyphermox> http://calypso.cyphermox.net/~mtrudel/silos/
[20:24] <cyphermox> I made myself a graph
[20:24] <cyphermox> it updates every hour
[20:24] <asac> cyphermox: ok, i think i am interested in loaded and green :)
[20:24] <asac> hehe
[20:24] <asac> always more and more
[20:24] <cyphermox> bah
[20:24] <bfiller> om26er: ok thanks, yes I see the same failure in another gallery-app test from the nightly build: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/818684/
[20:25] <om26er> bfiller, I saw the failure in test_add_photo as well
[20:25] <cyphermox> cgoldberg: I guess it could land today
[20:29] <kgunn> asac: actually i have a question about that...
[20:29] <kgunn> i have 1 unity-mir silo
[20:29] <kgunn> but...
[20:29] <kgunn> i really would like a silo in preparation for landing to begin...i'd like to have one for mir ?
[20:30] <kgunn> is it possible?
[20:30] <asac> kgunn: so we need fast path silos
[20:30] <asac> we have 17 allocated already.
[20:30] <asac> dont think we can really hand out more new ones :( ... otherwise we cant land the fixes for the regressions quickly once they came in
[20:30] <asac> come in
[20:31] <kgunn> ack
[20:31] <asac> kgunn: we probably could hand out one more ...
[20:32] <asac> i would really like to see this unity8 heap crash fixed somehow. from what i understand its 40% chance of being mir and 30% chance of being android 4.4 and the rest something else
[20:32] <kgunn> it'd be great if i got a silo
[20:32] <kgunn> i'm following phablet as well...seems like
[20:33] <asac> cyphermox: did anyone request a silo today?
[20:33] <kgunn> there's lots of suspiscions around TLS and hybris
[20:34] <asac> kgunn: so problem is that if a patch with mir comes out that fixes this, we would have to invalidate all your work if we want to land that cherry pickish
[20:34] <ogra> there is a long discussion about this going on atm on the internal channel (for whatever reason)
[20:34] <kgunn> ack, happy to be invalidated if its mir's fault
[20:36] <asac> kgunn: let me wait on what cypher says about my question above.
[20:36] <asac> need to be somewhat fair
[20:36] <kgunn> yep...thanks for trying at least
[20:37] <asac> bfiller: how many silos do you have loaded?
[20:38] <cyphermox> asac: yes, cgoldberg and seb128
[20:38] <asac> cyphermox: which landing topic?
[20:38] <cyphermox> 46, 47, 48
[20:38] <asac> isnt cgoldberg autopilot?
[20:38] <cyphermox> you didn't specify
[20:39] <asac> me didnt specify?
[20:39] <bfiller> asac: you mean how many outstanding requests do we have in the train?
[20:39] <bfiller> asac: I think 4 or 5
[20:39] <cyphermox> yes, autopilot, unity-control-center and dbustest-runner
[20:40] <asac> bfiller: how many silos do you have loaded and validated
[20:40] <asac> or in progress
[20:40] <asac> cyphermox: ok, but those got a silo it seems? i was interested if we rejected requests for new silos
[20:41] <bfiller> asac: none loaded and validated, many waiting for silos
[20:44] <asac> bfiller: think you are close to gallery or dialer fix?
[20:45] <asac> those are the ones you investigate right?
[20:45] <bfiller> asac: om26er helping with gallery, just sent an email about that. I don't know how to proceed on that one
[20:45] <bfiller> looks like Chris gagnon just pushed a fix for some dialer-app flakiness
[20:46] <bfiller> asac: we can release that
[20:46] <om26er> bfiller, btw there is also a gallery-app.crash file as well so the app might have crashed
[20:46] <om26er> http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/
[20:46] <asac> bfiller: ok cool. you could piggyback your other landings in that landing
[20:46] <asac> :)
[20:47] <asac> as an idea
[20:47] <asac> e.g. make one big silo request that also includes that fix... but please be extra careful about regressions in those other apps
[20:47] <asac> bfiller: what do you think?
[20:48] <bfiller> asac: yeah, was thinking that. but we have a bunch of other changes queued. might be better to just do the AP test fix first
[20:48] <bfiller> asac: just so we don't introduce any other weirdness
[20:49] <asac> dbarth_: i see you have two silos... are you still working on 005?
[20:50] <asac> bfiller: yeah, was just thinking how i can jusfity get your other stuff moving. but guess i would get harangued for such a move anyway
[20:50] <asac> bfiller: so for sure, if there is a dialer fix, land that asap
[20:50] <dbarth_> asac: 001 could land and free that slot; testing is finished
[20:50] <bfiller> asac: ok
[20:51] <asac> dbarth_: we cant really land
[20:51] <dbarth_> i know
[20:51] <asac> dbarth_: but want to ensure that others can continue preparing
[20:51] <asac> dbarth_: whats 001 about?
[20:51] <dbarth_> but if you want to recycle a ppa, can you take 005, but not 001 please
[20:51] <dbarth_> 001 i will use to do pkg copies to the sdk
[20:52] <asac> dbarth_: will surely not recycle a ppa that is validated. dont worry
[20:52] <asac> dbarth_: just wonder if 005 is still being worked on
[20:52] <dbarth_> ok
[20:52] <asac> if you are active on that one i dont want to take that away
[20:52] <asac> dbarth_: can you explain to me more about 001?
[20:52] <asac> dbarth_: is that a landing in the centre of the stack?
[20:53] <asac> or rather a leave component?
[20:53] <asac> guess its not fully leave
[20:53] <om26er> bfiller, yes, the time stamps of the .crash file and our ci dashboard match exactly at the same time. the app crashed at 12:42:11 and just 1 second before autopilot raised that error
[20:55] <bfiller> om26er: interesting
[20:55] <asac> robru-sick: 006 is in proposed?
[20:56] <bfiller> asac, robru: line 50 of the sheet has fix for dialer-app tests
[20:57] <asac> cyphermox: ^^
[20:57] <bfiller> at least some
[20:57] <asac> bfiller: good
[20:57] <asac> thanks!
[20:57] <asac> cyphermox: can you check if 006 is alreayd in release pcket?
[20:58] <asac> robru-sick: cyphermox:  bregma: isnt 008 ready for landing?
[20:58] <asac> seems desktop only
[20:58] <asac> same for 009
[21:02] <asac> robru-sick: can we recyclke your cordova cli ppa?
[21:21] <robru-sick> asac, oh, yeah
[21:21] <bregma> 0002 and 008 are definitely ready for landing, both exclusively desktop only
[21:21] <robru-sick> bregma, ok, desktop only we can do
[21:21] <asac> robru-sick: cyphermox: ^ ... not sure if there is a directive to not land these, if not, lets do it and make room for kgunn and bfiller
[21:21] <robru-sick> asac, only touch is frozen as far as i know
[21:21] <asac> bregma: do you have more in the pipe to land right after?
[21:21] <bfiller> om26er: I downloaded the crash file and installed apport-retrace on the device
[21:21] <bfiller> om26er: getting this error when I try to run it: apport-retrace -s _usr_bin_gallery-app.32011.crash
[21:21] <bfiller> ERROR: report file does not contain one of the required fields: CoreDump DistroRelease Package ExecutablePath
[21:21] <bfiller> om26er: how do I get the backtrace from the crash file?
[21:22] <robru-sick> bfiller, what's the status of that MP in line 3? will you ever land that? if not, please delete the row
[21:22] <om26er> bfiller, we can probably try to report that bug to launchpad and it may retrace it for us
[21:22] <sergiusens> robru-sick, it will land, but needs unity8
[21:22] <sergiusens> it's in blockade mode now; right?
[21:22] <bfiller> robru-sick: I think it's still valid
[21:23] <robru-sick> bfiller, oh ok, i thought it was abandoned. didn't realize you still wanted to land it eventually. thanks
[21:23] <bfiller> robru-sick: yeah, just didn't want to land it at the time to not interfere with other MR's and possibly break something
[21:23] <bfiller> sergiusens: you ever use apport-retrace with a crash file from smoketests?
[21:23] <sergiusens> robru-sick, we need to reconfigure it with unity8 though
[21:24] <sergiusens> bfiller, nope
[21:24] <robru-sick> sergiusens, no worries
[21:24] <bfiller> om26er: would you mind doing that? we need the trace to figure out what's going on
[21:25] <sergiusens> bfiller, there's an email from ev titled "Manually retracing crashes on Touch images" on the phone list though
[21:25] <om26er> bfiller, trying to do that but seeing problem here as well
[21:25] <asac> robru-sick: did you see bfillers silo request?
[21:25] <asac> oh i see you chattin gwith him
[21:25] <robru-sick> asac, on it
[21:25] <sergiusens> bfiller, it might be an incomplete crash
[21:25] <asac> robru-sick: seems he submitted a regresison fix
[21:26] <asac> e.g. flaky
[21:26] <robru-sick> bfiller, ok you got silo 13 for dialer-app
[21:27] <bfiller> robru-sick: thanks
[21:27] <robru-sick> bfiller, you're welcome
[21:28] <asac> robru-sick: the other question was whether 006 is already in release pocket and could be merged back
[21:29] <asac> seems not
[21:29] <asac> or maybe the status in that sheet is off
[21:29] <asac> robru-sick: actualy, is that in for a day already? (e.g. 006)
[21:30] <robru-sick> asac, yes, that got in yesterday.
[21:30] <asac> robru-sick: so we can recycle 006?
[21:30] <robru-sick> asac, yes, but bzoltan will be upset about it.
[21:30] <asac> e.g. you have to hit merge and clean? please triple check. the commit message in MP looks different
[21:30] <asac> bzoltan: show up
[21:37] <asac> robru-sick: but there is no way back anyway
[21:37] <asac> feels odd
[21:37] <asac> let me find someone from sdk team
[21:37] <robru-sick> asac, agreed, it's weird to have a published silo go unmerged for so long
[21:37] <robru-sick> asac, i guess i should just merge it, and if sdk team finds some problem with the code, we can rush through whatever fixes they feel appropriate.
[21:37] <asac> give me a sec
[21:37] <robru-sick> ok
[21:38] <asac> robru-sick: ok go ahead and hit the button. next time dont do that without sdk folks unless its a firedrill thingy
[21:39] <asac> kaleo gave an ack
[21:40] <asac> robru-sick: ok cool
[21:40] <asac> robru-sick: so 006 is free then afterwards
[21:40] <asac> also we have two silos freed by bregma
[21:40] <asac> lets give kgunn and bfiller each one
[21:41] <robru-sick> asac, ok sorry, thought it was a firedrill situation ;-)
[21:41] <asac> bfiller: do you wnt to change your landing request to just include all that you want to land
[21:41] <asac> bfiller: if you merge them you can have everything in one silo
[21:41] <asac> bfiller: (except the dialer-app which has its own silo)
[21:42] <bfiller> asac: sure, so combine all requests into one? (except dialer-app)?
[21:42] <asac> bfiller: i would think in this way you can at least continue staging changes for those apps there
[21:42] <asac> and hav ea place to basically maintain a temp branch for all
[21:42] <asac> bfiller: risk is tha tif one app is infected and you notice dduring testing you have to ask to drop that
[21:42] <asac> and rebuild everything
[21:43] <asac> bfiller: oh wait
[21:43] <asac> bfiller: at best dont put an app in that is currently named as flaky
[21:43] <asac> i would like to see if we can land green apps tomorrow
[21:43] <asac> even if the image isnt good yet
[21:43] <om26er> bfiller, you need apport-retrace -sR
[21:44] <robru-sick> bfiller, kgunn just ping me when your requests are ready to be assigned.
[21:44] <kgunn> cool thanks guys
[21:44] <asac> robru-sick: lets keep one of the freed silos for bregma/desktop landings ... e.g. jus thandout one for bfiller and one for kgunn after those three are freed
[21:44] <kgunn> robru-sick: sorry you're sick...
[21:45] <robru-sick> kgunn, thanks
[21:45] <asac> robru-sick: 002 008 and 006 (after the merging)
[21:45] <bfiller> asac, robru-sick : ack, let me review what I have in the pipeline and rearrange into one
[21:45] <bfiller> om26er: thanks, trying
[21:45] <asac> kgunn: bfiller: so 006 will be avail really soon. 002 and 008 will only happen after stuff is through proposed
[21:45] <asac> you guys decide who goes first :)
[21:46]  * ogra waits for asac to hand out boxing gloves
[21:46] <asac> think bfiller could potentially land green apps tomorrow potentially
[21:46] <asac> so maybe maybe he might be the one that could benefit the most from being ready today
[21:46] <asac> (but no promisses)
[21:46] <kgunn> bfiller: you can rock n roll first if you wnat
[21:47] <seb128> asac, there is a flag to ignore the "going through proposed" step if you want, I'm using it for desktop stuff atm, beta freeze keeps stuff even if they are ready, no reason to not merge back
[21:47] <asac> seb128: i think our touch stuff goes in by bot
[21:47] <asac> not?
[21:48] <ogra> it does
[21:48] <seb128> "in by bot"?
[21:48] <ogra> just not the stuff that overlaps with desktop/flavours
[21:48] <seb128> right
[21:48] <asac> seb128:  we have an auto approve bot
[21:48] <asac> so i think lets not use this option
[21:48] <seb128> well, you can clean the silo even if stuff are still in proposed, that's on box to click on
[21:48] <seb128> no we don't
[21:48] <asac> yeah good to know
[21:49] <asac> oh right its bregma :)
[21:49] <seb128> we have to click a "clean and merge back" button
[21:49] <asac> so yeah lets use that for those landings
[21:49] <seb128> right
[21:49] <seb128> no reason the unity8 session needs to lock a silo
[21:49] <seb128> just merge back
[21:49] <bregma> it's having trouble merging back, seems to want to push to the wrong place
[21:49] <asac> robru-sick: ^^ thast valid for 002 and 008 i guess.
[21:50] <robru-sick> asac, ok, on it
[21:50] <asac> bregma: hmm
[21:50] <seb128> bregma, where?
[21:50] <seb128> hum, weird
[21:50] <bregma> 2014-02-26 21:47:45,715 INFO Trying to push to https://code.launchpad.net/~bregma/unity8-desktop-session/trunk
[21:51]  * bregma is resigned to forever have problems
[21:51] <bregma> the merge is not lost, so I'll go ahead and clean the silo, I;m done with it
[21:52] <seb128> bregma, trunk is owned by you, whoever set that project up didn't do the checking it seems, the jenkins bot needs commit access to the trunk
[21:52] <bregma> the merge can get clean up later
[21:52] <robru-sick> bregma, well, the problem there is that you personally own lp:unity8-desktop-session, so citrain doesn't have permission to push there
[21:52] <bregma> doesn;t make sense why that would be, but I'll figure it out
[21:52] <seb128> bregma, https://code.launchpad.net/~bregma/unity8-desktop-session/trunk
[21:52] <seb128> that's owned by you
[21:53] <seb128> lp:unity8-desktop-session
[21:53] <robru-sick> bregma, well when you created the project, you would have set up the trunk branch as a branch that you owned, instead of a team-owned branch
[21:53] <bregma> I understand that's how it looks, but I'm fairly sure I didn;t do that, I must have messed it up some other way
[21:53] <bfiller> om26er: getting corrupted stack trace, nothing useful from it
[21:53] <bregma> doesn;t matter, I can recover
[21:53] <om26er> darn!
[21:54] <om26er> bfiller, maybe try the crash file from the other failure ?
[21:54] <robru-sick> bregma, please take this branch specifically: https://code.launchpad.net/~ps-jenkins/unity8-desktop-session/latestsnapshot-recup and push it to something like lp:~unity8-team/unity8-desktop-session/trunk and then reconfigure the lp project trunk to point at that
[21:54] <bfiller> om26er: I tried both
[21:54] <om26er> :/
[21:55] <om26er> bfiller, thats basically a dead end
[21:55] <bfiller> om26er: wondering if this might be the same crash that dialer experiences due to unity-mir bug
[21:55] <om26er> bfiller, no, thats probably a different crash, with different symptoms
[21:56] <bfiller> om26er: this the bug I'm talking about https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1240400
[21:57] <bfiller> om26er: basically we need to be able to reproduce the crash on a device to see what's going on I think
[21:57] <bfiller> om26er: going to try and reflash with 209 image and try again with that latest crash file
[21:58] <om26er> bfiller, dialer-app handles that crash through an exception, it happens on the end of the test normally but yess we need to see on the phone what really happens
[21:58] <bfiller> om26er: can you get it gallery to crash when you run in a loop or run the entire suite on the device?
[21:59] <om26er> bfiller, it failed once, so not exactly reproducible but it did happen, i'll run it again
[21:59] <bfiller> om26er: run "ulimit -c unlimited" first from a shell before you start the tests
[21:59] <bfiller> that way a core file will be gerneated if crash
[22:00] <bfiller> sergiusens: what's the new command to reflash with the 4.42 based image?>
[22:00] <bfiller> can't keep track of it all
[22:00]  * bfiller getting old
[22:00] <ChickenCutlass> bfiller: just use devel-propsed
[22:00] <bfiller> ChickenCutlass: phablet-flash?
[22:01] <ChickenCutlass> bfiller: ubuntu-device-flash -channel=devel-propsed
[22:01] <bfiller> ChickenCutlass: as I said, thanks
[22:02] <asac> bregma: i guess you should merge manually and then move the trunk to a better team
[22:02] <asac> not exactly sure what rules to obey for the merging though, but maybe seb128 knows
[22:03] <seb128> seems like bregma figured it out, the silo is being cleaned (didrocks included enough checkboxes/override in the system to let us unblock)
[22:03] <robru-sick> asac, no need to merge manually, merged branch exists at https://code.launchpad.net/~ps-jenkins/unity8-desktop-session/latestsnapshot-recup already
[22:10] <bfiller> robru-sick: silo 13 tested, ready to be released
[22:11] <om26er> bfiller, I have been able to reproduce the crash with albums tests here. what happens is that its able to switch to the albums tab but that tab is shown empty, i.e. no buttons on the toolbar and neither is there any 'dummy' album shown
[22:11] <om26er> and after a few seconds ofcourse the app has to go
[22:12] <bfiller> om26er: cool, did it generate a core file?
[22:12] <om26er> bfiller, i see a core on /home/phablet
[22:13] <bfiller> om26er: try running "gdb /usr/bin/gallery-app core"
[22:13] <bfiller> om26er: then "bt" once in gdb
[22:14] <om26er> bfiller, says corrupt stack
[22:14] <bfiller> (:
[22:14] <asac> robru-sick: oh nice
[22:14] <bfiller> om26er: can you tell me how to reproduce the crash?
[22:14] <asac> nice feature
[22:15] <om26er> bfiller, run this multiple times. autopilot run gallery_app.tests.test_album_view
[22:16] <bfiller> om26er: let me try
[22:16] <om26er> bfiller, i reported a crash report from the file https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1285387
[22:16] <om26er> but its pretty much going to be useless as well
[22:20] <robru-sick> bfiller, thanks
[22:48] <sergiusens> bfiller, might want 't a a bt' for a bigger picture view
[22:48] <bfiller> sergiusens: I've tried that
[22:48] <sergiusens> are looking at the crash on start?
[22:48] <sergiusens> bfiller, cause rsalveti was thinking that they all have the same root cause
[22:48] <bfiller> sergiusens: no, just a very hard to reproduce autopilot failure on gallery tests
[22:49] <sergiusens> ah, ok
[22:49] <bfiller> sergiusens: don't think it's on startup though
[22:49] <bfiller> sergiusens: http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/gallery_app/
[22:49] <rsalveti> sergiusens: bfiller: it's the same one
[22:49] <rsalveti>   #0 0x3810d8f8 in ?? ()
[22:49] <rsalveti> that's the same offset we get with the qmlcrash and unity8
[22:50] <bfiller> rsalveti: really?
[22:50] <rsalveti> yes
[22:50] <rsalveti> v8 code
[22:50] <rsalveti> qt v8
[22:51] <bfiller> rsalveti: you're looking at the .crash file?
[22:51] <rsalveti> bfiller: stack trace
[22:51] <rsalveti> bfiller: happens when you start gallery-app
[22:51] <rsalveti> same for qmlscene and unity8
[22:51] <bfiller> rsalveti: how do you reproduce?
[22:52] <bfiller> I can't make it happen
[22:52] <rsalveti> bfiller: open/close it until you get it
[22:52] <rsalveti> yeah, it's painful
[22:52] <rsalveti> and not going to help you either
[22:52] <rsalveti> we're debugging this crash like 2 days already
[22:52] <rsalveti> doesn't happen with qt5.2 though
[22:52] <bfiller> I guess that's good
[22:52] <bfiller> move on then
[23:00] <bfiller> rsalveti: is the dialer-app crash the same too?
[23:01] <rsalveti> bfiller: check the stacktrace
[23:01] <bfiller> rsalveti: k
[23:01] <rsalveti> if it ends with d8f8, then yes
[23:01] <ChickenCutlass> rsalveti: if this crash does not happen with 5.2
[23:02] <ChickenCutlass> why are we wasting time
[23:02]  * ChickenCutlass is confused
[23:07] <bfiller> ChickenCutlass: +1
[23:07] <bfiller> move one
[23:07] <bfiller> on
[23:33] <bfiller> robru-sick: per asac earlier, I've combined a few asks into line 36. so that is ready for a silo
[23:42] <robru-sick> bfiller, alright
[23:43] <kgunn> fginther: surely you're eod....
[23:43] <kgunn> but whoever is taking up vanguard
[23:44] <kgunn> i've been hawking this for a while
[23:44] <kgunn> https://code.launchpad.net/~afrantzis/mir/update-valgrind-armhf-suppressions/+merge/208421
[23:44] <kgunn> and jenkins seems to be ignoring
[23:44] <kgunn> i suppose i can manual merge...but
[23:44] <kgunn> stepping away, bbiab
[23:44] <robru-sick> bfiller, ok you got silo 2, please build.
[23:48] <bfiller> robru-sick: ack
[23:51] <bfiller> robru-sick: argh, merge failure
[23:52] <bfiller> robru-sick: will try and resolve later, dinner now