=== _salem is now known as salem_
=== salem_ is now known as _salem
[06:00] <MCR1> sil2100: Good morning :) Thanks for fixing Compiz yesterday - fixes are landing again 8-)
[06:00] <MCR1> sil2100: But Unity still is blocked ?
[06:01] <MCR1> duflu: Hi :) Have you seen: https://code.launchpad.net/~mc-return/compiz/compiz.merge-replace-defines/+merge/122865 ?
[06:02] <duflu> MCR1: Yes I know about it. Too busy to get to looking at it yet
[06:03] <MCR1> duflu: Ah, okay - but I hope the general direction of replacing #defines is okay for you too...
[06:09] <MCR1> duflu: I've read a survey that said that 9.7 out of 10 duflus like #defines being massaged to static constants of standard variable types ;)
[06:20] <Mirv> staging looks like fixed at least now, and unity also has rebuilt against compiz
[06:20] <Mirv> I re-pushed all the unity branches that got rejected to approved again, but indeed it does not look like they'd still be going forwards really
[06:21] <Mirv> or then it's just slow, also the compiz stuff took quite many hours to start merging, and I only pushed unity two hours ago
[06:23] <MCR1> Mirv: That are good news :) Hope it will soonish start to merge. Thx.
[06:26] <sil2100> MCR1: it's still blocked? Will have to check that later! Morning btw/
[06:27] <Mirv> sil2100: the merger isn't rejecting anything anymore regarding unity, so it maybe just slow (compiz was only fixed and built 3 hours ago)
[06:28] <Mirv> so now the next checks merger will do should be successful
[06:28] <MCR1> sil2100: I do not know exactly, because I do not see this info (it would be cool if that info could be added to the launchpad code review page), but Compiz merged, then stopped, while Unity was not merging anything...
[06:30] <MCR1> For a newbie like me this is exciting - will Jenkins do it this time or... :-D
[06:31] <Mirv> well it's exciting for everyone ;)
[06:31] <MCR1> hehe
[06:37] <sil2100> MCR1: can you point me to a recent merge that failed?
[06:39] <MCR1> sil2100: Not really, I think they just stopped... like on hold.
[06:39] <MCR1> sil2100: They are still in the "ready to land" queue...
[06:40] <sil2100> huh
[06:41] <MCR1> sil2100: 6 hours ago, 5 commits were merged into lp:compiz, the last commit merged into lp:unity was 19 hours ago...
[06:47] <Mirv> the unity couldn't have continued until the 5 commits committed to lp:compiz went in and also built, which happened 3h ago
[06:47] <Mirv> so I'm just wondering if it takes time for lp:unity to continue (no rejects so far)
[06:48] <MCR1> idk
[06:48] <Mirv> sil2100: do you think that's possible?
[06:53] <MCR1> sil2100: This lp:compiz merge failed 6 hours ago: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-URLs/+merge/122632
[06:55] <MCR1> sil2100: The Jenkins console says Finished: SUCCESS - but did not merge it then...
[06:56] <MCR1> sil2100: But unity-merger says that the same console report shows an error and refuses to merge, see: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-URLs/+merge/122632/comments/264474
[06:56] <MCR1> sil2100: Maybe that helps...
[07:01] <sil2100> MCR1: the merge you posted is one of those strange cases where the merger fails by success
[07:03] <MCR1> sil2100: yes
[07:05] <didrocks> sil2100: hey hey, you are around! :)
[07:08] <sil2100> didrocks: hi! Yes! Battling with some things right now
[07:08] <didrocks> sil2100: can I give you another request for today?
[07:11] <sil2100> didrocks: yes, please ;p
[07:14] <TheMuso> Hey folks. What is the likelyhood of getting bug 1023542 expedited? An at-spi2 package update is pending, and I can't update it until this bug/branch is merged upstream, so it can be cherry-picked into the quantal unity package...
[07:14] <ubot5> Launchpad bug 1023542 in unity (Ubuntu) "[a11y] Unity and unity-panel a11y initialization need to be ported to atk-bridge library" [Undecided,In progress] https://launchpad.net/bugs/1023542
[07:18] <didrocks> sil2100: so, did you read my email yesterday about branches without FFe?
[07:18] <didrocks> sil2100: the 2 bugs
[07:18] <didrocks> sil2100: can you poke the release team and watch closely about new features introduced without FFe acked
[07:18] <didrocks> sil2100: because right now trunk is unreleasable
[07:19] <didrocks> sil2100: my take 2 is that I saw Mirv's branches for compiz have been merged, did you finish your part for migration/default values and can we cherry-pick that and upload today?
[07:36] <sil2100> didrocks: will try!
[07:38] <didrocks> thanks
[07:38] <didrocks> keep me posted
[09:13] <didrocks> sil2100: you did notice that the merger still doesn't merge everything on unity?
=== mmrazik is now known as mmrazik|lunch
[09:25] <sil2100> didrocks: I see that it didn't even fail merging - it just doesn't merge unity
[09:25] <sil2100> didrocks: I'm trying to poke Martin about it
[09:26] <didrocks> sil2100: right, it's just someway stalled…
[09:26] <sil2100> didrocks: since I actually wanted to know if my yesterday's fix actually fixed all problems
[09:27] <didrocks> what was it btw?
[09:27] <didrocks> oh right
[09:27] <didrocks> the .pc file
=== mmrazik|lunch is now known as mmrazik
[11:03] <tsdgeos> how am i supposed to start "unity" properly?
[11:03] <tsdgeos> unity --replace doesn't seem to give me much
[11:04] <tsdgeos> i.e. i don't have a launcher, etc.
[11:09] <Mirv> tsdgeos: unity imples --replace, no need to specify it. some problem if launcher isn't shown, maybe pastebin output of unity --debug..
[11:11] <sil2100> tsdgeos: if the launcher and panel are not visible it means that the unityshell plugin is not loaded probably
[11:12] <tsdgeos> hmmm
[11:12] <tsdgeos> maybe i broke something while compiling
[11:12] <tsdgeos> let me recompile
[11:13] <tsdgeos> Mirv: http://paste.ubuntu.com/1188757/ not much besides the complaint about the panel service
[11:14] <Mirv> tsdgeos: 12.10 or 12.04? hmm, maybe the --debug wasn't a good idea, try also without
[11:15] <Mirv> tsdgeos: without I get something like this (start of output): http://pastebin.ubuntu.com/1188760/
[11:15] <Mirv> on 12.10
[11:15] <Mirv> so you should see Backend/Integration/Profile at least
[11:15] <Mirv> Profile shoud be unity, Backend should be gconf (on 12.04) or gsettings (on 12.10)
[11:16] <tsdgeos> Mirv: 12.10
[11:16] <Mirv> with --debug I don't get Unity running, funnily..
[11:16] <Mirv> (ok, now it ran with --debug as well)
[11:16] <tsdgeos> interesting
[11:17] <tsdgeos> yep without debug works
[11:17] <tsdgeos> tx :D
[11:17] <Mirv> hmm :D
=== MacSlow is now known as MacSlow|lunch
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[14:48] <tsdgeos> Mirv: any hints on compiling compiz from lp:compiz sources? if i do the typical, cmake, make, make install i end up with unity not being loaded, seems like it does use ini backend instead of gsettings and everything goes downhill from there
[14:49] <sil2100> That's why I'm always using packaging for testing lp:compiz
[14:50] <tsdgeos> right
[14:50] <tsdgeos> but i want to develop
[14:50] <tsdgeos> so i need to compile stuff
[14:50] <tsdgeos> and compile the packages all the time
[14:50] <tsdgeos> is a bit of a pain
[14:50] <tsdgeos> being doing that
[14:51] <tsdgeos> but each time i want to change a line have to wait like 5 imnutes to get the deb files recompiled
[14:51] <tsdgeos> does note scale much
[14:52] <sil2100> hm, it's been a while since I last used lp:compiz directly for testing, so I'm not sure if I can help you here - in the past it was easy, just the 3 steps as already mentioned
[14:58] <dandrader> tsdgeos, you will probably have to compile lp:unity and lp:nux as well. Just to make sure you're everything in sync
[14:59] <dandrader> tsdgeos, check this http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source
[14:59] <tgm4883> Is it possible to open a unity preview from inside another unity preview (nested previews?). I've been testing, but it just seems to close the preview whenever I click a button in a preview rather than just go to another preview
[15:00] <MCR1> tsdgeos: https://answers.launchpad.net/compiz/+question/203490
[15:01] <tsdgeos> dandrader: MCR1: tx, will have a look
[15:04] <MCR1> tsdgeos: Your help is appreciated, there is enough to do ;)
[15:06] <tsdgeos> well, let me get stuff compiling first :D
[15:08] <MCR1> tsdgeos: A trick I use often if it is just a plug-in I am fixing: simply copy the 2 files (nameoftheplugin.xml file in build/generated and the .so file from build/plugins/nameoftheplugin/nameoftheplugin.so to the respective .compiz-1 directories in ~)
[15:09] <MCR1> tsdgeos: After compiling lp:compiz ofc
[15:09] <tsdgeos> yep
[15:09] <tsdgeos> actually compiling and overwriting a plugin worked
[15:09] <tsdgeos> it's just the main thing that somehow doesn't want to work
[15:09] <MCR1> :)
[15:10] <MCR1> duflus solution *should* work
[15:11] <tsdgeos> back in a sec
[15:11] <tsdgeos> my window manager setup kind of broke, need to logoff and fix some stuff
[15:13] <sil2100> didrocks: small report (sorry that so late)
[15:13] <didrocks> sil2100: I was just about to ping you!
[15:13] <didrocks> :)
[15:13]  * MCR1 is listening interested also :)
[15:14] <sil2100> didrocks: I pushed the migration branch (took so long since we were checking some other things in the meantime, like the merges and SRUs) - will request a merge soon for comment
[15:14] <sil2100> didrocks: regarding the two FFe's
[15:15] <sil2100> didrocks: the gtk decorator has been ACKed, but the XIM nux one needs discussion still
[15:15] <didrocks> sil2100: bug #1042323
[15:15] <sil2100> didrocks: I have been asked by Daviey to discuss it on #ubuntu-desktop
[15:15] <ubot5> Launchpad bug 1042323 in Compiz "[FFE] Port GTK Window Decorator to GSettings" [High,Confirmed] https://launchpad.net/bugs/1042323
[15:15] <didrocks> I don't see a ack?
[15:15] <didrocks> sil2100: yeah, we discussed about it a couple of hours ago
[15:15] <didrocks> with Daviey
[15:16] <sil2100> didrocks: it'll get formally ACKed in a moment
[15:16] <didrocks> sweet :)
[15:16] <didrocks> sil2100: can you make sam aware once done?
[15:17] <didrocks> sil2100: they, we can pack this up with the migrations part
[15:17] <sil2100> didrocks: regarding the XIM branch... well, I would *personally* like to have it, since this way we'll have time to test such things till 13.04
[15:17] <didrocks> and release a package tomorrow
[15:17] <sil2100> didrocks: ACK
[15:17] <sil2100> ;)
[15:17] <didrocks> sil2100: 12.10 is not a test bed for 13.04 :)
[15:17] <didrocks> bet*
[15:17] <sil2100> I know, but it still would open up Nux for many many input methods
[15:18] <sil2100> Right now we only have the standard IM and ibus, which might be a bit problematic
[15:18] <didrocks> right, but now that the FF target is done, I want to know what the test coverage is and how this can impact existing code
[15:18] <sil2100> didrocks: right, we'll need bschaefer to get online for that
[15:18] <didrocks> sil2100: well, it wasn't problematic enough to ship only ibus support in 11.04, 11.10, 12.04
[15:19] <didrocks> so, what changes?
[15:21] <sil2100> Sure, it's not a regression, but it doesn't mean it was supposed to be like this always, since this is not intended behavior, right?
[15:21] <didrocks> depends on who you ask :)
[15:21] <sil2100> It's maybe not *necessary*, ok
[15:21] <didrocks> GNOME is going to support only ibus
[15:21] <sil2100> Ouch
[15:21] <sil2100> I wouldn't like that
[15:21] <sil2100> Really
[15:22] <didrocks> so I'm just wondering what the benefit/risk to just wait for enabling that for 13.04 and not 12.10
[15:22] <didrocks> if the benefit is greater than the risk, fine
[15:22] <didrocks> otherwise we should reconsider :)
[15:22] <sil2100> True true, hm hm
[15:23] <sil2100> THe diff is big, I would also like to ask some questions related to this branch
[15:23] <didrocks> yeah, better to check beforehand
[15:23] <didrocks> giving all assets to the release team
[15:23] <didrocks> so that they can decide
[15:29] <MCR1> sil2100: Are you aware that ~1h ago r2658 in Unity was merged, but now merges seem to have stopped again ?
=== dandrader is now known as dandrader|afk
[15:50] <sil2100> MCR1: ah, patience please ;)
[15:50] <sil2100> MCR1: but it should be alright now
[15:51] <MCR1> sil2100: :-[
[15:51] <bschaefer> MCR1, im awake now!
[15:51] <MCR1> Yeaj
[15:53] <MCR1> bschaefer: If you are bored: https://code.launchpad.net/~mc-return/unity/unity.merge-remove-unused-variables/+merge/122940 ;)
[15:54] <bschaefer> MCR1, im never bored :), Ill take a look at that later (I have some other review's to fix atm )
[15:54] <bschaefer> MCR1, thanks though!
[15:55] <bschaefer> MCR1, actually it is really small...
[15:55] <MCR1> bschaefer: hehe
[15:55] <bschaefer> 26	- CompWindow* w, *oldPrev, *oldNext;
[15:55] <bschaefer> 27	+ CompWindow* w;
[15:55] <bschaefer> what happened to old?
[15:55] <bschaefer> and Prev and Next? unused?
[15:56] <MCR1> they just got assigned NULL, but were not used
[15:56] <MCR1> to my understanding
[16:05] <bschaefer> MCR1, cool, let me just look through that really quick :)
[16:05]  * MCR1 is recompiling to make sure also (40%)...
=== dandrader|afk is now known as dandrader
[16:09] <didrocks> sil2100: https://bugs.launchpad.net/unity/+bug/761155 needs a FFe
[16:09] <ubot5> Ubuntu bug 761155 in unity-2d (Ubuntu) "[launcher] All launcher icons should be moveable except trash and BFB" [Medium,Triaged]
[16:09] <didrocks> and it's also landed into trunk :/
[16:09] <didrocks> sil2100: can you have a review from Daviey/the release team please?
[16:10] <didrocks> sil2100: this is between a bug fix and a feature btw (as it's part 2 of the work landing)
[16:10] <didrocks> but the change is large
[16:14] <sil2100> didrocks: will take care of that too!
[16:14] <sil2100> didrocks: and the XIM issue
[16:14] <didrocks> thanks!
[16:15] <didrocks> and keep watching the merger please, to ensure you spot them and go to people :)
[17:00] <mhall119> mhr3: hey, would it make sense to pre-fetch the next screenshot when doing previews?  Waiting for images to load makes it feel slow
[17:01] <mhall119> or does it already do that, and I'm just flipping through too fast
[17:01] <mhr3> mhall119, no, and not gonna happen for 12.10 sorry
[17:02] <mhall119> that's fine, it's still an awesome feature
[17:05] <mhr3> mhall119, which lens is this slow for you though?
[17:05] <mhall119> mhr3: applications
[17:05] <mhr3> ah, right grabs images from web
[17:06] <mhr3> mhall119, but i'm pretty sure people on mobile connections are happier went it doesn't do any pre-fetching
[17:07] <mhall119> I'd think just +1 wouldn't be that big of a deal
[17:07] <mhall119> you'd never load more than one more than you wanted
[17:08] <mhall119> mhr3: on a side note, what's a good python example of using the previews api?
[17:11] <mhr3> lp:unity-lens-sample
[17:12] <didrocks> mhr3: didn't you eod a while ago? (just checking ;))
[17:13] <mhr3> didrocks, i did, but actually i'm just putting shoes on and am out
[17:14] <didrocks> ah, it's not mhr3bot then :)
[17:14] <didrocks> mhr3: run run :)
[17:15] <mhall119> thanks mhr3
[17:15] <mhr3> didrocks, why do you think my bots can't run? ;)
[17:16] <mhr3> didrocks, they're very advanced
[17:16] <mhr3> but really /me out
[17:16] <didrocks> mhr3: I don't doubt about it!
[17:16] <didrocks> mhr3: good night :)
[17:18] <sil2100> didrocks: will you find time for unity SRU precise branch analysis? ;)
[17:19] <didrocks> sil2100: not tonight TBH, but bring them on, I can have a look tomorrow morning
[17:21] <sil2100> didrocks: ok, as long as we'll be able to release unity tomorrow, I'm fine with that ;)
[17:21] <didrocks> well, it will be in -proposed
[17:22] <didrocks> then, someone has to accept it there
[17:33] <sil2100> didrocks: for now I need someone to upload branches to lp:ubuntu/unity and nux
[17:34] <sil2100> didrocks: since we're blocked on those
[17:34] <didrocks> what is blocked? new build-dep?
[17:34] <sil2100> didrocks: https://code.launchpad.net/~fginther/nux/precise-libgeis-rename-patch <- nux
[17:34] <sil2100> THe geis rename
[17:35] <sil2100> https://code.launchpad.net/~sil2100/unity/precise-geis-rename <- unity
[17:35] <didrocks> this is for precise
[17:35] <sil2100> didrocks: since we need some modifications in trunk too, but we need packaging changes first
[17:35] <sil2100> Yes
[17:35] <didrocks> how come you want that to lp:ubuntu/unity and lp:ubuntu/nux
[17:35] <sil2100> Preparations for Unity SRU
[17:35] <sil2100> Aaaah, sorry!
[17:35] <didrocks> which are for quantal?
[17:35] <sil2100> ;)
[17:35] <sil2100> ~ubuntu-desktop/unity/precise I meant, eh
[17:36] <didrocks> why debian/patches/02_libgeis_rename.patch?
[17:36] <didrocks> and nothing in unity?
[17:36] <didrocks> there is no utouch-* ref in unity?
[17:37] <didrocks> in that case, we shouldn't build-dep on it, right?
[17:37] <sil2100> didrocks: no no, let me explain
[17:37] <sil2100> didrocks: there is, but all those changes are made in trunk
[17:37] <sil2100> didrocks: upstream
[17:37] <sil2100> didrocks: the nux patch is necessary because nux build system is broken
[17:37] <didrocks> broken?
[17:38] <sil2100> didrocks: yes - it includes 'configure' in the tarball, and doesn't generate a new one from configure.am automatically it seems
[17:38] <didrocks> well, that's normal
[17:38] <didrocks> you mean, there is no autoreconf, right?
[17:38] <sil2100> I think so
[17:39] <didrocks> sil2100: I want first to see the code in nux upstream trunk
[17:39] <didrocks> and rerolling a tarball
[17:39] <didrocks> I think it worthes it
[17:41] <sil2100> didrocks: to get it merged in, we need to change the build-deps change
[17:41] <sil2100> One moment, I'll give you the MRQs
[17:42] <sil2100> https://code.launchpad.net/~fginther/unity/unity-5.0-libgeis-rename
[17:42] <sil2100> I mean:
[17:42] <sil2100> https://code.launchpad.net/~fginther/unity/unity-5.0-libgeis-rename/+merge/121654
[17:42] <sil2100> https://code.launchpad.net/~fginther/nux/nux-2.0-libgeis-rename/+merge/121653
[17:43] <sil2100> TO anyone interested: https://code.launchpad.net/~sil2100/unity/keybindings-migrations/+merge/123117
[17:43] <didrocks> argh seb128 had a lock
[17:43] <didrocks> on the bzr repo
[17:43] <didrocks> let me break it
[17:45] <didrocks> sil2100: unity branch: it diverged from lp:~ubuntu-desktop/unity/ubuntu
[17:46] <sil2100> You mean, lp:~ubuntu-desktop/unity/precise I think ?
[17:51] <sil2100> See you tomorrow everyone
=== dandrader is now known as dandrader|lunch
=== yofel_ is now known as yofel
=== dandrader|lunch is now known as dandrader
[20:02] <Oranger> Hello, sorry to kill this silent but I want to know if it's possible to compile the 6.0 branch of Unity into precise ?
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader_ is now known as dandrader
[23:42] <MCR1> bschaefer: Are you still here ?
[23:43] <bschaefer> MCR1, yup
[23:43] <MCR1> Do you remember my launcher hiding although the mouse was over the launcher problem ?
[23:44] <MCR1> The one I posted the video about...
[23:44] <MCR1> The one you could not reproduce...
[23:44] <bschaefer> MCR1, yeah
[23:44] <bschaefer> do you know how to reproduce it?
[23:45] <MCR1> No, but to my understanding the code says that it should hide if the mouse is not moved after reveal...
[23:45] <MCR1> which is wrong
[23:46] <MCR1> I do not know of any case where the launcher should hide although the pointer hivers over it...
[23:46] <bschaefer> MCR1, if the mouse is over the launcher at all it should never hide (If set to autohide)
[23:46] <bschaefer> until the mouse is moved away
[23:46] <MCR1> bschaefer: Please look at LauncherHideMachine.cpp line 150+
[23:47]  * bschaefer takes a look
[23:47] <MCR1> thx
[23:47] <MCR1> to my understanding it forces the user to move the mouse after reveal to keep the launcher open
[23:48] <MCR1> which is also what the comment says
[23:48] <MCR1> and which I experienced quite often in several installations, but noone could reproduce it and it would not happen in a guest session...
[23:48] <bschaefer> MCR1, well comments are not always write. The code is always right. It looks like it gets set on line 58
[23:49] <MCR1> the code does the same like the comment, no ?
[23:49] <bschaefer> well it looks like it sets that Quirk to true when the launcher is revealed...
[23:49] <bschaefer> from pressure
[23:50] <bschaefer> but then I have to see where MOUSE_OVER_LAUNCHER is set
[23:51] <bschaefer> MCR1, which gets set in the Launcher...which gets set when the mouse is inside the launcher
[23:52] <bschaefer> MCR1, when a mouse_enter is emited, which should happened when the pressure is large enough to reveal the launcher
[23:52] <bschaefer> MCR1, and this it is set to false when mouse_leave is emited
[23:52] <bschaefer> which would cause the launcher to hide
[23:53] <bschaefer> so it should know that the mouse is over the launcher when it activates the launcher with pressure....and the mouse_enter signal gets emited
[23:53] <bschaefer> the bug could be that Nux doesn't emit the mouse_enter when the launcher opens up...but I can't get it to do that
[23:54] <bschaefer> though I could be missing something :) (I haven't really devoured that part of the code yet )
[23:56] <MCR1> to me it says: if the launcher is hidden show it if visibility is required or the mouse revealed it (REVEAL_PRESSURE_PASS) else (if it is already revealed) check  (MOUSE_MOVE_POST_REVEAL) then show it when _should_show_quirk is true or the mouse is over the launcher...
[23:57] <MCR1> the check for (MOUSE_MOVE_POST_REVEAL) should be completely removed
[23:58] <bschaefer> MCR1, well te best way to check is to add print statments in :)
[23:58] <bschaefer> comment it out and see what happens
[23:58] <MCR1> MOUSE_OVER_LAUNCHER check should be enough to determine this
[23:59] <MCR1> well, I could not test the code at the moment...
[23:59] <bschaefer> hmm