[09:01] <Laney> helloooooooooooooooooooooooooo
[09:02] <seb128> goooood morning desktopers!
[09:02] <seb128> back to work today
[09:02] <seb128> happy new year ;-)
[09:05] <didrocks> work day 3 but IRC day 1 here! :)
[09:05] <didrocks> happy new year ;)
[09:05] <Laney> TSK
[09:06] <didrocks> Laney: was able to do 2x12h of coding on Thursday and Friday. No email reading, no IRC were really helping
[09:06] <seb128> didrocks, haha, nice try, you were not on IRC, you didn't work :p
[09:06] <didrocks> and I have 700 lines of code to prove it! :)
[09:06] <didrocks> and commits!
[09:06] <Laney> haha
[09:06] <didrocks> https://code.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk
[09:06]  * seb128 has been working for 3 weeks, just not been on IRC, can I reclaim those vac days? ;-)
[09:06] <Laney> he's been working on his tan
[09:06] <Laney> don't believe the lies jason!
[09:07] <didrocks> ahah :)
[09:09] <seb128> impressive number of uploads during the holidays with those dh-autoreconf changes
[09:10] <seb128> I hope those get to debian/upstream so we don't keep a diff for all those sources
[09:10] <didrocks> ogra_: Monday and trolling? :)
[09:10] <didrocks> happy new year
[09:10] <Laney> I've been committingn those I can to Debian
[09:11] <seb128> great
[09:11] <Laney> but they aren't usually forwarded from what I can see, which I can kind of understand
[09:12] <seb128> right
[09:12] <seb128> well in theory they are only needed until upstream gets proper support and tarball got rolled with that version
[09:13] <seb128> so those diff should go away over time in any case
[09:14] <Laney> I think there's a libtool fix which isn't in a released version yet
[09:15] <seb128> k
[09:15] <Laney> but yeah, in enough time
[09:15] <seb128> right
[09:15] <seb128> looks like today is going to be spent in my email client
[09:15] <seb128> dealing with email after holidays is always fun :p
[09:16] <seb128> (I did some on friday but stopped when I started being annoyed by people sneaking in GNOME 3.10 updates while we were not working)
[09:17] <larsu> seb128: Ctrl+A Del :P
[09:17] <seb128> larsu, that's what you did, right? ;-)
[09:18] <larsu> seb128: no, I was only off for a couple of days ;)
[09:18]  * larsu always reads all of his email
[09:18] <seb128> jaja
[09:18] <larsu> *cough* *cough*
[09:18] <seb128> lol
[09:19] <mlankhorst> Happy newyear for those I missed. :P
[09:19] <mlankhorst> I'll try to hit harder next time
[09:20] <seb128> happy new year mlankhorst!
[09:28] <xnox> seb128: if upstreams roll tarball on debian-sid or ubuntu-trusty, then it's golden.
[09:31] <seb128> xnox, great ;-)
[14:04] <mpt> larsu, do you have any objection to my proposal in bug 1108765?
[14:04] <ubot2> Launchpad bug 1108765 in indicator-datetime (Ubuntu) "Locations in the menu updating every second is distracting" [Undecided,New] https://launchpad.net/bugs/1108765
[14:07] <larsu> mpt: I didn't even know we showed seconds in the menu. I'm definitely in favor for this. Thanks for filing the bug!
[14:07]  * larsu confirms and assigns to charles_ :)
[14:10] <seb128> larsu, would you have any idea about https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1262801 by any chance?
[14:10] <ubot2> Launchpad bug 1262801 in eog (Ubuntu) "eog hangs when the print dialog is closed" [Undecided,New]
[14:10] <seb128> basically
[14:10] <seb128> - open an image in eog
[14:10] <seb128> - open the print dialog using the unity appmenu
[14:10] <seb128> - close the dialog
[14:10] <seb128> -> hangs
[14:11] <seb128> it only happens with appmenu (e.g if you UBUNTU_MENUPROXY= eog it doesn't hang)
[14:12] <larsu> seb128: no idea what that could be, but I can have a look right now :)
[14:12] <seb128> larsu, danke
[14:12] <larsu> happens for me as well, so that's good
[14:13]  * larsu suspects recursive mainloop madness. Might be one for desrt_ 
[14:13] <desrt_> >:|
[14:13] <desrt_> hi everyone!
[14:13] <seb128> desrt, hey, happy new year!
[14:14] <desrt> seb128: did you see santa?
[14:15] <seb128> desrt, no, he came while I was sleeping :/ He left some present though ;-)
[14:15] <seb128> desrt, how are you? did you have good holidays/start of year?
[14:15] <desrt> more or less
[14:15] <desrt> typical :)
[14:16] <seb128> now to loose those extra kgs from the extra food :p
[14:16]  * desrt is actually doing surprisingly OK on that front... only 1 or 2
[14:20] <seb128> larsu, hum, another GTK 3.10 issue, https://bugzilla.gnome.org/show_bug.cgi?id=720750
[14:20] <ubot2> Gnome bug 720750 in general "DnD no longer shows the object being dragged" [Normal,Unconfirmed]
[14:21] <larsu> seb128: :(
[14:26] <seb128> larsu, of course that's a theme issue, wouldn't be fun otherwise :/
[14:28]  * larsu cries
[14:29] <seb128> :-(
[14:29] <seb128> larsu, I guess it's another bg color issue
[14:51] <larsu> seb128: hm, the same happens when activating "save as…" and dismissing it
[14:51] <larsu> but not for open…
[14:53] <seb128> larsu, weird
[14:55] <larsu> desrt: looks like I really do need your help on this
[14:55] <larsu> let me know when you have a minute
[14:58] <desrt> i am here
[15:00] <desrt> larsu: what's up?
[15:00] <larsu> ah great
[15:01] <larsu> so I have a main thread waiting in gdk_threads_dispatch
[15:01] <larsu> and another one blocking on come cond
[15:01] <larsu> and I have no clue on how I start debugging this :)
[15:01] <larsu> short of understanding eog's job model
[15:01] <desrt> sounds like a lock inversion
[15:02] <desrt> easiest way forward; get eog off of the gdkthreads crack
[15:02] <larsu> gdk_threads_dispatch is called form gtk
[15:04] <desrt> you'd only be deadlocking there if gdk threads are enabld
[15:07] <larsu> indeed
[15:07] <larsu> I'm guessing removing gdk_threads_init() is not all there is to making this work, eg?
[15:07] <larsu> *eh
[15:23] <desrt> larsu: make sure other things aren't trying to access gtk from a thread and convert them to using idles
[15:24] <desrt> larsu: problem is: plugins....
[15:24] <larsu> are they run in separate threads?
[15:24] <larsu> or they might assume that thread_init() was called...
[15:25] <larsu> the only reference I found to gdk_thread_* is gdk_thread_add_idle_full(), which should be quite easy to convert...
[15:37] <desrt> larsu: the latter
[15:38] <desrt> larsu: talk to some eog maintainers... they might know more about why they have this
[17:06] <kenvandine> whew... temp is dropping fast here!
[17:06] <kenvandine> during my 30 minute run, the temp dropped 8 degrees
[17:07] <larsu> kenvandine: 8 °F?
[17:07] <larsu> that's not that much, is it?
[17:07] <kenvandine> larsu, yeah...
[17:08] <kenvandine> it's going to drop another 30 degrees in the next few hours
[17:08] <larsu> ugh
[17:08] <larsu> wow
[17:08] <kenvandine> gonna be cold tonight!
[17:08] <kenvandine> high of 53 and low of 9 today
[17:08] <kenvandine> the high was in the morning
[17:09] <kenvandine> had to get out for some exercise before it got to cold
[17:09] <kenvandine> is anyone else getting bit by the libtool-bin split?
[17:10] <kenvandine> libaccounts-glib now ftbfs because of missing libtool
[17:33] <ritz> Sweetshark, hi, https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1200277
[17:33] <ubot2> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Undecided,New]
[17:34] <ritz> any thoughts ?
[17:34] <davmor2> rickspencer3: when does raring eol?
[17:34] <ritz> will be filing an SRU on this
[17:34] <rickspencer3> hi davmor2 not sure, exactly, I guess 9 months after we released it ;)
[17:35] <ogra_> i think raring was special in that regard
[17:36] <ogra_> (ask #ubuntu-release though)
[17:36] <davmor2> rickspencer3: Thanks, I'm guessing towards the end of the month then in that case, 1 less job for me woohoo!
[17:36] <ogra_> since we dont support quantal->trusty
[17:36] <ogra_> (without raring in the middle ... and quantal still has a while)
[17:37] <davmor2> ogra_: Quantal EOL on 14.04 release if iirc
[17:37] <ogra_> well, ask the release team, i just remember there was something special to work around the overlap
[17:37] <davmor2> which will drop me from 4 supported releases to 2
[17:38] <ogra_> since we have one release thats longer supported than the next non LTS ...
[17:41] <bschaefer> attente, hey
[17:41] <attente> bschaefer, hey
[17:42] <bschaefer> attente, so, if one wanted to patch gnome-setting-daemon to fix this bug: https://bugs.launchpad.net/unity/+bug/830709
[17:42] <ubot2> Launchpad bug 830709 in unity (Ubuntu) "Keyboard shortcut - Unity should also use Super-L to lock screen by default" [Low,Triaged]
[17:42] <bschaefer> attente, as i don't see a debian folder in the lp branch for gsd
[17:43] <attente> bschaefer, which branch are you looking at?
[17:43] <bschaefer> lp:gnome-setting-daemon
[17:43] <attente> this is the old packaging branch i think: lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu
[17:43] <bschaefer> attente, i figured there could be a more recent one somewhere else, apt-get source has all the patches
[17:44] <bschaefer> o cool
[17:44] <Laney> old?
[17:44]  * bschaefer looks
[17:44] <attente> Laney, are we forking g-s-d too?
[17:44] <attente> or is it just g-c-c?
[17:45] <Laney> sure, but it's still not old until that happens
[17:45] <Laney> i don't know of any work on g-s-d yet though
[17:46] <attente> oh ok, i thought robert ancell already started it https://code.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/unity
[17:46] <bschaefer> attente, thanks, as i have a diff from the lp:g-s-d, but I should test its working :)
[17:47] <attente> bschaefer, you just wanted to change the default key binding for lock screen?
[17:47] <bschaefer> attente, yup
[17:47] <Laney> mmm, very minimally
[17:47] <bschaefer> from Ctrl+Alt+L -> Super+L
[17:47] <Laney> anyway, that other one is the one for now
[17:47] <bschaefer> just an xml change
[18:08] <Sweetshark> ritz: on my todo list already, but low prio. self-assigning now in lp though ...
[18:09] <ritz> Sweetshark, thank you . Will this look fine for q ?
[18:09] <ritz> creating patch for p
[18:25] <bschaefer> attente, hey, so should i purpose a branch to lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu with this patch? http://paste.ubuntu.com/6704534/
[18:26] <bschaefer> attente, o yeah, how was that compiz stuff you were working on going?
[18:26] <attente> bschaefer, it's a bit buggy, but usable so far
[18:27] <bschaefer> awesome! Sorry, got really busy before the break and couldnt look much at it
[18:28] <attente> bschaefer, no worries :)
[18:30] <attente> bschaefer, oh, are you aware of a bug with xchat and ibus? running xchat maximized makes the candidate window appear off-screen when typing
[18:30] <bschaefer> attente, well thats really the placement of the preedit window
[18:30] <bschaefer> its even worse with XIM
[18:31] <bschaefer> attente, and no im not atm :)
[18:31] <attente> bschaefer, oh ok
[18:31] <bschaefer> but, IIRC...that wasn't an issue with 1.4?
[18:31] <attente> it was pointed out to me, and it seemed weird because other applications place it properly
[18:31] <popey> Hmm. Would I be right in saying a typical desktop application should have a line in the .desktop file which says "Exec=/path/to/executable" and not "Exec=executable" ?
[18:31] <bschaefer> attente, strange, so its only happening with xchat?
[18:31] <attente> bschaefer, i'm not really sure
[18:31] <bschaefer> yeah
[18:32] <popey> seems inconsistent, some do, some don't
[18:32] <bschaefer> attente, well it'll happen with the gnome-terminal as well if your input is at the bottom of the screen
[18:32] <bschaefer> as it just places the preedit box under the text entry
[18:32]  * bschaefer tests out some more things
[18:33] <attente> i've tried it out with gedit (shifted down) and firefox
[18:33] <attente> those seem fine
[18:33] <bschaefer> attente, yeah you're right! Very strange...
[18:33] <bschaefer> it seems to not detect its off the screen for xchat?
[18:34] <attente> bschaefer, i'm not sure
[18:34] <bschaefer> yeah neither am i :), something is a mist though
[18:34] <bschaefer> a mis*?
[18:34] <attente> bschaefer, ok, you're right, gnome-terminal is also doing that too, heh
[18:35] <attente> amiss?
[18:35] <attente> :P
[18:35] <bschaefer> haha
[18:35] <bschaefer> yeah
[18:35] <bschaefer> i've never actually typed that word out before
[18:38] <attente> bschaefer, the patch looks godo
[18:38] <attente> *good
[18:38] <bschaefer> attente, cool, ill purpose a branch. Thanks for looking at it!
[18:39] <attente> hope nobody gets too annoyed at ctrl+alt+l no longer working...
[18:39] <bschaefer> yeeah...thats going to be umm intersting
[18:39] <bschaefer> interesting*
[18:47] <bschaefer> attente, also, shouldn't there be a way to only make sure this gets patched for the unity env?
[18:47]  * bschaefer doesn't want to change other ubuntu envs with this
[18:49] <attente> bschaefer, i'm not sure you can without making a new key-value pair in the schema...
[18:50] <bschaefer> attente, im re-reading this bug now...and the title vs the description are a bit different one sec
[18:50] <bschaefer> Super-L should be added to (not replace) the existing keybinding by default.
[18:50] <bschaefer> soo i think my patch is an error :)
[18:50] <attente> oh.
[18:50] <attente> is Super-L configurable?
[18:51] <attente> i guess you could just add a new CompOption to unity
[18:51] <bschaefer> well from what im reading, its saying it wants Super+L to lock the screen as well as Ctrl+Alt+L?
[18:51] <bschaefer> yeah i could
[18:53] <bschaefer> attente, im moving that branch to a WIP, or possibly rejected as I don't want to replace that ctrl+alt+l option
[18:53] <attente> bschaefer, ok
[19:10] <doko> cyphermox, I did "inherit" your network-manager-applet merge ...
[19:32] <cyphermox> doko what merge, there shouldn't be a merge...
[19:34] <doko> cyphermox, then maybe keep the debian version number, so that mom doesn't present a merge?
[19:34] <doko> mom wants to merge ...
[19:35] <cyphermox> well, a merge is *eventually* going to have to be done, and if you want to do it, by all means, but it's still going to be a rather painful process I don't want to inflict on other people ;)
[19:35] <doko> then just claim it =)
[19:35] <cyphermox> sure, will start it nao :)
[19:37] <cyphermox> I'll take the n-m-pptp one as well,
[19:49] <bschaefer> attente, you're suggestion works very well :), could you reject my patch branch?
[19:49] <bschaefer> i can only seem to move it to wip, needs review
[19:50] <attente> bschaefer, sure
[19:50] <bschaefer> attente, thanks!
[19:52] <attente> bschaefer, hrm. i guess i can't change it either...
[19:53] <bschaefer> attente, o well, it will stay there forever!
[19:53]  * bschaefer makes a comment on the branch
[19:53] <attente> bschaefer, *shrug*
[19:53] <bschaefer> attente, yeah no worries, just figured would be best to reject it if possible :)