[05:47] <zsombi> hai world
[08:18] <zsombi> mzanetti: ping, I saw you were looking after me
[08:24] <zsombi> mzanetti: the promised FocusShape code http://pastebin.ubuntu.com/23769222/
[09:35] <zbenjamin> zsombi: could it be you forgot my PR with the source tree reorg? :)
[09:42] <zbenjamin> bzoltan_: any idea about daker's problem? https://paste.ubuntu.com/23753990/
[09:43] <zbenjamin> daker: seems the lxd bridge tries to use a existing subnet
[09:44] <zbenjamin> daker: is that something you have in your network? 10.0.2.1
[09:44] <zbenjamin> daker: looks like a lxd bug maybe
[09:54] <zbenjamin> daker: what you can try is to change all occurences of 10.0.2.x in /etc/default/lxd-bridge into a subnet not used in your network, then try to restart the upgrade
[12:13] <kalikiana> zsombi: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bugs?field.tag=unity8
[12:13] <zsombi> kalikiana: thx!!
[12:29] <zsombi> mzanetti: ping bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1647415
[12:29] <zsombi> mzanetti: from teh bug it is not clear whether the GU change signal causes the behavior
[12:29] <mzanetti> ?
[12:30] <mzanetti> what behavior?
[12:30] <zsombi> mzanetti: isn't the onBlaChanged emitted because it gets a value different from 0 (default) ?
[12:30] <mzanetti> zsombi, wouldn't "onBlubbChanged" be called too in that case?
[12:31] <zsombi> mzanetti: well, that is a value binding, may behave differently
[12:32] <zsombi> beside, units is a context property, it doesn't know anything about the Item's completion, so it'll emit a signal whenever it detects a GU change
[12:33] <zsombi> mzanetti: and in that case, if units is changed, the change signal will cause the bla property change to happen even if the component si not completed yet
[12:34] <mzanetti> zsombi, but is there a gu change?
[12:34] <mzanetti> I mean... I do "property int bla: units.gu(10)"
[12:34] <mzanetti> this should never change
[12:34] <zsombi> mzanetti: there is
[12:35] <zsombi> mzanetti: are you sure? what if the GU value changes?
[12:35] <mzanetti> does it?
[12:35] <mzanetti> I mean, sure, with DGU, it can change
[12:35] <zsombi> mzanetti: and in teh first launch, that GU value changes almost everywhere
[12:35] <mzanetti> but not in my setup
[12:35] <mzanetti> yes, exactly, that's the problem
[12:35] <kalikiana> the gu is set/initialized before completion, ergo it "changes" as before it would be 0
[12:35] <zsombi> mzanetti: on desktop, GU might be 8 pixels, but on phone is more, so how would you know when to really change and when not?
[12:35] <mzanetti> it should read GRID_UNIT_PX at very first, then initialize all the things with that, and unless DGU changes the env var, there should be no changed signal
[12:35] <daker> zbenjamin: no, i think it was created by lxd
[12:36] <kalikiana> mzanetti: ie. I don't think it can be set when the binding is set up
[12:36] <mzanetti> hmmm
[12:36] <mzanetti> I see what you mean...
[12:36] <mzanetti> still think we need to solve it somehow
[12:37] <kalikiana> so 1) binding evaluated 2) units initialized 3) completed
[12:37] <mzanetti> yeah, 1 and 2 would need to be swapped
[12:38] <zsombi> I can try that out...
[12:38] <kalikiana> mzanetti: it might sorted with the MainWindow since that can initialize the gu "immediately"
[12:38] <kalikiana> but gu needs a window
[12:38] <zsombi> kalikiana: I could try to initialize the GU at the plugin loading time...
[12:38] <mzanetti> I don't think we can use MainWindow in the shell... maybe we can... dunno. so far we don't use any Window thing
[12:38] <zsombi> oh, yes, I keep forgetting teh multi-window...
[12:39] <kalikiana> zsombi: then it will change once there's a window which may have a different gu
[12:39] <kalikiana> so that can only work some of the times
[12:39] <zsombi> kalikiana: yes, realized that
[12:39] <kalikiana> mzanetti: What does Unity render on? The window is the owner of the scaling property ultimately
[12:40] <kalikiana> For apps anyway
[12:40] <mzanetti> we set up a scenegraph on Mir
[12:41] <zsombi> well, that would be solved by initing GU on plg load... never the less each Window would have a separate initialization...
[12:41] <kalikiana> mzanetti: Perhaps we need to consider a non-Window type that has a gu property? Essentially we need an Item to get rid of the context property
[12:41] <mzanetti> ah no... actually we use a QQuickWindow
[12:41] <kalikiana> Ah
[12:42] <mzanetti> although we hijack things in there quite a bit
[12:42] <zsombi> mzanetti: so you could then use the MainWindow... once we get it released...
[12:42] <mzanetti> probably...
[12:43] <kalikiana> mzanetti: The MainWindow is intended to be minimal, ie. no header/APL in there - what else do you use/need from the window?
[12:44] <mzanetti> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/src/ShellApplication.cpp
[12:44] <kalikiana> mzanetti: Right now it's got an action context, applicationName and units
[12:44] <mzanetti> the ShellView is a QQuickView
[12:45] <mzanetti> which in itself is a QQuickWindow
[12:45] <mzanetti> so... those things done in ShellApplication is what we need
[12:45] <mzanetti> and then, with multimonitor it might become a bit more
[12:47] <zsombi> well, MainWindow is basically a QQuickWindow with units and i18n exposed as properties, to ditch the global context property...
[12:47] <zsombi> so you could use that instead of QQuickWindow
[12:47] <kalikiana> mzanetti: multimonitor for...? you're doing some initialization bits there that are normally in the launcher, like the testability - but the i18n and applicationName are also done in MainWindow
[12:48] <mzanetti> kalikiana, yeah well, this is the shell... this is the compositor
[12:48] <kalikiana> what it doesn't have is the organizationName, we could add that, or you just keep that as-is
[12:49] <kalikiana> with click we never set it because it broke confinement
[12:49] <daker> zbenjamin: is this a bug in lxd https://paste.ubuntu.com/23770161/ ?
[13:41] <zbenjamin> daker: try dpkg -l | grep -i lxd to see if you still have lxd related packages installed
[13:50] <daker> zbenjamin: ah yes lxd-client
[13:50] <daker> should i remove it ?
[13:51] <zbenjamin> daker: hmm, the client should be unrelated to that... could you check if there is still a lxdbr0 device?
[13:52] <daker> zbenjamin: no it was removed after the purge i think
[13:52] <zbenjamin> daker: then try the update again
[13:53] <daker> zbenjamin: i will run the apt-get install ubuntu-sdk again
[14:02] <daker> zbenjamin: no luck :( https://paste.ubuntu.com/23770421/
[14:03] <daker> $ ifconfig | grep "wlan0"
[14:03] <daker> wlan0     Link encap:Ethernet  HWaddr cc:52:af:5e:4c:7e
[14:04] <daker> i am not using wlan0 to connect to internet
[14:06] <zbenjamin> daker: seems somehow your network setup is broken ...
[14:08] <zbenjamin> daker: remove the /etc/default/lxd-bridge file and try again
[14:08] <zbenjamin> daker: move it to something like /etc/default/lxd-bridge.backup
[14:08] <zbenjamin> sorry need to run, i have a appointment soon :(
[14:10] <daker> zbenjamin: no problem, i'll try again