[01:15] <skunk_> hello, I have a question abour unity search tool
[01:15] <skunk_> anyone there??
[01:22] <thumper> which search tool?
[01:23]  * thumper wanders off to make coffee
[04:22] <tberman> I have questions about the new webapp support
[04:22] <tberman> is this the right place to ask them?
[07:58] <didrocks> sil2100: hey, how are you?
[07:59] <sil2100> didrocks: hello, rather fine - how about you?
[08:01] <didrocks> sil2100: I'm fine, thanks!
[08:01] <didrocks> working on gnome-control-center to support the new gsettings keys
[08:01] <sil2100> didrocks: excellent - I'm currently testing the migration files on my chroot
[08:02] <didrocks> sil2100: also, we need to pick the new metacity for the compiz support, I think the key change doesn't work without it :)
[08:02] <didrocks> greta
[08:02] <sil2100> didrocks: new metacity?
[08:03] <didrocks> sil2100: right, for gsettings support
[08:03] <didrocks> as the keys picked by compiz are the metacity ones
[08:03] <didrocks> (I wonder why all testing worked btw, I think ws switcher and changing the key should have failed)
[08:04] <sil2100> didrocks: what tests?
[08:04] <didrocks> sil2100: didn't Francis perform some tests on gsettings?
[08:04] <didrocks> I think changing the ws keybindings in ccsm should have failed
[08:04] <sil2100> didrocks: yes, he did
[08:04] <didrocks> like changing those in gnome-control-center
[08:05] <sil2100> didrocks: did we have tests for changing keybindings btw.?
[08:05] <didrocks> this shouldn't work and picked by compiz AFAIK until we have the new rebuild on metacity
[08:05] <sil2100> Don't remember those in the past
[08:05] <didrocks> well, I asked for extra tests with gsettings, right?
[08:05] <sil2100> didrocks: yes, we made the extra tests that were in compiz tests/ directory for gsettings
[08:06] <sil2100> didrocks: and those were purely gsettings support tests
[08:06] <sil2100> I had no knowledge of anything else
[08:07] <didrocks> I sent some manual tests to do, also for testing, should just try things that can be broken, I'm doing nothing magical than thinking of what can break :)
[08:07] <didrocks> and made the tests up
[08:07] <sil2100> didrocks: you sent it to the ML or to Timo/Alan?
[08:08] <didrocks> sil2100: Timo/Alan (don't remember who), was on IRC IIRC
[08:09] <didrocks> sil2100: but even without it, it's just a question of trying to figure out what can change and what needs testing
[08:09] <sil2100> didrocks: ok, then I didn't know about that - and I wasn't really aware of metacity having anything to do with compiz actually
[08:10] <sil2100> didrocks: I just advised Francis to do all settings switching through ccsm until g-c-c is modified
[08:11] <didrocks> sil2100: I'm even not sure that changing the settings through ccsm for those keys handled by g-c-c works
[08:11] <didrocks> sil2100: again, not 100% sure
[08:24] <sil2100> didrocks: not sure about the keys, but other settings work
[08:27] <didrocks> would worth trying the keys :)
[08:32] <sil2100> didrocks: it works for the wall plugin here (workspace switcher)
[08:34] <sil2100> didrocks: why did you say a metacity rebuild was necessary..?
[08:35] <didrocks> sil2100: are the changes done in gsettings?
[08:35] <didrocks> if you look at the keys, I don't think it's using the gsettings ones
[08:35] <sil2100> compizconfig - Info: Backend     : gsettings
[08:36] <didrocks> sil2100: I mean, do you see the *keys* changing in gsettings?
[08:36] <didrocks> the one for the ws switcher
[08:36] <didrocks> (keybindings)
[08:36] <sil2100> didrocks: one moment then
[08:40] <sil2100> didrocks: woah, that's true actually - but what makes those keys different from other keys? I'm shocked
[08:41] <sil2100> didrocks: seems that I do not know the insides of how keybindings are handled in compiz
[08:41] <didrocks> sil2100: it's some metacity/compiz magic ;) will explain you shortly
[08:42] <didrocks> let me finish some g-c-c work first
[08:42] <didrocks> concentrate on the upgrade meanwhile :)
[08:42] <sil2100> didrocks: aye ;)
[08:42] <didrocks> sil2100: oh btw
[08:42] <didrocks> sil2100: what the path already for unityshell settings?
[08:42] <didrocks> /org/compiz/unityshell/ ?
[08:42] <didrocks> (not the id, meaning org.compiz…, the path written by compiz)
[08:47] <sil2100> didrocks: ah, its /org/compiz/profiles/<profile_name>/plugins/unityshell
[08:47] <sil2100> didrocks: where profile_name is unity most probably
[08:48] <didrocks> sil2100: thanks :)
[09:46] <MCR> didrocks: Hi :) What could be the error here: https://code.launchpad.net/~mc-return/unity/unity.merge-fix-typos/+merge/116216 ?
[09:47] <popey> MCR, don't you need to escape that apostrophe?
[09:48] <MCR> popey: ?
[09:48] <popey> MCR, ??
[09:49] <MCR> popey: Do you mean ´ instead of ' ?
[09:49] <popey> no
[09:49] <popey> i mean \'  or ''' instead of '
[09:49] <popey> but that's just a guess :)
[09:50] <didrocks> greyback: hey, I see some gconf code in unity-2d, but it seems there is no key used, right?
[09:50] <didrocks> MCR: mmrazik is reponsible for the merger now
[09:51] <greyback> didrocks: no key used. It's reading metacity' gconf stuff I think
[09:51] <didrocks> greyback: I'm switching metacity to gsettings
[09:51] <didrocks> greyback: so, it won't work anymore
[09:52] <MCR> popey: Maybe that is why I instinctively avoided using it in the first place ;), but it would be nice to know if that is the problem. Maybe I should search the code for other usecases of ' to be sure...
[09:52] <greyback> didrocks: hmm ok, then unity-2d will probably need a few changes. Let me see...
[09:52] <MCR> didrocks: What does this mean ?
[09:52] <didrocks> MCR: you should ping mmrazik when the merger isn't working properly in your opinion :)
[09:54] <didrocks> greyback: few keys from what I see
[09:54] <MCR> didrocks: ok, but no mmrazik around here - in the worst case I will have to rebase again ;), so thanks for the info.
[09:55] <MCR> didrocks: One other question: Do you know if lp:compiz merges are on hold ?
[09:55] <didrocks> MCR: yeah, it's frozen until sil2100 can get the gsettings version out
[09:56] <MCR> didrocks: Thx 4 the info. :)
[09:56] <MCR> again ;)
[09:57] <didrocks> no worry ;)
[09:59] <MCR> I am proud to announce I've fixed "Simple Animations" for Compiz, btw - so if someone wants to try some new open/close animations: https://code.launchpad.net/~mc-return/compiz/compiz.merge-plugin-simple-animations/+merge/115048
[10:00] <MCR> well, new is not completely correct term here, but anyway...
[10:00] <MCR> *a completely
[10:02] <greyback> didrocks: only places I see unity-2d reads gconf are "/apps/metacity/general/titlebar_font" and "/apps/compiz-1/plugins/unityshell/screen0/options/show_hud"
[10:02] <didrocks> greyback: indeed, both needs to be changed
[10:02] <didrocks> greyback: do you think you have resource for those changes?
[10:03] <didrocks> greyback: same with all the patches related to unity-2d in metacity
[10:05] <MCR> JohnLea: AFAIK, design was not completely satisfied with how animations currently work - we could assign animations much more fine-grained to specific actions, but also applications and we have a lot of additional animations we could use to do that and be impressive, while providing clarity for the user.
[10:26] <sil2100> didrocks: but only compiz is blocked right now, right?
[10:31] <didrocks> sil2100: right
[10:32] <sil2100> didrocks: hows it going with converting g-c-c and metacity?
[10:33] <didrocks> sil2100: all is locked into itself, I will write an email after a break
[10:34] <sil2100> didrocks: ok - I have tested the migration files on my chroot and it all looks good, but I'm building compiz and unity on my PPA now so that Alan and the others can test it on real systems
[10:34] <sil2100> https://code.launchpad.net/~sil2100/compiz/gsettings_migration/+merge/116230
[10:34] <sil2100> https://code.launchpad.net/~sil2100/unity/gsettings_migration/+merge/116231
[10:34] <sil2100> Here are the two proposed MRQs for including .convert files
[10:35] <didrocks> sil2100: see my comment on the compiz MR
[10:35] <didrocks> seems you didn't note what I wrote here on Friday ^^
[10:35]  * didrocks really takes his break now, postponing it for too long :)
[10:35] <sil2100> didrocks: I did that
[10:35] <sil2100> didrocks: see the first line - it checks whether the unity .convert files are installed
[10:36] <didrocks> sil2100: hum? the diff is wrong or did I miss anything?
[10:36] <sil2100> 271	+ try:
[10:36] <sil2100> 272	+ with open('/usr/lib/compiz/migration/compiz-profile-unity.convert') as f: pass
[10:36] <sil2100> 273	+ except IOError as e:
[10:36] <sil2100> 274	+ print "No unity profiles installed, only migrating Default"
[10:36] <sil2100> 275	+ migrate_file('compiz-profile-active-Default.convert')
[10:36] <sil2100> 276	+ return
[10:36] <sil2100> 277	+ f.close()
[10:36] <sil2100> No need to check the gconf active_profile if unity is not installed
[10:36] <didrocks> ah, hum, not really elegant code ;)
[10:36] <sil2100> So all the checks for gconf are irrevelant - not needed, right ;)?
[10:37] <didrocks> sil2100: right, but if we change the call later on or the file profile name, you have to change it twice
[10:37] <didrocks> instead of one
[10:37] <didrocks> so I would rather go the way I describe which just add one line
[10:37] <seb128> didrocks, go running!
[10:37] <seb128> you will chat later
[10:38] <didrocks> sil2100: and use os.path.isfile()
[10:38] <didrocks> rather than opening and reading the content
[10:38] <sil2100> didrocks: I read somewhere it has security issues
[10:38] <sil2100> didrocks: http://stackoverflow.com/questions/82831/how-do-i-check-if-a-file-exists-using-python
[10:38] <didrocks> sil2100: hum? really? it's used everywhere and in the standard library
[10:39] <sil2100> didrocks: nothing serious, I just used what they recommended
[10:39] <sil2100> didrocks: but I'll probably switch to os.path.isfile() if you use it frequently
[10:39] <didrocks> sil2100: well, at worst, if the file doesn't exist (it's talking about os.path.exist()), the script will return 1
[10:39] <didrocks> and there is one thread here :)
[10:40] <sil2100> didrocks: ok ;)
[10:40] <didrocks> can you do the change at the end then?
[10:40] <didrocks> at least, there is just one flow that way
[10:40] <sil2100> didrocks: will do
[10:40] <didrocks> sil2100: thanks!
[10:40]  * didrocks really goes now
[10:40] <sil2100> Well, as I said, I just didn't want to do any gconf calls when unneeded - but if it's not a problem, I'll just change it
[10:40] <sil2100> didrocks: have fun!
[10:40] <didrocks> thanks :)
[11:03] <rye> uhm, has anybody seen bug #995916 reappearing recently (week/2 ago) with gimp in current most-up-to-date + proposed precise?
[11:10] <popey> rye, i haven't
[11:10] <sil2100> rye: not sure, we'll look into this though
[11:12] <rye> popey: so when you start gimp it adds the launcher icon and appears in alt-tab?
[11:13] <popey> rye, yes, i just tested it before saying "I haven't" :D
[11:13] <popey> I dont use gimp often but I know i have in the last week or so
[11:13] <rye> hmmm
[11:13] <alo21> hi all
[11:14] <alo21> I read this page (http://developer.ubuntu.com/resources/technologies/launcher/), but I did not understand how does it work
[11:15] <alo21> I also saw at hello-unity
[11:16] <alo21> can someone help me, please?
[11:18] <seb128> rye, do you use unity 3d?
[11:18] <seb128> alo21, hey, what issue do you have?
[11:20] <alo21> seb128: I would like to integrate my app with unity launcher
[11:20] <seb128> alo21, the documentation you pointed should help you, what issue do you get?
[11:20] <alo21> for example I would a count on the icon
[11:21] <rye> seb128: yes, unity standard, not 2d
[11:21] <seb128> rye, ok, dunno then, it works here
[11:21] <rye> uh-huh, launching gimp shows the launcher, when all windows appear the launcher disappears
[11:22] <rye> which is weird
[11:22] <alo21> seb128: it tells me "NameError: name 'unity_launcher_entry_get_for_desktop_id' is not defined"
[11:22] <seb128> alo21, where is your code? what ubuntu version do you use?
[11:23] <alo21> seb128: I use ubuntu 12.04
[11:23] <alo21> seb128: my code is in my pc :)
[11:23] <alo21> seb128: would you like to see it
[11:23] <alo21> ?
[11:24] <seb128> alo21, I mean, can you share your source code? like copy it on http://paste.ubuntu.com
[11:24] <alo21> the code, not the pc
[11:25] <alo21> seb128: http://paste.ubuntu.com/1106249/
[11:25] <alo21> here my code
[11:25] <alo21> it is a little bit long and not very cleare
[11:26] <alo21> seb128: this code should sends a clipboard to an IP
[11:26] <seb128> alo21, oh, you can't use a C api like that in python
[11:26] <alo21> seb128: where python one are?
[11:27] <seb128> alo21, on the page you gave before
[11:27] <seb128> launcher = Unity.LauncherEntry.get_for_desktop_id("evolution.desktop")
[11:27] <seb128> alo21, that's the python version
[11:27] <seb128> from gi.repository import Unity
[11:28] <seb128> launcher = Unity.LauncherEntry.get_for_desktop_id("gedit.desktop")
[11:28] <seb128> in your case
[11:29] <alo21> seb128: what library should I use?
[11:29] <seb128> alo21, libunity
[11:29] <seb128> or you mean?
[11:30] <seb128> alo21, install gir1.2-unity-5.0
[11:34] <rye> seb128: http://www.youtube.com/watch?v=Y4Nb4ZYNYFg - that looks weird
[11:35] <seb128> rye, dpkg -l | grep unity
[11:35] <seb128> rye, dpkg -l | grep bamf
[11:35] <seb128> to a paste please
[11:37] <rye> seb128: hm, i have webapps version, let me try w/o that
[11:37] <seb128> rye, good, you might to restart unity,bamfdaemon
[11:37] <rye> i should have started with checking this...
[11:58] <didrocks> sil2100: so, if you change any shortcuts in g-c-c, the new shortcut is working right? Like changing ws
[12:00] <sil2100> didrocks: not sure if when changing in g-c-c - but when changing in ccsm, it works
[12:00] <sil2100> didrocks: but the gsettings variable is not modified actually
[12:00] <sil2100> ;/
[12:01] <didrocks> sil2100: can you try in g-c-c?
[12:06] <sil2100> didrocks: works as well
[12:09] <didrocks> sil2100: ok, that what I reckon, so saved in gconf
[12:09] <sil2100> Ok, need to reboot, need to switch something in bios
[12:09] <sil2100> brb
[12:19] <sil2100> didrocks: so, hm, what about those key shortcuts?
[12:22] <didrocks> sil2100: I'm writing a long email, will forward it to you
[12:23] <sil2100> didrocks: thanks!
[12:23]  * sil2100 is afraid of long e-mails
[12:48] <didrocks> sil2100: just fwed you it
[12:53] <sil2100> didrocks: thanks! Just reading it right now
[12:54] <didrocks> good luck :)
[13:04] <alo21> hi
[13:04] <alo21> how can I install libunity for python?
[13:09] <alo21> can someone help me with  unity, please?
[13:10] <seb128> alo21, I told you before
[13:10] <seb128> alo21, install gir1.2-unity-0.5
[13:12] <alo21> seb128: yes... I really sorry, but my computer gone down for a while
[13:14] <alo21> seb128: and what library should I import?
[13:14] <alo21> in a .py?
[13:14] <seb128> alo21, the example is on the page you gave before...
[13:15] <alo21> seb128: can I import the example's library with the other (like time, os, sys, etc..)?
[13:15] <seb128> alo21, from gi.repository import Unity
[13:15] <seb128> alo21, launcher = Unity.LauncherEntry.get_for_desktop_id ("gedit.desktop")
[13:15] <seb128> alo21, just that
[13:16] <alo21> seb128: If I run that example alone is all ok. But if I run it within another code i got an issue
[13:18] <seb128> alo21, what issue?
[13:20] <alo21> seb128: fortunatly, now is all ok, but I cannot see the notification's number
[13:21] <seb128> alo21, how did you set the number?
[13:21] <alo21> seb128: http://paste.ubuntu.com/1106410/
[13:21] <alo21> seb128: Have I to set a loop?
[13:21] <alo21> is it mandatory?
[13:21] <seb128> alo21, you have gedit.desktop in your launcher?
[13:22] <alo21> seb128: I have a file open with gedit
[13:23] <seb128> alo21, yes you need an event loop
[13:24] <alo21> seb128: so... If I want a progress bar during a process.. I have to use thread. right?
[13:25] <seb128> alo21, no, you can use idle callbacks
[13:29] <alo21> seb128: idel callback in pygtk?
[13:30] <seb128> alo21, it's gobject
[13:30] <seb128> ide_add or timeout_add
[13:35] <alo21> seb128: for example, how can I add a count: http://paste.ubuntu.com/1106426/
[13:37] <seb128> alo21, what do you mean?
[13:37] <seb128> alo21, that example should work, it doesn't?
[13:38] <alo21> yes it is.... I set the count at 124. How can I add 1 cont avrey 5 sec?
[13:38] <seb128> alo21, put the count in a variable and increment the variable in the function?
[13:45] <alo21> seb128: what about it: paste.ubuntu.com/1106439/
[13:47] <alo21> seb128: but it does not increment the "lo" value
[13:48] <seb128> alo21, why do you need to pass it as a function argument if you defined this way?
[13:48] <seb128> alo21, the local definition take over the first one
[13:49] <seb128> alo21, you increment the lo from the function, not the one you want
[13:54] <alo21> seb128: sorry, but I did not understand
[13:54] <seb128> alo21, you increment the lo function that is local to your function, not the one you want
[13:55] <seb128> alo21, that one goes away when your function return
[13:55] <seb128> alo21, don't use the same name for 2 variables
[13:57] <alo21> seb128: could you write me a little axample, please?
[13:57] <DebolazW> I'm curious about something; When wayland replaces X completely some time in the future, how will compiz integrate into the solution?
[13:57] <seb128> alo21, no, I'm busy with other stuff sorry, it's trivial, just drop the "lo" argument to your timeout callback
[13:57] <seb128> alo21, you don't need it, lo is defined for the file
[13:57] <seb128> alo21, by doing that you just replace the variable you want to use
[13:58] <seb128> DebolazW, at the same place it does today?
[13:59] <DebolazW> seb128: So it will essentially just be a client to wayland?
[13:59] <seb128> DebolazW, not sure to understand the question
[14:00] <DebolazW> Well, I guess it might be better to point me to some page or debate discussing how the system components will ideally be attached together when the wayland transition is completed.
[14:00] <DebolazW> If such a thing exists.
[14:01] <seb128> DebolazW, I don't think wayland is close enough for a such plan to exist yet
[14:23] <alo21> seb128: I've done... thank you for your patience.
[14:24] <seb128> alo21, yw!
[14:24] <alo21> seb128: now I am wondering... how can I update a launcher status if I am running a pygtk loop?
[14:25] <alo21> have I use thread?
[14:25] <seb128> alo21, what do you mean?
[14:25] <alo21> seb128: for example I have a window open on my desktop
[14:26] <alo21> seb128: to keep thi window open, my programm run a loop. right?
[14:26] <seb128> yes
[14:27] <alo21> seb128: and the unity launcher tun a loop too, to keep it satus on. right?
[14:27] <alo21> run*
[14:27] <seb128> alo21, well, most programs run an event loop and wait for events to do actions yes
[14:28] <alo21> so.. if for example this programm have a button which rise the count on launcher...
[14:29] <alo21> seb128: when I push the button, the count rise up
[14:30] <alo21> seb128: if I push this button, I go into "launcher" loop.
[14:30] <alo21> seb128: and them how can I exit from it, to push the button again?
[14:38] <seb128> alo21, that's not how event loops work, they will just keep dealing with events where they arrive
[14:57] <alo21> seb128: for example I made this programm
[14:57] <alo21> http://paste.ubuntu.com/1106539/
[14:57] <alo21> seb128: where cac is a .py to manage my icon on the launcher
[14:58] <alo21> seb128: but I got an error
[15:24] <tberman> seb128: who should i talk to wrt the unity webapp support?
[15:24] <seb128> tberman, try racarr or kenvandine
[15:25] <kenvandine> tberman, #ubuntu-webapps
[15:26] <fginther> didrocks, Bonjour! Can you please ack the precise nomination for https://bugs.launchpad.net/ayatana-design/+bug/839717
[16:21] <sil2100> seb128: I'm pushing the nux SRU to my PPA for testing - if all seems fine and Jay will ACK it, we'll be ready to push it for the release
[16:21] <seb128> sil2100, ok
[16:22] <sil2100> seb128: I also opened a bug for the 2 performance fixes https://bugs.launchpad.net/ubuntu/+source/nux/+bug/1028020
[16:22] <sil2100> I have added it to the changelog so it is trackable
[16:22] <seb128> sil2100, great, thanks
[16:23] <sil2100> seb128: as for the SRU descriptions for unity - sadly Francis couldn't work on them on Friday, but I did a bunch of them today - so by tomorrow we should be cleared with that
[16:23] <seb128> sil2100, great, I pinged the SRU guys but as I though they were all busy on friday, I hope they can review it today
[16:24] <sil2100> seb128: excellent, thanks
[16:24] <spoleeba> morning campers,  I'm attempting to get a clean build of libunity into the official fedora repos. I've hit one snag. Fedora F17 and rawhide ship libgee 0.7.x which has some api differences from libgee 0.6.x series.  I'm prepared to do the work to patch the calls from libunity into libgee on my own over the next few days, but before I start on that, I was wondering if libgee 0.7.x is already on someone's radar screen for roadmapping purposes. I'd hate to
[16:24] <spoleeba>  duplicate work unncessarily
[16:24] <seb128> mhr3, ^
[16:25] <seb128> spoleeba, we will probably update at some point but I don't think anyone started work on that
[16:27] <spoleeba> seb128, okay I'll branch trunk and generated some bzr commits. Would you be a person I should ping to look over a potential libgee 0.7.x support patchset for merge sometime in the next month?
[16:27] <seb128> spoleeba, in libunity? you should talk to mhr3 rather
[16:27] <spoleeba> mhr3, tag you're it
[16:29] <spoleeba> seb128, once i make changes, I'll probably need some help from someone crafting tests to make sure the patches are correct
[16:31] <nmarques> kenvandine, ping
[16:31] <spoleeba> nmarques, good morning
[16:31] <nmarques> spoleeba, hello
[16:32] <spoleeba> nmarques, i havent had a chance to follow up with the OBS Fedora repo guy yet
[16:32] <nmarques> spoleeba, according to the email he sent to fedora-devel he moved to Fedora :)
[16:32] <nmarques> spoleeba, so I've requested a new devel proj (X11:Unity) and I'm making the port to openSUSE
[16:32] <nmarques> spoleeba, before my former repo gets all twisted
[16:33] <kenvandine> hey nmarques!
[16:33] <nmarques> spoleeba, either way we can help each other :)
[16:33] <kenvandine> thx for the reminder.. let me go digging
[16:33] <spoleeba> nmarques, im still very interested in knowing how much vendor patching still has to be done or not done
[16:33] <nmarques> kenvandine, the info was for spoleeba
[16:33] <nmarques> spoleeba, that's what I came to check with kenvandine
[16:34] <spoleeba> nmarques, at this point the bulk of the work might just be missing depedency stack elements as packages
[16:34] <spoleeba> nmarques, do you have review ability?
[16:34] <nmarques> spoleeba, for ?
[16:34] <nmarques> spoleeba, in Fedora ?
[16:34] <spoleeba> nmarques, we might be able to tag team through a series of packages and get them through review as a stack
[16:34] <spoleeba> nmarques, yes in fedora
[16:35] <spoleeba> nmarques, i know adamw will also help with reviews as well
[16:35] <nmarques> spoleeba, not really, I only maintain 1 package in Fedora, Matthias Runge is my sponsor and Dan Callaghan is my co-maintainer
[16:35] <nmarques> spoleeba, but I can help with reviews or co-maintaining
[16:35] <spoleeba> nmarques, im currently working through the libunity stack... to get all the application support bits into the repo
[16:35] <spoleeba> nmarques, if you maintain you have review capabilities i thought
[16:36] <nmarques> spoleeba, then I do :)
[16:36] <nmarques> spoleeba, my interest on Fedora is mainly on EL side
[16:36] <spoleeba> nmarques, then we probably have enough interested maintainers to make a conherent push
[16:36] <nmarques> spoleeba, well, I have some people on SUSE side to help with the ports to gcc 4.7 ;)
[16:36] <kenvandine> seb128, do you know if we still have any gtk patches that are required for unity?
[16:36] <nmarques> spoleeba, we can all work together :)
[16:37] <kenvandine> i think we have one required for appmenu
[16:37] <kenvandine> but none that are needed for unity specifically
[16:37] <nmarques> spoleeba, this is, upstream, fedora and suse
[16:37] <spoleeba> kenvandine, required for appmenu or desired?
[16:37] <kenvandine> required, i am pretty sure
[16:37] <kenvandine> seb128, ^^
[16:37] <seb128> kenvandine, we still have one to expose some set_grab for ido
[16:37] <nmarques> kenvandine, that stuff to export widgets through DBus ?
[16:38] <nmarques> kenvandine, the app_grab hack ?
[16:38] <seb128> required for old appmenu
[16:38] <seb128> gmenus doesn't require patches
[16:38] <seb128> so that one gtk patch is going away over time as stuff are ported
[16:38] <spoleeba> seb128, is the gmenu stuff in unity trunk?
[16:38] <seb128> spoleeba, yes, gmenu support was in unity 5
[16:38] <seb128> the precise version
[16:39] <spoleeba> seb128, for Fedora purposes...we dont have to suppor the old appmenu at all in our deliverable...we've got no technical debt in our packages for that support
[16:39] <spoleeba> seb128, so to get a clean set of packages into fedora at all...not having to patch gtk is a huge win
[16:39] <seb128> spoleeba, well, it's not a technical debt, it's so standard gtkmenus got exported
[16:40] <seb128> spoleeba, you will not have appmenu working well with most apps without that patch
[16:40] <seb128> but appmenu isn't an hard requirement in unity
[16:40] <seb128> you can use unity without appmenu-gtk
[16:40] <seb128> you will just don't get the menus in the panel for stuff not using gmenus (which is still most of the world)
[16:40] <spoleeba> seb128, fine with me
[16:41] <seb128> good
[16:41] <seb128> the other patch required is a small one to expose a grab api
[16:41] <kenvandine> so it should be much easier to get this packaged now :)
[16:41] <seb128> I think ido uses it for the indicator-sound slider grabbing
[16:41] <kenvandine> i think we dropped that?
[16:41]  * kenvandine is probably wrong... since seb128 maintains gtk :)
[16:42] <seb128> kenvandine, we dropped the offscreen stuff from ido, let me see if it means we stopped needing that gtk patch
[16:42] <spoleeba> seb128, worst case we can turn that into a noop and just lose that functionality?
[16:42] <seb128> spoleeba, yes, that's only for indicator sound to not have the indicator closing when using the slider
[16:43] <kenvandine> 062_ubuntu-set-grab-add.patch
[16:43] <seb128> so specific to an indicator
[16:43] <nmarques> spoleeba, an initial package from over 1 year ago already had a patched ido for not using that patch in Fedora
[16:43] <seb128> kenvandine, src/idoscalemenuitem.c:  ubuntu_gtk_widget_set_has_grab (scale, TRUE);
[16:43] <nmarques> spoleeba, it wasnt Adam who did it, but some other dude, nevertheless Adam most likely remembers it
[16:43] <seb128> kenvandine, still used
[16:44] <kenvandine> yeah
[16:44] <spoleeba> nmarques, shrug... im not hearing any showstoppers
[16:44] <kenvandine> so we are done to just one patch :)
[16:44] <kenvandine> not bad
[16:44] <spoleeba> nmarques, though Im not sure the OBS repo is a good starting point or not for submittable effort
[16:44] <kenvandine> spoleeba, nmarques: we've worked hard to reduce the need for patching
[16:44] <nmarques> spoleeba, forget OBS :)
[16:45] <nmarques> kenvandine, and hopefully you will get a few honor points for Ubuntu with that ;)
[16:45] <nmarques> kenvandine, thx for the effort :)
[16:45] <kenvandine> and seb128 :)
[16:45] <nmarques> kenvandine, maybe I finish now what I started 2 years ago
[16:46] <spoleeba> kenvandine, i'll make it a point to lavish praise for closing the gap when we get these packages through fedora's review process
[16:46] <kenvandine> :)
[16:46] <kenvandine> people seem to think we like maintaining patches...
[16:46] <nmarques> kenvandine, for SUSE I'll work with the hacks
[16:46] <kenvandine> we try very hard not to :)
[16:46] <kenvandine> awesome guys!
[16:46] <spoleeba> kenvandine, people seem to think a lot of things about alot of people...myself included
[16:46] <nmarques> kenvandine, lets go for the full fledged experience ;)
[16:46] <kenvandine> indeed
[16:48] <nmarques> spoleeba, Jeff, let me know when you create a meta bug report for this
[16:48] <spoleeba> kenvandine, while im stuck on the ass end of an island out in the middle of the northern pacific next month... I should be able to push through all the packaging for unity
[16:48] <nmarques> spoleeba, so I can subscribe it and follow it/help with the review
[16:48] <kenvandine> sweet
[16:48] <spoleeba> kenvandine, not sure i'll internet access..but even off the grid I can get the packageset roughed out
[16:48] <nmarques> spoleeba, ./query ?
[16:49] <nmarques> of no interest for the channel
[16:49] <mhr3> spoleeba, we don't really do anything crazy with gee, were there such big changes?
[16:51] <spoleeba> mhr3, call to some functions changed number of arguments... libunity fails to build.  I wasnt going to touch it until I talked to you guys for a status report. when I get back home tonight I can provide a more detailed summary for you
[16:52] <mhr3> spoleeba, changed args vala-wise or c-wise?
[16:52] <spoleeba> mhr3, C wise I believe  as it references a .h header file in the error message.
[16:53] <mhr3> spoleeba, then i'd suggest to just touch the vala files, i wouldn't be surprised if it passed then
[16:53] <spoleeba> mhr3, the libunity vala files?
[16:54] <mhr3> spoleeba, yes
[16:54] <spoleeba> mhall119, i'll look tonight.  I believe you and I are on something like a 9 or 10 hour time difference so irc probably isnt going to be the best way to communicate
[16:54] <spoleeba> mhr3, sorry that was for you
[16:55] <mhall119> no worries :)
[16:56] <mhr3> spoleeba, if touching won't feel free to create a branch, but i'm not sure we want to transition to unstable gee right now
[16:56] <mhr3> won't work*
[16:56] <spoleeba> mhr3, im not expecting you to transition... but i have to
[16:57] <spoleeba> mhr3, i just want to make sure the patchset i produce is reusable so when you do make the jump you can use my changes
[16:57] <mhr3> spoleeba, right, but no worries, imo it'll work just fine if you let valac rebuild the c files
[16:58] <spoleeba> mhr3, if its a tiny patchset I can just carry it as a vendor patch in the packaging
[16:58] <mhr3> spoleeba, sure
[16:58] <spoleeba> mhr3, well that's all i need for now.
[16:59] <mhr3> cool, eod for me.. :)
[17:01] <nmarques> kenvandine, one last question :)
[17:01] <nmarques> kenvandine, are you aware of any Xorg patches?
[17:01] <kenvandine> nope
[17:01] <kenvandine> afaik there are none needed
[17:02] <nmarques> kenvandine, trunk and gcc 4.7 works ?
[17:02] <kenvandine> yes
[17:02] <kenvandine> well... i think
[17:02] <nmarques> ok... so I'll just backport the necessary bits to last stable
[17:02] <kenvandine> quantal is gcc 4.7 by default
[17:02] <kenvandine> so i assume it is building with 4.7
[17:02] <kenvandine> unless the package is overriding that
[17:02] <kenvandine> i actually know very little about the unity package
[17:03] <kenvandine> i mostly look after the rest of the stack :)
[17:03] <nmarques> kenvandine, sry :) I was used to speak to ya in the past... old habbits
[17:03] <kenvandine> no worries
[17:03] <kenvandine> i can always try to answer your questions
[17:03] <nmarques> none so far
[17:04] <nmarques> but I'm starting today to port stuff for the new namespace, X11:Unity
[17:04] <nmarques> and need to speak to GTK+ maintainer to see if we can slip the GTK+ patches in 12.2
[17:04] <kenvandine> export CC=gcc-4.6
[17:04] <kenvandine> export CXX=g++-4.6
[17:04] <kenvandine> just checked the debian/rules
[17:04] <nmarques> I know vincent didn't opposed to the widget grabbing patch
[17:04] <kenvandine> looks like the package is still using 4.6
[17:04] <nmarques> not sure about the menu-proxies, but since it's going to be dropped soon, thats a plus
[19:41] <antialias> hello?