[04:16] <johann_> Someone can tell me how to get the source code of unity
[07:18] <MCR1> sil2100: Hi :)
[07:19] <MCR1> sil2100: Are there problems with Unity landings or why is it jamming ?
[07:21] <MCR1> sil2100: Could you also approve this branch ? : https://code.launchpad.net/~brandontschaefer/unity/improve-keyboard-shortcut-overlay-wording/+merge/119071
[07:21] <sil2100> MCR1: unity is still in freeze, I hope to unfreeze it today
[07:22] <sil2100> Starting next week we'll try to use a different release approach
[07:22] <sil2100> So it won't be a problem hopefull
[07:22] <sil2100> *hopefully
[07:23] <MCR1> sil2100: It would be important to have this ^^ in trunk, so I could start working on the elimination of the hardcoded shortcuts that would probably also touch the same code...
[07:23] <didrocks> sil2100: we will probably need a compiz snapshot next Monday/Tuesday FYI once the gsettings g-c-c part is landed FYI
[07:23] <didrocks> (just to keep you up to date)
[07:24] <didrocks> sil2100: there will be a need of two cherry-picks in the unity codebase
[07:28] <MCR1> didrocks: Hi :) My plan is to convert all hardcoded Unity keys to Compiz keys and integrate those that are currently hardcoded to the Unity plug-in. Is thos a good plan and is there something special I should take care of ?
[07:28] <MCR1> *this a good plan
[07:29] <didrocks> MCR1: this is great, you will need to coordinate later on with sam to ensure those are exposed in g-c-c (there are a hardcoded list for that) and how to make those optionals for people not having unity
[07:30] <didrocks> MCR1: just remember that Feature freeze is 2 weeks away, so approx only one week to get things integrated :)
[07:31] <MCR1> didrocks: Ok, I hope I can get this done (weekend is reserved for that task) - I'll try to coordinate stuff with Sam, probably he needs to help me anyway... ;)
[07:32] <MCR1> didrocks: One thing that came to my mind is how Unity-2d will handle stuff if those hardcoded shortcuts are converted for example...
[07:32] <didrocks> no more unity-2d starting next week
[07:33] <didrocks> so don't bother :)
[07:33] <MCR1> didrocks: Oh, ok. One thing less to worry about then, although it works quite nice...
[07:46] <MCR1> duflu: Hi :) If feature-freeze is near, I would be very happy if we could get the most important "lost" plug-ins merged before the freeze. We do not need to activate those in GLES, or do we (afaik trip for example is simply deactivated in GLES) ?
[07:47] <sil2100> mhr3: hello! Will you find a free few moments of your time for releasing tarballs for bamf, libunity and the lenses (files, apps, music) in an hour or so ;)?
[07:47] <mhr3> sil2100, did we have any changes to lenses?
[07:47] <duflu> MCR1: Sorry, am in a mad rush getting the important features completed. The new plugins come after that
[07:48] <sil2100> mhr3: just the vala update, true... so maybe I'll just distropatch those
[07:48] <sil2100> mhr3: so only bamf and libunity for now ;)
[07:48] <mhr3> oh right, that's actually worth a release
[07:49] <mhr3> sil2100, we just finished standup, so i guess it's ok if i do them right away
[07:50] <didrocks> mhr3: sit! :)
[07:50] <mhr3> didrocks, grrrrrrrr
[07:52] <MCR1> duflu: I hope and wish your mad rush is successful and does end before feature freeze ;) - I stop disturbing you now :-X
[07:53] <sil2100> mhr3: I'll just check one more autopilot test and we're ready for release
[07:53] <mhr3> meh, it's not like there could a bug in libunity :P
[07:53] <sil2100> True, but still! ;) Better safe then sorry ;p
[07:54] <mhr3> i'll wait with bamf though :D
[07:54] <didrocks> sil2100: don't believe him, don't believe him!
[07:54] <mhr3> didrocks, ssshushhh
[07:56]  * mhr3 shakes fist at the half broken build system in trunk libunity
[07:56] <didrocks> mhr3: if it's only half broken, it's fine, take the other half!
[07:57] <mhr3> didrocks, right, half of the source files should do, right? :)
[07:57] <didrocks> sure, you write useless code, let's cut it down! :)
[07:58] <mhr3> didrocks, it's a sign of project maturity though, you know that libreoffice has like 20% of code that's unused?
[07:59] <didrocks> mhr3: yeah, I heard about that, it's scary that we have that much code around, and still not real good way to instrumente the code to detect dead part
[08:00] <sil2100> ...;) I'm scared when I listen to you guys ;p
[08:02] <sil2100> Arrgh
[08:02] <sil2100> hm, I need JohnLea!
[08:02] <sil2100> Since either something changed by design, or we have a small regression
[08:03] <mhr3> sil2100, in?
[08:03] <sil2100> mhr3: in switcher - it's probably unity-only though
[08:04] <sil2100> mhr3: checking how it looks in 6.0
[08:05] <mhr3> sil2100, tarball for dee as well?
[08:05] <mhr3> seems like there's wasn't one for quite a while
[08:07] <sil2100> mhr3: hell, why not? If you only feel like it ;)
[08:16] <mhr3> sil2100, what version are we doing now?
[08:16] <mhr3> 6.2?
[08:16] <mhr3> or 6.4?
[08:18] <sil2100> 6.2
[08:20] <sil2100> Ah, no, it seems to work - no regression here
[08:28] <didrocks> sil2100: btw, do not forget to have a google doc with the results of manual tests and autopilot ones :)
[08:28] <sil2100> didrocks: it's already done ;)
[08:34] <mhr3> sil2100, so green to push the tarballs?
[08:35] <mhr3> quick! hide! kamstrup's here
[08:35] <kamstrup> mhr3: hey!
[08:35] <kamstrup> what ever you do - I DISAPPROVE!
[08:35] <kamstrup> ;-)
[08:35] <mhr3> kamstrup, hey, hey! i see holiday has good effect on you :)
[08:37] <kamstrup> i know, right?!
[08:55] <sil2100> mhr3: GREENZ
[09:08] <mhr3> eeek, i have to create 6.0 series for all the lenses :/
[09:10] <gord> sucks to be yoou
[09:18] <mhr3> sil2100, disted, milestoned, uploaded, tagged, pushed
[09:18] <sil2100> mhr3: awesooome! I'll release for unity in nux in a moment
[09:18] <sil2100> s/in/and
[09:58] <mhr3> sil2100, oh dear, i forgot about bamf
[09:58] <mhr3> Trevinho, you here?
[10:02] <Trevinho> mhr3: yep
[10:03] <mhr3> Trevinho, still no big changes in bamf for the major bump?
[10:03] <Trevinho> mhr3: no :(
[10:04] <mhr3> 61st release of 0.2 series then? :/
[10:04] <sil2100> ...;)
[10:08] <sil2100> didrocks: in the changelog, should I also put changes from trunk that weren't assigned to any bugs?
[10:08] <sil2100> Or only the ones with bugs?
[10:09] <didrocks> sil2100: only those with bugs are enough, it's long enough already :)
[10:09] <didrocks> sil2100: btw, IIRC, there are some merges with contains "UIFe" in the bug title (not sure before this release, but some are proposed now)
[10:09] <didrocks> sil2100: if it's the case, you can remove the "UIFe" part :)
[10:10] <sil2100> didrocks: could you later on run unify again to generate the changelog for unity ;p ?
[10:11] <sil2100> didrocks: since for nux and the rest I do manually, since those are small
[10:11] <sil2100> But unity, phew
[10:11] <didrocks> sil2100: sure, tell me once you are ready :)
[10:12] <sil2100> \o/ thank you!
[10:12] <mhr3> sil2100, uploaded bamf
[10:12] <sil2100> mhr3: excellent, thanks!
[10:13] <sil2100> didrocks: for unify, all other unity projects (nux, bamf) should have unity upstream in their bugs as well, right?
[10:13] <didrocks> sil2100: yeah, as usual :)
[10:14] <sil2100> didrocks: last thing, since I forgot - do I need to set the milestone to 6.2 for unity on those as well? For instance, for nux?
[10:14] <didrocks> sil2100: on the unity upstream task, yeah
[11:07] <sil2100> didrocks: can I publish the new unity tarball, or do you need to do it yourself for unify to work?
[11:16] <didrocks> sil2100: no, you can publish it
[11:16] <didrocks> sil2100: just don't close the milestone
[11:19] <sil2100> didrocks: so, I should tick 'keep the 6.2. milestone active'?
[11:22] <didrocks> exactly
[11:53] <sil2100> didrocks: I sent an e-mail with branches and all the release details
[11:59] <didrocks> sil2100: "I checked lintian warnings - had to silence some for unity, but besides that no *new* ones seem to have appeared. "
[11:59] <didrocks> can you detail please?
[11:59] <didrocks> also,should I run unify now as you are telling you are waiting on the changelog?
[12:00] <didrocks> (ok on unify, running now)
[12:00] <didrocks> sil2100: unfreeze should be done by mmrazik
[12:14] <sil2100> didrocks: I know ;) Will ask him once I get  your ACK
[12:15] <sil2100> didrocks: no *new* lintian errors, since I remember getting this one before: E: unity-common: python-script-but-no-python-dep usr/lib/unity/makebootchart.py
[12:15] <sil2100> For unity ;p
[12:15] <sil2100> But since it's like not a main script, I think that's ok?
[12:16] <didrocks> sil2100: all in one commit :/
[12:16] <didrocks> don't remember about the one commit per act I really insisted on
[12:16] <didrocks> that makes the review painful
[12:17] <sil2100> ah, shit, sorry about that - in unity it's like that because I first did merge-upstream ...
[12:17] <sil2100> Could have started from the override branch already
[12:17] <didrocks> sil2100: just remember that for next time :)
[12:18]  * sil2100 writes that down this time
[12:18] <sil2100> My desk is actually getting very messy with all these notes
[12:37] <didrocks> Conflicting tags:
[12:37] <didrocks>     upstream-3.2.0
[12:37] <didrocks> hum, interesting
[12:38] <didrocks> in nux
[12:38] <didrocks> sil2100: you should use unify btw
[12:38] <didrocks> sil2100: you miss bugs
[12:38] <sil2100> :(
[12:39] <sil2100> So I missed one...
[12:39] <sil2100> Actually I though I had them all, hmm
[12:39] <didrocks> 3 in nux
[12:39] <sil2100> Which ones?
[12:40] <didrocks>     - Support for automation (LP: #685199)
[12:40] <didrocks>     - add alpha function on a NuxBaseWindow (LP: #718827)
[12:40] <didrocks>     - Timestamp field on the event structure is always 0 (LP: #735645)
[12:40] <sil2100> Ok, those completely I missed, need to check why
[12:42] <didrocks> I get 20 conflicting tags on unity
[12:42] <didrocks> have you done anything special?
[12:42] <didrocks> or is bzr going crazy?
[12:42] <sil2100> hm, no? 20 conflicting tags? That's a bit too much for a 'mistake'
[12:43] <didrocks> sil2100: no, you made something weird
[12:43] <didrocks> your bzr branch is based on revision 25
[12:43] <didrocks> and you remerged everything from that
[12:43] <sil2100> Which one? lp:ubuntu/unity ?
[12:43] <didrocks> right
[12:43] <sil2100> All I did was bzr branch lp:ubuntu/unity freshly today
[12:43] <didrocks> hence conflicting tags all over your branch when pulling on ubuntu/unity
[12:44] <didrocks> sil2100: look at your revision
[12:44] <didrocks> you start at rev 25
[12:44] <sil2100> And did a bzr merge-upstream
[12:44] <didrocks> or something is really weird in bzr-gtk
[12:44] <didrocks>     revno: 55.813.24 [merge]
[12:44] <didrocks> should rather be revno: 746
[12:45] <sil2100> revno: 747 [merge]
[12:45] <sil2100> committer: Łukasz 'sil2100' Zemczak <lukasz.zemczak@canonical.com>
[12:45] <didrocks> yeah, this is your upper commit
[12:45] <sil2100> This is what bzr log |less gives me
[12:45] <sil2100> revno: 746
[12:45] <sil2100> tags: 6.0.0-0ubuntu6
[12:45] <sil2100> This is the one I based on
[12:45] <didrocks> now, look at the first nested entry
[12:45] <didrocks> bzr log -n 1
[12:45] <didrocks> -n 2 sorry
[12:45] <didrocks>     revno: 55.813.24 [merge]
[12:45] <didrocks> this is your merge-upstream
[12:46] <didrocks> same issue with nux btw
[12:46] <didrocks> you started from     revno: 159.3.40 [merge]
[12:46] <sil2100> Wait, so what did I do wrong?
[12:46] <sil2100> I did exactly this:
[12:46] <didrocks> well, tell me you did do :)
[12:46] <sil2100> bzr branch lp:unity
[12:46] <sil2100> bzr branch lp:ubuntu/unity ubuntu
[12:46] <sil2100> cd ubuntu
[12:47] <sil2100> bzr merge-upstream ../unity-6.2.0.blabla ../unity --version=6.2.0 -r -1
[12:47] <sil2100> # changelog editing
[12:47] <didrocks> let me try that with nux
[12:47] <sil2100> debcommit
[12:47] <sil2100> And that's all I did
[12:47] <sil2100> Everything fresh from 0 today
[12:47] <didrocks> well, the log shows that something is wrong, isn't it?
[12:47] <didrocks> btw, when you did merge-upstream, I think it bailed on conflicting tags
[12:48] <didrocks> so you should have noticed that something went wrong (also, look at the logs)
[12:48] <didrocks> so let me redo this for nux
[12:48] <didrocks> and see if it's a merge-upstream issue
[12:49] <sil2100> hmmm, maybe it's something broken on my system?
[12:49] <sil2100> Since I'm doing what I was always doing
[12:50] <didrocks> nux is fine, no tag conflict
[12:50] <didrocks> let me try unity
[12:50] <didrocks> did you uncommit at some point?
[12:51] <sil2100> hm, in the past you mean?
[12:51] <didrocks> like, for the last release?
[12:52] <sil2100> hm, I don't remember :/ I don't think so though
[12:53] <didrocks> sil2100: ok, anyway, the history is good, let me "force" bzr for the tagging issue
[12:53] <sil2100> didrocks: sorry about that, whatever might have caused it :(
[12:53] <didrocks> sil2100: I have unfortunately no idea of what the actual cause is TBH :/
[12:54] <didrocks> maybe something in bzr in quantal
[12:54] <didrocks> ok, forced :)
[12:54] <didrocks> sil2100: on another note…
[12:54] <didrocks> nux broke its abi
[12:55] <didrocks> so, in the build-dep, you need to dep on latest nux as we are pushing everything at the same time
[12:55] <didrocks> (doing it now)
[12:55] <sil2100> Thank you!
[12:55] <didrocks> the abi system will then do the right think to dep on the right version :)
[12:55] <sil2100> Ok, need to attend a meeting now, brb
[13:02] <didrocks> mhr3: does u-l-a, u-l-f or u-l-m needs latest libunity API addition?
[13:03] <mhr3> didrocks, latest being?
[13:03] <mhr3> 94?
[13:04] <mhr3> but actually, no
[13:04]  * mhr3 remembers that the latest changes are only proposed so far
[13:07] <didrocks> mhr3: great, thanks :)
[13:11] <didrocks> sil2100: geis: the build-dep has been bumped in nux to 2.2.10
[13:11] <didrocks> think about doing a diff in configure.ac (again :p)
[13:15] <didrocks> sil2100: oh oh, and we ship the script for transitionning to gsettings
[13:15] <didrocks> sil2100: we shouldn't yet
[13:15] <didrocks> as compiz is not there
[13:17] <didrocks> so you have those changes shipped and not in the changelog as well
[13:22] <sil2100> didrocks: we ship it already? Wait ;)
[13:22]  * sil2100 didn't see it
[13:23] <didrocks> sil2100: yeah, you did
[13:23] <sil2100> didrocks: I don't see any script though
[13:23] <sil2100> didrocks: where is it?
[13:24] <didrocks> sil2100: you do have debian/unity.migrations in your branch, right?
[13:24] <didrocks> let me see, maybe me and some cruft around
[13:24] <sil2100> didrocks: but that's yours
[13:24] <didrocks> rev 750
[13:24] <didrocks> yeah, but it's your branch as well, right?
[13:24] <sil2100> bzr blame unity.migrations
[13:24] <sil2100> 736 didier. | tools/migration-scripts/01_unity_change_dconf_path
[13:25] <didrocks> indeed
[13:25] <didrocks> but it's in the branch you ship, right?
[13:25] <sil2100> Yes, but it was already in lp:ubuntu/unity
[13:25] <didrocks> yes because we were supposed to land the gsettings branch first
[13:25] <didrocks> which didn't happen
[13:25] <sil2100> Ah, shit ;)
[13:25] <didrocks> so we need to revert that
[13:25] <didrocks> no worry, doing it
[13:25] <didrocks> just to tell you: look at everything
[13:25] <didrocks> litterally, everthing :)
[13:25] <didrocks> everything*
[13:26] <didrocks> sil2100: speaking of migration
[13:26] <didrocks> sil2100: as you are not around next week
[13:26] <didrocks> sil2100: the script is in trunk, right?
[13:26] <didrocks> there is nothing you didn't add?
[13:26] <didrocks> (for both compiz and unity)
[13:28] <sil2100> didrocks: yes :)
[13:28] <sil2100> All seems merged in
[13:29] <didrocks> sil2100: excellent, thanks! I'll maybe add more keys due to the g-c-c keybindings migration, but good to know everything is good to go on your side
[13:29] <didrocks> sil2100: finishing with the lenses right now, the rest seems good :)
[13:30] <seb128> sil2100, hey
[13:31] <sil2100> didrocks: I'll double-check with Timo about gsettings in a moment
[13:31] <seb128> sil2100, do you plan to update dee? it was not listed on your ubuntu-release@ email
[13:31] <sil2100> didrocks: thanks!
[13:31] <sil2100> seb128: yes, I missed it in the mail :(
[13:31] <seb128> ok, no worry
[13:31] <seb128> I was just checking you did notice it
[13:33] <didrocks> sil2100: ok, all looks good here, after some dogfooding :)
[13:34] <didrocks> sil2100: I'll only upload on Monday though, still not found of Friday afternoon uploads, you can go on vacation with a light heart, well done!
[13:34] <didrocks> mhr3: FYI ^
[13:34] <didrocks> mmrazik: you can unfreeze the unity stack I guess :)
[13:35] <sil2100> didrocks: thank you! :)
[13:35] <mhr3> didrocks, cool
[13:36] <didrocks> sil2100: thanks to you :)
[13:36] <sil2100> didrocks: unfreezing then!
[13:37] <didrocks> sweet :)
[13:55] <jaytaoko> sil2100: didrocks: thanks for the release
[13:55] <didrocks> jaytaoko: yw ;)
[13:58] <sil2100> jaytaoko: yw - thanks for the help ;)
[14:28] <seb128> sil2100, didrocks: any reason to not upload to proposed? nobody should run proposed or those who do can only blame themself
[14:28] <seb128> speaking about unity 6.2, I saw the "will be uploaded on monday"
[14:29] <didrocks> seb128: not really, but I hope there will be no "copy to release in the wild"
[14:29] <didrocks> if you are confident, I can do it
[14:30] <seb128> didrocks, I'm confident, nobody is here during W.E and I will announce it in the release meeting
[14:30] <didrocks> ok, doing then
[14:32] <seb128> didrocks, thanks
[14:32] <seb128> BRING THE CRACK
[14:32] <seb128> sil2100, your phone number is in the directory right? and you have your phone with you at night, w.e and holidays?
[14:32]  * seb128 hides
[14:32] <didrocks> seb128: just for your pleasure!
[14:32] <sil2100> Erm...
[14:33]  * sil2100 throws away his phone through the window
[14:33] <sil2100> I have no phone
[14:33] <seb128> lol
[14:33] <sil2100> Sorry
[14:33] <sil2100> ;)
[14:34] <didrocks> seb128: I have his address!
[14:35] <sil2100> Need to run!
[14:36] <didrocks> sil2100: you won't run fast enough, why do you think I'm training everyday? :)
[14:43] <sil2100> I'm doomed!
[14:43] <sil2100> ;)
[14:57] <sil2100> mhr3: how busy are you? ;)
[14:58] <mhr3> sil2100, ehm, moderately busy? :)
[15:26] <didrocks> sil2100: you need to ensure that -proposed is added to the merger I guess
[15:27] <didrocks> sil2100: mmrazik and his team should do that, I don't remember if I added it back last time
[15:27] <didrocks> (as the packaging needs latest nux)
[15:28] <sil2100> didrocks: ok, will ping him about that
[15:28] <didrocks> thanks :)
[16:13] <nmarques> anyone can help me with a build issue (unity 6.2.0) ? (http://fpaste.org/tMI3/)
[16:30] <MCR1> bschaefer: Hi :) +1 for re-proposing and fixing conflicts for improve-keyboard-shortcut-overlay-wording.
[16:34] <MCR1> Does someone know why the Jenkins unity-automerger failed to merge so many branches ? The console output https://jenkins.qa.ubuntu.com/job/automerge-unity/1021/console does not really help, but I noticed that many other branches also failed to merge...
[16:51] <nmarques> is unity and nux ready for gcc47 ?
[16:54] <bschaefer> MCR1, you're welcome, and im not sure....I think it's being looked at
[16:55] <MCR1> bschaefer: thx
[16:56] <MCR1> nmarques: I am compiling on Quantal, so I guess the answer is yes
[16:58] <nmarques> MCR1, I'm having here a strange issue around, preventing me from building it
[16:59] <MCR1> nmarques: oh, maybe it is the same issue jenkins has ? I did not try lately - what is your error ?
[16:59] <nmarques> [   16s] CMake Error at CMakeLists.txt:178 (add_subdirectory):
[16:59] <nmarques> [   16s]   add_subdirectory called with incorrect number of arguments
[17:00] <nmarques> strangely somehow it inserts a line in CMakeLists.txt with: add_subdirectory()
[17:00] <nmarques> and it doesnt build :)
[17:00] <MCR1> nmarques: I will try to confírm, wait a minute.
[17:05] <MCR1> nmarques: nux compiled
[17:06] <nmarques> nux also builds here fine :)
[17:09] <MCR1> nmarques: test_launcher.cpp fails
[17:12] <nmarques> I'm not building the tests and documentation :)
[17:14] <MCR1> nmarques: maybe this is a good idea, but here now also BFBLauncherIcon.cpp fails :(, might be my cmake config though
[17:15] <nmarques> MCR1, mine doesn't even start to build :) it fails on the initial config fase
[17:15] <nmarques> http://fpaste.org/tMI3/
[17:16] <MCR1> http://pastebin.com/SZTgxgFD
[17:18] <bschaefer> nmarques, sorry, i haven't seen that error before...
[17:18] <bschaefer> MCR1, for that error you need libgeis
[17:18] <bschaefer> MCR1, and you need to autogen nux with this --enable-gestures
[17:18] <nmarques> bschaefer, CMakeLists.txt gets a 'add_subdirectory()'
[17:18] <MCR1> bschaefer: Ah, thx
[17:19] <nmarques> bschaefer, and it blows, maybe a missing dependency (though they all seem to be there)
[17:19] <bschaefer> nmarques, but I don't get that error, so saying its the make file is odd...
[17:19] <bschaefer> are you trying to build unity on fedora?
[17:20] <nmarques> opensuse
[17:20] <nmarques> :)
[17:21] <MCR1> bschaefer: Do I have to get libgeis from source and compile it also, or is libgeis-dev enough ?
[17:21] <bschaefer> nmarques, hmm well im not sure why you're getting that config error :(
[17:21] <bschaefer> MCR1, if you're on P then yes
[17:22] <bschaefer> P = 12.04
[17:22] <bschaefer> Q = 12.10
[17:22] <MCR1> Q
[17:22] <nmarques> bschaefer, do you know where is the log file from the config? I'm not fluent with cmake
[17:22] <nmarques> bschaefer, maybe the answer lies there :)
[17:22] <bschaefer> nmarques, im not really either :( sadly...
[17:22] <bschaefer> MCR1, yeah that should be good then
[17:22] <MCR1> nmarques: You could try cmake-gui, which is quite nice to configure options
[17:22] <nmarques> bschaefer, I think I found it ;)
[17:22] <nmarques> bschaefer, missing dependency, gtest
[17:22] <bschaefer> nmarques, awesome!
[17:23] <MCR1> bschaefer: thx again :)
[17:23] <bschaefer> MCR1, np!
[17:38] <MCR1> bschaefer: worked now.
[17:38] <bschaefer> MCR1, sweet
[18:06] <nmarques> bschaefer, it's building... but there's hardcoded paths for gtest in the makefile, uncool stuff :)
[18:07] <bschaefer> nmarques, :(, thats no good...if you make a bug report it should get looked at :)
[18:08] <niadh> hey
[18:08] <nmarques> bschaefer, it's commented out, so its something people are aware... (gtest)
[18:08] <nmarques> either way I've disabled the tests and kicked out gtest, hopefully no second effects :P
[18:08] <bschaefer> nmarques, oo alright, it must have been a work around :(
[18:08] <bschaefer> nmarques, you could just not built tests haha
[18:08] <bschaefer> nmarques, yeah! thats the way to do it :)
[18:09] <bschaefer> (there should be none! unless you want to run the gtest :) )
[18:09] <niadh> Hi all, I was looking into packaging Unity for Arch Linux, was wondering if I might be able to get some help here on how to do that?
[18:11] <niadh> I have started with the nux component, but it has various dependencies on utouch libraries some of which I can find, others I cant
[21:00] <MCR1> bschaefer: Still here ?
[21:02] <MCR1> Good news. I guess (hope) I fixed the first of the hardcoded Unity shortcut bugs.
[21:02] <MCR1> \o/
[21:09] <bschaefer> MCR1, yeah im around
[21:09] <bschaefer> cool, hmm what issue was it?
[21:09] <MCR1> bschaefer: It was multiple issues, one moment
[21:10] <MCR1> bug 1022743
[21:10] <ubot5`> Launchpad bug 1022743 in unity (Ubuntu) "Hardcoded Unity shortcuts create multiple Compiz problems" [Low,Confirmed] https://launchpad.net/bugs/1022743
[21:10]  * bschaefer looks
[21:11] <MCR1> the problem was that Unity takes over shortcuts, which Compiz already controls
[21:11] <bschaefer> MCR1, nice. I never noticed that as I usually keep my shortcuts default haha
[21:12] <bschaefer> MCR1, do you have a branch? If so we'll need some tests!
[21:12] <MCR1> maybe you noticed the I don't know comments in the branch you have worked on
[21:12] <MCR1> when you fixed the conflicts
[21:12] <MCR1> the improve wording one
[21:12] <bschaefer> yeah, I was just fixing the conflicts, I noticed some //FIXME conflicts blah blah
[21:13] <MCR1> yeah, somebody did an unfinished job there, haha
[21:13] <MCR1> which introduced bugs
[21:14] <MCR1> because both, Unity and Compiz were watching for those keys...
[21:14] <bschaefer> MCR1, does this just causes problem with the keyboard shortcut layout or actually causes usability issues?
[21:14] <MCR1> usabilty also - no possibility to change shortcuts for example
[21:14] <MCR1> if you change them they jump back currently
[21:14] <bschaefer> oo I should have looked at the code more....yeah. Im surprised it makes the shortcuts there...
[21:15] <MCR1> I guess it was not your fault
[21:15]  * bschaefer just thought it was a nice pretty window
[21:15] <MCR1> somebody was to lazy to search for all the Compiz equivalents, so they just got hardcoded
[21:15] <bschaefer> and that it was 'pulling' the shortcuts from compiz, and if not then it was just hardcoded
[21:15] <bschaefer> yeaah, well if you have a branch that would be an awesome fix :)
[21:16] <MCR1> sure, I am working on it, but it will ofc conflict with yours ;)
[21:16] <bschaefer> hmm yeah that stupid unity merger isn't working
[21:16] <MCR1> maybe I should continue the work on improve-wording ?
[21:17] <bschaefer> though I do like the unity merger it just seems to be always angry :(
[21:17] <MCR1> and make it improve-wording-and-shortcuts ;)
[21:17] <bschaefer> MCR1, you could do that and say its is a umm...
[21:17] <bschaefer> one sec I forgot the name...
[21:18] <bschaefer> MCR1, a Prerequisite Branch
[21:18] <MCR1> the bad thing is that this was the task for the weekend, and now I fixed it already - haha
[21:18] <bschaefer> when you do a merge proposal, and under extra options there is a Prerequisite Branch, put my branch under that so it has to be merged first before yours
[21:18] <bschaefer> haha
[21:19] <bschaefer> MCR1, no worries, I can take a look at it as well. It's only Friday 2pm here
[21:19] <MCR1> bschaefer: yes, I mistakenly used that once already... ;)
[21:19] <MCR1> USA ?
[21:19] <bschaefer> MCR1, yup
[21:19] <bschaefer> it gets lonely on Fridays around this time haha
[21:19] <MCR1> hehe
[21:22] <MCR1> ok, I'll start from your branch and re-fix and fix stuff there and then I submit the proposal with your branch as prerequisite, but it might take a while (I need a break now ;))
[21:23] <bschaefer> MCR1, no worries ping me when it's ready for a review :)
[21:23] <MCR1> ok, ql
[21:52] <cjohnston> me4oslav: ping
[22:14] <MCR1> bschaefer: Part One should be ready for review: https://code.launchpad.net/~mc-return/unity/unity.merge.fix-hardcoded-keys-part1/+merge/119204
[22:16] <bschaefer> MCR1, 32	+ hints.push_back(std::shared_ptr<shortcut::AbstractHint>(new shortcut::MockHint(_("Switching"), "", "", _("Move the focus."), shortcut::HARDCODED_OPTION, _("Left & Right"))));
[22:16] <bschaefer> what was done on that line?
[22:16] <bschaefer> i can't see a change haha
[22:16] <MCR1> bschaefer: foucs -> focus
[22:16] <MCR1> typo
[22:16] <bschaefer> MCR1, nice, im bad at finding those kind of typos haha
[22:17] <MCR1> I am good at those -> they hurt my eyes
[22:17] <bschaefer> MCR1, let me test it. Yeah I was staring at it intensively but still couldn't find it!
[22:18] <MCR1> bschaefer: Unfortunately some of the shortcuts need more investigation, while others, which are Unity-only, need additional options in the unityshell plug-in.
[22:18] <MCR1> bschaefer: Some simply ARE hardcoded, which is bad.
[22:19] <bschaefer> MCR1, yeah...hmm but at lease it's slowly getting fixed...idk why they were hard coded
[22:20] <MCR1> I think someone would have had to add additional code to the unityshell plug-in, but I have to investigate.
[22:20] <bschaefer> MCR1, hmm im still finding it hard to believe this is were shortcuts get generated though...cause im pretty sure events go X11 -> Compiz -> Unity or X11 -> Nux -> unity
[22:20] <MCR1> I think, that when you invent a new feature you do not think about the possibility of configuring it, you simply add the feature first and make it work with some default
[22:20] <bschaefer> yeah
[22:21] <bschaefer> well let me test this out!
[22:22] <bschaefer> cause unity overrides compiz events (which is also a bad workaround...)
[22:22] <bschaefer> sometimes
[22:22] <MCR1> bschaefer: I cannot test the fix at the moment, but it makes sense for me, hopefully it works, but imho it should - or things are more complicated than needed
[22:23] <bschaefer> MCR1, cause what I would think it does is use a Get...to Get the current shortcut so it can draw the correct one
[22:23] <bschaefer> not set it, but if it also Sets it then that would be a problem...haha
[22:24] <bschaefer> (also bad design if it Gets and Sets with 1 function call...)
[22:24] <MCR1> bschaefer: Can you test it ? I am a bit excited...
[22:24] <bschaefer> MCR1, yeah, i have to let it compile first :)
[22:24]  * bschaefer should have merged it to my unity branch...
[22:25] <MCR1> cool, thanks - I'll tell you in the meantime how to best test if it works...
[22:25] <bschaefer> either way though, you're branch is good. As it fixes hard coded problems
[22:26] <bschaefer> well im guessing to test it would be to change the shortcut option in CCSM with one of the ones you changed
[22:26] <MCR1> to test it go to CCSM->General Options->Key Bindings and change the "Window Menu" key to something else than <Alt>space
[22:27] <MCR1> bschaefer: yes, exactly - I just wanted to guide you along the way (many folks do not like CCSM it seems)
[22:27] <MCR1> :)
[22:27] <bschaefer> yeeah CCSM can cause 'problems'
[22:28] <bschaefer> MCR1, /home/bschaefer/src/unity.merge.fix-hardcoded-keys-part1/shortcuts/StandaloneShortcuts.cpp:77:202: error: expected ‘)’ before ‘;’ token
[22:28] <bschaefer> you forgot a ')' :)
[22:29] <MCR1> ups
[22:29] <MCR1> it is 0:29 here ;)
[22:29] <bschaefer> no problem, I did that when I was fixing the conflict on all of them haha
[22:29] <bschaefer> oo that is a bit late!
[22:30] <MCR1> I will fix it in the branch
[22:31] <bschaefer> MCR1, hmm I wonder if that was from my branch haha
[22:31] <bschaefer> it couldn't be though as it was compiling...
[22:31] <bschaefer> o well it's an easy fix :)
[22:31] <MCR1> no, I think it was my fault during copypaste
[22:32] <bschaefer> oo yeah, that'll happen. I don't like how we even generate all those shortcuts...
[22:32] <bschaefer> I want to get it into a header in a const structure...
[22:32] <MCR1> Compiz is great at shortcut handling imho
[22:33] <bschaefer> yeah, compiz does shortcuts well...I just don't like:
[22:33] <bschaefer> hints.push_back(std::shared_ptr<shortcut::AbstractHint>(new shortcut::MockHint(_("Menu Bar"), "", "", _("Reveals application menu."), shortcut::COMPIZ_KEY_OPTION, "unityshell", "show_hud")));
[22:33] <bschaefer> 50 times...
[22:33] <bschaefer> we should be able to loop over a structure that will do that haha
[22:33] <bschaefer> plus we have duplication in unityshell.cpp and that Standalone one...
[22:34] <MCR1> hehe
[22:34] <MCR1> yes the duplication is stupid
[22:34] <MCR1> pushed
[22:34] <bschaefer> MCR1, yeah. Hmm you're branch didn't seem to fix it :(
[22:34] <MCR1> noooooooooooooooooooo
[22:35] <bschaefer> MCR1, I think this is a problem somewhere else, possibly in compiz or in unity.xml thingy hmm
[22:35] <MCR1> then I have to dig further into the code - planned to find some time for that on the weekend...
[22:35] <MCR1> thanks a lot for testing - does it still jump back to Alt+Space ?
[22:35] <bschaefer> MCR1, you're branch is still good though. As we don't want that hardcoded stuff in there...
[22:35] <bschaefer> yeah
[22:35] <MCR1> grmmpf
[22:35] <bschaefer> so you're branch will still get merged :)
[22:36] <MCR1> but should be easy to find the problem... but not today
[22:36] <bschaefer> yeah haha
[22:36] <MCR1> ok, thx a lot for the help
[22:36] <bschaefer> MCR1, np! Go get some sleep :)
[22:36] <bschaefer> thanks for digging into that problem :)
[22:37] <MCR1> yeah, I guess we will fix for 12.10 ;)
[22:37] <MCR1> gn
[22:37] <bschaefer> yup. good night!