=== jhodapp is now known as jhodapp|afk [02:05] === trainguard: IMAGE 276 building (started: 20140404 02:05) === [03:26] morning [03:28] popey: music-app 409 uploaded https://myapps.developer.ubuntu.com/dev/click-apps/143/ [03:35] === trainguard: IMAGE 276 DONE (finished: 20140404 03:35) === [03:35] === changelog: http://people.canonical.com/~ogra/touch-image-stats/276.changes === [03:36] ... and flashing. [06:02] Mirv: hey, can you do me a favor? [06:05] didrocks: what kind of? [06:06] (but sure) [06:07] veebers: hi. you've marked autopilot as being tested. so zero failures on the image testing suite of APs with the new autopilot now? [06:08] Mirv: it seems that the AP tests on the image is stuck in the reboot [06:09] Mirv: can you start from that? [06:09] don't rerun the ones that already rerun [06:09] (maybe just rerunning the unity8 to be sure) [06:09] Mirv: you can maybe double check the new AP that way :) [06:12] didrocks: right, we've partial results. and that's what I was thinking, adding the new autopilot into the mix... [06:12] yep, makes sense, initiaintg [06:12] Mirv: thanks a lot dude :) [06:12] Mirv: that way, we'll get results from latest image + AP [06:17] hi! [06:17] may I have a silo for apparmor? (line 54 in pending) [06:18] jdstrand: sure [06:19] fyi, the landing will happen pretty quickly cause we've built everything in the security-proposed ppa and it is already tested [06:19] jdstrand: you got the best one, landing-001 [06:20] \o/ [06:20] thanks :) [06:20] np [06:23] (and in case I wasn't clear, I'm pocket copying those without rebuilding) [06:23] (like I normally do) [06:28] jdstrand: once you copy pocket, just a reminder to run "build" with "watch only" (and look at the job that it picks your packages) [06:29] Mirv: maybe ensure your /var/crash is empty btw when running the unity8 tests [06:31] good idea [06:34] didrocks: ack [06:53] ogra_: not sure where you were with the bisecting (didn't see the script on the ML nor progress, I could have restarted this morning from where you left of…) [07:12] jdstrand: you can self-publish I guess :) [07:12] didrocks: yes, I just tried, but I never seem to do this right [07:12] eg [07:12] https://ci-train.ubuntu.com/job/landing-001-2-publish/3/console [07:13] jdstrand: let me look :) [07:13] I ACK_PACKAGING, then Build [07:13] s/I/I did/ [07:13] jdstrand: yeah, all sounds good, I think you triggered a bug… (never saw that one) [07:13] jdstrand: let me one minute so that I can fetch the status [07:14] jdstrand: "sources": ["apparmor", "", "lxc", "", "libvirt", "", "lightdm", "", "apparmor-easyprof-ubuntu"] [07:14] (this is fetched from the spreadsheet [07:15] I think there is a safeguard missing when iterating over your cell [07:15] oh, did I not format it right? [07:15] I guess if I removed the spaces, it would work? [07:15] jdstrand: the main format is space separated, but I tried to support this one as well [07:15] jdstrand: you have an override even to avoid a reconfigure [07:16] not sure how it will handle those weird entries, but worth a try :) [07:16] jdstrand: try IGNORE_MISSINGPROJECTS [07:16] (that should say "yeah, I know, some projects are missing in the publication, go ahead") [07:17] jdstrand: I'll look exactly what this bug is so that it doesn't occur anymore [07:17] ok. I'll add a note about space-delimited for next time [07:17] https://ci-train.ubuntu.com/job/landing-001-2-publish/4/console [07:17] success :) [07:17] jdstrand: no, I should really support that ;) [07:17] great [07:17] didrocks: thanks :) [07:17] jdstrand: and I think I did (even \n, /…) [07:17] jdstrand: sorry for this bug, will get to it :) [07:17] np [07:18] jdstrand: you will then just need to m&c once it's in the released pocket (which, in your case, will just free up the silo) [07:18] if we are low in silo, we'll probably do it for you [07:19] that's cool [07:20] jdstrand: do you spot anything in http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/prepare-silo-using-spreadsheet-info#L33 (only if you have a minute)? [07:20] seems to me it should have supported your case [07:21] probably US spaces (kidding) [07:21] didrocks: hi! It seems to be a bit problematic on first look ;) [07:22] hey sil2100! [07:22] sil2100: oh, why? [07:22] * jdstrand looks [07:22] didrocks: since you first split on whitespaces, if you have something like: "a, b, c" you get 'a,', 'b,' etc. and then split each of those by ',', so you will get 'a', '', 'b', '' [07:22] ahah [07:23] you're right [07:23] And this might smell trouble ;p ! [07:23] indeed [07:23] there you go [07:23] :) [07:23] ok, let me do some changes + add new tests [07:24] thanks sil2100, jdstrand [07:26] yw o/ [07:27] didrocks: btw. autopilot it FINALLY set to tested \o/ [07:27] didrocks: should I publish, 'just like that'? [07:27] Or should we wait for having smoketesting up? [07:27] sil2100: yeah \o/ (and NO!) Mirv is running the whole image test and is using that opportunity to try with new AP [07:28] sil2100: yep, I'm running tests with that, since we need some #276 AP info anyway it doesn't hurt to test the new AP at the same time [07:31] \o/ [07:32] * didrocks wrote the 6 new tests and have 4 failures [07:32] time to fix the function! [07:36] and fixed + deploying: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/579 [07:40] added as well http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/580 as another test [07:40] (if we regress on that, all MPs uris would be broken) [07:43] didrocks: indeed ;) [07:43] sil2100: the unity8 crash during the tests, can you find the bug report related to that one? [08:01] didrocks: yes, one moment ;) [08:01] didrocks: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1256360 <- no movement though [08:01] Ubuntu bug 1256360 in Mir "unity8 crashed with SIGSEGV in glDeleteTextures() from mir::scene::GLPixelBuffer::~GLPixelBuffer() from mir::scene::ThreadedSnapshotStrategy::~ThreadedSnapshotStrategy()" [High,New] [08:02] didrocks: from what Saviq mentioned, it's only happening on unity8 stop [08:02] sil2100: ok, wanted to confirm it was that one [08:02] yeah [08:03] sil2100: maybe you can try to report one from the previous run or Mirv can? [08:03] to ensure we have an up to date stacktrace [08:03] Mirv should have the crash [08:03] when running the AP tests [08:03] so will be good to use apport-bug [08:03] and ensure it's duplicating to that one (now that we have the timeout 60, we should be up to date) [08:04] Mirv: did you get a unity8 crash during last testing? Could you maybe push it to LP? [08:04] sil2100: do you know what happened on the bisect yesterday? I didn't see any news [08:04] I have that, I'll try filing it at some point but not during running tests [08:04] Mirv: yeah, after tests of course :) [08:04] thanks Mirv! [08:05] although I've unity8 testing failing anyway for some reason. I didn't debug it in addition to rebooting once, and I'm now running what is remaining of the other tests. [08:05] didrocks: my mailbox is empty, I didn't see any messages on the channel related to that ;/ [08:05] sil2100: I probably misunderstood, but you were not going to bisect one image as well yesterday? [08:05] sil2100: if you have spare device time you could run #276 unity8 AP tests just for fun, first as is and then with the autopilot PPA added [08:05] but I'll get to that eventually [08:05] Mirv: ok [08:06] yeah, what Mirv tells make sense [08:07] didrocks: no, no one told me to do any bisecting - Robert and Oliver were said on the meeting to do that [08:07] ok, my memory is bad :) [08:07] Mirv: let me reflash ;) [08:07] I mean, flash latest and greatest, since I have a b0rken OSK now [08:13] didrocks, bug 1302174 ... popey and robru were testing a fix over night, while i was running a test with all debugging enabled ... i had hoped rob would add his findings to the bug [08:13] bug 1302174 in lxc-android-config (Ubuntu) "Booting mako hangs randomly right after run-init" [Critical,Confirmed] https://launchpad.net/bugs/1302174 [08:14] ogra_: so you are going to test that yourself I guess? [08:14] ogra_: want more testing, do you have your reboot script? [08:14] didrocks, still the same script [08:15] i havent been near my test phone yet, i'll capture the logs soon (if it actually finally stopped, when i went to bed it was at 380 loops) [08:15] ogra_: with sleep 10 then? [08:15] sleep 30 [08:15] the script on the ML is sleep 10, so not the same :) [08:15] well, we discussed it in the meeting yesterday [08:16] ogra_: yeah, but that's why putting those infos on the ML would have enable people to help and try [08:16] not having those only in a hangout meetings [08:16] and then no result on the following day if robru doesn't publish results… [08:17] also, if I had the bug on it, I would have tried this morning as well [08:17] and I would have tricked seb128 or other to help confirming :p [08:18] * seb128 sees his name here and is getting nervous [08:21] didrocks, well, it doesnt matter how long the sleep is as long as you can reproduce the hang ... [08:21] ogra_: yeah, but now that you have a lead for a fix, that's fine :) [08:22] * didrocks turns rw mode on latest and start [08:23] bah [08:24] bah, so my phone died right after i went to bed ... [08:24] one downside of the infra changes is that the auth is asking me for the freaking 2fa now [08:24] and the log is totally mangled [08:24] ogra_: with your patch suggestion? [08:24] didrocks, no, i just had the idea after i had started the run with extra logging [08:24] didrocks, thats why i was asking popey and robru to test the fix [08:24] ogra_: ah ok, so there is hope :) [08:25] up to now my "fix" is just a guess [08:25] i was hoping to get detailed logs [08:25] ogra_: yeah… well, let's try your fix anyway [08:29] (running) [08:32] are people running to the meeting? [08:33] :p [08:33] ogra_: sil2100? ^ [08:34] ! [08:49] Mirv: hmmm, I seem to be having problems with the unity8 suite, as my unity8 hangs up from time to time becoming unresponsive ;/ [08:51] sil2100: it happens that unity8 AP did run on the test infra. keep on poking, I seem to get 37 failures every time (basically it aborts or something), but I'm running with the new AP [08:52] then there's the crash also that happens possibly the first time one stops unity8 ie just after starting phablet-test-run -n [09:04] sil2100: I've some additional tests for you to run with pure #276: dialer-app messaging-app webbrowser_app [09:05] so far I seem to have _same_ failures with both old and new AP [09:05] ev: FYI, just got https://job/landing-001-3-merge-clean/build?delay=0sec [09:06] didrocks: oooh [09:06] it returns [09:06] didrocks: if you leave that tab up and open ci-train.u.c in another tab, are you logged in? [09:08] Mirv: will try those once unity8 finally finishes, since it seems b0rkish now [09:12] Mirv: ok, unity8 finished: Ran 37 tests in 1216.179s [09:13] Mirv: with the old AP - but some tests were 'hanging' unity8 up, but as we guessed, it might have been the crash on stop [09:13] Mirv: let me run the other tests on the old AP === psivaa_ is now known as psivaa [09:17] sil2100: well I guess if I had success with _new_ AP, it wouldn't need repeating with old AP, or what do you think? [09:17] I guess so! [09:21] yeah ran out :) [09:22] switching places [09:23] dbarth: is line 26 ready for assigning a silo? [09:26] ogra_: tell me if you I can do anything to help you [09:27] will do [09:39] sil2100: not yet, i'm still tsting / gathering branches [09:39] sil2100: however you could rmove one line [09:39] sil2100: line 6; we won't land that request as-is [09:39] sil2100: the branches will be taken by bfiller for a silo which requires a part of them [09:40] so feel free to remove the line [09:45] dbarth: you can remove it yourself :) [09:46] dbarth: just don't remove lines on assigned silos without doing m&c "only free silo" first [09:46] vila, ping [09:47] mandel: pong [09:47] didrocks: I have a problem that the exports are not set from the .bashrc when I run the app test on my mako. [09:47] bzoltan: sorry, I'm totally out of context it seems? [09:47] vila, hello! so I have been looking at other projects that might have similar issues on arm but I'm trying to drill down the real issue [09:48] vila, for what I can read in the comments f unity-scope-click the connections on arm are flacky (the qt connections) [09:48] vila, I would be very very very surprise that there is an issue in a combination of cmake + qt + arm but I'm trying to add some code to rule that out [09:49] didrocks: flashed the device with devel-proposed, turned to writable and executed ` phablet-test-run -p address-book-app-autopilot address_book_app` ... the app looks scaled down, like if the GRID_UNIT_PX were not set [09:49] vila, if that is the case I'll let you know all the info since we might have other projects with the same problem [09:49] mandel: thanks ! [09:50] Mirv: sil2100: is that what you see as well? ^ [10:06] didrocks: ok, i thought you may have some formulas affected; i'll do the removal [10:07] dbarth: not if it's not assigned [10:07] dbarth: the system adapts to lines addition/removal [10:07] vila, the arm nodes used by the js bot, are they virtualized?? The tests do pass on non virtualize envs, they seem to fail with qemu [10:07] didrocks: didn't look at the screen while it was running... [10:07] didrocks: let me try that [10:08] Ah, address-book [10:08] Didn't try that one yet [10:08] Mirv: my device ended up in 9 failures while running tests for those 3 apps [10:08] (on old AP) [10:10] mandel: hmm, not virtualised AFAIK, fginther can confirm [10:10] mandel: fail with qemu emulating arm ? Known to be slow... [10:10] vila, yes, and I get a segfault in an arm chroot in my machine :-/ [10:11] vila, yes, on a nexus 4 and a nexus 7 everything works well [10:12] bzoltan: the application looks fine here - why you use devel-proposed instead of trusty-proposed? [10:13] sil2100: devel-proposed is pointed at trusty-propsoed and that's what should be used [10:13] mandel: so the cyclops are calxeda afaik, not emulated [10:13] ah, k [10:13] bzoltan: didrocks I see at least dialer app being very small, probably a regression somewhere.. and maybe related to the dialer/messaging AP failures too? [10:13] Mirv: it might be, but the address-book-app here look ok right now [10:13] mandel: would be nice to know if you run into an emulator bug or trigger a genuine one in the image/stack under test [10:14] Mirv: didrocks: the .bashrc exports are clearly not set [10:14] vila, I'm looking into it, is very strange... [10:14] bzoltan: I'm unsure why sil2100/Mirv doesn't reproduce the same issue. Maybe something to discuss with sergio? he's the most up to date on those changes if possible [10:14] ah, Mirv reproduces [10:14] now [10:15] Mirv: bzoltan: didrocks I see at least dialer app being very small, [10:15] didrocks: yeps [10:15] vila, doint a builddeb from source in qemu segfaults, I'm compiling and going to do a make check in qemu and check the results, if they failt and not segfautl I'm going to write an example test [10:15] vila, where it just emits the signal and waits for it, then I'll test that [10:15] way to go ! [10:15] * sil2100 waits for address-book tests to finish [10:16] Then I'll re-run dialer-app tests to see if it's smaller than usual [10:16] sil2100: the problems for me were dialer/messaging, not address book [10:16] bzoltan: confirming [10:17] Mirv: 11:49 < bzoltan> didrocks: flashed the device with devel-proposed, turned to writable and [10:17] executed ` phablet-test-run -p address-book-app-autopilot address_book_app` ... the app looks scaled down, like if the GRID_UNIT_PX were not set [10:17] Mirv: so, bzoltan mentioned address-book having the problem as well, but it doesn't seem to be the case on my device [10:17] Which is strange, hmmm [10:18] Mirv: was dialer-app smaller for you on all the tests? [10:20] sil2100: dialer app was, yes. weird that there are differing experiences [10:21] although well I didn't look the first time, but now. and I thought the AP fails would be related [10:24] Mirv: here dialer-app was fine for all the tests, I had 1 failure out of 9 tests [10:25] Mirv: for me _all_ apps are scaled down when run by the autopilot [10:26] bzoltan: so only in autopilot, and not if you launch them from the apps scope? [10:26] sil2100: you flashed clean on latest iso? [10:27] sil2100: no rw mode with leftover updates? [10:27] 54 loops with the revert to cgroup-lite up to now [10:29] ogra_: reverted to 1.8? [10:30] didrocks: hm, didn't flash it clean, let me maybe remove all user-data [10:30] didrocks, nope, just installed cgruops-lite, turned cgmanager and cgproxy off with override files and set the start condition og lxc-android-config to started cgroup-lite [10:30] ogra_: \o/ [10:30] ogra_: ok, keep us posted :) [10:30] 59 :) [10:30] ogra_: do you have something that we can test as well? [10:31] if it doesnt hang until 300 i'll upload lxc-android-config with that change [10:31] didrocks, well, do the steps i told above [10:31] ogra_: I would have said 200 is enough :) [10:31] if you prefer an additional 100 ones… :p [10:32] well, my run over night only died at 363 [10:32] t1mp: it looks perfectly normal when the app is launched from the Shell [10:39] sil2100: can we compare the AP results now? so for new AP, I got 8 failures in messasing_app (out of 16), and 2 failures in dialer_app (out of 9). but then I also got the same with old AP. [10:39] sil2100: but I still haven't been able to run unity8 AP for some reason, new or old AP. [10:40] sil2100: so I'm thinking if you could upgrade to the autopilot AP and compare dialer + messaging + unity8 there to the new. oh, and did you run webbrowser_app? [10:41] so far I don't have clear indications that the new autopilot would cause problems directly, but with all these other problems it's a bit hard to say for sure, so doube-checking would be welcome [10:41] sil2100: o/ line 25 should be ready now [10:42] didrocks: sil2100: but anyway with the new autopilot I've everything else 100% passing - only unity8, messaging, dialer, webbrowser would need double-checking with old/new so that we could at least understand whether we can release the autopilot [10:42] vila, bug #668799 [10:42] bug 668799 in Linaro QEMU "qemu-arm segfaults executing msgmerge (gettext)" [Undecided,Fix released] https://launchpad.net/bugs/668799 [10:42] vila, and bug #1098729 [10:42] I let you guys handle it :) [10:42] bug 1098729 in QEMU "qemu-user-static for armhf: segfault in threaded code" [Undecided,New] https://launchpad.net/bugs/1098729 [10:43] yep, I'll run webbrowser again at least with old AP now, might be just something flaky. [10:44] dbarth: \o [10:44] Mirv: ok, so... [10:44] Mirv: I had 1 failure on dialer-app and 8 on messaging-app, I ran webbrowser-app but didn't get any failures there seemingly [10:45] Mirv: and I was able to run unity8 tests as mentioned earlier - they took much much longer because of the hangups, but it said that all succeeded, no failures [10:45] Mirv: but I need to clean my environment [10:46] mandel: you should subscribe to bug 1098729 [10:46] bug 1098729 in QEMU "qemu-user-static for armhf: segfault in threaded code" [Undecided,New] https://launchpad.net/bugs/1098729 [10:46] mandel: I'm not sure who you could ping to get progress on it though... [10:46] may be ogra knows ^ [10:47] sil2100: ok, so that sounds about the same as I do, and you could check with the new AP if you also get similar results there [10:47] sil2100: but it seems so far the new autopilot is not to blame [10:48] Mirv: I'll give it a shot ;) [10:49] thanks. at least we can probably get a result on the autopilot. then what's causing the size issues and AP failures is a whole another topic. [10:52] dbarth: assigning the silo [10:53] Mirv: assigning silo for seb128 then ;) [10:54] cool [10:54] dbarth: landing-001 [10:55] sil2100, thanks [10:58] ogra_: ping, bzoltan told me you are the right guy to ask if there is a way to get the device name (like mako, maguro..) when i run something on the device [10:58] ogra_: i need to know which ubuntu-touch-session file contains the environment variables i need to set for executing a application in a debug session. [11:00] zbenjamin, DEVICE="$(getprop ro.product.device)" [11:00] ogra_: awesome thx! [11:01] if you run it before the container (and thus the property system is up) DEVICE="$(grep ^ro.product.device= /system/build.prop |sed -e 's/.*=//')" [11:02] Mirv: thanks [11:02] mandel, try hallyn (in #ubuntu-devel ... though i'm not sure he is fancy caring for the armhf side of things) [11:03] ogra_: i have to run it when executing a click app, so the device is fully booted [11:03] ogra_, thx [11:03] zbenjamin, then the first one is what you want [11:08] didrocks, i'm at 110 loops and still counting [11:08] ogra_: let's cross fingers! [11:12] sil2100: Mirv: can I get a silo for line 28? These are two MRs need to be tested separate from the other UITK MRs [11:13] bzoltan: sure [11:14] bzoltan: these need urgent testing, right? [11:15] sil2100, can i get silo for 27? [11:15] sil2100, plus question, we bumped soversion, is it enough to list all the dependant pkgs in "additional source packages to land"? [11:15] mhr3: oh, you just turned it to yes, sure [11:16] sil2100: as urgent as any ;) I need to test it and land it, other changes are pending on it. But they are not related to any critical bug that is in the images now [11:16] mhr3: hm, no - how many rdeps do you have? [11:16] sil2100, 5-6... ish [11:16] sil2100: ^I was referring to line 28 that bzoltan requested a silo for [11:17] t1mp, bzoltan: since uitk already has a silo - if you really need to test this before the other lands, I can override conflicts for you and allow you to have a silo, but you need to remember to rebuild the silo once the other one lands [11:18] mhr3: the "additional source packages to land" mean source packages which will be dput to the PPA [11:18] mhr3: you would need to include at least empty MRs for those rdeps (for those that we do CITrain for) and then force_rebuild during build [11:19] sil2100: ok [11:20] sil2100, why is the empty mr necessary? isn't it the same as listing them there? [11:21] mhr3: listing where? Additional source packages to land means that CITrain will 'expect' some additional source packages to be dputted to the PPA [11:21] oh... ok i see [11:21] mhr3: if you list them there, you would have to actually dput no-change rebuilds then [11:22] right [11:22] sil2100, ok, so let's build the lib and then i'll reconfigure and add mrs for all the rdeps [11:22] wow ! [11:22] mhr3: ok ;) Let me assign then [11:22] did anyone ever try to ssh from the terminal app ? [11:23] it prints your password in clear text on the screen at the password prompt [11:23] ogra_: sounds like a nice feature [11:23] At least you won't make any mistakes! [11:23] lol [11:23] ogra_: *finally* a terminal app where we can see what we are typing :D [11:23] beyond that it works really nicely ! [11:24] ogra_: change your password to 6 *s :) [11:24] lol [11:25] ogra_: http://www.bash.org/?244321 :D [11:26] ogra_: did you get the zero size font issue on initial startup? [11:26] davmor2, nope. started fine [11:26] ogra_: ah is this a fresh install though or just and upgrade? [11:27] davmor2, fresh install of 274 upgraded to 275 [11:27] loop 137 btw ... [11:27] oh nice maybe it has been fixed then [11:27] t1mp, heh, i know that one :) [11:27] davmor2, but i never remember having it [11:28] (though i only use the terminal occasionally [11:28] ) [11:28] ogra_: keeping my fingers crossed! [11:32] ogra_: this is on flo http://davmor2.co.uk/~davmor2/screenshots-phone/screenshot-20140404-122912.png if I change the font to 14 everything is fine then, but this is an older install so I'll do a fresh install and see if is shows up again [11:33] ouch [11:33] yeah, i dont get that [11:36] yay [11:36] 150 [11:39] didrocks: ogra_: sil2100: sorry, I did not follow the logs... was there a response to the wrong scaling issue? [11:39] bzoltan: it's not reproducible on my device, but Mirv saw it sometimes [11:40] bzoltan, i didnt even recognize a question about the wrong scaling issue :P [11:40] * ogra_ reads backlog [11:40] sil2100: I see it all the time with all autopilot tests... [11:40] ogra_: in brief... for me it seems that the .bashrc exports are missing when autopilot starts the apps [11:41] hm, strange [11:41] bzoltan, that either means you restarted lightdm (and thus the dbus/upstart adresses changed underneath you) without re-login on the shell, or that there is some bug we dont know about yet [11:42] also make sure to have the latest phablet-tools [11:42] adb shell handling was changed significantly by the foundations team recently [11:42] ogra_: All I do is a clean flash, make it writable (that reboots) install a bunch of packages as Mirv suggested and run the test [11:43] ogra_: I have the latest phablet t ools [11:43] ad you only use phablet-test-run ? [11:43] hmmm [11:43] thats weird [11:43] it was definitely adjusted for the changes ... [11:44] the easiest way to reproduce is (maybe) running dialer_app tests, but even that doesn't seem to be the case for all [11:44] so it seems weird [11:44] phablet-tools 1.0+14.04.20140401-0ubuntu1 [11:44] thats what you need [11:44] Mirv: hmm... with the new autopilot I get a bigger, varying number of failures, not sure what's up [11:45] note that dialer and messaging app need ohhono-phonesim-autostart installed ... note also that other tests may fail if ofono-phonesim-autostart is installed, you want to make sure to remove it after testing the dialer or messaging app [11:47] sil2100: here's all I have, for reference http://pastebin.ubuntu.com/7202885/ [11:47] I've now been trying to get the retrace out of the unity8 crash, but the device choked on that so I'm trying again and also on host [11:48] Mirv, see above, did you properly install/uninstall ophono-phonesim-autostart ? [11:48] Mirv: I ran 3 test suites at once now and got 27 failures o_O But maybe my device is not clean enough [11:48] ogra_: you have a flo right? [11:48] davmor2, yes [11:48] ogra_: not installed, but note that #275 I had AP:s passing fine without [11:49] Mirv, hmm, did you have a SIM during the test ? [11:49] ogra_: can you bootstrap it to the latest and try and connect to wifi please [11:49] ogra_: no SIM either [11:49] and the tests passed ? [11:49] that cant be [11:49] :S [11:49] either a SIM card or ophono-phonesim-autostart needs to be installed [11:50] and #275 didn't have it somehow automatically? [11:50] (i thought that was a dep of the two AP packages) [11:50] ogra_: I have 1.0+14.04.20140401-0ubuntu1 [11:50] the important point is that you need to purge it after the test [11:50] bzoltan, hmm, and this is a fresh install with --wipe and --bootstrap ? [11:51] ogra_: with --wipe not with --bootstrap [11:51] ogra_: it doesn't seem to be a dependency, but the results I posted on the mailing list yesterday with full pass rate for dialer/messaging were without SIM and with the same autopilot packages as today [11:51] oh, you should always use --bootstrap [11:51] else you end up with the former kernel/initrd [11:51] ogra_: no, unfortunately not too fresh [11:51] argh [11:51] so I'm running some weird kernel/initrd then.. [11:52] ok, I'll be back in a few hours. If anything urgent, send me a message or ask seb to send on my personal emails. Working offline meanwhile [11:52] sil2100: Mirv: ogra_: ^ [11:52] ogra_: keep up the successfully reboot meanwhile! :) [11:52] ok didier [11:52] the one that was installed with the last --bootstrap or if you did an OTA that got you a full flash with the one that came by OTA [11:52] didrocks, loop 172 [11:52] \o/ [11:53] sil2100: have you had a change of unity8 AP with the new autopilot? if that passes, I'm inclined to believe the new autopilot is not a problem [11:54] ogra_: interesting I did a reboot and then the popup for wifi pasword appears [11:54] a small race perhaps [11:54]