[00:05] rsalveti, approved [00:05] cjohnston, wiki updated [00:05] sergiusens: great, thanks [00:05] thanks sergiusens [00:05] building tarball, then upload, then new image [00:05] mako-07 is back online [00:07] cjohnston: thanks! [00:09] rsalveti: with your fix, will we be able to continue using phablet-flash (atleast for now) or will we still break with phablet-flash [00:09] cjohnston: should work with mako [00:10] ack [00:10] can someone file a bug against ubuntu-ci-services-itself with the need to switch please? [00:11] I'll test it again tonight, if it doesn't work, I'll look at getting it switched tonight [01:21] rsalveti: are you building a new image? [01:59] cjohnston: soon [03:20] rsalveti, asac: Sorry, I've been away from home most of the weekend. Looking at it now [03:37] ok, this doesn't bode well [03:37] I'm trying it at home and not getting good results - I don't even get past the google boot screen [03:37] rsalveti: is there something other than -b I need to pass to phablet-flash? [03:38] rsalveti: 'phablet-flash ubuntu-system -b --channel trusty-proposed' is what I'm using and I'm getting 205 [03:39] rsalveti: I also don't see a wlan0 in ifconfig -a on my local mako, nor in the lab [04:18] plars: right, we fixed the issue already [04:18] plars: latest image should have the fix, and should be around in a few minutes [04:18] rsalveti: ok, so this is a known problem and will be fixed in 206? [04:18] plars: yes [04:18] rsalveti: awesome [04:18] cdimage part is done already [04:19] rsalveti: argh, you have to tell me that at 10pm, now I can't sleep till I see it work :) [04:19] plars: haha, sorry :-) [04:19] also waiting for that here [04:19] heh, no worries. It will be worth it if I see this working [04:20] yeah [04:20] rsalveti: going to try to have flo up and running tomorrow too. I tried it manually with a device in the lab but the device isn't responding now. I suspect it needs some ack on the screen or something [04:20] it had android before, so not sure [04:20] basically the new recover wasn't flashing the boot partition, so it was still booting with the older kernel [04:20] I'll have to wait for rfowler to see what's on the screen tomorrow I guess [04:21] right, could be as well [04:21] rsalveti: ah, ok [04:21] well, would be good to at least see mako booting and start to run tests before I sleep [04:21] yeah [04:31] wonder why it's taking so long for an image to be published in system-image nowadays [04:31] 50 minutes already [04:31] should probably be done anytime soon, but stil [04:31] *still [04:31] yeah [04:39] rsalveti, how about now? [04:39] still waiting [04:40] :-) [04:44] still nothing, jezz [04:59] sergiusens: is there a ppa with ubuntu-device-flash for precise? [05:02] sergiusens: I would assume it becomes part of the regular phablet-tools at some point right? And are the other phablet-tools still applicable if used with ubuntu-device-flash? [05:16] plars, it's in ppa:phablet-team/tools [05:17] independent; tryying to avoid having a regular person that just installs to land a set of unneeded tools [05:17] could be a dep though [05:18] sergiusens: I don't see it available on precise, and I'm trying to run 'ubuntu-device-flash -bootstrap=true -channel=trusty-proposed' on trusty right now which seems to be doing nothing for about 15 min now [05:21] oh, I see... it no longer autodetects the device type? [05:22] still no 206 either :( [05:28] plars, bootstrap is with two '-' and is done from the bootloader (as stated in the help, man page and wiki) [05:30] sergiusens: I was just looking at running it with --help '-bootstrap=false: Bootstrap the system, do this from fastboot' where it only has 1 -, didn't look at the man yet [05:30] hmm, right; the two dashes isn't released yet [05:31] plars, are you doing that from the bootloader [05:31] ? [05:31] sergiusens: so I'm confused - is phablet-flash not expected to work at all and we'll need to do something with ubuntu-device-flash + adb + something else? to get back to where we were before? [05:31] sergiusens: I'm not, it seems to be downloading right now but hasn't gone farther yet [05:31] it seems import-images was commented out from cronjob =\, running it manually now [05:31] plars, I asked you guys to review two months ago [05:32] sent an email a month ago as well [05:32] sergiusens: I didn't see that, I found an email with no responses mentioning it in ubuntu-phone, but that was about it [05:32] plars, phablet-flash is deprecated [05:32] plars, was over irc (the review request) [05:33] plars, anyways, you just need to bootstrap once [05:33] sergiusens: I believe you, I just don't think I ever saw it [05:33] sergiusens: in the past we've always run phablet-flash in bootstrap mode, so I guess we don't want to do that now with this new tool? [05:33] plars, then you just need to ubuntu-device-flash --wipe --channel devel-proposed and that's it [05:33] I see [05:34] plars, bootstrap implies you can have no OS installed; a broken one or android and not need any requirement on the currently installed os [05:34] plars, the only difference is flashing recovery and booting into it [05:35] nothing else differs from that [05:36] sergiusens: the other phablet-tools for -{network|config|click-test-setup|etc} are expected to be compatible with this though, correct? [05:36] plars, correct [05:37] awesome [05:37] plars, those won't change [05:37] plars: do you know why http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/ is still stuck? [05:37] plars, keep in mind though that when we disable adb on default images I'm going to add one more switch to ubundu-device-flash to enable it while flashing [05:38] plars, but we are not there yet; so no worries [05:38] rsalveti: best guess, is because for some reason, the run ended prematurely [05:38] plars, if you are doing this in ci already, can you please add two dashes to the params? should work still [05:38] plars: hm, ok, can we resume it? [05:38] sergiusens: I'm just playing with it locally at this point [05:39] ack [05:39] rsalveti: no [05:39] 202 is the last 4.2.2 image we had, so that's why it would be useful to have the complete run for it [05:39] rsalveti: it's not paused - it's dead and other things tried to run since then, leaving that dashboard entry in a bad state [05:39] got it [05:39] rsalveti: but it was still trying to use phablet-flash too [05:39] rsalveti: we'll need to put some fixes for all this into the ci infrastructure before things are happy again it seems [05:40] right, that's broken for 203, 204 and 205 [05:40] but phablet-flash should hopefully be good again with 206 [05:40] importing as we speak [05:40] sergiusens: in the meantime, if we could get it in the ppa for precise, that would help a lot [05:40] plars, I thought it was? [05:40] sergiusens: doesn't seem to be, let me double-check [05:40] oh wait [05:41] crap I forgot this stupid box is on 13.04 [05:41] *sigh* [05:41] plars, source package is goget-ubuntu-touch [05:41] plars, oh, didn't do 13.04; that's EOL, right? [05:41] so, yes, our system attached to the phones is on 13.04 and needs to be updated [05:41] I could to buy you time though [05:42] sergiusens: thanks [05:42] plars, hmm, I can't bin copy to raring anymore from the ppa :-/ [05:43] hmm, ok [05:43] should be able to wget https://launchpad.net/~phablet-team/+archive/tools/+files/ubuntu-device-flash_0.2%2B14.04.20140117-0ubuntu1_amd64.deb [05:43] I see lucid, but no raring [05:44] wow [05:44] plars, let me try using the cli [05:45] even with ubuntu-device-flash locally, it seems to not boot [05:45] I guess 206 is needed no matter what tool we flash with? [05:45] yeah, wait for 206 [05:45] yeah [05:46] with -b, yeah [05:46] I was hopeful :) [05:46] plars, yeah, you need 206 [05:46] it works only when updating 202->206 with system-settings [05:46] we didn't notice this as unfortunately I had the right kernel before (because of the mwc image) [05:47] but at least the import-images job is actually running now [05:47] plars, can't copy; I get this from launchpad [05:47] raring is obsolete and will not accept new uploads. [05:47] guess stgraber removed that entry from cronjob when adding the new targets [05:47] raring is not supported anymore, right? [05:47] it isn't [05:48] sergiusens: I was able to install from the wget package - good enough for now. I'll see what we can do to get that box updated soon [05:48] rsalveti, but plars tells me some of our boxes are still on [05:48] maguro is still fine [05:48] raring you mean? [05:48] plars, yeah, you won't be getting updates for anything if you stay on raring [05:48] might be confusing stuff [05:48] rsalveti, raring [05:48] right [05:49] * sergiusens plans for an early wakeup and goes to bed [05:55] Yeah, I think I'm losing hope that we'll see 206 tonight [06:02] yeah, compressing them now [06:02] I'd guess at least more 10 minutes [06:04] ok, well it should kick off on it's own... going to come back and check on it in a bit [06:25] alright, finally done [06:41] well, at least locally I can confirm that I have a wlan0 device [06:41] with 206 [06:41] awesome [06:42] rsalveti: and I boot to the gui :) [06:42] \o/ [06:42] waiting a bit more to see how the ci run goes - want to see it at least get through the install [06:42] yeah [06:42] nothing at https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/ still [06:42] once that happens, it will be some time before we really see results roll in, and I know psivaa will be up soon [06:42] rsalveti: it's still installing [06:43] oh, great [06:43] image is downloaded, just flashing now [06:56] alright, both mako and flo are working just fine [06:56] time to get some sleep [06:57] later [07:00] yeah, other than a failed systemsettle on default, the tests seem to be up and running now [07:00] I'll work on flo in the morning, then on converting it all to run with the new tool [07:01] rfowler: when you get a chance tomorrow, could you poke flo-01 - if it's in too bad a shape, just try to get it as far as the bootloader and I should be able to fix it from there === mardy_ is now known as mardy [09:30] sil2100, hey there [09:32] Mirv: hey, welcome back! mind to come? [09:33] didrocks: oh, I'm in a wrong hangout url? [09:33] Mirv: should be === ev_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: - [09:47] ev_: we're seeing "Cannot add PPA: 'ppa:chris.gagnon/mir-demo-tester'." failures on CI any idea why? e.g. https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/586/console === ev_ is now known as ev [09:48] * ev looks [09:55] ev: also if you have time can you look at https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5472/console ? "Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/p/pygobject/python-gi_3.11.90-0ubuntu1_armhf.deb Could not resolve 'ports.ubuntu.com'" [10:03] alan_g: was this working previously? I'm wondering if it's because you only have packages built for trusty [10:07] sil2100, around? [10:07] ev: These started over the weekend [10:10] tvoss: hello, on a meeting still, will poke you in 30 minutes [10:10] sil2100, ack [10:26] ogra: G+ on 206 on mako works fine here [10:32] ok, then it likely is the high resolution that causes this [10:32] i guess G+ tries to use the desktop version on the flo [10:32] popey, btw, do you notice that webapps ate slightly to large on flo ? [10:33] or is that only me [10:33] * popey looks [10:33] (/me can scroll horizontally on myna of them ... it is like 1cm to wide) [10:33] *many [10:33] my flo is portrait [10:34] mine too [10:34] (teh default image is portrait ... missing the switch option inside unity8) [10:35] yes, getting browser not supported on flo [10:35] right [10:35] i get the same on the desktop when using the webapp btw [10:39] sil2100: i definitely see unity-system-compositor and pulseaudio on the top all the time [10:40] ogra: any idea what else could cause this app launch issue bug 1284025 [10:40] bug 1284025 in Ubuntu Music App "Music app 356 on mako image 206 doesn't play music launched from dash 1st time" [Undecided,New] https://launchpad.net/bugs/1284025 [10:40] popey, pulse ? [10:41] ooh, hang on [10:41] i may need to go back further to eliminate music as the culprit itself [10:41] we updaed from 329 to 350 on friday [10:41] * popey reverts to 329 [10:41] bug 1283818 [10:41] bug 1283818 in android (Ubuntu) "voice call not working properly after the first call" [Critical,Confirmed] https://launchpad.net/bugs/1283818 [10:41] i think this is a pulse issue too [10:42] (or an issue with the android HAL not providing the right bits) [10:42] interesting [10:42] can be linked, yeah [10:42] popey: mind testing on image 201, just in case? [10:43] or rather 202 even [10:43] yeah [10:43] which ? [10:43] which what? ;) [10:43] 201 or 202 [10:44] ah [10:44] 202, the latest before 4.4 :) [10:44] kk [10:44] thx! [10:44] i need to pop out to take cat to vet shortly [10:44] sure, it's not the biggest issue we have on worth anyway now :) [10:45] :D [10:45] world* [10:45] * didrocks is really worried about global system settle [10:45] nope, its music [10:45] revert to 329 works [10:45] * ogra blames Mir [10:45] ahah ;) [10:46] k [10:46] 329? :p [10:46] * didrocks is lost [10:46] one donw :) [10:46] didrocks, music-app [10:46] in image number [10:46] ah [10:46] ok, so music-app itself [10:46] popey: can you revert music-app in the store? [10:47] that would be one less :p [10:47] then, upstream can quietly work on a fix [10:47] lets see [10:48] there is a button which allows me to revert to previous [10:48] but dunno how many back it lets me go [10:48] revert to previous -> repeat -> revert to previous -> repeat :p [10:48] and i need to go 2 steps back [10:48] also, we need to ensure that in their testing story is going to cover this [10:49] well, i dunno if it lets me, and I dont want to revert once and be stuck on 350 [10:49] yeah [10:50] yeah [10:54] mhr3: hey, not sure if you saw but upstart-app-launch doesn't depend anymore on zeitgeist itself but zeitgeist-core, do you think that will have any impact? [10:54] * mhr3 checks [10:55] didrocks, nah, it's fine, zeitgeist is just a metapkg [10:56] mhr3: but python-zeitgeist [10:56] is removed now [10:56] from the imag [10:56] image* [10:56] as well as data-hub [10:56] yea, that's fine [10:56] http://people.canonical.com/~ogra/touch-image-stats/20140223.changes [10:56] mhr3: ^ [10:56] so looking at the topafter.log of the unity8 tests on the dashoard shows that neither pulse nor unity-system-compositor actually consume much resources [10:56] they both run ... but with 0.5 to 0.8 CPU load only ... [10:57] not a massive consumption [10:57] ogra: do we know why system settle is triggering then? [10:57] (as failure) [10:57] systemsettle expects 97.5 % ... the overall load is at ~95 [10:58] we surely eat more, but not massively [10:58] i think what we see with unity-system-compositor is the same we saw before ... [10:58] (we had minor systemsettle issues since nested was involved, remember ? ) [10:59] now it seems pulse added iteslf to the issue which makes it fail every time [10:59] ok [11:02] didrocks, image 199 http://ci.ubuntu.com/smokeng/trusty/touch/mako/199:20140221.1:20140115.1/6736/ubuntu_clock_app/808519/ [11:02] (clock app tests, settle_after failed) [11:02] this looks pretty much the same [11:02] just that it doesnt happen randomly but constantly now [11:03] Morning all [11:03] (system-compositor and pulse keep it up in this test) [11:04] ogra: yeah, so overall CPU usage is higher still [11:04] hey davmor2 [11:06] didrocks, right, but the two processes keeping it up have been there before, seems we just passed a threshold now (so that each of them eats 0.1 more or whatever) [11:10] aha [11:10] https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/79/artifact/clientlogs/friends_app/topafter.log/*view*/ [11:10] there i see pulse constantly eating 2.9% [11:10] towards the end [11:10] thats definitely more than it should [11:11] now if there was only a syslog to check ... :( [11:11] http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/friends_app/ doesnt have one [11:15] yeah [11:15] psivaa: can you provide us a syslog maybe? [11:15] didrocks: just a sec [11:15] pulse errors should be in there [11:17] ogra: I wonder if pulse doesn't act up even more due to the issue on first call [11:17] meaning, if the 2 issues are mixed up [11:18] well, does any test involve making an actual call ? [11:18] i.e. one wheer audio is really involved [11:18] ogra: I don't know if audio is really involved when the mock test for phoning is used [11:19] * ogra doubts it [11:20] didrocks: so tomorrow on I'll be joining the morning all today was a bit of a meh day slept in getting back into a really timezone :) === alan_g_ is now known as alan_g [11:20] do we have any "story" why those phablet-test-run failures happen on some APs, but not all? [11:21] asac, we are still looking at system-settle [11:21] most likely a pulse issue though [11:21] ogra: system settle? [11:21] yeah, the tests all go mad over it [11:21] ogra: those look greenish on most: http://ci.ubuntu.com/smokeng/trusty/touch/mako/201:20140222:20140115.1/6756/ubuntu_clock_app/ [11:21] asac, 201 ... old stuff [11:22] ic [11:22] * asac hits reload [11:22] you want to start looking from 202 on where android 4.4 took over the world [11:22] ogra: didrocks: http://pastebin.ubuntu.com/6986465/ for the syslog [11:22] ogra: 203 actually, no? [11:22] hope it does not break the browser [11:22] psivaa: let's see :) [11:22] didrocks, err, right === davmor2_ is now known as davmor2 [11:22] ogra: still see those phablet-test-run thingies on 202 [11:23] http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/mediaplayer_app/ [11:23] asac: yeah, not the first time there are those kind of issues [11:23] asac: paul told me he's rerunning and asking internally why there are those cases [11:23] (that was last week) [11:23] psivaa: ogra: no enough log spam to be convinced by pulseaudio [11:24] ic. 206 really is system settle infected [11:24] didrocks, look for rtkit-daemon ... thats part of pulse [11:24] asac: yeah [11:24] but seems the phablet-test-run went away [11:24] though i see a *ton* of NM spam as well [11:24] asac: see my email prep I pasted to you :) [11:25] ogra: NM is only at startup, though? [11:25] eb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! [11:25] Feb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers. [11:25] Feb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. [11:25] ogra: yeah, but see, it's only at every boot [11:25] then, nothing [11:26] well but there seems to be something fishy [11:26] hard to believe it's what creating a crazy pulseaduio running [11:26] yeah, but it's not like spamming every second? [11:26] i think what creates the crazyness are rather the rtkit bits [11:26] why would it have to spam every second [11:26] yeah [11:26] it is enough that pulse keeps busy [11:26] that one is a better lead [11:26] and +1 on NM [11:26] it's spamming every second as well [11:27] hmm [11:27] lots of apparmor DENIED's too [11:28] filemanager tries to open / [11:28] notes-app and filemanager [11:28] so yeah, can be another issue [11:28] ah, and there is another one [11:28] Feb 24 06:59:14 ubuntu-phablet kernel: [ 69.971310] type=1400 audit(1393225154.432:84): apparmor="DENIED" operation="open" parent=2851 profile="com.example.confined-basic_confined-basic_0.1" name="/dev/input/event0" pid=3516 comm="confined-basic" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [11:28] heh, yeah, definitely not related to pulse :) [11:28] but maybe that's the security tests? [11:29] Feb 24 07:04:30 ubuntu-phablet kernel: [ 385.889912] type=1400 audit(1393225470.349:187): apparmor="DENIED" operation="open" parent=2851 profile="com.example.confined-basic_confined-basic_0.1" name="/etc/issue" pid=9955 comm="confined-basic" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0 [11:29] yeah, clearly security ones [11:29] well, would be nice to know what PID 3516 actually was :P [11:29] ah, k [11:30] so, let's add to the basket notes-app and filemanager making nasty things on the list to get fixed :p [11:31] right, biut thats not the systemsettle issue [11:31] (most likely)# [11:31] com.example.confined-basic_confined-basic_0.1 is from no click app [11:31] I would be shocked if it was the case :p [11:31] it's most likely a security test [11:32] yeah, that's what we came to [11:32] so… [11:32] let's order [11:32] Feb 24 06:48:49 ubuntu-phablet rtkit-daemon[2148]: message repeated 4 times: [ Failed to make thread 2245 RT: Operation not permitted] [11:32] Feb 24 06:48:49 ubuntu-phablet rtkit-daemon[2148]: Failed to make thread 2260 RT: Operation not permitted [11:32] pulseaudio -> ftkit-daemon [11:32] and network-manager [11:32] seems the 2 that we need to look at [11:32] ogra, the problem with filemanager and terminal is that for some reason it's confined now [11:32] sil2100: with us? [11:32] they were supposed to be confined [11:32] alan_g and tsdgeos: I've filed tasks in Asana to track your issues. [11:32] sergiusens, yeah, they are most likely not the cause for our systemsettle issues [11:32] * sergiusens regrets handing keys over [11:33] didrocks: yes [11:33] sil2100: backloged, agreed with the diagnosis? [11:34] didrocks: those make sense, yes, should we poke upstream people regarding those? [11:35] sil2100: well, we don't have an official active maintainer for pulse [11:36] but yeah, for nm, it's cyphermox :) [11:36] Let's wake him up, YEAH! ;) [11:36] Just kidding [11:36] mup! ;) [11:36] do we know if diwic is still around? [11:36] /mup sms cyphermox "wake up" [11:36] :) [11:36] hehe [11:37] he is, but in other areas [11:37] ftkit? fischertechnik API :) https://github.com/CodaFi/FTKit [11:37] doing OEM stuff [11:37] asac, lol [11:37] asac, rtkit [11:37] I don't find him on IRC [11:37] ah [11:37] that makes more sense :) [11:37] he isnt regulary on freenode anymore i think [11:37] he's not anywhere I can find him :/ [11:37] ev: should i have got some kind of asana notification? [11:38] oops, adding you as a follower now [11:38] asac: do you kow of any other awesome pulseaudio god? [11:38] hm, he should normally be online [11:38] ev: thanks. FWIW I've now seen a "pass" this morning (followed by a "fail" - so it didn't just go away) https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/ [11:38] didrocks: TheMuso maybe? [11:38] He doesn't seem to have holidays as well [11:39] asac: he's in AU timezone, not sure that will help us fixing it/debugging it now [11:40] didrocks: let's try e-mailing David - maybe he'll see the e-mail and pop up then [11:40] and i doubt he does much phone/tablet stuff [11:40] ogra: yeah [11:40] sil2100: mind doing that, with the link to the pastebin? [11:40] didrocks: sure [11:40] thanks [11:41] didrocks, rsalveti is also looking into the calls thing with pulse ... he said he'd handle that as high prio on the ML [11:41] probably it is actually the same and saves our butt automatically :) [11:41] yeah, can be linked if there is a bad bandwidth between android <-> ubuntu through hybris [11:41] yeah [11:41] I hope os [11:41] so* [11:41] * ogra too [11:41] we still need to look at the nm one [11:42] well, NM is only reavily logging [11:42] then, only, when the system is a little lower, we can watch at actual test failures [11:42]