=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:02] <dangerranger11b> hey guys I cant find any help on this I am new to linux and am using the latest version of ubuntu. When I shut my lid and open it the lights on my keyboard light up but the screen wont turn on. It is a pavilion g6. I have read the forums but no real solutions can be found
=== duflu_ is now known as duflu
[09:34] <pstolowski> mzanetti, hey, do you plan to land https://code.launchpad.net/~aacid/unity8/bottom_list_no_favorites/+merge/244169 this with your existing silo?
[09:34] <pstolowski> tsdgeos, ^
[09:41] <tsdgeos> Saviq: how's the sickness today?
[09:41] <Saviq> pstolowski, yes, that's what we were waiting for
[09:41] <Saviq> tsdgeos, I'm around, not 100%, but am ok
[09:42] <tsdgeos> Saviq: was thinking on https://code.launchpad.net/~seb128/unity8/set-inline-reply-hint/+merge/240766, do we want the pot regeneration to be included in it?
[09:42] <pstolowski> Saviq, k, thanks. get well!
[09:43] <Saviq> pstolowski, we still don't have a clear solution on bug #1400762 though
[09:43] <ubot5> bug 1400762 in unity8 (Ubuntu) "Manage Dash allows to unfavourite all scopes and leave you with a blank page" [Critical,Triaged] https://launchpad.net/bugs/1400762
[09:44] <Saviq> pstolowski, I'd like to wait for design guidance on it
[09:44] <Saviq> tsdgeos, makes sense, yeah
[09:49] <tsdgeos> waaaaaaaaaa
[09:49] <tsdgeos> what's up with the wizard now
[09:50] <tsdgeos> we won all it's messages, but will it work?
[09:50] <Saviq> tsdgeos, ?
[09:51] <Saviq> tsdgeos, ah
[09:51] <tsdgeos> Saviq: http://paste.ubuntu.com/9454259/
[09:52] <Saviq> tsdgeos, that'd be mterry's importing the wizard into our codebase (since we want to have it run as part of unity8 on first launch)
[09:52] <Saviq> but it's not used yet
[09:53] <Saviq> maybe we should make all the tr()s for the wizard use the settings' domain for now
[09:54] <tsdgeos> Saviq: i don't think it makes sense, the messages will disappear from settings once they go away from the codebase
[09:54] <Saviq> tsdgeos, right
[09:54] <tsdgeos> Saviq: question is if i should propose a MR with the .po changes or tell seb to merge trunk in his and re-use it for that too?
[09:54] <Saviq> tsdgeos, separate MP please
[09:55] <tsdgeos> then it will conflict :D
[09:55] <Saviq> let's put it in the silo we have now already
[09:55] <Saviq> tsdgeos, we'll release that sooner
[09:55] <tsdgeos> ok
[09:55] <Saviq> tsdgeos, yeah, I know, we really need the train to do it, but apparently I don't have enough push to get that implemented :/
[09:56]  * Saviq needs food
[09:57] <tsdgeos> Saviq: there it goes https://code.launchpad.net/~aacid/unity8/make_pot_file/+merge/244267
[09:59] <tsdgeos> dednick: ping on https://code.launchpad.net/~nick-dedekind/qmenumodel/lp1385331.led/+merge/241422 ?
[10:02] <Saviq> tsdgeos, re: power on lock, this was the initial approach https://code.launchpad.net/~mterry/unity8/cache-greeter-bg/+merge/239144
[10:03] <Saviq> tsdgeos, but it's contested because of the increased mem usage
[10:03] <tsdgeos> aha
[10:03] <dednick> tsdgeos: the ActionStateParser created in the constructor is qobject parented to the QDBusActionGroup.
[10:04] <dednick> so it will be deleted
[10:04] <Saviq> dednick, can you explain on bug #1372061 what needs to happen?
[10:04] <ubot5> bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress] https://launchpad.net/bugs/1372061
[10:11] <tsdgeos> dednick: right, but wouldn't be my suggestion simpler?
[10:18] <dednick> tsdgeos: urrg. not really. QStateAction uses the actionState method. Wont be able to override the actionStateParser unless i put a actionStateParser property in there...
[10:19] <dednick> tsdgeos: i could give it a go...
[10:20] <dednick> tsdgeos: it would be a bit neater though
[10:20] <tsdgeos> dednick: who calls actionState ?
[10:21] <dednick> tsdgeos: QStateAction in qmennumodel, ActionRootState & ModelActionRootState in unity8
[10:38] <tsdgeos> dednick: i see, ok, maybe then just add a comment to setActionStateParser saying that the class does not take ownership of actionStateParser?
[10:39] <dednick> tsdgeos: ok
[10:39] <tsdgeos> qt5.4 is out \o/
[10:44] <tsdgeos> dednick: you're probably the best to review https://code.launchpad.net/~paulliu/unity8/lp1378469_MessageMenu/+merge/244164 right?
[10:51] <dednick> tsdgeos: ok
[10:59] <Saviq> dednick, thanks
[11:06] <facundobatista> Holas
[11:11] <mzanetti> Wellark: ping
[11:11] <Wellark> mzanetti: pong
[11:12] <mzanetti> Wellark: so, what's the issue?
[11:12] <mzanetti> and what's the status?
[11:13] <Wellark> mzanetti: I have an MP that clears the errorAction status when the first pin unlock dialog is closed
[11:13] <Wellark> but still
[11:14] <Wellark> the second dialog picks up the error message from the first dialog (this might be because of the async nature of all of this communication)
[11:14] <Wellark> and displayes the error message from the first dialog on the second one as well
[11:15] <mzanetti> Wellark: what's the branch?
[11:15] <Wellark> mzanetti: https://code.launchpad.net/~unity-api-team/indicator-network/lp1382033-14.09/+merge/244128
[11:16] <Saviq> Wellark, bug #1400502 is getting annoying, think you could make something happen?
[11:16] <ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
[11:18] <Wellark> Saviq: for some reason that has escaped my filters
[11:18] <Wellark> python3-xdg:armhf not being installable
[11:18] <Wellark> any idea what's behind that?
[11:19] <Wellark> sounds like a root cause
[11:25] <Saviq> Wellark, it's Arch :all
=== _salem is now known as salem_
[11:26] <Saviq> Wellark, so it would have to be python3-xdg:any maybe, but I'm not sure that's good to have in runtime depends
[11:40] <Wellark> Saviq: I don't know where that dependency is coming
[11:41] <Wellark> oh, right
[11:41] <Wellark> from i-network
[11:41] <Saviq> Wellark, yeah
[11:42] <Wellark> but I don't know how that is not working
[11:42] <Wellark> python3-xdg is a main package
[11:43] <Wellark> anyway, I need to grab a quick lunch
[11:43] <Saviq> Wellark, but it's :all, and :armhf is being requested
[11:44] <Saviq> Wellark, so well, I agree this might be an apt dep resolution bug
[11:44] <Wellark> Saviq: how would you suggest to fix this?
[11:44] <Wellark> i-network only lists plain "python3-xdg" dep
[11:44] <Saviq> Wellark, I think we talked about making i-networj a Recommends
[11:44] <Saviq> if possible
[11:44] <Saviq> otherwise this pulls in unity8 itself, even
[11:45] <Wellark> yes, but the real issue seems to be python3-xdg not being installable
[11:45] <Wellark> which is weiard
[11:45] <Saviq> Wellark, you can emulate by trying to do "sudo apt-get build-dep -ai386 unity8"
[11:46] <Wellark> so, having connectivity-api Recommends i-network would leave it uninstalled?
[11:46] <Saviq> Wellark, yeah, I agree, you might wanna raise this with core devs
[11:46] <Saviq> Wellark, yes
[11:46] <Wellark> me? :)
[11:46] <Wellark> I have not seen this issue :P
[11:46] <Saviq> Wellark, fine, I will
[11:47] <Wellark> Saviq: if the above line provides an easy repro, please add it to the bug report
[11:47] <Wellark> so I can get back to this
[11:48] <Wellark> Saviq: will change i-network as recommends then
[11:48] <Saviq> Wellark, just added to bug
[11:48] <Wellark> but now.. some lunch
=== dandrader is now known as dandrader|afk
[12:27] <tsdgeos> mzanetti: i can randomly reproduce the fact that dash doesn't come up with no scopes
[12:27] <tsdgeos> having a look
[12:27] <mzanetti> tsdgeos: ah good. yeah, didn't happen 100% here either.
[12:27] <mzanetti> tsdgeos: so the splash goes away when the app paints its first frame
[12:28] <mzanetti> I think that's not happening in that case. the fact that you added the pull up thingie decreased chances of it happening, as that one comes in and causes the app to paint
[12:29] <tsdgeos> well
[12:29] <tsdgeos> but we should still have the gray background no?
[12:29] <tsdgeos> otherwise it seems there's a race somewhere
=== dandrader|afk is now known as dandrader
[12:57] <Saviq> tsdgeos, I think we know that issue
[12:58] <Saviq> bug #1394208
[12:58] <ubot5> bug 1394208 in qtmir (Ubuntu) "Unity8 unable to find the dash, which is also running in the background" [High,Triaged] https://launchpad.net/bugs/1394208
[12:58] <Saviq> mzanetti, ↑
[12:58] <Saviq> this happens sometimes when dash starts too early and AppMan misses its startup
[13:02] <Saviq> Cimi, mzanetti, why the "autohideEnabled: false" prop?
=== alan_g is now known as alan_g|a
=== alan_g|a is now known as alan_g|lunch
[13:02] <Saviq> in https://code.launchpad.net/~cimi/unity8/fix-1368778-2/+merge/242942 that is
[13:04] <Saviq> tsdgeos, is it by design that Manage header text and icon is lighter than the default for scopes?
[13:05] <Saviq> tsdgeos, also, what's happening with the header icons in the dash when opening Manage ¿?
[13:06] <Saviq> Cimi, tsdgeos, what's up with https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 btw?
[13:07]  * Saviq logs in to unity8@desktop
[13:22] <mzanetti> Wellark: ok... so seems that error text is coming in again when the second notification is created
[13:23] <mzanetti> Wellark: UnityMenuAction triggers a stateChanged event with an error text
[13:24] <Saviq> seb128, seems your override says lowercase "unity8", the setting is under title-cased "Unity8" though
[13:29] <Cimi> Saviq, to disable autohide
[13:29] <Cimi> Saviq, we will need autohide on desktop
[13:29] <Cimi> Saviq, he asked me to keep the code and just disable it with a property
[13:29] <Wellark> mzanetti: hmpf..
[13:30] <Saviq> Cimi, we could hook it up to the unity7 setting already...
[13:30] <Wellark> mzanetti: I'm trying to make sense of the dbus logs I got
[13:30] <Wellark> to see if i-network is actually doing with the states
[13:30] <Cimi> Saviq, well we want always off for now...
[13:30] <Cimi> Saviq, let's hook it up later
[13:30] <Saviq> Cimi, meh, ok
[13:30] <Cimi> Saviq, and have this bug fixed
[13:31] <Wellark> or is this just that the actiongroups are cached on unity8 side and something weird happens with the loader
[13:31] <Cimi> Saviq, not sure which are defaults...
[13:31] <mzanetti> Saviq: yeah, I'm gonna work on this as soon as I have mouse input available
[13:31] <Saviq> Cimi, default is no hiding
[13:32] <Wellark> mzanetti: would it still be possible to clear the error text immediately if unity8 gets errorAction.stateChanged signal that contains "" ?
[13:32] <Saviq> but yeah, fine
[13:32] <mzanetti> Wellark: yeah, but once you set some error it'll shake
[13:32] <Saviq> mzanetti, is power indicator b0rked for you on unity8 desktop?
[13:32] <mzanetti> Saviq: with the silo? or in general?
[13:32] <mzanetti> need to test
[13:32] <Saviq> mzanetti, in general
[13:33] <mzanetti> Saviq: seems ok
[13:33] <mzanetti> what's wrong?
[13:34] <Saviq> mzanetti, has a 2GU correct background and black for the rest, here
[13:34] <mzanetti> let me start the vm with the real session
[13:34] <Saviq> mzanetti, yeah, it has to be the actual desktop session
[13:35] <mzanetti> still good here
[13:35] <Saviq> weird
=== alan_g|lunch is now known as alan_g
[13:50] <tsdgeos> Saviq: i'm waiting on Cimi on that one, no idea what's going on
[13:51] <tsdgeos> Saviq: is it different color? it's using the same component
[13:51] <tsdgeos> Saviq: not sure what you mean with the header icons
[13:54] <tsdgeos> you're right is a different color
[14:00] <Cimi> Saviq, tsdgeos did we get a silo for that?
[14:01] <tsdgeos> Cimi: i don't know, yuo can still compile the code, no?
[14:02] <Cimi> tsdgeos, sure but I have been told many times we were building a silo :)
[14:03] <tsdgeos> Cimi: well then ask who told you, not me :)
[14:05] <Cimi> tsdgeos, I did :P
[14:05] <tsdgeos> Saviq: regarding the color, i can bind the root scope style to  the header, but it's still not coming down, so it'll still be a differnet color than applicaions that specifies a color
[14:05] <tsdgeos> but i'll write a MR with it
[14:05] <tsdgeos> so it can be changed if needed
=== salem_ is now known as _salem
[14:43] <seb128> Saviq, sorry, I copied from the bug description
[14:43] <seb128> Saviq, no bonus point to mzanetti if he wrote it wrong in the summary
[14:45] <mzanetti> :D
[14:46] <mzanetti> seb128: yep, true, my bad
[14:47] <seb128> mzanetti, Saviq, so do I need to change it to Unity8?
[14:47] <mzanetti> seb128: yes," gsettings set com.canonical.Unity8 usage-mode Windowed" would be the call
[14:47] <mzanetti> let me verify :D
[14:47] <seb128> mzanetti, k, need to redo an upload I guess
[14:47] <seb128> when is the unity side going to land?
[14:48] <mzanetti> seb128: Saviq is currently testing the silo
[14:53] <greyback>  libconnectivity-qt1-dev:armhf : Depends: libconnectivity-qt1:armhf (= 0.0.1+14.10.20140826-0ubuntu1) but it is not going to be installed
[14:53] <greyback> anyone see that when trying to sbuild unity8?
[14:56] <pstolowski> Saviq, mzanetti what's your eta for landing of silo 3?
[14:56] <tsdgeos> greyback: merge ?
[14:56] <greyback> tsdgeos: I have
[14:57] <tsdgeos> greyback: ok, i could build not much ago
[14:57] <greyback> ok
[14:57]  * greyback checks if he did a bad merge
[14:57] <tsdgeos> greyback: any idea what logs UbuntuWindow::handleSurfaceResize  ?
[14:57] <greyback> tsdgeos: qtubuntu
[14:58] <tsdgeos> greyback: any quick guess on why sometimes unity8-dash would not get there? if not it's ok, i'm debugging it
[14:59] <greyback> tsdgeos: so that is printed when shell resizes the surface on the app. Shell only resizes surface when it has been added to the qml scene, which happens only when the app  has drawn its first frame
[15:00] <tsdgeos> greyback: can it happen that the app renders its first frame before the shell "is looking"?
[15:00] <greyback> I don't understand "is looking" ?
[15:01] <greyback> you mean, is it possible for app to render a frame and shell to not know about it?
[15:01] <tsdgeos> yes
[15:01] <tsdgeos> because it'd seem it's what i'm having
[15:01] <greyback> that isn't possible, unless I screwed up somewhere
[15:02] <greyback> to show you the relevant parts of the code, look at lp:qtmir in modules/Unity/Application/mirsurfaceitem.cpp
[15:03] <greyback> there's a MirSurfaceObserver::frame_posted method in there - that is registered as a callback with Mir, and is called when the app has drawn its frame & swapped
[15:04] <tsdgeos> oki
[15:04] <tsdgeos> i'll dig a bit more around there
[15:04] <tsdgeos> tx
[15:04] <greyback> MirSurfaceManager::onSessionCreatedSurface creates the MirSurfaceItem, which should be called in a blocking manner by Mir also
[15:06] <dandrader> tsdgeos, mind if I claim that review? https://code.launchpad.net/~mterry/unity8/power-button-on-lock/+merge/239076
[15:06] <tsdgeos> dandrader: all yours
[15:14] <Saviq> greyback, bug #1400502
[15:14] <ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
[15:16] <Saviq> greyback_, bug #1400502
[15:16] <ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
[15:17] <Saviq> greyback_, looks like i-network is missing Multi-Arch: foreign is the actual issue
=== _salem is now known as salem_
[15:17] <dandrader> Saviq, that build failure might be related to it I guess?  https://launchpadlibrarian.net/192260397/buildlog_ubuntu-vivid-armhf.unity8_8.02.4%2Bbzr1487~ubuntu15.04.1_FAILEDTOBUILD.txt.gz
[15:18] <Saviq> dandrader, yes, same issue
[15:18] <greyback_> Saviq: cool, thanks for finding it
[15:36] <mterry> dandrader, removed tags  :-/
=== dandrader is now known as dandrader|lunch
[15:51] <Saviq> mterry, dude, where are you taking them from :D
[15:51] <mterry> Saviq, I DON'T KNOW
[15:52] <mterry> Saviq, they showed up in a remote branch that I only ever worked on locally in a checkout that didn't have any tags
[15:52]  * mterry is paranoid now
[16:04] <Mirv> I think people in general are paranoid on "where do those tags come from!? ghost tags, I say, ghost tags!"
[16:04] <tsdgeos> greyback_: how do i build qtmir on the device? cmake && make don't seem to work
[16:04] <Mirv> they just keep on coming back no matter how many times they're killed
[16:04] <greyback_> tsdgeos: don't work - how?
[16:04] <greyback_> is it crashing?
[16:05] <tsdgeos> greyback_: http://paste.ubuntu.com/9460651/
[16:05] <tsdgeos> i'm guessing i need some cmake option/Define/somethig
[16:05] <tsdgeos> th README is old btw, mentions qmkae
[16:06] <greyback_> tsdgeos: as if it's missing -lgl in the linker flags. Odd. I'll be honest, I've not built on device since we switched to cmake, it might be a bug
[16:06] <greyback_> lemme try it here
[16:06] <greyback_> also, might need  -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc-4.9 -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++-4.9
[16:06] <greyback_> to ensure it uses g++4.9 - not sure if that's relevant on vivid
[16:18] <greyback_> tsdgeos: need to add " -DUSE_OPENGLES=1" to cmake command
[16:18] <tsdgeos> greyback_: tx
[16:19] <greyback_> that's annoying, need to autodetect that somehow
[16:23] <tsdgeos> +1
[16:23] <tsdgeos> a compile check should not be that hard, no?
[16:23] <tsdgeos> LastFamousWords
[16:23]  * tsdgeos runs
=== dandrader|lunch is now known as dandrader
[16:57] <dandrader> mterry, what do the qml/Greeter/Infographics.qml changes have to do with making loading async?
[16:59] <mterry> dandrader, there was a race between the animation and objects being constructed async by qml
[16:59] <mterry> Got some console warnings
[17:01] <mterry> dandrader, the actual "make it asyn" change was relatively simple.  Most of those code changes are cleanup to handle objects being loaded async
[17:01] <dandrader> ok
[17:04] <dandrader> mterry, speaking about console warnings
[17:05] <dandrader> mterry, I'm getting thousands of warnings in "make testMultiGreeter" like this one: file:///home/dandrader/unity8/power-button-on-lock/qml/Greeter/Infographics.qml:188: TypeError: Cannot read property of null
[17:05] <dandrader> mterry, could you also fix this one in this MP? hopefully it's a one liner
[17:06] <dandrader> mterry, although it's not strictly related to subject of this MP
[17:21] <mterry> dandrader, will look
[17:28] <mterry> dandrader, done
[17:29] <dandrader> mterry, thanks!
[17:29] <mterry> dandrader, huh!
[17:29] <mterry> dandrader, doing that brought the tags back
[17:29] <mterry> Oh!  I wonder if it's because I have a local repo, not just a branh
[17:30] <dandrader> mterry, the tags must be in your local rope. did you run strip_tags on it?
[17:30] <dandrader> rope/repo
[17:31] <mterry> dandrader, not in my local branch, but I'm guessing they're hiding in the repo itself
[17:31] <mterry> but the strip script doesn't handle repos
[17:31] <dandrader> mterry, works for me
[17:32] <dandrader> mterry, I do "~/unity8$ ./strip-tags.py power-button-on-lock"
[17:32] <mterry> dandrader, are we talking about the same thing?  You created a shared repository using "bzr init-repo" that you store all your u8 branches in?
[17:33] <dandrader> mterry, I've a unity8 dir from where I do "bzr branch lp:oo"
[17:33] <dandrader> mterry, so I have a trunk subdir  there with lp:unity8, a  power-button-on-lock with your branch, and so on
[17:33] <mterry> dandrader, right, that's a branch not a repo.  A repo is a directory which can share commit history between many branches that share history, to reduce storage space and run time
[17:34] <dandrader> mterry, oh, don't know about that stuff
[17:34] <mterry> dandrader, nor does the strip script  :)
[17:34] <mterry> dandrader, well, while I figure that out, I also stripped the remote branch again
[17:41] <mterry> dandrader, removed that id: too
[17:43] <dandrader> mterry, and not tags in tow this time :)
[17:43] <mterry> dandrader, I stripped again
[17:43] <mterry> dandrader, I don't know what's going on, I think I may just nuke all my checkouts and start fresh
[17:47] <dandrader> mterry, check the video in the comment I just added
[17:48] <mterry> dandrader, oh boy ok
[17:55] <mterry> dandrader, so I'm not convinced that's the regression
[17:55] <mterry> dandrader, on vivid normal, I can also interact with the background before the greeter appears
[17:56] <mterry> dandrader, I could buy that there is a timing difference
[17:56] <mterry> dandrader, like maybe it takes longer for greeter to come up with async mode?  (but I would naively expected the opposite)
[17:56] <dandrader> mterry, I did "ubuntu-device-flash touch  --channel devel-proposed" on both devices
[17:56] <mterry> dandrader, I just did that myself
[17:56] <dandrader> mterry, before buidling and installing your branch on the N4
[17:56] <mterry> dandrader, and I can interact with background if I quickly turn on screen again
[17:57] <dandrader> mterry, but ok, will try out the N4 without your branch
[17:59] <dandrader> mterry, that would be quite odd. why such a big difference between devices? there should be none...
[17:59] <mterry> dandrader, it's a performance thing, how quickly the greeter appears
=== alan_g is now known as alan_g|EOD
[18:33] <mterry> kgunn__, btw, I filed bug 1401213 to track the issue
[18:33] <ubot5> bug 1401213 in unity8 (Ubuntu) "Can't enter passphrase in unity8 wizard" [Undecided,New] https://launchpad.net/bugs/1401213
[18:34] <mterry> Do we have a good way to test the OSK in qmluitests?  Or do we need to do autopilot for that?
=== dpm is now known as dpm-afk
=== dpm-afk is now known as dpm
=== salem_ is now known as _salem