[07:04]  * tsdgeos reports back from holiday week #1
[07:04] <tsdgeos> bitten by mosquitos all over
[07:04] <tsdgeos> have to type slower because of swollen mosquito-bit finger
[07:13] <tsdgeos> am i going to be killed if i mention we should move to Qt5.3.1 insteadd of Qt5.3.0?
[07:53] <tsdgeos> mzanetti: Saviq: what's the status of https://code.launchpad.net/~aacid/unity8/swipe_down_close_no_remove_dash/+merge/221996 ?
[07:56] <mzanetti> tsdgeos: Saviq found some issues and put it back to needs review
[07:56] <mzanetti> tsdgeos: I have then done/fixed it on top of the QtComp branch
[07:56] <tsdgeos> i see
[08:09] <tsdgeos> mzanetti: can you comment in https://code.launchpad.net/~aacid/unity8/swipe_down_close_no_remove_dash/+merge/221996 saying it's done in the qtcomp branch?
[08:09] <tsdgeos> so it's clearer it's "done-ish"
[08:11] <mzanetti> tsdgeos: ack
[08:21] <Cimi> mako improved so much over the last months
[08:21] <Cimi> exciting
[08:43] <mhr3> tsdgeos, could you take a look at https://code.launchpad.net/~unity-team/unity8/caching-image-provider/+merge/224415 pls? it seems to be causing memory corruption and i have no idea why
[08:46] <tsdgeos> mhr3: how does the memory corruption manifest?
[08:46] <tsdgeos> i.e. what do i do to make it crash?
[08:47] <mhr3> Saviq, also, async image providers suck, qt is using a single thread to request them, so basically all requests to custom image providers get serialized
[08:47] <mhr3> tsdgeos, it's kinda random and i can make it happen only on armhf
[08:47] <mhr3> tsdgeos, basically play with it on phone and it crashes after a while
[08:47] <mhr3> tsdgeos, fwiw it's in 005
[08:48] <tsdgeos> ok
[08:48] <Saviq> mhr3, requests, maybe, but the provider can return and fill the image later, no?
[08:48] <Saviq> mhr3, if not, QTBUG
[08:50] <mhr3> Saviq, nope, the sync part of it (the actual ->requestImage() calls) is serialized cause it's being done by just one thread
[08:51] <tsdgeos> mhr3: not the cause of the problem for sure but i'd say if (uri.search(/^http(s)?:/) == 0) { should be if (uri && uri.search(/^http(s)?:/) == 0) { since we're passing down stuff we previously were not checking was undefined or anything
[08:52] <Saviq> mhr3, well, yeah, but I was under the impression that you can return an empty image and fill it later, isn't that how asyncing custom providers work?
[08:52] <tsdgeos> Saviq: nope
[08:52] <mhr3> Saviq, not as far as i know, after you return the image, it will try to just upload it to the gpu, no?
[08:52] <tsdgeos> async providers just promise they won't crash if running in a multithread env
[08:53] <Saviq> mhr3, tsdgeos, :|
[08:53] <Saviq> mhr3, OTOH, the provider is just a single object, right (as opposed to a factory)?
[08:54] <Saviq> mhr3, so that kinda precludes multiple requests at the same time
[08:54] <mhr3> Saviq, not really, the docs do explicitely say that the methods image provider implements need to be reentrant
[08:54] <Saviq> mhm
[08:55] <Saviq> mhr3, in any case, that calls for a QTBUG to find out what's the deal and what can be done about it... like 90% of our SDK uses a custom image provider (via the image://scaled/ provider for @blah) :|
[08:57] <mhr3> well, the thread is per QQmlEngine, but i haven't seen there being multiple QmlEngine, when can that happen?
[09:07] <tsdgeos> mhr3: i really can't find anything wrong in the code, but otoh i'm not really much into std::future (i should look at them more carefully)
[09:08] <mhr3> tsdgeos, i think it actually has something to do with the future/promise
[09:08] <tsdgeos> mhr3: might as well be that the glibc/arm implementation of it is not totally perfect
[09:09] <tsdgeos> it's not like stuff like that hasn't happened before
[09:09] <mhr3> dont even want to think about that
[09:09] <mhr3> tsdgeos, were you able to rep the crash?
[09:10] <mhr3> maybe it's just me in the end? :)
[09:10] <tsdgeos> mhr3: still flashing the phone, just came back from a week of holidays today
[09:11] <mhr3> tsdgeos, right, sorry for jumping on you like that :)
[09:11] <tsdgeos> it's ok :)
[09:12] <mhr3> guess i could try to reimplement it using simple mutex and condvar
[09:23] <tsdgeos> may be one way to try to get it fixed
[09:23] <tsdgeos> mhr3: if you give me soem time i'll try it on the phone and see if i can make it crash too
[09:41] <Cimi> Saviq, I updated infographics apart moving infographics code to sdk, which I will start now
[09:42] <Saviq> Cimi, ktx
[09:53] <mhr3> tsdgeos, think i fixed it, will rebuild the silo
[09:53] <tsdgeos> mhr3: cool
[09:55] <mhr3> tsdgeos, oh, should add the js check.. how do i check if something is string?
[09:55] <mhr3> cause ints won't have .search() :)
[09:55] <tsdgeos> mhr3: there's the tyeof thing
[09:57] <mhr3> -    if (uri.search(/^http(s)?:/) == 0) {
[09:57] <mhr3> +    if (typeof uri == "string" && uri.search(/^http(s)?:/) == 0) {
[09:57] <mhr3> ^^ k?
[09:58] <tsdgeos> triple equal to be more JS
[10:13] <mhr3> Saviq, btw anyone trying u8 on the device with valgrind? it's *very* unhappy about things
[10:14] <mhr3> might have something to do with hybris, but still... at least having a suppressions file would be nice
[10:23] <Saviq> mhr3, tsdgeos has experience
[10:23] <tsdgeos> mhr3: i just ignore all that crap
[10:23] <tsdgeos> :D
[10:24] <tsdgeos> mhr3: agreed someone that knows about android should look at it and either fix it or provide a supressions file
[10:24] <mhr3> tsdgeos, do you also get the please use --workaround-gcc-bug thing?
[10:24] <tsdgeos> hmmm
[10:24] <tsdgeos> don't remember i get that no
[10:25] <mhr3> hm, when i tried it, it started to print hundreds of those, so after a while it just went - oh yea, too many error, i won't report any more
[10:26] <tsdgeos> hmmm
[10:26] <tsdgeos> mhr3: does adding --smc-check=all-non-file help?
[10:26] <mhr3> haven't tried that
[10:27] <tsdgeos> give it a go
[10:27] <tsdgeos> i think i'm using it
[10:28] <mhr3> yea, from reading about that, i guess it could help
[10:29] <mhr3> don't feel like trying to launch it under valgrind again, too much pain and takes ages :P
[10:33] <tsdgeos> :D
[10:40] <greyback> any chance we could get https://codereview.qt-project.org/#/c/84026/ landed in our Qt5.3? I really miss my scrollwheel in QtC
[10:42] <tsdgeos> greyback: let's just update to 5.3.1 :D
[10:42] <greyback> tsdgeos: or that :)
[10:45] <tsdgeos> i'm confused :/
[10:45] <tsdgeos> http://paste.ubuntu.com/7725836/
[10:45] <tsdgeos> how can root be null :/
[10:46] <greyback> dat be f*cked up yo
[10:47] <greyback> tsdgeos: does it crash?
[10:47] <tsdgeos> greyback: i can make it assert or crash or work depending on the elements of that list i comment out
[10:48] <greyback> tsdgeos: eeek
[10:48] <tsdgeos> yep
[10:52] <mhr3> Saviq, ok, so i'm ready to land 005, seems like it's no longer crashing which is good :) the question is are we ok about loosing http pipelining?
[10:53] <Saviq> mhr3, QNetworkAccessManager doesn't do it?
[10:53] <mhr3> Saviq, it does, but as i said earlier, requests from image provider will be serialized, so it will never ask for an image until the previous one finishes loading
[10:55] <Saviq> mhr3, well, as it's cached... shouldn't it be better anyway?
[10:55] <mhr3> it should... once they fix the servers
[10:55] <Saviq> mhr3, most times we shouldn't even hit the servers, right?
[10:55] <Saviq> based on cache control?
[10:55] <mhr3> yea.. it's just they don't serve cache control yet :)
[10:56] <Saviq> so it'll get worse before it gets better? ;)
[10:56] <mhr3> kinda... it will still use the cache, but it will have to validate it first
[10:56] <Saviq> ah so just the HTTP header?
[10:57] <mhr3> yep
[10:57] <mhr3> fwiw that's like 90% of the latency :P
[10:57] <Saviq> trueth
[10:57] <mhr3> but will still save quite some data
[10:57] <Saviq> mhr3, what's the feel btw?
[10:58] <mhr3> Saviq, hm, let me reflash current image to be able to tell :)
[10:58] <mhr3> Saviq, or you can check 005
[11:18] <Saviq> dednick, hmm DashContent failure in move-indicator-qml now?
[11:18] <dednick> Saviq: hm. i'll take a look
[11:42] <sil2100> Saviq: hi! On the last image we noticed a crash happening during unity8 tests, probably causing a test failure
[11:42] <sil2100> Saviq: psivaa filled in a bug for it:
[11:42] <sil2100> Saviq: https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141 <-
[11:43] <sil2100> Saviq: it might not be unity8 here at fault, but still I guess you would be able to judge the best
[11:43] <Saviq> sil2100, if it's qmlscene crashing, then it's not unity8 at fault for sure ;)
[11:44] <Saviq> sil2100, if you get some symbols, please let us know
[11:47] <sil2100> Sure :)
[11:49] <mhr3> Saviq, when you know what you're looking for, you can see that things take longer to load
[11:50] <Saviq> mhr3, I'm starting to wonder... maybe we just need a caching proxy on the device :P
[11:53] <Saviq> mhr3, what's the ETA on fixing the servers?
[11:53] <mhr3> Saviq, i did have the same idea... but shelved in the crazy folder :P
[11:53] <Saviq> not so crazy now!
[11:54] <mhr3> Saviq, for click store it was on staging on friday, but had some issues
[11:55] <mhr3> Saviq, we could still go with what you did - set the cache on the global QmlEngine's network access manager
[11:56] <mhr3> then it will at least still do the pipelining
[11:57] <mhr3> but then we won't be able to cache scaled images
[11:57] <Saviq> mhr3, I'm leaning towards that, we were just missing the per-request setting to use the cache on no network?
[11:57] <mhr3> that shouldn't even be necessary when the servers are fixed
[11:58] <Saviq> well, I'd rather not rely on all servers being fixed ;)
[11:58] <Saviq> mhr3, the scaling is most important for svgs, and we could put those through a different code path than the rest
[12:05] <Cimi> Saviq, i am lost with the inline diffs
[12:05] <Cimi> do you have a tip to see where you comment?
[12:05] <Saviq> Cimi, click on "see inline diff" in the comment header
[12:06] <Saviq> Cimi, and then scroll, unfortunately
[12:06] <Cimi> Saviq, but sends me to your first comment
[12:06] <Saviq> to find
[12:06] <Cimi> not the new added
[12:06] <Saviq> Cimi, right, if it's on the same revision, it's not great
[12:08] <facundobatista> Holas
[12:09] <Cimi> Saviq, I think it doesn't work great with the current implementation, can we stick to the old reviews until they fix the ui?
[12:09] <Saviq> Cimi, no
[12:09] <Saviq> Cimi, I will use it
[12:09] <Cimi> I'm scrolling in this super long page trying to find your comments
[12:09] <Saviq> it's not great, but it's still much better
[12:09] <Cimi> and where you replied
[12:10] <Saviq> Cimi, Ctrl+F
[12:10] <Cimi> before was simply looking at the comment, easy
[12:10] <Cimi> so I should ctrl f saviq? :)
[12:10] <Saviq> Cimi, yeah, you know it was me that commented
[12:11] <Cimi> Saviq, so basically what's wrong is the wrapper?
[12:11] <Saviq> Cimi, its existence
[12:11] <Cimi> I thought it was fine
[12:11] <Cimi> abstract programming
[12:12] <Saviq> Cimi, just for the purpose of having 2 props, there's no point in adding another object / hierarchy level
[12:12] <Cimi> Saviq, that's because now we have two props
[12:12] <Cimi> we might change implementation
[12:12] <Cimi> anyway ok
[12:13] <Saviq> Cimi, when we change the implementation so that it requires a wrapper, let's!
[12:13] <Cimi> Saviq, so I should remove the first preload in tests/qmltests/CMakeLists.txt ?
[12:14] <Saviq> Cimi, LD_ only matters for linking, for dynamically loaded libraries
[12:14] <Cimi> I thought I needed it for test/mocks/Infographics
[12:14] <Cimi> to avoid using thr system one
[12:14] <Saviq> Cimi, ld doesn't know anything about QML, qmldir or whatnot
[12:14] <Saviq> Cimi, that's what you have QML2_IMPORT_PATH for
[12:14] <Cimi> ok
[12:17] <Cimi> Saviq, although makes testing the infoghraphics harder
[12:17] <Saviq> Cimi, what does?
[12:17] <Cimi> Saviq, because you'd have to use the whole greeter then
[12:17] <Saviq> Cimi, when?
[12:17] <Cimi> Saviq, merging Greeter/Infographics.qml into Greeter/GreeterContent
[12:18] <Saviq> Cimi, I'm not saying you should do that
[12:18] <Cimi> Saviq, I'd have to move the tests into tstSingleGreeter
[12:18] <Saviq> Cimi, I'm saying the Item in Infographics.qml is not needed
[12:18] <Cimi> sh using CrossFadeImage directly?
[12:18] <Saviq> yes
[12:18] <Cimi> that was abvious
[12:18] <Cimi> my bad
[12:25] <Saviq> mhr3, so what do we do, what do we do? it's a rock and a hard place :|
[12:26] <mhr3> Saviq, i want proper async image providers :/
[12:27] <Saviq> mhr3, I *know*, and a way to override the default one...
[12:28] <mhr3> Saviq, if we're not going to do caching of scaled images, i think we should just override the network access manager
[12:28] <mhr3> Saviq, although you didn't like it's feel either when you tried it right?
[12:28] <mhr3> its*
[12:28] <Saviq> mhr3, that was non-authoritative...
[12:28] <Saviq> mhr3, I never tried on device
[12:29] <Saviq> mhr3, and spent like 2 minutes on this
[12:32] <mhr3> Saviq, hm, let's revisit it, i'll build it in 005 and see if it's better
[12:32] <Saviq> mhr3, yup, thanks
[12:33] <mhr3> Saviq, can you change owner of https://code.launchpad.net/~saviq/unity8/cache-network-data to unity-team?
[13:11] <kgunn> tsdgeos: welcome back!
[13:12] <tsdgeos> kgunn: hi
[13:12] <kgunn> dednick: do you just need a volunteer for review ?
[13:12] <kgunn> https://code.launchpad.net/~nick-dedekind/unity8/indicator.call-hint/+merge/218627
[13:13] <dednick> kgunn: hm. nearly. i'm busy fixing the tests.
[13:13] <dednick> i'll put it back in wip
[13:14] <kgunn> dednick: its fine...
[13:14] <kgunn> pretty large code diff, i never realized it was that meaty
[13:49] <paulliu> Saviq: if I want to test the logout Dialog stuff. I'll need to trigger a fake dbus event. Does that mean I need to go writing some code in tests/mocks/Unity/Session? Is tests/mocks for that?
[13:51] <Saviq> paulliu, yeah, you want a mock object that doesn't actually talk DBus
[13:51] <Saviq> paulliu, but you can control from the test
[13:51] <paulliu> Saviq: ok. got it.
[13:51] <Cimi> Saviq, branch updated
[13:52] <Saviq> Cimi, k
[14:55] <Saviq> dednick, could you go through https://code.launchpad.net/~unity-team/unity8/suru-switch/+merge/207991 please
[14:55] <Saviq> dednick, stuff this depends on is built in silo 004
[14:57] <Saviq> dednick, ah crap, need to put the image thing in settings components, settings UI is broken with it, too :|
[14:57] <dednick> Saviq: image thing?
[14:58] <Saviq> dednick, I had to re-do SDK's Icon
[14:58] <Saviq> dednick, to maintain aspect ratio of icons
[14:58] <Saviq> dednick, bug #1284235
[14:59] <tsdgeos> dandrader: http://paste.ubuntu.com/7726801/ looks scary
[15:03] <dednick> Saviq: property string iconPath: "/usr/share/icons/suru/status/scalable/%1.svg" - is that your fix for it picking up the lower prioirty icons?
[15:03] <Saviq> dednick, not really, I need to load the images directly through Image
[15:03] <Cimi> mterry, we have a crash on the wizard with the wifi
[15:03] <Saviq> dednick, themed icons can only be square
[15:04] <Saviq> dednick, side-effect is indeed that the priority problem is gone
[15:04] <Saviq> dednick, it's a nasty hack, but we won't fix it properly in time
[15:04] <Saviq> dednick, and we need to land this shit finally
[15:05] <dednick> Saviq: uhuh :)
[15:05] <Saviq> dednick, another solution welcome
[15:05] <Cimi> mterry, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1334203
[15:05] <Cimi> mterry, I had a look, and I will have a look now
[15:06] <Cimi> mterry, if you have ideas... throw
[15:06] <dednick> Saviq: write a c++ image component?
[15:06] <Cimi> mterry, from what I have seen, it's the property http://paste.ubuntu.com/7710506/
[15:06] <mterry> Cimi, I haven't looked into that yet.  Not sure off the top of my head
[15:07] <Saviq> dednick, that doesn't solve the problem that themed icons can only be square by definition of the icon theme
[15:07] <Saviq> dednick, so would be a workaround just as the one I'm proposing
[15:07] <mterry> Cimi, ah maybe destroying that property is buggy
[15:07] <Saviq> dednick, the index.theme files only deal with one-dimensional "size" of the icon, resulting in the assumption that the icons are square
[15:08] <Saviq> dednick, which means you'd need to load the image file to find the aspect ratio out, at which point the whole icon theme system becomes kinda useless
[15:08] <mterry> Cimi, maybe also related to bug 1335298
[15:08] <dednick> Saviq: hm. I'm sure the bluetooth icon was rectangluar at some point.
[15:09] <Saviq> dednick, sure, that's why unity7 has its own loading implementation, too ;)
[15:09] <dednick> Saviq: although that may have been due to some aspect
[15:09] <Saviq> dednick, battery is rectangular
[15:09] <Cimi> mterry, but not bug on our side?
[15:09] <Cimi> mterry, do you know what can we do to workaround this property?
[15:10] <mterry> Cimi, I don't know if it's a bug on our side or not
[15:10] <Cimi> mterry, I don't think it is
[15:10] <Cimi> mterry, commenting out that code makes the wizard stop crashing
[15:11] <mterry> Cimi, does other code that uses UnityMenuAction have this problem, is what I'm wondering?
[15:11] <mterry> Cimi, i.e. is it a problem with UnityMenuAction, or how we use it
[15:12] <Cimi> dednick, about the crash with UnityMenuAction
[15:12] <Cimi> http://paste.ubuntu.com/7710506/
[15:12] <Cimi> dednick, this makes the wizard crash on some occasions
[15:12] <Cimi> dednick, do we have similar crashes somewhere else on the platform?
[15:13] <Cimi> dednick, are we using it wrong in the wizard?
[15:13] <dednick> Cimi: can you send a stacktrace?
[15:13] <Cimi> not sure hot to get it
[15:13] <Cimi> mterry, to get stacktrace we attach gdb right?
[15:13] <mterry> Cimi, yeah
[15:13] <Cimi> which dbg symbols we need?
[15:14] <dednick> Cimi: apport-cli /var/crash/XXX.crash
[15:14] <Cimi> mterry, in order to reproduce bug I need to have wifi off
[15:14] <Cimi> so might try to manually get dbg
[15:14] <mterry> Cimi, you probably want qtbase5-dbg at least
[15:15] <mterry> Cimi, not sure which package has UnityMenuAction
[15:15] <Cimi> mterry, qmenumodel
[15:16] <Cimi> but I don't see dbg for it
[15:16] <dednick> libqmenumodel
[15:16] <Cimi> dednick, and debug symbols?
[15:19] <dednick> Cimi: libqmenumodel0-dbgsym
[15:19] <Cimi> it's not on the phone
[15:19] <Cimi> what shall I enable?
[15:20] <Cimi> who knows guys?
[15:20] <dednick> Cimi: https://wiki.ubuntu.com/DebuggingProgramCrash
[15:20] <dednick> on phone presumably
[15:21] <dednick> Saviq: you need me to check that branch out now, or you doing something in usc for it?
[15:22] <Saviq> dednick, yeah, I'll have another usc branch for this in a few mins hopefully
[15:23] <Cimi> dednick, mterry http://paste.ubuntu.com/7726901/
[15:23] <Cimi> so yeah I need those symbols
[15:27] <dednick> Cimi: that trace was fine.
[15:31] <dednick> Cimi: where is the code?
[15:34] <Cimi> dednick, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/wizard/qml/Pages/20-wifi.qml
[15:34] <Cimi> line 121 I think
[15:35] <tsdgeos> kgunn: Saviq: some managementarial decision needed at https://bugs.launchpad.net/unity8/+bug/1332598
[15:36] <tsdgeos> upstream guys that can decide on that bug seem to be away for a while
[15:37] <Saviq> dednick, https://code.launchpad.net/~unity-team/ubuntu-settings-components/status-icon/+merge/225034
[15:37] <tsdgeos> dandrader: can you confirm that your crash is also gone if you use the patch from https://codereview.qt-project.org/#/c/88717/ ?
[15:38] <dednick> hm. network indicator doesnt seem to work on desktop anymore...
[15:38] <dednick> tedg: ^ ?
[15:38] <dandrader> tsdgeos, will try it now
[15:43] <dandrader> tsdgeos, yes, it does fix it!
[15:44] <tsdgeos> Saviq: so how do we proceed in here? ↑
[15:44] <dednick> Cimi: hm. doesnt seem to crash on desktop.
[15:46] <dednick> Cimi: does it always happen under certain cirumstances? how to reproduce?
[15:49] <dandrader> mzanetti, hey, what's the situation with "dash as an app"?
[15:50] <dandrader> ie, why did we stop working on it?
[15:50] <mzanetti> dandrader: we decided to land that separately, no?
[15:50] <mzanetti> dandrader: we didn't really stop working on it
[15:50] <dandrader> mzanetti, I don't remember. that's why I'm asking :)
[15:50] <kgunn> tsdgeos: so iiuc, upstream says "your patch is our best guess"
[15:50] <kgunn> "use it, until we fix it"
[15:50] <mzanetti> dandrader: that's one step towards that: https://code.launchpad.net/~mzanetti/unity8/new-header/+merge/224585
[15:50] <tsdgeos> kgunn: upstream says "the guys that knows how this works are on holiday, your patch doesn't look terribly wrong to the guys left"
[15:51] <mzanetti> dandrader: once this has landed there shouldn't be any links between shell and dash any more in the code.
[15:51] <mzanetti> dandrader: I already have a branch here that creates an application binary for it
[15:51] <dednick_> Saviq: has that usc branch gone into the silo?
[15:51] <kgunn> tsdgeos: based on your experience & dandrader, we should go for a distro patch  & stick it in ci-train...we can always ask for more extensive testing
[15:51] <tsdgeos> kgunn: +1
[15:52] <mzanetti> dandrader: one thing missing is we need ApplicationManager pick up applications started by upstart (as opposed to ubuntu-app-launch) so the dash would appear in the running apps list
[15:52] <kgunn> e.g. get a qa resource at least, and maybe pull in some app folk
[15:52] <dednick_> Saviq: ubuntu-settings-components  branch that is
[15:52] <tsdgeos> does anyone know if Mirv is on holiday?
[15:52] <mzanetti> dandrader: I decided not to make Gerry do that before we have QtComp in, or at least in the silo
[15:52] <kgunn> tsdgeos: he was...
[15:52] <tsdgeos> he always does the ci-train-ing of Qt stuff for me
[15:52] <kgunn> mmm he's Finnish....might be long vacation
[15:53] <Saviq> dednick_, not yet, lemme add
[15:53] <mzanetti> kgunn: tsdgeos: yeah, I think its another week
[15:53] <dednick_> Cimi: not sure if you got my message. How do you reproduce the crash? doesnt seem to occur on desktop
[15:53] <kgunn> mzanetti: did you get a Qt-patch in ci-train ?
[15:53] <kgunn> ...i know the process is a little diff
[15:53] <mzanetti> into the train yes, not sure if it made it into the image yet
[15:54] <dandrader> mzanetti, because I think "dash as an app" is an important piece in the "shell rotation" story
[15:54] <mzanetti> dandrader: I agree that might make things a lot easier
[15:54] <kgunn> mzanetti: did you use a canonical branch ? or just local mod and give src ball to core dev
[15:54] <kgunn> assuming you did this w/o Mirv
[15:54] <mzanetti> dandrader: well. afaik we were also not enabling rotation for the first batch of QtComp goodness
[15:54] <dandrader> mzanetti, on the phone. Dash stays in portrait but the indicartors panel,  launcher etc do rotate according to app preferences
[15:55] <mzanetti> kgunn: I used the kubuntu-packagers branch and proposed my change towards that
[15:55] <mzanetti> kgunn: after I figured we got the packages from that one lately
[15:55] <dandrader> mzanetti, and we hopefully also mitigate (or even eliminate) that horrible ~2 secs gui choke when resizing unity8 due to a rotation
[15:55] <mzanetti> dandrader: huh? we're going to rotate launcher and panel but not the rest?
[15:56]  * mzanetti wonders how we even do that
[15:56] <dandrader> mzanetti, with dash as an app?
[15:56] <Saviq> mzanetti, well, dash might choke, shell won't ;)
[15:56] <mzanetti> ah... yeah, once its an app, yes
[15:57] <mzanetti> I thought dandrader was doing that with current codebase
[15:57] <Saviq> dednick_, is building
[15:58] <mzanetti> dandrader: so yeah, after QtComp is in the silo and requires less attention we're going to do the appman changes and finish my branch with the separate app for the dash
[15:58] <mzanetti> dandrader: then you can finalize the rotation along with that
[15:59] <Cimi> dednick_, on the phone
[16:00] <Cimi> dednick_, https://bugs.launchpad.net/qmenumodel/+bug/1334203
[16:00] <Cimi> dednick_, basically on the phone, you have to do
[16:01] <Cimi> rm /etc/NetworkManager/system-connections/%
[16:01] <Cimi> rm /etc/NetworkManager/system-connections/*
[16:01] <Cimi> then
[16:01] <Cimi> rm /home/phablet/.config/ubuntu-system-settings/wizard-has-run
[16:01] <Cimi> reboot
[16:02] <Cimi> at the wizard, wait till it loads wifi then you tap back
[16:02] <Cimi> happens 100% here
[16:03] <kgunn> tsdgeos: are you familiar with that part of the process ? (see zanetti's post wrt kubuntu-packagers)
[16:04] <mzanetti> tsdgeos, kgunn: fyi, this is the branch: https://code.launchpad.net/~mzanetti/kubuntu-packaging/qtdeclarative-opensource-src/+merge/224517
[16:06] <kgunn> yep...i see it now, tsdgeos, if you  can upload in the same fashion & get me the mp, i can get you on the ci-train
[16:06] <dednick_> Cimi: need to connect to a wifi hotspot?
[16:06] <tsdgeos> kgunn: tomorrow :)
[16:07] <kgunn> tsdgeos: no worries...you can hit up Saviq you're morning, he can get you on the train
[16:07] <tsdgeos> cool :)
[16:07]  * tsdgeos leaves for the day
[16:08]  * kgunn feels qt code control less out of control than he thot...
[16:08] <kgunn> still seems funky
[16:09] <Cimi> dednick_, no
[16:10] <dednick_> Cimi: didnt work for me.
[16:10] <Cimi> dednick_, clear as I said
[16:10] <dednick_> Cimi: i'm flashing device.
[16:10] <Cimi> dednick_, do not connect to any wifi
[16:10] <dednick_> Cimi: i didnt
[16:10] <Cimi> dednick_, otherwise bootstrap
[16:10] <dednick_> Cimi: heh. good luck getting me to do that ;)
[16:10] <Cimi> dednick_, https://bugs.launchpad.net/qmenumodel/+bug/1334203
[16:28] <Cimi> dednick_, luck?
[16:29] <dednick_> Cimi: :( nope
[16:29] <Cimi> dednick_, do you want me to test code?
[16:35] <Cimi> dednick, do you want me to test code?
[16:35] <dednick> Cimi: give me a minute.
[16:35] <Cimi> ok
[17:12] <dednick> Cimi: reproduced.
[17:32] <mhr3> Saviq, here?
[17:34] <mhr3> Saviq, when you will be - https://code.launchpad.net/~unity-team/unity8/cache-network-data/+merge/224995 seems to work fine and ready for landing in 005
[17:45] <dednick> Cimi: https://code.launchpad.net/~nick-dedekind/qmenumodel/unitymenuaction.lp1334203
[19:42] <Saviq> mhr3, kk
[20:31] <Saviq> seb128, could you please resubmit https://code.launchpad.net/~seb128/ubuntu-system-settings/use-theme-icons/+merge/214950 using lp:~unity-team/ubuntu-system-settings/use-theme-icons instead?