[00:05] <sergiusens> rsalveti, approved
[00:05] <sergiusens> cjohnston, wiki updated
[00:05] <rsalveti> sergiusens: great, thanks
[00:05] <cjohnston> thanks sergiusens
[00:05] <rsalveti> building tarball, then upload, then new image
[00:05] <cjohnston> mako-07 is back online
[00:07] <rsalveti> cjohnston: thanks!
[00:09] <cjohnston> 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] <rsalveti> cjohnston: should work with mako
[00:10] <cjohnston> ack
[00:10] <cjohnston> can someone file a bug against ubuntu-ci-services-itself with the need to switch please?
[00:11] <cjohnston> I'll test it again tonight, if it doesn't work, I'll look at getting it switched tonight
[01:21] <cjohnston> rsalveti: are you building a new image?
[01:59] <rsalveti> cjohnston: soon
[03:20] <plars> rsalveti, asac: Sorry, I've been away from home most of the weekend. Looking at it now
[03:37] <plars> ok, this doesn't bode well
[03:37] <plars> I'm trying it at home and not getting good results - I don't even get past the google boot screen
[03:37] <plars> rsalveti: is there something other than -b I need to pass to phablet-flash?
[03:38] <plars> rsalveti: 'phablet-flash ubuntu-system -b --channel trusty-proposed' is what I'm using and I'm getting 205
[03:39] <plars> rsalveti: I also don't see a wlan0 in ifconfig -a on my local mako, nor in the lab
[04:18] <rsalveti> plars: right, we fixed the issue already
[04:18] <rsalveti> plars: latest image should have the fix, and should be around in a few minutes
[04:18] <plars> rsalveti: ok, so this is a known problem and will be fixed in 206?
[04:18] <rsalveti> plars: yes
[04:18] <plars> rsalveti: awesome
[04:18] <rsalveti> cdimage part is done already
[04:19] <plars> rsalveti: argh, you have to tell me that at 10pm, now I can't sleep till I see it work :)
[04:19] <rsalveti> plars: haha, sorry :-)
[04:19] <rsalveti> also waiting for that here
[04:19] <plars> heh, no worries. It will be worth it if I see this working
[04:20] <rsalveti> yeah
[04:20] <plars> 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] <plars> it had android before, so not sure
[04:20] <rsalveti> basically the new recover wasn't flashing the boot partition, so it was still booting with the older kernel
[04:20] <plars> I'll have to wait for rfowler to see what's on the screen tomorrow I guess
[04:21] <rsalveti> right, could be as well
[04:21] <plars> rsalveti: ah, ok
[04:21] <plars> well, would be good to at least see mako booting and start to run tests before I sleep
[04:21] <rsalveti> yeah
[04:31] <rsalveti> wonder why it's taking so long for an image to be published in system-image nowadays
[04:31] <rsalveti> 50 minutes already
[04:31] <rsalveti> should probably be done anytime soon, but stil
[04:31] <rsalveti> *still
[04:31] <plars> yeah
[04:39] <sergiusens> rsalveti, how about now?
[04:39] <rsalveti> still waiting
[04:40] <sergiusens> :-)
[04:44] <rsalveti> still nothing, jezz
[04:59] <plars> sergiusens: is there a ppa with ubuntu-device-flash for precise?
[05:02] <plars> 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] <sergiusens> plars, it's in ppa:phablet-team/tools
[05:17] <sergiusens> independent; tryying to avoid having a regular person that just installs to land a set of unneeded tools
[05:17] <sergiusens> could be a dep though
[05:18] <plars> 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] <plars> oh, I see... it no longer autodetects the device type?
[05:22] <plars> still no 206 either :(
[05:28] <sergiusens> plars, bootstrap is with two '-' and is done from the bootloader (as stated in the help, man page and wiki)
[05:30] <plars> 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] <sergiusens> hmm, right; the two dashes isn't released yet
[05:31] <sergiusens> plars, are you doing that from the bootloader
[05:31] <sergiusens> ?
[05:31] <plars> 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] <plars> sergiusens: I'm not, it seems to be downloading right now but hasn't gone farther yet
[05:31] <rsalveti> it seems import-images was commented out from cronjob =\, running it manually now
[05:31] <sergiusens> plars, I asked you guys to review two months ago
[05:32] <sergiusens> sent an email a month ago as well
[05:32] <plars> 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] <sergiusens> plars, phablet-flash is deprecated
[05:32] <sergiusens> plars, was over irc (the review request)
[05:33] <sergiusens> plars, anyways, you just need to bootstrap once
[05:33] <plars> sergiusens: I believe you, I just don't think I ever saw it
[05:33] <plars> 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] <sergiusens> plars, then you just need to ubuntu-device-flash --wipe --channel devel-proposed and that's it
[05:33] <plars> I see
[05:34] <sergiusens> 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] <sergiusens> plars, the only difference is flashing recovery and booting into it
[05:35] <sergiusens> nothing else differs from that
[05:36] <plars> sergiusens: the other phablet-tools for -{network|config|click-test-setup|etc} are expected to be compatible with this though, correct?
[05:36] <sergiusens> plars, correct
[05:37] <plars> awesome
[05:37] <sergiusens> plars, those won't change
[05:37] <rsalveti> plars: do you know why http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/ is still stuck?
[05:37] <sergiusens> 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] <sergiusens> plars, but we are not there yet; so no worries
[05:38] <plars> rsalveti: best guess, is because for some reason, the run ended prematurely
[05:38] <sergiusens> plars, if you are doing this in ci already, can you please add two dashes to the params? should work still
[05:38] <rsalveti> plars: hm, ok, can we resume it?
[05:38] <plars> sergiusens: I'm just playing with it locally at this point
[05:39] <sergiusens> ack
[05:39] <plars> rsalveti: no
[05:39] <rsalveti> 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] <plars> 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] <rsalveti> got it
[05:39] <plars> rsalveti: but it was still trying to use phablet-flash too
[05:39] <plars> rsalveti: we'll need to put some fixes for all this into the ci infrastructure before things are happy again it seems
[05:40] <rsalveti> right, that's broken for 203, 204 and 205
[05:40] <rsalveti> but phablet-flash should hopefully be good again with 206
[05:40] <rsalveti> importing as we speak
[05:40] <plars> sergiusens: in the meantime, if we could get it in the ppa for precise, that would help a lot
[05:40] <sergiusens> plars, I thought it was?
[05:40] <plars> sergiusens: doesn't seem to be, let me double-check
[05:40] <plars> oh wait
[05:41] <plars> crap I forgot this stupid box is on  13.04
[05:41] <plars> *sigh*
[05:41] <sergiusens> plars, source package is goget-ubuntu-touch
[05:41] <sergiusens> plars, oh, didn't do 13.04; that's EOL, right?
[05:41] <plars> so, yes, our system attached to the phones is on 13.04 and needs to be updated
[05:41] <sergiusens> I could to buy you time though
[05:42] <plars> sergiusens: thanks
[05:42] <sergiusens> plars, hmm, I can't bin copy to raring anymore from the ppa :-/
[05:43] <plars> hmm, ok
[05:43] <sergiusens> 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] <sergiusens> I see lucid, but no raring
[05:44] <plars> wow
[05:44] <sergiusens> plars, let me try using the cli
[05:45] <plars> even with ubuntu-device-flash locally, it seems to not boot
[05:45] <plars> I guess 206 is needed no matter what tool we flash with?
[05:45] <rsalveti> yeah, wait for 206
[05:45] <plars> yeah
[05:46] <rsalveti> with -b, yeah
[05:46] <plars> I was hopeful :)
[05:46] <sergiusens> plars, yeah, you need 206
[05:46] <rsalveti> it works only when updating 202->206 with system-settings
[05:46] <rsalveti> we didn't notice this as unfortunately I had the right kernel before (because of the mwc image)
[05:47] <rsalveti> but at least the import-images job is actually running now
[05:47] <sergiusens> plars, can't copy; I get this from launchpad
[05:47] <sergiusens> raring is obsolete and will not accept new uploads.
[05:47] <rsalveti> guess stgraber removed that entry from cronjob when adding the new targets
[05:47] <rsalveti> raring is not supported anymore, right?
[05:47] <sergiusens> it isn't
[05:48] <plars> 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] <sergiusens> rsalveti, but plars tells me some of our boxes are still on
[05:48] <rsalveti> maguro is still fine
[05:48] <rsalveti> raring you mean?
[05:48] <sergiusens> plars, yeah, you won't be getting updates for anything if you stay on raring
[05:48] <rsalveti> might be confusing stuff
[05:48] <sergiusens> rsalveti, raring
[05:48] <rsalveti> right
[05:49]  * sergiusens plans for an early wakeup and goes to bed
[05:55] <plars> Yeah, I think I'm losing hope that we'll see 206 tonight
[06:02] <rsalveti> yeah, compressing them now
[06:02] <rsalveti> I'd guess at least more 10 minutes
[06:04] <plars> ok, well it should kick off on it's own... going to come back and check on it in a bit
[06:25] <rsalveti> alright, finally done
[06:41] <plars> well, at least locally I can confirm that I have a wlan0 device
[06:41] <plars> with 206
[06:41] <rsalveti> awesome
[06:42] <plars> rsalveti: and I boot to the gui :)
[06:42] <rsalveti> \o/
[06:42] <plars> waiting a bit more to see how the ci run goes - want to see it at least get through the install
[06:42] <rsalveti> yeah
[06:42] <rsalveti> nothing at https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/ still
[06:42] <plars> 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] <plars> rsalveti: it's still installing
[06:43] <rsalveti> oh, great
[06:43] <plars> image is downloaded, just flashing now
[06:56] <rsalveti> alright, both mako and flo are working just fine
[06:56] <rsalveti> time to get some sleep
[06:57] <rsalveti> later
[07:00] <plars> yeah, other than a failed systemsettle on default, the tests seem to be up and running now
[07:00] <plars> I'll work on flo in the morning, then on converting it all to run with the new tool
[07:01] <plars> 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
[09:30] <tvoss> sil2100, hey there
[09:32] <didrocks> Mirv: hey, welcome back! mind to come?
[09:33] <Mirv> didrocks: oh, I'm in a wrong hangout url?
[09:33] <didrocks> Mirv: should be
[09:47] <alan_g> 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
[09:48]  * ev looks
[09:55] <tsdgeos> 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] <ev> alan_g: was this working previously? I'm wondering if it's because you only have packages built for trusty
[10:07] <tvoss> sil2100, around?
[10:07] <alan_g> ev: These started over the weekend
[10:10] <sil2100> tvoss: hello, on a meeting still, will poke you in 30 minutes
[10:10] <tvoss> sil2100, ack
[10:26] <popey> ogra: G+ on 206 on mako works fine here
[10:32] <ogra> ok, then it likely is the high resolution that causes this
[10:32] <ogra> i guess G+ tries to use the desktop version on the flo
[10:32] <ogra> popey, btw, do you notice that webapps ate slightly to large on flo ?
[10:33] <ogra> or is that only me
[10:33]  * popey looks
[10:33] <ogra> (/me can scroll horizontally on myna of them ... it is like 1cm to wide)
[10:33] <ogra> *many
[10:33] <popey> my flo is portrait
[10:34] <ogra> mine too
[10:34] <ogra> (teh default image is portrait ... missing the switch option inside unity8)
[10:35] <popey> yes, getting browser not supported on flo
[10:35] <ogra> right
[10:35] <ogra> i get the same on the desktop when using the webapp btw
[10:39] <psivaa> sil2100: i definitely see unity-system-compositor and pulseaudio on the top all the time
[10:40] <popey> ogra: any idea what else could cause this app launch issue bug 1284025
[10:40] <ogra> popey, pulse ?
[10:41] <popey> ooh, hang on
[10:41] <popey> i may need to go back further to eliminate music as the culprit itself
[10:41] <popey> we updaed from 329 to 350 on friday
[10:41]  * popey reverts to 329
[10:41] <ogra> bug 1283818
[10:41] <ogra> i think this is a pulse issue too
[10:42] <ogra> (or an issue with the android HAL not providing the right bits)
[10:42] <popey> interesting
[10:42] <didrocks> can be linked, yeah
[10:42] <didrocks> popey: mind testing on image 201, just in case?
[10:43] <didrocks> or rather 202 even
[10:43] <popey> yeah
[10:43] <popey> which ?
[10:43] <didrocks> which what? ;)
[10:43] <popey> 201 or 202
[10:44] <didrocks> ah
[10:44] <didrocks> 202, the latest before 4.4 :)
[10:44] <popey> kk
[10:44] <didrocks> thx!
[10:44] <popey> i need to pop out to take cat to vet shortly
[10:44] <didrocks> sure, it's not the biggest issue we have on worth anyway now :)
[10:45] <popey> :D
[10:45] <didrocks> world*
[10:45]  * didrocks is really worried about global system settle
[10:45] <popey> nope, its music
[10:45] <popey> revert to 329 works
[10:45]  * ogra blames Mir 
[10:45] <didrocks> ahah ;)
[10:46] <ogra> k
[10:46] <didrocks> 329? :p
[10:46]  * didrocks is lost
[10:46] <ogra> one donw :)
[10:46] <ogra> didrocks, music-app
[10:46] <didrocks> in image number
[10:46] <didrocks> ah
[10:46] <didrocks> ok, so music-app itself
[10:46] <didrocks> popey: can you revert music-app in the store?
[10:47] <didrocks> that would be one less :p
[10:47] <didrocks> then, upstream can quietly work on a fix
[10:47] <popey> lets see
[10:48] <popey> there is a button which allows me to revert to previous
[10:48] <popey> but dunno how many back it lets me go
[10:48] <didrocks> revert to previous -> repeat -> revert to previous -> repeat :p
[10:48] <popey> and i need to go 2 steps back
[10:48] <didrocks> also, we need to ensure that in their testing story is going to cover this
[10:49] <popey> well, i dunno if it lets me, and I dont want to revert once and be stuck on 350
[10:49] <popey> yeah
[10:50] <didrocks> yeah
[10:54] <didrocks> 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] <mhr3> didrocks, nah, it's fine, zeitgeist is just a metapkg
[10:56] <didrocks> mhr3: but python-zeitgeist
[10:56] <didrocks> is removed now
[10:56] <didrocks> from the imag
[10:56] <didrocks> image*
[10:56] <didrocks> as well as data-hub
[10:56] <mhr3> yea, that's fine
[10:56] <didrocks> http://people.canonical.com/~ogra/touch-image-stats/20140223.changes
[10:56] <didrocks> mhr3: ^
[10:56] <ogra> 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] <ogra> they both run ... but with 0.5 to 0.8 CPU load only ...
[10:57] <ogra> not a massive consumption
[10:57] <didrocks> ogra: do we know why system settle is triggering then?
[10:57] <didrocks> (as failure)
[10:57] <ogra> systemsettle expects 97.5 % ... the overall load is at ~95
[10:58] <ogra> we surely eat more, but not massively
[10:58] <ogra> i think what we see with unity-system-compositor is the same we saw before ...
[10:58] <ogra> (we had minor systemsettle issues since nested was involved, remember ? )
[10:59] <ogra> now it seems pulse added iteslf to the issue which makes it fail every time
[10:59] <didrocks> ok
[11:02] <ogra> didrocks, image 199 http://ci.ubuntu.com/smokeng/trusty/touch/mako/199:20140221.1:20140115.1/6736/ubuntu_clock_app/808519/
[11:02] <ogra> (clock app tests, settle_after failed)
[11:02] <ogra> this looks pretty much the same
[11:02] <ogra> just that it doesnt happen randomly but constantly now
[11:03] <davmor2> Morning all
[11:03] <ogra> (system-compositor and pulse keep it up in this test)
[11:04] <didrocks> ogra: yeah, so overall CPU usage is higher still
[11:04] <didrocks> hey davmor2
[11:06] <ogra> 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] <ogra> aha
[11:10] <ogra> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/79/artifact/clientlogs/friends_app/topafter.log/*view*/
[11:10] <ogra> there i see pulse constantly eating 2.9%
[11:10] <ogra> towards the end
[11:10] <ogra> thats definitely more than it should
[11:11] <ogra> now if there was only a syslog to check ...  :(
[11:11] <ogra> http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/friends_app/ doesnt have one
[11:15] <didrocks> yeah
[11:15] <didrocks> psivaa: can you provide us a syslog maybe?
[11:15] <psivaa> didrocks: just a sec
[11:15] <ogra> pulse errors should be in there
[11:17] <didrocks> ogra: I wonder if pulse doesn't act up even more due to the issue on first call
[11:17] <didrocks> meaning, if the 2 issues are mixed up
[11:18] <ogra> well, does any test involve making an actual call ?
[11:18] <ogra> i.e. one wheer audio is really involved
[11:18] <didrocks> 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] <davmor2> 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 :)
[11:20] <asac> do we have any "story" why those phablet-test-run failures happen on some APs, but not all?
[11:21] <ogra> asac, we are still looking at system-settle
[11:21] <ogra> most likely a pulse issue though
[11:21] <asac> ogra: system settle?
[11:21] <ogra> yeah, the tests all go mad over it
[11:21] <asac> ogra: those look greenish on most: http://ci.ubuntu.com/smokeng/trusty/touch/mako/201:20140222:20140115.1/6756/ubuntu_clock_app/
[11:21] <ogra> asac, 201 ... old stuff
[11:22] <asac> ic
[11:22]  * asac hits reload
[11:22] <ogra> you want to start looking from 202 on where android 4.4 took over the world
[11:22] <psivaa> ogra: didrocks: http://pastebin.ubuntu.com/6986465/ for the syslog
[11:22] <didrocks> ogra: 203 actually, no?
[11:22] <psivaa> hope it does not break the browser
[11:22] <didrocks> psivaa: let's see :)
[11:22] <ogra> didrocks, err, right
[11:22] <asac> ogra: still see those phablet-test-run thingies on 202
[11:23] <asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/mediaplayer_app/
[11:23] <didrocks> asac: yeah, not the first time there are those kind of issues
[11:23] <didrocks> asac: paul told me he's rerunning and asking internally why there are those cases
[11:23] <didrocks> (that was last week)
[11:23] <didrocks> psivaa: ogra: no enough log spam to be convinced by pulseaudio
[11:24] <asac> ic. 206 really is system settle infected
[11:24] <ogra> didrocks, look for rtkit-daemon ... thats part of pulse
[11:24] <didrocks> asac: yeah
[11:24] <asac> but seems the phablet-test-run went away
[11:24] <ogra> though i see a *ton* of NM spam as well
[11:24] <didrocks> asac: see my email prep I pasted to you :)
[11:25] <didrocks> ogra: NM is only at startup, though?
[11:25] <ogra> 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] <ogra> 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] <ogra> 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] <didrocks> ogra: yeah, but see, it's only at every boot
[11:25] <didrocks> then, nothing
[11:26] <ogra> well but there seems to be something fishy
[11:26] <didrocks> hard to believe it's what creating a crazy pulseaduio running
[11:26] <didrocks> yeah, but it's not like spamming every second?
[11:26] <ogra> i think what creates the crazyness are rather the rtkit bits
[11:26] <ogra> why would it have to spam every second
[11:26] <didrocks> yeah
[11:26] <ogra> it is enough that pulse keeps busy
[11:26] <didrocks> that one is a better lead
[11:26] <didrocks> and +1 on NM
[11:26] <didrocks> it's spamming every second as well
[11:27] <ogra> hmm
[11:27] <ogra> lots of apparmor DENIED's too
[11:28] <ogra> filemanager tries to open /
[11:28] <didrocks> notes-app and filemanager
[11:28] <didrocks> so yeah, can be another issue
[11:28] <didrocks> ah, and there is another one
[11:28] <didrocks> 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] <ogra> heh, yeah, definitely not related to pulse :)
[11:28] <didrocks> but maybe that's the security tests?
[11:29] <didrocks> 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] <didrocks> yeah, clearly security ones
[11:29] <ogra> well, would be nice to know what PID 3516 actually was :P
[11:29] <ogra> ah, k
[11:30] <didrocks> so, let's add to the basket notes-app and filemanager making nasty things on the list to get fixed :p
[11:31] <ogra> right, biut thats not the systemsettle issue
[11:31] <ogra> (most likely)#
[11:31] <sergiusens> com.example.confined-basic_confined-basic_0.1 is from no click app
[11:31] <didrocks> I would be shocked if it was the case :p
[11:31] <sergiusens> it's most likely a security test
[11:32] <didrocks> yeah, that's what we came to
[11:32] <didrocks> so…
[11:32] <didrocks> let's order
[11:32] <ogra> 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] <ogra> Feb 24 06:48:49 ubuntu-phablet rtkit-daemon[2148]: Failed to make thread 2260 RT: Operation not permitted
[11:32] <didrocks> pulseaudio -> ftkit-daemon
[11:32] <didrocks> and network-manager
[11:32] <didrocks> seems the 2 that we need to look at
[11:32] <sergiusens> ogra, the problem with filemanager and terminal is that for some reason it's confined now
[11:32] <didrocks> sil2100: with us?
[11:32] <sergiusens> they were supposed to be confined
[11:32] <ev> alan_g and tsdgeos: I've filed tasks in Asana to track your issues.
[11:32] <ogra> sergiusens, yeah, they are most likely not the cause for our systemsettle issues
[11:32]  * sergiusens regrets handing keys over
[11:33] <sil2100> didrocks: yes
[11:33] <didrocks> sil2100: backloged, agreed with the diagnosis?
[11:34] <sil2100> didrocks: those make sense, yes, should we poke upstream people regarding those?
[11:35] <didrocks> sil2100: well, we don't have an official active maintainer for pulse
[11:36] <didrocks> but yeah, for nm, it's cyphermox :)
[11:36] <sil2100> Let's wake him up, YEAH! ;)
[11:36] <sil2100> Just kidding
[11:36] <didrocks> mup! ;)
[11:36] <didrocks> do we know if diwic is still around?
[11:36] <ogra> /mup sms cyphermox "wake up"
[11:36] <ogra> :)
[11:36] <didrocks> hehe
[11:37] <ogra> he is, but in other areas
[11:37] <asac> ftkit? fischertechnik API :) https://github.com/CodaFi/FTKit
[11:37] <ogra> doing OEM stuff
[11:37] <ogra> asac, lol
[11:37] <ogra> asac, rtkit
[11:37] <didrocks> I don't find him on IRC
[11:37] <didrocks> ah
[11:37] <asac> that makes more sense :)
[11:37] <ogra> he isnt regulary on freenode anymore i think
[11:37] <didrocks> he's not anywhere I can find him :/
[11:37] <tsdgeos> ev: should i have got some kind of asana notification?
[11:38] <ev> oops, adding you as a follower now
[11:38] <didrocks> asac: do you kow of any other awesome pulseaudio god?
[11:38] <sil2100> hm, he should normally be online
[11:38] <alan_g> 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] <asac> didrocks: TheMuso maybe?
[11:38] <sil2100> He doesn't seem to have holidays as well
[11:39] <didrocks> asac: he's in AU timezone, not sure that will help us fixing it/debugging it now
[11:40] <sil2100> didrocks: let's try e-mailing David - maybe he'll see the e-mail and pop up then
[11:40] <ogra> and i doubt he does much phone/tablet stuff
[11:40] <didrocks> ogra: yeah
[11:40] <didrocks> sil2100: mind doing that, with the link to the pastebin?
[11:40] <sil2100> didrocks: sure
[11:40] <didrocks> thanks
[11:41] <ogra> 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] <ogra> probably it is actually the same and saves our butt automatically :)
[11:41] <didrocks> yeah, can be linked if there is a bad bandwidth between android <-> ubuntu through hybris
[11:41] <didrocks> yeah
[11:41] <didrocks> I hope os
[11:41] <didrocks> so*
[11:41]  * ogra too
[11:41] <didrocks> we still need to look at the nm one
[11:42] <ogra> well, NM is only reavily logging
[11:42] <didrocks> then, only, when the system is a little lower, we can watch at actual test failures
[11:42] <ogra> *heavily
[11:42] <didrocks> yeah, maybe it impacts a little still though, even if it's not in top ps
[11:42] <ogra> not sure there is an actual issue apart from it filling the disk
[11:42] <didrocks> worth having a look I guess
[11:42] <didrocks> while we are at it :)
[11:42] <ogra> indeed
[11:43] <didrocks> ok, at least music-app -> reverted (thanks popey!)
[11:43] <ogra> yeah
[11:43] <ogra> one less
[11:43] <psivaa> didrocks: ogra: http://pastebin.ubuntu.com/6986534/ is the last bit of kern.log during a system settle run
[11:44] <psivaa> rings any bell?
[11:44] <ogra> psivaa, yep, just the general powermgmt noise and a bit of NM
[11:44] <didrocks> yeah
[11:44] <sil2100> psivaa: looks ok to me
[11:45] <ogra> do you see anything unusal above that ?
[11:45] <asac> sergiusens: do we have adding systemsettle as an option to phablet-test-run somewhere on our roadmap?
[11:45] <psivaa> let me check
[11:46] <sergiusens> asac, it wasn't requested; but I can; mandatory or optional with skip?
[11:46] <ogra> sergiusens, optional please
[11:46] <ogra> it eats a lot of time
[11:46] <ogra> well, an option to switch it off ... should be on by default i guess
[11:47] <sergiusens> ok
[11:49] <asac> sergiusens: kind of with a flag --pre-landing-run
[11:49] <asac> or something
[11:49] <asac> :)
[11:49] <asac> or indeed rather --quick
[11:51]  * ogra wonders if there is simply a permission issue with the android 4.4 udev rules and pulse 
[11:51] <sergiusens> ogra, the works once and not again?
[11:52] <sergiusens> for phone calls that is
[11:52] <ogra> sergiusens, the "pulse is constantly eating above 1% cpu since the switch"
[11:52] <ogra> i guess the two are related though
[11:52] <didrocks> ogra: not really, it was high as well before
[11:53] <ogra> didrocks, over 1% ?
[11:53] <psivaa> ogra: http://pastebin.ubuntu.com/6986572/ and the kernel log is roughly a repetition of http://pastebin.ubuntu.com/6986534/ during the systemsettle run
[11:53] <didrocks> ogra: sometimes, not contantly
[11:53] <didrocks> as the system settle after
[11:54] <ogra> didrocks, right, not it is constantly at least 1% and bumping up to 5% during systemsettle
[11:54] <didrocks> yeah
[11:54] <ogra> s/not/now/
[11:55] <ogra> and while ricardo added compltete udev rules for flo and hammerhead, the changes to the exoisting rules for existing devices were minor
[11:55] <ogra> for mako actually only one for the rotation detection
[11:55] <ogra>  * 70-mako.rules: changing default permission for msm_rotator, which is now
[11:55] <ogra>     used by 4.4.2
[11:56] <ogra> everything else stayed as is
[11:56] <didrocks> yeah, I already looked at this
[11:58] <ogra> my maguro doesnt look so bad on 206 btw ...
[11:58] <ogra> (not that it matters, it still uses the old android indeed)
[11:58] <didrocks> ahah :)
[11:58] <didrocks> ogra's looking at his maguro with a tear :)
[11:58] <ogra> not really
[11:59]  * ogra would like to replace maguro with hammerhead :P
[11:59] <didrocks> heh
[11:59] <didrocks> btw, really likes the music used for the mwc demos
[11:59] <didrocks> musics*
[12:00] <Laney> is it the free software song?
[12:01] <didrocks> I wonder, didn't look
[12:01] <didrocks> ah
[12:01] <didrocks> *the*
[12:01] <didrocks> oh no :)
[12:01] <didrocks> I told it IS nice ;)
[12:01] <didrocks> that wouldn't match with rms voice :p
[12:06] <Laney> :D
[12:06]  * popey hugs his RMS soundboard app
[12:07] <popey> http://popey.com/~alan/phablet/device-2014-02-06-171210.png
[12:07] <popey> sergiusens: see last comment on bug https://bugs.launchpad.net/music-app/+bug/1284025
[12:07] <didrocks> popey: is it you putting on Linux UNplugged "Get it out of here" :)
[12:07] <didrocks> or "Negative is the freedom dimension
[12:08] <didrocks> "
[12:08] <popey> i took those samples from LAS, yes
[12:08] <didrocks> ahah :)
[12:08] <didrocks> sergiusens: can you ensure this test case is part of upstream's manual test plan or that there is an integration test then?
[12:10] <sergiusens> didrocks, the RMS stuff?
[12:10] <didrocks> ahah, no :) the bug popey raised :)
[12:11] <sergiusens> didrocks, well it was tested before it landed!
[12:11] <didrocks> sergiusens: the first launch?
[12:11] <didrocks> (music doesn't play on first launch, reverting making it work)
[12:11] <popey> i have a fix in the works
[12:12] <sergiusens> didrocks, I don't think so
[12:12] <sergiusens> wrong item
[12:12] <didrocks> sergiusens: yeah, so we need to get that case added on the integration tests or as part of manual tests running while releasing
[12:15] <sergiusens> didrocks, ok, but I already have to write test plans for like 20 components; not sure I want to write the apps ones as well
[12:15]  * sergiusens delegates to balloons 
[12:15] <didrocks> sergiusens: I don't think you should be the one having to write those, ask upstream to help :)
[12:16] <didrocks> just if you can track those are part of the release test plan so that we don't regress the same way again
[12:16] <didrocks> (when they release the fixed version)
[12:17] <psivaa> didrocks: http://pastebin.ubuntu.com/6986667/ is the content of /var/log/lightdm/unity-system-compositor.log
[12:17] <psivaa> unity-system-compositor is also on the top most of the time. so curious if this shows anything
[12:17] <ogra> delegation is the first step into management :)
[12:18] <didrocks> psivaa: hum, yeah, I don't find anything really worrying in there, the unable to set active session does make sense on the destkop, not sure for touch tohugh
[12:18] <ogra> psivaa, but unity-system-compositor was there before and usually stays below 1%
[12:18] <didrocks> psivaa: we need to get some Mir guys on it
[12:18] <didrocks> psivaa: can you join #ubuntu-mir?
[12:18] <ogra> while pulse usually stays above 1%
[12:19] <ogra> and even bumps pretty high in spikes
[12:19] <psivaa> ogra: we are checking for 97.5 % idle time. so 1% is a lil high?
[12:19] <ogra> psivaa, yes, and we had random issues with that since unity-system-compositor is uesd
[12:19] <ogra> the pulse issue is new with andorid 4.4
[12:20] <psivaa> ogra: ack, i removed pulseaudio and settling still fails. so was wondering
[12:21] <didrocks> psivaa: removed?
[12:21] <ogra> bug 1279391
[12:21] <ogra> thats the bug for unity-system-compositor
[12:21] <psivaa> didrocks: apt-get remove pulseaudio  ( although i dint know how stupid the attempt is :D)
[12:21] <ogra> open since a while
[12:22] <ogra> psivaa, heh, that will surely make some things go mad
[12:22] <didrocks> psivaa: I guess you need to remove rtkit as well
[12:22] <didrocks> as it's the package containing the crazy process :)
[12:22] <didrocks> $ dpkg -S /usr/lib/rtkit/rtkit-daemon
[12:23] <didrocks> rtkit: /usr/lib/rtkit/rtkit-daemon
[12:23] <didrocks> psivaa: FYI ^
[12:23] <ogra> chmod -x :P
[12:23] <didrocks> you, evil guys! :)
[12:24] <psivaa> ogra: removing pulse dint cause a lot of issues, at least in weather app test
[12:24] <psivaa> didrocks: rtkit message was seen before as well and i checked with kernel team a couple of weeks ago and they said it was not changed for a long time
[12:25] <didrocks> psivaa: yeah, but maybe an interaction with 4.4?
[12:27] <psivaa> didrocks: http://ci.ubuntu.com/smokeng/trusty/touch/mako/172:20140209:20140115.1/6518/dialer_app/754252/ is with image 172 containing the similar message as the syslog for 206.
[12:28] <psivaa> but this time with android interaction this could cause settling issues
[12:28] <psivaa> i.e. in relation to rtkit
[12:29] <didrocks> psivaa: yeah, anyway, we need to get those messages fixed as it's always harder to read with those, wdyt?
[12:29] <ogra> didrocks, dont bother ... i will at some point kill all kernel logging
[12:29] <ogra> since it fills the disk
[12:30] <psivaa> didrocks: agreed. lots of warnings and it's hard to find the message that actually causes the issue
[12:30] <sil2100> didrocks: so, just in case, diwic is e-mail-reachable, so we can poke him to help us as well
[12:30] <didrocks> ogra: hem, issue "fixed"? :p
[12:30] <sil2100> didrocks: he's looking at it as well
[12:30] <didrocks> sil2100: oh, excellent! :)
[12:30] <ogra> didrocks, kind of :P
[12:30] <didrocks> sil2100: thanks man
[12:31] <ogra> didrocks, point is that we are doing way to excessive logging for end users
[12:31] <ogra> it eats your disk quickly
[12:31] <didrocks> ogra: yeah, but we need a way to still get those infos when things go wrong
[12:31] <didrocks> developer mode? :p
[12:31] <sil2100> ogra: if anything, we CC'd you as well, so if you have any useful pointers or info that I missed, just give diwic a sign ;)
[12:31] <ogra> didrocks, or dmesg ...
[12:31] <ogra> but thats a ring buffer that overwrites itself
[12:32] <didrocks> yeah
[12:33] <ogra> i was talking to apw about the excessive logging ... but i didnt get to provide him the needed logs yet
[12:34] <ogra> he wanted to look into it ... seems that it is mainly powermanagement android drivers that dont respect kernel log settings
[12:37] <didrocks> ah, yeah, more than possible :)
[12:38] <didrocks> ogra: sorry for the stupid question, but as we run on our own kernel, we do have a kernel version matching the one from android 4.4? What's the package containing our kernel?
[12:38] <ogra> linux-image-$arch
[12:38] <ogra> as usual
[12:38] <ogra> linux-image-mako for N4
[12:38] <ogra> or linux-image-$version-mako rather
[12:39] <ogra> (just search for mako on the -changes ML (or flo, maguro, manta)
[12:40] <didrocks> ogra: ah ok, and so, we choose a version of the kernel matching the android one for ABI compatibility, right?
[12:40] <ogra> the kernel source comes from android
[12:40] <ogra> we just package it
[12:40] <ogra> (and patch it for i.e. apparmor etc)
[12:41] <didrocks> ah ok, I thought we got our own ubuntu kernel running
[12:41] <didrocks> hence my "I was puzzled"
[12:41] <didrocks> thanks to have shed some lights ogra
[12:41] <ogra> no the android blobs expect the right kernel
[12:41] <ogra> so we need to use this one
[12:41] <didrocks> yeah, I was wondering how magical this was for us to use anothe kernel
[12:41] <didrocks> but ok, there is no magic :p
[12:57] <sil2100> I jump out to the vet for a moment (just for the periodical a shot), be back in a jiffy
[13:03] <dbarth> hi
[13:03] <dbarth> i had a question this morning: can i have 2 merge props, one being stacked on top of the other, in a silo config?
[13:03] <dbarth> or do they need to be all MPs targetting bzr trunks?
[13:06] <ralsina_> sil2100: can I get a reconfigure in silo 14? Added a branch in the spreadsheet
[13:07] <ralsina_> dbarth: I usually have stacked branches in the silo and it seems to work nicely as long as prereq brnches are set in the proposals
[13:07] <jdstrand_> didrocks, sergiusens: those are absolutely from the security tests
[13:08] <didrocks> jdstrand_: excellent, thanks for confirming
[13:08] <didrocks> dbarth: you need all targetting the same branch (this is a sanity check to ensure that some doesn't get in a raring branch and the rest in a trusty branch)
[13:08] <didrocks> and yeah, what ralsina_ told
[13:09] <dbarth> ok, clear, that should work then
[13:10] <dbarth> btw, the ci train spreadsheet is read-only for me this morning, is that normal?
[13:10] <didrocks> dbarth: shouldn't, did you try to refresh?
[13:10] <didrocks> ralsina_: done
[13:10] <ralsina_> didrocks: awesome, thanks
[13:10] <didrocks> yw
[13:10] <dbarth> ok works
[13:12] <xnox> didrocks: with click apps, commits into trunks are merged by humans, and then click packages are released elsehow?
[13:12] <xnox> didrocks: or who do i talk to about coreapp click releases?
[13:13] <psivaa> ogra: didrocks: i also noticed 'top' is taking more than 2.3%
[13:14] <didrocks> xnox: stgraber defined the procedure, so yeah, commits are done manually in trunk and then, we have a release in another branch
[13:14] <didrocks> psivaa: oh waow
[13:14] <psivaa> didrocks: yea, that's pretty persistent
[13:15] <psivaa> and while me running another top during the test run doubles it :)
[13:15] <xnox> didrocks: and debian/changelog? do i write useful things there for coreapps?
[13:15] <xnox> didrocks: or where can i read the "procedure" ?
[13:16] <didrocks> xnox: not sure if Stephane wrote the procedure anywhere
[13:16] <didrocks> ask him about it :)
[13:16] <didrocks> psivaa: indeed… nice catch!
[13:17] <didrocks> psivaa: so next stop… kernel guys?
[13:17] <psivaa> didrocks: yep, exactly what i was typing :)
[13:18] <ogra> xnox, popey and sergiusens usually handle the landing of core apps
[13:18] <didrocks> xnox: you are talking about click itself, right?
[13:18] <didrocks> not core apps
[13:19] <xnox> didrocks: no, i'm not talking about lp:click, i'm talking about e.g. lp:ubuntu-*-app
[13:19] <popey> depends which app
[13:19] <didrocks> xnox: ah ok, so sergiusens :)
[13:19] <xnox> popey: but do humans merge things into trunk? or is that "ci-train"/automerger managed stuff?
[13:19] <ogra> popey, messaging
[13:19] <popey> ah, not my department then
[13:20] <didrocks> xnox: there is no ci-train/automerger yet
[13:20] <ogra> i think messaging-app actually needs to go through bfillers team first
[13:20] <ogra> for the actual merge
[13:20] <didrocks> yeah, for those shipped in distro, it's different
[13:20] <didrocks> (as .debs)
[13:20] <ogra> the landing is then via sergiusens' scripts
[13:20] <ogra> didrocks, hmm, isnt is a click ?
[13:20]  * ogra thought it was
[13:21] <didrocks> ogra: it is, but it's duplicated as .debs and as click
[13:21] <popey> ii  messaging-app  0.1+14.04.20 armhf        messaging application for Ubuntu
[13:21]  * ogra checks 
[13:21] <ogra> yeah, same here
[13:21] <didrocks> right
[13:21] <didrocks> so deb and click
[13:21] <ogra> right
[13:21] <didrocks> I don't like having that, because it's not an easy mapping
[13:21] <ogra> i wonder why we do that
[13:21] <popey> not a click yet on device, or it would be in /usr/share/click/preinstalled
[13:21] <ogra> click should be fine
[13:21] <popey> (which it isnt)
[13:22] <didrocks> ogra: because until click run on the desktop, bill wants to be able to install them as .deb
[13:22] <ogra> k
[13:22] <ogra> up to him i guess
[13:29] <sergiusens> xnox, what do you want?
[13:29] <xnox> sergiusens: how are core-click-apps released? e.g. am I fine to merge things into trunk  (those that are ready to go)
[13:30] <xnox> sergiusens: and then something/somewhere/eventually will generate a new click et.al.
[13:30] <didrocks> ogra: do you know with session upstart if I can add some env variable with sudo start <env var=foo> <process>?
[13:30] <sergiusens> xnox, merge to trunk then there's this http://s-jenkins.ubuntu-ci:8080/view/click/ which builds them from trunk
[13:30] <sil2100> Back
[13:31] <xnox> sergiusens: excellent. and when do those end up on the image? cause e.g. calculator is out of date.
[13:31] <xnox> (and 219 is not on p.c.c./~u-a/click_packages)
[13:31] <sergiusens> xnox, it gets uploaded to the store by balloons or myself
[13:31] <ogra> didrocks, usc-wrapper
[13:32] <ogra> (thats a script)
[13:32] <xnox> sergiusens: oh, the store. ack.
[13:32] <didrocks> ogra: $ usc-wrapper
[13:32] <didrocks> -bash: usc-wrapper: command not found
[13:32] <sergiusens> xnox, yeah; the store; there's no general user id's but if you behave we can work out oauth credentials
[13:32] <sergiusens> :-)
[13:33] <xnox> sergiusens: hm... tempting. I'd rather just poke you and balloons to e.g.
[13:33] <xnox> sergiusens: balloons: please upload new calculator into the store =)
[13:33] <sergiusens> fginther, btw; are we going to have click testing on those click builds with a mako at least?
[13:34] <ogra> didrocks, /usr/share/ubuntu-touch-session/usc-wrapper
[13:34] <ogra> didrocks, though thats not the session ... thats actually system wide
[13:34] <didrocks> yeah
[13:35] <ogra> didrocks, for the session i'd take the unity8 upstart job
[13:35] <didrocks> and just add the env var here?
[13:35] <ogra> yeah
[13:35] <sil2100> ralsina_: reconfigure still needed?
[13:36] <ralsina_> sil2100: no, didrocks did it, thanks
[13:42] <Laney> sil2100: can you reconfigure silo 010 (line 13) for me please? I added a new branch
[13:43] <didrocks> ogra: ok, hacked the unity8 upstart job, seems to be the only way
[13:43] <ogra> there are other ways, but yeah, thats the best
[13:44] <didrocks> interesting, can't get unity8 to show off though
[13:44] <didrocks> let's reboot
[13:44] <xnox> didrocks: did i gather it correct, that messaging-app is, at the moment, under ci-train?
[13:44] <didrocks> xnox: yeah
[13:45] <xnox> didrocks: can i be trained as an add-hoc lander then? i'd like to be able to ci-train release, all the things i can commit to.
[13:46] <didrocks> xnox: check with asac if there are more slots, we are quite full in term of rampining up in term of capacity, but let's see what he thinks if we should have one more session
[13:46] <rsalveti> morning
[13:46] <didrocks> xnox: until then, you can use the messaging-app lander to add your request to their landing (they should do that themselves if you add a MP)
[13:46] <didrocks> hey rsalveti!
[13:47] <sil2100> Laney: sure
[13:47] <xnox> didrocks: and how do i find out who the landers are?
[13:47] <xnox> didrocks: cause it's been 20 days now, which in my head is the timeout to do direct dput into the archive.
[13:47] <didrocks> xnox: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
[13:47] <didrocks> xnox: well, ping on IRC the lander I guess :)
[13:48] <didrocks> where is your branch?
[13:49] <xnox> didrocks: none of the listed people work 24/7 all year around, it's a single point of failure, both timezone wise, and vacation/holiday/sprints/travel wise.
[13:49] <rsalveti> ogra: hm, a lot of settle_before
[13:49] <didrocks> xnox: you can use other landers, as it works well for now, they have backup
[13:49] <ogra> rsalveti, and after
[13:49] <didrocks> xnox: then, the landers are coordinating themselves
[13:49] <ogra> rsalveti, pulse seems CPU greedy
[13:49] <rsalveti> ogra: is pulse the bad guy here?
[13:49] <rsalveti> interesting
[13:49] <ogra> rsalveti, and i see some alsa pulse errors in syslog
[13:49] <xnox> didrocks: right, so which line is for messaging-app there? =)))))
[13:50] <didrocks> rsalveti: it was already quite high sometimes in the past
[13:50] <rsalveti> right
[13:50] <xnox> didrocks: i'm sorry but like i have no idea what team that's under or what e.g. OLS is.
[13:50] <didrocks> but it's even higher
[13:50] <ogra> rsalveti, also unity-system-compositor ... but that was bad since we switched to nested
[13:50] <xnox> didrocks: team apps i guess?
[13:50] <rsalveti> indeed
[13:50] <asac> right
[13:50] <asac> its not our fault if the lander doesnt land your stuff
[13:50] <asac> :)
[13:50] <ogra> and didnt degrade
[13:50] <didrocks> xnox: hum, did you ctrnl + F "messaging-app"?
[13:50] <Laney> sil2100: what's that failure about?
[13:50] <didrocks> xnox: in the link I pasted to you
[13:50]  * didrocks finds
[13:51] <xnox> didrocks: oh, it opened landers tab for me, due to 2fa auth
[13:51] <asac> we will ramp up more folks, once the current folks have settled and everything goes smoothly. i believe its a couple weeks until thats the case
[13:51] <didrocks> messaging-app bfiller Yes https://wiki.ubuntu.com/Process/Merges/Checklists/system-apps https://wiki.ubuntu.com/Process/Merges/TestPlan/messaging-app
[13:51] <Laney> is the rebuild going to rebuild all of the components?
[13:51] <didrocks> xnox: argh ;)
[13:51] <Laney> because I only added one new branch for u-s-s so the others should be fine
[13:51] <didrocks> Laney: you have an option for only rebuilding one source
[13:51] <Laney> cool
[13:51] <didrocks> (check in the build and tell me if it's not obvious)
[13:52] <Laney> PREPARE_ONLY?
[13:52] <didrocks> yep :)
[13:52] <Laney> the name isn't obvious but the description is alright
[13:52] <xnox> didrocks: i giggle at the requirements in light of my branch =)
[13:52] <didrocks> Laney: can be renamed, opened to any pointters
[13:53] <Laney> PACKAGES_TO_BUILD :-)
[13:53] <didrocks> Laney: it's only the MP
[13:53] <didrocks> not the sources
[13:53] <Laney> it says 'enter the source package names'
[13:53] <didrocks> so needs to be clear in the name we only prepare things ;)
[13:53] <sil2100> Laney: done ;)
[13:53] <didrocks> Laney: yeah, but it doesn't changes the "direct upload to ppa"
[13:54] <didrocks> PACKAGES_TO_BUILD can let you think that direct upload to ppa will be rebuilt, no?
[13:55] <Laney> it doesn't say anything about that currently either
[13:55] <Laney> unless you know what 'prepare' means?
[13:55] <didrocks> Laney: prepare is about preparing source packages from MPs
[13:56] <didrocks> Laney: just give me a name and a description and I can change that easily :)
[13:56] <didrocks> (I would rather use _REBUILD than _BUILD though)
[13:57] <Laney> do you error out if it's used the first time?
[13:57] <didrocks> yeah
[13:57] <Laney> ok
[13:58] <rsalveti> didrocks: ogra: we have some tests using audio as well
[13:58] <dbarth> sil2100: can i get a last reconfig on silo 005 please?
[13:58] <ogra> rsalveti, actual audio or fake stuff
[13:58] <rsalveti> ogra: these alsa messages are expected, also happen with 4.2.2
[13:58] <ogra> i.e. does something actually play/record
[13:59] <dbarth> line 1 of the spreadsheet
[13:59] <ogra> rsalveti, ok
[13:59] <Laney> Enter source package names separated by spaces. A new build will be submitted to this silo containing all merge proposals attached to this landing request. It is an error to specify a source package name that has no merge proposals listed here. (leave blank for all)
[13:59] <didrocks> rsalveti: diwic has been pinged FYI and looking as well
[13:59] <Laney> s/to this landing request/to this landing request for the given packages/
[13:59] <sil2100> dbarth: sure
[14:00] <didrocks> Laney: ok, and so PACKAGES_TO_REBUILD as the flag name?
[14:00] <Laney> if that works for you
[14:00] <didrocks> sure
[14:00] <didrocks> I need to change some error message though
[14:00] <didrocks> as I'm talking about "prepare"
[14:00] <Laney> in this case I think the packages could have been detected
[14:00] <Laney> u-s-s had a new MP added and none of the others changed
[14:00] <seb128> could somebody give me a silo for l28?
[14:00] <didrocks> Laney: well, explicit is always better than implicit
[14:01] <didrocks> Laney: happened a lot like "I click rebuild opssss"
[14:01] <sil2100> dbarth: could you modify the MP list to include only links to merge proposals? ;)
[14:01] <Laney> I don't know about that
[14:01] <Laney> you could get more explicit than this :P
[14:02] <didrocks> Laney: well, if you click "build" without any other parameter after one full build was successful, it will error out as well
[14:02] <didrocks> what kgunn saw btw
[14:02] <ogra> rsalveti, in the before logs i see ofono phonesim everywhere
[14:03] <Laney> okay, it's minor so I don't want to push it :-)
[14:03] <sil2100> dbarth: I see that there's one merge request that's targetting some other branch, not trunk
[14:03] <rsalveti> ogra: real audio
[14:03] <rsalveti> ogra: I was surprised when testing as it started to produce noises :-)
[14:03] <ogra> rsalveti, looking at image 196 it doesnt seem to show that often
[14:03] <ogra> haha
[14:04] <ogra> i never heard noises ... thats why i'm so surprised
[14:04] <rsalveti> psivaa: ogra: how can I easily reproduce the systemsettle test?
[14:04] <ogra> rsalveti, top -c -b -d 6 -n 5
[14:04] <ogra> run that ten times in a loop
[14:04] <sil2100> dbarth: all the merges should target trunk if they are to be released ;)
[14:04] <ogra> rsalveti, and take the average idle time out of it
[14:05] <ogra> hmm
[14:05] <ogra> not so easy to capture it
[14:05] <rsalveti> didrocks: where did you ping diwic?
[14:05] <sil2100> dbarth: you can either re-target it to trunk or take that branch and merge it manually to that target branch
[14:05] <ogra> rsalveti, per mail
[14:05] <ogra> rsalveti, sil2100 did with me on CC
[14:06] <rsalveti> oh, mind including me as well?
[14:06] <didrocks> rsalveti: sil2100 sent an email
[14:06] <Laney> sil2100: sorry, forgot to say thanks - thanks ;-)
[14:06] <ogra> rsalveti, top -c -b -d 6 -n 5 | grep id,
[14:06] <ogra> that works for me
[14:06] <rsalveti> alright, let me flash 206 from scratch again
[14:07] <dbarth> sil2100: ok, hang on
[14:07] <ogra> http://paste.ubuntu.com/6987137/
[14:07] <ogra> thats an idling flo
[14:07] <rsalveti> ogra: hm, not that good
[14:08] <rsalveti> how many seconds do we wait before getting that data?
[14:08] <ogra> (and btw i still cant reproduce the runlevel thing with lightdm here ... i trired on all devices)
[14:08] <rsalveti> sergiusens: would you mind taking a look at the camera issue as well?
[14:08] <ogra> not sure
[14:09] <ogra> rsalveti, i think psivaa or plars should know
[14:10] <didrocks> Laney: done, will be deployed next time we deploy code :) http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/517
[14:12] <sergiusens> rsalveti, the one photo freeze issue?
[14:12]  * sergiusens hopes it wasn't mako
[14:12] <ogra> what else :P
[14:12] <psivaa> rsalveti: so that's 6 seconds
[14:15] <sergiusens> ogra, mako is my personal device :)
[14:15] <sergiusens> ogra, if phone calls worked it would of been fine :-P
[14:15] <ogra> sergiusens, mine too, thats why i refuse to do any testing on it
[14:15] <ogra> it only runs promoted images
[14:16] <ogra> (well, i tested the bootspeed changes manually i have to admit)
[14:16] <rsalveti> sergiusens: well, I wasn't able to reproduce the phone call issue anymore, but will test more later today
[14:16]  * sergiusens flash 206 on mako
[14:16] <rsalveti> sergiusens: maybe check the autopilot failures with flo
[14:17] <rsalveti> sergiusens: the camera one
[14:17] <sergiusens> oh right
[14:17] <sergiusens> rsalveti, flo has the same issues?
[14:17] <sergiusens> rsalveti, I'll check click camera and autopilot
[14:17] <rsalveti> sergiusens: not same
[14:18] <seb128> hum
[14:18] <ogra> flo works fine
[14:18] <seb128> is there anyone giving silos today? ;-)
[14:18] <ogra> i just took ten pics in a row with each camersa
[14:18] <rsalveti> ogra: autopilot fails from time to time
[14:18]  * seb128 would like to get one for l28
[14:18] <ogra> rsalveti, ah, i thought freezes
[14:18] <seb128> I've another landing I want to do later than relies on that first to go through
[14:18]  * seb128 would like to get things rolling a bit
[14:20] <rsalveti> ogra: why do we have phonesim running all the time as well?
[14:20] <ogra> rsalveti, no idea
[14:21] <ogra> it should settle down after initializing the sim, no ?
[14:21] <rsalveti> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/85/artifact/clientlogs/friends_app/topafter.log/*view*/
[14:21] <rsalveti> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/85/artifact/clientlogs/friends_app/topbefore.log/*view*/
[14:21] <rsalveti> pulse is not even there
[14:21] <ogra> yeah, not in this one
[14:21] <rsalveti> but phonesim is going crazy
[14:21] <ogra> the ones we looked at during the meeting all showed pulse and u-s-c
[14:22]  * seb128 waves
[14:22] <ogra> but u-s-c was like that before
[14:22] <ogra> pulse wasnt
[14:22] <seb128> is there anyone reading me?
[14:22] <rsalveti> seb128: yes
[14:22] <plars> rsalveti: what are you looking for? time between running the test and systemsettle?
[14:22]  * ogra wonders what that noise between his lines is
[14:22] <ogra> :P
[14:22] <seb128> rsalveti, thanks
[14:22] <seb128> what do one has to do to get a silo here? ;-)
[14:22] <ogra> seb128, pompoms and miniskirt help ...
[14:22] <rsalveti> plars: just trying to understand what is causing the systemsettle test to fail
[14:23] <ogra> and waving your arms
[14:23]  * seb128 waves
[14:23]  * seb128 waves
[14:23]  * seb128 waves
[14:23] <ogra> lol
[14:23] <seb128> sorry but I'm getting annoyed
[14:23] <ogra> didrocks, ^^^
[14:23] <seb128> I've work to land and there is no way to get any traction
[14:23] <seb128> I'm close to just dput manually
[14:23] <ogra> give that frenchie a silo !
[14:23] <didrocks> ogra: isn't sil2100 giving silos now? :)
[14:23] <sil2100> Silo? Can I assign?
[14:23] <seb128> sil2100, yes please, l28
[14:24] <rsalveti> ogra: wonder if pulse is crashing now with 4.4.2
[14:24] <seb128> I've waited a few hours before starting nagging
[14:24] <seb128> but since things didn't seem to move...
[14:24] <seb128> sil2100, thanks
[14:24] <rsalveti> ogra: as it's not even around for friends-app
[14:24] <sil2100> Ok, so if didrocks gave me the blessing, let me assign
[14:24] <ogra> rsalveti, we checked syslog of one test that exposed it ... pulse wasnt restarting
[14:24] <rsalveti> crash would make it restart, and consume cpu
[14:24] <didrocks> sil2100: why wouldn't I give you the blessing?
[14:24] <rsalveti> ogra: but then why is it not even there for friends-app?
[14:25] <ogra> rsalveti, good question
[14:26] <plars> rsalveti: it actually looks like top is the big consumer from the logs, but iirc we somehow filtered that one out for the calculations. Even without it, it looks like there are a few other things eating up enough that the sum would push it over the edge perhaps. Looking at my local mako which I installed 206 on last night, it has pulseaudio holding a steady 2.6% of the cpu and has been idle since it first booted
[14:26] <ogra> plars, i still dont agree to that claim
[14:26] <ogra> (top being the big consumer)
[14:26] <rsalveti> ogra: also, it there a way to just promote 206 for flo? so we can have at least one image in trusty for it
[14:26] <ogra> top spikes to 36% like it did  before
[14:27] <ogra> two or three times in a run
[14:27] <rsalveti> plars: cool, will investigate pulse here
[14:27] <ogra> but is tame the rest of the time
[14:27] <ogra> rsalveti, i cant just promote an image ...
[14:27] <ogra> needs landing team approval
[14:27] <rsalveti> ogra: the udev files didn't change
[14:28] <ogra> i can bring it up in the landing meeting
[14:28] <ogra> rsalveti, yes, i was wondering if we are probably missing a change on mako or some such
[14:28] <rsalveti> ogra: sure, just because there's no CI for it still, and only in trusty-proposed
[14:28] <ogra> right
[14:28] <ogra> it looks fine for me in manual smoketesting
[14:28] <rsalveti> right, that's why my request :-)
[14:29] <didrocks> I think that makes sense
[14:29] <rsalveti> so people can flash at least 206, until we're able to promote a new one for it
[14:29] <dbarth> sil2100: landing-001 is good to go (publish)
[14:29] <ogra> they can ... when using the proposed channel
[14:29] <dbarth> sil2100: but still stuck with 005 for now
[14:29] <ogra> didrocks, so should i do a singlle promotion just for flo ?
[14:29] <rsalveti> ogra: right, but it'd just be better (mwc for example), for people to use trusty instead
[14:29] <ogra> (if you say it makes sense)
[14:29] <didrocks> sil2100: so, I saw that you assigned a silo, but you know it's because it's desktop-only, right?
[14:29] <didrocks> ogra: +1
[14:29] <rsalveti> and wait for a better update, instead of always getting trusty-proposed automatically
[14:30] <ogra> didrocks, rsalveti, promoting then
[14:30] <rsalveti> awesome, thanks
[14:31] <ogra> rsalveti, what about generic
[14:31] <ogra> could need promotion too i guess
[14:31] <ogra> same siatuation here
[14:31] <rsalveti> ogra: yeah, that would need as well indeed
[14:31] <ogra> let me do that one too then
[14:31] <rsalveti> is generic finally published there as well?
[14:31] <ogra> didrocks, ^^^^
[14:32] <ogra> rsalveti, stepahne added it yesterday
[14:32] <rsalveti> great
[14:32] <didrocks> ogra: sure :)
[14:32] <xnox> rsalveti: is generic -> x86 or armhf?
[14:32] <rsalveti> xnox: armhf
[14:32] <xnox> rsalveti: excellent!
[14:32] <rsalveti> generic_x86 would be x86 :-)
[14:32] <rsalveti> but still need the androideabi compiler
[14:32] <xnox> rsalveti: ack, thanks for letting me know.
[14:32] <sil2100> didrocks: righto, I'm not publishing anyway for now (maybe if it's desktop only, maybe then)
[14:32] <rsalveti> np :-)
[14:33] <xnox> rsalveti: yeah, i don't have it for you yet =) will get it done as soon as I can.
[14:33] <rsalveti> no worries
[14:33] <ogra> [14:33] <popey> oooh
[14:33] <sil2100> Damn, my girlfriends grandparents are here for a visit and they're successfully decreasing my productivity ;p
[14:34] <ogra> sil2100, give them ubuntu touch devices to play with :P
[14:34] <xnox> sil2100: by trolling behind your back?! =)
[14:34] <popey> s/play with/bug hunt/
[14:34] <ogra> (thats the secret plan)
[14:34] <ogra> :)
[14:35] <rsalveti> ogra: you're using 4.2.2 still, right?
[14:35] <ogra> rsalveti, on mako
[14:35] <rsalveti> ogra: how much is pulse consuming there in idle?
[14:35] <rsalveti> it's always ~1.0 here (4.4)
[14:35] <fginther> sergiusens, It can be done, but it wasn't on our list of projects
[14:35] <didrocks> rsalveti: yeah, that's what we saw
[14:36] <fginther> didrocks, is http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/ still be used?
[14:36] <sergiusens> fginther, but I asked you during the sprint :-)
[14:36] <ogra> rsalveti, not in toop at all
[14:36] <didrocks> fginther: as long as not everything is moved to CI train, yeah
[14:36]  * ogra does a fresh boot
[14:36] <rsalveti> ogra: right, but just check with ps
[14:36] <fginther> sergiusens, I misunderstood, this morning you're talking about the core apps, right?
[14:37] <sergiusens> fginther, talking about http://s-jenkins.ubuntu-ci:8080/view/click/
 psivaa-afk-bbl, ogra, ok this is accounted for by a change to what is reported in /proc/stat (which is consumed by top)
 aha
 basically when the machine is idle, cpus are turned off complely, in the previous kernel the offline cpus counted as 100% idle, now the do not
