[00:04] kgunn, great, got silo 5 fully landed, I just hit merge & clean for you now because we're a little short on silos ;-) [00:06] kgunn, I guess this means silos 2 and 3 should be rebuilt, but I will leave that up to you. [00:06] * robru -> dinner! bbl [00:07] robru: dinner and thanks! [00:07] :) [00:07] kgunn, you're welcome! [00:07] sergiusens, mandel: The unity-scope-click MP in the download manager silo looks like it's waiting on re-testing and review from alecu. [00:07] sergiusens, mandel: You sure this is ready for landing? [00:07] https://code.launchpad.net/~mandel/unity-scope-click/rebuild-with-udm/+merge/214935 [00:08] The last jenkins test run also lists some failures. [00:20] Chipaca: Any extra details you could give about silo 012 (push) would be helpful. Really, almost any detail at all. Link to a bug or MP, details on how to test it, etc. [00:21] The landing proposal has a comment indicating it can't currently be tested, and needs additional people around. [01:01] ToyKeeper: I'm not so worried about the jenkins failures as it requires the latest unmerged u-d-m (which is why it built fine in the silo); I am worried however about alecu's comment from just 3 hours ago [01:03] Thanks, I was wondering about that. [03:06] ToyKeeper, how's it going? anything signed off for me to land? [03:48] robru: Sorry, didn't hear your ping earlier. [03:48] robru: I finally got the third phone, and am testing it. [03:48] ToyKeeper, no worries, thanks [03:49] Its owner stayed late at work... [03:57] good morning [04:03] robru: It appears to work, aside from one kind of big issue. After ending one call, the second one stays on hold. [04:03] ToyKeeper, oh excellent [04:03] It's still an improvement over the base image though, so I'm inclined to give it a "Yes". [04:16] It must be late. It didn't occur to me for like 10 minutes that you can get the second call back by hitting 'play' after hanging up the first call. [04:19] robru: In any case, silo 004 is signed off. [04:19] ToyKeeper, thanks! [06:42] maybe a new image with mir 0.1.8 should be kicked? [06:43] Mirv: +1, doing [06:43] * didrocks wonders why a Mir version landed without the qt fix [06:43] asac: do you know from your backlog? ^ [06:49] === trainguard: IMAGE 296 building (started: 20140415 06:50) === [07:08] Uh! [07:09] Am I the only one not being able to sign in on the CI Train spreadsheet? I get a login.ubuntu.com Oops! [07:09] sil2100: LP seems down too, so no, not the only one [07:10] ouch [07:10] it worked a while ago, and spreadsheet does work but I was already logged in [07:10] so down maybe for 10 mins or so [07:11] Mirv: btw. I marked you as a reviewer for one of my appmenu-qt5 fixes I made - didn't know who to ask and thought maybe you could help ;) [07:12] sil2100: I noticed, the diff looked good to me (aside from the #undef signals but that's what you get for mixing Gtk + Qt...) but I've not run it yet [07:15] Mirv: thanks for taking a look - yeah, it's also what Qt5 does actually for their gtk theme plugin, so I would say it's something acceptable... [07:15] At least in this case, as I am not using signals anywhere in that file [07:21] yep, should be good [07:22] LP seems to work again [07:24] login.ubuntu.com still seems to have problems [07:30] * Saviq just had to try 5 times to finally log in to ci-train... openid failed to "discover a server" first, then OOPS, then 2fa, wrong link... [07:30] uh or am I able to log in at all? [07:30] ah, 6 times a charm... [07:30] :| [07:31] * sil2100 still can't log in [07:35] didrocks, asac, did either of you request the cron job to be shut off ? [07:36] ogra_: I didn't at least [07:36] hmpf [07:38] didrocks: i dont know tbh. i know kgunn came along with a crash fix that was supposed to be added to the projects that jfunk could validate while we are waiting for the event fix. I didn't know that was landing a new upstream version with ABI break etc. [07:38] didrocks: any damage? [07:38] ogra_: not me [07:38] asac: the crash fix was the one with "crash on shutdown" that we had for weeks now [07:39] didrocks: right [07:39] asac: we don't know yet of any damage as I had to kick an image with it [07:39] hmm. [07:39] should i start an image build now ? we didnt get one for the night and there were quite some chnages [07:39] ogra_: already done [07:39] *changes [07:40] ah, k [07:40] right, i should listen to my bot :P [07:40] ogra_: still ~30 minutes before it's done I guess [07:40] :p [07:40] (1h ago, I didn't realize right away that the image didn't contain Mir as it wasn't the cronned one) [07:40] not good that we didnt get an image; is robru not able to kick images? [07:41] nope [07:41] asac: we got an image [07:41] before the Mir change [07:41] Mir was early today [07:41] we got 295 from yesterday evening [07:41] I thought the produced image was the cronned one [07:41] as there was only one [07:41] would have been nice to have one inbetween [07:41] didn't check right away, and so, assumed that Mir which entered before the cronned image was in latest [07:41] since 2/3 of the changes of the night are on the image [07:42] yeah [07:42] ogra_: so you think the release team disabled again by error? [07:42] ogra_: is there a comment in crontab? [07:42] no comment [07:42] should have one I guess :) [07:42] and this kind of changes usually doesnt happen in the bzr branch [07:42] so no commit message either [07:43] we got that on beta as well, right? [07:43] (only permanent changes to crontab usually go to bzr) [07:43] not sure beforehand [07:43] yep [07:43] i assume infinity has a script or some such ... and forgot to remove touch [07:43] maybe, infinity can you check, please? [07:43] ogra_: is there a way to ensure that I'm on the right android version? [07:44] (tested some upgrade path) [07:44] ## Also built on demand by touch release team. [07:44] ## DO NOT DISABLE DURING MILESTONES [07:44] 02 2 * * * for-project ubuntu-touch cron.daily-preinstalled --live [07:44] like, the container has the right drivers… [07:44] i changed it to that [07:44] :) [07:44] great ;) [07:44] didrocks: if ToyKeeper refers to "new bugs found" ... this doesnt mena they are regressions, right? [07:44] (though if it is a script it probably cant read ) [07:44] :P [07:45] asac: I guess so. It doesn't seem anything that could have been regressed again. It's hard to parse though [07:45] asac: but I'm unsure, as I explained to her multiple times that we don't really care about exploratory testing and if we find new bugs, we need to confirm if it's a regression or not [07:45] ToyKeeper: would be cool if you could clearly state that "New bugs found" are not regressions and highlight those that are. [07:46] ogra_: did you see my question about the driver/android version? [07:46] nope [07:46] 09:43:58 didrocks | ogra_: is there a way to ensure that I'm on the right android version? [07:46] 09:44:02 didrocks | (tested some upgrade path) [07:46] 09:44:16 didrocks | like, the container has the right drivers… [07:47] hmm [07:48] didrocks, there is one stamp in the system-image ini file [07:48] and there is: [07:48] adb shell getprop ro.build.date [07:48] Fri Apr 11 21:04:45 UTC 2014 [07:48] seems to match [07:48] yeah [07:48] so, it's a good news :) [07:49] asac: I tested stable -> devel upgrade [07:49] i dont think there is a way to verify the boot.img though [07:49] worked well [07:49] (a full image download happened of course) [07:49] but if it wouldnt have changed you wouldnt be able to boot a new rootfs [07:49] then, I did devel -> devel-proposed to be on latest [07:49] ogra_: oh? I thought some people were still able to boot the new rootfs with the old android [07:49] ogra_: like those on maguro [07:50] didrocks, they need an up to date initrd [07:50] ah, so probably possible at the beginning [07:50] until we broke ABI [07:50] it is still possible, but the initrd needs to have the recent code changes [07:50] ok, anyway, good news! the fact to not flash recovery right away while doing stable -> devel-proposed doesn't impact us [07:51] (worst case you can just update-initramfs -u) [07:51] ooopsss [07:51] stable -> devel [07:51] ogra_: ok, making sense ;) [07:51] (I didn't tried with any living data, just the upgrade path regarding recovery) [07:51] rsalveti: FYI ^ [07:52] this is good stuff :) [07:52] try* [07:52] yep! [07:52] so, of course, you see the old android logo while doing the first update :) [07:52] and then, the new one with new recovery [07:52] right [07:52] (while I was doing devel -> devel-proposed as a subsequent update) [07:53] you did that all with a readonly image ? [07:54] didrocks: really? [07:54] didrocks: thats good news :) [07:54] ogra_: had to pass it rw to change channels.ini [07:54] asac: indeed! I was quite skeptical myself TBH :p [07:54] ah so only the last bit in rw [07:54] yeah [07:54] didrocks: did you use apps at all on the old image? [07:54] === trainguard: IMAGE 296 DONE (finished: 20140415 07:55) === [07:54] === changelog: http://people.canonical.com/~ogra/touch-image-stats/296.changes === [07:54] asac: no, it was really about testing recovery [07:54] checking how configs might explode [07:55] ah [07:55] ok [07:55] I think QA is going to do the real test? [07:55] ugh [07:55] so many changes [07:55] well, now that we know that it works, we could try to find someone else [07:55] I was just preparing the rest as we didn't get any news :p [07:55] yeah [07:55] I was really worried about that one, so good to know where we stands for [07:55] and having a positive news) [07:55] ogra_: most of the changes are rsalveti's rebuild for shlibs [07:55] ogra_: yeah, that might mean dead to the idea of producing a better image. lets hope [07:55] ogra_: so don't be so afraid [07:55] some of them, yes [07:56] * didrocks updates to get new Mir and see [07:57] hmmm [07:57] my phone woke up, i opened system-settings and now it is stuck [07:57] ogra_: unity crash? [07:57] doesnt take input [07:58] asac, well, might be, the screen is still on [07:58] with system-settings on it [07:58] sounds like something is freezing [07:58] might dump core [07:58] so if it crashed it doesnt repawn [07:58] be patient [07:58] it's a whole minute :) [07:58] check if something appeared in /var/crash [07:58] with a growing size [07:59] ok, after reboot with new Mir, I have an UI [07:59] ship it! :) [07:59] ok, it respawned now [07:59] I don't see perf enhancement :/ [07:59] thats a very odd user experience [07:59] i doubt an enduser will wait that long and just reboot [08:00] -rw-r----- 1 phablet whoopsie 6696880 Apr 15 09:59 _usr_bin_system-settings.32011.crash [08:00] -rw-r----- 1 phablet whoopsie 31881265 Apr 15 09:59 _usr_bin_unity8.32011.crash [08:00] 31M ... sigh [08:00] ogra_: probably ricks crash [08:01] yeah, smells very much like it [08:01] maybe it got fixed by the crash that only happens on shut down :) [08:01] oh ! [08:01] and thats why they wanted that in [08:01] ogra_: thats not on the latest, right? [08:01] seems download-manager did its job while the system was hung+ [08:01] asac: because ogra asked to shutdown his unity8! :) [08:01] asac, 294 [08:01] (j/k) [08:01] at least our services dont get torn down [08:01] I know what you mean :p [08:01] :) [08:02] ok, after a 5 minutes play, at least, nothing major [08:02] * ogra_ got the reboot dialog immediately after opening updates after the crash [08:02] didrocks: on the new mir image? [08:02] asac: yep [08:02] didrocks: i tell you they fixed the crash that ogra is seeing :) [08:02] asac: let's hope it's the same :) [08:02] we'll know if the crash is really fix however in some hours only [08:03] when the AP for that image will run [08:03] yeah [08:03] or maybe [08:03] let me run them [08:03] didrocks: try to get a backtrace from your .crash [08:03] :) [08:03] or upload to a bug at least [08:03] or not :) [08:03] ogra can do that [08:03] asac: I mean, you talk to ogra, right? [08:03] oh right [08:03] you didnt see it yet :P [08:03] yep :) [08:03] let me run AP tests [08:03] ogra_: can you try to retrace that one? [08:04] (AP tests started) === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: - [08:05] asac, just checking why whoopsie doesnt bother to upload them [08:05] asac: few tests run, no AP crash! (it crashed on first one) [08:06] but I do see the rendering is so slowwww compared to #250 [08:06] (UI staggering) [08:06] was already the cases in recent images [08:07] ok [08:08] ogra_: whoopsie is supposed to work? [08:08] asac, yes [08:08] ogra_: why didnt we tell rick to use that? [08:08] :) [08:08] asac, well, it is supposed to upload [08:08] without interaction? [08:08] because it should happen automatically [08:08] right [08:08] thought we disabled that to avoid bandwidth etc. [08:09] i actually was under the impression we disabled whoopsie automatic upload [08:09] saying people should run it manually if there is a crash [08:09] http://paste.ubuntu.com/7253982/ [08:09] that was roughly 8 month ago :) [08:10] /var/lib/apport/autoreport exists? [08:10] no, but the MATCH=NULL disables it [08:10] asac: huh? Why would we rely on people to manually run whoopsie? That's a recipe for wildly skewed statistics. There were bugs in the upstart job, but if those are fixed we should enable automatic reporting. [08:10] as was always the intention [08:11] ev: err [08:11] ev: if you are on a phone [08:11] ev, well, look at the job above [08:11] you dont want to do that [08:11] ev, http://paste.ubuntu.com/7253982/ [08:11] ev: we agreed to not auto upload long ago :) [08:11] really? Because it's exactly what Apple and google do [08:11] ev: 3g bandwidth [08:11] etc. [08:11] we agreed to disable it in the face of bugs [08:11] whoopsie already is a no-op when you're on 3g data [08:12] ok; well, seems to not work still :P [08:12] Every time an application crashes on my iPhone, data goes up to either the application developer or to Apple [08:12] and the platform and applications are better for it [08:12] well, it seems pretty explicitly disabled from what i see in the job [08:12] they don't rely on developers to manually trigger crash reporting for every general consumer use case [08:12] because developers wont use their phones in the same way that consumers do [08:13] and because developers will never scale to the degree that consumers do [08:13] ev: i am not saying it should be manually forever [08:13] high hopes :) [08:13] but rather opt in [08:13] allowing users when there is a crash to decide whether he wants to provide feedback or not [08:13] and then remembering that seting [08:13] anyhow [08:13] we have a switch in treh privacy settings for that [08:14] that's entirely not how our competitors operate, and for good reason [08:14] seems its not working/enabled from what ogra is saying [08:14] ogra_: right, is that disabled? [08:14] but i doubt it does any apport/whoopsie interaction [08:14] it can be disabled, and we can give them the opportunity to disable it at first use [08:14] last time i chgecked it was on [08:14] * ogra_ looks [08:14] ev: we should ask on first use; until that happens you shouldnt just call home and upload potentially sensitive data. [08:14] i havent really used android for a while [08:15] hmm [08:15] err started using a new phone; but if i remember i also got asked something like that [08:15] on first use [08:15] it is off now and i cant tick it [08:15] anyhow, seems we agree [08:15] :) [08:15] ogra_: thats seb128 [08:15] asac: the plan is to have the first use dialog ask you if you want to turn it off [08:15] no? [08:16] ev: where is that plan? [08:16] in general its what i am saying: ask user on first use what to do [08:17] asac: in conversations between myself and the legal team [08:17] what? [08:17] right, but to be clear the default will be set to leaving it on [08:17] opt-out, rather than opt-in [08:17] asac: ok, no crash while running the unity8 AP tests… [08:17] ev: if you get asked on first use, there is no default [08:17] asac: however, got a freeze of the whole UI [08:17] its a choice [08:17] completely stuck… [08:17] it's a toggle in this case [08:18] if we plan to make the dialog so that we trick users to enable it, i would think we should at least have a wider discussion on what we want [08:18] didrocks: the freeze isnt a crash? [08:18] aww [08:18] asac: doesn't seem so, no crash file, no collect happening [08:19] asac: it's not tricking anyone into enabling anything [08:19] so my former crash left the renderer processes of all open webapps around [08:19] sigh [08:19] ev: we will see :) [08:19] it's about being positive about the error reporting experience [08:19] asac: we will see? [08:19] how the solution looks like [08:19] the solution is already established and has been for some considerable amount of time [08:19] we have a first start dialog asking that? [08:20] didrocks: that happens after AP tests were run? [08:20] no [08:20] the UI responsivness seems even worse to me [08:20] asac: while it was running [08:21] -/+ buffers/cache: 4254 3613 [08:21] seb128: i am not sure; ogra mentioned that the error reporting setting doesnt work; thought you might know more [08:21] -/+ buffers/cache: 400 1434 [08:21] rather [08:21] so not swapping/mem full [08:21] didrocks: yeah, me and Mirv noticed something similar before [08:21] didrocks: dmesg? [08:21] sil2100: before == before that image? [08:21] sil2100: in an old image? [08:21] asac, seb128, it worked after a while (two minutes or so) that i tried to tick it [08:21] we've already planned out with the design team how it should look. With people coming and going in that department, I haven't followed up on where it stands - I know the first use dialog was stalled for a while. I need to catch up with cimi. [08:21] asac, no, our code didn't change, we are just using dbus to talk to whoopsie iirc ... [08:22] ogra_, ^ [08:22] didrocks: remember when we were running AP tests once because of smoketesting being done? During running unity8 tests I was getting a unity8 hang-up, no crash, just non-responsive [08:22] I would say it's an issue on the whoopsie side [08:22] *done=gone [08:22] ogra_: kk [08:22] asac, didrocks: on an old image, yes [08:22] asac: nothing apart from britness and wlan changes [08:22] seb128, well, i dont think i have ever even touched that area of the settings before (i had seen it once) so i dont know if it ever worked for me [08:22] ogra_: did it ever work better? [08:22] sil2100: hum… [08:22] let me reboot [08:23] ogra_: ah ok [08:23] asac, i never ticked/unticked the box before and it was ticked the times i opened that page before [08:23] didrocks: I remember I think I just restarted unity8 from console, pressed the power button twice and the tests moved on [08:23] this time i saw it untick itself while the page opened [08:23] didrocks: as it seemed that unity8 hanged becoming unresponsive after stopping [08:23] hmm. eventqueue bug? [08:23] (during restart) [08:23] ok, let's try a full rerun [08:23] and trying to tick it again didnt work for about 2min [08:24] didrocks: from what I understood, Mirv was getting something similar apparently [08:24] ok, let's see [08:24] ogra_: maybe after you enabled, whoopsie started processing the crash files? [08:24] ogra_: and thats why system was busy? [08:24] asac, ? [08:24] sil2100: yes, I got it once [08:25] ogra_: 10:23 < ogra_> and trying to tick it again didnt work for about 2min [08:25] asac, i only looked at that setting long after the crash appeared [08:25] well, whoopsie also has to do something with the .crash file [08:25] and there are no whoopsie upload processes [08:25] (and there were none, i checked) [08:25] sil2100: Mirv: I would like to land couple of fixes with the line 44 [08:25] ogra_: ok [08:25] then i dont know [08:26] whoopsie only reads crash files and shovels them over the wire to daisy.ubuntu.com if a .upload file exists for the .crash file [08:26] if something is going wrong in the report creation or processing, that's apport [08:26] * ogra_ runs whoopsie-upload-all manually ... [08:26] guess something that ev and seb128 would have to look at if its the same behaviour for other folks [08:27] kernel core pipe -> apport -> something that touches .upload (apport-gtk or whoopsie-upload-all) -> whoopsie -> daisy.u.c [08:27] e.g. odd behaviour of settings [08:27] root@ubuntu-phablet:~# sudo -u \#32011 /usr/share/apport/whoopsie-upload-all [08:27] WARNING: Not running as root, cannot process reports which are not owned by uid 32011 [08:27] so running it manually works fine it seems ... [08:27] it just doesnt auto-trigger [08:28] ogra_: cool. how will you find the error report online? [08:28] whoopsie keeps a local record or so [08:28] ok then lets wait what it tells us [08:28] there is a UI option too [08:28] asac, ogra_: settings just call defined whoopsie interfaces, I would be surprised if the issue was on our side [08:28] * asac excited :) [08:28] probably this works now [08:28] asac: sil2100: Mirv: stuck again [08:28] can you reproduce guys? [08:28] bzoltan: landing-004 [08:28] Mirv: thanks [08:28] didrocks: will be 2 mins late.. [08:28] hmm, I haven't seen it now [08:28] seb128, well, the odd behavior of the tickbox seems to be on your side [08:29] Mirv: try on latest image [08:29] seb128, i doubt any of the other issues is [08:29] seb128: have you ever tried that settting :)? [08:29] oh, crap, i will be late for the meeting [08:29] * ogra_ brb in 5 [08:29] I'll be late as well [08:29] I have a delivery [08:29] asac, yes, it worked fine and works fine on the desktop as well [08:29] so 5 minutes [08:29] ogra_: asac: sil2100: Mirv: popey: davmor2: ^ [08:29] Let me upgrade [08:30] didrocks: ACK [08:30] start the unity8 AP tests meanwhile :p [08:31] hmm. i only intended to attend the evening meeting [08:31] didrocks: I'm on it, and I've been running dialer app AP tests mostly [08:35]