[02:10] <imgbot> [03:25] <imgbot> [03:25] <imgbot> [04:33] <rsalveti> ogra_: small one https://code.launchpad.net/~rsalveti/ubuntu-touch-session/fixing_expect_upstart_obexd/+merge/257202
[07:03] <ogra_> rsalveti, approved
[08:16] <sil2100> Mirv: we have one free silo - do you want to take it? ;)
[08:20] <Mirv> sil2100: well.. I think I'd rather wait for a better situation. I need to first to do the actual rebasing (of this Qt 5.6 code...) anyway and can build locally, plus thumbnailer branch isn't ready
[09:00] <sil2100> dbarth_, oSoMoN: ping
[09:00] <oSoMoN> sil2100, pong
[09:00] <oSoMoN> what’s up?
[09:00] <sil2100> dbarth_, oSoMoN: the oxide 1.6.4 silo seems to have some webapp problems (QA double-confirming now), did that pop up during your testing as well?
[09:01] <sil2100> Also, how's progress with 1.7.2 testing?
[09:01] <oSoMoN> sil2100, I didn’t see any issues with webapps with 1.6.4, what kind of issues?
[09:01] <oSoMoN> sil2100, we found a blocker with 1.7.2, Chris wrote a fix and we will have to update the silo to 1.7.4
[09:02] <oSoMoN> I mean 1.7.3
[09:02] <sil2100> oSoMoN: ToyKeeper commented on trello: "Fail: This silo fixes the HERE T&C but makes web apps crash on start."
[09:02] <sil2100> You can check the details there
[09:03] <sil2100> davmor2 will try to reproduce
[09:04] <oSoMoN> I did my testing on krillin
[09:05] <dbarth_> pong
[09:05] <dbarth_> 1.7.3 working great here
[09:05] <dbarth_> checking the trello board now
[09:07] <dbarth_> oSoMoN: i wonder if the crashers are arale and same as what we saw yesterday
[09:07] <dbarth_> ie, the sandbox model change triggered by the newer kernels
[09:07] <dbarth_> ToyKeeper: around? can you confirm the tests were on arale?
[09:08] <ToyKeeper> dbarth_: Yes, it was on arale.
[09:08] <oSoMoN> dbarth_, it shouldn’t be related, afaiu that’s a change in chromium itself
[09:08] <dbarth_> right
[09:08] <dbarth_> webbrowser-app works, because of the security policy, but all webapps would crash because of that newer kernel
[09:08] <dbarth_> well, i guess 1.7.3 comes handy then
[09:08] <oSoMoN> dbarth_, still, we should try and publish 1.6 first
[09:09] <dbarth_> but just not on arale
[09:09] <dbarth_> sil2100: how's that doable ? ie, release 1.6.4 to all but vivid/arale
[09:09] <dbarth_> and line up 1.7.3 in a silo for the image
[09:09] <dbarth_> sorry it is that complicated
[09:12] <oSoMoN> dbarth_, I’m not an expert on that, but I don’t think that’s doable, the same archive and overlay PPA feed all images
[09:14] <dbarth_> so 1.6.4 for vivid is toasted; there's just the security updates for other releases which will be releasable
[09:14] <dbarth_> and 1.7.3 is the only one we can try on vivid proper
[09:14] <sil2100> dbarth_: we can't release something that's broken for arale...
[09:14] <dbarth_> 1.7.2 was already working fine on mako, 1.7.3 fixes issues on arale
[09:14] <sil2100> Since our goal is arale
[09:14] <dbarth_> sil2100: precisely
[09:14] <dbarth_> so unfortunately the 1.6.4 step was a waste of efforts
[09:15] <sil2100> No worries, let's just try making sure 1.7.3 is good for everything
[09:15] <dbarth_> i'll double check on krillin and mako right now
[09:15] <sil2100> Thanks :)
[09:34] <jibel> sil2100, so we stop on 1.6.4 and wait for a new silo with 1.7.3?
[09:42] <sil2100> jibel: yeah... there's no use in 1.6.4 it seems ;/
[09:42] <jibel> k
[09:42] <sil2100> It was broken on arale from the start it seems
[09:42] <jibel> dbarth_, ETA for a new version?
[09:48] <sil2100> At least it seems to be already built...
[09:53] <oSoMoN> dbarth_, no 1.6.4 was not a waste of efforts, it still needs to go to vivid-security
[10:05] <dbarth_> jibel, oSoMoN: 1.7.3 is built indeed
[10:07] <dbarth_> the build won't install on krillin/rtm-14.09 though, because of build deps; it will take a source copy into a silo to get rid of media-hub/qt5.4 build deps i guess
[10:07] <dbarth_> i'm on reviving my mako which fainted out of battery last night
[10:19] <dbarth_> jibel, sil2100, oSoMoN: initial testing on mako/vivid is positive: problems fixed and we even get background audio playback for free ! :) \o/
[10:20] <sil2100> Ou yeah
[10:20] <sil2100> \o/
[10:20] <dbarth_> and arale was working fine earlier today on my arale with the key webapps as well + webgl in the browser + CTR as well
[10:20] <dbarth_> maybe we can unfold the rest of the test suite with oSoMoN and hand that over back to QA early this afternoon
[10:20] <sil2100> dbarth_: that's great news - when do you think it would be ready for a silo? Maybe we could re-use the 1.6.4 silo and just copy over the newer oxide
[10:21] <oSoMoN> ubuntu-qa: any chance silo 21 will be validated before the landing gates for vivid close tonight?
[10:21] <sil2100> Would be great, we can't have the RC without a new oxide
[10:21] <dbarth_> sil2100: ah silo yes: can you transfer the build to whichever is free
[10:22] <sil2100> dbarth_: btw. there's silo 11 that has oxide 1.5.6 in it, let me free that up then
[10:22] <rvr> oSoMoN: It's in the queue, so there are chances.
[10:22] <dbarth_> oSoMoN: so that 1.6.4 silo is not needed anymore, since the other releases will be via the normal security pocket
[10:22] <jibel> oSoMoN, priority is 16, 18, 25 and 27. It can be verified once these are done
[10:23] <dbarth_> sil2100: right, this one is outdated anyway
[10:23] <sil2100> jibel: do we have anyone on 18 from our current timezone?
[10:23] <jibel> rvr, which silo are you on?
[10:24] <dbarth_> jibel: and so 16 becomes 11, as i guess oxide is the priority item
[10:24] <rvr> jibel: I've been trying to validate 7, but I'm blocked and will take 27 after repartitioning
[10:24] <jibel> dbarth_, ack
[10:24] <oSoMoN> dbarth_, sure the silo is not needed any longer, but the testing was not a waste of time
[10:25] <dbarth_> oSoMoN: no, you're right
[10:25] <oSoMoN> jibel, rvr: thanks, you guys are doing a great job of validating our work, keep it up :)
[10:25] <sil2100> chrisccoulson: hey! So I would like to copy 1.7.3 from the phablet PPA to a silo PPA but I see that it's suffixed with ~ppa1 - would you want to publish it with this version to the touch overlay PPA?
[10:25] <jibel> rvr, can you continue alesage verification of 18?
[10:26] <rvr> jibel: Sure
[10:26] <jibel> rvr, thanks
[10:27] <sil2100> dbarth_, oSoMoN, jibel: I'll copy oxide-qt 1.7.3 to silo 16, but it'll be with the ~ppa1 suffix
[10:27] <sil2100> I think it should be fine to publish it with such a version
[10:28] <sil2100> Since we're publishing to the PPA nad 1.7.3 will appear in security with the right version sooner or later anyway
[10:29] <oSoMoN> sil2100, the changelog doesn’t include the 1.7.3 changes, I don’t think that build is intended for publication as is
[10:29] <oSoMoN> chrisccoulson, can you confirm? ^
[10:30] <chrisccoulson> sil2100, oSoMoN, that's fine. I didn't include the extra change as it disables a feature that was already disabled in previous releases
[10:31] <oSoMoN> ok, thanks
[10:31] <sil2100> ACK
[10:31] <sil2100> So I guess it's fine to copy
[10:31] <oSoMoN> seems so
[10:35] <sil2100> cjwatson: hey! Could you maybe bump the size of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages for us? :)
[10:35] <sil2100> cjwatson: thanks!
[10:51] <cjwatson> sil2100: how about I implement my suggestion from the other day to set all silos to 20480MB across the board?
[10:51] <cjwatson> (then I'm going back to being on holiday)
[10:53] <cjwatson> sil2100: that's done now (the across-the-board thing)
[10:57] <sil2100> cjwatson: thanks :)
[10:57] <sil2100> Works fine for us at least
[11:07]  * sil2100 off to a family lunch
[12:31] <jibel> dbarth__, oSoMoN is oxide 1.7 ready for testing? or it'll never land on time.
[12:37] <oSoMoN> jibel, it is, I’ll be testing in parallel with you guys
[12:52] <rvr> Mirv: ping
[12:53] <Mirv> rvr: pong
[12:53] <rvr> Mirv: I have installed silo 18
[12:54] <Mirv> rvr: I've just updated both trello and the bug report with my afternoon's test findings. it seems the problem is that U1 account disappears on reboots (usually) when using th e silo.
[12:54] <rvr> Mirv: I can reproduce the problem. When I hit to "Install", nothing happens. But then, in Ubuntu System Settings, the account was gone.
[12:54] <rvr> Mirv: Yes, I confirm.
[12:54] <Mirv> so when I tested before that I updated to silo first, then added account and tried installing apps I didn't see a problem
[12:55] <Mirv> sil2100: ^ unfortunately even thought the unity8 hang is gone it does not seem the current upstream state of the patches is good enough for us, or alternatively there's some complications in backporting them to 5.4
[12:55] <Mirv> tsdgeos: ^ 018 does not seem good for our use, even forget about KDE legacy apps for a while
[12:56] <Mirv> tsdgeos: did you discuss with thiago about the current state and Merge ETA?
[12:56] <tsdgeos> Mirv: i haven't been able to get him on IRC the last two days
[12:56] <tsdgeos> so n
[12:56] <tsdgeos> o
[12:56] <Mirv> I noticed some of the MR:s actually had been merged, but not the bunch of it
[12:57] <Mirv> I wonder if the route of "use DBus less like we did until February" is a possible workaround
[12:57] <Mirv> for the boot issue
[13:00] <tsdgeos> Mirv: it could i guess yes
[13:00] <Mirv> pete-woods: tsdgeos: do you think anything in http://bazaar.launchpad.net/~unity-team/libusermetrics/trunk/revision/189 - which triggered the issue in February, could be changed in a way that for example libusermetrics and Unity8 wouldn't use the DBus at the same time so Unity8 wouldn't randomly hang during the boot?
[13:00] <Mirv> like delaying the libusermetrics until a bit later, or getting a signal from unity8 to proceed or something like that
[13:03] <pete-woods> Mirv: well I'm hesitant to just assume it's interaction like that. it could be libclick blocking, or a bunch of different things
[13:04] <Mirv> pete-woods: in the bug report there was this piece of information earlier "I got a symbolic trace out of all the threads. It seems to be a dbus lock between usermetrics and networkmanager bits."
[13:05] <pete-woods> Mirv: okay, well I suspect that if it's happening now, it could easily have happened before that change
[13:06] <pete-woods> the change you linked just adds a new source for translations
[13:06] <pete-woods> it doesn't really change the way we use DBus
[13:06] <Mirv> pete-woods: yes, it could, but the thing is that it didn't, and because upstream still doesn't have a complete fix we're wondering if we can trigger it back one way or another to the shape that things don't collide during bootup (unity8 <-> networkmanager <-> libusermetrics)
[13:09] <Mirv> there were other landings in http://people.canonical.com/~ogra/touch-image-stats/106.changes for sure too, but it's mostly general libraries
[13:09] <tsdgeos> Mirv: honestly i'd rather get us to put someone to work on fixing those patches were needed and other software if needed than doing fragile changes hoping a lock won't happen
[13:09] <tsdgeos> but i'm not the manager :D
[13:10] <Mirv> sil2100: ^ we need a manager! :)
[13:10] <Mirv> sil will read the backlog once back from his family lunch
[13:17] <Saviq> trainguards, looking at https://launchpadlibrarian.net/204090374/unity8_8.02%2B15.04.20150423-0ubuntu1_source.changes is it on purpose that the "added:" string is on the same line?
[13:17] <Saviq> in the most recent changelog
[13:26] <Mirv> Saviq: probably not and robru will want to add a \n in there
[13:27] <Saviq> Mirv, is it the plan to list things like dependency changes and such in there? (TBH listing added/removed files feels extreme IMO)
[13:33] <Mirv> Saviq: well I'd have thought deps would be the first to be added, but maybe that's experimentation now
[13:49] <sil2100> Mirv: wazzup?
[13:49] <sil2100> Reading backlog
[13:50] <sil2100> Mirv, tsdgeos: ok guys, do we have any other short-term options to get this bug resolved?
[13:52] <tsdgeos> sil2100: define short-term :D
[13:53] <sil2100> Like, anything we can do till EOD
[13:53] <sil2100> ;p
[13:54] <sil2100> Or, at max till Monday
[13:54] <sil2100> tsdgeos: btw. since it's been a while since I had this info - could you remind me how often the unity8 hang on boot happens?
[13:57] <tsdgeos> sil2100: i guess it depends on how unlucky you are
[13:57] <tsdgeos> i'd go with "not very often"
[13:57] <tsdgeos> but since it's race dependant, it happens more on first boots after flashing when the qml cache is being built
[13:57] <tsdgeos> so it's kind of bad for first experience if your first boot ever gets you a deadlocked phone
[13:58] <sil2100> Right, so it's as I thought then... no quick workaround we can do to make the race happen less frequently for first boots?
[13:59] <tsdgeos> not that i know of
[14:00] <sil2100> Damn...
[14:00] <sil2100> pmcgowan: we might have a slight problem ^
[14:01] <pmcgowan> I have been listening
[14:02] <pmcgowan> tsdgeos, Mirv so what is it that is racing
[14:03] <tsdgeos> pmcgowan: qtdbus code
[14:04] <pmcgowan> tsdgeos, was looking for a bit more, like its libusermetrics doing somethign while ...
[14:06] <tsdgeos> pmcgowan: there is lots of things we use that use dbus, one case we've seen is libusermetrics watching a dbus signal while qt-networkmanager waiting for networkmanager answering on how many networks there is
[14:06] <tsdgeos> but wouldn't say this is the only such case
[14:07] <tsdgeos> basically the qtdbus code is not good when used from multiple threads
[14:07] <pmcgowan> thats awful
[14:07] <rsalveti> yeah
[14:07] <rsalveti> unity8 can't hang on boot
[14:07] <rsalveti> sil2100: even if it hangs like 1/10
[14:07] <rsalveti> on factory that is a lot
[14:07] <pmcgowan> yeah factory is more the issue that customer since thats the first boot
[14:08] <ogra_> rsalveti, thats just because we dont produce enough phones :P
[14:08] <sil2100> Right
[14:08] <sil2100> That's why I always advertised this issue as a 'ship blocker'
[14:08] <sil2100> And now it finally seems that we're stuck with a ship blocker without a good way to workaround/fix it
[14:09] <sil2100> It was important enough for us to actually agree on getting so many devel patches to Qt ;p
[14:09] <sil2100> Still, it seems we have bugs
[14:09] <sil2100> tsdgeos, Mirv, pmcgowan: maybe we could have some additional people looking into solving this issue?
[14:10] <tsdgeos> sil2100: those patches are going to eventually hit upstream and we while eventually move to that upstream version, so we should just use them and make sure they are good enough imho
[14:10] <tsdgeos> s/while/will
[14:11] <pmcgowan> tsdgeos, so you suggest we fix the patches
[14:11] <sil2100> I would say that sounds like a good idea, but do we have enough experienced manpower to do it till the EOW?
[14:12] <sil2100> There's also the risk that those patches introduced additional regressions
[14:12] <sil2100> So we need to proceed carefully
[14:12] <ogra_> heh
[14:12] <ogra_> EOW sounds so far away
[14:12] <ogra_> you could have said "tomorrow" :)
[14:12] <sil2100> ogra_: ;)
[14:12] <tsdgeos> sil2100: EOW? i doubt we can do anything before tomorrow, no
[14:12] <sil2100> ogra_: tomorrow is like 8 letters, while EOW is 3 - I obviously took the shortest one ;)
[14:13] <ogra_> wo, are you sure you are not german ?
[14:13] <ogra_> *wow even
[14:13] <sil2100> tsdgeos, pmcgowan: we could of course proceed with building the RC image and in the meantime hope for the boot-hang fix, and then do a delta test once we release it
[14:14] <sil2100> But...
[14:14] <sil2100> Qt is such a low-level component and shared by so many applications that the delta testing will mean re-runing a lot of tests
[14:14] <ogra_> yeah, wouldnt buy us much
[14:14] <sil2100> So *at best* we'll need one more day to finish testing
[14:14] <tsdgeos> sil2100: yes, you basically need to test "everything" since nowadays dbus is everywhere in our stack
[14:15] <pmcgowan> sil2100, tsdgeos the part I missed is what regressions did we see with the patches, or did they just not solve the problem
[14:15] <sil2100> pmcgowan: it solves the problem, but there are issues with things like unable to install apps and accounts disappearing
[14:16] <sil2100> So pretty serious regressions
[14:16] <pmcgowan> sil2100, tsdgeos and why on first boot
[14:16] <tsdgeos> pmcgowan: first boot is more common because there's no qml cache built yet, so things run "at a different speeed"
[14:17] <pmcgowan> tsdgeos, can we preseed the cache
[14:18] <tsdgeos> pmcgowan: i guess we could, ricmm_ would know more, but the hang may still happen, tests indicate that a bit less frequently, but would still be there
[14:19] <Mirv> sil2100: I'd say "fix Qt" is what's wanted, but meanwhile if anything could arranged during boot to not have multiple threads accessing DBus, similar to what we had until February 20th when libusermetrics changed behavior, we'd be in a fragile yet similar to before-Feb20th situation
[14:21] <tsdgeos> Mirv: honestly i think it's unfair to blame it on that libusermetrics change, has anyone tested that reverting that change makes it less frequent?
[14:21] <Mirv> Saviq: tsdgeos: can you share your unity8 booting script you used to the bug report? I mean, if experimenting with the boot process. I remember you were able to get it by cleaning cache all the time and rebooting 10-30 times.
[14:21] <Mirv> tsdgeos: it's unfair to blame it on that, but we've data that the problem didn't exist before that day of http://people.canonical.com/~ogra/touch-image-stats/106.changes
[14:21] <Mirv> it's not really "libusermetrics" problem, but "what happens during boot triggering Qt problem"
[14:23] <Saviq> Mirv, while true; do adb shell rm -R "~phablet/.cache/QML"; ./tools/unlock-device || break; done
[14:23] <Saviq> Mirv, where ./tools/unlock-device is from lp:unity8
[14:23] <tsdgeos> Saviq: don't you need to restart unity8 at some point?
[14:23] <tsdgeos> ah  ./tools/unlock-device does it
[14:24] <Mirv> Saviq: thanks. it looks like unlock-device is the thing that reboots?
[14:24] <tsdgeos> ignore maself
[14:24] <Saviq> tsdgeos, Mirv, yeah unlock-device does it all
[14:24] <sil2100> Mirv, tsdgeos: how many people do we have that could work on fixing the Qt patches to not cause these regressions?
[14:25] <sil2100> Mirv: my memory is weary so I don't remember what the situation was in February - we didn't have any hangs like this then, right?
[14:25] <Saviq> sil2100, we don't have anyone dedicated to upstream Qt work
[14:26] <Mirv> sil2100: yes, there's some amount of info in the bug report but one can also see it in the dashboard results and boottest results before/after 20150221 image
[14:27] <tsdgeos> Saviq: i guess between 0 and ~300 depending on how selective you want to be :D
[14:27] <tsdgeos> sil2100: i mean ↑↑↑
[14:27]  * tsdgeos hides from the bad joke
[14:27] <sil2100> ;)
[14:28] <sil2100> I think we should really consider assigning someone to do Qt-specific bugs for usptream, I know tsdgeos is doing a lot of work with Qt but maybe we could dedicate someone only to this purpose
[14:28] <sil2100> But that's something for the future
[14:29] <tsdgeos> i mean i have "some" experience with the dbus code, i produced a patch that shifted the deadlock from one place to another different place :D
[14:29] <tsdgeos> no idea if there's someone with qtdbus experience
[14:32] <Mirv> going through our upstream committers, tsdgeos and mardy are ones who have 1-2 QDBus commits
[14:33] <sil2100> Do we have any leads what might be causing the regression in accounts and app installation?
[14:33] <sil2100> Actually, I'll read the latest comment in the bug
[14:35] <Mirv> sil2100: yes, do that. it sounds like QDBus is simply failing during boot in some way resulting in the account getting removed on an error either during boot or later when an app is tried to be installed. the account handling in u-o-a could be handled more error-pronely, but the question is what else might be broken (even though all AP:s pass and the Unity8 hang is now gone)
[14:35] <rvr> rsalveti: ping
[14:36] <Mirv> so the options are 1. fix Qt (long term), 2. experiment with boot ordering without touching Qt to try to get to February situation in DBus usage during boot, 3. make u-o-a more error-prone so that the current 018 is usable as is
[14:36] <rsalveti> rvr: pong
[14:36] <Mirv> 3. if there are no other regressions, it seems like everything problematic with or without the PPA is related to boot time simultaneous use
[14:37] <sil2100> Mirv: maybe we could get someone from u-o-a to take a look at that - they might know exactly what u-o-a does and how it might break QDBus in our current situation
[14:37] <rvr> rsalveti: https://trello.com/c/OpyHNSgA/1441-ubuntu-landing-027-ofono-awe-rsalveti
[14:37] <rsalveti> rvr: are these new issues?
[14:38] <sil2100> mardy: ping
[14:38] <mardy> sil2100: I'm from u-o-a, I've seen my name highlighted a few times in this channel, but i didn't understand yet what bug we are talking about :-)
[14:38] <Mirv> sil2100: I guess that'd be mardy who also has a bit of QDBus experience. he's probably EOD for today. but yes he could install 018 silo and try to see if the problem can be workarounded in u-o-a.
[14:38] <rvr> rsalveti: I was verifying "Blocked SIM card keeps on asking for PUK"
[14:38] <mardy> Mirv: still 22 mins to go :-)
[14:38] <Mirv> mardy: if you install 018 and add U1 account and install apps, the U1 account disappears either during next boot or after the next boot when you try to install an app.
[14:39] <rvr> rsalveti: And i haven't been able to fully unblock my SIM card so...
[14:39] <Mirv> mardy: related to bug #1421009
[14:39] <tsdgeos> mardy: so there's a qtdbus bug in which it deadlocks, we have upstream patches from thaigo that fix that by moving lots of stuff into threads and generally "doing stuff better" but it seems some part of the accounts stack regresses because of it
[14:39] <rsalveti> rvr: hm, need help from alfonso here
[14:40] <rvr> abeato: ^^
[14:41] <abeato> rvr, what do you mean? have you blocked your SIM?
[14:41] <rvr> abeato: To test PUK, yes
[14:42] <abeato> rvr, ok, and which is the issue?
[14:42] <rvr> abeato: I've been trying to verify  "Blocked SIM card keeps on asking for PUK" and found some issues described in the trello card https://trello.com/c/OpyHNSgA/1441-ubuntu-landing-027-ofono-awe-rsalveti
[14:42] <rvr> abeato: Right now, it asks me for new PIN, but when introduced, it says "Incorrect PUK"
[14:42] <rvr> abeato: But there are other issues as well
[14:43] <rvr> abeato: Did you test this?
[14:43] <abeato> rvr, I did
[14:44] <abeato> in krillin and arale
[14:44] <abeato> rvr, which phone are you using?
[14:44] <abeato> note that for mako there is no change
[14:44] <rvr> abeato: Arale, vivid-proposed 183
[14:46] <abeato> rvr, ok let me try again
[14:46] <abeato> rvr, "New pin cannot be introduced because the accept button is not enabled"?
[14:46] <abeato> that is very weird
[14:47] <rvr> abeato: The whole workflow is very weird :-/
[14:48] <sil2100> mardy: so, this is a critical thing for us, the unity8 hang on boot is a ship blocker and the fix silo is causing apparent regressions in u-o-a
[14:48] <rvr> Charging the iPhone to unblock and retry
[14:48] <sil2100> mardy: we would need some assistance to help us fix the Qt patches we imported so that u-o-a works properly - or maybe even fixing u-o-a if needed
[14:49] <mardy> sil2100: I'm checking the source code of uoa, to see if I'm doing something stupid
[14:50] <tsdgeos> mardy: "known" thing that doesn't work anymore is using qtdbus before there's a qapplication around
[14:50] <mardy> sil2100, Mirv, tsdgeos: so, uoa is registering the service name just before registering the object; indeed there's the risk of a race condition there
[14:51] <mardy> it would explain why the service was activated and yet why no object was found at the "/" path
[14:52] <Mirv> so, it might be a race condition _enabled_ by multi-threading of QDBus?
[14:52] <mardy> tsdgeos: I'm instantiating QCoreApplication as the very first step
[14:52] <mardy> Mirv: well, it could, though I'm not sure that this race condition is very likely
[14:52] <mardy> Mirv: how easy is it to reproduce this bug?
[14:53] <Mirv> mardy: the bug of having U1 account disappearing when using the 018 happens all the time
[14:53] <Mirv> mardy: if you have U1 account before upgrading to the silo, it appears. also if you readd the account, even though app installation then works for the rest of that boot, the account will disappear (seemingly) every time during the next reboot or the app installation after reboot
[14:56] <mardy> Mirv, sil2100: do you want to try this? https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/lp1421009/+merge/257267
[14:57] <mardy> Mirv: well, it might be that the system is especially busy when booting, so times get slower and race conditions become more likely to happen
[14:58] <Mirv> mardy: thanks, trying
[14:58] <mardy> Mirv: however, the RequestAccount method which I see failing in your comment to the bug, is an API which gets called when one wants to *create* a new account, not when authenticating. I wouldn't expect that to be called on boot
[14:59] <sil2100> mardy, Mirv: thanks guys!
[14:59] <Mirv> mardy: that gets called when I try to install an app, before which the account has probably already disappeared
[15:00] <Mirv> and since the account is not there, u-o-a decides to add one
[15:08] <pmcgowan> sil2100, jibel  once we clear the current qa backlog we should only let in fixes for blockers
[15:08] <pmcgowan> which we will need to land after today it seems likely
[15:09] <sil2100> Yeah, we'll close the gates shortly
[15:10] <pmcgowan> sil2100, I am ok clearing what is ready for qa
[15:12] <abeato> rvr, testing in arale channel tangxi-vivid-proposed, image 18 it seems fine: PIN retries number right when starting the phoe, PUK retries ok too
[15:13] <abeato> rvr, ofono (1.12.bzr6894+15.04.20150423-0ubuntu1)
[15:13] <rvr> abeato: I just unlocked the SIM, trying again too :-/
[15:13] <sil2100> om26er: how does silo 25 look so far? :)
[15:13] <rvr> sil2100: It was rebuilt
[15:13] <rvr> sil2100: And I haven't seen om26er online since then
[15:14] <sil2100> hmmm
[15:17] <pstolowski> sil2100, hey, landing-020 can be freed
[15:19] <sil2100> pstolowski: ACK :)
[15:19] <pstolowski> sil2100, i've updated landing-026 with the final MP to land in trunk, but reconfigure failed, can you re-check? also removed your comment for landing-026
[15:20] <rvr> abeato: How did you open the pin unlock screen, after reboot or via indicator-network?
[15:20] <sil2100> pstolowski: let me reconfigure that too
[15:20] <om26er> sil2100, landed.
[15:21] <sil2100> pstolowski: will it be ready for QA?
[15:21] <pstolowski> sil2100, btw, i got Problem accessing /job/-0-reconfigure/parambuild. Reason: not found (404)
[15:21] <abeato> rvr, I enabled it in system settings, then I rebooted and entered it from unity
[15:21] <sil2100> om26er: excellent! \o/
[15:21] <sil2100> Publishing
[15:21] <sil2100> pstolowski: hm, probably bug in the spreadsheet
[15:22] <om26er> so there seems to be something wrong with xchat and notifications in 15.04, they don't appear in the messaging menu
[15:22] <rvr> abeato: Can you try to lock your SIM card opening the SIM unlock page via indicator network?
[15:22] <pstolowski> sil2100, depends how fast it builds.. i tested the original branch and it worked, so if i have it built today, i should finish testing it in the evening
[15:23] <sil2100> pstolowski: yeah, hm, spreadsheet issues I see
[15:25] <abeato> rvr, I don't get that... the only way I see I could do that is trying to enable SIM lock, failing 3 times and then getting the SIM blocked, waiting for PUK
[15:25] <abeato> rvr, is that what you mean?
[15:28] <rvr> abeato: With your SIM unlocked. Reboot your phone, unlock the device, dismiss the SIM unlock screen. Go to indicator network, click on Unlock SIM button.
[15:28] <om26er> rvr, Saviq pinged me when the silo was rebuilt.
[15:28] <abeato> rvr, ok,
[15:28] <rvr> om26er: Cool
[15:29] <sil2100> Ok, officially scripts on the spreadsheet are broken
[15:29] <sil2100> Looking into why
[15:30] <abeato> rvr,  there is no unlock SIM button in the indicator network if the SIM is unlocked
[15:31] <rvr> abeato: Sorry, I ment, that the SIM is not in PUK mode.
[15:35] <abeato> rvr, ok, I see now what you mean, the behaviour is radically different if you try to unlock from indicator network instead of directly after booting
[15:35] <abeato> rvr, yes, number of PIN retries is wrong, etc.
[15:36] <abeato> rvr, but I do not know if this is a regression
[15:36] <abeato> rvr, my guess is that this was happening without the latest ofono changes
[15:37] <abeato> rvr, the ofono state seems to be fine but looks likes unity/indicator is not noticing
[15:37] <abeato> weird
[15:38] <rvr> abeato: Ok, so confirmed that it's not just me. Let me check without silo packages.
[15:39] <abeato> rvr, good catch... I thought we could not enter phone without entering the PIN nowadays
[15:39] <abeato> so I had never tried the "x" on start ;)
[15:40] <rvr> abeato: :)
[15:41] <abeato> rvr, if you enter PIN/PUK on boot all is fine
[15:41] <rvr> abeato: Right, so it seems the behavior of SIM unlock screen is different when launched from the indicator
[15:41] <abeato> yep
[15:44] <sil2100> robru, Mirv: so it seems the spreadsheet scripts are now borken and getRange().getValue() doesn't return anything useful
[15:46] <om26er> bfiller, Hi! I am testing silo21 so needed to look at design docs to really understand bug 1351177 -- oSoMoN left early for an appointment, I read. Can you provide the docs link ?
[15:46] <sil2100> robru, Mirv: ok, issue fixed
[15:47] <sil2100> robru, Mirv: this spreadsheet is so fragile that it's crazy - the reason why things stopped working is that someone by accident moved some other sheet in front of the Pending sheet
[15:47] <sil2100> And this is the result now &
[15:47] <sil2100> ^
[15:47] <sil2100> jibel, rvr, davmor2: expect duplicate trello cards
[15:48] <bfiller> om26er: https://docs.google.com/a/canonical.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit
[15:48] <sil2100> Saviq, damn, unity8 went to vivid, I think there was some glitch in the spreadsheet
[15:48] <sil2100> Saviq: let me copy it to overlay and free the silo
[15:49] <Saviq> sil2100, yeah, I saw the migration msg, was wondering if that's some weirdness of publishing to overlay...
[15:49] <Saviq> sil2100, would've pung you soon if it didn't recover ;)
[15:51] <sil2100> Saviq: copied and merging :) Sorry about that
[15:51] <Saviq> sil2100, nw
[15:51] <Saviq> sil2100, but yeah, must've been some glitch, overlay was selected as the target
[15:52] <sil2100> pstolowski: silo reconfigured ;) Will it be ready for QA?
[15:54] <sil2100> Mirv is probably away already, any brave souls around to test silo 18 again with the small fix from mardy ?
[15:56] <pstolowski> sil2100, when is the deadline? i can test tonight
[15:56] <sil2100> pstolowski: we want to close the gates soonish
[15:56] <Mirv> sil2100: mardy: tsdgeos: pstolowski: yes I should be away... and will be just after this. it's now possible it's shifted to not happening during boot - three times now, after adding an account and rebooting, the account is still there if checked via system settings. so it's possible this is fixing u-o-a boot time problem! but it now always (still) disappears when it's rebooted and "Install" is clicked in a store, so maybe a similar fix to mardy's 
[15:57] <Mirv> that definitely got cut somewhere, right?
[15:57] <sil2100> pstolowski: your change is maybe not a ship blocker, but it's a good fix which wouold be nice to have
[15:58] <tsdgeos> Mirv: i guess it's possible yes
[15:58] <sil2100> Mirv: where do you think we should do a similar fix as well?
[15:58] <rvr> abeato: Not completely sure that is not a regression, without the silo I can't type the PUK to follow.
[16:00] <Mirv> sil2100: whatever the app installation does via dbus, like querying the accounts or something
[16:00] <abeato> rvr, you can't enter PUK?
[16:00] <rvr> abeato: The accept button is not enabled :(
[16:00] <pstolowski> sil2100, i know, but realistically, the build will take ~1.5h, and hopefully it doesn't fail on a flaky test we discovered lately
[16:00] <abeato> rvr, even if you try from the screen on boot?
[16:01] <Mirv> now I even got add account + reboot + install app without problem, similar to sometimes the boot didn't remove the account before. so it seems there's a similar racy condition when pressing the install button for the first time after reboot.
[16:01] <sil2100> Mirv: we need to find someone from the click app installation to take a look at that then
[16:02] <sil2100> \o/
[16:02] <pstolowski> sil2100, so i can conclude my testing in about 2h
[16:03] <Mirv> sil2100: that mardy's example code sounds promising in the sense that it can be used as an example by someone who understands what/where happens when app is wanted to be installed
[16:07] <sil2100> Mirv: ok, I'll try to forward it to the right place
[16:08] <Mirv> sil2100: thanks! check up with alec_u who is checking with his team as seen on -touch
[16:08] <sil2100> pstolowski: ^ do you know anything about this?
[16:08] <sil2100> Ah, ok, I see on -touch
[16:08] <sil2100> :)
[16:24] <dbarth__> sil2100: we're still testing, and investing some occasional issues with tabs and webapps when the system is loaded
[16:25] <dbarth__> sil2100: how much are you blocked on oxide?
[16:26] <pat__> dbarth__, we have 3 or 4 things that need to land to be done, oxide is one
[16:26] <sil2100> dbarth__: it's a ship blocker, since without it the T&C won't show up
[16:26] <sil2100> So it's one of the criticals as pmcgowan says
[16:26] <sil2100> pmcgowan: might as well close the landing gates to anything that's not a blocker for us I suppose
[16:26] <pmcgowan> sil2100, lets land what has been preped for QA
[16:27] <pmcgowan> ready for testing and in testing
[16:27] <sil2100> pmcgowan: right, that's the plan, after the gates are closed those silos that are ready are still signed-off and landed
[16:27] <pmcgowan> then yes
[16:27] <dbarth__> well, then 1.7.3 is an improvement overall
[16:27] <sil2100> But after closing we don't accept new landings (besides blockers in this case)
[16:28] <dbarth__> still not sure what those white screens are made of; chris is on it
[16:28] <sil2100> dbarth__: I suppose the webbrowsing quality on arale is still better, I think we had the white screens on the old oxide as well
[16:28] <dbarth__> but then it means another 6-8h of build time before we can re-test a fix
[16:29] <pmcgowan> then we should make sure its the last fix we need
[16:31] <dbarth__> pmcgowan: that "fix" is more an hypothesis right now; in the absence of a solution in the next hours, the tradeoff is improved, more polished exp (flickering, gl, CTR)
[16:31] <dbarth__> pmcgowan: but at the cost of increased browsing instability when the system is loaded with many webviews
[16:32] <pmcgowan> dbarth__, surely chris can do inceremental builds quicker than that to test?
[16:32] <dbarth__> pmcgowan: at least, yes
[16:33] <pmcgowan> we have no choice now but to land 1.7 dbarth__
[16:33] <sil2100> Maybe since davmor2 is already testing 1.7.3, we could land it anyway and anticipate a probable 1.7.4 with the fixes
[16:34] <sil2100> But in case it's not feasible in our timeframes simply stay around with 1.7.3 (and the instabilities)
[16:34] <dbarth__> pmcgowan: i'd rather land 1.7, i think that's a better version overall
[16:34] <pmcgowan> its no longer a choice afaik
[16:34] <pmcgowan> there is no rather
[16:34] <davmor2> sil2100: there are definitely issue with tabs in 1.7.3
[16:34] <dbarth__> ok, deal
[16:34] <pmcgowan> we could land it with that known and do as sil2100 says
[16:35] <pmcgowan> if it allows some regression testing to start
[16:38] <sil2100> The unity8 on-boot hang worries me a bit
[16:39] <sil2100> Worst thing is we'll probably have to wait till tomorrow to know more on that one
[16:40] <rvr> abeato: Ok. This is what I found.
[16:40] <sil2100> Anyway, let me close the gates
[16:40] <rvr> abeato: In vivid proposed 183, without silos, in the "boot" SIM lock screen, things work just fine.
[16:41] <sil2100> rvr, jibel, davmor2, om26er, ToyKeeper, alesage: landing gates will now be closed, sign-off only those silos that are are ready now and those that are blockers for release - consult me or Pat in this case
[16:41] <rvr> abeato: I'm able to lock the SIM after three unsuccessful trials, count is updated, and PUK can be introduced and SIM can be unlocked.
[16:42] <rvr> sil2100: Ack
[16:42] <rvr> sil2100: Silo 10 is in, I understand.
[16:44] <ogra_> sil2100, FYI ... initramfs-tools-ubuntu-touch uploaded ... will be interesting if it actually builds at all in the PPA (it uses a werid multi wrapped build process)
[16:45] <alesage> Mirv, on silo 18, app store => install PodBird (my fav!) => UO sign-up => two factor, then spinning orange wheel
[16:45] <sil2100> rvr: yeah, those that are ready now can be still signed-off and landed, but we prioritize those silos that have blockers
[16:45] <sil2100> alesage: yeah... even with the additional change it still seems to have some racy parts in the application installation
[16:46] <alesage> sil2100, ack, was going to ask for other D-Bus test cases around this change
[16:47] <sil2100> alesage: actually, as part what was mentioned in -touch, could you try using some other online accounts in click apps?
[16:47] <sil2100> We were actually wondering if U1 is the only one having issues
[16:47] <alesage> sil2100, ok shall do
[16:48] <sil2100> alesage: thanks! :0
[16:48] <sil2100> We need as much info as we can
[16:50] <abeato> rvr, and what happens when doing things from indicator network, without silos?
[16:53] <robru> sil2100: yeah I've seen getRange() fail before, apparently the ranges need to be extended when new rows are added. There is a script that does that, but it seems to intermittently fail. Usually it fixes itself if you just add more rows later.
[16:53] <Mirv> alesage: sil2100 just a quick note that I've seen spinning orange wheel after two factor as often also without the ppa, so that part is probably not regression, the account disappearings are
[16:53] <sil2100> Mirv: ACK
[16:53] <alesage> Mirv, intriguing
[16:53] <rvr> abeato: No count is shown. After PIN is locked, it doesn't switch to PUK.
[16:54] <abeato> rvr, then we can conclude that it is not a regression from silo 27 and that bug was already around, isn't it?
[16:54] <rvr> abeato: Closing and opening it ("Unblock SIM" from indicator network) does show the PUK screen.
[16:55] <rvr> abeato: Introducing the PUK unlocked it.
[16:55] <rvr> abeato: But screen remains there.
[16:55] <rvr> abeato: Closing and opening the screen, shows "introduce the new PIN".
[16:56] <abeato> rvr, yep, pretty similar to what happened with the silo
[16:56] <rvr> abeato: So all problems are in this screen.
[16:58] <rvr> abeato: But the silo doesn't address this. The PIN can be unlocked when booting.
[16:58] <rvr> PIN Lock + PUK unlock works fine from boot.
[16:58] <abeato> rvr, the silo addresses the case when the SIM is PUK-blocked
[16:58] <abeato> that is, you cannot recover the SIM
[16:59] <abeato> without the silo it incorrectly asked for PUK
[16:59] <abeato> with the silo it tells you that your SIM is completely blocked
[16:59] <rvr> abeato: Yes, you can
[16:59] <abeato> rvr, I am talking about the case when you introduce a wrong PIN 3 times and a wrong PUK 10 times
[17:00] <abeato> so you cannot use the SIM
[17:00] <rvr> abeato: Ahhhhh... and the wrong PUK 10 times, I see
[17:00] <abeato> that's what the bug talks about
[17:01] <abeato> the change also makes sure you know the number of retries available all times
[17:01] <rvr> Right, right
[17:01] <abeato> it is just that the terminology for this is soooo confusing...
[17:01] <rvr> err
[17:02]  * rvr doesn't want to block his SIM card
[17:02] <abeato> hehe
[17:02] <abeato> you can ask mzanetti to test the silo ^^
[17:02] <abeato> he had the blocked SIM
[17:03] <rvr> Is any other way to test it? :-/
[17:03] <abeato> not really ;-(
[17:04] <sil2100> jibel: hey! So, the landing gates closed, but we can't really create an RC image without the Qt fix for unity8 hangs
[17:05] <sil2100> jibel: this might shift the build of the RC...
[17:13] <rvr> abeato: If I block my SIM card I need to go to the store, to get a duplicate ... I'll check this at the end.
[17:14] <abeato> rvr, I completely understand
[17:14] <davmor2> rvr: what this?
[17:15] <rvr> davmor2: A test that involves a SIM card being blocked after 10 unsuccessful PUK trials.
[17:15] <alesage> Mirv, sil2100  reverting to trunk i'm not seeing the spinning orange wheel for several trials when signing up for UO--is simply removing the account an authentic test of signing up again?
[17:15] <abeato> rvr, however mzanetti already did some testing (see comments in bug #1436820)
[17:15] <cwayne> sil2100, davmor2 what happened to krillin vivid custom tar, is that blocked at the gate now?
[17:15] <alesage> sil2100, I'll chase the other online clicks now with the silo
[17:15] <davmor2> rvr: yeah I'm not about to test that either :D
[17:15] <rvr> davmor2: haha
[17:15] <abeato> don't know if that can be considered enough or not
[17:16] <rvr> abeato: We prefer to check ourselves
[17:16] <sil2100> cwayne: I guess it's not blocked, but I think QA might be busy with arale as that has higher priority ;)
[17:16] <rvr> When possible, of course
[17:17] <sil2100> cwayne: I know it's on their list but there's a lot of blocker/criticals for arale that still need tending
[17:17] <rvr> cwayne: QA overflow!
[17:17] <cwayne> figured as such, just wanted to make sure I hadn't missed a +1 again :)
[17:17] <abeato> rvr, yep understandable
[17:18] <davmor2> cwayne: no I will ping you in every known format so you don't miss it again
[17:18] <cwayne> davmor2, i await your smoke signals
[17:19] <Mirv> alesage: I didn't see the spinning wheel today with the ppa at all, and once without the ppa. not sure when it happens.
[17:19] <davmor2> cwayne: if you find bird poo on your car don't shoot it it's the carrier pigeon and it's flown a long way
[17:21] <cwayne> davmor2, can you instruct it to poop on my neighbors car instead
[17:21] <davmor2> cwayne: hahaha
[17:28] <ogra_> cjwatson, bah ... does a package build in the overlay PPA  actually prepend the overlay PPA to sources.list ? (initramfs-tools-ubuntu-touch just exploded in my face trying to use the PPA line as mirror for debootstrap)
[17:29] <boiko> sil2100: hi, where can I check what changed from one vivid-proposed image to another?
[17:30] <ogra_> imgbot, status 183
[17:30] <imgbot> Error: There does not seem to be any build with the number 183
[17:30] <ogra_> imgbot, status 182
[17:30] <imgbot> Error: There does not seem to be any build with the number 182
[17:30] <ogra_> imgbot, status 183 vivid
[17:30] <imgbot> Status: succeeded, Started: 2015-04-23 02:02:06 UTC, Finished: 2015-04-23 02:57:41 UTC
[17:30] <imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/25796
[17:30] <imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/183.changes
[17:31] <ogra_> boiko, ^^
[17:31] <boiko> ogra_: thanks!
[17:33] <pstolowski> sil2100, my silo just built... i guess it's too late (i need ~20 minutes for testing)
[17:34] <sil2100> pstolowski: I would still think about it
[17:34] <boiko> ogra_: and for krillin is that the same?
[17:34] <pstolowski> sil2100, ok.. testing
[17:34] <ogra_> boiko, yes, different versioning though ...
[17:34] <ogra_> imgbot, map 183 vivid
[17:34] <imgbot> mako ubuntu version: 183 maps to krillin version: 196"
[17:34] <imgbot> mako ubuntu version: 183 maps to generic_x86 version: 185"
[17:34] <sil2100> pmcgowan: ^ pstolowski has the fix for the scopes disappearing during upgrade - it's not critical to have for RC I suppose since they're all in custom tarball, but maybe it could be a good idea? What do you think?
[17:35] <sil2100> pmcgowan: considering that we'll anyway blocked on building the RC image with the unity8 hang bug...
[17:35] <ogra_> boiko, vivid is all mapped against mako so you need the map command to actually find the krillin version
[17:35] <boiko> ogra_: great! thanks!
[17:35] <pmcgowan> sil2100, sure good to land
[17:36] <ogra_> i guess i need to change that at some point
[17:39] <sil2100> pstolowski, davmor2, rvr, ToyKeeper: ^ please make sure that silo 26 is also signed-off once set as ready
[17:41] <boiko> imgbot, map 181 vivid
[17:41] <imgbot> mako ubuntu version: 181 maps to krillin version: 195"
[17:41] <imgbot> mako ubuntu version: 181 maps to generic_x86 version: 184"
[17:42] <boiko> imgbot, map 182 vivid
[17:42] <imgbot> mako ubuntu version: 182 maps to krillin version: 195"
[17:42] <imgbot> mako ubuntu version: 182 maps to generic_x86 version: 184"
[17:47] <pmcgowan> sil2100, rvr we have been waiting for silo 24 so if thats now ready for QA would like to get those
[17:50] <rvr> pmcgowan: Ack
[17:51] <pmcgowan> thanks
[17:56] <sil2100> pmcgowan: indeed, that's a blocker fix so it's good to have that
[17:57] <sil2100> pmcgowan: too bad jibel is not around, I wanted to consult with him what to do in this situation with the RC, but I guess we'll decide that tomorrow morning
[17:58] <alecu> sil2100: with latest silo-18 in mako #183, logging into U1 after clicking "Install", or logging into U1 from system settings->accounts are working much better. Still, the account was still deleted after reboot.
[17:59] <sil2100> alecu: deleted after reboot? Damn, I actually thought it would be the other way around with this silo installed
[17:59] <pmcgowan> sil2100, we can make an image tonight but I suspect we need another prior to regression tests starting
[17:59] <pstolowski> sil2100, marked silo 26 tested
[18:00] <sil2100> pstolowski: excellent
[18:01] <sil2100> pmcgowan: ok, so I'll be logging off in some minutes, but I'll log in in a few hours to maybe kick an image - want as many silos to land as possible
[18:02] <alecu> sil2100: and just while I'm saying this, I'm attempting to log in again, only to get the spinner showing forever after clicking in "Sign In"
[18:02] <alecu> sil2100: so, please disregard my previous comment
[18:02] <alecu> top shows that unity8 and online-accounts are pegging the cpu, will take a screenshot of that.
[18:05] <pstolowski> sil2100, signing off for today. cu!
[18:05] <alecu> so, the "spinner forever" seems to be some weird interaction between unity8, online-accounts, and system-settings: http://pasteboard.co/2MKyOsZ9.png
[18:07] <alecu> actually, it's online-accounts-ui
[18:09] <alecu> http://pasteboard.co/2MKR1ed7.png
[18:10] <alecu> ten minutes, and still spinning.
[18:10] <cjwatson> ogra_: The context archive itself always comes first, yes.  You should probably do something like checking the Origin of release files, or you could just exclude ppa.launchpad.net perhaps
[18:12] <cjwatson> ogra_: I see you attempted to do the latter, but it would work better if you wrote "ppa.launchpad.net" rather than "ppa.launchpa.net". :-)
[18:13] <alesage> Mirv, still seeing this spinning circle reliably, happens in settings proper (store process not implicated), http://pastebin.ubuntu.com/10873064 , http://pastebin.ubuntu.com/10873079 <= unity8 log
[18:13] <alesage> sil2100, ^^
[18:14] <ogra_> cjwatson, gah, damned ...
[18:14] <ogra_> cjwatson, thanks though !
[18:14] <alecu> alesage: I'm seeing the spinner too, both from the store and from system settings.
[18:14] <alesage> alecu whew I'm not crazy :)
[18:15] <alecu> alesage: are you on arale? the cpu usage is very different from the screenshot I pasted above from a mako.
[18:15] <alesage> alecu arale, yes
[18:15] <alecu> great.
[18:21] <alesage> alecu, sil2100 FWIW other normal accounts (Twitter, Google, FB) don't appear affected
[18:24] <alecu> and using dbus-monitor there doesn't seem to be any unusual dbus traffic while the spinner is shown and the processes are chewing the cpu....
[18:39] <sil2100> alecu, alesage: thanks for looking into that guys, I'm actually wondering what's causing all those issues
[18:40] <sil2100> alecu: be sure to document your findings in the unity8 hang bug ;)
[18:40] <alesage> sil2100, not seeing without silo at least to this point
[18:40] <sil2100> I need to AFK now for a while, but will be back in 3-4 hours
[19:32] <rvr> abeato is no more
[19:32] <rvr> rsalveti: davmor2 found a problem with the "after-PUK"
[19:32] <rvr> on silo 27
[19:34] <davmor2> rvr: I think rsalveti is off too ircc
[19:34] <davmor2> iirc even
[19:34] <ogra_> yeah, traveling
[19:34] <rvr> Ok
[19:35] <rvr> davmor2: I'll send them an email
[19:35] <ogra_> he wont be around before monday officially ... (probably drops by on the weekend though)
[19:35] <ToyKeeper> mandel: I see a note on silo 24 saying to contact you about testing the change.  What's needed to test it?
[19:36] <davmor2> rvr: http://people.canonical.com/~davmor2/screenshot20150423_192816321.png
[19:37] <davmor2> rvr: does that on hitting the X or if you just don't press anything
[19:37] <rvr> davmor2: :-O
[19:37] <davmor2> rvr on the initial purple screen that looks correct
[19:39] <davmor2> rvr: you can't drag anything in, you can't swipe it either because that isn't unlocked yet :(  had to remove the sim to get into the phone to get the screenshot
[19:39] <davmor2> I'll try and get a purple one too
[19:39] <rvr> Sounds really bad
[19:41] <rvr> Ok, copied your comments to the card and sent an email to abeato with cc to rsalveti
[20:45] <mandel> ToyKeeper, hello! sorry I was out for dinner