[03:54] <Hawk_> like to try out the newer version of mir
[03:54] <Hawk_> can I just installed related debs?
[03:55] <Hawk_> such as https://launchpad.net/~mir-team/+archive/ubuntu/staging/+build/7842048
[04:27] <Hawk_> QOpenGLShader::link: "--From Vertex Shader: Error: Symbol textured defined with different precision in vertex and fragment shaders.
[04:27] <Hawk_> any idea what could cause this in unity log?
[04:27] <Hawk_> icons not showing in dash and app scope
[04:41] <RAOF> Hawk_: That's a GL error; specifically, it seems that QOpenGLShader is constructing a with mismatching precision on one of its shaders.
[04:42] <RAOF> Since it seems you've got this problem after a driver update, it might be that the driver is now being more picky, or that QOpenGLShader isn't specifying the precisions and the driver has changed defaults.
[04:47] <Hawk_> i am try a port on xperia L
[04:48] <Hawk_> its not an update issue
[04:48] <Hawk_> can a particular fussy app cause this?
[04:50] <RAOF> Hawk_: It's not an app being fussy; it's your graphics drivers.
[05:25] <lotuspsychje> http://linux.softpedia.com/blog/libreoffice-viewer-for-ubuntu-touch-making-great-progress-491039.shtml
[05:47] <Hawk_> RAOF, i see. guess it out of my league
[06:58] <mj-meo-dmt> good day everyone
[06:58] <mj-meo-dmt> I want to find out if anyone here tried ubuntu touch on the Huawei ascend p1?
[07:04] <Stanley00> mj-meo-dmt: you mean this one? https://wiki.ubuntu.com/Touch/Devices/u9200
[07:04] <Stanley00> mj-meo-dmt: last edit 2013, I'm not sure if anything new, but the current page look not so good
[07:15] <dholbach> good morning
[07:18] <mj-meo-dmt> Hi Stanley00 sorry was afk, ahh okay i see uhhmm missed that page..  Damn thats pretty sad because im pretty fed up with this 4.0.3 now...
[07:21] <mj-meo-dmt> yeah that sure doesnt look good.
[07:22] <Stanley00> mj-meo-dmt: well, you can try contact the maintainer, I see that he have some recent update on his launchpad account, there may have many good update there
[07:24] <mj-meo-dmt> Sure thing thanks ill try to get hold of him, Thanks
[08:28] <JamesTait> Good morning all; happy Monday, and happy Buy a Book Day! 😃
[08:54] <duflu> Did we recently release changes to touch/gesture logic?
[08:54] <duflu> Or is just my mako broken?
[08:57] <duflu> greyback, Saviq: Did we just change anything to do with gesture recognition? My mako is suddenly quite erratic. Can't notice edge swipes properly even
[08:58] <Saviq> duflu, did not, but there's a bug about mako, its input area manages to grow outside of the phone somehow
[08:58] <Saviq> bug #1408263
[08:58] <Saviq> any chance that's that?
[08:59] <duflu> Saviq: A bit different. I need to rule out pure Mir first...
[09:00] <Saviq> duflu, you guys working on wily, right?
[09:00] <duflu> Saviq: yes
[09:00] <Saviq> there's likely not enough attention being paid to wily
[09:00] <Saviq> vivid+overlay is still our main target
[09:02] <duflu> Saviq: Nevermind. My touchscreen is screwed. Even with pure Mir demos.
[09:02] <Saviq> kk
[09:02] <duflu> It works slightly and intermittently
[09:02] <anpok_> Saviq: while testing silo-014 I experienced some odd stuff in camera
[09:02] <anpok_> -app.
[09:02] <Saviq> anpok_, oh?
[09:03] <anpok_> photos looked fine, but video at first did not take up the whole screen
[09:04] <anpok_> it first seemed like it would leave an area untouched for the small preferences tool bar..
[09:04] <duflu> Why must there still be so many variables?
[09:04] <anpok_> but it also made a low resolution video..
[09:04] <duflu> So many different bugs need fixing simultaneously
[09:04] <anpok_> after a restart of camera-app it worked normally..
[09:05] <Saviq> anpok_, doesn't seem like anything we (mir or unity8) have control over
[09:05] <anpok_> other than that mako / silo-014 on image 232 worked fine
[09:06] <Saviq> anpok_, I just tried on mako/wily and indeed the video played back had maybe some 2-3% blank edge
[09:06] <Saviq> more on the longer edges than the short edge
[09:06] <anpok_> it seems to depend on the system rotation during start..
[09:06] <Saviq> oh, that might be indeed
[09:07]  * Saviq tries
[09:07] <anpok_> but i cannot reproduce the issue anymore.. the space just seemed to match the difference height/width between
[09:11] <Saviq> anpok_, everything seems fine here, too, I can only notice some margins in the camera app, video is HD
[09:12] <duflu> Goodbye mako.
[09:12] <Saviq> anpok_, maybe you somehow got into a lower res recording mdoe
[09:12] <Saviq> duflu, that bad?
[09:12] <duflu> Saviq: It's low level, maybe kernel or hardware. I need to try reflashing
[09:13] <duflu> Touches go missing a lot (visible in fingerpaint and target too)
[09:13] <duflu> The same device has been fine for quite a while. I only updated over the air today
[09:14] <Saviq> anpok_, I can easily get the camera app confused by changing video resolution and toggling between front/back camera, there's a lot of stretched images and such
[09:15] <Saviq> but it's all the app doing that
[09:38] <duflu> greyback, Saviq: I've noticed (especially on wily) that the welcome wizard is exhibiting Apple/Lollipop level scrolling smoothness (when selecting language). What's so different about the wizard that makes it fantastically smooth?
[09:39] <greyback> duflu: it runs as part of the shell
[09:39] <duflu> greyback: Ah, yes.
[09:40] <greyback> duflu: am looking forward to your qtmir smoothness patch! :)
[09:40] <guest42315> me2
[09:40] <duflu> greyback: Annoyingly I'm losing count of the number of fixes that have to all work together
[09:40] <duflu> But we're getting there
[09:41] <greyback> duflu: is there an obvious way we can measure the improvement, aside from fps?
[09:41] <duflu> greyback: Try flashing a device with wily. The welcome wizard's responsiveness really is far ahead of everything else
[09:41] <greyback> buffer acquire/release times
[09:42] <duflu> greyback: The Mir client perf report also mentions number of unique buffers (and the queue cycle latency)
[09:43] <duflu> greyback: Also, just landed: Mir's latency acceptance test now works and gives proper latency numbers
[09:43] <duflu> (coming in 0.16)
[09:43] <greyback> duflu: ok. I would like to aim towards gathering numbers on these things, with the goal to ensure we don't regress
[09:44] <duflu> greyback: It's actually enforced in CI now. Latency must be in a strict range or failure
[09:44] <duflu> That's not really new, but the test now works as of today
[09:45] <greyback> duflu: in mir's perhaps :) I wants me the same in qtmir!
[09:46] <duflu> greyback: You know what I was working on in QtMir was actually just smoothness. If it goes well, that will allow Mir's latency improvements but I fear we're also waiting on some GL optimizations (like making the dash consistently quicker to render)
[09:56] <duflu> greyback: When do you use wakelocks, btw? Do you have any numbers on their benefit?
[09:57] <greyback> duflu: wavelock only grabbed when app running and in foreground
[09:58] <duflu> greyback: For the duration of the app?
[09:59] <duflu> I thought wakelocks automatically expire so have to be acquired for only short, or regular periods. But could be wrong
[09:59] <greyback> duflu: no, they're acquired and released by qtmir. they don't time out
[10:00] <duflu> greyback: In that case they're either ineffectual or we're holding them wrong... https://bugs.launchpad.net/qtmir/+bug/1488386
[10:01] <greyback> duflu: then it's not related to wakelocks. Wakelock is held while app running and in the foreground.
[10:02] <greyback> use "power-cli list" to check
[10:02] <greyback> powerd-cli
[10:02] <duflu> greyback: Right, we may well be using them correctly, but they're still not helping us
[10:03] <greyback> duflu: they do prevent cpu dropping to low power mode, keeping system a bit more responsive
[10:05] <duflu> greyback: Hmm, OK, I guess it could always be worse. My observations are that the scaling and frequency governors are not affected by them then...
[10:05] <duflu> At least not sufficiently. Not as much as just touching the screen
[10:05] <greyback> must be something else at work so
[12:07] <zzarr> hello everyone! I'm still loving my Ubuntu phone
[12:07] <zzarr> :)
[12:10] <popey> :)
[12:10] <davmor2> zzarr: \o/
[12:18] <zzarr> :)
[12:28] <undertasker> I did it. I ordered an Ubuntu phone.
[12:28] <popey> :)
[12:28] <undertasker> Was too pissed about Google in general and especially about my Android phone.
[12:29] <undertasker> BTW: Does sshunnel run on Ubuntu touch?
[12:32] <zzarr> gratz undertasker, I think you should be able to run an ssh tunnel
[12:33] <ogra_> ssh server and client are preinstalled (server is disabled by default and only allows login via key auth once you enabled it)
[12:34] <teve> Is it so that backgrounded apps will loose network access?
[12:35] <teve> I tested quicly and as soon as I change app, ssh connection dies.
[12:35] <ogra_> backgrounded apps recieve a SIGSTOP signal
[12:35] <ogra_> and once they go back into foreground a SIGCONT
[12:35] <ogra_> so it depends how the timeout of the server is set ...
[12:36] <ogra_> (for keepalive)
[12:36] <teve> also if the terminal gets locked, unlocking wipes existing session.
[12:37] <ogra_> sounds like a terminal bug to me
[12:40] <undertasker> Can I run services?
[12:41] <ogra_> without making the system writable you can only run session services for the user (by storing upstart jobs in ~/.init/)
[14:04] <popey> greyback_: yo. you mentioned last week that silo0 was all janky and was being moved away from, is there now some way to install latest unity/mir and it be usable?
[14:05] <greyback_> popey: by "usable" you're asking specifically about multimonitor/docking phone to monitor?
[14:05] <popey> ya
[14:06] <greyback_> popey: we've still work to do before silo0 can go away entirely unfortunately.
[14:06] <popey> greyback_: okay, but silo0 was broken in such a way that it doesn't work / isn't installable right now?
[14:06] <greyback_> silo0 just kept for demos really - it is installable on top of the stable image
[14:06] <popey> ok
[14:06] <popey> i misunderstood
[14:08] <greyback_> popey: there are instructions at the end of https://docs.google.com/document/d/1EtDf3MXVrTaW3xfPNUALYmKTNmTHxBAAtTmgnpRX-E4/edit# if you'd like to give it a whirl
[14:08] <popey> ta
[14:08] <greyback_> works best on N7
[14:08] <popey> greyback_: magic, thanks.
[14:08] <greyback_> np
[14:27] <Thaurwylth> Are SD storages a bottleneck compared to traditional HD's? Let's say I create a new partition on a Windows laptop with Ubu desktop installation for dual boot. Or my Android device has little native disk space so I add more storage and put part of Ubuntu Touch there. Or whatever. Is this going to severely affect performance?
[14:29] <mcphail> Thaurwylth: I used to do this with my old Nexus One. It was slower, and was at the borderline of annoyance.
[14:35] <mardy> jdstrand: hi! When you have some time: https://code.launchpad.net/~mardy/click-reviewers-tools/new-account-hook/+merge/268445
[14:36] <dhbiker> interesting glitch on arale and RC proposed
[14:36] <dhbiker> if you have the screen always on
[14:36] <dhbiker> and it dims
[14:37] <dhbiker> the music stutters right after it dims
[14:37] <dhbiker> :D
[14:37] <Thaurwylth> Augh, OK. So you'd say it was a serious bottleneck?
[14:37] <Thaurwylth> Mcphail
[14:38] <mcphail> Thaurwylth: it was noticeable on that device
[14:38] <Thaurwylth> OK, I'll take your word for it. Are there in general benchmarks for SD speed somewhere? I guess traditional HDD speeds are pretty well behaved.
[14:40] <mcphail> Thaurwylth: no idea, I'm afraid
[15:06] <jgdx> dhbiker, can you file that?
[15:07] <dhbiker> i would but i don't know where yet :D
[15:07] <dhbiker> still fairly new ~3 weeks with the device
[15:18] <mcphail> Still getting frequent lags on current OTA, with "top" showing dbus-daemon consuming up to 99% of CPU. dbus-monitor has lots of entries with "INTERFACE=org.freedesktop.NetworkManager/AccessPoint/variousnumbers". Most lags happen at work, and may be related to poor 3G signal, I suppose. Any way I can debug this further without access to a decent computer with adb etc?
[15:18] <popey> are there lots of networks near you?
[15:18] <mcphail> popey: half a dozen
[15:18] <popey> are there a small number of network SSIDs with lots of access points?
[15:19] <mcphail> popey: I suspect that would be right. I work in a biggish building
[15:19] <popey> known bug
[15:20] <mcphail> aah. Workaround?
[15:21] <popey> bug 1480877
[15:21]  * popey pokes john-mcaleely ^
[15:21] <popey> We all saw this in the Canonical office a couple of weeks ago
[15:22] <popey> Looks like Tony is on it
[15:22] <mcphail> popey: that looks like the culprit. Cheers. Has been driving me mental
[15:22] <popey> ditto
[19:01] <coin> Hi. I asked myself why there is (to my knowledge) no application on mako that uses the compass. Looking at /sys, I can't find the magnetometer, which is, according to the Nexus 4 spec, an AK8964, nor the gyroscope/accelerometer, which is a MPU-6050. Looking at the code source of vivid-mako, I see that it contains a code for the magnetometer for AK8975, and not AK8963. Why ? And why the compass seems not to be accessible for applica
[19:01] <coin> tions ? Any idea ?
[19:03] <dhbiker> jgdx, where do i report that ?
[19:04] <jgdx> dhbiker, it sounds like pulse, but I'm not 100% sure. Maybe file it against canonical-system-image? https://bugs.launchpad.net/canonical-devices-system-image/+filebug
[19:12] <popey> coin: does the sensor status app not have a compass entry?
[19:15] <rschroll> Question on app review: How long show I expect to wait for a manual review of an app that failed the automated review?
[19:17] <dhbiker> ty jgdx
[19:18] <popey> rschroll: let me take a look.
[19:18] <coin> popey, yes, that is the point: It says that no datas are available for gyroscope and compass (and all others, except GPS and accelerometer).
[19:18] <coin> But the nexus 4 seems to have a gyroscope and an accelerometer.
[19:18] <rschroll> popey: click app #3405, if you want to see why I'm asking.
[19:18] <popey> rschroll: ah, one for jdstrand who is on vacation today I suspect.
[19:18] <coin> it has according to the harware specs
[19:19] <coin> hardware
[19:19] <popey> coin: ah sorry, I don't know why, maybe we don't expose that some how, I would file a bug at the link jgdx provided though
[19:19]  * popey checks on his bq e4.5
[19:21] <rschroll> popey: Should I try him tomorrow?
[19:21] <popey> rschroll: I would.
[19:21] <rschroll> Will do.  Thanks!
[19:21] <popey> coin: yeah, no data on e4.5
[19:21] <popey> np rschroll
[19:26] <coin> popey, thanks ! Hope that all the sensors will be exposed !
[19:28] <lpotter> coin: that's because there is no QCompass backend in the ubuntu QtSensors plugin
[19:28] <popey> me too!
[19:29] <lpotter> https://bugs.launchpad.net/qtubuntu-sensors/+bug/1398809
[19:31] <coin> lpotter, thanks !  That explains why there is no Qt application using some sensors. But they should be exposed on /sys, at least.
[19:31] <lpotter> yes. but apparmour will not grant access, I believe
[19:32] <lpotter> I could be wrong though
[19:34] <coin> Ah, yes, you must be right. That's another pb.
[19:37] <coin> So I understand that the policy is to expose only the strict necessary (for lib and priviledged procs) on /sys ?
[19:42]  * coin thinks that he should be able to write a priviledged app using the compass
[19:48] <coin> well, lpotter popey thanks
[19:49]  * coin has to leave