[08:34] <MCR1> sil2100: Hi :) I've fixed another Compiz Grid bug, this MP needs approval: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1139835-grid-wrong-top-left-corner-calculation/+merge/151358
[08:34] <sil2100> MCR1: checking in a moment!
[08:36] <MCR1> sil2100: Thanks. It was calculating the top left corner wrongly. So with 2 monitors the top-left corner detection and mouse-gridding the window into top left with the mouse will not work on monitor 2. This MP fixes that.
[08:38] <MCR1> didrocks: Hi. Unmaximize_or_restore_window is working per default as intended on Raring daily ISO. I do not know what you tested on your system, that it did not work 4 you...
[08:39] <MCR1> *Unmaximize_or_minimize
[08:39] <MCR1> *sry
[08:40] <MCR1> unmaximize is a bad name choice anyway <- it should be restore and work for all size manipulated windows... like the gridded ones as well...
[08:43] <didrocks> MCR1: hey! FYI, we froze compiz after talking to Sam, duflu and other. Meaning than lp:compiz is the pure upstream, and we only pick "safe changes" on lp:compiz/raring
[08:43] <didrocks> MCR1: but on the unmaximize thing, did you try to install quantal and then upgrade?
[08:44] <MCR1> didrocks: ahem, no.
[08:44] <didrocks> that's one of the main use case :)
[08:44] <MCR1> ok, I'll look into that also...
[08:44] <didrocks> thanks
[08:45] <MCR1> didrocks: Maybe that is a good choice, the freeze - I do not know. But it is kind of sad to see 0 Canonical maintainers for such a important thing like Compiz :(
[08:46] <didrocks> MCR1: well, that's the consequence, we can't maintain it anymore, so we don't want to take risks
[08:46] <MCR1> didrocks: Do you plan to drop Compiz in the near future ?
[08:47] <didrocks> MCR1: I don't know of any precise plan. More something to ask to the PS team
[10:09] <Trevinho> didrocks/seb128: are we going to merge this https://code.launchpad.net/~jbicha/nautilus/nautilus-3.7.90/+merge/149617 ?
[10:09] <didrocks> I guess that part is for seb128 :)
[10:09] <Trevinho> ok
[10:10] <Trevinho> seb128: since I need to push to nautilus other patches that I just pushed upstream...
[10:10] <Trevinho> seb128: so, I'd like to know if I should do over 3.6 or 3.7 (which seems to work pretty well here, though)
[10:11] <seb128> Trevinho, not before 3.8 is out
[10:11] <seb128> e.g not before a few weeks
[10:12] <Trevinho> seb128: mh, the fact is that I need to do some work in unity that is depending on them, so I'd like to have new nautilus released before unity...
[10:14] <Trevinho> seb128: so is it better if I backport the patches to 3.6 waiting for 3.8?
[10:15] <seb128> Trevinho, shrugh, how much works is it to backport those and when do you want to land the unity changes?
[10:16] <Trevinho> seb128: it shouldn't be too much work... I've worked mostly upstream, but it should be quite straight forward to get them for 3.6... Unity changes are under work still, but I think I can finish them in this week
[10:16] <seb128> Trevinho, wait a few days, I need to look more at nautilus 3.8 before telling you when we will update
[10:16] <Trevinho> seb128: ok, that's fine
[10:16] <seb128> Trevinho, we have UDS this week and the rolling release discussion and a zillion thing, priority is not to land GNOME 3.8 beta in
[10:17] <Trevinho> seb128: yeah, I know
[10:17] <seb128> Trevinho, I need to have a look if nautilus implies other updates
[10:17] <didrocks> is there any matter of urgency? Can't we just wait for nautilus 3.8 to get out and you can move to something else meanwhile?
[10:17] <seb128> like GTK 3.8 which is not in yes
[10:18] <Trevinho> seb128: I asked only because I didn't know which branch I should use to work on...
[10:18] <seb128> Trevinho, just do your unity work and assume we will get what you need from nautilus in the archive
[10:18] <Trevinho> didrocks: well... not urgency, but I don't like keeping things staging for long time before merging (due to upcoming conflicts and such)
[10:18] <Trevinho> seb128: ok cool
[10:19] <Trevinho> didrocks: the dependency is on dbus side, btw...t hat's why they need each others
[10:19] <didrocks> Trevinho: anyway, you will need to still "work (== not regressing)" even if the user didn't upgrade to latest nautilus
[10:19] <didrocks> so you don't block on the nautilus side :)
[10:19] <Trevinho> didrocks: yes, there won't be a problem on that side...
[10:20] <didrocks> so you're not blocked :)
[10:20] <Trevinho> didrocks: the user would just lose a feature
[13:53] <mterry> sil2100, nvidia-autopilot is jumping from 18 failing tests to 10 back up to 20.  Is it more susceptible to race conditions than ati/intel?
[13:53] <mterry> (ati and intel have stayed relatively static at around 10 to 13)
[13:56] <didrocks> hey mterry, is libcolumbus in main now?
[13:56] <sil2100> mterry: strange, hm
[13:57] <didrocks> mterry: also, are sil2100's AP tests enabled and running on both indicators and unity stacks? (I asked cyphermox about it)
[13:58] <mterry> didrocks, not promoted yet, but it's MIR is approved and things in main depend on it.  So it's just a matter of time
[13:58] <didrocks> mterry: great! and about the tests?
[13:59] <mterry> didrocks, what do you mean by "sil2100's AP tests"?  I mean, as opposed to other AP tests
[13:59] <mterry> We are running the AP tests, of course...
[13:59] <didrocks> mterry: he wrote some tests for the fuzzy matching, but there were disabled as long as libcolumbus didn't land
[14:00] <didrocks> mterry: so I asked cyphermox IIRC to check about those to be enabled back, and also, to add to the "test list" we have for indicators
[14:00] <mterry> didrocks, I thought those tests had went through, since we approved libcolumbus
[14:00] <sil2100> I don't think those got enabled
[14:00] <mterry> i.e. I hadn't thought they had been disabled.  Guess I missed that
[14:00] <sil2100> Let me check
[14:06] <didrocks> sil2100: keep us posted :)
[14:17] <sil2100> didrocks: they're still disabled, but I'll compose a merge request in a moment
[14:17] <sil2100> I just need to finish up something first
[14:18] <didrocks> sil2100: thanks, do they depend on the HUD thing to be merged? or just u-l-a?
[14:53] <seb128> mterry, hey, where is update-manager getting its app icons from?
[14:53] <seb128> mterry, it's showing a "missing icon" icon for the video lens update here
[14:54] <mterry> seb128, hrm.  It gets it from the desktop file I believe
[14:54] <seb128> mterry, do we have some of thoses for lenses?
[14:54] <mterry> seb128, let me double confirm that, and can you see if your desktop file points at a real icon
[14:55] <seb128> mterry, no .desktop in the lens binary
[14:56] <mterry> seb128, it gets it from /usr/share/app-install/desktop
[14:56] <mterry> seb128, it searches the .desktop files in there and uses its icon
[14:56] <seb128> Icon=unity-lens-video
[14:57] <seb128> app-install-data: /usr/share/app-install/icons/unity-lens-video.png
[14:57] <seb128> mterry, is update-manager looking in that dir for icons?
[14:57] <mterry> seb128, just noticing that myself.  It seems not
[14:57] <mterry> that's a bug
[14:57] <seb128> mterry, opening it
[14:57] <seb128> mterry, thanks
[15:19] <sil2100> didrocks: for now just in the u-l-a, since HUD has a rather sufficient fuzzy searching functionality built-in
[15:20] <sil2100> didrocks: so the fuzzy parts of HUD were already enabled
[15:31] <cyphermox> mterry: perhaps we should revert the app lens merge that brings in libcolumbus
[15:32] <cyphermox> mterry: thoughts?
[15:32] <mterry> cyphermox, why?
[15:32] <cyphermox> (Satoris isn't ready with the hud libcolumbus pieces, it's having issues)
[15:32] <mterry> cyphermox, are the two connected?
[15:32] <sil2100> Problems with libcolumbus?
[15:33] <sil2100> Since if u-l-a stays libcolumbus-using, https://code.launchpad.net/~sil2100/unity/autopilot_enable_fuzzy_u_l_a/+merge/151533 can get merged in I think
[15:33] <cyphermox> argh
[15:34] <cyphermox> yeah, I guess it's probably fine
[15:37] <cyphermox> mterry: ignore me, I'm being confused by lack of context.
[15:37] <cyphermox> and passing on that lack on context....
[16:01] <jjed> I asked this on Friday, but at the risk of annoying, I'll try again. Is there any chance lp:unity will be abandoned or radically refactored in the near future?
[16:01] <bregma> jjed, there's no chance it will be abandoned:  Canonical has committed to support 12.04 for a good many years yet
[16:02] <mterry> jjed, there is lp:unity/phablet where all the cool new phablet work is being done though
[16:02] <bregma> and we're certainly not planning any refactoring, radical or not, in the near future
[16:05] <jjed> bregma, mterry: Thanks, smspillaz recently implied (with understandable irritation) that Canonical would be basically dropping the Nux version in favor of the phablet implementation
[16:05] <jjed> I wouldn't want to waste time on that branch were that the case
[16:09] <mterry> jjed, I don't know what the plans are there
[16:09] <jjed> ...........
[16:09] <mterry> But as bregma said, Nux unity is sticking around until at least 2017
[16:09] <mterry> even if Canonical did switch to phablet today
[16:09]  * bregma thinks 2017 sounds so far away
[16:51] <didrocks> mhr3: https://code.launchpad.net/~didrocks/unity/generate-recommends-from-default-scope/+merge/151170 do you mind for the globale approve? we have the libunity in already
[16:51] <mhr3> wasn't sure what the processes on unity merges these days, don't at least two people have to ack it?
[16:52] <didrocks> mhr3: hum, not that I know of
[16:53] <didrocks> mhr3: and not what I'm seeing :)
[16:53] <mhr3> ok, approved
[16:53] <didrocks> thanks mhr3
[16:53] <didrocks> sil2100: please got https://code.launchpad.net/~sil2100/unity/autopilot_enable_fuzzy_u_l_a/+merge/151533 merged now that the feature is in :)
[17:10] <sil2100> didrocks: aye!
[17:29] <sil2100> didrocks: reviewed and approved by fginther \o/
[17:33] <didrocks> \o/
[17:33] <didrocks> thanks sil2100
[17:33] <didrocks> sil2100: tomorrow, I'll add it to the indicator tests we cherry-pick
[17:33] <didrocks> cyphermox: FYI ^
[17:35] <cyphermox> ack
[17:35] <cyphermox> brb
[17:36] <sil2100> Ok, let's see how well it works ;)
[17:41] <didrocks> kenvandine: robru: cyphermox: in case you didn't notice, our session tomorrow is at 6:15 UTC. I put it as one of the last one to have robru waken up enough :)
[17:41] <robru> didrocks, aha, thank you
[17:42] <robru> didrocks, where's the schedule?
[17:43] <didrocks> robru: yw ;) http://summit.ubuntu.com/uds-1303/2013-03-05/display
[17:44] <kenvandine> cool
[17:45] <robru> wow, that's an action packed day... not sure how I'll choose which to attend ;-)
[17:54] <mterry> jjed, https://wiki.ubuntu.com/MirSpec seems relevant
[17:54] <mterry> Or rather wiki.ubuntu.com/UnityNextSpec
[18:04] <jjed> > April 2014: Target of reaching full convergence! Unity Next QML on Mir for on all platforms...phone, tablet, pc, tv
[18:04] <jjed> Wow, that's heavy stuff. With
[18:24] <robru> mterry, strange, the wiki is giving me 503s