[00:13] <mandel> barry, have we had any feedback from the testing?
[00:31] <barry> mandel: a little, not much
[00:33] <mandel> barry, bad, good?
[00:33] <mandel> barry, we need to move that silo because it blocks other possible landings, we can only have one project per silo...
[00:33] <barry> mandel: good, but Laney found a ui bug, which he's pushing a fix to.  now i'm just struggling with the normal dbus hup build failures
[00:34] <barry> infinity: is toyol a virtualized buildd?
[00:34] <infinity> barry: No.
[00:35] <barry> infinity: then crap
[00:35] <infinity> barry: It's not crap either. :P
[00:35] <barry> infinity: then dang
[00:35] <sergiusens> at least not dung
[00:36] <mandel> barry, ok, if there is anything I can help just ping
[00:36] <barry> mandel: cool, thanks
[00:43] <mandel> barry, I'll be around for a little longer
[00:44] <barry> mandel: sounds good.  i think we're waiting on Laney and my ppa build atm
[02:28] <barry> ralsina_: any chance you're still around?
[03:04] <basketballllll> Does anyone here work for cononical
[04:58] <liam-kelly> I have been following the porting guide and I am having some trouble with the breakfast command finding me device.
[05:56] <liam-kelly> Is this the correct place to ask questions about porting ubuntu touch?
[06:01] <RAOF> liam-kelly: Yes; xda is also appropriate, I think.
[06:02] <RAOF> I'm not sure how many porting-knowledgeable people there are online at the moment.
[06:05] <liam-kelly> On that subject is there a better time of day to ask porting questions here?
[06:11] <RAOF> I don't know, sorry.
[06:12] <RAOF> But just ask your question; if there's anybody here who can answer it, they might :)
[06:12] <RAOF> And hang around; when people come online they might scan backscroll for questions they can answer.
[07:13] <diwic> good morning
[08:25] <dholbach> good morning
[08:37] <Saviq> tvoss, hey, q: any experience in debugging android-side crashes?
[08:37] <Saviq> like where to get symbols and such :?
[09:26] <Laney> can I switch channel but not update to it right away?
[09:26] <Laney> -b <build i'm currently on> ?
[09:35] <JamesTait> Good morning all; happy Chocolate-Covered Peanuts Day! :-D
[09:44] <Laney> alternatively
[09:44] <Laney> how do I flash an old image?
[09:45] <Laney> does -revision blah work?
[09:45] <Laney> seems to!
[09:51] <ogra> Laney, yep
[10:02] <Laney> barry: I gave it a couple of retries and it failed both :/
[10:05] <nhaines> rsalveti, ogra: Nexus 5 (hammerhead) basically just works, and the sound fixes posted to the ML on Sunday enable sound.
[10:06] <nhaines> I know resources are limited, but would it possible to run builds for hammerhead so that the built-in updater would work?
[10:07] <ogra> nhaines, you need to convince asac (and the mgmt.), not us :)
[10:07] <nhaines> (And if so, then what do you need from me to make it easy for you?)
[10:07] <nhaines> ogra: okay, challenge accepted.  :)
[10:08] <nhaines> asac: ^^
[10:08] <ogra> nothing needed, its a few lines of changes in a few places to make that happen
[10:08] <nhaines> Basically, it can be like the maguro builds.  Maybe you're running tests but you're not blocking on failures.
[10:09] <nhaines> And since the Engineering spreadsheet indicated that support was coming by the end of June anyway, it can't hurt to just have automated builds.
[10:10] <nhaines> Besides, apparently Canonical has Nexus 5s in the MWC booth.  :)
[10:10] <ogra> do we ?
[10:11] <ogra> i thought there are only N4s
[10:11] <nhaines> It might be a typo, but I read it earlier.  Either on CNet or OMGUbuntu.
[10:11] <ogra> (if there are N5s they are definitely not officially dmoed)
[10:12] <nhaines> I ran my N5 for the Ubuntu booth at SCALE all weekend.  But that was definitely not official.  Was useful when the N4s were not available, though.
[10:12] <popey> nhaines: nice
[10:12]  * ogra read about that somewhere :)
[10:13] <nhaines> It was very useful for talking about how Ubuntu is meant for purpose-built phones but that the community could organize ports, too.
[10:14] <nhaines> And it was funny, since I had my Galaxy Nexus at the booth last year showing off the phone just a week after the preview image dropped.  (Thanks to Canonical for the N4s, too.)
[10:14] <Saviq> ogra, hey, can you point me how to info on how to get a local android build for debugging android-side crashes?
[10:15] <ogra> Saviq, well, you can use logcat (with the full path /system/bin/logcat) ... and you can enter the container via: lxc-console -nandroid -t0 ...
[10:16] <ogra> not sure if there is a way to enable more symbols or anything
[10:18] <Laney> barry: I'm starting to smell a s-i bug for that other one
[10:19] <Laney> You never get any subsequent UpdateAvailableStatus messages
[10:19] <Laney> "checking lock not acquired" on console
[10:19] <Laney> (in response to a CheckForUpdate call)
[10:19] <Laney> it does work under testing=update-auto-success though
[10:20] <Saviq> ogra, well, yeah, I need to build it locally (on my host) to get more symbols
[10:20] <Saviq> that's what I'm trying to find out how to do
[10:44] <davmor2> Morning all
[10:57] <effbiai> is there a comunity port of ubuntu touch for the nexus 5?
[10:58] <ogra> effbiai, https://wiki.ubuntu.com/Touch/Install_UT_on_android4.4.2
[10:59] <xnox> ogra: system-image is up for flo, so why not just use ubuntu-device-flash?
[11:00] <ogra> xnox, thats hammerhead, not flo
[11:02] <xnox> ogra: oh, right. I'm not used to new codenames yet =)
[11:02] <ogra> :)
[11:02] <effbiai> "install UT on android"? what do you actually do? install ubuntu inside some kind of a container in android or do you wipe the phone and install UT? the heading is a bit mis-leading..
[11:02] <ogra> effbiai, no
[11:03] <ogra> you replace the android install
[11:03] <xnox> ogra: have you got meizu/bq builds and hw to sneak to me?! =)
[11:03] <effbiai> no to which question? :)
[11:03] <effbiai> ok
[11:03] <effbiai> then "install UT on android" is a bit misleading..
[11:03] <ogra> effbiai, but to do that the android device needs to be in a certain state (radio firmware needs to be initialized etc)
[11:03] <effbiai> "isntall UT instead of android" should be better
[11:04] <ogra> it should actually be "install the android 4.4 based UT" :)
[11:05] <ogra> but that site will hopefully go away anyway
[11:05] <effbiai> ogra: so "From Ubuntu Touch devices" is actually how to re-install android if you have Ubuntu Touch on your phone. and "Install from android" is if you want to wipe your android partition and install UT?
[11:05] <ogra> right, the point is that you need to have android installed and properly initialized first
[11:06] <effbiai> cuz it uses android 4.4.2's radio/baseband/fw?
[11:06] <ogra> because we do not touch radio firmware and bootloader ... these two come from the android install
[11:06] <effbiai> okay
[11:06] <ogra> also make sure to have it booted into android once after fastboot oem unlock ... else you get issues with adb later
[11:07] <effbiai> roger that
[11:07] <effbiai> fastboot oem unlock is for unlocking bootloader, right? and it will wipe the phone aswell, right?
[11:07] <ogra> yeha, it resets to a default android
[11:07] <effbiai> thanks
[11:08] <effbiai> and then the million dollar question.. is it possible to send sms and do phone calls? :)
[11:08] <ogra> effbiai, ask nhaines (or check the ubuntu-phone ML) for the alsa config files
[11:09] <ogra> they are not merged yet (will do that later today)
[11:09] <effbiai> ok, thanks
[11:09] <ogra> so that you get working sound ...
[11:09] <effbiai> yep, know what alsa does :)
[11:09] <ogra> if thats in place sms and calls should work just fine
[11:09] <ogra> (sms will most likely work without sound i guess :) )
[11:09] <effbiai> so the problem is alsa and not conectivity? :)
[11:09] <ogra> right
[11:09] <ogra> missing alsa UCM profile
[11:10] <effbiai> ah, okay
[11:10] <effbiai> is there a docking station or a usb-micro cable converter to be purchased to get ubuntu on a desktop screen available yet?
[11:11] <ogra> no, that functionality isnt in the current Ubuntu
[11:11] <ogra> probably in 15.04
[11:11] <ogra> focus ofr 14.04 is to get a rock solid phone OS
[11:11] <ogra> focus for 14.10 is to get that over to the desktop
[11:12] <ogra> thne in 15.04 there should be convergence possible
[11:12] <effbiai> any roadmaps laying around with this kind of information, maybe? :)
[11:12] <ogra> not really
[11:12] <ogra> the thing is that we need to merge the two bases first
[11:13] <ogra> and thats plkanned for 14.10
[11:13] <effbiai> okay
[11:13] <effbiai> is UT a fork from the normal Ubuntu?
[11:13] <ogra> only the UI ... which will be merged back into the desktop in 14.10
[11:13] <effbiai> roger that
[11:14] <ogra> under the hood there is a normal ubunu (plus the lxc container with the android hardware abstraction layer to get access to sensors, modem etc)
[11:14] <effbiai> okay
[11:14] <effbiai> is there  any news on when the bq and that other brand is coming out for sale?
[11:15] <ogra> no idea about a specific date ... summer or end of summer perhaps
[11:15] <effbiai> should have been a FAQ with these questions answered =)
[11:15] <xnox> ogra: any instructions on debuging ofono / using the ofono-scripts?
[11:15] <xnox> ogra: all i get is dbus errors Could not get owner of name 'org.ofono': no such name
[11:16] <ogra> xnox, well, does ofono run ?
[11:16] <ogra> you can add debug stuff to the ofono.override job we ship
[11:16] <ogra> it logs to syslog by default
[11:16] <xnox> ogra: yes, i may however not be on the same DBUS....
[11:16] <ogra> ofono itself should use the system bus
[11:16] <ogra> iirc the scripts need to use the session bugs ... so make sure to be the phablet user
[11:17] <ogra> beyond that ... awe :)
[11:17] <ogra> s/bugs/bus/
[11:17] <ogra> silly finger memory
[11:18] <ogra> hmm
[11:19] <ogra> so i see that CONFIG_RT_GROUP_SCHED is set in our kernels ... which prevents pulse to go into realtime mode ...
[11:19] <ogra> i wonder why we set that option ... is that needed for anything in lxc ?
[11:19]  * ogra wouldnt have though so
[11:20] <ogra> stgraber, would it be bad to switch off CONFIG_RT_GROUP_SCHED in our kernels (to allow rtkit daemon to grant realtime privileges to pulse)
[11:20] <e-Ra> hi guys, is it possible to develop apps in QML/C++ for tablets and smartphones with the current preview version of the sdk? Which template should I choose in the ide?
[11:21] <xnox> ogra: i appear to have no modem =(
[11:21] <ogra> xnox, on what device ?
[11:21] <xnox> ogra: generic
[11:21] <ogra> ah
[11:21] <ogra> yeah
[11:21] <xnox> ogra: but it's suppose to have one.
[11:21] <ogra> probably installing ofono-honesim can help ?
[11:21] <ogra> *phonesim
[11:22] <ogra> it should create a mock device
[11:25] <xnox> ogra: but i already have a device which has signal, status, etc. and i can control it via telnet.
[11:25] <ogra> hmm
[11:25] <ogra> but does it have an emulated  SIM ?
[11:26] <xnox> right, it appears to be faked up and down.
[11:43] <Ashkar> Hello??
[11:44] <Ashkar> Are you there??
[11:45] <Ashkar> hello, is ot possible to install ubuntu for android on sony xperia L (C2104)????
[11:46] <popey> !devices | Ashkar
[11:46] <popey> is it listed there?
[11:46] <firelmnt_> hi all, where i can set kernel for debugging?
[11:47] <Ashkar> i couldn't find Xperia L at there.. does it mean its impossible??
[11:49] <firelmnt_> no, it could mean no1 tried to port it | Ashkar
[11:49] <Ashkar> ok
[11:50] <Ashkar> what should i do to install ubuntu for android on xperia L
[11:50] <Ashkar> ??
[11:50] <ogra> you wuld need to do a port
[11:50] <ogra> (see the channel topic for a link to the porting guide)
[11:50] <ogra> or search xda-developers and hope that you find something there that was not added to the wiki yet
[11:51] <firelmnt_> how can i debug booting?
[11:51] <ogra> firelmnt_, whats your issue ?
[11:52] <firelmnt_> well i need to log it, cause it's booting and even before booting logo it reboots
[11:55] <ogra> boot into recovery and do: cat /proc/last_kmsg
[11:55] <ogra> that holds the dmesg from last boot
[11:55] <firelmnt_> ok, thanks i'll try
[12:00] <e-Ra> Is it possible to delvelop with the qtcreator from qt project, not the sdk from ubuntu dev page?
[12:17] <ogra> xnox, wow, thats a lot of prints
[12:18] <ogra> oh, wow, 2/3 through the MP there is actual code changes :)
[12:18] <xnox> ogra: yeah, all of them would be 10x quicker and less the size in perl =)
[12:19] <xnox> ogra: well, pitti is doing his own cover version of them =)
[12:19] <ogra> heh
[12:20] <ogra> remix culture
[12:20] <ogra> from a plain look at the code the MP looks fine
[12:23] <Guest87556> ogra: thx (alsa-lib) :)
[12:23] <ogra> np :)
[12:23] <ogra> i hope you guys fine solutions for the remaining issues
[12:23] <ogra> happy to merge them too
[12:24] <Guest87556> chris did the most thinking work. I just modified some values from android to ucm style ;)
[12:25] <FuLgOrE_> anyway: since the first steps are done and the principle is clear I will also take a look on the weekend
[12:49] <Vezzoni> Hello everyone, I'm from Brazil and I have installed the ubuntu touch trusty
[12:49] <Vezzoni> Do, anyone know how to sync google contacts?
[12:49] <Vezzoni> *does
[12:53] <nik90> Vezzoni: try http://victorpalau.net/2013/12/17/ubuntu-qml-importing-google-contacts/
[12:53] <Vezzoni> Thanks nik90
[12:53] <nik90> Vezzoni: yw
[12:55] <diwic> ogra, rsalveti, hi, do you still need assistance with the PulseAudio CPU bug or was it resolved with rsalveti's uevent filter?
[12:55] <ogra> diwic, not resolved yet
[12:56] <ogra> diwic, seems our kernel has CONFIG_RT_GROUP_SCHED set which might have some impact on the rtkit thing
[12:56] <ogra> thats as far as i got ... waiting for stgraber to tell me if we actually need that in our kernels
[12:57] <diwic> ogra, do you have a Nexus 4 in front of you or should bring mine up to date?
[12:57] <ogra> rsalveti was looking into the other issue that keeps pulse awake all the time
[12:57] <ogra> diwic, my nexus4 is private ... it is my main phone, i dont do development on it :)
[12:58] <ogra> (so yes, this would most likely help)
[12:59] <diwic> ogra, ok, I'll flash mine then, it was a while, so might take some time. Would this one do: "ubuntu-device-flash --wipe --channel devel-proposed" ?
[12:59] <ogra> s/--wipe/--bootstrap/
[12:59] <diwic> ok
[12:59] <ogra> and i think for bootstrap you need to be in bootloader mode
[12:59] <ogra> (adb reboot bootloader)
[13:07]  * diwic flashing
[13:22] <rsalveti> diwic: morning
[13:23] <diwic> rsalveti, hi!
[13:23] <diwic> rsalveti, I've just finished flashing the device, let me see if I see the problem here as well
[13:25] <rsalveti> diwic: great, thanks
[13:34] <diwic> rsalveti, ok, I'm seeing it here too. It eats 1% CPU and the sink is IDLE but not SUSPENDED. Maliit-server has a sink input, but it is corked. *looks deeper into the code*
[13:35] <rsalveti> diwic: right
[13:35] <rsalveti> that's what I saw as well
[13:52] <diwic> rsalveti, I don't have things set up to do test builds for the phone, if I send a patch to you, will you test it for me?
[13:52] <diwic> rsalveti, or is it easy to set up?
[13:53] <rsalveti> diwic: sure, I can quickly rebuild it for you
[13:53] <rsalveti> phablet-config writable-image
[13:53] <rsalveti> to get the image writable
[13:53] <rsalveti> then you'd need to build on the phone, don't know if you already can easily cross build pulse
[13:53] <diwic> rsalveti, patch sent  :-)
[13:54] <rsalveti> diwic: but I have a local build already, so it might be faster
[13:54] <diwic> rsalveti, btw, I noticed that if you just played a test sound, when the test sound stopped, the sink was suspended like it should
[13:55] <rsalveti> diwic: yeah, noticed that as well here
[13:55] <rsalveti> but indeed, the maliit-server stream is not even started
[14:00] <diwic> ogra, why would config_rt_group_Sched disable rtkit ?
[14:00] <diwic> ogra, or, in what doc did you read that...?
[14:00] <ogra> diwic, dunno, thats what i read everywhere in bug reports that google gave me ... it would either need configuration for rtkit or switching off in the config apparently
[14:01] <ogra> i dont think we need it for anything so switching it off seems like the easiest option
[14:02] <diwic> ogra, but don't we have that option set on the desktop too? And I don't think we have that problem there, or do we?
[14:02] <ogra> seemingly by default the config option prevents all non root processes from gaining RT
[14:03] <ogra> not sure if we have it on the desktop
[14:03] <ogra> yeah, we do
[14:03] <ogra> hmm
[14:04] <ogra> i dont see any RT related syslog messages here though
[14:06] <diwic> ogra, maybe we're better at enabling RT for non-root users on the desktop, perhaps through logind or something
[14:06] <ogra> yeah, might be something that we dont ship on the touch images
[14:07] <rsalveti> diwic: boot log, pulse is still consuming cpu http://paste.ubuntu.com/6994548/
[14:08] <rsalveti> should I wait more?
[14:08] <ogra> By default all bandwidth is assigned to the root group and new groups get the
[14:08] <ogra> period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
[14:08] <ogra> want to assign bandwidth to another group, reduce the root group's bandwidth
[14:08] <ogra> and assign some or all of the difference to another group.
[14:08] <ogra> thats what i find in the kernel docs
[14:11] <diwic> rsalveti, thanks
[14:11] <rsalveti> diwic: pulse is still giving that message from time to time, but it seems to be consuming less cpu
[14:11] <diwic> rsalveti, it looks indeed like module-suspend-on-idle is not doing what it should, just that my patch doesn't fix it
[14:11] <rsalveti> sorry, that was another machine
[14:11] <rsalveti> it's still consuming 1.0% here
[14:14] <diwic> rsalveti, ok, I'll send another patch shortly.
[14:14] <rsalveti> diwic: ok
[14:15] <rsalveti> let me also make sure it's indeed using your changes
[14:20] <rsalveti> diwic: http://paste.ubuntu.com/6994614/
[14:20] <rsalveti> diwic: it seems indeed better now, I didn't copy the updated idle module at the previous run
[14:21] <rsalveti> pulse is now only consuming 0.1% cpu
[14:22] <rsalveti> let me get a package with that
[14:24] <rsalveti> argh, just noticed maliit-sever didn't actually start the stream this time
[14:24] <diwic> rsalveti, looking at the log, something happened...why did PA restart (first pid 1882, then pid 2279)
[14:24] <rsalveti> that explains :-)
[14:25] <rsalveti> yeah, why would it crash now, let me get the package done
[14:26] <barry> Laney: hi
[14:26] <rsalveti> I replaced pulseaudio and module-idle, which were the only ones that got updated
[14:27] <ogra> rsalveti, diwic are we sure it crashes ? we start pulse from an upstart job in the session ... desktop doesnt do that, probably we actually start it twice ?
[14:28] <rsalveti> ogra: no, it crashed
[14:28] <ogra> (by inheriting some desktop behavior we didnt have before or some such)
[14:28] <rsalveti> doing a clean install now
[14:30] <barry> Laney: can you give landing 10 a rebuild?
[14:36] <Laney> barry: did you fix something?
[14:36] <barry> Laney: just the PPA build.  i'm responding to LP: #1284217.  happy to discuss that further, but let me finish my comment there first
[14:37] <Laney> barry: I  mean I already retried it twice this morning and it failed both times
[14:37] <Laney> so, reluctant to do it again unless there's a change :P
[14:38] <diwic> rsalveti, yeah, I first thought I saw a flaw in my patch, but now I think it should have worked. Could it have been that pulseaudio crashed with some assert failure due to my patch?
[14:39] <barry> Laney: it needs s-i 2.1-0ubuntu3
[14:39] <Laney> roger
[14:40] <barry> Laney: and hopefully my interwebs will stay up.  my isp is out there re-burying the line
[14:40] <Laney> http://162.213.34.102/job/landing-010-1-build/21/console
[14:41]  * barry watches
[14:41] <Laney> that's only the source package build
[14:41] <Laney> it polls the PPA after it's uploaded there
[14:43] <Laney> looking forward to reading the reply to the bug
[14:43] <rsalveti> diwic: yeah, logs after installing the debs http://paste.ubuntu.com/6994698/
[14:43] <rsalveti> diwic: debs also available at http://people.canonical.com/~rsalveti/pulse/
[14:45] <diwic> rsalveti, that looks quite good, doesn't it?
[14:45] <rsalveti> diwic: yup, seems it fixed the issue
[14:45] <diwic> rsalveti, \o/
[14:45] <rsalveti> diwic: give it a try with my debs, and if it also fix the issue for you, mind uploading it as well?
[14:46] <rsalveti> ogra: pulse just consuming 0.1 now :-)
[14:46] <rsalveti> diwic rocks :-)
[14:46] <ogra> rsalveti, great
[14:46] <ogra> yeah, he does
[14:46] <diwic> 0.1 is still 0.1 too much ;-)
[14:46] <rsalveti> haha
[14:46] <ogra> if we could now only get rtkit to behave
[14:47] <ogra> i cant find any differences in the setup comparing sysfs on the phone with my laptop
[14:47] <ogra> but i definitely never get any rtkit (or even pulse) messages in syslog here
[14:48] <diwic> rsalveti, ogra, thanks :-) and same to you btw, doing all the dirty work for me so I just have to write patches :-)
[14:48] <rsalveti> haha :-)
[14:48] <ogra> :)
[14:51] <diwic> rsalveti, I'll do a test here. In case it works, can I just upload, or do I need to fill out spread sheets, ping people and whatnot to get an "ok" to upload ?
[14:51] <rsalveti> diwic: just upload
[14:51] <diwic> rsalveti, sounds good :-)
[14:51] <rsalveti> I tested the fix
[14:52] <rsalveti> code looks sane as well
[14:52] <ogra> but the upload will get stuck until thu ... in beta freeze
[14:52] <rsalveti> diwic: there's just another annoying audio bug to fix (bug 1283818), but will take a better look at that later today
[14:53] <rsalveti> it seems audio hal is not behaving properly with 4.4.2
[14:58] <diwic> rsalveti, ok
[15:00] <diwic> rsalveti, fix confirmed working here
[15:00] <rsalveti> diwic: \o/
[15:00] <stgraber> ogra: I'm not aware of any obvious problem that'd result from changing CONFIG_RT_GROUP_SCHED but I'd recommend you take this to the kernel team instead as I won't pretend to know much about the realtime stuff in the kernel
[15:00] <ogra> heh, ok
[15:01] <diwic> stgraber, ok, do you know anything about how we set up cgroups for non-root users?
[15:01] <ogra> mdeslaur, lets take it over here
[15:01] <diwic> stgraber, is that done through logind, pam, or something?
[15:01] <ogra> root@ubuntu-phablet:/# ps axu|grep rtkit
[15:01] <ogra> rtkit     1434  0.0  0.0  20484  1008 ?        SNl  14:07   0:00 /usr/lib/rtkit/rtkit-daemon
[15:01] <stgraber> diwic: yes, logind does that
[15:01] <mdeslaur> ogra: yes, the daemon drops privs but keeps CAP_SYS_NICE
[15:02] <ogra> then i dont get why we cant set RT caps
[15:02] <ogra> i wouldnt mind just dropping the kernel option though
[15:02] <ogra> i doubt it does any harm
[15:02] <mdeslaur> ogra: excuse me, what?
[15:03] <ogra> mdeslaur, rtkit refuses to set the capabilities for pulse in our setup
[15:03] <diwic> stgraber, so if one would look for where logind enables non-root users to have RT permissions...?
[15:03] <ogra> mdeslaur, i dont think we make any use of CONFIG_RT_GROUP_SCHED on the phone ... so i wouldnt expect ill sideefects when dropping that option ... which should make rtkit work
[15:04] <barry> Laney: comment posted.  let me know if you want to discuss further
[15:04] <mdeslaur> ogra: why don't you figure out the problem instead of working around it? :)
[15:04] <diwic> stgraber, "This uses the cgroup virtual file system '<cgroup>/cpu.rt_runtime_us' to control the CPU time reserverd for each control group."
[15:05] <diwic> stgraber, mdeslaur does that say anything to you?
[15:05] <mdeslaur> diwic: your problem has nothing to do with cgroups
[15:06] <mdeslaur> it's either pulse can't talk to rtkit, or rtkit is failing the policykit check, or rtkit is failing to set the pulse priority
[15:06]  * ogra guesses our prob is that we start pulse directly from an upstart job 
[15:06] <ogra> which desktop doesnt
[15:06] <diwic> ogra, have you confirmed this has anything to do with config_rt_group_sched by disabling it and see that it works?
[15:07] <mdeslaur> ogra: you should see a message in the pulse output if it couldn't contact rtkit
[15:07] <ogra> diwic, well, mdeslaur told me in -desktop that this cant be our prob
[15:07] <diwic> mdeslaur,
[15:07] <diwic> Feb 25 14:42:10 ubuntu-phablet rtkit-daemon[1900]: Failed to make thread 1953 RT: Operation not permitted
[15:07] <ogra> mdeslaur, it seemingly can contact it, else i wouldnt see rtkit complaiun in syslog
[15:08] <ogra> so the communication layer is intact ... the permissions probably are not
[15:08] <ogra> and all hints i found in bug reports etc point to the fact that the cgroup by default doesnt allow non-root access
[15:09] <ogra> fedorea seems to have patched sytemd for this specifically
[15:09] <mdeslaur> ogra: ok, so if you got that message that means you've passed all the policykit stuff, and you're hitting an issue setting the priority on the process itself
[15:09] <mdeslaur> ogra: perhaps related to the android specific priority patches
[15:10] <mterry> Laney, you had mentioned not being thrilled with sync'ing volume via AccountsService.  Did you mean as the canonical location (I agree it should stay in pulse), or just at all?
[15:10] <ogra> does that fiddle with cgroups ?
[15:10] <mdeslaur> this problem is in _no_ way related to cgroups
[15:10] <Laney> mterry: The concept of doing that kind of syncing
[15:10] <stgraber> ogra: ignore cgroups there, we're talking process priority.
[15:10] <ogra> ok
[15:11] <Laney> mterry: Ideally the session would be able to communicate things like that to the greeter when the switch happens
[15:11] <mterry> Laney, but it is also a per-user setting.  I remember we have a long-standing bug on desktop to do that, but we never bothered
[15:11] <stgraber> the cgroup keys are only there to tweak some of the delays but that won't prevent you from making a process rt and those keys aren't set by default anyway
[15:12] <mterry> Laney, although that bug was probably more about going the other way (i.e. changing in greeter and having that change the session)
[15:12] <ogra> stgraber, well, the kernel doc is confusing me
[15:12] <ogra> "By default all bandwidth is assigned to the root group and new groups get the
[15:12] <ogra> period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
[15:12] <ogra> want to assign bandwidth to another group, reduce the root group's bandwidth
[15:12] <ogra> and assign some or all of the difference to another group"
[15:14] <stgraber> note that those are "groups" not "cgroups"
[15:14] <ogra> yes, i understood that
[15:17] <mhall119> ogra: where's the instructions for making an image-based install writable?
[15:17] <ogra> mhall119, phablet-config writable-image
[15:19] <mhall119> really? it's that simple now?
[15:19] <sergiusens> has been for 3 months I say (or more)
[15:19] <mhall119> is that documented on the wiki somewhere?
[15:20] <ogra> probably :)
[15:23] <stgraber> mdeslaur: might have something to do with cgroups after all...
[15:23] <stgraber> root@castiana:~# chrt -r -p 99 $$
[15:23] <stgraber> chrt: failed to set pid 19023's policy: Operation not permitted
[15:23] <stgraber> root@castiana:~# echo $$ > /sys/fs/cgroup/cpu/tasks
[15:23] <stgraber> root@castiana:~# chrt -r -p 99 $$
[15:23] <mhall119> ogra: I don't even have to restart?
[15:23] <ogra> mhall119, you do
[15:24] <ogra> mhall119, oh, btw https://code-review.phablet.ubuntu.com/#/c/189/
[15:24] <mhall119> oh...maybe I'd already made it writable then
[15:24] <Laney> barry: I replied again
[15:24] <ogra> mhall119, did you open a bug for that ?
[15:24] <ogra> (teh fix will land with the next android upload)
[15:24] <mdeslaur> stgraber: curiously, I do have messages that rtkit set my pulse process to realtime in the log
[15:24] <mhall119> ogra: I opened one against dialer-app
[15:24] <mdeslaur> stgraber: but chrt isn't showing it
[15:25] <ogra> mhall119, can you re-assign against android ? dialer-app is just a victim
[15:26] <stgraber> mdeslaur: so my guess is that everything works fine so long as rtkit runs as root and isn't itself in a cgroup
[15:26] <ogra> mdeslaur, getprop ro.build.version.release
[15:26] <barry> Laney: okay.  btw, the build succeeded.  yay for sleep(2)
[15:26] <ogra> mdeslaur, are you on android 4.4 already ?
[15:26] <Laney> \o/
[15:26] <stgraber> mdeslaur: if it's a cgroup, it gets affected by cpu.rt_runtime_us which is 0 for the /user hierarchy
[15:26] <stgraber> *in a cgroup
[15:26] <diwic> ogra, fwiw, I did see error messages on 4.2 too
[15:27] <mhall119> ogra: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1284255 I can't change the project
[15:27] <ogra> diwic, i never noticed that... but rsalveti telling me "thats normal" kind of indicates that they were there before :)
[15:28] <diwic> ogra, well, they were there before, but it's not normal :-)
[15:28] <diwic> it should be fixed
[15:28] <ogra> heh, yeah
[15:28] <stgraber> mdeslaur: and AFAICT nothing is setting that value to 0, it's the controller's default that only something in the root cgroup has it set to 950000, any other sub-cgroup defaults to 0
[15:28] <mdeslaur> ogra: I don't have a device, I'm just looking at my laptop
[15:29] <stgraber> however looking on my mako, rtkit is in the root cgroup, so it should be able to set the priority just fine
[15:29] <stgraber> it's just if pulseaudio attempts to do it itself that it'll fail
[15:29] <xnox> 15:28:59.080 INFO __init__:387 - dbus.DBusException while attempting to get PID for org.freedesktop.ReserveDevice1.Audio1: DBusException("Could not get PID of name 'org.freedesktop.ReserveDevice1.Audio1': no such name",)
[15:29] <xnox> does not sound good.
[15:30] <ogra> mhall119, adjusted
[15:30] <diwic> xnox, hmm, is this related to anything or are you just talking about error messages in general? :-)
[15:30] <mdeslaur> stgraber: I'm wondering if something is failing in trusty... do chrt -a -p `pidof pulseaudio`
[15:30] <xnox> diwic: filemanager autopilot tests fail, but that's about it.
[15:31] <xnox> diwic: and it sounds like not the only sound problem at the moment.
[15:31] <mdeslaur> stgraber: in precise, I get this: pid 1837's current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK
[15:31] <mdeslaur> pid 1837's current scheduling priority: 5
[15:31] <ogra> xnox, weird that filemanager triggers such a message though
[15:31] <mdeslaur> stgraber: but none of them in trusty is getting realtime
[15:31] <xnox> ogra: oh, it has some sound settings / sound feedback or somesuch and the tests check that.
[15:31] <diwic> xnox, uhm, filemanager? Why would it try to look at the second sound card in a system?
[15:32] <xnox> diwic: i dunno, i'm just verifying it works with python3.... and it doesn't work at all at the moment on my grouper.
[15:32] <xnox> (and that is _not_ on 4.4 i take it?!)
[15:32] <ogra> xnox, grouper is dead and buried
[15:33] <ogra> have your manager get you a flo
[15:33] <xnox> ogra: what happened? it does have full 4.4 support from cyanogen mod trees.
[15:33] <xnox> ogra: why can't we just build that? (sure it will still be phone UI without sim, but it's better than nothing)
[15:33] <ogra> we have long stopped looking into grouper issues
[15:33] <ogra> Mir doesnt work right etc
[15:33] <xnox> ogra: Mir got fixed, and works right.
[15:34] <xnox> ogra: it's actually very slick.
[15:34] <stgraber> mdeslaur: http://paste.ubuntu.com/6994941/
[15:34] <ogra> well, groupper wont be supported anymore by end of the week or so
[15:34] <stgraber> mdeslaur: to me it looks like rtkit is just completely buggy
[15:34] <stgraber> mdeslaur: all those paths are lacking an obvious /proc
[15:35] <mdeslaur> stgraber: oh gah, what's that on?
[15:35] <diwic> stgraber, it does a chroot into /proc as an additional security thing
[15:35] <diwic> stgraber, IIRC
[15:35] <stgraber> mdeslaur: strace of rtkit while restarting pulseaudio
[15:35] <stgraber> diwic: well, if it does that, it doesn't seem to be terribly succesful :)
[15:36] <ogra> probably it only works with systemd nowadays :P
[15:36] <stgraber> diwic: though, you're right, ls /proc/$(pidof /usr/lib/rtkit/rtkit-daemon)/root confirms it
[15:37] <stgraber> diwic: ok, so re-reading with that in mind, it actually looks kind of fine
[15:37] <ogra> https://bugzilla.redhat.com/show_bug.cgi?id=655321... admittedly 3 years old and no reference which patches were added
[15:39] <ogra> is our rtkit actually recent ?
[15:40] <barry> Laney: i think i see what's going on.  see my last comment, esp. the last paragraph.  ping me when you've read that and we can do a quick discussion
[15:40] <ogra> oh, awesome ... so the homepage of rtkit is http://0pointer.de/public/
[15:40] <ogra> lovely
[15:40] <Laney> barry: okay, sec, desktop team meeting atm
[15:40] <mdeslaur> ogra: looks like it was http://git.0pointer.de/?p=rtkit.git;a=commit;h=933c59c232df3c3910bf61ea3dc7c45c27e79129
[15:40] <barry> Laney: no rush
[15:42] <ogra> yeah, seems we have it
[15:43] <xnox> barry: i am on grouper/devel r194
[15:43] <xnox> barry: i've treid system-image-cli -v -c devel-proposed
[15:43] <xnox> barry: and i get SignatureError =(
[15:43] <ogra> xnox, -b 0
[15:43] <barry> xnox: are you testing with the new s-i and u-d-m stack?
[15:44] <xnox> barry: no.
[15:44] <xnox> barry: worked the second time....
[15:44] <barry> xnox: right.  try it with the debs from https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+packages
[15:45]  * ogra finds it astonishing that rtkit only had 6 revisions in 4 years
[15:45] <Laney> barry: I think your last paragraph is what I was thinking of
[15:45] <Laney> You just repeat the previous UAS in that case
[15:46] <barry> Laney: it will only happen if the initial check was completed of course.  if that check is still in progress, we have no status and will return without issuing a UAS signal
[15:46]  * mdeslaur really likes multiple commit messages that are "systemd: update sd-daemon.[ch]"
[15:46] <mdeslaur> only slightly better than "change stuff."
[15:47] <Laney> barry: yup
[15:47] <stgraber> hmm, so I see the problem but I'm not sure how that one got solved on Fedora
[15:47] <jodh> mdeslaur: http://imgs.xkcd.com/comics/git_commit.png
[15:47] <stgraber> basically, when setting a task as RT, no matter who sets it, the cgroup limit will be checked
[15:47] <barry> Laney: here's what i think i can do: i'm going to try to fix this in s-i trunk, but i'm not going to release a 2.2 upstream.  i'll take that patch and turn it into a quilt patch for 2.1, push it to my existing ci-train mp and ask you to do a landing 10 rebuild.  then we'll have something to test.  i can back the patch out when i do the next 2.2 upstream release
[15:47] <mdeslaur> jodh: heh :)
[15:48] <stgraber> so even if I'm root, in the root cgroups and have no limit applied to ME, I can't set the value for a process which is in a limited cgroup
[15:48] <stgraber> root@castiana:~# echo $$ > /sys/fs/cgroup/cpu/tasks
[15:48] <stgraber> root@castiana:~# chrt -r -p 99 $$
[15:48] <stgraber> root@castiana:~# chrt -r -p 99 21371
[15:48] <stgraber> chrt: failed to set pid 21371's policy: Operation not permitted
[15:48] <Laney> barry: ack, sounds fine to me
[15:48] <Laney> Not really bothered how the code gets to me as long as it does :P
[15:48] <barry> Laney: :)  okay, stay tuned
[15:48] <Laney> Unless you mean *really* back out, and not drop the quilt patch because it's then upstream
[15:48] <mdeslaur> stgraber: http://git.0pointer.de/?p=rtkit.git;a=commit;h=10a96f332f0f31275f53cf370989c828d72cf5bc
[15:49] <barry> Laney: right, drop the quilt patch because it's then upstream
[15:49] <stgraber> mdeslaur: sure but that's not enough, that's what I just said :)
[15:49] <Laney> good :)
[15:49] <stgraber> mdeslaur: my example above shows me being root, in the root cgroup and still not being allowed to change rt capabilities of processes in a restricted cgroup
[15:50] <mdeslaur> stgraber: ah, right
[15:50] <mdeslaur> hrm
[15:51] <stgraber> mdeslaur: this may be very well also apply to Fedora as I'm not sure they actually set the cpu controller in logind
[15:51] <stgraber> if they don't, they won't have the problem
[15:51] <stgraber> and that's why a saucy system or a trusty system without cgroup-lite installed won't have that problem at all
[15:51] <stgraber> but since we plan on having logind setup all the controllers for all users in trusty, we'll have to find a way to sort out that mess...
[15:54] <mdeslaur> stgraber: ok, I'm sure you'll manage to figure it out :)
[15:54] <mdeslaur> ogra: sorry, seems you were right about it being related to cgroups
[15:55] <ogra> :)
[15:55]  * ogra is good at guessing 
[15:55] <mdeslaur> heh :)
[15:55] <hallyn> hey ( though i can't actually pay attention for the next few mins, biab )
[15:55] <stgraber> hey hallyn, let me just brain dump where we are at this point :)
[15:56] <stgraber> hallyn: so ogra reported that rtkit (a Lennart project that grants RT privileges to user processes) fails on Ubuntu Touch and on some Ubuntu desktops in trusty
[15:56] <stgraber> hallyn: I tracked this down to us now setting up a cpu cgroup for each user, so pulseaudio is in a cpu cgroup
[15:57] <stgraber> hallyn: basically this is related to rt_runtime_us, /sys/fs/cgroup/cpu has it set to 950000 but any sub-cgroup will default to 0
[15:58] <stgraber> hallyn: as weird and stupid as this may be, even if rtkit is running in the root cgroup, it can't set rt priority on a process which is in a cgroup with rt_runtime_us set to 0
[16:01] <stgraber> hallyn: so since by the time we release trusty we'll have all user processes in a cpu cgroup, and most of our users unfortunately run pulseaudio which kind of likes to have rt priority (and I hear it's important for phone calls too...), we need to find a way out of this
[16:02] <hallyn> oh maybe that explains why i've had trouble soetimes with linphone
[16:02] <mdeslaur> hallyn: try chrt -a -p `pidof pulseaudio`
[16:02] <hallyn> stgraber: all right, basically i know nothing about rt cgroup;  after team mtg (which starts now) i'll look over
[16:02] <hallyn> http://lkml.iu.edu/hypermail/linux/kernel/0808.2/0223.html
[16:02] <stgraber> hallyn: current thoughts include: patch logind to set the limit to the root value (so manual inheritance of rt_runtime_us) or turning off that bit in the kernel entirely
[16:02] <hallyn> http://www.mjmwired.net/kernel/Documentation/scheduler/sched-rt-group.txt
[16:02] <mdeslaur> hallyn: on trusty, nothing is realtime
[16:02] <hallyn> and then hopefully i can talk more intelligently
[16:27] <diwic> rsalveti, hrm, other things got in the way, so didn't have time to upload PulseAudio with the fix today. Feel free to do so yourself. Sorry for the inconvenience.
[16:28] <rsalveti> diwic: no worries, will upload after my call then, thanks :-)
[16:34] <hallyn> stgraber: so the solution is multiple hierarchies?  :)
[16:38] <hallyn> stgraber: if pulseaudio is started by a user upstart session, it could create a different cpu cgroup for pulse
[16:39] <hallyn> we can say root gets 50% runtime_us, and the console cgroup gets 35?
[16:40] <stgraber> hallyn: so yeah, that's one possibility, technically logind doesn't apply any limitation at the moment, so it'd make sense to just manually inherit the rt value but that's slightly painful as logind does mkdir_p and we then need to go and walk the path to set it all the way to the user's cgroup
[16:41] <hallyn> well i think we can find a clean way to do that - the first question is whether that design makes sense
[16:41] <stgraber> the other possiblity being to get rid of that rt stuff from the cpu cgroup entirely (since it's confusing inconsistent and I'm not sure anyone actually uses this)
[16:41] <hallyn> what all would go into the console cgroup?
[16:41] <hallyn> also the rt cgroup is the one that lets a user hose the system iiuc
[16:42] <hallyn> who do we have who wants rt?  jackd users?
[16:42] <hallyn> stgraber: we wouldn't "walk a path" though,
[16:42] <stgraber> pulseaudio wants rt but it asks a privileged rtkit daemon to make it rt, so we don't need the user to be allowed to do that themselves
[16:42] <ogra> nobody on the phone, i can promise you
[16:43] <hallyn> stgraber: in a container, we wouldn't do this.  so we'd just use "/console"
[16:43] <stgraber> the problem is that because pulseaudio is in a rt limited cgroup, rtkit can't do its job
[16:43] <ogra> right
[16:43]  * ogra proposes since the start to just drop the kernel option 
[16:43] <hallyn> i'm ok with that.  i sort of assumed we would
[16:44] <ogra> though if you guys found general probs that extend into the desktop too ...
[16:44] <hallyn> do we need rt on desktop?
[16:44] <hallyn> s/need/want/
[16:44] <stgraber> ogra: you are proposing to drop the rt restriction feature enitrely which is slightly overkill, just killing the cgroup part of it would be better
[16:44] <ogra> we have rtkit there was well, to bump the scheduling for pulse
[16:44] <stgraber> hallyn: pulseaudio wants it and used to have it until we turned on the cpu cgroup for all users
[16:44] <Tassadar> barry: I'd like to fix https://bugs.launchpad.net/ubuntu-system-image/+bug/1278589 , but I'm not sure how to replace current use of http(s)_base in the code - would adding another method to Configuration class (like, url_base(prefer_https): ...) and then replacing http(s)_base with that call be okay?
[16:45] <hallyn> stgraber: but if we turn of rt cgroup, pulse audio will ignore it?
[16:45] <hallyn> (i'm not sure why you keeping sayin gthat to me, so i must be missing something)
[16:45] <stgraber> hallyn: my hope is that if we turn off the rt cgroup, things will be identical to the process being in the root cgroup, and we know that this works fine
[16:45] <hallyn> stgraber: so what is the downside to turning of the rt cgroup
[16:46] <hallyn> actually i suppose on small hw like a phone we in fact might want rt cgroup for the phone functionality...
[16:46] <stgraber> hallyn: none that I can think of though is there an easy way to turn off only those bits?
[16:46] <hallyn> I thought that was what CONFIG_RT_GROUP_SCHED was.
[16:46] <stgraber> hallyn: well, no, on the phone you'd want whatever wants rt privileges to talk to rtkit which will then grant them the privilege if they deserve it
[16:47] <ogra> right
[16:49] <stgraber> hallyn: is CONFIG_RT_GROUP_SCHED in fact only applying only to cgroups? the name and description I've seen here and there suggested it was also responsible for exposing some of the knobs in sysctl
[16:49] <hallyn> can't say i understand why rt isn't its own cgroup.  cpu was originally for resource tracking... this limits its usefulness for that
[16:50] <barry> Tassadar: nice!  i haven't had time to comment on that bug, but my thinking is that we'd add a use_https flag to the [service] section, which of course would default to yes.  then in config.py, where we calculate the service['https_base'] value, if use_https is false, we'd essentially copy the service['http_base'] value to service['https_base'].  other than tests, i think this is all we'd need to do.  let me add that to the bug
[16:50] <stgraber> well, the whole cpu* stuff is a mess at the moment, but yeah, rt should have been a separate controller
[16:50] <stgraber> hallyn: so if you can't think of a downside to turning CONFIG_RT_GROUP_SCHED off, then we probably ought to have that done for all kernels by the kernel team
[16:51] <hallyn> i dunno - it does show up all over the place,
[16:51] <Tassadar> barry: oh, okay) Should I do it and then propose merge? (I'm not sure how that works on launchpad...)
[16:52] <hallyn> stgraber: see http://paste.ubuntu.com/6995272/
[16:52] <stgraber> hallyn: ah, that's much clearer than the doc page :)
[16:53] <hallyn> it's from http://www.mjmwired.net/kernel/Documentation/scheduler/sched-rt-group.txt .
[16:53] <hallyn> but i'm still not convinced...
[16:53] <hallyn> only bc i'm not 100% clear on what exactly we want.
[16:53] <hallyn> so CONFIG_RT_GROUP_SCHED depends on cgroups.  but i dont' know if it is required for some other rt-y thing
[16:54] <barry> Tassadar: yeah, that would be awesome.  you'd be our first outside contributor! (have to figure out how that would work, might have to do a cla :).  the way to do it is to branch lp:ubuntu-system-image/client, make the changes, push a branch to lp, and do a merge proposal.  i can certainly help you with those steps
[16:54] <stgraber> I think what we want is the pre-trusty behaviour where users can't mark their task rt (obviously) but rtkit can (because its privileged) and we don't want to bother with quotas as that's exactly what rtkit does already
[16:54] <stgraber> so the equivalent of having all processes in cpu:/ with no limit applied to rt_* (default system wide values)
[16:55] <hallyn> stgraber: ok, so rtkit only does that per-task right?
[16:55] <hallyn> if it doe sit per-group, then i think it depends on the cgroups
[16:55] <hallyn> if per-task is ok then we can turn off CONFIG_RT_GROUP_SCHED
[16:55] <stgraber> hallyn: it doe it per-task and does some kind of throttling based on the uid that owns the task
[16:56] <Tassadar> barry: okay. See, I've set-up a system-image server for hammerhead, but I don't have https certificate, so it won't update itself after installation
[16:56] <stgraber> hallyn: I read through rtkit's code earlier and the only mention of cgroups is in its systemd detection code, it never reads or writes the rt_ cgroup entries
[16:56] <hallyn> stgraber: yes, but i was afraid there might be another way of grouping tasks which rtkit uses and which is not cgroup-y, but depends on cgroup in its in-kernel rt implementatin
[16:56] <stgraber> Tassadar: if you have a dedicated IP for that server, you can get a basic https certificate for free from startssl
[16:56] <hallyn> sounds like no
[16:56] <barry> Tassadar: https://bugs.launchpad.net/ubuntu-system-image/+bug/1278589/comments/1
[16:57] <barry> Tassadar: take a shot at it, and feel free to ping me.  it would be a very nice contribution.
[16:57] <stgraber> hallyn: right, I looked for that and it looks like none of Lennart's project ever try to read/write any of that rt cgroup stuff
[16:57] <stgraber> hallyn: so sounds like we should just poke the kernel team and have that thing turned off everywhere
[16:58] <hallyn> stgraber: agreed.  they might of course have a good reason why they can't do that...
[17:00] <Tassadar> barry: I suppose I have to change the server to pass that use_https flag from etc/config into channel.ini too, right?
[17:00] <hallyn> stgraber: note that, all the same, having a separate /console cgroup (one per host) might be interesting anyway
[17:03] <stgraber> hallyn: I'm not sure I understand what that'd do, would we move all of the user's tasks from /user/uid.user/cX.session/ to /console or what?
[17:03] <hallyn> only pulseaudio and maybe compiz;  anything related to audio/video
[17:03] <hallyn> maybe (*$&%($*% hangouts crap
[17:04] <barry> Tassadar: sorry, not sure i understand that last comment.  this shouldn't require a change on the server side, but a client who is connecting to an http-only server would have to edit their client.ini file, which yeah, could be somewhat problematic.  are you thinking about implementing auto-detect for http-only?
[17:05] <stgraber> barry: hmm, hold on, let me read your latest comment because client.ini seems like a very bad idea to me :)
[17:05] <Tassadar> barry: well system-image-server generates my channel.ini with address according to etc/config
[17:05] <Tassadar> it could generate it with use_https: false, if I set it in my server's etc/config
[17:06] <Tassadar> but using current port options (with 0 == don't use this one
[17:07] <Tassadar> ) seems better to me
[17:07] <Tassadar> (to a person who isn't familiar with system-image at all >_>)
[17:07] <stgraber> barry: commented in the bug
[17:15] <Laney> mpt: We got a system-settings bug complaining that "free space" tells you all of the free space on the system, rather than just the amount of space available for the home directory. What's it supposed to be?
[17:19] <Laney> If it were to be something other than all free space then you'd want to list the types of free space differently
[17:22] <Laney> I'll assign the bug instead. :)
[17:25] <barry> stgraber, Tassadar more thoughts in comment #3
[17:28] <barry> Laney: i have a patch in my trunk now, and it passes all the tests.  i'll adapt it to a quilt patch for landing-10 after lunch.
[17:28] <Laney> barry: nice one
[17:29] <barry> Laney:  4 files changed, 39 insertions(+), 17 deletions(-)
[17:29] <stgraber> barry: replied
[17:29] <Laney> barry: if you push it then I can build a package to test quickly
[17:29] <barry> but really that's more than necessary for quilt, since it includes NEWS and version bump
[17:29]  * Tassadar just leaves it to you, I don't know enough to say anything useful about the implementation - I can probably write those few lines of python once you decide what to do though)
[17:29] <Laney> will be going in 30
[17:29] <barry> Laney: okay, let me quiltify and push before lunch
[17:29] <Laney> oh I just meant to your work branch, but that works ;-)
[17:30] <barry> Laney: yeah might as well get the ci train wheels churning :)
[17:30] <Laney> wfm
[17:31] <Laney> could even publish today...
[17:45] <barry> Laney: i just pushed an update: 2.1-0ubuntu4.  doing a local build here too for verification, but i figured you could get the ci train rolling out of the station in parallel
[17:46]  * barry -> lunch
[17:47] <Laney> barry: roger, will build now
[18:12] <guinness6554> Hi. I am trying to port the ubuntu touch for nexus 5.  I know that there are people who already dealing with I just wanna do it 4 fun and I am a bit stacked. Is there anybody who could help me a bit?
[18:15] <Tassadar> guinness6554: there is no need to port anything, there are images for N5 and the code is in official repositories
[18:16] <effbiai> hi, anyone here running ubuntu touch on i9505 (galaxy s4)? i got it installed and when trying to boot it, it "freezes" at galaxy s4 boot screen. tho.. i am able to connect to it with adb
[18:16] <effbiai> in adb (shell) i'm able to do normal linux commands like list mounts, dmesg, etc
[18:16] <effbiai> any hints on what to troubleshoot?
[18:20] <ogra> effbiai, well, check logs and such
[18:20] <effbiai> i've checked dmesg. is there a spesific log i should check? a log in /var/log/somewhere maybe?
[18:33] <balloons> does 207 feel a bit sluggish to anyone else?
[18:35] <aquarius> if running dual-boot Ubuntu/Android on an N4, how do I update apps?
[18:36] <ogra> aquarius, use the app updater
[18:36] <rsalveti> balloons: maybe apport is getting a crash?
[18:36] <aquarius> ogra, that being System Settings > Updates ?
[18:36]  * ogra only tired 207 on flo and maguro ... on one it flies the other is always sluggish ... 
[18:36] <balloons> hmm could be.. it's just noticeably sluggish.. I'll look
[18:36] <ogra> aquarius, nope, the app in the click scope
[18:37] <ogra> aquarius, same icon as the updater in system settings
[18:37] <balloons> rsalveti, I don't see apport running
[18:37] <ogra> balloons, /var/crash ?
[18:37] <rsalveti> balloons: which device?
[18:37] <balloons> rsalveti, ogra I'm on an n4
[18:37] <aquarius> ogra, I don't seem to have that. Searching for "Update" on the apps scope doesn't show anything.
[18:38] <balloons> last crash is from feb 21 so :-)
[18:38] <ogra> aquarius, oh, then you are one of the few unlucky people that used an image from proposed atht accidentially had this app dropped
[18:38] <ogra> (we never promoted one with it missing iirc ... )
[18:39] <aquarius> ogra, I shouldn't be... I don't think I'm using -proposed, I'm just using trusty
[18:39] <aquarius> ogra, how can I check?
[18:39] <ogra> well, then i probably mis-remember
[18:39] <aquarius> I "upgraded" (that is: reinstalled, from the Android dual boot app) a few days ago, I think
[18:40] <ogra> aquarius, it was gone between 195 and 202
[18:41] <aquarius> ogra, ah, OK. How can I know what I'm running?
[18:41] <ogra> "about this device"
[18:41] <aquarius> ah, I'm on r194
[18:41] <aquarius> so I should upgrade, shouldn't I?
[18:41] <ogra> hmm
[18:41] <aquarius> has there been a promoted image since then?
[18:41] <ogra> you just pointed out a serious issue
[18:41] <aquarius> (I'm not running -proposed)
[18:42] <ogra> right
[18:42] <ogra> hasnt
[18:42] <aquarius> ogra, that's why I'm bringing it up here rather than, e.g., whining on reddit ;)
[18:42] <ogra> thats a little serious
[18:42] <aquarius> ogra, yeah. I can't upgrade any apps :)
[18:42] <aquarius> ogra, I thought I was going mad
[18:42] <ogra> we cant really promote anything atm ...
[18:43] <aquarius> ogra, OK -- if the answer is "you can't upgrade any apps until there's a new promoted image, and then you'll be able to again" then I'm OK with that
[18:43] <ogra> yes ... you could hack around that
[18:43] <aquarius> presumably I can "upgrade" an app by, e.g., uninstalling it and then reinstalling it :)
[18:43] <ogra> by making the image writable and installing click-update-manager
[18:44] <ogra> (and making it ro after that again)
[18:44] <aquarius> no, no, no writeable image for me. If I do that then I stop being a normal person and start being a haXX0r and I can never trust that my apps will work on normal devices ever again ;)
[18:45]  * aquarius uninstalls and reinstalls app
[18:45] <ogra> heh, k
[18:47] <balloons> someone mentioned phablet-screenshot is broken, and indeed it seems to be. Can anyone recommend how to get a screenshot atm?
[18:48] <aquarius> ogra, is there anything else I should do to notify people about this issue? ("Tell ogra" seems to be enough from my point of view, but you may disagree ;))
[18:48] <ogra> aquarius, already escalated it
[18:48] <aquarius> what a star
[18:48] <ogra> aquarius, but there isnt much we can do, the images are not in a promotable quality
[18:49] <aquarius> ogra, yeah, I understand that, and that's OK -- now that I know that I'm not mad, it's a known bug, and it's being dealt with, that helps. It would be nice if it were fixable somehow, though...
[18:49] <aquarius> (not "ssh in and run these commands" fixable, but "promote image 194.5" or something ;))
[18:50] <ogra> yeah
[19:09] <barry> Tassadar: comment #8 has an implementation plan.
[19:11] <Tassadar> barry: okay, thanks, will try to do that in a minute
[19:12] <barry> Laney: we have a successful s-i 2.1-0ubuntu4 in landing 10 PPA.  can you test that and see if it does what you need?
[19:24] <Laney> barry: yep, but it'll need to be tomorrow morning now
[19:25] <Laney> barry: you could try to trick seb128 into doing it
[19:25] <barry> Laney: ack.  i'll test it too.
[19:26] <barry> maybe mandel has some cycles to test it as well
[19:42] <asac> davmor2: do you have bugs about autopilot on qt5.2?
[19:42] <asac> davmor2: Mirv said there were bugs identified by you
[19:45] <davmor2> asac: the crashes are listed on the spreadsheet I need to complete the autopilot tests latter this week once the mwc stuff is out of the way.  I hadn't publish bugs for the autopilot failures, but did for the manual testing failures.
[19:46] <asac> davmor2: do all APs crash? or just some?
[19:46] <asac> davmor2: is AP crashing itself?
[19:46] <davmor2> asac: most of the manual testing failures have either been addressed or have been assigned
[19:46] <asac> davmor2: do you have a link to spreadsheet?
[19:46] <davmor2> asac: just some
[19:47] <thomi> davmor2: asac: please be careful with your language. I *think* you mean "acceptance test failures", not "autopilot failures"... unless you really do mean autopilot failures, in which case you should let me know :)
[19:47] <asac> davmor2: did you ever try to somehow validate how the apps in store behave with qt5.2? i really we need to do what i say here: https://lists.launchpad.net/ubuntu-phone/msg06611.html
[19:47] <davmor2> asac: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdGI4dGllUUxyZGxhc0tZWFhqNnJaaFE#gid=0  the red ones are the test failures orange were test passes but either a crash or extra info in the logs produced that might be important
[19:48] <davmor2> asac: popey is on that
[19:48] <popey> to be clear, I'm starting the apps to make sure they start, not spending ages testing each one
[19:49] <asac> popey: would it make sense to send a call for testing to the appdev community? like i suggested in the mail here: https://lists.launchpad.net/ubuntu-phone/msg06611.html ?
[19:49] <davmor2> meh popey I was just writing something similar but you beat me to it :)
[19:49] <asac> or does anything need to happen brefore that?
[19:50] <popey> asac: i think balloons wanted to spin up a community around testing apps, this would be a good bootstrap for that
[19:50] <asac> balloons: can we get started on that today :)?
[19:51] <davmor2> asac: before we can do the big push for 5.2.1 we need the qt multimedia sorting.  Currently no sound, no ring tone, speaking or audio in calls etc.  Once that fix lands I think most of the issues will slowly go away
[19:51] <balloons> asac, popey yea the plan was to kick it off today. We have to nail down the logistics as we discussed yesterday popey
[19:52] <asac> ChickenCutlass: ^^ qtmultimedia seems to block push for qt5.2
[19:53] <asac> who did qtmultimedia things in the past?
[19:54] <davmor2> asac: I'm not sure if it has landed yet I've been heavily testing mwc images so that has been my priority.  Mirv iirc has pointed it out that it needs fixing  so I believe did chase it initially but could be wrong
[19:55] <asac> davmor2: so you say we have a fix. thats good
[19:55] <asac> thought we didn thave that
[19:56] <davmor2> asac: I don't know, I just know that Mirv started chasing it from a conversation we had
[19:57] <davmor2> asac: let me see if I have some notes on it
[20:01] <asac> popey: how does the current "startup test" look like? is that all good so far?
[20:02] <asac> popey: do you have a list or something?
[20:02] <popey> asac: not finished yet... will update in a bit.. meeting
[20:03] <asac> thx
[20:04] <davmor2> asac: so current there is a qt-multimedia patch that drops the qt-multimedia components as they aren't compatible with 5.2.1.  As soon as it is then new package will build with it from what I can understand.  There was not media when I ran the autopilot tests last week on the 18th
[20:05] <asac> rsalveti: ChickenCutlass: who did qtmultimedia glueing to our sound stack for qt5.0? jim?
[20:05] <rsalveti> asac: yes
[20:05] <rsalveti> asac: is that the only blocker?
[20:05] <rsalveti> if so we should just port it to 5.2 as the new mediaservice will take at least another week
[20:06] <asac> rsalveti: seems its the big blocker preventing us to send out a wider call for testing to app community
[20:06] <rsalveti> alright
[20:06] <asac> balloons: can you confirm?
[20:06] <asac> or is there anything else that prevent us?
[20:07] <balloons> outside of multimedia? I don't know of anything else preventing moving, but multimedia is a big one :-)
[20:07] <davmor2> rsalveti, asac: I think the camera app is failing completely because of it, and as blockers go on a phone not being able to make a call is about as big as it gets ;)
[20:07] <asac> balloons: and sending out call for testing without MM doesnt make sense?
[20:08] <rsalveti> davmor2: issues with the dialer-app?
[20:08] <rsalveti> I can take a look at this package
[20:08] <balloons> asac, we can send out a call to test the apps with that known caveat, but I suspect it's one of the things we really want feedback on
[20:08] <davmor2> rsalveti: no sound and no audio
[20:08] <asac> davmor2: true. but is that also blocking app community from doing an intial round of useful testing on qt5.2? not sure how many use MM there
[20:08] <rsalveti> davmor2: that's interesting as it's not related with qt at all
[20:09] <asac> thomi: have you seen https://bugs.launchpad.net/ubuntu/+source/autopilot/+bug/1284316 ?
[20:10] <davmor2> rsalveti: so how does the audio stack work if it isn't through qt?
[20:10] <thomi> asac: yes, I agree with balloons comments on that bug.
[20:11] <thomi> asac: also, the fact that it exists independantly of the autopilot version seems to indicate that it's not a bug in autopilot itself
[20:11] <thomi> but rather, the tests fail poorly. We've already talked about this in the QA team, and elopio has a plan to fix things up, but we're not sure what the timeframe will be
[20:11] <rsalveti> davmor2: audio for phone calls is different, but yeah, qt calls telepathy-ofono, which calls pulseaudio
[20:13] <davmor2> rsalveti: I mean I get no sound from the music play, none from the internet, no video/sound from the videos scope, and then no audio from call, no ringtones  all seems pretty much linked but I could be horribly wrong :)
[20:13] <rsalveti> davmor2: oh, ok
[20:13] <rsalveti> let me first port qtmultimedia
[20:14] <asac> thomi: can you guys communicate the outcome of that discussion in bug?
[20:14] <asac> elopio: ^^
[20:14] <ChickenCutlass> rsalveti: its a shame we have to do this twice.  port qtmultimedia.
[20:14] <thomi> asac: elopio, sure, I'll update it now
[20:14] <rsalveti> ChickenCutlass: well, we didn't get the mediaserver sooner
[20:15] <ChickenCutlass> I know
[20:15] <rsalveti> but yeah
[20:22] <thomi> asac, elopio, balloons: my summary: https://bugs.launchpad.net/ubuntu/+source/autopilot/+bug/1284316/comments/4
[20:29] <asac> thomi: awesome thanks. anything we can do short term to get rid of this behaviour? not sure why we suddently start seeing this
[20:29] <rsalveti> asac: maybe because the kernel is behaving properly now regarding cpus on/off?
[20:29] <rsalveti> and using the 4 cpus as well
[20:29] <thomi> asac: I haven't looked at the specific failure yet - that's on my list for later today. I suspect that in the short term we can patch the test case up to do the right thing
[20:30] <rsalveti> that could possibly make asynchronous test cases behave a bit worse
[20:31] <balloons> I would support thomi's notion of addressing the testcases as the first step. If the errors persist, with our fixes it should pinpoint an issue in the app or platform which we can then deal with.
[20:33] <cyphermox> asac: what's this about MM?
[20:33] <asac> cyphermox: qt5.2 hsa broken MM and we need that fixed to do a serious push for 5.2
[20:33] <cyphermox> what do you mean by "MM" though?
[20:34] <asac> balloons: i think we shouldnt wait for MM fix... maybe we can make a small round of testing before that?
[20:34] <asac> but tell folks that audio/mm isnt working so they shouldnt report issues related to that?
[20:34] <rsalveti> MM could also be modem manager
[20:34]  * cyphermox still parses "MM" as ModemManager
[20:34]  * asac would like to get promissing feedback as soon as we can
[20:34] <asac> cyphermox: hehe qtmultimedia
[20:34] <asac> for a moment i wondered why you are so concerend :)
[20:35] <cyphermox> bah
[20:35] <cyphermox> there is a libmm-qt ;)
[20:35] <balloons> asac, sure.. so what image do we want to point people at ?
[20:36] <GreySyntax> would dmesg output be the best way to debug where a boot fails?
[20:37] <asac> balloons: good point. lets wait till tomorrow. i hope we get a few more issues fixed which makes testing even more valuable i figure and we can also sync with mirv again.
[20:37] <asac> to ensure that the ppa is really ready for this
[20:41] <gnuts> Hello everyone, I'm curious why there is no ~flo.zip only a ~flo.img in the ~/current directory. there are zips of the others. Can anyone tell me why or where I can find them?
[20:44] <rsalveti> gnuts: as flo is based on aosp, there's no zip anymore
[20:44] <rsalveti> just pure img files
[20:45] <rsalveti> the others are also aosp based now, but the old files are still around
[20:47] <gnuts> ok, but I'd like to flash the current files to my nexus 7 (2103) using multirom. I guess I'll wait and keep watching xda. thank you
[20:49] <Tassadar> gnuts: I'll update the android app to support installing new official images soon
[20:50] <GreySyntax> is there a recommended way to modify scripts/touch so the change is applied in every build?
[20:52] <gnuts> Wow, hearing directly from the source! Thank you. I'll keep watch.
[20:53] <Tassadar> gnuts: I'm trying to put things in place also to support N5, not sure how long will that take, should be a few days max
[21:02] <Tassadar> barry: can I run the tests on ubuntu computer or do the require to be ran on Ubuntu Touch device?
[21:09] <barry> Tassadar: you can run it on a desktop with a hacked up ini file.  just point all the paths to some tempdirs
[21:10] <Tassadar> when I run "python3 setup.py test" in the root dir, it seems to try to reboot the computer during some tests
[21:10] <Tassadar> (which fails, because it's not root, and then it's stuck waiting for the reboot I guess)
[21:18] <rtyupo> hi
[21:19] <rtyupo> anyone there ?
[21:20] <rtyupo> i would like to know it possible to install ubuntu-touch ?
[21:24] <matv1> rtyupo yes it is possible. but it depends on what device you want to install it on
[21:24] <rtyupo> iphone 5
[21:24] <GreySyntax> then no
[21:24] <rtyupo> why not possible ?
[21:24] <matv1> nope
[21:25] <matv1> touch is being deveoped on android hardware
[21:25] <GreySyntax> because apples secureROM is still 'secure' on modern devices you modify the boot-chain
[21:26] <matv1> question: I am confused: is Maguro now officialy desupported?
[21:28] <rtyupo> well is it possible to install IOS6 and IOS7 on dualboot on IPHONE 5
[21:31] <Tassadar> barry: http://bazaar.launchpad.net/~vbocek/ubuntu-system-image/support_http/revision/241 my code now looks like this, but I'm kinda lost in all the tests :/
[21:32] <matv1> and if so, why are images still being built and tested up to today?
[21:33] <rtyupo> bootcamp for iphone not exist ?
[21:34] <barry> Tassadar: that looks pretty good.  i suggest one small semantic change: DISABLED_PROTOCOL = object() and then test for identity instead of equality.  e.g.  if self.service.http_port is DISABLED_PROTOCOL
[21:35] <barry> Tassadar: as far as end-to-end tests, i am happy to write them when i merge your branch if you'd like.  that part of the test suite can get pretty complicated
[21:37] <pmcgowan> matv1, maguro is on its way out, but it still works and we have many devs using it
[21:38] <Tassadar> barry: yeah, I think that would be better. I don't even know how to run those tests. Should I remove those 3 I've added into test_config.py?
[21:38] <barry> Tassadar: naw, keep them in your branch.  i'll use that as a starting point and will probably flesh out all the corner cases.
[21:39] <barry> Tassadar: the way i run individual tests are:
[21:39] <barry> `tox --notest -r` to set up the test environment (don't need to do this if you've already done a full `tox` test)
[21:39] <barry> then:
[21:39] <barry> .tox/py33/bin/python -m nose2 -v -P test_config
[21:39] <barry> with variations thereof
[21:39] <Tassadar> okay. I'll change that DISABLED_PROTOCOL and add overriding of [system] as separate commit
[21:40] <barry> Tassadar: sounds good.  do please do a merge proposal once you're happy with the branch.  we can either continue to discuss on the mp, or i can merge + tweak
[21:40] <barry> Tassadar: and let me know when you've signed the cla :)
[21:40] <matv1> pmcgowan yes i saw that todays image test even looked good. So would bug report would still get looked at if one would report them against Maguro? and what about after the desupport date?
[21:41] <Tassadar> barry: I've signed it already, it said that a member or canonical team will contact me shortly)
[21:41] <pmcgowan> matv1, yes bugs would get looked at, and not sure when it might be officially cut off, maybe 14.04
[21:41] <barry> Tassadar: great, thanks
[21:42] <matv1> pmcgowan thank you
[21:44] <daker> Q: can UT run on Meizu MX2 ?
[21:52] <Tassadar> bean: http://bazaar.launchpad.net/~vbocek/ubuntu-system-image/support_http/revision/242 This isn't correct is it, because channel.ini would have to have [system] section (else it would load just empty Bag). I should check if the [system] is present and then overwrite it I guess..?
[21:52] <Tassadar> ups, wrong nick
[21:52] <Tassadar> barry: ^^
[21:52] <bean> o,.o
[21:54] <GreySyntax> rtyupo: no it doesn't
[21:54] <rtyupo> what doesn't ?
[21:55] <GreySyntax> "bootcamp for iPhone"
[21:55] <rtyupo> is it possible to install grub ?
[21:55] <GreySyntax> "no"
[21:55] <barry> Tassadar: that's a good point.  override will only ever be true when loading a channel.ini, but "legacy" channel.ini files may not have the [system] section.  you're probably right about first checking whether parser['system'] exists.  alternatively, Bag can be given an .update() method, but that's more work (i.e. refactoring & tests)
[21:56] <GreySyntax> you can't modify the boot process at all you can only boot iOS
[21:56] <barry> Tassadar: what do you feel up for? :)
[21:56] <rtyupo> tell me how to do it ?
[21:56] <GreySyntax> you can't
[21:56] <rtyupo> i would like to run IOS6 AND IOS7 on dualboot
[21:57] <GreySyntax> you can't
[21:57] <GreySyntax> it's impossible
[21:57] <rtyupo> how to modify the boot process
[21:57] <rtyupo> ?
[21:57] <GreySyntax> see above
[21:57] <Tassadar> barry: well, how should it work? if section is present, then remove all existing values and use only the ones specified in channel.ini, or just overwrite the existing values and leave the ones not specified in channel.ini as-is?
[21:57] <rtyupo> ok understand
[21:58] <Tassadar> barry: given how [service] override works, it should probably remove all existing options and add only the ones in channel.ini
[21:58] <barry> Tassadar: for the former, i think implementing a Bag.update() would be a better approach.  otherwise we can document that channel.ini must override everything or nothing (i.e. if the section exists, it must include all settings)
[21:59] <rtyupo> is there any snifer for IOS7 boot process  ?
[21:59] <GreySyntax> nope
[22:00] <GreySyntax> rtyupo: you'd be best to direct your iOS related questions to #openjailbreak or #jailbreakqa
[22:00] <rtyupo> ok
[22:00] <GreySyntax> does anybody know how to modify the ubuntu ramdisk, i need to make a few changes to /scripts/touch
[22:17] <Tassadar> barry: http://bazaar.launchpad.net/~vbocek/ubuntu-system-image/support_http/revision/242 I've added that Bag.update() and changed config.py so that both [service] and [system] section use it
[22:18] <Tassadar> barry: note that this changes how overriding of [service] works - now it just updates existing values
[22:20] <barry> Tassadar: that looks pretty good
[22:22] <Tassadar> barry: I'll submit merge proposal, then
[22:22] <barry> Tassadar: cool.  i'll work out the tests and comment on the mp, or ping you here if i have any questions
[22:27] <Tassadar> barry: does system-image server have no documentation? I'd add info about that "disabled" value in there too, but I can't see any man files in it's repo
[22:27] <barry> Tassadar: ini-manpage.rst
[22:27] <Tassadar> I mean etc/config in server, that's a different file
[22:33]  * barry looks at stgraber for server docs
[22:34] <stgraber> not much doc on the server side, though I've got examples around that say port=0 so I'll just push a change to the version tarball generator to set =disabled when I have =0 in my config
[22:36] <Tassadar> stgraber: I've found a mistake in config.example when I was setting up the server - http://hastebin.com/poxayofote.diff - should I make merge request for that?
[22:37] <stgraber> Tassadar: nah, I'll just fix it, thanks. That syntax changed a while back, I guess I just forgot to update the example...
[22:38] <Tassadar> k
[22:39] <Tassadar> stgraber: another "problem" I had with it was that remote-system-image tries to download rootfs file for each device, and when the device is not present on system-image.ubuntu.com (i.e. hammerhead) it fails
[22:40] <Tassadar> so I've added option to hardcode the device name it checks for
[22:40] <Tassadar> not sure if you want to do something about that, but ports are likely to encounter the same problem
[22:45] <stgraber> Tassadar: adding a device= keyword to remote_system_image would be fine with me
[22:45] <Tassadar> I did exactly that) I'll clean it up a bit and submit it)
[22:46] <stgraber> Tassadar: cool, please make sure we still get 100% test coverage with your change and that the test suite passes with both python2 and python3
[23:00] <Tassadar> stgraber: should I add test for that device=X option?
[23:04] <stgraber> Tassadar: yes you should, I never push to trunk with less than 100% code coverage
[23:24] <Tassadar> stgraber: I've submited the merge proposal, all tests pass (assuming running tests involves just "tests/generate-keys; python tests/run; python3 tests/run")
[23:25] <Tassadar> hm, except they shouldn't pass, that test I've copypasted is wrong
[23:33] <nhaines> effbiai: yes, SMS workds perfectly.  Phone calls and sound don't work at all (unless you get the ALSA config files from the ubuntu-phone ML, which plays sound great but I haven't tested calls yet).