[14:37] <ogra> didrocks, psivaa-afk-bbl plars rsalveti ^^^
[14:37] <ogra> there we got our issue
[14:37] <rsalveti> oh
[14:38] <didrocks> oh
[14:38] <davmor2> rsalveti: phablet   1885  0.5  0.2  97840  4008 ?        S<l  14:17   0:06 pulseaudio --start --log-target=syslog  n4 with mwc image on which is 4.4.2 based I believe
[14:38] <didrocks> ogra: turned off completely, not downscaled though? (so why do we have random values?)
[14:39] <ogra> davmor2, mwc is 4.4
[14:39] <fginther> sergiusens, ah, I just misunderstood then. Yes, that click testing is in plan.
[14:39] <sergiusens> great
[14:39] <plars> ogra: so is that causing top to report values we can't necessarily trust for all processes then?
[14:39] <ogra> didrocks, because 100% is defined differently now
[14:39] <ogra> plars, well, the consumption should still be fine
[14:39] <ogra> plars, the idle value wont
[14:40] <sil2100> uh
[14:40] <didrocks> ogra: ah, so basically, we can have just one core up, and that will be our global rate
[14:40] <ogra> rsalveti, phablet   1446  1.0  0.2  99628  3896 ?        S<l  15:37   0:02 pulseaudio --start --log-target=syslog
[14:40] <dbarth> sil2100: and i have an extra reques with silo-013 being stuck (it didn't build the cordova-cli package)
[14:40] <ogra> lokskk fine to me
[14:41] <dbarth> sil2100: but getting silo-001 landed is still my priority right now
[14:41] <ogra> didrocks, well, idle isnt 4*100/100 anymore but the average idle time of the running CPUs
[14:41] <ogra> only measured while they were online
[14:41] <didrocks> ogra: yeah, I was telling the same thing :)
[14:41] <didrocks> ok, so basically we do have "no issue"
[14:41] <plars> I see
[14:41] <ogra> didrocks, we do
[14:42] <didrocks> hum, why?
[14:42] <ogra> our test is crap
[14:42] <didrocks> yeah
[14:42] <didrocks> but I meant no issue on the image
[14:42] <ogra> it should use /proc/stat ...
[14:42] <rsalveti> lol
[14:42] <didrocks> yeah
[14:42] <rsalveti> crap
[14:42] <ogra> (not top which eats resources itself)
[14:42] <ogra> and it would need to take the new setup into account
[14:42] <ogra> no idea how to every get that reliable though
[14:42] <didrocks> so
[14:42] <ogra> *ever
[14:43] <apw> ogra, ok we have confirmed between my antient image and colin's updated one that the stats behave different
[14:43] <ogra> apw, yeah, you guys rock
[14:43] <ogra> thanks so much !!!
[14:43] <rsalveti> yeah, thanks :-)
[14:43] <rsalveti> was already typing gdb -p `pidof pulseaudio`
[14:43] <didrocks> sil2100: plars: psivaa-afk-bbl: as the image is behaving as we expect, can you look at every AP test results and note here those which fails + look at them?
[14:43] <ogra> there were like ten people burning half a day on it already
[14:44] <didrocks> plars: also, it seems phablet-test-run didn't start on things like dialer-app, any idea why?
[14:44] <didrocks> asac: another occurence btw ^
[14:44] <ogra> didrocks, so lets have upstream fix the systemsettle test ...
[14:44] <ogra> asac, °
[14:44] <ogra> asac, !
[14:44] <didrocks> ogra: but some tests didn't run and we need to know what tests failed
[14:44] <didrocks> liek weather-app for instance :)
[14:45] <ogra> didrocks, right, i would like to get the dirt off the dashboard though
[14:45] <rsalveti> yeah
[14:45] <ogra> we should disable systemsettle for now
[14:45] <didrocks> ogra: let's try to work on both in parallel
[14:45] <ogra> so it doesnt taint results on next run
[14:45] <plars> didrocks: it looks like the unlocker failed before dialer_app
[14:45] <rsalveti> sil2100: didrocks: ogra: mind also replying back to diwic? (and including me as well)
[14:45] <didrocks> plars: anyway to have it reported differently?
[14:45] <ogra> rsalveti, yeah, will do ... he isnt around today anyway
[14:45] <ogra> not super urgent
[14:46] <didrocks> rsalveti: I'm not in that email, sil2100 didn't include me :/
[14:46] <didrocks> thanks ogra
[14:46] <ogra> only cool people were included :)
[14:46] <ogra> like sil2100 and me :)
[14:46] <didrocks> tsss :p
[14:46]  * asac tries to figure whats up
[14:46] <rsalveti> hahah
[14:46] <didrocks> plars: not sure what that "daily" test is as well
[14:46] <ogra> asac, systemsettle doesnt (cant) work anymore
[14:46] <ogra> asac, the stats changed ... idle isnt idle anymore
[14:47] <didrocks> unity8 has 5 failures though
[14:47] <plars> didrocks: yeah, something confused the dashboard with that one. Not sure yet - there's a *LOT* to look at this morning
[14:47] <asac> ogra: dont get it. what is idle?
[14:47] <didrocks> plars: ok, please us posted please :)
[14:47] <asac> if its not idle
[14:47] <plars> will do
[14:47] <rsalveti> asac: before it was idle with 4 cpus, now it's idle with only 1
[14:47] <ogra> asac, before all CPUs were on, so idle was 100%*4 ...
[14:48] <davmor2> ogra: try installing saidar
[14:48] <rsalveti> so the rate changed, yeah
[14:48] <ogra> asac, now with the new kernel cores get shot down
[14:48] <sil2100> ;p
[14:48] <ogra> asac, so there isnt a reliable 100% value anymore
[14:48] <sil2100> It was David who included ogra in the e-mail!
[14:48] <asac> ogra: kernel cores get shot down? when?
[14:48] <ogra> asac, you just get idle values from the other cores while they are running
[14:48] <rsalveti> asac: kernel itself is doing that
[14:48] <ogra> asac, all the time they are not in use
[14:49] <ogra> the kernel shuts them down dynamically
[14:49] <sil2100> Damn, finally some peace
[14:49] <rsalveti> let me manually run the unity8 tests
[14:50] <davmor2> ogra, rsalveti, didrocks: http://paste.ubuntu.com/6987322/
[14:50] <ogra> davmor2, another tool wont help the issue
[14:50] <ogra> the kernel interface wont report reliable 100% anymore
[14:51] <ogra> userspace tools only hook into that interface
[14:51] <rsalveti> still don't get why phonesim is consuming that much cpu
[14:51] <ogra> yeah
[14:51] <rsalveti> let me run the dialer-app tests
[14:51] <davmor2> ogra: ah sorry I just read the comment on top and switched off after that :)
[14:52] <asac> sounds like an odd story
[14:52] <ogra> rsalveti, note that for some tests there is a reboot ... you might see it not settled after rebooting in the ones where it is in top-before
[14:52] <rsalveti> ogra: oh, ok
[14:53] <ogra> asac, sounds perfectly valuable for the issue we see
[14:53] <asac> where is the systemsettle test?
[14:53] <asac> i mean the code :)
[14:53] <ogra> somewhere buried in UTAH ?
[14:53] <davmor2> ogra: did the new content handlers land? could it be that they are keeping the system from 100% idle?
[14:53] <ogra> you should know, you wrote it
[14:53] <asac> https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch
[14:53] <asac> ogra: it was taken and integrated somewhere
[14:53] <ogra> davmor2, then we would see them
[14:53] <asac> found it
[14:53] <asac> :L)
[14:53] <ogra> :)
[14:54] <plars> balloons: when you get a sec, could you help look at some of the ap failures and see if anything jumps out at you? I'm going to kick off one in just a moment where the unlocker just failed it seems, but some of these are just one or two ap test failures
[14:54] <ogra> asac, it should use /proc/stat directly anyway to not taint the results with top stuff
[14:55] <ogra> the prob is though that we cant rely on the idle value anymore ... no matter which interface we use
[14:55] <rsalveti> right
[14:55] <ogra> so we should measure the other way round i think
[14:55] <ogra> load above ... instead of idle above ...
[14:56] <rsalveti> hm, got a dialer-app crash as well
[14:56] <ogra> a .crash file you mean ?
[14:56] <rsalveti> bfiller: ^ is this known?
[14:56] <rsalveti> ogra: yes
[14:56] <ogra> we have that since months
[14:56] <ogra> known
[14:56] <rsalveti> alright then
[14:56] <ogra> the tests should pass though
[14:56] <rsalveti> oh, and the annoying mir freeze
[14:56] <bfiller> rsalveti: yup, mir bug
[14:57] <rsalveti> kgunn: we need to land the mir freeze fix in the archive as well asap
[14:57] <rsalveti> bfiller: got it
[14:57] <ogra> keep it :P
[14:57] <rsalveti> oh, unity8 crashed now
[14:57] <ogra> we dont want it
[14:58] <didrocks> rsalveti: yeah, some tests failed, I wonder if a crash or hang is the cause
[14:58] <rsalveti> that's why, freeze is just apport taking all the cpu
[14:58] <kgunn> rsalveti: dialer app crash is a bug in unity-mir that we are trying to land a fix for
[14:58] <ogra> sigh
[14:58] <ogra> apport
[14:58] <rsalveti> kgunn: not that one, it hangs from time to time when using it
[14:58] <rsalveti> let me get a trace for this guy
[14:59] <asac> so i dont get why we get 95% idle if the idle value isnt right anymore... sounds too close to be wrong. i can understand that the idle is a bit lower if we end up having just one core on though. is that what you try to say?
[14:59] <ogra> asac, no, before all cores were constantly on
[15:00] <ogra> asac, so idle was 4*100% / 4
[15:00] <ogra> asac, now it is 1 * 100% ... plus the random idle values of cores when they are up
[15:00] <ogra> you cant divide cleanly by four anymore
[15:01] <ogra> you would have to take the time they were online into account
[15:01] <rsalveti> yeah
[15:01] <rsalveti> another reason why top is not the right tool
[15:01] <ogra> well, we should just not measure idle but consumption
[15:02] <ogra> and not use top as it is a userspace process that consumes resources itself
[15:02] <rsalveti> ogra: oh!
[15:02] <ogra> (though even reading from /proc/stat will eat resources for the reading)
[15:02] <asac> you mean we should use absolute cycles consumed rather than a percentage
[15:02] <rsalveti> ogra: one reason pulse is waking up a lot more now
[15:02] <asac> consumption in percent probably woul dhave the same issue
[15:02] <rsalveti> ogra: it gets all the cpu on/off uevents
[15:03] <rsalveti> which is happening all the time now
[15:03] <asac> so what we could do is force off cpus during systemsettle
[15:03] <ogra> asac, no, the total of system, user and nice and set an upper threshold
[15:03] <ogra> rsalveti, awwww
[15:03] <ogra> asac, i.e. measure the actual consumption
[15:04] <ogra> instead of watching idle
[15:04] <rsalveti> right, idle is relative now
[15:04] <asac> i still believe it would have similar issues
[15:04] <asac> %Cpu(s): 2.6 us, 3.1 sy, 0.0 ni, 94.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st
[15:04] <asac> that sums up to 100
[15:04] <rsalveti> ogra: http://paste.ubuntu.com/6987394/
[15:05] <ogra> oh man
[15:05] <ogra> whatever we do, we need to kill the logging in any case !
[15:05] <ogra> (or is that debug mode)
[15:05] <rsalveti> ogra: the log is not there by default, I just added (debug mode)
[15:05] <rsalveti> just showing that pulse is getting every single cpu event
[15:05] <ogra> asac, yes, thats a snapshot
[15:06] <ogra> asac, we take 10*5 snaphots over a ceratin amount of time
[15:06] <rsalveti> ogra: and the battery ones as well
[15:06] <ogra> asac, that wont sum up to 100 anymore as cores come and go
[15:06] <asac> ogra: show me a sample where it doesnt sum up
[15:06] <asac> in the log
[15:06] <ogra> asac, dunno, its just logical, i dont need logs for that
[15:06] <asac> heh
[15:07] <asac> i dont think its logical.
[15:07] <asac> i can see how the percent values are having a variety
[15:07] <ogra> your 100% vary as the resources underneath vary
[15:07] <asac> based on how many cores are on and off
[15:07] <asac> but its still right
[15:07] <plars> as I understand it, an offline cpu is no longer considered idle (due to the fact that it's simply off, rather than doing nothing)
[15:07] <asac> sure
[15:07] <asac> but doesnt mean the idle is wrong :)
[15:07] <ogra> plars, right
[15:08] <ogra> the sum is
[15:08] <asac> it just gets magnified by factor 4
[15:08] <ogra> no
[15:08] <asac> in case of 1 cpu only
[15:08] <ogra> you cant mgnify by 4 if the 4 isnt a constant
[15:08] <plars> so yes, logically it makes no sense - an offline cpu is about as idle as you get. But for accounting purposes, it's not factored in
[15:08] <ogra> right
[15:08] <asac> ogra: well, its getting magnified between 1 and 4
[15:08] <asac> and we dont know what it is exactly
[15:09] <ogra> asac, yes, and the 100% between now and in 1min are completely different to the 100% beween in 5 min and 6min
[15:09] <ogra> the 100% dont change, the factor does though
[15:09] <asac> i undefrstand it, but still the usage will have the same issue :)
[15:09] <ogra> which will give you an unreliable value
[15:09] <asac> which is the only thing i am questioning
[15:10] <asac> i am not questioning that we get awful variance due to CPUs on and off right now
[15:10] <ogra> the usage of processes in sum will stay reliable
[15:10] <ogra> you have to rip out the CPU values here
[15:10] <rsalveti> ogra: something is waking up pulse all the time http://paste.ubuntu.com/6987416/, but it might just be because we're getting way more events now
[15:10] <ogra> and sum the processes
[15:10] <rsalveti> will check
[15:11] <ogra> rsalveti, can we perhaps switch off threading ?
[15:11] <ogra> so it sticks to the first core
[15:11] <ogra> i bet there is a config option
[15:11] <rsalveti> not sure if that is the issue, let me take a look first
[15:17] <apw> asac, it does mean idle is wrong, the idle stats for non-online cpus do not accumulate now as they did before
[15:17] <rsalveti> ogra: another issue I saw yesterday, is that it's taking way more time now to generate the system-images
[15:17] <rsalveti> ogra: maybe more channels caused that
[15:17] <rsalveti> ogra: ~1:20h
[15:17] <apw> what we need to do is count the idle as "100% busy - what_we_used" for each cpu
[15:17]  * didrocks goes for a run
[15:17] <ogra> rsalveti, woah ...
[15:17] <apw> which will be 100% idle for offline cpus
[15:17] <ogra> rsalveti, i noticed it was longer ... but not that much
[15:18] <didrocks> apw: right, we need an absolute value
[15:18] <rsalveti> ogra: yeah, so it's taking ~2h to get a new image published now :-(
[15:18] <apw> didrocks, i'll try and find a way to get the numbers you need
[15:18] <ogra> rsalveti, crap
[15:18] <didrocks> apw: thanks :) keep doanac` in touch I guess (for the UTAH side)
[15:18] <ogra> rsalveti, well, goldfish will be gone soon
[15:18] <asac> apw: right.
[15:19] <rsalveti> ogra: yeah
[15:19] <ogra> thats one down
[15:19] <asac> that was my plan
[15:19] <rsalveti> asac: oh, as you created this test I guess I can just blame you then :P
[15:20] <asac> blame?
[15:20] <asac> :)
[15:20] <rsalveti> hahah :-)
[15:20] <rsalveti> ogra: yeah, the current jack-detection logic is consuming quite a lot of cpu =\
[15:21] <rsalveti> ogra: it walks over all properties when it gets an uevent
[15:21] <rsalveti> looking for the SWITCH_STATE property
[15:22] <rsalveti> there's a call there to make udev just return events from the switch subsystem, but commented out
[15:25] <ogra> hmm, the jack detection is diwics work
[15:26]  * ogra remembers the patch 
[15:26]  * sil2100 remembers doing jack-detection for the old transformer
[15:26] <sil2100> Damn that was a hack
[15:26] <ogra> yep
[15:26] <sil2100> ;)
[15:27] <ogra> even the one that landed in pulse was one ... just less evil ... i remember diwic raving about it
[15:27] <rsalveti> yeah
[15:27] <asac> ogra: do you have a cat /proc/stat while the cpus are on and while off?
[15:28] <sergiusens> didrocks, row 1 col 1 in train says thum
[15:29] <ralsina_> dear CI train people (didrocks, sil2100, Mirv), can I get silo 14 landed?
[15:29] <plars> balloons: specifically on rssreader, I'm thinking maybe the name change affected the AP tests too? They don't seem to run at all
[15:30] <balloons> plars, I can't remember what we did with that :-) However, the test suite is shorts_app now
[15:30] <plars> balloons: ok, sounds like we'll need to change the name on our side then
[15:30] <ogra> asac, http://paste.ubuntu.com/6987526/
[15:30] <ogra> seems they are always listed
[15:31] <sil2100> ralsina_: did you set it to 'Tested: yes'? :)
[15:31] <ralsina_> sil2100: oops, doing it.... done
[15:31] <sil2100> ogra: do you know if we're still holding the line of package publication?
[15:31] <ogra> sil2100, dunno
[15:32] <asac> ogra: sure htat they are off while you cat them?
[15:32] <ogra> did we actually block at all ? everyone was so shocked by the test rresults, i dont remember discussion that
[15:32] <asac> ogra: can you cat twice with 4.4 and wait like 10 secs in between?
[15:32] <ogra> asac, the device is idling since 1h with screen off
[15:32] <ogra> i would expect them to be offline, yes
[15:32] <sil2100> ogra: I remember Didier mentioning in the morning on IRC that 'we're holding off releases'
[15:32] <sil2100> Let me re-confirm
[15:33] <ogra> asac, note that flo might behave different though ... thats mako vs flo
[15:34] <ogra> popey, do you have a recent install on mako ? and could you pastebin /proc/cpuinfo and /proc/stat ?
[15:34] <ogra> popey, of an idling device that is
[15:35] <plars> balloons, didrocks: So here's the current lits I have of failures (after rerunning dialer_app). I haven't tried rerunning some of the others, but I think psivaa-afk-bbl has, and I'd like to sync up with him about what he observed. Also, rssreader needs a name change on our side, which I'll take care of in just a bit, hopefully in time for 207
[15:36] <balloons> plars, fginther had done some work on this with my original bug: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1279643
[15:36] <popey> ogra: image 206 on mako, yes
[15:36] <plars> balloons: ack
[15:37] <balloons> I'm confused why all this happened I guess :-)
[15:37] <balloons> I guess only the builder was changed, not the runner on your end
[15:38] <fginther> balloons, I wasn't aware that the suite name was used anywhere else in the ci infrastructure
[15:38] <popey> ogra: http://paste.ubuntu.com/6987544/
[15:38] <ogra> asac, ^^
[15:39] <ogra> asac, so the stats keep the cores around even when offline it seems
[15:39] <balloons> no worries fginther.. we know now ;-)
[15:39] <sergiusens> fginther, changing the suite name is problematic; reason why I started adding an x-test thing so you can phablet-test-run the package and forget about what the module name was (and in the future, also not depend on autopilot at all if needed)
[15:39] <fginther> balloons, and so do I
[15:40] <ogra> popey, thanks !!
[15:40] <fginther> sergiusens, nice
[15:41] <asac> ogra: so forcing online/offline cpu is like this: http://paste.ubuntu.com/6987573/
[15:41] <asac> e.g. it disappears
[15:41] <ogra> yep
[15:41] <asac> on my intel machine
[15:41] <ogra> not sure it works on android kernels, but yeah, thats how it usually works
[15:41] <ogra> ask the kernel team :)
[15:42] <asac> apw: how does the android kernel behave in this respect?
[15:42] <asac> see a few lines above
[15:43] <ogra> asac, the thing is that you might interfere with some android userspace tool that handles this inside the container
[15:43] <dbarth> sil2100: did you see my request earlier about publishing silo-001? it's blocking us a bit for the appshowdown release
[15:43] <ogra> i.e. you might confuse it
[15:43] <asac> maybe path of least resistance is really to turn off all cpus but one for systemsettle
[15:43] <asac> that surely would make things easy to calibrate :)
[15:44] <ogra> definitelly
[15:44] <ogra> i just fear that we might confuse android
[15:44] <ogra> as long as we dont, that might be the way
[15:45] <ogra> asac, prob is that issues llike what rsalveti is seeing with pulse above will be completely hidden
[15:45] <sil2100> dbarth: hi! Yes, I saw that, but I don't know if we're clear to publish things now or not - want to clarify this with didrocks first
[15:45] <sil2100> asac: maybe you know - should we hold of landings for now or can I publish new packages?
[15:45] <dbarth> ok traffic jam, nw
[15:46] <asac> sil2100: would prefer to wait for didrocks
[15:46] <asac> sil2100: that preference might change depending on the specific landing case
[15:46] <asac> e.g. if its a firedrill landing etc. let me know
[15:49] <mhr3> sil2100, silo for 29 pls
[15:49] <mhr3> sil2100, do i prefer pinging everytime i need a silo, or is just adding the line enough?
[15:49] <mhr3> do you*?
[15:50] <sil2100> mhr3: I usually notice it, I didn't assign it due to the firedrill happening right now
[15:51] <mhr3> sil2100, it's been there for the past two hours though
[15:51] <mhr3> so ping it is :)
[15:52] <sil2100> mhr3: yes ;p I'll assign it once I have clearence if it's ok to assign one ;)
[15:58] <apw> asac, they are still there, but we don't actually care
[15:58] <apw> didrocks, asac, doanac`, ogra: this script seems to get the "right" version of idle on either kernel: http://people.canonical.com/~apw/misc/idle
[15:59]  * apw can see why you care how busy the enabled cpus are, ie why they made this change (which mainline has now as well), as it lets you know if you really need to bring one back
[16:02] <sergiusens> sil2100, can I get a silo for l32?
[16:03] <sil2100> One moment
[16:03] <asac> apw: cool. with this we somewhat loose ability to log the processes and what they consume (to investigate in logs whats going on in case we are not idle enough anymore).
[16:04] <apw> asac, well if you fail that check you can run the previous dump, as you know it is over
[16:05] <sil2100> What the... I see some spreadsheet problems, something new it seems
[16:05] <apw> and i'd say from what i am seeing that your idle has gone to hell
[16:05] <asac> hmm
[16:06] <ralsina_> sil2100: gentle reminder to land silo 14 unless landings are blocked?
[16:07] <ogra> asac, i think we should be good running top once after apw's test
[16:07] <ogra> to just get the hanging top consumer
[16:07] <sil2100> ralsina_: I remember about that - just still missing clarification if we can land
[16:07] <sil2100> Waiting for didrocks
[16:07] <ralsina_> sil2100: ah, ok
[16:07] <sil2100> But I'll resume silo assignments for 'safe' components
[16:07] <ralsina_> sil2100: no rush, to be honest :-)
[16:07] <asac> apw: could i just use a top with delay 5 instead of sleep to capture the process business?
[16:07] <ogra> it wont be as fine grained but we will at least get hanging procs
[16:08] <ogra> asac, that will bring top back into the equation
[16:08] <ogra> i would try to keep them distinct to get more accurate numbers
[16:08] <sil2100> robru, cyphermox: just so that you guys know - the spreadsheet seems to be awfully slow today, so assigning a silo can take some serious seconds to complete
[16:09] <cyphermox> aye
[16:10] <sil2100> mhr3, sergiusens: silos assigned for you guys
[16:10] <mhr3> sil2100thx
[16:28] <apw> asac, if you run anything in there you won't see if it is idle
[16:31] <asac> apw: any way we can do something similar like top that captures details on the pid's while we sleep?
[16:31] <asac> e.g. manually?
[16:31] <ogra> asac, any process you run there will taint the result
[16:32] <apw> ogra, who do i talk to to get this flashy thing to work, it is completly impossible to know what it is doing
[16:32] <apw> even worse than the previous versio
[16:32] <ogra> apw, did you read what was suggested in the other channel ?
[16:32] <ogra> apw, boot into bootloader mode and just run it again
[16:33] <asac> ogra: right, hence ii think something like capture the process stats before and after the two cat's
[16:34] <ogra> asac, i would do it after the test fails actually
[16:34] <ogra> and onyl then
[16:34] <ogra> if it settles file you dont need the info
[16:34] <ogra> if it doesnt, chances are good that the process still is in your top run right after the test
[16:35] <ogra> s/file/fine/
[16:37] <didrocks> sil2100: what's up?
[16:39] <sil2100> didrocks: hello! Can I land stuff to distro? As the system settle issue is 'somewhat' cleared, I guess the smoketesting results look pretty ok, right?
[16:39] <didrocks> sil2100: as told, until we have a list of everything that failed (we now have the system settle things out), we only publish desktop-things only
[16:40] <didrocks> sil2100: do we have the list of what's failing still?
[16:40] <didrocks> I saw paul mentionned this, if you can with him build up that list for the meeting
[16:40] <didrocks> so that we know where we stand
[16:41] <sil2100> didrocks: sure, I just browsed through it myself before and saw 2 failures - terminal app and clock
[16:41] <sil2100> didrocks: but I'll make sure with Paul
[16:41] <sil2100> plars: ping :)
[16:41] <plars> sil2100: on a call right now, but what's up?
[16:42] <sil2100> plars: do you have a list of real-test-failures for the latest image by any chance?
[16:42] <sil2100> (excluding the system settle ones)
[16:42] <plars> sil2100: somewhat - some of these have not yet been double-checked to see if they are flaky or consistently failing, but here's the list so far: http://paste.ubuntu.com/6987534/
[16:42] <didrocks> sil2100: how did you build the list, I see a lot of unity8 ones
[16:42] <rsalveti> ogra: plars: phonesim takes a while to settle down because NM tries to create a data connection with it
[16:43] <ogra> yeah
[16:43] <rsalveti> and it takes a few seconds for NM to give up
[16:43] <rsalveti> http://paste.ubuntu.com/6987869/
[16:43] <rsalveti> wonder if we really need to export the data call interface with phonesim
[16:45] <AlbertA> cihelp: how do I retrigger this jenkins build? http://s-jenkins.ubuntu-ci:8080/job/unity-mir-ci/258/rebuild
[16:46] <AlbertA> cihelp: I have vpn access and I can see that url, but I don't see a way of re-trigger the build after following the link
[16:46] <fginther> AlbertA, you need someone to provide you jenkins access, which we're trying to get away from now
[16:47] <fginther> AlbertA, generally, updating the MP will automatically trigger a rebuild. Is there a specific reason why this needs to be rebuild?
[16:49] <fginther> AlbertA, looking at the logs, this build failed because the testing didn't cleanup, has this been fixed? Or will a rebuild just have the same problem?
[16:53] <rsalveti> ogra: sergiusens: any idea why maliit-server is getting an input channel from pulse?
[16:53] <ogra> output i could understand
[16:53] <rsalveti> playback stream
[16:53] <sergiusens> rsalveti, audible feedback?
[16:53] <ogra> for the click sounds
[16:53] <sergiusens> bfiller, ^^
[16:53] <rsalveti> yeah, not input
[16:53] <ogra> ah
[16:53] <ogra> yeah
[16:53] <ogra> thats fine i think
[16:53] <ogra> you want to shorcut that to not get latency
[16:53] <rsalveti> http://paste.ubuntu.com/6987898/
[16:54] <rsalveti> right, because I know someone is also waking pulse quite frequently
[16:54] <rsalveti> from alsa
[16:54] <ogra> (which we have anyway ... i often lose clicks when typing fast)
[16:55] <rsalveti> ogra: was it maliit-server the one you removed 2 seconds of sleep?
[16:55] <didrocks> kgunn: bfiller do you mind coming to your landing meeting?
[16:55]  * sergiusens smells another revert
[16:55] <didrocks> I guess we'll need you :)
[16:56] <kgunn> didrocks: normally i would...but i'm in another meeting, i can't atm
[16:56] <didrocks> kgunn: an hour meeting?
[16:56] <didrocks> or 30 minutes?
[16:56] <kgunn> will end in 30
[16:56] <didrocks> kgunn: ok, can I catch up with you then?
[16:56] <ogra> rsalveti, yes, because the missing unity8 commit we added them for is long merged
[16:57] <rsalveti> yeah, just trying to understand if we could have any other unexpected side effect
[16:57] <rsalveti> didrocks: not much from my side, still investigating pulse
[16:57] <rsalveti> should have something later today
[16:58] <didrocks> rsalveti: ok, no worry, you are already aware :) FYI, I'm going to propose pairing people to help fixing all the failing tests we have
[16:58] <rsalveti> didrocks: great, thanks so much
[16:58] <didrocks> rsalveti: and slow down/stop touch landings which are not set to get things fixed
[16:58] <rsalveti> and sorry for the noise, at least I'm happy we got some results today
[16:58] <sergiusens> rsalveti, can you monkey press publish here? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=24
[16:58]  * sergiusens likes calling it monkey press
[16:59] <didrocks> rsalveti: no worry, we knew it was going to be painful :)
[16:59] <rsalveti> yeah
[16:59] <rsalveti> :-)
[16:59] <rsalveti> sergiusens: DONE
[17:00] <sergiusens> rsalveti, I notice I forgot to add your name change
[17:00] <sergiusens> rsalveti, I'll get another train in place
[17:01] <didrocks> cyphermox: joining?
[17:19] <popey> balloons: any idea what's going on here https://bugs.launchpad.net/autopilot/+bug/1283868
[17:20] <balloons> UnicodeEncodeError fun
[17:21] <ogra> rsalveti, cyphermox just pointed out that phonesim shouldnt be installed at all
[17:21] <ogra> rsalveti, and in fact it isnt
[17:21] <robru> popey, balloons: sounds like somebody wrote a test in python2 but ran it under python3. needs some porting
[17:21] <ogra> rsalveti, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140224/trusty-preinstalled-touch-armhf.manifest
[17:22] <ogra> rsalveti, seems one of your tests pulled it in, just uninstall
[17:22] <ogra> cyphermox, thanks !
[17:24] <cyphermox> phonesim is nice for testing but then I'd be really scared if it was running normally, since you couldn't know for sure which modem is being used for what, and I'm not just talking about NM
[17:24] <ogra> yeah
[17:24] <cyphermox> i.e. I don't want tests running and having any chance to do something with the real SIM, which is why I remove it
[17:24] <ogra> and it is in fact not preinstalled
[17:24] <cyphermox> but the other way around is posisble
[17:24] <ogra> i know ricardo did a dialer-app test run before
[17:25] <didrocks> ogra: cyphermox: we nede to have after the dialer-app are run, unininstall it
[17:25] <didrocks> need*
[17:25] <ogra> that has most likely pulled it in
[17:25] <cyphermox> yes
[17:25] <didrocks> otherwise, depending on when dialer-app tests are run
[17:25] <cyphermox> dialer-app tests indeed pull it in IIRC
[17:25] <didrocks> all the other tests are "polluted"
[17:25] <cyphermox> or you know, something else
[17:25] <ogra> right, or run dialer-app last at least
[17:25] <didrocks> remember the issue we had at some point?
[17:25] <cyphermox> shouldn't have to mess with the ordering of tests though
[17:25] <didrocks> ogra: yeah, I think most of tests should have a teardown()
[17:25] <didrocks> cyphermox: +1
[17:25] <didrocks> asac: doanac`: agreed? anyway we can get that? ^
[17:26] <ogra> cyphermox, no, but its a workaround worst case
[17:27] <doanac`> didrocks: sorry - what are you asking of me?
[17:27] <cyphermox> ogra: no, the right way to fix this is to fix the cleanup for the test that pulls it in
[17:28] <ogra> cyphermox, i know what the right way is ... but if people are to busy right now to fix it, reordering until they can fix tomorrow would help for today ;)
[17:28] <didrocks> doanac`: basically, is is possible to remove -autopilot (and all automatically installed packages) from one tests at the end before we go to the next suite?
[17:29] <doanac`> didrocks: it goes a little against how the code works now. we install the deps up-front, and then run the tests. we could do it, but its a little work
[17:29] <asac> didrocks: you say autopilot should provide setup/teardown infrastructure in the framework?
[17:30] <didrocks> doanac`: up-front, meaning for every tests?
[17:30] <asac> sounds reasonable thing to do. not sure if thomi agrees
[17:30] <doanac`> didrocks: up front, after provisioning and before we start running tests
[17:30] <asac> (sorry, on call, so might not know what this is about exactly - take my input with proper care)
[17:30] <didrocks> doanac`: is it new, it wasn't the case before
[17:30] <didrocks> doanac`: I remember at some point (like 3 month ago) we had a bug where we got ofono-simd installed
[17:31] <didrocks> and then, all tests were failing
[17:31] <didrocks> but ofono-simd was installed only when we reach teh dialer-app AP test
[17:31] <doanac`> didrocks: semi-new. we've done it this way since the start for click-packages. we recnetly started doing it this way for .deb autopilot tests also
[17:31] <didrocks> ah ok, so yeah, it changed
[17:31] <didrocks> doanac`: hum, we have an issue, it seems ofono-simd shouldn't be used while we are testing other stuff
[17:32] <didrocks> as mocks replace real functionalities that may be used somewhere else
[17:32] <doanac`> didrocks: okay, so we need to apt-get install, test, apt-get remove for each test now?
[17:32] <didrocks> doanac`: yeah, for each testsuite
[17:33] <doanac`> didrocks: ack. i'll file a bug. it might take a few days for me/plars to sort that out.
[17:33] <didrocks> doanac`: sure, system settle idling is way more important :)
[17:34] <plars> apw: so if I understand this correctly, it's giving percent cpu usage (user+nice+system+iowait) *100/numcpus after sleeping for 10 sec, correct?
[17:37] <doanac`> didrocks: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1284226
[17:38] <didrocks> doanac`: thanks :)
[17:44] <rsalveti> ogra: phonesim is installed when testing dialer-app
[17:44] <rsalveti> ogra: plars: can we remove a package after testing that app?
[17:45] <rsalveti> plars: also, is the package installed before running that test only or when setting up the image itself
[17:45] <ogra> rsalveti, to late ... doanac` is already on it ;)
[17:45] <rsalveti> like, don't know if it first install all the tests and so on or if this only happens when starting a test
[17:45] <ogra> (see backlog)
[17:46] <rsalveti> oh, sorry, got a split, backlog is not part of my default screen
[17:46] <ogra> ah
[17:46] <ogra> bug 1284226
[17:47] <rsalveti> didrocks: it's just that this also affects system-settle
[17:48] <rsalveti> didrocks: because at every reboot NM will try to create a data connection a few times (5 I guess)
[17:48] <rsalveti> causing other cpus to go up and down, and then also causing pulse to consume more
[17:48] <rsalveti> (which I'm currently investigating
[17:48] <rsalveti> )
[17:51] <ogra> rsalveti, right, we discussed that at the landing meeting
[17:51] <ogra> (which brought up that phonesim should never be installed)
[17:51] <rsalveti> right, cool
[17:55] <didrocks> rsalveti: oh, we didn't see it in the "top"
[17:56] <didrocks> but saw a lot of logs spew
[17:56] <didrocks> ok, so yeah, that can as well mean we'll need that at the same time
[17:56] <didrocks> (and a cherry on top)
[18:00] <ogra> didrocks, phonesim was in all top-before logs that happened after the dialer test
[18:01] <ogra> (but it was like that since ages already ....)
[18:01] <didrocks> yeah, but not nm?
[18:01] <plars> yes, I believe it would be installed at setup time, not right before the dialer test
[18:01] <plars> this isn't a new thing though
[18:01] <rsalveti> right
[18:02] <rsalveti> it's not, but it's also delaying the settle-down job
[18:03] <ogra> didrocks, just because we never lookec at NM debug output
[18:17] <didrocks> popey: hey, so, all AP tests run for you?
[18:17] <didrocks> for music-app
[18:17] <sil2100> hmmm
[18:17] <popey> yes
[18:17] <didrocks> (that would be good input for robru and balloons)
[18:17] <popey> Ran 12 tests in 436.767s
[18:17] <popey> OK
[18:17] <didrocks> ok
[18:18] <didrocks> I guess a lot of issues we see are similar to sil2100's ones
[18:19] <didrocks> ok, time to go this time, see you tomorrow guys, and good luck!
[18:23] <ogra> oh. lovely, beta freeze
[18:25] <rsalveti> ogra: argh
[18:25] <ogra> only until thu.
[18:25] <rsalveti> right, pulse is part of every image haha
[18:26] <rsalveti> ogra: so, pulse is behaving properly with the default image here
[18:26] <rsalveti> after I install phonesim and reboot, there's always someone waking it up every 2 seconds
[18:26] <ogra> 206 ?
[18:26] <rsalveti> ogra: yes
[18:26] <ogra> phew
[18:26] <ogra> k, so it is just phonesim
[18:27] <ogra> which will be fixed soon to be removed
[18:27] <rsalveti> well, need to find why we have someone waking pulse (via alsa)
[18:27] <rsalveti> wonder if it could be a race with maliit-server, rebooting and will see
[18:27] <ogra> i guess some phonesim mock thingie does that
[18:28] <ogra> i wouldnt bother if it only shows with phonesim
[18:28] <ogra> (though it will indeed taint the settle test of dialer-app)
[18:29] <rsalveti> there's a package called phonesim-autostart
[18:30] <rsalveti> maybe the test could start it itself?
[18:30] <ogra> does that get installed ?
[18:30] <rsalveti> ogra: yes
[18:30] <ogra> ask pitti
[18:30] <ogra> phonesim is his baby
[18:30] <apw> plars, / (HZ * numcpus)
[18:31] <plars> apw: ah, right
[18:31] <rsalveti> ogra: compare, normal image: http://paste.ubuntu.com/6990307/
[18:31] <plars> apw: but what comes out at the end is the idle % at the point it's measured, correct? (corrected for cpu scaling and quantity)
[18:32] <rsalveti> ogra: after installing phonesim: http://paste.ubuntu.com/6990345/
[18:32] <rsalveti> see the amount of times alsa is waking up pulse
[18:32] <ogra> yeah, crazy
[18:35] <apw> plars, yes
[18:36] <apw> basically we work on the premise that there are HZ*numcpus worth of ticks, the ticks which arn't useful ticks are idle ticks, and this works whether the cpu is updating or not
[18:38] <cyphermox> robru: ogra: rsalveti: the issues look very much like something that would get broken by a change from android 4.3 to 4.4... camera image is majorly messed up ;)
[18:38] <ogra> works fine on flo though
[18:38] <cyphermox> mako
[18:38] <rsalveti> cyphermox: what is the issue?
[18:38] <ogra> just take your flo with you for taking photos when going out with your mako
[18:38] <ogra> easy fix :P
[18:39] <cyphermox> the image in camera_app for what you're looking at is doing like an old TV -- like horizontal sync is broke
[18:39] <cyphermox> I don't have a flo
[18:39] <ogra> you need to get one
[18:39] <cyphermox> ;)
[18:39] <rsalveti> that's weird, always works fine here, but it might indeed behave differently
[18:39] <rsalveti> the camera hal sucks so bad
[18:50] <sergiusens> rsalveti, looking at that later today
[18:51] <rsalveti> thanks
[18:53] <ralsina_> ogra: can I get silo 14 reconfigured? Since landings are on hold I am using it for testing branches for MWC as they come.
[18:53] <ogra> ralsina_, i cant configure silos, sorry ...
[18:54] <ralsina_> ogra: ack, no problem
[18:54] <ogra> ralsina_, cyphermox or robru
[18:54] <sergiusens> doanac`, can you rebless this? https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608
[18:54] <ralsina_> ogra: I actually meant robru! Not my best day with names :-)
[18:54] <ogra> lol
[18:54] <ogra> yeah, easy to mix up :P
[18:56] <doanac`> sergiusens: done
[18:57] <sergiusens> doanac`, I'm going to get a landing slot for this and yours, mind giving it a go with ci workflow when the silo is built just in case?
[18:58] <doanac`> sergiusens: no problem. i'm headed to lunch now, but just ping when you are ready for me to give it a spin
[18:59] <sergiusens> great
[18:59] <sergiusens> robru, hey, can I get a silo for l31?
[19:01] <balloons> ping fginther
[19:06] <fginther> balloons, pong
[19:07] <robru> sergiusens, is that desktop-only?
[19:07] <balloons> fginther, it seems the filemanager click builder isn't building; http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/90/console
[19:07] <sergiusens> robru, yup
[19:07] <robru> ralsina_, I can reconfigure, are the MPs up to date in the spreadsheet?
[19:07] <robru> sergiusens, ok
[19:07] <sergiusens> robru, as in what it installs is for the desktop to interact with the devices :-)
[19:07] <ralsina_> robru: yes they are
[19:08] <robru> ralsina_, ok just a sec
[19:08] <fginther> balloons, looks like it needs to be update. I'll get started on that.
[19:08] <balloons> fginther, yea, I was going to say the same.. looks like it needs to be cmake :-)
[19:08] <robru> sergiusens, ok you got silo 3
[19:09] <sergiusens> thanks
[19:11] <robru> ralsina_, ok it's reconfigured
[19:11] <ralsina_> robru: awesome, thanks!
[19:11] <boiko> robru: heym I have this change on line 24 of the spreadsheet, it is tested already, but it needs the calendar-app click package to be updated in the image, should I mark it as Testing pass?
[19:12] <ralsina_> robru: something happened, I added two branches and they are gone now. I'll readd them :-(
[19:12] <balloons> fginther, just looking through the rest; not sure if rssreader builder has an issue or not; have a look http://s-jenkins.ubuntu-ci:8080/job/rssreader-app-click/106/console
[19:13] <ralsina_> robru: ugh, I don't know what happened, re-added them and now it has to be reconfigured again
[19:14] <robru> boiko, you can mark it testing pass, but under the comments please write "don't release this until calendar-app click package is updated"
[19:15] <robru> boiko, oh and maybe mention what version number is required so we can check whether it's safe to release then
[19:15] <boiko> robru: and what is the process to get the calendar-app updated?
[19:15] <robru> boiko, not sure, I guess it needs to get uploaded to the click store. i don't deal with that
[19:15] <robru> ralsina_, ok one sec
[19:15] <fginther> balloons, I can fix that one too
[19:15] <sergiusens> doanac`, when you get back; can you update your mr as xnox has a couple of updates on his?
[19:16] <robru> ralsina_, ok so just to confirm, these are the merges you want? http://paste.ubuntu.com/6990558/
[19:16] <doanac`> sergiusens: ack
[19:16] <ralsina_> robru: correct
[19:16] <sergiusens> doanac`, I wish launchpad noticed changes in its prereqs :-)
[19:17] <robru> ralsina_, ok, done.
[19:17] <boiko> robru: ok, thanks
[19:17] <robru> boiko, you're welcome
[19:17] <ralsina_> robru: thanks again!
[19:18] <fginther> balloons, http://s-jenkins.ubuntu-ci:8080/view/click/job/rssreader-app-click/107/
[19:18] <robru> ralsina_, no worries
[19:19] <fginther> balloons, http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/91/
[19:24] <cyphermox> robru: found anything meaningful in the tests?
[19:24] <robru> cyphermox, haven't been able to find anything meaningful... they just seem flaky. I run them and I get different failures than were originally reported, and on second run I get yet different failures. still looking for any kind of pattern
[19:25] <cyphermox> ah
[19:25] <cyphermox> so far I get the same failures reproducibly
[19:25] <doanac`> sergiusens: i just merged my branch with the latest for xnox, tested and pushed. it should be in good shape
[19:26] <sergiusens> doanac`, great; let me rebuild the silo then; thanks
[19:27] <robru> cyphermox, which tests?
[19:31] <asac> plars: do you know if we abandoned N10 testing? cant find them in the "all targets" dashboard anymore
[19:31] <cyphermox> camera_app and gallery_app so far
[19:33] <plars> asac: iirc that and n7 were abandoned a long time ago as the focus got placed on phones, with the later intent of bringing back n7 and n10 with the new 4.4 based images (with the newer devices of course)
[19:33] <asac> plars: ok cool. didnt know we turned those jobs off... thought they were still running, just not looked at
[19:33] <asac> but thats fine
[19:33] <asac> plars: how is enabling flo going?
[19:33] <plars> asac: I'm hoping to have flo up and running today or tomorrow, on n10 I hear it needs a newer device though, is that so? or is there only one variety of n10?
[19:33] <asac> newer?
[19:34] <asac> plars: never heard that we need a newer N10
[19:34] <asac> rsalveti: any idea?
[19:34]  * rsalveti reading
[19:34] <ogra> there is only one N10 model
[19:34] <plars> asac: there are two n7's, someone said that the n10 we support with the newer image is not the original n10 that came out
[19:34] <ogra> no worries
[19:34] <plars> ah good
[19:34] <plars> ok, so that's a relief
[19:34] <rsalveti> yeah, there's only one model
[19:34] <rsalveti> we're safe
[19:35] <rsalveti> just need to add them back
[19:35] <rsalveti> the problem with n10 is that 4.2.2 was half backed for it
[19:35] <rsalveti> (the original android image)
[19:36] <asac> plars: ^^
[19:36] <asac> just add them back and we are good to go
[19:36] <asac> rsalveti: half baked? you mean by google?>
[19:36]  * ogra doubts that ...we surely will have awful test results :P
[19:36] <plars> rsalveti: right, but we expect the new 4.4.2 ones to be better right?
[19:37] <ogra> flo has all my sympathies though
[19:37] <asac> ogra: syure, but thats fine. we dont have seen better results so it wont block promotion
[19:37] <cyphermox> robru: hrm... actually for gallery-app the results are pretty abysmal
[19:37] <cyphermox> just dbus errors for all of them
[19:38] <rsalveti> plars: asac: yes, by google, that's why 4.4.2 is so much better with it
[19:38] <rsalveti> and so is our newer image
[19:38] <ogra> ++
[19:38] <ogra> if the sidestage wouldnt be so odd, the N10 would be a wonderful device
[19:38] <ogra> with the new image
[19:39] <rsalveti> yeah
[19:39] <rsalveti> argh, ports is really slow for me today
[19:39] <ogra> (though i'm not as impressed with the display as i thought)
[19:39] <ogra> flo is a true beauty wrt display
[19:42] <boiko> robru: so, I talked to the calendar guys, latest revision is already in the click store, so we are fine to release the qtorganizer5-eds change
[19:44] <robru> boiko, ok, but does that change fix any of the current regressions?
[19:45] <boiko> robru: ah you mean if we need to release that for MWC? good question, maybe bfiller knows for sure
[19:46] <robru> boiko, no, I mean does this release of qtorganizer5-eds have any impact on fixing any of this mess? http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/
[19:46] <bfiller> robru: no this is unrelated to that new mess
[19:46] <boiko> robru: oh, probably not, wow, things are not looking good there
[19:46] <robru> boiko, no they aren't ;-)
[19:47] <robru> boiko, bfiller so I recommend holding off on the qtorganiser5-eds release until this is more under control
[19:47] <bfiller> boiko: is the lastest calendar app part of the preinstalled image?
[19:47] <boiko> bfiller: well, it is on the store, and according to sergiusens if it is there, it will be updated on the image
[19:47] <bfiller> boiko: ah ok
[19:47] <sergiusens> if it's in the store it will show up
[19:48] <bfiller> boiko: then just go ahead and mark testing as pass on the train after it's been tested
[19:48] <robru> boiko, but next image build isn't for another ~7 hours
[19:48] <boiko> robru: that's fine
[19:49] <robru> boiko, wait, what's the nature of the dependency here? does calendar-app require the new qtorganizer? or does qtorganizer require the new calendar-app?
[19:50] <boiko> robru: so, I think the old calendar-app does not work with the current qtorganizer-eds, but the current one does
[19:50] <boiko> robru: this new qtorganizer-eds fixes some stuff related to recurrent events
[19:51] <robru> boiko, ok so what I'm afraid of is in ~7 hours, we'll get a new image build, and it'll have the new calendar app, but it probably won't have the new qtorganizer, is that a bad state to be in?
[19:52] <boiko> robru: don't think so
[19:53] <boiko> robru: recurrent events was not supported/working properly before, so no regressions here
[19:53] <robru> boiko, ok thanks
[20:00] <balloons> fginther, ty for both click fixes
[20:03] <bfiller> rsalveti: cyphermox found an issue with camera-app that seems related to new Android
[20:03] <rsalveti> bfiller: which one? :-)
[20:03] <bfiller> rsalveti: explaing why some AP tests failing. if you tap the preview for the focus ring it hangs the app
[20:03] <bfiller> rsalveti: sometimes have to tap it a few times
[20:04] <bfiller> sometimes happens right away
[20:04] <rsalveti> right, might be the same hang it is happening when taking pictures
[20:05] <bfiller> rsalveti: can you take a look at it?
[20:05] <rsalveti> bfiller: sure, sergiusens is already planning on taking a look at that today, but we're working on it
[20:05] <sergiusens> bfiller, on my plate
[20:05] <bfiller> rsalveti: cool, thanks
[20:06] <bfiller> cyphermox saw this in log might be of help http://paste.ubuntu.com/6990774/
[20:15] <bfiller> sergiusens: https://bugs.launchpad.net/ubuntu/+source/camera-app/+bug/1284290
[20:17] <sergiusens> thanks
[20:26] <davmor2> hey ogra with the first 4.4 release does that mean that maguro bites the dust </queen_another_one_bites_the_dust>
[20:30] <rsalveti> davmor2: it's still working with latest image
[20:30] <rsalveti> userspace is compatible with both 4.2 and 4.4
[20:30] <rsalveti> we're just not updating the android image for it anymore
[20:31] <davmor2> rsalveti: stop with the maguro cpr already ;)
[20:33] <ogra> davmor2, maguro will be gone from testing tomorrow (or wed.)
[20:34] <davmor2> ogra: kill it, kill it with fire!!!!!
[20:34] <ogra> davmor2, thats plars job
[20:34] <ogra> he's got the flamthrower
[20:34] <davmor2> plars: ^ KILL IT, KILL IT WITH FIRE!!!!!!!!!!!!!
[20:35] <ogra> *flame
[20:35] <plars> it's being done, but I should point out the reason CI is still trying to test it is because we seem to still be building images for it
[20:36] <plars> http://system-image.ubuntu.com/trusty-proposed/maguro/
[20:36] <plars> ogra: who needs to kill that?
[20:36] <davmor2> plars: it isn't quite dead yet
[20:36] <rsalveti> yeah, the goal was to kill it once we get the x86 emulator
[20:37] <balloons> ping fginther
[20:38] <ogra> plars, it can go from the dashboard
[20:38] <ogra> in favour of flo
[20:38] <rsalveti> guess it's up to asac to decide that
[20:40] <ogra> we seriously dont want to block image promotion on it
[20:40] <plars> we haven't done that for a while now
[20:40] <ogra> so it should go ...
[20:40] <asac> true. you can move it to the "all targets" section until we have finished the transition
[20:40] <ogra> right
[20:40] <asac> (maguro that is)
[20:40] <ogra> keep the data around ... keep the tests runnign until emulator
[20:40] <plars> asac: but we still want to try to run it?
[20:40] <plars> asac: it doesn't seem to work in the latest image
[20:41] <ogra> plars, getting some low end info is surely good
[20:41] <ogra> oh ?
[20:41] <ogra> i'm on 206 just fine here
[20:41] <ogra> OTA though
[20:41] <fginther> balloons, pong
[20:42] <plars> ogra: I didn't look at it much because I thought it was expected to fail - actually I thought it was expected not to even build
[20:42] <plars> ah, the device is not present
[20:42] <plars> I can see what's up with that
[20:42] <ogra> plars, we just left the 4.2 files for it on cdimage
[20:42] <plars> ok, I'll add it back to the runs then, I was just working on removing that
[20:42] <balloons> fginther, I'm wondering if you can have a look at how reminders-app is being built for the ppa (debian packaging mind you). I don't see qtdeclarative5-evernote0.1 being built and it's needed
[20:42] <ogra> and userspace is compatible to both versions
[20:43] <asac> plars: it is expected to boot and work still... dont put too much time into it, but the golden way would be to have it running until we have transition finished and emulator is up
[20:43] <plars> asac: that's the plan
[20:44] <fginther> balloons, what branch (or where) does qtdeclarative5-evernote0.1 come from?
[20:45] <balloons> fginther, I'm feeling a little behind on it, but they did work to merge the plugin into lp:reminders-app, and you can see it now in debian/control
[20:51] <fginther> balloons, I see that the i386 upload is blocked dueo to a newer account-plugin-evernote already being in the ppa. This appears to be blocking all uploads from the i386 build which includes qtdeclarative5-evernote0.1
[20:51] <fginther> balloons, https://launchpadlibrarian.net/166772018/upload_5616694_log.txt
[20:52] <balloons> fginther, oO so if I bump the version and commit it should set everything free?
[20:52] <fginther> balloons, it should, but you'll need to bump it higher then 3-0~10~ubuntu13.10.1
[20:53] <balloons> weird version.. ok
[20:53] <balloons> ty for your help fginther
[20:54] <fginther> balloons, you're welcome, let me know how it goes
[21:03] <balloons> fginther, is there a way to reject what's sitting in the ppa now?
[21:03] <balloons> in other words, no way to kick out that build
[21:04] <fginther> balloons, it can be removed, but launchpad may keep the records around for week(s)
[21:04] <fginther> balloons, I can give it the boot
[21:07] <balloons> it's going to be a pain to mangle the versioning that much I think, so worth a try
[21:09] <cjwatson> You can't ever reuse the same version, but I believe if you delete it it should let you upload an older version after a short while
[21:09] <cjwatson> (I think)
[21:09] <balloons> fginther, is account-plugin-evernote also a high version? 3-0~9~ubuntu14.04.1 it seems?
[21:11] <fginther> balloons, yes, that's the trusty version, the saucy version is 3-0~10~ubuntu13.10.1
[21:11] <balloons> fginther, can you kick that out also?
[21:13] <fginther> balloons, I've deleted them
[21:14] <balloons> thanks.. seems like just the beginning of untangling this mess.. :-)
[21:15] <fginther> balloons, do you have the power to retry the build?
[21:16] <balloons> fginther, I don't believe I do.. If I do I don't know it
[21:17] <fginther> balloons, I'll give it a friendly kick then
[21:49] <robru> boiko, actually i've decided to publish silo 2 because it looks like it reduces some failures in the image. please merge & clean once it reaches distro
[21:51] <boiko> robru: ok, nice, thanks
[21:52] <fginther> balloons, the rebuild work, the update trusty binary packages are in the ppa. saucy rebuild is in progress
[21:54] <balloons> fginther, wonderful, let me see if the dependency issue is sorted now at least
[21:58] <balloons> fginther, worked splendidly
[22:04] <fginther> balloons, nice
[22:07] <plars> maguro is running fine now: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/206:20140224:20140115.1/6811/
[22:15] <sergiusens> balloons, are you good with the update to calendar?
[22:18] <balloons> sergiusens, updates to calendar? the trunk version landing in store or ?
[22:18] <sergiusens> balloons, yeah that
[22:18] <balloons> sergiusens, rsalveti think we can land this? https://code.launchpad.net/~sergiusens/phablet-tools/buddy-x/+merge/206587
[22:18] <sergiusens> balloons, yes we can
[22:19] <balloons> sergiusens, yea, I've no reason not to be.. the EDS fix in the silo atm will solve the known bugs
[22:19] <balloons> btw sergiusens congrats on upload rights for lots of fun things
[22:20] <sergiusens> thanks, delayed that for too long :-)
[22:23] <balloons> sergiusens, I linked the bug to your MP as well
[22:23] <sergiusens> awesome
[22:31] <boiko> robru: in silo landing-002 the "Merge and clean" cell is showing as #N/A
[22:31] <robru> uh
[22:32] <robru> boiko, shows for me: http://162.213.34.102/job/landing-002-3-merge-clean/build?delay=0sec
[22:32] <boiko> robru: but the link is still correct it seems though
[22:32] <boiko> robru: reloading the document did the trick, not sure why the image was not showing up
[22:33] <robru> it's been glitchy lately i guess
[22:40] <sergiusens> balloons, just pushed a small improvement to that MR, can you take a look; would need a happrove as well
[22:40] <sergiusens> rsalveti, mind doing that review? https://code.launchpad.net/~sergiusens/phablet-tools/buddy-x/+merge/206587
[22:53] <sergiusens> robru, gotta love muting the music tests
[23:26] <sergiusens> fginther, hey, I'm having an issue with https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5497/ ;  and the otto counterpart; these tests pass locally on my device
[23:26] <sergiusens> the issue is, not sure what is failing there
[23:27] <fginther> sergiusens, I can take a quick look now
[23:29] <sergiusens> thanks
[23:39] <fginther> sergiusens, I don't know... The same 5 TestHud failures are on both the otto and mako tests. The Mako has extra failures due to unity8 crashing
[23:41] <fginther> sergiusens, I took a closer look at the packages installed for the otto tests and there are no differences between this test and one from a few builds ago that didn't show these failures
[23:41] <sergiusens> darn
[23:42] <fginther> sergiusens, the last unity8 MP to merge from from 2 days ago, was your MP older than that?
[23:43] <sergiusens> yes
[23:43] <dobey> fginther: if you could get a chance to take a look at https://code.launchpad.net/~dobey/tarmac/merge-specific/+merge/208037 that would be great. it adds the feature of passing a specific MP to merge.
[23:43] <sergiusens> fginther, my mp is 2 weeks old probably
[23:43] <sergiusens> fginther, I took it over from bfiller
[23:43] <fginther> sergiusens, by any chance did you merge to trunk before testing?
[23:44] <sergiusens> fginther, no; I was going to but then thought that this was done in jenkins anyways, right?
[23:44] <fginther> sergiusens, right it's done by jenkins, might explain why jenkins show the failures but you don't see them
[23:44] <sergiusens> ah you mean locally; well I tested using the output.zip from jenkins
[23:44] <fginther> oh
[23:44] <sergiusens> fginther, ^
[23:44] <sergiusens> so it is quite the same
[23:45] <sergiusens> and read what otto did for setup and replicated
[23:45] <fginther> sergiusens, I triggered a rebuild to get some more info
[23:45] <sergiusens> fginther, with more debug info?
[23:46] <fginther> dobey, I'll add it to the list of tasks, I'll try to get to it in a a day or two
[23:46] <fginther> sergiusens, no just another data point, same test run
[23:48] <fginther> sergiusens, I need to drop off, I might be able to take a look later, otherwise it will be tomorrow.
[23:51] <sergiusens> ok
[23:55] <dobey> fginther: cool, thanks