[08:00] <Saviq> greyback, ping
[08:02] <greyback> Saviq: pong
[08:42] <seb128> unity8 and several apps have a "search entry" (e.g one with a magnifying glass icon on one side and a crossed circle to clear it on the other side) ... is that using the standard TextField? or is there a custom widget doing that which can be re-used?
[08:44] <seb128> ok, seems like those are TextField with a primaryItem
[09:33] <Cimi> Saviq, why's unity-shell-launcher=2?
[09:33] <Cimi> *what's
[09:33] <Cimi> doesn't get installed with ./build -s
[09:33] <Saviq> Cimi, did you merge from trunk?
[09:34] <Saviq> Cimi, you need ppa:ubuntu-unity/next
[09:34] <Saviq> Cimi, instead of the other PPAs
[09:34] <Cimi> ah
[09:34] <Cimi> Saviq, I have trunk
[09:34] <Saviq> Cimi, do you have ppa:ubuntu-unity/next?
[09:34] <Saviq> Cimi, it's been merged in http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/106
[09:35] <Cimi> Saviq, installing now
[09:35] <Cimi> weird
[09:36] <Cimi> Saviq, which package?
[09:36] <Cimi> Saviq, still complaining
[09:37] <Saviq> damn ^W
[09:37] <Saviq> Cimi, libunity-api-dev
[09:37] <Cimi> Saviq, let's add it to the build deps
[09:37] <Saviq> Cimi, orly?
[09:37] <Saviq> Cimi, it's there
[09:38] <Cimi> Saviq, :\
[09:38] <Saviq> Cimi, ./build will build a unity8-build-deps package
[09:38] <Saviq> Cimi, and install it, installing all the build deps
[09:38] <Saviq> Cimi, ./build -c, btw
[09:38] <Cimi> Saviq, indeed it's in debian control
[09:38] <Saviq> Cimi, when in doubt ./build -c
[09:39] <Cimi> Saviq, maybe we need to update the version of this package?
[09:40] <Saviq> Cimi, no
[09:40] <Cimi> does it get reinstalled?
[09:40] <Saviq> Cimi, yes
[09:40] <Saviq> Cimi, but only if debian/control is newer than builddir/unity8-build-deps*deb
[09:40] <Cimi> http://paste.ubuntu.com/5880241/
[09:40] <Saviq> Cimi, so if it failed once, you need --clean so that it gets reinstalled
[09:40] <Cimi> ok
[09:41] <Cimi> it's newer but didn't work
[09:51] <didrocks> Saviq: I'll start making people pay when they use the term "autolanding" :p
[09:51] <didrocks> or CI as well ;)
[09:51] <Saviq> didrocks, :D
[09:51] <Saviq> like a swear-jar?
[09:51] <didrocks> right
[09:52] <didrocks> people are always confused with the term autolanding or CI
[09:52] <Saviq> didrocks, what shall we use?
[09:52] <didrocks> Saviq: upstream merger
[09:52] <didrocks> and daily release
[09:52] <didrocks> Saviq: want me to do a followup email?
[09:53] <Saviq> didrocks, sure, but upstream merger covers both CI and autolanding, really
[09:53] <Saviq> or it doesn't cover CI at all, depending how you look at it
[09:53] <didrocks> Saviq: well, it's the same in the way you are using it
[09:53] <didrocks> CI = autolanding :p
[09:55] <Saviq> didrocks, not in my book :P
[09:55] <didrocks> maybe not in your book
[09:55] <didrocks> but in your email, yeah :p
[09:55] <didrocks> * autolanding failed due to HW issue
[09:55] <didrocks> * decided to fast-track without CI
[09:55] <Saviq> didrocks, autolanding ( CI, merging )
[09:56] <didrocks> Saviq: what is CI for you?
[09:56] <Saviq> didrocks, the thing that unity8-ci does
[09:56] <Saviq> didrocks, so testing
[09:56] <Saviq> didrocks, but I agree that's the wrong name to use
[09:56] <Saviq> as there's no integration going on there
[09:56] <didrocks> Saviq: right ;)
[09:56] <didrocks> let me send a followup email
[09:56] <Saviq> didrocks, I'm about to send my comments
[09:56] <Saviq> didrocks, might want to wait for that
[09:57] <didrocks> Saviq: well, I want to give a rationale first and add fghinter :)
[09:57] <Saviq> didrocks, sure
[09:58] <didrocks> Saviq: daily release was triggered manually, right?
[09:58] <didrocks> Saviq: seeing the hours
[09:58]  * didrocks checks the hours
[09:58] <Saviq> didrocks, I didn't, maybe Sergio did
[09:59] <Saviq> didrocks, OTOH it was over 2hrs between landing and daily release
[09:59] <Cimi> Saviq, seb128 https://code.launchpad.net/~unity-team/unity8/unity8.background_gsettings/+merge/174958
[09:59] <didrocks> Saviq: the daily release starts at 2h30 for unity8
[10:00] <didrocks> Saviq: sent
[10:00] <Saviq> Cimi, lines 22 23 of the diff look weird
[10:00] <sil2100> brb
[10:01] <Saviq> Cimi, ah, know I get it...
[10:01] <seb128> Cimi, why do you build-depends on gsettings-desktop-schemas ? shouldn't you depends on it rather?
[10:01] <Cimi> seb128, don't ask me about debian stuff :P
[10:01] <Cimi> seb128, feel free to tell me what to change boss
[10:01] <Saviq> Cimi, same for qtdeclarative5-gsettings1.0
[10:01] <seb128> right
[10:02] <Saviq> didrocks, shouldn't have […] snipped if you added fginther to CC
[10:03] <Saviq> didrocks, unless you Fwd, too?
[10:03] <didrocks> Saviq: oh, good point, silly me :p
[10:03] <didrocks> Saviq: let me fw him the first discussion
[10:03] <Cimi> Saviq, seb128 pushed
[10:04] <didrocks> Saviq: "fixed" :p
[10:04] <Saviq> didrocks, I wonder if we should rename the Jenkins jobs, then
[10:04] <Saviq> didrocks, 'cause really that's where it all comes from
[10:04] <didrocks> Saviq: yeah… I know :/
[10:04] <Saviq> didrocks, and the bot votes "continuous-integration", too
[10:04] <didrocks> Saviq: I have no strong opinion on what should be done TBH, but right…
[10:05] <Saviq> didrocks, btw, would triggering manually at 1am have helped anything?
[10:05] <Saviq> didrocks, triggering daily, that is
[10:06] <didrocks> Saviq: not sure if the platform stack would have been finished by then
[10:06] <didrocks> Saviq: and no image build anyway
[10:06] <Cimi> Saviq, info graphics don't work with it
[10:06] <didrocks> so I would say "no"
[10:06] <Cimi> Saviq, it is of a fixed purple
[10:06] <didrocks> Saviq: and can't tell you, seems jenkins on magners decided to shut down…
[10:06] <Cimi> Saviq, shall I fix it here or new bug and separate branch?
[10:08] <Cimi> Saviq, also, the image should be cropped not scaled..
[10:11] <Saviq> Cimi, you mean that infographics don't change their colour with the background? yeah I know, it's nic-doffay's shortcut ;P
[10:11] <Saviq> Cimi, so no, not the same MP
[10:11] <Saviq> Cimi, as for scale vs. cropped, yeah, fix it in there
[10:12] <Cimi> Saviq, http://imgur.com/GzRBHD1.png
[10:12] <Cimi> weird
[10:12] <nic-doffay> Saviq, :P
[10:12] <Cimi> Saviq, this is with Image.PreserveAspectCrop :-\
[10:13] <Saviq> Cimi, doesn't look like it :D
[10:13] <Saviq> Cimi, remember it's a CrossFadeImage
[10:13] <Saviq> Cimi, maybe something to change there?
[10:14] <Cimi> Saviq, mmm yeah might be
[10:14] <Saviq> Cimi, while you're at it
[10:15] <Saviq> Cimi, didn't CrossFadeImage get into the SDK?
[10:15]  * Cimi checks
[10:15] <Saviq> Cimi, we could maybe get rid of it from our code
[10:15] <Cimi> I am still fighting with the massive abundance of italian ice cream I had last night as personal welcome :P
[10:26] <Saviq> seb128, you need to increase max flicking velocity in "Software licenses" :D
[10:26] <Saviq> seb128, getting to unity8 is tricky ;)
[10:27] <seb128> Saviq, hehe, indeed, I noticed that as well
[10:27] <Saviq> seb128, and it doesn't integrate with the header well (header doesn't scroll off screen and list isn't clipped)
[10:27] <seb128> Saviq, I was wondering if the slowness is due to the fact that the list is built "on demand" when you scroll
[10:27] <Saviq> seb128, no
[10:27] <Saviq> seb128, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-flickable.html#maximumFlickVelocity-prop
[10:27] <seb128> Saviq, will try that, thanks
[10:28] <seb128> do you have a value to recommend?
[10:29] <Saviq> seb128, we went for:
[10:29] <Saviq>     maximumFlickVelocity: height * 10
[10:29] <Saviq>     flickDeceleration: height * 2
[10:29] <Saviq> seb128, in the dash
[10:29] <seb128> ok, thanks
[10:29] <seb128> Saviq, noted for the header ... what about the list clipping?
[10:29] <seb128> do you know what's the issue there?
[10:29] <Saviq> seb128, well, the list does not have clip: true at least
[10:30] <Saviq> seb128, but then it should push the header off screen
[10:30] <Saviq> seb128, and am not sure how that works in the SDK
[10:30] <seb128> the header problem is there in the storage panel as well
[10:30] <seb128> I need to look at that
[10:31] <seb128> the pagestack is supposed to do that for us
[10:31] <Cimi> Saviq, mmm
[10:31] <Cimi> Saviq, small question
[10:31] <Saviq> Cimi, stop eating icecream
[10:31] <Cimi> lol
[10:31] <Saviq> unless you have enough to share!
[10:31] <Cimi> Saviq, so the sourceSize set to dimensions of the shell
[10:31] <Cimi> Saviq, makes the image blurred
[10:32] <Cimi> because there's a massive crop
[10:32] <Saviq> Cimi, yeah, we probably shouldn't have sourceSize there
[10:32] <Cimi> Saviq, maybe I should just set sourceSize width or height depending on the crop?
[10:32] <Saviq> Cimi, or just one dimension at most
[10:33] <Cimi> Saviq, I'd say just height maybe?
[10:33] <Cimi> wallpapers should be landscape no?
[10:33] <Saviq> Cimi, not necessarily, no
[10:33] <Cimi> or how can I be smarter?
[10:33] <Saviq> Cimi, I'd probably drop the sourceSize there
[10:33] <Cimi> Saviq, we get 2MB of men usage no?
[10:34] <Cimi> *mem
[10:34] <Cimi> in case of big image
[10:34] <Cimi> s
[10:34] <Saviq> Cimi, hopefully Qt is smart enough to drop the parts of the image that are out of bounds
[10:34] <Saviq> Cimi, otherwise we'd have to load the image, check its aspect ration
[10:34] <Saviq> -n
[10:34] <Saviq> Cimi, and then decide
[10:34] <Cimi> Saviq, I am doing it
[10:35] <Cimi> with TestImage
[10:35] <Cimi> already
[10:35] <Cimi> so what can I add here?
[10:35] <Cimi> help me thinking
[10:35] <Cimi> we have aspect ratio of the phone/tablet
[10:35] <Cimi> with width and height of shell
[10:35] <Cimi> and aspect ratio of the image
[10:36] <Cimi> mmm
[10:36] <Saviq> Cimi, if shell aspect ratio < image aspect ratio
[10:36] <Cimi> if aspect ratio of phone is smaller than the image aspect ratio
[10:36] <Cimi> yes...
[10:37] <Cimi> :P
[10:37] <Saviq> Cimi, sourceSize { height: }, otherwise sourceSize { width: }
[10:37] <Saviq> Cimi, you'll get there
[10:37] <Cimi> yes you type faster
[10:37] <Saviq> Cimi, depending on the definition of aspect ratio :)
[10:37] <Saviq> but yeah, you know the drill
[10:37] <Cimi> aspect ratio is a ratio with/height
[10:39] <Cimi> Saviq, you think the testImage might consume memory or not?
[10:39] <Saviq> Cimi, it will, you need to unset the source
[10:39] <Cimi> Saviq, dunno what qt does with visible: false
[10:39] <Cimi> ok
[10:57] <nic-doffay> Saviq, I need to use a ShaderEffect to render an Image component. The source for an image component is only a url though. How can I work around this?
[10:57] <nic-doffay> The ShaderEffect lives in the theme atm.
[10:57] <nic-doffay> The image is in the actual component class.
[10:58] <Saviq> nic-doffay, ShaderEffect needs a ShaderEffectSource, and an Image can be the sourceItem of ShaderEffectSource's, if I get your question correctly
[10:59] <nic-doffay> Saviq, nope. I'll ask the SDK guys about it. It's a bit trickier since it involves the theme stuff.
[10:59] <nic-doffay> ta though
[10:59] <Saviq> nic-doffay, k
[11:18] <Cimi> Saviq, I think I am missing something
[11:18] <Saviq> Cimi, hit me
[11:19] <Cimi> Saviq, if (shell.width / shell.height <= testImage.sourceSize.width / testImage.sourceSize.height) {
[11:19] <Cimi>                     backgroundImage.sourceSize = undefined
[11:19] <Cimi>                     backgroundImage.sourceSize.height = shell.height }
[11:19] <Cimi> Saviq, image is still blurred :-\
[11:20] <Cimi> seb128, gsettings is before qmenumodel in alphabetical order
[11:20] <Saviq> Cimi, is it a JPEG image?
[11:20] <Cimi> Saviq, yes
[11:20] <Saviq> Cimi, I think we identified an issue with JPGs that the scaler in Qt is bad for them
[11:20] <Cimi> Saviq, I expect the source size to behave correctly
[11:21] <Cimi> Saviq, shall I try smooth false?
[11:21] <Saviq> Cimi, can you try in a simple .qml for qmlscene?
[11:21] <Saviq> Cimi, and see the impact
[11:21] <Cimi> mm ok
[11:26] <Saviq> Cimi, I think we saw that with MacSlow|lunch and Kaleo before in notifications - but never followed up
[11:32] <mhr3> didrocks, didrocks, http://paste.ubuntu.com/5880522/ known?
[11:33] <didrocks> mhr3: slangasek made a transition on uity-common, it should work when dist-upgrading though
[11:33] <didrocks> mhr3: do you dist-upgrade and get that?
[11:33] <mhr3> didrocks, i did dist-upgrade, and didn't even notice that it removed unity :/
[11:33] <mhr3> had to install it
[11:33] <didrocks> mhr3: maybe check with slangasek? I have way too much on my plate right now to debug that
[11:33] <mhr3> didrocks, ok
[11:34] <didrocks> (merged 10 branches since this morning, 2 packages NEWing, a lot of jenkins debugging, a patch to cupstream2distro, lot of configuration changes…)
[11:34] <mhr3> sounds like one of those "fun" days :)
[11:34] <didrocks> and now unity-system-compositor is giving me hell
[11:34] <didrocks> mhr3: well, I have too many "fun" days TBH… :/
[11:35] <mhr3> fun couple of months then ;)
[11:35] <Cimi> Saviq, works here :-\ http://paste.ubuntu.com/5880531/
[11:37] <Saviq> Cimi, try to see what's the difference between that and unity8
[11:37] <Saviq> Cimi, smooth shouldn't be used for images, though
[11:37] <Cimi> Saviq, there is no difference
[11:38] <Cimi> Saviq, I copied code
[11:38] <Saviq> Cimi, can you push to your branch please?
[11:41] <Cimi> Saviq, lp:~unity-team/unity8/unity8.background_gsettings-sourceSize
[11:41] <Cimi> (pushing...)
[11:45] <Cimi> pushed
[11:51] <Cimi> Saviq, ^
[11:51] <seb128> Cimi, doh, you are right ;-)
[11:52] <Saviq> Cimi, yeah, got it, trying to find out what's happening
[11:52] <seb128> Cimi, g/q they look the same :p
[11:52] <Cimi> Saviq, it's weird isn't it?
[11:53] <Saviq> Cimi, yeah, I removed most of the shell and it's still like that
[11:54] <seb128> mhr3, dpkg -l | grep libunity
[11:54] <Cimi> Saviq, I'm checking if it's a bug on the sourcesize
[11:55] <Cimi> Saviq, due to phone_background
[11:55] <Cimi> Saviq, yes
[11:55] <Saviq> Cimi, ok, so you're on it
[11:55] <Cimi> Saviq, no idea though
[11:55] <Cimi> Saviq, why it happens
[11:55] <Saviq> Cimi, what's the solution then?
[11:56] <Cimi> Saviq, property url default_background: "graphics/tablet_background.jpg" and the bug is gone
[11:56] <Cimi> Saviq, if you can understand what could be the issue...
[11:56] <nic-doffay> Cimi, how do I access the label colour for a theme again?
[11:57] <Cimi> nic-doffay, which label?
[11:57] <nic-doffay> Cimi, do the themes have a set colour for headers?
[11:57] <nic-doffay> Or similar labels at the top of the component.
[11:57] <Cimi> should be Theme.palette.selected.foregroundText iirc
[11:57] <nic-doffay> Cimi, cool I'll try it now...
[11:58] <nic-doffay> Cimi, where does that colour file live again?
[11:58] <nic-doffay> So I can check the others (foreground text wasn't right for this)
[11:58] <Cimi> nic-doffay, modules/themes/...
[11:58] <Cimi> iirc
[11:58] <Cimi> search inside here
[11:59] <nic-doffay> Cimi, got it.
[11:59] <nic-doffay> ta
[12:00] <Saviq> Cimi, btw, you need to use Qt.binding(), so that sourceSize gets updated when shell size changes
[12:03] <Saviq> Cimi, sourceSize = undefined doesn't work
[12:04] <Saviq> Cimi, ah
[12:04] <Saviq> not sourceSize = undefined
[12:04] <Saviq> Cimi, sourceSize.width/height = undefined
[12:09] <Saviq> Wellark, but yeah, come here with that
[12:09] <Saviq> Wellark, what's the problem?
[12:09] <Wellark> Saviq: I have a meeting starting
[12:09] <Saviq> Cimi, got it
[12:10] <Saviq> Cimi, sourceSize.width/height = 0
[12:10] <Saviq> Cimi, not undefined or null
[12:12] <Saviq> Cimi, http://pastebin.ubuntu.com/5880631/ fixes your issue
[12:13] <Saviq> Cimi, it quietly ignores non-numeric values and keeps the original one
[12:16] <Wellark> Saviq: ok, the meeting got postponed
[12:16] <Wellark> Saviq: so, application identifiers and application identity
[12:17] <Saviq> Wellark, yes
[12:17] <Saviq> greyback, ↑ you want to be here
[12:17]  * greyback is
[12:17] <Wellark> Saviq: first off, some of our platform service like the hud-service needs to identify applications which push data to it
[12:18] <Wellark> currently the hud-service expects the application to provide it's application ID which is then used to match the application windows with the data the application provides
[12:19] <Saviq> yes
[12:19] <Wellark> clearly there is a flaw here as the service should not simply trust the application to tell it's appid (can be faked), but instead the hud-service should be able to ask from *somewhere* "who is this application that is pushing me data"
[12:20] <Saviq> Wellark, yeah, you can find the PID over DBus and then look through what the shell will expose to match the application
[12:20] <Wellark> Saviq: indeed. I can get the PID
[12:20] <Saviq> not sure how that'll work for multi-surface apps, but we'll manage
[12:21] <Wellark> Saviq: I imagine the interface for this does not yet exist
[12:21] <Wellark> Saviq: then this is also the same inside the shell
[12:21] <Saviq> Wellark, it *almost* does
[12:21] <Wellark> when writing the launcher backend (which I currently am)
[12:21] <Saviq> Wellark, greyback is working on it
[12:21] <greyback> Wellark: ApplicationManager can give you the application ID for a PID. Will need to add a dbus interface for it
[12:21] <Wellark> greyback: is ApplicationManager a singleton inside the shell?
[12:22] <Saviq> Wellark, yes
[12:22] <Wellark> great.
[12:22] <Wellark> even better
[12:22] <greyback> Wellark: yes
[12:23] <greyback> Wellark: so you need the app_id corresponding to a PID
[12:23] <Wellark> greyback: indeed
[12:23] <Wellark> greyback: and also the absolute path to the .desktop file
[12:23] <Wellark> inside the shell application manager probably provides the desktop file contents directly
[12:24] <Wellark> but the external services might need to read the .desktop file also
[12:24] <Wellark> and now that we will have click application
[12:24] <Wellark> there are actually multiple places the .desktop file may live
[12:25] <Wellark> not just under /usr/share/applications/
[12:25] <Wellark> greyback: so, when doing the launcher backend (inside shell) I will utilize your api directly
[12:28] <Saviq> Wellark, we need a common .desktop file reader, yes
[12:29] <Wellark> Saviq: yes, that is a known fact. :)
[12:29] <Saviq> Wellark, one that will respect XDG etc.
[12:29] <Wellark> Saviq: yes, but click .desktop files are not respecting XDG
[12:29] <Saviq> Wellark, why do you say that?
[12:30] <Wellark> Saviq: https://lists.launchpad.net/ubuntu-appstore-developers/msg00253.html
[12:30] <Saviq> Wellark, aren't the click hooks going to "install" .desktop files?
[12:30] <Wellark> Saviq: "he core difference being
[12:30] <Wellark> that it'll have relative paths that aren't resolvable using standard XDG
[12:30] <Wellark> directory definitions (they'll all be in the package)."
[12:31] <Saviq> Wellark, mhm
[12:31] <Wellark> Saviq: so we need special handling with the icons
[12:31] <Wellark> the file format follows the standard
[12:31] <Saviq> Wellark, mhm, got it
[12:32] <Wellark> Saviq: one options is simply convert the relative paths to absolute ones when parsing
[12:32] <Saviq> Wellark, yeah +1
[12:32] <Saviq> Wellark, I don't want to have to care in the shell
[12:32] <Saviq> Wellark, so the .desktop file reader, supporting click packages, will need to handle that
[12:33] <Wellark> Saviq: indeed
[12:33] <greyback> sorry dropped connection
[12:33] <Wellark> Saviq: but then again there is always the question how we handle the "themed" icons
[12:33] <Saviq> Wellark, we should probably not call it a .desktop file reader anyway
[12:33] <Wellark> so with this we have three options
[12:33] <Saviq> Wellark, but "application data provider" or something
[12:34] <Wellark> Icon=/absolut/path/icon.png
[12:34] <greyback> Wellark: http://studio.sketchpad.cc/EEd2PSjTRn <- is list of dbus APIs requested of ApplicationManager. I've added yours, does it look ok?
[12:34] <Wellark> Icon=from-theme
[12:34] <Wellark> icon=./click-relative
[12:34] <Wellark> but sure. I need to run to a meeting now
[12:35] <Saviq> Wellark, I imagine we'll need to add the app's dir to the theme search path
[12:41] <Cimi> Saviq, one remaining bit
[12:41] <Cimi> Saviq, setting the source of testImage to undefined
[12:42] <Cimi> Saviq, if I do this I think I'll break the binding with the gsettings...
[12:44] <Saviq> Cimi, yeah, you will, but that's ok - you don't need a binding, you need an on*Changed instead
[12:50] <Cimi> Saviq, mmm hard
[12:50] <Cimi> Saviq, I wanted to do onPictureUriChanged
[12:50] <Cimi> but it doesn't work
[12:50] <Saviq> Cimi, just proxy through an alias
[12:50] <Saviq> Cimi, or through another property
[12:50] <Cimi> ok
[12:50] <Cimi> indeed
[12:52] <mhr3> seb128, what am i looking for?
[12:52] <mhr3> we have too many libunitites :)
[12:53] <seb128> mhr3, libunity-core-*'s version
[12:53] <mhr3> seb128, 6.0-7 is installed
[12:53] <seb128> mhr3, https://launchpad.net/ubuntu/+source/unity/7.0.2+13.10.20130705.1-0ubuntu3
[12:53] <seb128> do you have the provides added there?
[12:54] <Saviq> guys, can you please fix your barrier :P
[12:55] <Saviq> kthxbye
[12:55] <mhr3> seb128, 7.0.2+13.10.20130705.1-0ubuntu3
[12:55] <mhr3> seb128, the problem now is that the compiz schema got weird, it doesn't start the unity plugin
[12:56] <seb128> mhr3, ok, dunno about that
[12:57] <seb128> mhr3, I was looking at your upgrade pastebin earlier saying that unity-common was not installed
[12:58] <mhr3> seb128, strangely it was a warning
[12:58] <seb128> oh, ok
[13:00] <Cimi> Saviq, cannot set the url to undefined
[13:01] <Cimi> Saviq, so how can I unload the image?
[13:01] <Saviq> Cimi, ""
[13:01] <Cimi> ok
[13:05] <Cimi> Saviq, ok I finished the branch, it's ready for review...
[13:05] <Cimi> Saviq, I have afternoon off, but I think I can come to the standup
[13:05] <Cimi> Saviq, in any case, you know what I did :)
[13:06] <Saviq> Cimi, yup
[13:17] <Wellark> hmm.. upgrading with unity-next enabled was not that good idea..'
[13:17] <Wellark> didrocks: any known breakage?
[13:17] <didrocks> Wellark: what ppa exactly are you upgrading to?
[13:18] <didrocks> unity-next doesn't exist :)
[13:18] <Wellark> didrocks: :D
[13:18] <Wellark> didrocks: let me check (once I get to the VT...)
[13:19] <didrocks> yeah, either ubuntu-unity/daily-build-next (but as the description tells, you shouldn't use that one)
[13:19] <didrocks> or ubuntu-unity/next (this one should be safe)
[13:20] <Wellark> didrocks: ubuntu-unity-next
[13:20] <Wellark> didrocks: not it works
[13:20] <Wellark> it actually probably was not unity related at all
[13:20] <didrocks> Wellark: this isn't a ppa :) I think you mean ubuntu-unity/next
[13:20] <sil2100> didrocks: hmmm
[13:21] <Wellark> might be that I hadn't updated in a while
[13:21] <sil2100> didrocks: why didn't otto collect failing videos of autopilot tests?
[13:21] <Wellark> reinstalling virtualbox drivers fixed it
[13:21] <didrocks> sil2100: I guess jibel reenabled that with his patch, isn't it? ^
[13:21] <Wellark> didrocks: saw error on starting X that GLX driver had old ABI version
[13:21] <didrocks> Wellark: you should just develop on your system with latest saucy ;)
[13:21] <Wellark> 13 vs. 14
[13:22] <jibel> sil2100, when running unity testsuite?
[13:22] <sil2100> didrocks: not sure, the latest unity test runs don't have any videos
[13:22] <sil2100> jibel: yes
[13:22] <jibel> sil2100, because I forgot to reenable them
[13:22] <jibel> doing now
[13:23] <sil2100> didrocks: talking with mhr3 about that now
[13:23] <sil2100> jibel: ok
[13:23] <sil2100> Thanks
[13:23] <Cimi> Saviq, I'll skip the standup, gotta run!
[13:23] <Saviq> Cimi, k, have fun
[13:23] <Cimi> Saviq, I'm on holiday tomorrow afternoon
[13:24] <Cimi> Saviq, and thursday/friday
[13:24] <Cimi> Saviq, but I'll check here once a while
[13:24] <jibel> sil2100, they will be recorded with 6 frame per seconds to put less pressure on the system. Let me know if it is not enough
[13:24] <Cimi> reviews
[13:24] <Saviq> Cimi, be on holiday instead
[13:26] <sil2100> jibel: should be ok
[13:27] <sil2100> didrocks: anyway, mhr3 says it's all because of the bus saturation, and no one has any idea why ;/
[13:28] <didrocks> sil2100: what triggered that suddenly though?
[13:28] <didrocks> mhr3: can you talk with tedg about it?
[13:28] <didrocks> mhr3: something had to change…
[13:29] <jibel> sil2100, didrocks done. ping me if next run of unity doesn't have videos or if videos are black or broken
[13:29] <sil2100> didrocks: it seems there was no real big changes related to that
[13:29] <mhr3> didrocks, it started on the 5th iirc, and there were no changes in hud nor bamf at that point, it's odd
[13:30] <mhr3> hm, maybe something in unity itself?
[13:30] <didrocks> mhr3: dbus changed the 24/06
[13:30] <didrocks> mhr3: so yeah, maybe unity…
[13:31] <Wellark> didrocks: well.. I had upgraded, but not rebooted :)
[13:32] <Wellark> it's linux you know. rebooting is so windows95
[13:32] <didrocks> Wellark: hem, if you upgrade components/services, you will need to kill/restart them at some point :p
[13:33] <greyback> Saviq: standup?
[13:33] <mhr3> didrocks, ted is on holiday the whole week :/
[13:33] <didrocks> :/
[13:34] <kgunn> anyone else having mumble troubles
[13:34] <mhr3> Wellark, are you familiar with the old hud protocol?
[13:35] <Wellark> mhr3: yes. more or less
[13:35] <mhr3> Wellark, from my investigations, most of the Update signals had empty body
[13:35] <mhr3> and uint 1 at the end iirc
[13:35] <mhr3> is that of any help?
[13:36] <Wellark> mhr3: I assumed you had discussed with this ted and it was under control
[13:36] <Wellark> mhr3: so HUD is causing AP failures?
[13:36] <Wellark> mhr3: if that is so, then I have to fix them as top priority
[13:36] <mhr3> Wellark, not really, ted just asked the unity guys to migrate to the new hud interface
[13:37] <mhr3> but it's blocking the releases to S, so should be taken care of asap
[13:37] <Wellark> mhr3: yeah, but I thought this is not major
[13:37] <mhr3> it's the reason of the huge number of ap failures
[13:37] <mhr3> Wellark, so to make it clear - this *is* major :)
[13:37] <Wellark> mhr3: well if it is then I will do whatever it takes (the quick bandate option) to enable the AP testing again
[13:38] <Wellark> mhr3: roger.
[13:38] <Wellark> mhr3: I will stop working on anything else
[13:38] <mhr3> Wellark, ok, thx
[13:38] <Wellark> I need to take care some family stuff (it's almost 5pm here), but will get back to you shortly
[13:46] <olli_> Saviq, ping
[13:46] <olli_> well, actually anybody :)
[13:46] <olli_> I am trying to install unity8 on my desktop
[13:46] <olli_> added https://launchpad.net/~ubuntu-unity/+archive/next/
[13:47] <olli_> but I am cautious as to which package to install, don't want to overwrite U7 on S
[13:47] <olli_> would I simply install unity8
[13:50] <didrocks> olli_: if you dist-upgrade, what does it tell you?
[13:50] <didrocks> olli_: it should just be unity8-related stuff AFAIK
[13:52] <olli_> didrocks, yeah, nevermind
[13:52] <olli_> I just showed again - in public - you unsmart I am ;)
[13:52] <olli_> apt-get update
[13:52] <olli_> I will write that 100x on my white board
[13:53] <didrocks> ahah ;)
[13:55] <Saviq> olli_, just install unity8, it will work next to unity7 just fine
[13:55] <olli_> Saviq, yeah, I have 2 left hands when it comes to PPAs and apt
[13:56] <olli_> ;)
[13:56] <Saviq> olli_, add-apt-repository should update automagically
[13:56] <Saviq> olli_, +1 there
[13:56] <olli_> got it up and running just fine
[13:56] <olli_> after some public embarrassment
[13:56] <olli_> Saviq, it uses more lenses on the desktop
[13:57] <olli_> is that intended or just a temporary glitch
[13:57] <Saviq> olli_, yes, it uses the same set unity7 does
[13:57] <Saviq> olli_, intended
[13:57] <olli_> it's kind of cool
[13:57] <olli_> but not ;)
[13:57] <olli_> (as it isn't fully there)
[13:57] <olli_> but that's imho still good enough to land
[13:58] <olli_> will try to figure out a "wallpaper" solution for tvoss
[13:58] <olli_> ;)
[13:58] <olli_> nice work
[13:58]  * olli_ likes positive surprises
[13:59] <dandrader> dednick, would you have time to review this one: https://code.launchpad.net/~dandrader/unity8/showWithoutAnimation/+merge/174799  It's a very simple one
[13:59] <tvoss> olli_, thanks so much :)
[13:59] <TitusJ> hi
[14:00] <Saviq> tvoss, greyback see Kaleo's comments on bug #1089962 btw
[14:00] <kgunn> olli_: i couldnt find your work of art to supply
[14:00] <dednick> dandrader: sure
[14:01] <dandrader> dednick, thanks!
[14:02] <tvoss> Kaleo, Saviq, greyback fair point, but I would rather avoid doing that without being able to measure the impact
[14:02] <TitusJ> Hi everybody ! How I can enjoy to unity dev project?
[14:02] <Kaleo> tvoss: impact of overdraw is massive really
[14:03] <tvoss> Kaleo, sure, agreed but still: do you think that the gain is so significant that we should tackle it right now? I would propose to land whatever we have first
[14:03] <Kaleo> tvoss: I don't understand, what do we have first?
[14:04] <tvoss> Kaleo, a single-surface shell
[14:04] <Kaleo> tvoss: it's already landed
[14:04] <Kaleo> tvoss: the single surface shell I use since Dec
[14:04] <dednick> dandrader: +1
[14:04] <tvoss> Kaleo, I'm saying on top of Mir
[14:04] <tvoss> Kaleo, fair
[14:04] <greyback> Kaleo: makes a lot of sense. But first I'll land single-surface shell on Mir. Then can break it up into individual surfaces
[14:04] <Kaleo> greyback: I think the work in unity8 is unrelated to that
[14:04] <Kaleo> greyback: APIs used would be the same
[14:05] <Kaleo> greyback: so it should at least be prepared
[14:05] <slangasek> mhr3: do you have a full apt log for when unity was removed?
[14:05] <greyback> Kaleo: mostly yes. Mir has to implement it, then unity can use it
[14:05] <tvoss> Kaleo, agreed, but let's land greyback's work first
[14:05] <mhr3> slangasek, should be in one of those log files right?
[14:06] <slangasek> mhr3: have you posted your logs somewhere?
[14:06] <slangasek> mhr3: /var/log/apt/history.log
[14:06] <mhr3> slangasek, not yet, give me a sec
[14:12] <mhr3> slangasek, actually, it was my screwup, forgot to disable one of the daily ppas
[14:14] <slangasek> ah, ok
[14:15] <TitusJ> I'm new. How I support unity project?
[14:22] <Kaleo> tvoss: when would it land? 3-4 weeks?
[14:22] <tvoss> Kaleo, for the final version: yeah, for the alternative image we are preparing: sooner
[14:23] <Kaleo> tvoss: right
[14:24] <tvoss> Kaleo, so yeah, no question about looking into the optimization you are mentioning
[14:25] <Kaleo> tvoss: good, I believe it's 100% parallel work
[14:26] <Wellark> mhr3: back
[14:27] <Wellark> now, let's deal with this HUD stuff
[14:27] <Wellark> and get the queue moving again
[14:34] <Wellark> hmm.. I found a nice way to get a lot of stuff crashing on saucy
[14:34] <Wellark> "$ stop dbus"
[14:36] <mhr3> gdbus does exit() when session bus connection closes
[14:37] <Wellark> mhr3: well I just accidentally did that and got like 10 dialogs saying "there was something wrong with your system"
[14:37] <Wellark> or whatever it says when service/app crashes
[14:37] <Wellark> so clearly some of our stuff crash hard if dbus goes away
[14:37] <mhr3> yea, not surprising
[14:53] <Wellark> mhr3: ok. I got it
[14:54] <Wellark> basically hud is emitting UpdatedQuery signal each time an active window changes or some other change in the search data happens
[14:54] <sil2100> hmm
[14:54] <Wellark> and it's emitting it n times each time
[14:54] <Wellark> where n is the number of times hud has been opened
[14:58]  * Saviq logs off for today o/
[14:59] <Wellark> mhr3, sil2100: cheap karma available: https://code.launchpad.net/~kaijanmaki/hud/fix-updated-query-signals/+merge/175040
[15:00] <Wellark> additional water marker stamp for getting the S langing queue moving again
[15:01] <Wellark> pete-woods2: ^^^
[15:01] <mhr3> Wellark, looks reasonable, although i'm not really familiar with the hud code, so maybe pete-woods2 can ack it
[15:03] <pete-woods> looking at it now guys
[15:03] <sil2100> Wellark: will this fix our problems? Any idea why it became a problem now?
[15:03] <Wellark> sil2100: well, no idea. the legacy interface has been there for a long time now
[15:04] <Wellark> sil2100: probably the problem has always been there but we haven't had enough AP tests running to get over the treshold that dbus actually gets starved
[15:04] <pete-woods> Wellark: totally a fix - should definitely not be calling that each time - only when we make a new query!
[15:05] <sil2100> pete-woods: could you top-approve? Thanks!
[15:05] <pete-woods> sil2100: shouldn't I wait for jenkins?
[15:05] <sil2100> pete-woods: jenkins will anyway run a test right before merging
[15:05] <Wellark> pete-woods: autolanding will check it anyway
[15:05] <sil2100> So no need
[15:06] <pete-woods> sil2100, Wellark: okay fair enough - is there a point to the first Jenkins run then?
[15:06] <Wellark> pete-woods: it helps to get feedback from jenkins if you are pushing multiple revs before top-approve
[15:06] <sil2100> pete-woods: sometimes it's useful when you're having a branch that's work-in-progress
[15:06] <pete-woods> Wellark: that's a fair point!
[15:07] <pete-woods> sil2100: as above :)
[15:08] <Wellark> sil2100, mhr3: maybe it would be a good idea to collect dbus log from each of the AP runs
[15:09] <mhr3> Wellark, yes, i was thinking about it too, but they're too big
[15:09] <Wellark> so that can be inspected and any unusually high activity could be noticed before we actually simply start seeing dbus starvation when we reach some magic limit
[15:09] <Wellark> mhr3: right
[15:10] <Wellark> mhr3: even when compressed?
[15:10] <Wellark> or just provide the top 20 or something
[15:10] <mhr3> Wellark, i can imagine that it'd compress very well, but it'd still use a lot of space during the run
[15:11] <mhr3> Wellark, but it's totally doable to write a new dbus-stats tool that would do exactly what we need and just collect stats, not save every msg and it's body
[15:12] <mhr3> its*
[15:12] <Wellark> mhr3: dbus-monitor | xz > dbus-log.txt.xz
[15:12] <Wellark> that would do the compression on the fly. no space gets wasted :)
[15:13] <mhr3> Wellark, right, otoh then we need a tool that analyzes a log from dbus-monitor :)
[15:13] <Wellark> mhr3: so you were using bustle?
[15:13] <mhr3> yea
[15:14] <Wellark> well, s/dbus-monitor/bustle-dbus-monitor/ :)
[15:14] <Wellark> bustle-dbus-monitor outputs to stdout
[15:15] <Wellark> oh
[15:15] <Wellark> no
[15:15] <Wellark> no, yes
[15:24] <Wellark> mhr3, sil2100: the fix got merged. keep me posted how it works :)
[15:25] <mhr3> Wellark, well, we'd still need that analysis tool, cause bustle itself cant handle it
[15:25] <sil2100> Wellark: thanks!
[15:26] <mhr3> sil2100, can you re-run the tests with the fix?
[15:27] <Wellark> mhr3: didn't you have a script to do the analyzis? or did you count the numbers by hand you sent in your email :P
[15:27] <Wellark> "another week well spent"
[15:27] <sil2100> mhr3: will do, although first I need to re-build the HUD stack
[15:29] <mhr3> Wellark, yep, i used matches though :P
[15:30] <didrocks> sil2100: does this mean we need to recheck all the pastebin?
[15:30] <didrocks> sil2100: W: share-app source: virtual-package-depends-without-real-package-depends build-depends: libgl-dev
[15:31] <didrocks> sil2100: it seems share-app isn't done at all :/
[15:33] <sil2100> didrocks: I know what happened ;/
[15:33] <sil2100> didrocks: it seems I didn't check share-app as it was said to be: "OK. NEWED" in the pastebinit
[15:33] <didrocks> that's a first step :)
[15:33] <didrocks> sil2100: well, we did it for all of them
[15:33] <sil2100> didrocks: so I assumed the warnings got fixed
[15:34] <didrocks> sil2100: so we need to recheck everything?
[15:34] <sil2100> Since it's "OK" ;p
[15:34] <sil2100> No no, one moment
[15:34] <sil2100> Let me just take a quick look
[15:34] <didrocks> ok
[15:34] <didrocks> sil2100: the OK was "NEWed to ubuntu"
[15:34] <didrocks> despite the warnings
[15:35] <didrocks> as it's been done way before the request to fix them
[15:35] <didrocks> (see the timestamp)
[15:35] <sil2100> didrocks: there are just 3 OK'ed packages that have warnings, so I'll re check them now then - since those NOTOK were handled
[15:35] <didrocks> sil2100: ok
[15:39] <didrocks> sil2100: didn't you do a wrong copy/paste?
[15:39] <didrocks> ah, fixed now
[15:39] <sil2100> didrocks: ok, gallery-app has its previous issues fixed, but has new ones
[15:39] <sil2100> didrocks: W: gallery-app-autopilot: image-file-in-usr-lib usr/lib/python2.7/dist-packages/gallery_app/data/default/.thumbnails/preview/b117f754f46e254a434a73c9f4501853.jpg
[15:39] <sil2100> Things like this :o
[15:39] <sil2100> Should those be included in the package anyway?
[15:41] <didrocks> sil2100: keep it like that for now, as long as it's in an -autopilot package
[15:42] <sil2100> didrocks: fixing share-app
[15:42] <didrocks> great ;)
[15:42] <sil2100> didrocks: should I override lack-of-manpage errors/warnings?
[15:43] <didrocks> sil2100: no, we have that in a lot of components, no override needed I guess
[15:52] <sil2100> didrocks: when I leave the {shlibs:Depends} in share-app I get pkg-has-shlibs-control-file-but-no-actual-shared-libs, but without it I'm missing the libc dependency - should I remove it and add libc-dev instead?
[15:53] <sil2100> And it seems dephelper generates the invalid problems postinst-has-useless-call-to-ldconfig, I'll override those
[15:53] <didrocks> sil2100: no, that's fine, there is a bug in debhelper that I tend to ignore because of that
[15:53] <didrocks> sil2100: don't override either, that's a debhelper issue
[15:53] <sil2100> Ok
[15:53] <didrocks> there is a bug in the BTS :)
[15:54] <didrocks> when a lib is private, it's still doing the call to ldconfig when it's not needed
[15:55] <sil2100> geh ;)
[15:55] <sil2100> https://code.launchpad.net/~sil2100/share-app/fix_lintian_errors/+merge/175053
[16:02] <sil2100> didrocks: what about errors like arch-dependent-file-in-usr-share ?
[16:02] <didrocks> sil2100: ah, that needs to be fixed
[16:02] <didrocks> sil2100: should be in libexec
[16:02] <sil2100> :)
[16:02]  * sil2100 fixing fixing
[16:02] <didrocks> sil2100: you have a conflict :)
[16:02] <sil2100> hmmm
[16:02] <sil2100> I wonderrrr
[16:02] <didrocks> with trunk
[16:03] <sil2100> Aaah, your change is there ;)
[16:03] <sil2100> Fixing!
[16:03]  * sil2100 had a typo anyway
[16:04] <sil2100> didrocks: anyway, qtubuntu-cameraplugin-fake has a cameraplugin-fake-tests package...
[16:04] <sil2100> But why would we install unit tests in the system?
[16:04] <didrocks> sil2100: meeting btw :p
[16:05] <didrocks> let's discuss that there
[16:54] <Wellark> sil2100, mhr3: any luck with the HUD?
[17:01] <sil2100> Wellark: last time I looked at it the stack was still building
[17:01] <sil2100> Let me take a look
[17:06] <sil2100> Wellark, mhr3: just to make sure - does unity need to be rebuilt against the new hud or is it enough it uses the latest HUD packages?
[17:06] <mhr3> sil2100, no need to rebuild, it's all dbus
[17:06] <sil2100> Excellent
[17:06] <mhr3> hm, maybe i should run bustle again so we see if things really improved
[17:06] <mhr3> sil2100, can you ping me once the testing starts?
[17:06] <sil2100> mhr3: ok, the check job started, but waiting for the autopilot job to start
[17:06] <mhr3> sil2100, how long will that take?
[17:06] <sil2100> mhr3: jibel will be sad with another 500 MB log file published to jenkins.u.c
[17:06] <sil2100> :<
[17:06] <sil2100> mhr3: should start in a moment
[17:06] <mhr3> sil2100, ok, ok, i'll compress it this time... will be just 300 :P
[17:07] <sil2100> It's checking all the components right now
[17:08] <mhr3> sil2100, although if the fix works the log will automatically be much smaller :)
[17:08] <sil2100> True true ;)
[17:08] <mhr3> and i'm more afraid that the compression is going to screw up the file
[17:08] <sil2100> mhr3: started!
[17:08] <mhr3> yey
[17:08] <sil2100> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/459/
[17:08] <mhr3> sil2100, intel?
[17:09] <sil2100> Sounds ok
[17:09] <mzanetti> Saviq: hey ho
[17:35] <mhr3> sil2100, good news i think, ~20minutes into the testing and the bustle log is only 45mb
[17:36] <mhr3> so if we extrapolate by the end it will be 5x smaller than last time
[17:44] <Wellark> mhr3: good to hear :)
[17:52] <kgunn> mterry: ealier you were mentioning you were sort of stalled on u-s-c greeter work ? (or did i misunderstand)
[17:53] <mterry> kgunn, uh, I mentioned that for testing the split code I have, I'm blocked on a version of lightdm that supports pure Mir
[17:54] <mterry> kgunn, for u-s-c greeter work, I'm waiting a bit on the Mir maintainers to figure out how to expose an API I need
[17:54] <mterry> kgunn, but I'm working on other stuff (edge-discoverability demo) right now
[17:55] <kgunn> mterry: so you talking with racarr on this? (he was becoming a little more free from helping greyback)
[17:55] <kgunn> lookin' for something to do :)
[17:55] <mterry> kgunn, for the Mir API bit, yeah.  racarr, any further word on what you Mir folk want for session/surface tie-in?
[17:56] <kgunn> mterry: on the lightdm "supporting pure mir"....are robert_ancell's patches for xmir being pushed to trunk not enough ? (just trying to understand...what needs to happen)
[18:00] <sil2100> mhr3: \o/
[18:01] <sil2100> mhr3: looks promising!
[18:01] <mhr3> sil2100, it grew to 180mb meanwhile...
[18:01] <mhr3> so hmmm...
[18:02] <mhr3> we'll see
[18:14] <sil2100> ehh
[18:31] <mhr3> sil2100, lovely, intel testing finished with a stacktrace from a bug in the intel driver
[18:33] <mterry> kgunn, sorry, missed your question
[18:33] <mterry> kgunn, xmir is not enough apparently.  robert_ancell indicated he was in the middle of working on a pure mir version of lightdm
[18:37] <sil2100> Shiiit
[18:44] <kgunn> mterry: thanks...
[18:44] <kgunn> i'll pester robert later
[20:12] <mhr3> bregma, could you? https://code.launchpad.net/~mhr3/unity/fix-ap-preview-tests/+merge/175123
[20:13]  * bregma looks
[20:16] <mhr3> nvm, thx Trevinho
[20:18] <mhr3> hopefully with the hud fix and this things will actually start autolanding again
[20:34] <Saviq> mzanetti, missed me, wassup?
[20:50] <mzanetti> Saviq: hey. just wanted to check how things are
[20:50] <mzanetti> nothing particular
[20:50] <Saviq> mzanetti, it's tough without you, but we make do ;)
[20:50] <Saviq> mzanetti, how's CS?
[21:04] <mhall119> are there any known problems with Unity+HUD when used on large applications?
[21:05] <mhall119> I've been using it heavily between Gimp and LibreOffice the past couple days, and several times now while doing that Compiz has started thrashing my disk doing something (iotop confirmed it was compiz) and my system becomes unusable (slow to the point of taking several minutes (yes minutes) to switch workspaces or even VT)
[21:05] <mhall119> on Saucy I should add
[21:06] <mhall119> I think it's HUD related because it always seems to start at one of the times I open HUD to start typing
[21:22] <mhr3> mhall119, it was fixed today
[21:28] <dednick> Saviq: something funky going on with the hud lately?
[21:29] <dednick> failing ap tests all over the place
[21:29] <Saviq> dednick, those tests were never reliable enough, I'm afraid
[21:29] <mhall119> awe
[21:29] <mhall119> ignore
[21:30] <Saviq> dednick, should be better soon (thomi and veebers are working on our ap test suite)
[21:30] <dednick> Saviq: owesome.
[21:30]  * thomi waves to dednick
[21:31] <dednick> thomi: sup fool
[21:31] <thomi> not much, yourself?
[21:31] <thomi> you're up late :)
[21:31] <dednick> thomi: meh. sweating my arse off. london is insanly hot at the moment
[21:32] <thomi> dednick: so when you going to come visit us in New Zealand huh? get it sorted!
[21:32] <dednick> but i wont complain :)
[21:32] <dednick> thomi: yeah, i should do that. need to buy some tickets for SA first though
[21:33] <thomi> pfffft. SA is lame, compared to NZ.
[21:33] <dednick> guess that will be next on the list ;)
[21:34] <thomi> dednick: convince Saviq to have a sprint in New Zealand :)
[21:34] <dandrader> thomi, +1!!
[21:34] <dednick> thomi: lol. unfortunately i dont think it's Saviq we have to convince :)
[21:35] <Saviq> thomi, I don't need no convincing there
[21:35] <Saviq> !
[21:35]  * dednick goes to find #canonical-finance
[21:36] <Saviq> dednick, you can't put a price tag on that, ya know! ;)
[21:36] <dednick> Saviq: i bet they can. :)
[21:45] <dednick> Saviq: is it only new images from today that we cant run_on_device ?