[07:48] <didrocks> bzoltan: rsalveti: hey, looking at the discussion yesterday after seeing the sdk being published
[07:49] <bzoltan> didrocks: yes sir
[07:49] <didrocks> bzoltan: rsalveti: remember that we are in a degraded mode, and the landing team is retesting every landing
[07:49] <didrocks> seems this one wasn't tested on our side, was it?
[07:49] <bzoltan> didrocks: I do not know about your side
[07:49] <didrocks> bzoltan: so, I guess it's a "no", let's hope we won't discover any issue with the sdk today
[07:50] <bzoltan> didrocks: I am on my side :)
[07:50] <didrocks> (tests are still running)
[07:50] <didrocks> bzoltan: always better to double check. I was happy to relax the "no landing rule" to help getting things landing, but at least, we need to follow the rule :/
[07:50] <bzoltan> didrocks: one thing is for sure ... merge conflicts are just the first fold, the MRs can have conflicting tests ...
[07:51] <bzoltan> didrocks: of course... I would not never ask for bending the rules.
[07:51] <didrocks> yeah, but the landing was done this way though :/
[07:51] <didrocks> (the one from this week-end)
[07:51] <didrocks> let's cross fingers nothing was unseen and wait for the test results
[07:52] <bzoltan> didrocks:  sorry for that, I was not aware of that
[07:53] <didrocks> bzoltan: no worry, I know it's a misunderstanding, please reread the email on the degraded landing on what we try to do :)
[07:53]  * bzoltan goes to the archive room to read 
[09:15] <xnox> bzoltan: ubuntu-ui-toolkit as in the ubuntu archive, ftbfs in the test-suite....
[09:17] <xnox> tst_MainView::testLocalStorage fails for me.
[09:17] <Mirv> didrocks: there'd be the first two CI Train packages to be built in landing-006 (Qt 5.2). I made empty MP:s against those.
[09:18] <didrocks> Mirv: ensure with upstream that they are ok with being "locked" (no more landing) until 5.2 is out
[09:22] <Mirv> thostr_: ^ I'd be starting the Qt 5.2 PPA uploads by "locking" libqtdbustest, libqtdbusmock and hud from your packages. the whole list and ordering can be seen at http://pad.ubuntu.com/qt52-dependencies
[09:22] <Laney> does jenkins delete old autopkgtest results?
[09:22] <Laney> It seems to have 20 in its sidebar
[09:22] <Laney> and going to earlier ones 404s
[09:22] <thostr_> Mirv: should be ok as we don't have any urgent chagnes there today
[09:22] <Mirv> thostr_: ok, thanks
[09:23] <didrocks> Mirv: thostr_: don't plan on "today", I fear this is going to take until thursday at best
[09:23] <Mirv> true, that
[09:23] <thostr_> Mirv: still, should be ok
[09:23]  * didrocks doesn't want any misunderstanding :)
[09:23] <didrocks> ok, great, thanks thostr_ :)
[09:23] <sil2100> +1
[09:23] <sil2100> ;)
[09:24] <sil2100> I don't remember any hud fixes in the CI Train since a while anyway
[09:24] <Mirv> of course, the whole list of 80 packages will become locked the further it's gone through
[09:25] <Laney> jibel: hey, could you see my question ^ please? ;-)
[09:25] <jibel> Laney, IIRC it does, let me check
[09:25] <seb128> hum, the recent ofono update seems to be buggy
[09:25] <seb128> e.g https://errors.ubuntu.com/problem/8a965beab09bc5c1bc862dd24455edc0feba5bd8
[09:26] <sil2100> seb128: we also noticed a lot of ofono crashes on the smoketesting dashboard
[09:26] <jibel> Laney, it keeps the last 20 builds.
[09:26] <didrocks> seb128: yeah, see CI results as well
[09:26] <didrocks> ricardo confirmed it as well
[09:26] <sil2100> seb128: Ricardo mentioned it on the ML as well
[09:26] <seb128> ranked high on the daily reports
[09:26] <seb128> rsalveti, ^
[09:26] <sil2100> Right
[09:26] <seb128> k
[09:26] <jibel> Laney, do you think it'd be useful to keep more?
[09:26] <sil2100> seb128: they might revert it soon I guess
[09:26] <didrocks> seb128: let's have the meeting, but I smell the revert for now
[09:27] <seb128> just pointed it while reviewing e.u.c
[09:27] <Laney> jibel: I want to find an old failure log to show to upstream
[09:27] <seb128> didrocks, sil2100: thanks
[09:27] <Laney> I don't know how you could guess that though without keeping everything
[09:30] <didrocks> popey: sil2100: coming?
[09:30] <popey> oh is that the time!
[09:31] <didrocks> it is THE time :)
[09:31] <didrocks> :)
[09:31] <sil2100> !
[09:31] <thostr_> Mirv: didrocks: will actually everything using Qt be blocked?
[09:32] <didrocks> thostr_: yeah
[09:32] <jibel> Laney, it is even purged from the backups. I can increase the history a bit more but not unlimited so not sure that would have helped.
[09:36] <Laney> jibel: Probably not, as it could be some way back for a test that gets triggered a lot
[09:36] <Laney> I guess it's not possible to keep just failures
[09:47] <mandel> sil2100, sorry I was out, the branch is linked to the bug afaik
[09:49] <sil2100> mandel: hi! It's no longer valid, I already released it during the weekend ;) Thanks
[09:50] <mandel> sil2100, great!
[11:13] <xnox> bzoltan: unity8 devs are pinging me about ubuntu-ui-toolkit py3 getting released.... when are you going to land it?
[11:13] <xnox> bzoltan: and why did it not land last time around? were other branches chosen to be landed over this one?
[11:14] <xnox> bzoltan: not having python3 ubuntu-ui-toolkit, is at the moment blocking migrating all other tests off python2.
[11:14] <xnox> and it's the only blocker...
[11:24] <didrocks> sil2100: FYI, pushed a fix to ci train to get into account debian sync package
[11:24] <sil2100> Oh
[11:31] <sil2100> didrocks: I tested history-service and telephony-service according to the test plans
[11:31] <sil2100> It's ok, so I publish it
[11:32] <didrocks> great!
[11:32] <didrocks> ah, seems elopio is around :)
[11:32] <didrocks> sil2100: for you, I guess ^
[11:32] <sil2100> Poking him right now ;)
[11:33] <sil2100> Although this might have been an auto-reconnect
[11:33] <didrocks> ok, going for a run while I still can, this evening will be busy :)
[11:33] <didrocks> maybe
[11:33] <sil2100> I'll jump out for lunch soon, but I'll leave elopio some messages in case he appears during my feast ;p
[11:33] <davmor2> didrocks: whats the magic line ending that I am looking for in the crash file please?
[11:34] <didrocks> davmor2: you need to retrace it in gdb and look for d8f_
[11:34] <didrocks> d8f8*
[11:34] <didrocks> davmor2: you know how to get a retrace? (without debug symbols)
[11:34] <davmor2> didrocks: yeah I think I have the page saved
[11:35] <didrocks> davmor2: you don't need to have the debug symbols, as we are interested in the address :)
[11:35] <didrocks> on the phone:
[11:35] <didrocks> cd /tmp/
[11:35] <didrocks> wget <crashfile>
[11:35] <didrocks> apport-unpack <crashfile> foo
[11:35] <didrocks> gdb <process_name> foo/CoreDump
[11:35] <didrocks> bt, eventually
[11:36] <didrocks> check that you have something like: #0  0x<…>d8f8 in ?? ()
[11:38] <davmor2> Cannot access memory at address 0xb0b2a35c
[11:38] <davmor2> #0  0x40d0d8f8 in ?? ()
[11:38] <davmor2> Cannot access memory at address 0xb0b2a35c
[11:38] <davmor2> #1  0x40d2d7e8 in ?? ()
[11:38] <davmor2> I'd say that is a positive then
[11:38] <didrocks> hum
[11:38] <didrocks> yeah
[11:38] <didrocks> :)
[11:39] <didrocks> davmor2: ok, so user can get the crash
[11:39] <didrocks> asac: FYI ^
[11:39] <didrocks> davmor2: tell us about the frequency of such issues
[11:39] <didrocks> (thanks!)
[11:39]  * didrocks really goes for a run now :p
[11:40] <davmor2> didrocks: once as far as I can tell but I'll do a fresh install now and hit it hard and see what shows up then
[11:40] <didrocks> davmor2: can happen in any application, anything
[11:41] <didrocks> so keep a close eye :)
[11:56] <ogra_> didrocks, what is ofono-simd ?
[11:57] <didrocks> ogra_: AFAIK, it's a mock for dialer-app and other call-related tests
[11:57] <ogra_> are you meaning ofono-phonesim ?
[11:57] <didrocks> yeah, mistyped
[11:57] <ogra_> ok
[11:58] <ogra_> seems the ofono testing needs to take that into account ... i can reproduce the crashes locally as soon as i install ofono-phonesim-autostart ... just looking into it with xnox in -touch btw
[11:58] <didrocks> ogra_: ah, nice that you can confirm it!
[12:01] <xnox> didrocks: well phonesim-autostart polls list-modems and enable-modem for up-to 10 times... waiting for org.ofono to be available on the dbus, but crashes generated from list/enable-modems whilst polling are not caught at all... and phonesim job appears to be started, before it is ready.
[12:01] <xnox> didrocks: i believe this should fix it http://paste.ubuntu.com/7027072/
[12:03] <didrocks> xnox: should be easy enough to test on a phone running all AP tests I guess ;) but yeah, seems you are right. however, the thing should wait and try to reconnect later on rather, no?
[12:04] <ogra_> didrocks, well, the .crash files are not from testing but from booting
[12:04] <ogra_> i doubt we need to run all APs to verify ... a few will be enough
[12:05] <ogra_> (in fact booting should be enough to see it is gone ... it creates a new one each boot)
[12:06] <xnox> didrocks: i'll talk to pitti, on how to do it properly.
[12:06] <ogra_> xnox, there is also a crash for the dial-number script
[12:06] <ogra_> that might need the same fix
[12:06] <xnox> ogra_: read it, it's unrelated to this.
[12:06] <didrocks> thx
[12:06] <ogra_> ah, k
[12:06] <xnox> ogra_: but, if fake ofono is not reliably up, i wouldn't trust any test results.
[12:06] <ogra_> yeah
[12:07] <xnox> didrocks: cause, at the moment those two scripts are exected in a time-out loop, if they start waiting/polling themself, we'll square the timeout (e.g. 100s instead of 10s)
[12:08] <didrocks> xnox: oh, indeed
[12:09]  * ogra_ reboots with the fixes in place
[12:10] <ogra_> hmm
[12:10] <ogra_> root@ubuntu-phablet:/# ls /var/crash/
[12:10] <ogra_> _usr_share_ofono_scripts_enable-modem.0.crash
[12:10] <ogra_> still :/
[12:10] <xnox> ogra_: can you read that file?
[12:10] <xnox> ogra_: or paste it to me....
[12:11] <ogra_> http://paste.ubuntu.com/7027127/
[12:12] <ogra_> xnox, you match on service unknown
[12:13] <ogra_> oh, wait, my upstart job was changed ...
[12:13]  * ogra_ reverts to original and reboots again
[12:14] <didrocks> ok, running now :)
[12:14] <didrocks> ogra_: feel free to revert the revert if you have clear evidence that we don't have any crash
[12:14] <ogra_> well, i'm trying here ... but the crash still occurs
[12:15] <xnox> ogra_: the crash you are showing, is not the crash we've seen in testing.
[12:15] <xnox> ogra_: any my patch specifically resolves service name unknown, not anything else.
[12:16] <xnox> ogra_: can you first, reproduce original crash?
[12:16] <xnox> ogra_: and _no_ it's not _just any_ python traceback crash from enable-modem/list-modems, but specifically
[12:17] <xnox> as per your original ping, org.freedesktop.DBus.Error.ServiceUnknown
[12:17] <ogra_> xnox, but the crash you catch there wont help with enable-modem
[12:17] <ogra_> https://jenkins.qa.ubuntu.com/job/trusty-touch-flo-smoke-daily/18/artifact/clientlogs/calendar_app/_usr_share_ofono_scripts_enable-modem.0.crash/*view*/
[12:17] <ogra_> enable-modem always had that crash
[12:17] <ogra_> list-modems has the service unknown one
[12:17] <ogra_> i dont get a list-modem  crash locally
[12:18] <ogra_> only the enable-modem one
[12:18] <xnox> ogra_: well, i want ps chain, to the enable-modem executor.... it's from phonesim upstart job?
[12:18] <ogra_> yes, must be, it goes away if i disable the autostart job
[12:19] <xnox> ogra_: or somebody who knows how to debug ofono, to figure out why it's failing to power the modem.
[12:19] <ogra_> its powering the fake modem (or tries to)
[12:19] <xnox> ogra_: can you manually give me "strace -o /tmp/foo.log -s 999 with-ofono-phonesim quiet"
[12:20] <xnox> ogra_: when ofono/ofono-phonesim are both stopped and all crashes are cleared.
[12:20] <xnox> ogra_: and any crashes that that strace will generated.
[12:20] <xnox> ogra_: and the console log output.... (well i could extract it from strace log, but getting it separate would be easier)
[12:21] <xnox> ogra_: which device you are testing this on? it works correctly on the desktop...
[12:21] <ogra_> xnox, flo
[12:21] <xnox> ogra_: and why is phonesim used on the phones, i thought we'd test against real one on the phones.
[12:22] <ogra_> heh, even with "quiet" with-ofono-phonesim is very noisy on the console
[12:23] <ogra_> xnox, http://paste.ubuntu.com/7027184/
[12:25] <ogra_> http://paste.ubuntu.com/7027192/ is the console outut when running the strace
[12:26] <xnox> ogra_: weird, i see. so it stars up on the third try, but whilst polling it generates ofono.Errors.... so ofono is on the dbus, but the modem is not yet.
[12:26] <ogra_> yeah
[12:26] <xnox> ogra_: ok, i'll change to catch the ofono.Error then in the enable-modem script.
[12:26] <ogra_> yeah, sounds legit
[12:26] <xnox> ogra_: but when pitti is back, we need to fix it up properly.
[12:26] <ogra_> right
[12:27] <ogra_> well, it was no issue before the new ofono
[12:27] <xnox> ogra_: as catching errors like this, is not reliable (e.g. if order of execution changes inside ofono, etc.)
[12:27] <ogra_> i ssume we need to fix it on the ofiono side
[12:27] <xnox> ogra_: yeah, and if ofono internals change again, this may manifest itself... again...
[12:27] <ogra_> right
[12:27] <xnox> ogra_: ... or phonesim... pitti would know better.
[12:28] <ogra_> yup
[12:28] <ogra_> or awe :)
[12:32] <xnox> didrocks: thanks for revert.... how am i suppose to fix and test this now, my debdiffs now do not apply =(
[12:32] <ogra_> hmm, just changing the match doesnt help here
[12:33] <xnox> didrocks: and it's not python2/3 specific, so you should not have reverted that portion of patch.
[12:33] <ogra_> well, revert usually means roll back to last known good package
[12:33] <xnox> didrocks: why did you revert all of it?
[12:34] <ogra_> thats the rule
[12:34] <xnox> ogra_: didrocks: you don't know where the problem is comming from, roll back takes you into a new state, which is unknown.
[12:34] <ogra_> (discuss with asac if you want it different with a good reason)
[12:35] <ogra_> roll back is supposed to take you to the last state ... works fine if you roll back all involved packages in a change
[12:35] <popey> didrocks: did you want 216 or 217 dogfooded?
[12:37] <asac> right, you can rollback transactions. so whatever our granularity of transactions delivered into the baseline is, is what can be rolled back
[12:37] <asac> currently best we have for that is packages, but its not perfect for sure, but would require innovation on how we maintain/deliver things into our baseline
[12:38] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140301.1.changes
[12:38] <ogra_> thats what caused the issue ... and thats what was rolled back (i hope)
[12:43] <cjwatson> Hm, this suggests to me that before landing libclick, maybe I have to land my prerequisite stack of miscellaneous cleanups first
[12:43] <cjwatson> Otherwise I get the whole thing rolled back if anything at all goes wrong, and my head explodes
[12:44] <sil2100> I might be back a bit later, my animal has additional health problems ;/
[12:47] <cjwatson> Though I guess prereq cleanups => 354-line diff, libclick => 8000 or so.  Maybe it's not worth it
[12:47] <asac> cjwatson: for complicated/non-trivial landings you could/should coordinate with LT to discuss options - including te option to accept temporary bustage. in most cases that shouldnt be the case though. one clean path that exist is to stage everything - including cleanups - in a silo, once touch baseline is not regressed, all goes in.
[12:47] <cjwatson> Yeah, it's CI-trainable (in theory anyway)
[12:47] <asac> cjwatson: LT folks can help on non-trivial landings by supporting with testing and giving you quick feedback etc.
[12:48] <cjwatson> So OK, I'll just do that once I'm ready, which will be probably tomorrow
[12:48] <asac> nice. lets try
[12:49] <asac> cjwatson: if you want a silo to start staging stuff, let us know
[12:50] <asac> also we might want to do your libclick before doing the qt5.2
[12:50] <cjwatson> Just because Qt5.2 might take a while, you mean?
[12:51] <asac> qt5.2 might make our tests go red, which then will hit super hard to say with confidence that your work isnt regressing something hidden behind it
[12:51] <asac> for qt5.2 we are probably willing to take a temporary hit (even though we prep as much as we can outside)
[12:51] <asac> just because its awful late
[12:51] <cjwatson> Yeah
[12:52] <cjwatson> Not that I'm sure any of the autopilot tests actually hit click, but I don't really want to be implicated unnecessarily :)
[12:52] <asac> right
[12:52] <asac> it becomes too messy
[12:52] <ogra_> well, we do manual smoketesting too :)
[12:52] <ogra_> (which involves click)
[12:52] <asac> also who knows if suddenly stuff starts breaking somewhere
[12:52] <asac> right
[12:53] <asac> we have to learn the best rules of engagement still. e.g. what can go in safely without putting the lander accidentially into a messy friedrill etc.
[12:53]  * asac checks latest APs
[12:53] <asac> for qt5.2 silo
[12:55] <ogra_> so what the ofono issue clearly shows is that pre-landign testing needs to be done with ofono-phonesim-autostart installed
[12:55] <asac> Mirv: didrocks: elopio: can we get a fresh AP run?
[12:55] <asac> ogra_: if ofono goes through Train, hyou could easily hook that detail in the testplan
[12:56] <ogra_> right
[12:56] <asac> ogra_: does it? :)
[12:56] <ogra_> well, i'm not even sure if we should have it installed at all
[12:57] <ogra_> it seems to fake a sim wehere we actually have a sim available
[12:57] <ogra_> imho it should only be used on tablets ... mako should use its existing modem
[12:57] <ogra_> which points to another issue ... we cant really differentiate tests between tablet/phone in this case
[12:59] <asac> ogra_: is tablet a subset of phone packageset?
[12:59] <asac> or are there packages for tablet that we dont want on phone?
[13:01] <ogra_> they are the same
[13:07] <davmor2> didrocks: so the weather app crash is the qmlscene crash so if that is the crash from ci train, and it leaves a window open that is white/grey but no process running.  So crash and failed test might be due to that.
[13:09] <asac> ogra_: same?
[13:09] <asac> thought we dont have phone stuff
[13:09] <ogra_> asac, we only have one seed
[13:09] <asac> yeah in know :)
[13:10] <ogra_> same goes for the tuch tests ...
[13:10] <ogra_> we only have one autopilot-touch metapackage
[13:10] <asac> i was trying to figure if thats really the best case
[13:10] <ogra_> it isnt i guess
[13:10] <asac> best approach
[13:10] <ogra_> testing dialer-app or messaging app on a tablet without 3G is nonsense
[13:10] <asac> ogra_: android surely has different packageset in repo for tablet, right?
[13:10] <asac> or is that all the same for them as well?
[13:11] <asac> ogra_: yeah, if the tablet would have a 3g modem at least messaging would make sense though, but we dont
[13:11] <asac> so... :)
[13:12] <asac> Mirv: is the silo in a state that we could poke it with the AP test thingy?:
[13:13] <ogra_> asac, might be ... i think there is even a property that tells us if we are tablet or phone ... but currently we do not differentiate at all
[13:13] <ogra_> (which causes issues)
[13:14] <Mirv> asac: no, apparently the Friday's transitional package is not working correctly for upgrades, so the dist-upgrade method AP testing would use fails. qtbase should be updated either to revert the change or tweak it further
[13:15] <Mirv> (the change that added libqt5core5 back as a transitional package)
[13:15] <asac> Mirv: so you say we would temporarily add that transitional package?
[13:15] <asac> Mirv: if that keeps us moving, lets do it i guess. what would be the implications?
[13:15] <asac> the  negatives?
[13:16] <Mirv> asac: no, we added it already like you asked, it's just not working 100% correctly
[13:16] <Mirv> so either it should be reverted similar to what should be done eventually anyway, or another upload made with the transitional package working better
[13:16] <asac> hmm. thought we said we dont do it after the call
[13:16] <asac> Mirv: just remove it. we dont want to test the apps without rebvuilding them we said
[13:17] <asac> assuming that the revert would help
[13:17] <asac> Mirv: wonder... what is th eerror we get?
[13:17] <Mirv> asac: no, it was made before the call since you insisted on it being done. then during the call it was decided it's not needed and that it could be reverted later
[13:17] <asac> ah
[13:17] <asac> ok
[13:17] <asac> didnt know the upload lready happened
[13:17] <Mirv> asac: yep, reverting is the easiest
[13:17] <asac> Mirv: will that work?
[13:18] <asac> Mirv: just revert qt? or also respin the stuff on top?
[13:18] <Mirv> asac: sure, then it's the same as qt5-beta2 where upgrades and AP testing work. the error is that libqt5core5a is tried to be installed before libqt5core5 has been replaced by the new empty package
[13:18] <Mirv> asac: just upload ubuntu3 version of qtbase and let it build. it does not affect the rest of the landing.
[13:18] <asac> Mirv: yeah. i see. so there is a conflict missing. sure that problem doesnt exist for non-transitional package case?
[13:19] <asac> sound we need that libqt5core5a conflicts libqt5core5 < VERSION
[13:19] <asac> in any case
[13:19] <Mirv> asac: the conflict was removed in this ubuntu2 upload so that the transitional package could exist, but it should not have been removed completely but only partially
[13:19] <asac> Mirv: you need to conflict < CURRENT
[13:20] <asac> with transitional packages
[13:20] <Mirv> indeed
[13:20] <asac> thats the practice i remember from my time :)
[13:20] <asac> ok go ahead and fix things ;)
[13:21] <asac> Mirv: byt the edgers ppa is still good?
[13:21] <asac> Mirv: can we have another run there?
[13:21] <asac> given that today mako is pretty reasonably green, the results on a fresh run would be more interestin
[13:21] <asac> g
[13:21] <asac> might be more interesting
[13:21] <Mirv> asac: ok! the edgers is good, we need elopio or someone else who has credentials to trigger the job
[13:21] <asac> what is interesting is that the unity8 AP passed today :)
[13:21] <asac> lol
[13:22] <asac> seems we either were super lucky
[13:22] <asac> or we improved the runtime behaviour in favour of hiding those crashes
[13:23] <asac> psivaa: do you know if we retried the jobs with the crsaehs today?
[13:23] <asac> we have very very few qmlscrene crashes i feel.
[13:23] <psivaa> asac: i did run dialer-app tests a couple more times
[13:23] <asac> suspiciously few
[13:23] <asac> psivaa: that had the qmlscene crash?
[13:23] <psivaa> asac: no i dint rerun any qmlscene crash ones
[13:24] <asac> thats very interesting
[13:24] <asac> we have like just one
[13:24] <psivaa> asac: yes, we noticed that in the landing meeting
[13:24] <asac> didrocks: any theory why things are suddenly as good as before :P
[13:24] <asac> rsalveti: ?
[13:25] <ogra_> because we all rock
[13:25] <ogra_> :)
[13:25] <asac> maybe we can stay on 5.0 after all :P
[13:25] <asac> lol
[13:25] <asac> j.k.
[13:26] <ogra_> asac, one issue was a stale mir socket
[13:26] <ogra_> thats cleaned up with one of the recent unity8 uploads
[13:26] <ogra_> and the other was some missing header intialization ...
[13:28] <ogra_> asac, that fixes it with 5.0 but according to rsalveti introduces other bugs that 5.2 fixes
[13:28]  * ogra_ tries to remember in which upload that fix landed
[13:31] <asac> Mirv: if you are fine we could start a run with qt5 edgers now
[13:31] <davmor2> ogra_, popey: have either of you done a fresh flash to the latest image?  bluetooth is off by default and you don't seem to be able to turn it on
[13:31] <ogra_> unity8 (7.84+14.04.20140228-0ubuntu1)
[13:31] <asac> elopio: what do you think?
[13:32] <ogra_> that had the fix for stale sockets
[13:32] <ogra_> davmor2, what device ?
[13:33]  * ogra_ only has flo and manta to test 
[13:33] <davmor2> ogra_: mako
[13:33] <ogra_> we got new kernels ... hmm
[13:33] <davmor2> ogra_: let me try on flo
[13:34] <ogra_> i definitely have a BT indicator here
[13:34] <davmor2> ogra_: so flo works from an upgrade let me install it fresh now
[13:34] <ogra_> but i didnt flash from scratch in a week or so
[13:34] <ogra_> there were no changes to bluetooth regarding mako ...
[13:35] <davmor2> ogra_: this was a bootstrap install I wanted a completely fresh install
[13:35] <ogra_> so the only thing i can imagine is the changed kernels
[13:35] <ogra_> davmor2, new kernels landed in 215 iirc
[13:36] <davmor2> flo is flashing now I'll come back to it after lunch
[13:36] <ogra_> davmor2, can you try if it works on 214 and breaks on 215 on mako ?
[13:36] <ogra_> if so, then it must be the new kernel
[13:37] <davmor2> ogra_: not right now but I can latter on
[13:37] <ogra_> k
[13:49] <popey> davmor2: no
[13:52] <bregma> sil2100, good day, I have ci-train platforms 43 and 44 in need of a launch silo if you would be so kind as to find the time
[13:52] <Mirv> asac: I'm fine with the AP run, I just finished a bunch of rebuilds in qt5-beta2
[13:52] <asac> elopio: ^^
[13:52] <asac> can you kick?
[13:52] <asac> Mirv: thats in edgers?
[13:54] <didrocks> ogra_: kicking an image, anything that you are waiting for?
[13:54] <ogra_> didrocks, nope
[13:55] <didrocks> ok, /me does :)
[13:55]  * ogra_ sets up an alarm for 218 
[14:00] <Mirv> asac: yes, it's the canonical-qt5-edgers/qt5-beta2
[14:00] <asac> Mirv: do you have powers to start that AP job?
[14:00] <asac> seems elopio is off or something
[14:02] <ogra_> he did a lot on the weekend by the looks of it
[14:02]  * ogra_ sees MPs 
[14:02] <Mirv> asac: I don't think so, and it needed some parameters to be known for the job
[14:03] <jibel> asac, is there any specific parameter to pass, or just build with the default?
[14:03] <Mirv> asac: elopio is in hangout, so yes he can then start the job :)
[14:04] <asac> oh right. will join in a bit
[14:04] <davmor2> trying to paste copied text into the notes app and I don't get the option to paste, select all appears briefly but it disappears :(
[14:05] <didrocks> davmor2: ok, thanks for looking!
[14:20] <ChrisTownsend> Has anyone noticed that a autopilot-trusty-daily_release job has been stuck for almost 6 days? http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/1698/
[14:22] <bregma> I think they've been doing major changes to support phone testing infrastructure, that may be having some affect
[14:23] <bregma> I expect it will cause massive breakage to our stuff, knowing how they do not test their changes against shipping code using it
[14:30] <didrocks> bregma: both assign
[14:30] <bregma> didrocks, thanks -- is the ci-train really busy right now with qt5-related stuff or should I feel free to grab more slots?
[14:31]  * bregma doesn't want to be greedy
[14:31] <didrocks> bregma: qt5.2 is one slot only. You can batch things together if you prefer, what else do you have in the pipe?
[14:32] <didrocks> we do have some room if that's the question :)
[14:32] <bregma> didrocks, a couple of low-priority OIF things
[14:32] <bregma> just to get them off my plate and stop eating my karmna
[14:33] <didrocks> bregma: you can get one slot with all the OIF, that should be fine
[14:33] <didrocks> we do 50% on Monday ;)
[14:34] <sil2100> Damned animals, never again I agree to buy an animal!
[14:34] <sil2100> Nothing but fluffy trouble I tell you
[14:35] <didrocks> sil2100: +1
[14:35] <didrocks> that's exactly the reason why we don't have any
[14:35] <didrocks> (and if you want to move somewhere during holidays…)
[14:35] <sil2100> Indeed
[14:35] <sil2100> didrocks: anyway, elopio said he'll take a look today on weather-app tests ;)
[14:36] <didrocks> sil2100: great! seems that davmor2 thinks it's the qmlscene crash as well
[14:36] <elopio> didrocks, sil2100: I will take a look, but in a couple of hours.
[14:36] <elopio> is that ok?
[14:36] <didrocks> elopio: sounds good, I'll mention it in my landing email on the phone ML, mind answering there then?
[14:37] <elopio> didrocks: yes, I will.
[14:37] <didrocks> perfect ;)
[14:37] <elopio> we are also looking at a clock alarm error.
[14:37] <didrocks> yeah, that's one of the remaining one
[14:37] <didrocks> (that + camera-app that Ricardo is looking at)
[14:38] <didrocks> hey dbarth
[14:38] <davmor2> didrocks, sil2100: I'm running watch on the /var/crash dir and it popped up total 1 when the weather crash happened which was the qmlscene crash :)  I'm still trying to trigger the unity8 crash but it might take a while :D
[14:38] <didrocks> dbarth: not sure if you noted, but Mirv added some note on your html5/cordova landing (seems he couldn't get the tests to pass)
[14:39] <didrocks> davmor2: ok, I guess that's good input for taking a decision when those remaining issudes are fixed. Is the crash a blocker for promotion or not?
[14:39] <didrocks> (like how often does it occur, and so on…)
[14:40] <davmor2> didrocks: weather it happens with fairly consistently and I think maybe the google+ app too but I've not got to installing apps yet
[14:41] <didrocks> davmor2: so, maybe apps that are js greedy
[14:41] <davmor2> didrocks: could be
[14:41] <davmor2> let me install the g+ app and fire up facebook and twitter
[14:42] <davmor2> oh nice webapp container crash on starting facebook
[14:43] <davmor2> ogra_: flo now doesn't have bluetooth working after bootstrap install of 217
[14:43] <ogra_> davmor2, right, what about something before 215
[14:44] <ogra_> the new kernels landed there ...
[14:44] <davmor2> ogra_: I'll hit that in a second
[14:44] <ogra_> awesome
[14:44] <ogra_> apw, ^^^did any bluetooth option change in the recent kernels
[14:44] <davmor2> ogra_: was flo supported in 214?  I'm assuming so but I think I was on mwc at the time
[14:44] <ogra_> (i would have assumed not ... but i think i better ask :) )
[14:45] <ogra_> yes, 214 had working BT
[14:45] <davmor2> ogra_: okay I'll flash that as soon as I figure out how with the new tool I'm assuming -b 214 but I'll look
[14:46] <ogra_> davmor2, BT support for flo was added in 210
[14:46] <ogra_> so 210-214 should be fine
[14:46] <ogra_> 215 then got new kernels and new android ... i suspect the issue is with one of these two
[14:46] <ogra_> (android rebuild is required to pick up the kernels)
[14:47] <davmor2> ogra_: right flashing 214 on flo now
[14:56] <davmor2> ogra_, asac, didrocks, popey: hmmm that's odd how is it when I adb in I can type apt-get install w3m on a normal freshish install and it install it?  I thought the system was R/O
[14:57] <ogra_> davmor2, hmm
[14:57] <popey> davmor2: does it actually install?
[14:57] <didrocks> davmor2: on flo? not sure, I don't have one (but that doesn't work for sure on mako)
[14:57] <ogra_> davmor2, ls -l /userdata/.writable_image
[14:57] <ogra_> davmor2, smells lik a bug in the flasher ... it should remove that file
[14:57] <davmor2> didrocks: no on mako
[14:58] <didrocks> ogra_: it does remove it
[14:58] <davmor2> -rw-rw-rw-  1 root   root            0 Feb 27 12:35 .writable_image
[14:58] <popey> it doesnt
[14:58] <popey> i updated mine today and it still has one there
[14:58] <didrocks> davmor2: you did upgrade or reflash?
[14:58] <ogra_> yeah, thats what i suspected
[14:58] <popey> i upgraded
[14:58] <didrocks> yeah, it doesn't remove on upgrade
[14:58] <davmor2> didrocks: fresh bootstrap flash
[14:58] <ogra_> phablet-flash removed it ... i guess the re-write (ubuntu-device-flash) doesnt
[14:58] <didrocks> flashing does
[14:59] <ogra_> davmor2, file a bug against ubuntu-device-flash
[14:59] <didrocks> ogra_: no, it's the upgrader rather
[14:59] <didrocks> let me test something
[14:59] <ogra_> didrocks, ?
[15:00] <davmor2> didrocks: using the following "ubuntu-device-flash --channel=devel-proposed --device=mako --bootstrap"
[15:00] <ogra_> why would it have anything to do with the upgrader
[15:00] <didrocks> davmor2: that's really weird, it should remove it under that consideration
[15:00] <ogra_> --bootstrap needs to remove it
[15:00] <didrocks> ogra_: because the flasher just uses the upgrader
[15:00] <ogra_> i guess its simply an oversight on sergios side
[15:01] <rsalveti> ogra_: the only thing that changed: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=625dc76723341bc375d1ba277ff8f26def1c3a25;hp=77576d7e4c72425b2ba519e287d31f3c30f84081
[15:01] <rsalveti> and http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=c2ecce599b3159d615c52d269de04cc95a83f409;hp=4948db412bc63cc4815bb20cba99cb65a8aacb14
[15:01] <ogra_> rsalveti, hmm, then it must be the android side
[15:01] <ogra_> at least if davmor2 can confirm that BT actually works somewhere between 210 and 214
[15:02] <davmor2> ogra_: I have bt on 214 on flo
[15:02] <ogra_> davmor2, thanks
[15:02] <ogra_> rsalveti, http://people.canonical.com/~ogra/touch-image-stats/20140301.1.changes only this and android/kernels changed
[15:02] <davmor2> ogra_: and I have the spinner in bt settings in the settings app too
[15:03] <ogra_> yeah
[15:03] <ogra_> not sure if it actually connects properly :) i only made sure BT suuport in general is there so the test of the indicator doesnt fail :P
[15:04] <rsalveti> ogra_: right, but you can check the diff for android, nothing specific to that
[15:04] <ogra_> weird
[15:04] <rsalveti> the diff is actually minimal, just your recovery patch
[15:05] <ogra_> yeah, that shouldnt have any influence on BT
[15:05] <ogra_> just sets a filesystem flag
[15:05] <rsalveti> ogra_: and what's up with ofono in the end?
[15:05] <rsalveti> ogra_: what is the proposed fix?
[15:05] <ogra_> rsalveti, well, ofono-phonesim causes massive dbus errors with eth new scripts
[15:06] <rsalveti> right, and do we know why exactly?
[15:06] <ogra_> rsalveti, xnox worked out a fix for one of the scripts
[15:06] <ogra_> not really, no
[15:06] <rsalveti> because once you install phonesim, the rild modem is not even active anymore
[15:06] <davmor2> ogra_: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1287208
[15:06] <ogra_> it seems that phonesim-ofono starts before ofono is properly providing the dbus service
[15:07] <ogra_> it runs a startup script that loops over the ofono scripts ...
[15:07] <rsalveti> oh, maybe we're just having a race or something now
[15:07] <davmor2> ogra_: I will now flash 215 and confirm it dies then
[15:07] <ogra_> for one script that easily explains the issue and the try:/except: fix is the right solution
[15:07] <rsalveti> did we already build a new image after reverting ofono?
[15:07] <ogra_> but there is another one where it doesnt help
[15:07] <rsalveti> right
[15:07] <ogra_> rsalveti, didrocks seems to have started one, seems he forgot to notify the channel
[15:08] <rsalveti> alright
[15:08]  * ogra_ has an alarm watcher running, will ping once it is done
[15:08] <rsalveti> ogra_: please ping awe then later today and ask him to sync with pitti
[15:08] <rsalveti> I'm mostly off today, focused on the camera issue
[15:08] <ogra_> rsalveti, pitti is on vac. :(
[15:08] <tvoss> rsalveti, ping
[15:08] <didrocks> I should use ogra_'s tag :)
[15:08] <ogra_> and i fear we need him to fix this
[15:09] <rsalveti> tvoss: hey, did you see my email?
[15:09] <ogra_> didrocks, yes, that helps :)
[15:11] <ogra_> [15:12] <tvoss> rsalveti, yup, looking at the code right now
[15:12] <rsalveti> tvoss: awesome
[15:16] <davmor2> ogra_: 215 still has bt
[15:16] <davmor2> ogra_: flashing 216 now
[15:17] <ogra_> oh, intresting
[15:17] <ogra_> 216 only has a new download-manager
[15:18] <ogra_> so it must be 217
[15:18] <ogra_> hmm
[15:18] <ogra_> which doesnt have any relevant changes either
[15:18] <ogra_> unless the UITK can have any influence here which i dont really like to belive
[15:30] <davmor2> ogra_: dies on 216
[15:31] <ogra_> but 216 only had the download manager changes o_O
[15:31]  * ogra_ blames mandel for breakin bluetooth then :P
[15:31] <davmor2> haha
[15:31] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140302.changes
[15:32] <ogra_> thats the changelog of 216
[15:32] <seb128> ogra_, there were some android uploads saturday
[15:32] <seb128> ogra_, would that show on the .changes?
[15:32] <ogra_> seb128, yes, for 214
[15:32] <seb128> k
[15:32] <ogra_> seb128, no
[15:32] <ogra_> it isnt in the manifest since we dont install it inside the image
[15:32] <mandel> ogra_, wait what? I did nothing! :)
[15:32] <ogra_> :)
[15:33] <davmor2> mandel: in that case it's your fault for not fixing it :P
[15:33] <mandel> davmor2, oh, then sorry :)
[15:33] <ogra_> heh
[15:34] <davmor2> mandel: nice play along :)
[15:34] <ogra_> davmor2, well, whats weird is that i have BT on my upgraded devices
[15:34] <seb128> ogra_, how do you know on what image the new android landed?
[15:35] <ogra_> seb128, checking the promotion time vs the image build time
[15:35] <davmor2> seb128: he has all the change logs?
[15:35] <ogra_> or if i want it detailed i can look at the livefs build log
[15:35] <ogra_> davmor2, android isnt in the changelogs ... thats the issue
[15:35] <davmor2> ogra_: ah right
[15:36] <ogra_> davmor2, so looking at my flo, i'm actually on 216 here
[15:36] <ogra_> with BT working
[15:36] <seb128> ogra_, well, looking at the .changes timestamps and the time android landed in trusty, I would think it landed in http://people.canonical.com/~ogra/touch-image-stats/20140302.changes
[15:36] <ogra_> i think i flashed with 213 or 212 last
[15:36] <davmor2> ogra_: I wonder if it just effects fresh flashing
[15:36] <ogra_> sabshould be http://people.canonical.com/~ogra/touch-image-stats/20140301.1.changes
[15:36] <ogra_> seb128, ^
[15:36] <ogra_> davmor2, seems so
[15:37] <seb128> ogra_, if you say so
[15:37] <ogra_> well, i think so
[15:37] <seb128> it might, they are less than 1 hour interval
[15:37] <ogra_> sigh ... i'll check the log ... not you made me uncertain :P
[15:37] <seb128> but android would be a better candidate to create bt issues than the download manager
[15:38] <ogra_> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-touch/20140301.1/livecd-20140301.1-armhf.out has
[15:38] <ogra_> Get:1 http://ftpmaster.internal/ubuntu/ trusty/multiverse android all 20140228-2008-0ubuntu1 [246 MB]
[15:38] <ogra_> so 1.1 was the right one
[15:39] <ogra_> which is 215
[15:40] <ogra_> seb128, i fully agree though ... but that sadly doesnt help :)
[15:40] <seb128> :-(
[15:41] <ogra_> and the android change itself  is a one liner in teh recover upgrader script ...
[15:41] <ogra_> there were new kernels with that android build though ...
[15:41] <ogra_> thats why i was pointing at them earlier
[15:41] <ogra_> but they also only had minor config changes that cant affect BT
[15:42] <seb128> ogra_, http://launchpadlibrarian.net/168024412/android_20140224-0005-0ubuntu2_20140228-2008-0ubuntu1.diff.gz
[15:42] <ogra_> (and the breakage still starts one image later only)
[15:42] <seb128> ogra_, that's not a 1 liner
[15:43] <seb128> well, the other parts are in libhybris though
[15:43] <ogra_> bootable/recovery/system-image-upgrader was the one i referred to (that was mine) ... i wasnt aware of the other changes
[15:43] <ogra_> yeah, and hybris isnt even involved in the BT stack ... thats actually plain android, we only set the android property to start/stop it on our side
[15:44] <ogra_> thats really confusing
[15:44] <ogra_> davmor2, hmm
[15:45] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/flo/216:20140302:20140301.1/6923/unity8/ ... the tests show that the Bt indicator was visible there too
[15:45] <ogra_> test_indicator_exists(Bluetooth) has passed
[15:45] <davmor2> ogra_: I'm reflashing 215 to double check
[15:45] <ogra_> (it fails if there is no BT indicator visible)
[15:45] <ogra_> so UTAH disagrees with you somehow about 216
[15:46] <davmor2> ogra_: how is utah installing the image?
[15:46] <ogra_> flo and mako on 216 both looks fine (manta doesnt have BT and thus fails all the time on this test)
[15:46] <ogra_> davmor2, it flashes using phablet-flash (still i think)
[15:46] <ogra_> with bootstrap option afaik
[15:47] <ogra_> davmor2, psivaa or plars should be able to tell
[15:47] <davmor2> ogra_: that's a difference then
[15:47] <ogra_> well, a minor one
[15:47] <ogra_> shouldnt influence BT
[15:47] <davmor2> ogra_: yay so 215 has no bluetooth on this flash
[15:48] <davmor2> ogra_: I wonder if it is just a race issue that as normal always effects me :D
[15:48] <ogra_> i wonder if you just hit some kind of weird race over there
[15:48] <ogra_> try a few reboots
[15:49] <davmor2> ogra_: adb reboot and I have bluetooth now
[15:49] <psivaa> ogra_: davmor2: "phablet-flash ubuntu-system -b --channel trusty-proposed" is what we use
[15:49] <davmor2> ogra_: looks like a race
[15:49] <davmor2> psivaa: thanks
[15:50] <plars> davmor2, ogra_: utah isn't installing the image per se, in fact utah doesn't even enter into the picture with installation really. There's a wrapper script called provision which calls phablet-flash (soon to use ubuntu-device-flash), phablet-network, phablet-config, phablet-click-test-setup, etc
[15:50] <awe> didrocks, I saw rsalveti's email from overnight.  Do you need my help debugging the ofono related problems?  Sounds like they were isolated to dialer AP tests only?
[15:50] <davmor2> plars: thanks
[15:51] <ogra_> davmor2, yay
[15:51] <didrocks> awe: hey, yeah, unfortunately, we saw that ofono-phonesimd wasn't uninstalled after the tests run (which is another bug and for doanac` :)). xnox is working on the fix I guess, maybe check with him?
[15:51] <ogra_> awe, xnox and i did much of the debugging already
[15:51] <didrocks> awe: I reverted, so no stress/hurry to get it fixed, just do when you have time
[15:52] <davmor2> ogra_: so I wonder if it is again an issue with ubuntu-device-flash and/or the way it is flashing?
[15:52] <ogra_> awe, i fear we need pitti for a proper fix
[15:52] <awe> ogra_, agreed... I've never actually touched the ofono-phonesim package
[15:52] <awe> ogra_, didrocks, was the ofono package reverted too?
[15:52] <ogra_> awe, ofono-phonesim calls a pretty evil script on autostart that loops over dbus until the scripts start to work ... not sure why the py3 port causes these dbus errors now
[15:52] <ogra_> awe, yes
[15:53] <awe> ok
[15:53] <didrocks> awe: I just reverted ofono, it was the only one changing
[15:53] <ogra_> awe, the ofono source package was reverted
[15:53] <ogra_> which reverts the scripts as well ... coming from the same source
[15:53] <awe> OK, so basically the py3 change sent the ofono-phonesim package into a tailspin
[15:53] <awe> arrggg
[15:53] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140303.1.changes
[15:54] <ogra_> thast the changelog of the last image ... all reverted
[15:54] <awe> k
[15:54] <ogra_> not sure where xnox went ... he was pretty angry about the revert
[15:55] <doanac`> didrocks: i think psivaa has a fix for that issue that can be merged now. i approved his MP a few minutes ago
[15:56] <didrocks> doanac`: excellent, something with autoremove and --purge?
[15:56] <didrocks> doanac`: so next image will (not the one running tests) will have thefix?
[15:56] <psivaa> didrocks: yes, i just pushed it but the tests have already started
[15:56] <doanac`> didrocks: that's exactly what psivaa changed
[15:56] <didrocks> great :)
[15:57] <didrocks> thanks guys!
[15:57] <didrocks> awe: rsalveti: at least, without that ofono issue, we wouldn't have found that infra bug, so in some way, was positive :)
[15:58] <awe> didrocks, always the optimist!  ;D
[15:58] <davmor2> ogra_: hmmm so any idea where I should file a bug if it is just a race condition?
[15:58] <didrocks> awe: hum, you don't talk to people knowing me well that often then ;)
[15:59] <didrocks> awe: people call me the pessimist rather :p
[15:59] <awe> well maybe they're wrong.  ;D
[16:00] <didrocks> ahah, I keep telling "I'm pessimistic, but most of the time, in the end, it's what happen" ;)
[16:01] <ogra_> davmor2, bluetooth-touch
[16:03] <davmor2> ogra_: ta
[16:04] <popey> ogra_: is 218 released? my mako is just sat there at 0%
[16:04] <popey> oh, ignore that, suddenly moved on
[16:04] <ogra_> y<eah
[16:04] <ogra_> seems to be fine
[16:06] <apw> ogra_, not that i know of, no
[16:06] <ogra_> apw, yeah, seems to be a race in userspace
[16:07] <apw> bluetooth is utter junk ...
[16:07] <ogra_> ++
[16:07] <cyphermox> word.
[16:07] <ogra_> cyphermox, we will need to look into manta (N10) at some point
[16:07] <cyphermox> hey, be my guest
[16:07] <cyphermox> what do you want to look at it?
[16:08] <ogra_> cyphermox, no idea, i see the BT device in rfkil and i see it being powered on in dmesg when i rfkill unblock
[16:09] <cyphermox> ok..
[16:10] <ogra_> cyphermox, so it seems there is some BT on the android side but i cant see anything of it on ubuntu
[16:11] <cyphermox> tbh I think I'll just make sure it works at all on mako, since I have the device to test with, and just enable any others missing once that's done
[16:12] <davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/bluetooth-touch/+bug/1287240
[16:13] <ogra_> davmor2, you forgot to mention that rebooting fixes it too :)
[16:13] <davmor2> ogra_: oh ah
[16:14] <davmor2> ogra_: no it's there honest you just weren't looking at where I hadn't typed it ;)
[16:15] <davmor2> cyphermox: I blame you entirely ;)
[16:17] <Laney> poor cypher :(
[16:18] <davmor2> ogra_, cyphermox: so oddly 214 still shows bluetooth with no issues.  So I'm wondering if it is the new android/kernel stack that then makes it racy?
[16:18] <davmor2> Laney: I'm only teasing cyphermox rocks really :)
[16:20] <cyphermox> no
[16:20] <cyphermox> if I rocked bluetooth would have been working weeks ago, and we wouldn't be talking about it anymore
[16:20] <ogra_> cyphermox, lol
[16:20] <ogra_> you think we would stop talking about it ?
[16:21] <cyphermox> yes
[16:21] <davmor2> cyphermox: but if it just worked you'd have nothing else to do right ;)
[16:21] <cyphermox> there is that ;)
[16:21] <cyphermox> so I'm very much thinking there's some kind of firmware issue but I can't put my finger on it
[16:21] <davmor2> cyphermox: okay so r214 looks good, upgrading to 218 and I have lost it again
[16:22] <ogra_> cyphermox, we have other issues on first boot as well, i suspect there is something that should hold up the boot that runs scripts on first boot which simply isnt holding us back
[16:23] <ogra_> the system goes to its knees if the apparmor click registration happens ... i suspect we want to have that block the boot and only move on if thats done
[16:23] <ogra_> (or something like that)
[16:25] <cyphermox> ogra_: I seriously doubt this would affect bluetooth
[16:26] <ogra_> cyphermox, i see off behavior of lightdm too
[16:26] <ogra_> only on first boot
[16:26] <cyphermox> sure
[16:26] <ogra_> which i wouldnt expüect to be affected either
[16:26] <cyphermox> but the bluetooth problems are very much lower level that that
[16:26] <cyphermox> at least, as far as making HSP and A2DP work
[16:26] <cyphermox> this is still the only thing I care about ^
[16:27] <ogra_> well, i'm only talking about races on startup :)
[16:27] <cyphermox> HSP still doesn't work, and without it, no point hacking much on UI and stuff ;)
[16:27] <cyphermox> right
[16:27] <ogra_> as long as the indicator is there i'm fine :P
[16:27] <cyphermox> race is for the indicator not showing?
[16:27] <ogra_> no, BT not coming up apparently
[16:27] <ogra_> davmor2, some logs your be nice on that bug
[16:27] <davmor2> cyphermox: it doesn't switch on from settings app either
[16:28] <cyphermox> ogra_: ok, then give me a second to reflash my mako to the latest image
[16:28] <davmor2> ogra_: sure what logs would you like from what image I'm current on 218 upgrade from 214 with no bt
[16:28] <ogra_> cyphermox, seems to need --bootstrap=true to actually trigger it
[16:29] <cyphermox> ogra_: I always do that :)
[16:29] <ogra_> davmor2, syslog is always helpful ... checking rfkill output
[16:29] <Laney> Silo for line 45 appreciated
[16:29] <Laney> Won't upload it without approval ;-)
[16:29] <cyphermox> Laney: just a second
[16:29] <Laney> k
[16:31] <davmor2> cyphermox, ogra_: done
[16:32] <davmor2> ogra_: only wifi shows in rfkill
[16:32] <ogra_> davmor2, that indicates that BT wasnt enabled by the upstart script
[16:32] <davmor2> cyphermox, ogra_: do you want me to reboot and grab the logs and rfkill output again?
[16:33] <cyphermox> Laney: need to wait after landing-002
[16:33] <Laney> cyphermox: ah ok
[16:33] <cyphermox> davmor2: sure
[16:33] <Laney> bfiller: ^^^ that says that it can be cleaned, can you look at that?
[16:34] <bfiller> Laney: looking
[16:34] <ogra_> davmor2, wait a sec ... getprop | grep hci
[16:34] <ogra_> davmor2, that output too
[16:34] <davmor2> ogra_: meh
[16:34] <bfiller> Laney: done
[16:34] <Laney> bfiller: thanks!
[16:34] <Laney> cyphermox: should be good to go in a few minutes then
[16:35] <rsalveti> ogra_: didrocks: it seems we got a fix for the camera issue, cleaning it up and testing with the other devices
[16:35] <ogra_> rsalveti, wohooo !
[16:35] <ogra_> you rock
[16:35] <davmor2> ogra_: right I'll grab that from my mako
[16:35] <ogra_> (and should really sleep at one point again)
[16:35] <ogra_> davmor2, anyway, i'd like one with and one without BT
[16:36] <rsalveti> ogra_: tvoss helped as well :-)
[16:36] <ogra_> rsalveti, i thought so ... given your mail :)
[16:36] <davmor2> ogra_: yeah I haven't rebooted my mako so it still has no bt
[16:36] <didrocks> rsalveti: oh, already? rocking! :)
[16:36] <ogra_> great
[16:37] <didrocks> rsalveti: you have time, tests are just starting, so I guess a good 2 hours if you want to kick an image before your EOD ;)
[16:37] <didrocks> (if you want to get results before your EOD)
[16:37] <davmor2> ogra_: added
[16:37] <ogra_> thx
[16:37] <ogra_> yeah
[16:37] <ogra_> [init.svc.hciattach]: [stopped]
[16:38] <ogra_> the upstart job raced it seems
[16:38] <ogra_> (it calls the setprop
[16:38] <ogra_> )
[16:38] <rsalveti> didrocks: great
[16:38] <dbarth> didrocks: missed the ping earlier, but yeah i saw Mirv's comments
[16:39] <dbarth> didrocks: i have validated the silo 005 again, since it's been reconfigured; with regression testing to check that webapps and browser keep working of course
[16:39] <dbarth> didrocks: ready for landing when you see fit
[16:39] <didrocks> dbarth: ok, so Mirv or anyone else can follow now the test procedure and reproduce?
[16:40] <didrocks> (which was the issue Mirv had IIRC)
[16:40] <dbarth> didrocks: for the hmtl5 stack part (ie silo 001, i'm updating the test proc. to re-do the tests cleanly
[16:40] <didrocks> dbarth: oh sorry, 005, not 001
[16:40] <didrocks> ok then :)
[16:40] <dbarth> will ping shortly for 001
[16:40] <davmor2> ogra_, cyphermox: added new syslog and reran commands on flow for comparison
[16:40] <didrocks> davmor2: great ;)
[16:41] <didrocks> hum dbarth: great ^ ;)
[16:41] <didrocks> dbarth: we'll have someone looking at online account
[16:41] <dbarth> didrocks: but can you reconfigure 001 with the latest stack of branches (we have docs fixes now, and some more)
[16:41] <dbarth> didrocks: thanks
[16:41] <ogra_> davmor2, thx
[16:41] <didrocks> dbarth: oh sure, one sec
[16:41] <davmor2> didrocks: you can call me great anytime I won't take offence :)
[16:41] <didrocks> dbarth: you added someMPs?
[16:41] <didrocks> davmor2: great! :)
[16:41] <didrocks> :p
[16:42] <davmor2> :D
[16:43] <Laney> cyphermox: ogoggogogo
[16:44] <dbarth> didrocks: yes, added some more (doc fixes, one runtime fix)
[16:44] <didrocks> Laney: cyphermox: oh, you took my runner! :)
[16:44]  * didrocks was queued for at least… 10s!
[16:44] <cyphermox> mwahhaah
[16:45] <cyphermox> Laney: done.
[16:45] <didrocks> dbarth: done
[16:45] <didrocks> 10s later
[16:45] <didrocks> thanks to cyphermox and Laney :p
[16:45]  * didrocks shakes fist
[16:48] <Laney> usain bolt eat your heart out
[16:52] <sil2100> And now even internet mocks me
[16:52]  * sil2100 shakes his fist
[16:52] <didrocks> sil2100: you did install the ofono-desktopinternet package? :p
[16:52] <davmor2> sil2100: oh great there are 2 of you now then, but one only works in testing environments?
[16:53] <didrocks> davmor2: as long as there is no race by the 2 answering simultaneously…
[16:53] <sil2100> ...;p
[16:53] <Laney> I can't authenticate to be able to press build on my silo
[16:53] <Laney> anyone else seen this?
[16:53] <didrocks> Laney: are you really you? :)
[16:53] <Laney> I press "Yes, log me in" and get taken to a blank page
[16:54] <davmor2> didrocks: as long as the reply is the same surely it just becomes self confirming :)
[16:54] <didrocks> Laney: I guess its #is? (or #webops?)
[16:54] <Laney> dunno, could be a didrocks bug :-)
[16:54] <didrocks> Laney: unlikely on that part TBH :p
[16:54] <didrocks> (/me hides the "blacklist Laney" commit)
[16:54] <Laney> hahaha
[16:54] <didrocks> davmor2: but you need to be equipped to support that
[16:54] <Laney> can you verify anyway?
[16:55] <didrocks> yeah, let me see if someone changed the sso cred
[16:55]  * davmor2 confirms that Laney is Blacklisted thanks to didrocks hidden patch
[16:55] <didrocks> davmor2: test passed \o/
[16:55] <Laney> THIS GUY IS TOO GOOD
[16:55] <Laney> SLOW HIM DOWN A BIT
[16:55] <didrocks> ahah :)
[16:56] <didrocks> Laney: so, the sso id didn't change
[16:56] <didrocks> let me try to logout and back in
[16:56] <didrocks> Laney: working well here
[16:57] <Laney> ok, let me fully log out
[16:57] <Laney> noooooooooooooooooooooooooooooooooo
[16:58] <didrocks> hum?
[16:58] <didrocks> are you fired finally?
[16:58] <didrocks> :)
[16:58] <Laney> hah
[16:58]  * Laney (checks to make sure...)
[16:58] <didrocks> :p
[16:58] <Laney> webops time
[16:58] <didrocks> I guess so :/
[17:00]  * Laney tries in chromium first
[17:00] <didrocks> ah, you are starting to use a web browser? :)
[17:00]  * didrocks looks
[17:00] <didrocks> oh, it's not Friday :p
[17:00] <Laney> hrhr
[17:02] <davmor2> didrocks: are you laughing at didrocks in a French accent with the hrhr ;)
[17:02] <Laney> that worked :|
[17:03] <didrocks> cyphermox: popey: davmor2: coming?
[17:03] <popey> can't, am on another hangout I'm afraid
[17:04] <davmor2> omw
[17:07] <cyphermox> sorry, I'm breaking audio on my laptop to figure out stuff on the phone :/
[17:07] <cyphermox> brb
[17:11] <Laney> the pbuilder chroots that you build the source packages in should be freshened ;-)
[17:12] <cjwatson> Does CI still have a mirror of cdimage.ubuntu.com which keeps more history?
[17:13] <cjwatson> I vaguely recall you did once ...
[17:18] <jibel> retoaded, ^ does it still exist? it was setup on magners-orchestra but I lost track after the move.
[17:22] <davmor2> didrocks: yeah I blame sil2100 we already know the internet hates him and it is starting to spread :D
[17:23] <didrocks> davmor2: right, even in the US, poor balloons!
[17:24] <davmor2> indeed
[17:25] <balloons> I did manage to get image 218 downloaded and flashed, so I suppose everything I need from the internet is done for today eh?
[17:25] <didrocks> balloons: just install ofono-phonesim and are you done: fully offline!
[17:25] <davmor2> balloons: yeah just work on your phone all day via 3g right
[17:26] <davmor2> didrocks: that's evil dude
[17:26] <didrocks> ;)
[17:27] <davmor2> didrocks: don't forget about finding out that the images are all R/W instead of R/O
[17:27] <didrocks> davmor2: yeah, but seems the download is stalling
[17:27] <didrocks> davmor2: anyway, it's on my list, probably tomorrow morning
[17:28] <balloons> didrocks, brillant idea!
[17:28] <davmor2> oh man see sil2100 hate of internet is affecting you too now dude it's spreading faster
[17:28] <balloons> davmor2, yes I spent some time usb tethered this morning.. I'm happy to report it "just worked" on ubuntu
[17:28] <balloons> I was surprised
[17:29] <didrocks> davmor2: right, it's a plague!
[17:29] <davmor2> balloons: usb tethered to an ubuntu phone?   or android
[17:29] <didrocks> balloons: ahah, my last attempt wasn't that successful
[17:30] <sil2100> ;)
[17:30] <balloons> davmor2, android.. Can't flash the phone you are tethering eh? :-)
[17:31] <didrocks> kgunn: I added a note earlier this morning to tell you are blocked on the dbus-cpp from tvoss' landing. Not sure you read it
[17:32] <didrocks> (due to unity-system-compositor)
[17:32] <davmor2> balloons: right yeah so that under ubuntu just works for me too, you can apparently manually set it up on ubuntu phone too but you need to know the random voodoo that you need to shout at the command line :)
[17:32] <kgunn> arg... didrocks, ok...thanks
[17:32] <didrocks> kgunn: tvoss told he would have that done by EOD, but seems a little bit late
[17:32] <kgunn> and i'm behind on mails...so thanks :)
[17:32] <didrocks> so maybe you should talk together to see who is first (we can flush dbus-cpp silo :))
[17:33] <didrocks> kgunn: oh, it's just a comment on the ci train spreadsheet
[17:33] <tvoss> didrocks, I only got the silo this morning. On it
[17:33] <kgunn> didrocks: i won't push tvoss too hard...it allows me to sneak stuff in :)
[17:33] <sil2100> tvoss: did you find any testers?
[17:33] <didrocks> kgunn: ahah :)
[17:33] <sil2100> ;)
[17:33] <tvoss> sil2100, yup, Wellark is helping me out and I will test myself now
[17:33] <kgunn> tvoss: no worries, i can probably pull over a few more changes from dev branch
[17:33] <didrocks> great :)
[17:35] <cjwatson> tvoss: you have a gigantic libclick MP in your inbox
[17:35] <tvoss> cjohnston, \o/
[17:35] <cjohnston> other cj<tab>
[17:36] <cjwatson> Ha, LP helpfully truncates the diff before it gets to any of the actual new library code ...
[17:37] <tvoss> cjwatson, yeah :) just seeing that
[17:41] <tvoss> cjwatson, I will likely take some time for the review
[17:42] <tvoss> rsalveti, is the camera issue fixed?
[17:43] <cjwatson> tvoss: understood
[17:44] <tvoss> rsalveti, or better: does it work reliably across devices?
[17:45] <rsalveti> tvoss: still testing
[17:45] <tvoss> rsalveti, ack
[17:50] <retoaded> jibel, sorry, cd ubot5
[17:51] <jibel> retoaded, what do you mean?
[17:51] <retoaded> jibel, window shifted focus on me
[17:52] <retoaded> jibel, what I had started to type before I was distracted was sorry, checking into the mirror data now
[18:16] <davmor2> I got the unity8 crash again \o/
[18:41] <rsalveti> haha, annoying that with vibrator the device keeps moving when running autopilot tests
[18:45] <davmor2> rsalveti: haha
[18:46] <ogra_> yeah
[19:05] <retoaded> jibel, cjwatson: we do not have a mirror of cdimage.u.c. the history we do have covers 20130406 to 20131109
[19:24] <bregma> hokay, not sure who is handling this at the moment, but I need silo assignments for platforms 46 and 47 for ci-train departures
[19:24] <bregma> just, you know, thought I'd put that out there
[20:00] <robru-at-doctor> bregma, I just got back from the doctor. should have been cyphermox handling it up til now but it's ok, I'm here now
[20:00] <bregma> get well soon
[20:00] <robru-sick> thanks
[20:00] <cyphermox> bregma: you can ping when you need something
[20:02] <robru-sick> bregma, ok, got you silos 8 and 9. please build
[20:02] <bregma> robru-sick, thanks
[20:07] <robru-sick> bregma, you're welcome
[20:51] <cjwatson> retoaded: ok, worth a try, thanks
[20:51] <retoaded> cjwatson, np
[21:53] <kgunn> robru-sick: yo...your still sick, sorry to hear it...i had the flu over my holidays...14 days of being down and out...i sympathize
[21:53] <kgunn> robru-sick: any chance of getting a build silo for row 30 ?
[21:53] <robru-sick> kgunn, yeah, I just got diagnosed with strep throat today. it's rough
[21:53] <kgunn> robru-sick: almost as bad as the flu...shorter, but way more pain
[21:53] <robru-sick> kgunn, yeah, lots of pain
[21:54] <robru-sick> kgunn, so... i've been instructed to delay line 30, because it's considered high risk and we're still working towards getting a green image
[21:55] <robru-sick> kgunn, but i dunno, i guess it can't hurt just to have the silo...
[21:56] <kgunn> robru-sick: right...i want the silo
[21:57] <kgunn> i love it..."high risk"
[21:57] <robru-sick> kgunn, well that's a huge list of MPs you have there ;-)
[21:57] <kgunn> i haven't broken shit in months....and i'm high risk
[21:57] <kgunn> yeah...true
[21:57] <robru-sick> kgunn, more to do with the fact that it's a low-level system component. if you break something, everybody is effected.
[21:57] <robru-sick> kgunn, not that you're likely to, just that if you do, it's much higher impact
[21:58] <robru-sick> kgunn, just tried to assign the silo but it failed due to platform-api already being in silo 15
[21:58] <robru-sick> kgunn, so I guess ping tvoss to get his silo 15 tested and published.
[21:59] <kgunn> @ being blocked, thanks for trying, @risk yeah i know...@number of mp's..worth noting that list'd be shorter if landing could happen but i've been put on "high risk" ignore category since thurs :)
[22:00] <kgunn> man...i can't catch a break :)
[22:02] <robru-sick> kgunn, sorry!
[22:03] <kgunn> hey, it happens
[22:03] <kgunn> fwiw, i told tvos no worries earlier :)
[22:04] <kgunn> thot he'd be done by his eod