[00:02] Kaleo: ? [00:03] cyphermox, we are going to need to land a ui toolkit release soon [00:03] cyphermox, can you help? [00:07] Kaleo, sorry, I was on lunch. back now. is it landed? [00:07] robru, lunch? [00:07] robru, where do you live?? [00:07] Kaleo, west coast north america ;-) [00:08] robru, mad person [00:08] robru, anyway [00:08] robru, it's not landed yet, we are doing final tests before top approving [00:11] Kaleo, ok, i'm here now for at least 3 more hours [00:12] robru, brilliant [00:12] then dinner break, then probably back again even later [00:12] :D [00:28] robru, it's top approved; waiting for landing. [00:28] Kaleo, great [00:57] robru: I'm around too if you need any help [00:57] cyphermox, cool. might need you to help test ubuntuuitoolkit once it builds. [00:58] alright, just ping me when [01:05] Kaleo, there's a test failure in the branch: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/1104/console can you fix it? [01:07] robru, it's a blip [01:07] robru, rerun jenkins [01:07] Kaleo, flaky test? [01:07] robru, or flaky infra [01:07] (test completely unrelated to the fix) [01:07] (also it succeeded before) [01:08] Kaleo, ok, I'll just ram it through then. I see timp did some independent verification as well [01:08] yes, looks unrelated. [01:08] t1mp, :) [01:08] I can happrove again and then really go to sleep :) [01:08] t1mp, no worries, I will merge manually due to the urgency of this [01:08] okay, thanks. [01:08] thanks robru [01:09] * t1mp off [01:09] t1mp, goodnight! [01:27] Kaleo, this commit doesn't apply cleanly based on what is in distro currently. very difficult for me to backport. are you sure we can't just release uitk trunk as is? [01:28] ls [01:28] robru, go for the release [01:28] Kaleo, great, thanks [01:29] cyphermox, still around? just built uitk in PPA, ready for testing ASAP [01:38] Kaleo, erm.... just tried the latest build with this patch on my device and it doesn't show any tabs at all for the indicators... [01:40] robru, that does not quite make sense, let me see [01:41] Kaleo, tab bar takes up corrent height space, but it's blank. no text appears within it [01:41] Kaleo, oh, nm, rebooted and it's fine. must have been some mismatch between memory vs newly installed files. [01:42] ah [01:42] Kaleo, actually they still don't like up after the reboot though ;-) [01:43] Kaleo, oh strange, i might not have the right version installed. odd. [01:44] " Kaleo, actually they still don't like up after the reboot though ;-)" not sure what that means [01:45] Kaleo, I mean, the indicator icons do not match the tab names. as in, the original bug is still the same. but it seems when I updated the package on the device it didn't get the latest version from the PPA [01:45] ok [01:45] Kaleo, couple of false starts here, rushing too hard ;-) [01:45] :) [01:45] you are scaring me [01:46] Kaleo, first problem was not rebooting after update, second problem was looking at https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=toolkit&field.status_filter=published seeing 'published' and then not realizing that armhf was still building (published just means source package published) [01:47] oki doki [01:52] I'm here in case anything goes kaboum [01:52] Kaleo, ok, indicators look good, just gotta run through a suite of tests to check for regressions then will publish. thanks for doing the hard part ;-) [01:53] robru, thanks [01:54] rsalveti, you still around to kick the image build? should be ready in about an hour [01:55] robru: yup [01:55] robru: let me know once you publish the package [01:55] rsalveti, ok, will do [02:09] robru, I suppose you don't need me anymore [02:09] actually [02:09] Kaleo, just saw 100% passes on uitk tests, so I think we're good. some more tests before publishing though [02:09] Kaleo, thanks! [02:09] robru, ok [02:10] robru, if anything goes awry zsombi and bzoltan should be up in few hours [02:10] robru, thank you [02:21] robru: sorry, I'm around now [02:21] still need testing? [02:27] cyphermox, yeah sure, install uitk from the ppa and run some app tests [02:27] ok [02:28] cyphermox, so far so good, ive done addressbook, camera, dialer, and working on gallery now [02:33] figured ;) [03:08] rsalveti, ok, uitk is published. not sure when it will make it through -proposed and into distro, but can you watch for it and kick a build soon? [03:09] robru: just, still waiting it to be accepted by lp [03:13] in proposed [03:23] rsalveti, alright I'm EOD but will probably be back around in 4ish hours if anything is needed. best is to email me. [03:24] ok, will trigger a new image in a few [03:24] rsalveti, thanks! goodnight! [03:24] np, goodnight! [05:12] robru: seems to be published in the lp UI for almost one hour but not yet published in the real archive [05:13] wonder if something wrong happened [05:23] weird [05:23] rmadison ubuntu-ui-toolkit is still not showing the latest version [05:23] not even in proposed, as it was one hour ago [05:23] rsalveti: do you know who archive admin might be online? I've never seen a situation where LP states it in either proposed/release but rmadison doesn't show anything [05:24] not sure, let me ping them at #ubuntu-release [05:24] thanks [05:26] triggered a new image so we can have the other many changes tested asap [05:26] but we'll need another one once this issue with the toolkit is fixed [05:28] anyway, scheduled another image respin once the one I triggered a few minutes ago is done [05:30] and I'm gone, later! [05:32] bye! [06:57] Mirv: hey, how are you? [07:08] thanks, fine didrocks. how's your start of the day? [07:08] Mirv: well, catching up, I guess will be a busy day! [07:08] Mirv: thanks for the keyboard release, you are on upstart-app-launch now? [07:09] didrocks: yeah, or that's also now published and soon in proposed [07:09] great! [07:09] so, if I'm correct, what remains: [07:10] the unity8 crash due to Mir [07:10] and the wlan/gsm connexion in empathy [07:10] did I mention anything else to you that I'm forgetting? [07:12] no, that's the remaining thing, and you didn't even mention empathy [07:12] the bug has been updated to say it's not mir related, but might be unity-mir related (which hasn't seen changes besides version bump) [07:13] Mirv: I wonder if we can envision reverting unity-mir to previous release [07:14] Mirv: there were a lot of revs between rev 136 and latest in distro [07:14] Mirv: can you try building rev 136 against latest Mir? (well 137 to get the changelog ;)) [07:15] to ensure there is no API break [07:15] I guess the daily-build ppa has a newer Mir, so building directly on phone? [07:15] (when I meant latest Mir, I meant, latest Mir released in distro) [07:15] I'm taking care of the empathy thing with upstream [07:15] we do have a double bug there :) [07:29] didrocks: hmm actually there is one new commit in unity-mir, I wonder if there's any chance it would fix something [07:30] Mirv: it doesn't seem related, I would rather try "previous Mir release" [07:30] (to the part of the code crashing) [07:30] ok.. and locally indeed [07:30] thanks Mirv, keep us posted, if we can get that + the empathy one, we can rekick an image [07:30] and have a beautiful day :) [07:45] didrocks, http://q-jenkins.ubuntu-ci:8080/job/cu2d-webapp-saucy-3.0publish/82/console can you check why this never made it into proposed? [07:46] saucy-proposed, that is [07:46] robru: because saucy is released? [07:47] so it's in unapproved: https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text= [07:47] didrocks, i thought the whole point of saucy-proposed was to hold uploads prior to SRU approval? [07:48] robru: no, SRU approval is to get to -proposed [07:48] then, people can test for 7 days in proposed [07:48] and if no regression is spotted, it's going to -updates [07:48] didrocks, this process is insane. [07:49] robru: well, it's the process when we had no test automation [07:49] it was fine by then [07:50] didrocks, so i have an SRU bug filed and ubuntu-sru proposed, they will eventually look at it and put it in -proposed? I already verified the change in a fresh saucy VM, so I already tagged the bug 'verification-done' even though it's not even in -proposed yet. [07:50] robru: you shouldn't tag it before it's in proposed [07:51] robru: but yeah on your first question, this is the process [07:51] didrocks, ok. /me cries [07:51] weird you were not aware about the process before discussion the SRU process session :) [07:52] didrocks, and yet, I was arguing against a simpler process... now I find out the process is **even harder** than I already thought was so hard it deserved to be argued against! [07:52] well, there are reason to not accept every crack that people want to SRU [07:52] or we can end like in fedora when they SRU a new KDE major release :) [07:53] didrocks, yeah, I understand the need for SRU when it comes to stuff that can't break when left to it's own. but when you are in a race to play catch up with half the websites on the internet, every step in the process represents an enormous slowdown. [07:53] robru: agreed [07:53] this is really a difficult situation [07:53] I totally get you, no worry :) [07:54] didrocks, well, I published my first click app today. it was delightful. it is *absolutely* the only acceptable way to publish webapps. The fact that I have to SRU webapps into trusty for the next 5 years is nothing short of tragic. I don't think I can do it. [07:55] robru: push to convert them to click apps then, but there are a lot of implication in term of security I guess :) [07:55] didrocks, that's what my talk was about! i wanted to clickify desktop webapps in trusty! but I was immediately shot down, click apps won't be ready in desktop trusty. [07:58] didrocks, can you accept my saucy nomination here? https://bugs.launchpad.net/ubuntu/+source/unity-webapps-facebookmessenger/+bug/1246503 [07:58] Ubuntu bug 1246503 in FacebookMessenger WebApp "Installed icon is wrongly referenced by the desktop file" [Undecided,Fix committed] [07:59] robru: done! [08:00] didrocks, thanks. [08:00] yw [08:00] thanks for the toolkit upload [08:00] * didrocks hopes the last 2 remaining issues will be gone soon and we can move on [08:00] didrocks, no worries. I did really try to backport that patch but there were soo many conflicts. [08:01] robru: as long as you ensured all tests were working, that's fine [08:01] didrocks, yep yep, ran all tests and also dogfooded directly, saw the indicators working. [08:02] robru: excellent, let's cross fingers, there was no other unseen regression bundled [08:02] robru: the fix has a test btw? [08:02] didrocks, yeah, I think so. I didn't read it too closely but I saw the diff touching test files ;-) [08:03] well, you should look more :) [08:03] didrocks: doesn't look good for compiling older unity-mir against the current archive mir. the refactoring done needed for mirserver10 support is where the crash also happens, and there's eg. bzr141 after the refactoring that claims to fix another crash related to unity-mir's MirSurface. I'm not sure what to try. [08:03] most of test files were deleted [08:03] but function test_tabOrder_bug1253804() { [08:03] robru: so we're good ^ [08:03] :) [08:04] Mirv: ok, so let's try to see with greyback [08:04] didrocks, my understanding is that they didn' tjust fix the bug, they changed the way tabs are created. so many tests were testing obsolete API that was removed, that's why those tests are dropped. but yeah I do see new tests written there [08:04] robru: ok [08:04] robru: yeah, sounds good! [08:05] ok [08:05] alan_g as well [08:05] Mirv: the first who can catch either of them :) [08:05] robru: I also had the UI Toolkit updated already when I ran my various tests today, looked good too [08:06] didrocks: upstart-app-launch is stuck because of a new dependency that is not available on arm64 [08:07] Mirv: can you work with the release team to get that unblock/see the best way to get the transition done? [08:07] I'm trying hard on the empathy side meanwhile [08:08] didrocks: ok [08:12] arh, I can't bug them, it's not as simple as that. it's not that it wouldn't be available for arm64 otherwise, but there's a build-dep that specifies the PPA version. [08:12] and for a reason, ie. the dbus-test-runner would need to be released [08:14] so, hmm, adding dbus-test-runner to the landing task [08:22] didrocks: it seems the reverse build-depends continue to build with the new dbus-test-runner (including the new upstart-app-launch that also uses the added DbusMock functionality), so is there something more specific to test in order to release it? [08:23] Mirv: if it builds against it, feel free to release it to unblock [08:23] as it's using it at build time [08:25] thanks, yes it does and the build logs show the tests being run [08:26] didrocks: ack needed http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-test-runner_14.04.0+14.04.20131126-0ubuntu1.diff [08:27] the changelog is slightly misleading since the Vcs/M-A were added in a manual upload already [08:27] Mirv: +1 [08:27] thanks again [08:30] thank you Mirv :) [08:43] Am I the only one that thinks a day should have more than 24 hours? [08:43] So sleepy... [08:43] sil2100: +1 [08:46] ogra_: popey: good morning around? [08:46] didrocks: morning [08:47] popey: I have a potential fix on the GSM bug [08:47] (you know about that one, right?) [08:47] https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1252737 [08:47] Ubuntu bug 1252737 in telepathy-ofono (Ubuntu) "[regression] Ubuntu touch cannot get GSM signal if not joined to a WLAN network" [Critical,Confirmed] [08:47] gsm no working when wifi? [08:47] right [08:47] when no wifi, right :) [08:47] can you try a recent image [08:47] with nothing changed on it of course :) [08:47] + [08:48] https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5269486/+files/libmission-control-plugins0_5.16.0-1ubuntu2~ppa1_armhf.deb [08:48] and https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5269486/+files/telepathy-mission-control-5_5.16.0-1ubuntu2~ppa1_armhf.deb [08:48] I've tried a tentative "fix" [08:48] then what? try and make a call when on wifi? [08:49] no, disable wifi [08:49] reboot [08:49] see you are connected to the GSM network [08:49] (hopefully) [08:50] what's your test for connected to gsm? [08:50] nmcli d ? [08:51] popey: I'm just relying on the indicator TBH, not sure about a command line tool (and not really knowledgeable in that area) [08:51] ah ok [08:54] didrocks: http://popey.com/~alan/phablet/device-2013-11-26-085434.png [08:54] that what you expect? [08:56] wlan is down and I am browsing the web, and made a phone call too didrocks [08:56] popey: yeah \o/ [08:56] * didrocks hugs popey [08:56] \o/ [08:56] popey: this is after a reboot, right? [08:56] yes [08:56] with wlan down? [08:56] yes [08:56] \o/ [08:56] * didrocks makes a dance [08:56] root@ubuntu-phablet:/# nmcli d [08:56] DEVICE TYPE STATE [08:56] /ril_0 gsm connected [08:56] thanks a bunch for confirming :) [08:56] wlan0 802-11-wireless unavailable [08:56] np [08:56] * popey makes tea [08:57] you dance, we drink tea. It's our cultural differences I value so much! [08:57] ahah :) [08:57] * didrocks can have tea just after dputing === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues [09:14] The indicators on my phone confuse me on the yesterday's image ;) [09:43] so can I ask also autopkgtest failure question on release? [09:44] or simply here? I mean, this d-jenkins job ended with machine shutting down, which is maybe the only reason it failed? http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ARCH=amd64,label=adt/6/ [09:44] psivaa: ^ any idea? [09:44] Mirv: i'll take a look [09:45] thanks [09:46] ev, could we re-nice whoopsie (and all its sub processes) and make sure it only starts ... say ... 30min after boot for the first time or some such ? [09:46] -s [09:47] ogra_: it doesn't have subprocesses [09:47] if you have more than one whoopsie running, that's a bug [09:47] ah, well, then only whoopsie itself ... [09:48] what i'm thinking is, if we could make it slow and silent enough that the user doesnt get massively get bothered by having it running ... even if it takes 5x longer then ... i dont think it matters how fast we get the info if we get it at all [09:48] the problem with delaying or disabling whoopsie is that it will make us blind to particular types of crashes. What happens if the phone boots, but crashes as soon as unity starts? They're not going to leave it running for 30 minutes. [09:48] and a phone usually runs for a long time [09:49] other platforms have crash reporting end-to-end. I think what we need to be doing is fixing whatever bugs exist in whoopsie, rather than papering over them by hiding it away [09:49] yes, i dont want to disable it, just make it "silent" enough for the user to not notice it massively [09:50] now there may be structural changes here as well. If someone can figure out how to get it to spawn via upstart whenever the same set of conditions are met that it's currently using to process reports, then it doesn't have to be long running [09:50] I think renice'ing it or putting it in a cgroup that uses far less CPU is a wise idea [09:51] I don't think processing a crash report should take priority over the UI process [09:51] right ... just make it eat less resources if possible ... even if it takes longer to run [09:51] exactly [09:52] if it doesnt take more than i.e. the browser running ... the user shouldnt massively notice it [09:52] but we should also be looking at why it's taking so long to process, and seeing if we can optimise that as well [09:52] let's hit the problem from both ends [09:52] ++ [09:52] whoop [09:52] sie :) [09:53] psivaa: I see also the previous successful run ended in shutdown, so I guess that part is normal but the permission denied etc. not similar to the successful run http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ARCH=amd64,label=adt/5/console [09:53] psivaa: so the "dsc0t-with-bustle"", whatever it means, was the failure [09:53] Mirv: yea I see that, permission denied appears to be the cause [09:55] ogra_: ev: also checking we only run it on wlan :) [09:55] well [09:55] I don't think people want to upload on 3G the crash report ;) [09:55] we should run it at all times ... but only upload on wlan [09:56] yeah, that's what I meant by "running" [09:56] didrocks: we only treat wifi and ethernet as being online [09:56] in whoopsie [09:56] ev: oh nice! [09:56] always thinking ahead :-P [09:57] heh, well done :) [09:57] funnily i never see .upload files in /var/crash here [09:58] (i assume i should ?) [10:01] yes, though that's the job of apport (via whoopsie-upload-all) [10:01] psivaa: there was also a new autopkgtest 2.5 released yesterday, maybe you could check with pitti if it's related? and just a few minutes ago some patch release "Fix ownership of test tree with --user option."? [10:01] https://launchpad.net/ubuntu/+source/autopkgtest/2.5.1 [10:02] so if the error comes from that ownership issue, then it should be just fixed in proposed [10:02] I vaguely recall us disabling this around release due to my broken upstart job [10:02] slangasek had a bug for it [10:02] well, /etc/default/apport considers it enabled [10:02] i dont see it running though [10:03] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1235436 [10:03] Ubuntu bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,New] [10:04] aww [10:07] Mirv: thanks for the clarification. pitti is tracking and will restart the jobs that failed due to that issue. so i guess i could we are good [10:08] psivaa: yep, it seems everything's now in order [10:25] Mirv, robru, rsalveti, do you know if there was an image built with the latest toolkit? [10:25] didrocks, fyi, on maguro the screen doesnt switch on again with r30 ... [10:25] Kaleo, there was [10:25] ogra_: really? :/ [10:26] didrocks, i know that davmor2 saw it before ... i can only manage to get it on when i tap or touch the screen after pressing the power button [10:26] didrocks, ogra_, rsalveti tried to kick it in the night; hopefully yes [10:26] smells like Mir input handling [10:26] ogra_: I was still on 29, let me upgrade [10:26] Kaleo, yes, it is version r30 [10:26] for mako [10:26] didrocks, seems to only affect maguro [10:26] ogra_, thanks! [10:27] but if you dont know it it looks like it never wakes up again [10:27] ogra_: so, in order, what are you doing? [10:27] pressing the power button [10:27] Kaleo, the indicator issue seems fixed [10:27] to get it on [10:27] ogra_, thanks :) [10:27] and then? :) [10:27] didrocks, pressing the power button leaves me with a black screen ... then touching the screen immediately switches it on [10:27] so that we can put into a bug report and starts looking at it [10:28] an, juts pressing shortly [10:28] just* [10:28] so, the regression is about "it's turning on when you don't want to" [10:28] right? [10:29] no [10:29] ah no [10:29] got it [10:29] its not turning on unless you touch the screen [10:29] pressing the power button to turn the screen on doesn't seem to work [10:29] yeah [10:29] argh [10:29] right [10:29] do you think it's the android upload? [10:29] no [10:29] i assume its Mir [10:30] ogra_: did you get that on image 29? [10:30] (but totally guessing) [10:30] and 28? [10:30] Mir didn't change since then [10:30] didrocks, i know davmor2 saw it before, but not sure which image he was on [10:30] might have been <28 [10:30] ogra_: I guess your network connection is not good enough to flash an older image? [10:30] just to confirm if we get it on image 28 [10:31] ogra_: confirming, it's not on mako [10:31] well, lets wait for davmor2, he usually files bugs immediately [10:31] yeah [10:31] ogra_: if it's as reliable on image 28, I would say, let's not block the promotion on that, thoughts? [10:31] it doesnt seem to be on mako based on a conversation i just had with timppa in #ubuntu-touch [10:32] yeah, I do confirm [10:32] didrocks, you know that mark uses a maguro for dogfooding ? [10:32] ogra_: well, if it's in image 28, it's already there (and he didn't complain about it) [10:32] at least thats what i was told a while ago (might have changed) [10:32] ogra_: so, we won't regress from that image [10:33] well, he might have switched to something performant nowadays :) [10:33] roh, maguro isn't that bad [10:33] I was really happy with android 4.x on it [10:33] did you ever actually use it as your main phone ? [10:33] (with ubuntu( [10:33] ogra_: not on touch [10:33] this was my own phone :) [10:33] yeah, its dog slow [10:33] ogra_: right, but seems android can do something fast with it [10:33] so we shouldn't blame it on the hw [10:34] starting more thna a few apps makes it go crazy etc [10:34] i do blame the HW ... but just because it has an awful video chip that has awful drivers [10:34] (if we had the same driver access google has it wouldnt be an issue) [10:35] ogra_: but we are using the same driver, right? [10:35] yes, but we cant look inside ... google can [10:35] right [10:35] and the PVR drivers are pretty awful ... that will bite us on intel even more [10:36] PVR? [10:36] * didrocks googles [10:36] (most of the mobile intel chips have the same PowerVR graphics chip the omaps use) [10:36] ok ;) [10:37] Mirv: any progress on the autopkgtests? [10:37] Mirv: unity-mir is in trusty [10:37] (using the same binary driver blob ..) [10:37] Mirv: so just waiting on upstart-app-launch I guess [10:38] sigh ... the clock is still only randomly running [10:38] (out of three boots i only get it once nowadays ....) [10:39] ogra_: I'm more lucky on mako [10:39] ogra_: but even have it on desktop… [10:39] that bug is open since months ... [10:39] I know… [10:41] final: autopkgtest,upstart-app-launch [10:41] SUCCESS (263/261) [10:41] phew! [10:41] ogra_: almost ready to push the triggered once published in the release pocket? [10:41] sure [10:42] hum, maybe I'm reading it wrong [10:44] didrocks: so the autopkgtest was with dbus-test-runner, and that was because of yesterday's autopkgtest 2.5, now fixed in 2.5.1 and pitti rerunning the tests [10:45] the rerun seems to be now at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dbus-test-runner/ , but update_excuses still showing it as fails [10:45] and the upstart-app-launch arm64 rebuild was now done [10:46] Mirv: yeah, so upstart-app-launch seems to be able to migrate, yeah! [10:46] (just confirmed on #ubuntu-release) [10:47] right, so it looks [10:47] good good [10:47] yep! [10:47] ogra_: rmadison says it's published, wasn't there a slight delay with porter? [10:47] before you kick the image? [10:48] if rmadison has it it is fine [10:48] === Image r31 building === [10:48] \o/ [10:48] \o/ [10:48] let's cross fingers ;) [10:49] for the power button issue, let's see if we have it in image 28 [10:49] r31, the famous 'perfect' image [10:49] will be nice to pinpoint which image it started with [10:49] Mirv: well, for mako, not maguro :p [10:50] with small exceptions, then [10:56] didrocks, bug 1255045 [10:56]