[02:10] === IMAGE 183 building (started: 20150423-02:10) === [03:25] === IMAGE 183 DONE (finished: 20150423-03:25) === [03:25] === changelog: http://people.canonical.com/~ogra/touch-image-stats/183.changes === [04:33] ogra_: small one https://code.launchpad.net/~rsalveti/ubuntu-touch-session/fixing_expect_upstart_obexd/+merge/257202 === chihchun_afk is now known as chihchun [07:03] rsalveti, approved [08:16] Mirv: we have one free silo - do you want to take it? ;) [08:20] 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 === marcusto_ is now known as marcustomlinson [09:00] dbarth_, oSoMoN: ping [09:00] sil2100, pong [09:00] what’s up? [09:00] 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] Also, how's progress with 1.7.2 testing? [09:01] sil2100, I didn’t see any issues with webapps with 1.6.4, what kind of issues? [09:01] 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] I mean 1.7.3 [09:02] oSoMoN: ToyKeeper commented on trello: "Fail: This silo fixes the HERE T&C but makes web apps crash on start." [09:02] You can check the details there [09:03] davmor2 will try to reproduce [09:04] I did my testing on krillin [09:05] pong [09:05] 1.7.3 working great here [09:05] checking the trello board now [09:07] oSoMoN: i wonder if the crashers are arale and same as what we saw yesterday [09:07] ie, the sandbox model change triggered by the newer kernels [09:07] ToyKeeper: around? can you confirm the tests were on arale? [09:08] dbarth_: Yes, it was on arale. [09:08] dbarth_, it shouldn’t be related, afaiu that’s a change in chromium itself [09:08] right [09:08] webbrowser-app works, because of the security policy, but all webapps would crash because of that newer kernel [09:08] well, i guess 1.7.3 comes handy then [09:08] dbarth_, still, we should try and publish 1.6 first [09:09] but just not on arale [09:09] sil2100: how's that doable ? ie, release 1.6.4 to all but vivid/arale [09:09] and line up 1.7.3 in a silo for the image [09:09] sorry it is that complicated [09:12] 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] so 1.6.4 for vivid is toasted; there's just the security updates for other releases which will be releasable [09:14] and 1.7.3 is the only one we can try on vivid proper [09:14] dbarth_: we can't release something that's broken for arale... [09:14] 1.7.2 was already working fine on mako, 1.7.3 fixes issues on arale [09:14] Since our goal is arale [09:14] sil2100: precisely [09:14] so unfortunately the 1.6.4 step was a waste of efforts [09:15] No worries, let's just try making sure 1.7.3 is good for everything [09:15] i'll double check on krillin and mako right now [09:15] Thanks :) [09:34] sil2100, so we stop on 1.6.4 and wait for a new silo with 1.7.3? [09:42] jibel: yeah... there's no use in 1.6.4 it seems ;/ [09:42] k [09:42] It was broken on arale from the start it seems [09:42] dbarth_, ETA for a new version? [09:48] At least it seems to be already built... [09:53] dbarth_, no 1.6.4 was not a waste of efforts, it still needs to go to vivid-security [10:05] jibel, oSoMoN: 1.7.3 is built indeed [10:07] 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] i'm on reviving my mako which fainted out of battery last night [10:19] jibel, sil2100, oSoMoN: initial testing on mako/vivid is positive: problems fixed and we even get background audio playback for free ! :) \o/ [10:20] Ou yeah [10:20] \o/ [10:20] 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] maybe we can unfold the rest of the test suite with oSoMoN and hand that over back to QA early this afternoon [10:20] 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] ubuntu-qa: any chance silo 21 will be validated before the landing gates for vivid close tonight? [10:21] Would be great, we can't have the RC without a new oxide [10:21] sil2100: ah silo yes: can you transfer the build to whichever is free [10:22] dbarth_: btw. there's silo 11 that has oxide 1.5.6 in it, let me free that up then [10:22] oSoMoN: It's in the queue, so there are chances. [10:22] oSoMoN: so that 1.6.4 silo is not needed anymore, since the other releases will be via the normal security pocket [10:22] oSoMoN, priority is 16, 18, 25 and 27. It can be verified once these are done [10:23] sil2100: right, this one is outdated anyway [10:23] jibel: do we have anyone on 18 from our current timezone? [10:23] rvr, which silo are you on? [10:24] jibel: and so 16 becomes 11, as i guess oxide is the priority item [10:24] jibel: I've been trying to validate 7, but I'm blocked and will take 27 after repartitioning [10:24] dbarth_, ack [10:24] dbarth_, sure the silo is not needed any longer, but the testing was not a waste of time [10:25] oSoMoN: no, you're right [10:25] jibel, rvr: thanks, you guys are doing a great job of validating our work, keep it up :) [10:25] 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] rvr, can you continue alesage verification of 18? [10:26] jibel: Sure [10:26] rvr, thanks [10:27] dbarth_, oSoMoN, jibel: I'll copy oxide-qt 1.7.3 to silo 16, but it'll be with the ~ppa1 suffix [10:27] I think it should be fine to publish it with such a version [10:28] 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] 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] chrisccoulson, can you confirm? ^ [10:30] 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] ok, thanks [10:31] ACK [10:31] So I guess it's fine to copy [10:31] seems so [10:35] 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] cjwatson: thanks! [10:51] sil2100: how about I implement my suggestion from the other day to set all silos to 20480MB across the board? [10:51] (then I'm going back to being on holiday) [10:53] sil2100: that's done now (the across-the-board thing) [10:57] cjwatson: thanks :) [10:57] Works fine for us at least [11:07] * sil2100 off to a family lunch === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [12:31] dbarth__, oSoMoN is oxide 1.7 ready for testing? or it'll never land on time. === _salem is now known as salem_ [12:37] jibel, it is, I’ll be testing in parallel with you guys [12:52] Mirv: ping [12:53] rvr: pong [12:53] Mirv: I have installed silo 18 [12:54] 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] 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] Mirv: Yes, I confirm. [12:54] 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] 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] tsdgeos: ^ 018 does not seem good for our use, even forget about KDE legacy apps for a while [12:56] tsdgeos: did you discuss with thiago about the current state and Merge ETA? [12:56] Mirv: i haven't been able to get him on IRC the last two days [12:56] so n [12:56] o [12:56] I noticed some of the MR:s actually had been merged, but not the bunch of it [12:57] I wonder if the route of "use DBus less like we did until February" is a possible workaround [12:57] for the boot issue === marcust__ is now known as marcustomlinson_ [13:00] Mirv: it could i guess yes [13:00] 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] like delaying the libusermetrics until a bit later, or getting a signal from unity8 to proceed or something like that === marcustomlinson_ is now known as marcustomlinson [13:03] 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] 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] Mirv: okay, well I suspect that if it's happening now, it could easily have happened before that change [13:06] the change you linked just adds a new source for translations [13:06] it doesn't really change the way we use DBus [13:06] 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] 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] 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] but i'm not the manager :D [13:10] sil2100: ^ we need a manager! :) [13:10] sil will read the backlog once back from his family lunch [13:17] 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] in the most recent changelog [13:26] Saviq: probably not and robru will want to add a \n in there [13:27] 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] Saviq: well I'd have thought deps would be the first to be added, but maybe that's experimentation now [13:49] Mirv: wazzup? [13:49] Reading backlog [13:50] Mirv, tsdgeos: ok guys, do we have any other short-term options to get this bug resolved? [13:52] sil2100: define short-term :D [13:53] Like, anything we can do till EOD [13:53] ;p [13:54] Or, at max till Monday [13:54] 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] sil2100: i guess it depends on how unlucky you are [13:57] i'd go with "not very often" [13:57] but since it's race dependant, it happens more on first boots after flashing when the qml cache is being built [13:57] so it's kind of bad for first experience if your first boot ever gets you a deadlocked phone [13:58] 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] not that i know of [14:00] Damn... [14:00] pmcgowan: we might have a slight problem ^ [14:01] I have been listening [14:02] tsdgeos, Mirv so what is it that is racing [14:03] pmcgowan: qtdbus code [14:04] tsdgeos, was looking for a bit more, like its libusermetrics doing somethign while ... [14:06] 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] but wouldn't say this is the only such case [14:07] basically the qtdbus code is not good when used from multiple threads [14:07] thats awful [14:07] yeah [14:07] unity8 can't hang on boot [14:07] sil2100: even if it hangs like 1/10 [14:07] on factory that is a lot [14:07] yeah factory is more the issue that customer since thats the first boot [14:08] rsalveti, thats just because we dont produce enough phones :P [14:08] Right [14:08] That's why I always advertised this issue as a 'ship blocker' [14:08] And now it finally seems that we're stuck with a ship blocker without a good way to workaround/fix it [14:09] It was important enough for us to actually agree on getting so many devel patches to Qt ;p [14:09] Still, it seems we have bugs [14:09] tsdgeos, Mirv, pmcgowan: maybe we could have some additional people looking into solving this issue? [14:10] 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] s/while/will [14:11] tsdgeos, so you suggest we fix the patches [14:11] I would say that sounds like a good idea, but do we have enough experienced manpower to do it till the EOW? [14:12] There's also the risk that those patches introduced additional regressions [14:12] So we need to proceed carefully [14:12] heh [14:12] EOW sounds so far away [14:12] you could have said "tomorrow" :) [14:12] ogra_: ;) [14:12] sil2100: EOW? i doubt we can do anything before tomorrow, no [14:12] ogra_: tomorrow is like 8 letters, while EOW is 3 - I obviously took the shortest one ;) [14:13] wo, are you sure you are not german ? [14:13] *wow even [14:13] 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] But... [14:14] 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] yeah, wouldnt buy us much [14:14] So *at best* we'll need one more day to finish testing [14:14] sil2100: yes, you basically need to test "everything" since nowadays dbus is everywhere in our stack [14:15] 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] pmcgowan: it solves the problem, but there are issues with things like unable to install apps and accounts disappearing [14:16] So pretty serious regressions [14:16] sil2100, tsdgeos and why on first boot [14:16] pmcgowan: first boot is more common because there's no qml cache built yet, so things run "at a different speeed" [14:17] tsdgeos, can we preseed the cache [14:18] 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] 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] 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] 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] 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] it's not really "libusermetrics" problem, but "what happens during boot triggering Qt problem" [14:23] Mirv, while true; do adb shell rm -R "~phablet/.cache/QML"; ./tools/unlock-device || break; done [14:23] Mirv, where ./tools/unlock-device is from lp:unity8 [14:23] Saviq: don't you need to restart unity8 at some point? [14:23] ah ./tools/unlock-device does it [14:24] Saviq: thanks. it looks like unlock-device is the thing that reboots? [14:24] ignore maself [14:24] tsdgeos, Mirv, yeah unlock-device does it all [14:24] Mirv, tsdgeos: how many people do we have that could work on fixing the Qt patches to not cause these regressions? [14:25] 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] sil2100, we don't have anyone dedicated to upstream Qt work [14:26] 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] Saviq: i guess between 0 and ~300 depending on how selective you want to be :D [14:27] sil2100: i mean ↑↑↑ [14:27] * tsdgeos hides from the bad joke [14:27] ;) [14:28] 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] But that's something for the future [14:29] 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] no idea if there's someone with qtdbus experience [14:32] going through our upstream committers, tsdgeos and mardy are ones who have 1-2 QDBus commits === chihchun is now known as chihchun_afk [14:33] Do we have any leads what might be causing the regression in accounts and app installation? [14:33] Actually, I'll read the latest comment in the bug [14:35] 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] rsalveti: ping [14:36] 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] rvr: pong [14:36] 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] 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] rsalveti: https://trello.com/c/OpyHNSgA/1441-ubuntu-landing-027-ofono-awe-rsalveti [14:37] rvr: are these new issues? [14:38] mardy: ping [14:38] 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] 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] rsalveti: I was verifying "Blocked SIM card keeps on asking for PUK" [14:38] Mirv: still 22 mins to go :-) [14:38] 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] rsalveti: And i haven't been able to fully unblock my SIM card so... [14:39] mardy: related to bug #1421009 [14:39] bug 1421009 in qtbase-opensource-src (Ubuntu) "unity8 sometimes hangs on boot" [Critical,In progress] https://launchpad.net/bugs/1421009 [14:39] 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] rvr: hm, need help from alfonso here [14:40] abeato: ^^ [14:41] rvr, what do you mean? have you blocked your SIM? [14:41] abeato: To test PUK, yes [14:42] rvr, ok, and which is the issue? [14:42] 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] abeato: Right now, it asks me for new PIN, but when introduced, it says "Incorrect PUK" [14:42] abeato: But there are other issues as well [14:43] abeato: Did you test this? [14:43] rvr, I did [14:44] in krillin and arale [14:44] rvr, which phone are you using? [14:44] note that for mako there is no change [14:44] abeato: Arale, vivid-proposed 183 [14:46] rvr, ok let me try again [14:46] rvr, "New pin cannot be introduced because the accept button is not enabled"? [14:46] that is very weird [14:47] abeato: The whole workflow is very weird :-/ [14:48] 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] Charging the iPhone to unblock and retry [14:48] 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] sil2100: I'm checking the source code of uoa, to see if I'm doing something stupid [14:50] mardy: "known" thing that doesn't work anymore is using qtdbus before there's a qapplication around [14:50] 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] it would explain why the service was activated and yet why no object was found at the "/" path [14:52] so, it might be a race condition _enabled_ by multi-threading of QDBus? [14:52] tsdgeos: I'm instantiating QCoreApplication as the very first step [14:52] Mirv: well, it could, though I'm not sure that this race condition is very likely [14:52] Mirv: how easy is it to reproduce this bug? [14:53] mardy: the bug of having U1 account disappearing when using the 018 happens all the time [14:53] 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] Mirv, sil2100: do you want to try this? https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/lp1421009/+merge/257267 [14:57] 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] mardy: thanks, trying [14:58] 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] mardy, Mirv: thanks guys! [14:59] mardy: that gets called when I try to install an app, before which the account has probably already disappeared [15:00] and since the account is not there, u-o-a decides to add one [15:08] sil2100, jibel once we clear the current qa backlog we should only let in fixes for blockers [15:08] which we will need to land after today it seems likely [15:09] Yeah, we'll close the gates shortly [15:10] sil2100, I am ok clearing what is ready for qa [15:12] 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] rvr, ofono (1.12.bzr6894+15.04.20150423-0ubuntu1) [15:13] abeato: I just unlocked the SIM, trying again too :-/ [15:13] om26er: how does silo 25 look so far? :) [15:13] sil2100: It was rebuilt [15:13] sil2100: And I haven't seen om26er online since then [15:14] hmmm [15:17] sil2100, hey, landing-020 can be freed [15:19] pstolowski: ACK :) [15:19] 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] abeato: How did you open the pin unlock screen, after reboot or via indicator-network? [15:20] pstolowski: let me reconfigure that too [15:20] sil2100, landed. [15:21] pstolowski: will it be ready for QA? [15:21] sil2100, btw, i got Problem accessing /job/-0-reconfigure/parambuild. Reason: not found (404) === ricmm_ is now known as ricmm [15:21] rvr, I enabled it in system settings, then I rebooted and entered it from unity [15:21] om26er: excellent! \o/ [15:21] Publishing [15:21] pstolowski: hm, probably bug in the spreadsheet [15:22] so there seems to be something wrong with xchat and notifications in 15.04, they don't appear in the messaging menu [15:22] abeato: Can you try to lock your SIM card opening the SIM unlock page via indicator network? [15:22] 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] pstolowski: yeah, hm, spreadsheet issues I see [15:25] 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] rvr, is that what you mean? [15:28] 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] rvr, Saviq pinged me when the silo was rebuilt. [15:28] rvr, ok, [15:28] om26er: Cool [15:29] Ok, officially scripts on the spreadsheet are broken [15:29] Looking into why [15:30] rvr, there is no unlock SIM button in the indicator network if the SIM is unlocked [15:31] abeato: Sorry, I ment, that the SIM is not in PUK mode. [15:35] 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] rvr, yes, number of PIN retries is wrong, etc. [15:36] rvr, but I do not know if this is a regression [15:36] rvr, my guess is that this was happening without the latest ofono changes [15:37] rvr, the ofono state seems to be fine but looks likes unity/indicator is not noticing [15:37] weird [15:38] abeato: Ok, so confirmed that it's not just me. Let me check without silo packages. [15:39] rvr, good catch... I thought we could not enter phone without entering the PIN nowadays [15:39] so I had never tried the "x" on start ;) [15:40] abeato: :) [15:41] rvr, if you enter PIN/PUK on boot all is fine [15:41] abeato: Right, so it seems the behavior of SIM unlock screen is different when launched from the indicator [15:41] yep [15:44] robru, Mirv: so it seems the spreadsheet scripts are now borken and getRange().getValue() doesn't return anything useful [15:46] 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] robru, Mirv: ok, issue fixed [15:46] bug 1351177 in webbrowser-app "Suggestions improvements" [Medium,In progress] https://launchpad.net/bugs/1351177 [15:47] 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] And this is the result now & [15:47] ^ [15:47] jibel, rvr, davmor2: expect duplicate trello cards [15:48] om26er: https://docs.google.com/a/canonical.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit [15:48] Saviq, damn, unity8 went to vivid, I think there was some glitch in the spreadsheet [15:48] Saviq: let me copy it to overlay and free the silo [15:49] sil2100, yeah, I saw the migration msg, was wondering if that's some weirdness of publishing to overlay... [15:49] sil2100, would've pung you soon if it didn't recover ;) [15:51] Saviq: copied and merging :) Sorry about that [15:51] sil2100, nw [15:51] sil2100, but yeah, must've been some glitch, overlay was selected as the target [15:52] pstolowski: silo reconfigured ;) Will it be ready for QA? [15:54] Mirv is probably away already, any brave souls around to test silo 18 again with the small fix from mardy ? [15:56] sil2100, when is the deadline? i can test tonight [15:56] pstolowski: we want to close the gates soonish [15:56] 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] that definitely got cut somewhere, right? [15:57] pstolowski: your change is maybe not a ship blocker, but it's a good fix which wouold be nice to have [15:58] Mirv: i guess it's possible yes [15:58] Mirv: where do you think we should do a similar fix as well? [15:58] abeato: Not completely sure that is not a regression, without the silo I can't type the PUK to follow. [16:00] sil2100: whatever the app installation does via dbus, like querying the accounts or something [16:00] rvr, you can't enter PUK? [16:00] abeato: The accept button is not enabled :( [16:00] 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] rvr, even if you try from the screen on boot? [16:01] 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] Mirv: we need to find someone from the click app installation to take a look at that then [16:02] \o/ [16:02] sil2100, so i can conclude my testing in about 2h [16:03] 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] Mirv: ok, I'll try to forward it to the right place [16:08] sil2100: thanks! check up with alec_u who is checking with his team as seen on -touch [16:08] pstolowski: ^ do you know anything about this? [16:08] Ah, ok, I see on -touch [16:08] :) [16:24] sil2100: we're still testing, and investing some occasional issues with tabs and webapps when the system is loaded [16:25] sil2100: how much are you blocked on oxide? [16:26] dbarth__, we have 3 or 4 things that need to land to be done, oxide is one [16:26] dbarth__: it's a ship blocker, since without it the T&C won't show up === pat__ is now known as pmcgowan [16:26] So it's one of the criticals as pmcgowan says [16:26] pmcgowan: might as well close the landing gates to anything that's not a blocker for us I suppose [16:26] sil2100, lets land what has been preped for QA [16:27] ready for testing and in testing [16:27] pmcgowan: right, that's the plan, after the gates are closed those silos that are ready are still signed-off and landed [16:27] then yes [16:27] well, then 1.7.3 is an improvement overall [16:27] But after closing we don't accept new landings (besides blockers in this case) [16:28] still not sure what those white screens are made of; chris is on it [16:28] 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] but then it means another 6-8h of build time before we can re-test a fix [16:29] then we should make sure its the last fix we need === alecu is now known as alecu-lunch [16:31] 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] pmcgowan: but at the cost of increased browsing instability when the system is loaded with many webviews [16:32] dbarth__, surely chris can do inceremental builds quicker than that to test? [16:32] pmcgowan: at least, yes [16:33] we have no choice now but to land 1.7 dbarth__ [16:33] 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] But in case it's not feasible in our timeframes simply stay around with 1.7.3 (and the instabilities) [16:34] pmcgowan: i'd rather land 1.7, i think that's a better version overall [16:34] its no longer a choice afaik [16:34] there is no rather [16:34] sil2100: there are definitely issue with tabs in 1.7.3 [16:34] ok, deal [16:34]