[01:01] <Noskcaj> knome: Should we add something about python3 to the blueprint?
[01:02] <Noskcaj> And should we add something about whiskermenu?
[01:25] <micahg> yeah
[02:56] <Noskcaj> micahg: Is there anything i can do to help with the remaining uploads we need?
[02:58] <micahg> I think I'm ok with xfce4-panel now, will start on it in a little bit
[02:58] <Noskcaj> ok. 
[02:59] <Noskcaj> one other thing, what's the process for joining the ~xubuntu-dev team? 
[03:01] <micahg> just for bzr, familiarity with good branch practices and packaging
[06:41] <Noskcaj> My parents have decided that xubuntu is a bad influence on me, so i won't be able to do anything other than small amounts of irc for the next 24 hours. sorry
[07:30] <Unit193> Corsec pulled xfce4-whiskermenu-plugin in, for those of you that care.
[07:37] <Noskcaj> Unit193: fyi, i said that two days ago and Most of the work was one of the linux mint devs
[07:37] <Noskcaj> bluesabre: PING
[07:38] <Unit193> But it wasn't in NEW, so not in repo or anywhere close to installable. :)
[07:38] <Noskcaj> good point, it was just the svn that mati and i got it to.
[08:24] <lderan> good morning people :)
[09:03] <ochosi> Unit193: cool! that's good news, so we can basically sync that "for free"
[09:03] <Unit193> It'll autosync for Trixy Tiger.
[09:03] <ochosi> mm, yummy
[09:08] <slickymaster> morning all
[09:23] <bluesabre> anybody know what Noskcaj wanted from me?
[09:23] <ochosi> not really, maybe it was about python3?
[09:25] <bluesabre> or being on xubuntu-dev
[09:26]  * bluesabre needs to finish his developer application today
[09:26] <ochosi> mm
[09:28] <bluesabre> hm
[09:28] <bluesabre> patching light-locker for gdm, seems a bit redundant
[09:28] <bluesabre> ;)
[09:29] <ochosi> yeah, but that's for *bsd
[09:29] <ochosi> and they don't have the latest gdm i think, which includes the locking
[09:29] <bluesabre> ah, I see
[09:29] <ochosi> but we'll see whether that's gonna happne
[09:29] <ochosi> for now i love the screensaver-autolocking
[10:30] <brainwash> I still hate the vt switching =S
[10:34] <brainwash> ochosi: so I fixed the delayed kbsa (keyboard shortcut actions) on my test system by running a wrapper for xfsettingsd, it adds just a debug env var and redirects the error output
[10:35] <ochosi> i agree that the VT switching isn't ideal, but maybe that'll get less flickery with X/Mir
[10:35] <brainwash> maybe it's the minimal delay added by the wrapper
[10:36] <ochosi> weird, so why would you say does the wrapper work exactly?
[10:36] <brainwash> maybe it's just randomness, but both accounts work now
[10:36] <brainwash> I also did clear any session cache
[10:37] <brainwash> usually that did not help
[10:37] <ochosi> hm
[10:37] <ochosi> kinda odd still
[10:38] <brainwash> and I noticed that xfsettingsd gets started by the session manager, but there's also an activated autostart entry for it
[10:38] <brainwash> the autostart entry doesn't do much, because xfsettingsd is already running at this point
[10:40] <ochosi> hm, weird
[10:41] <ochosi> did removing it from there do any good?
[10:41] <brainwash> no, but leaving it and removing the session entry might
[10:42] <brainwash> if it really is some sort of race condition / process starting to earyl
[10:42] <brainwash> early
[10:43] <brainwash> I'll file a bug report today
[10:45] <brainwash> http://git.xfce.org/xfce/xfce4-settings/tree/xfsettingsd/xfsettingsd.desktop.in
[10:45] <brainwash> probably just a fall back solution, if xfce session is failing or not used at all
[10:49] <ochosi> mhm
[10:49] <ochosi> good work!
[10:49] <brainwash> and I noticed that users-admin triggers apport after you did create a new account and relog
[10:50] <brainwash> but that's a general ubuntu issue
[10:51] <brainwash> ochosi: still, I have no single log file which explains the strange xfsettingsd behavior 
[10:52] <brainwash> a glib critical can occur, but even when everything works fine
[11:08] <brainwash> if anyone wants to test the patch for bug 1232363 and none of the updated packages trigger a restart, simply run "sudo touch /run/reboot-required" and reopen update-manager
[11:25] <ochosi> brainwash: you could add that info to test the patch to the bugreport so others see it as well
[11:26] <ochosi> have you already thugged a dev bout itß
[11:26] <ochosi> ?
[11:28] <brainwash> yes, I've asked the dev who uploaded the last fix to update-manager, but he wasn't in the mood to write a patch, only told me that he gladly sponsor the upload
[11:29] <brainwash> the report is marked for the review team to test.. but who knows how long it will take
[11:33] <brainwash> but with the amount of kernel updates there shouldn't be any need to request a reboot manually :)
[11:48] <ochosi> hehe
[11:48] <ochosi> indeed
[11:49] <brainwash> xfce4-panel xcb io assertion fail on login
[11:50] <brainwash> apport redirects me to some ancient bug report
[11:52] <brainwash> I started to launch/test different applications (everything ubuntu related), and apport keeps bugging me
[11:55] <elfy> I've got a update-manager restart hanging around - I can test the patch later - but you'll need to run me through applying it - don't do it often and consequently forget each time
[11:57] <brainwash> elfy: cd /usr/lib/python3/dist-packages/UpdateManager && sudo patch < /path/to/patch
[12:02] <elfy> that's just hanging around - I'll see if it's still hanging around in a few hours when I get back :)
[12:03] <brainwash> you'll need to restart the update-manager
[12:14] <ochosi> ali1234, andrzejr: an update for the sound-indicator just came in that enables a "volume" action that does the same as scrolling but without showing a notification...
[12:15] <brainwash> notification popup?
[12:15] <brainwash> or tooltip
[12:16] <ochosi> notification
[12:16] <ochosi> afaik the indicators don't have tooltips
[12:17] <brainwash> xfce4-volumed is responsible for showing a notification when the volume changes
[12:18] <ochosi> i know
[12:19] <ochosi> but now there seems to be support for not showing a notification in the sound-indicator, so that could theoretically be used in the volumed
[12:19] <ochosi> haven't looked at the implementation yet though
[12:19] <ochosi> just thought i'd mention it since we had talked about it before
[12:19] <brainwash> the never-ending gtk2 indicator story =S
[12:20] <brainwash> or wait, are you talking about the gtk3 one?
[12:20] <ochosi> yup
[12:21] <ochosi> gtk2 is dead-dead-dead in terms of indicators as far as i am concerned
[12:27] <brainwash> wish I could help with the xfce gtk2 -> gtk3 transition and even wayland... but I have no clue about almost anything
[12:29] <brainwash> it would basically mean forking the project and start coding, experimenting,..
[12:30] <ochosi> not necessarily forking, cloning git and making your private branch is usually the first step
[12:30] <brainwash> yea
[12:30] <ochosi> then you can always push your stuff, as soon as you have working code, to e.g. github for others to try
[12:31] <brainwash> but it would be my way of doing things
[12:31] <brainwash> well, too much work anyway :P
[12:31] <ochosi> well usually people do things their way
[12:33] <brainwash> bug 1238635
[12:35] <brainwash> (just a random bug report)
[12:36] <ochosi> well it's actually quite an important one i'd say
[12:36] <ochosi> i've come across it several times, and it's true that it should be addressed
[12:36] <ochosi> and it shouldn't be too hard i guess, if you wanna give it a try ;)
[12:37] <brainwash> needs to be fixed upstream
[12:37] <ochosi> yeah, i meant you could try to compile thunar and fix the bug
[12:38] <ochosi> then attach a patch to bugzilla upstream
[12:39] <brainwash> if I run out tasks :)
[12:39] <brainwash> there's also the maximize button on dialog windows issue
[12:40] <brainwash> cosmetic one
[12:53] <ochosi> yeah, not sure about that bug tbh
[13:18] <GridCube> the ones under "saucy final" are the release candidates
[13:18] <GridCube> ?
[13:20] <jjfrv8> Don't know. I assumed they were but they seemed to be linked to the ones marked "daily".
[13:21] <jjfrv8> the 'final' ones don't have any previously reported bugs showing either, but the 'daily' ones do.
[13:24] <GridCube> mmhm
[13:27] <thad> ochosi: can you please test http://lpaste.net/94151
[13:32] <brainwash> ochosi: getting closer to a solution :)
[14:34] <brainwash> ochosi: so basically something fails when xfsettingsd daemonizes
[14:36] <brainwash> elfy: I recall that you also did confirm the initial ~10sec delay, please test http://lpaste.net/94151
[14:37] <brainwash> ochosi: looks like xfsettingsd and xfce4-appfinder share the same problem :)
[14:52] <ochosi> brainwash: that's both good and bad i suppose
[14:54] <brainwash> it explains, why we both are affected by the same issue
[14:55] <brainwash> if you are affected by one of them, you are also affected by the second one
[14:56] <ochosi> yup
[14:57] <brainwash> the question is still, why isn't it a general issue everyone can confirm :/
[14:58] <brainwash> my test system isn't an upgrade one, but a bloated one
[14:58] <ochosi> mine is an upgraded one
[14:58] <ochosi> so it's still possible that clean installs aren't affected (which would be good i suppose)
[14:58] <brainwash> but it's mainly only xubuntu or?
[14:59] <brainwash> which you've installed
[14:59] <brainwash> I installed every single DE afterwards
[15:00] <brainwash> do you plan do a fresh installation of xubuntu 13.10 (RC?) anytime soon?
[15:02] <ochosi> i only have xubuntu here, but it's polluted with quite a bit of git-compiled stuff
[15:03] <ochosi> so my system is just a little more reliable than an archbox in terms of bugreporting
[15:05] <brainwash> ok, I don't expect a patch anytime soon unless more people start to confirm the delay
[15:13] <skellat> Okay, it looks like we can add LP Bug #1232363 as a "Known Issue" that will be address after release according to the most recent comment from Brian Murray on it
[15:16] <ochosi> indeed
[15:16] <ochosi> well done brainwash ^
[15:17] <brainwash> mmh, why not before final release =S
[15:18] <ochosi> let's hope people won't do an upgrade in saucy before that ;)
[15:18] <brainwash> after release means, that everyone not downloading updates during installation will encounter a non working restart button once
[15:18] <ochosi> it's not such a big deal, only ppl who are currently testing saucy are really affected
[15:19] <ochosi> yeah true, but it could be worse
[15:19] <brainwash> and the people downloading the final iso?
[15:19] <brainwash> ye :)
[15:19] <ochosi> after all, it's getting fixed
[15:19] <ochosi> you oughta look at the bright side
[15:21] <brainwash> we have to reduce the amount of annoyances.. because the indicators already generate so much confusion :D
[15:28] <ochosi> a few days in, the focus will shift to 14.04 anyway, and it's much more important to get that one right
[15:30] <skellat> ochosi: As much as it is not good to say it...every release is indeed important but some releases are more special than others.
[15:34] <skellat> And LP Bug #1238718 is odd to see popping up **now**
[15:39] <jjfrv8> I did notice the inconsistency, but it was that way in the Raring docs so I let it go.
[15:41] <slickymaster> skellat, jjfrv8, I did file that bug after discussing it with knome 
[15:42] <skellat> slickymaster: That's likely going to be stuff for a Stable Release Update and not something we're going to get into the shipping image
[15:44] <slickymaster> skellat: yeah, I'm aware of that, but the way I see it at least it will be corrected for the LTS release
[15:44] <skellat> slickymaster: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001064.html
[15:45] <slickymaster> skellat: :) I've received that one, and knew about it
[15:46] <jjfrv8> We're probably going to be doing a major rewrite for T, eh, skellat?
[15:46] <slickymaster> skellat: I've already made all the corrections, are you implying not to push it?
[15:46] <skellat> slickymaster: Go ahead.  We'll have to prep it to be an SRU
[15:47] <slickymaster> skellat: okie dokie, thanks
[15:48]  * slickymaster hopes to have all the xubuntu-docs translated before the LTS release :P
[15:50] <skellat> jjfrv8: I'm still wondering what'll come up at the Ubuntu Documentation Project meeting.  Theoretically we should attend since Xubuntu Documentation is considered part.
[15:51] <jjfrv8> Right. I plan on attending.
[15:53] <skellat> jjfrv8: Do you want to set a time & date after the Ubuntu Documentation Project meeting to hold a Xubuntu Documentation meeting?
[15:53] <jjfrv8> Sounds like a good idea.
[15:54] <skellat> We'll have time before UDS to do so
[15:54] <jjfrv8> K
[15:56] <jjfrv8> We'll talk more after the Ubuntu meeting?  Gotta go for now.
[15:57] <skellat> jjfrv8: Bye
[16:07]  * skellat goes to lunch
[16:44] <elfy> brainwash: not getting that patch to work. and as far as "you also did confirm the initial ~10sec delay" I might have - but I'm not seeing it now
[16:44] <elfy> and it's pointless showing me code - it means absolutely nothing to me at all 
[16:58] <brainwash> elfy: you can edit the Dialogs.py and add the lines manually
[17:00] <brainwash> elfy: and an easy way to verify the 10sec delay is to run "xfsettingsd --replace" and hit some kb shortcuts like super-t
[17:01] <elfy> no delay 
[17:01] <elfy> as I said :)
[17:01] <brainwash> ok, great :)
[17:01] <elfy> and that has knackered xchat
[17:09] <ali1234> brainwash: what's this 10 seconds delay? this is with upstart?
[17:09] <ali1234> the new fixed version?
[17:10] <brainwash> no, xfsettingsd and xfce4-appfinder respond with a slight delay (10/5) to dbus messages after daemonizing
[17:11] <brainwash> hardly anyone can reproduce it
[17:11] <brainwash> not calling the daemonize function resolves it
[17:12] <ali1234> yeah i can't reproduce
[17:12] <ali1234> i'm not fully up to date tho, i'll try again in a bit
[17:12] <brainwash> the appfinder report is more than a year old
[17:13] <brainwash> starting with xfce 4.10
[17:14] <brainwash> nick already migrated the appfinder to gdbus communication upstream, which solved the issue for me
[17:15] <ali1234> can you have a look what is happening with dbus-monitor and/or dfeet?
[17:16] <ali1234> also maybe ~/.cache/upstart/dbus.log
[17:17] <ali1234> also, try making a fresh user profile and see if it still happens
[17:18] <brainwash> I'll try it again for xfsettingsd, the the daemonized appfinder process gets stuck at some point and therefore doesn't respond to dbus messages anymore
[17:18] <brainwash> it gets stuck loading icon theme files...
[17:18] <ali1234> is it possible you have some stale dbus sockets or something? like maybe because you ran dbus as root one time by accident
[17:18] <brainwash> maybe it's random
[17:19] <brainwash> in my home folder?
[17:19] <ali1234> yeah, perhaps
[17:19] <ali1234> or maybe /tmp
[17:19] <ali1234> but proably ~
[17:20] <brainwash> unlikely, /tmp gets cleaned on every reboot and I already tested with new user accounts, same result
[17:20] <ali1234> that's really weird
[17:20] <ochosi> yeah, i have the same issue
[17:20] <ochosi> but it more or less suddenly showed up
[17:20] <brainwash> can't reproduce it when booting the daily iso 
[17:20] <ali1234> uptime?
[17:21] <ochosi> although i can't say whether it showed up after upgrading to 13.10 or sometime running 13.10 upgrades
[17:21] <ali1234> i've seen where buggy apps spam dbus to the point where it crawls and/or crashes
[17:21] <brainwash> ochosi: run "xfsettingsd --replace" and hit some kb shortcuts
[17:21] <ochosi> yeah
[17:21] <brainwash> delayed?
[17:21] <ali1234> and by buggy apps i mean gnome system monitor, lol
[17:21] <ochosi> that makes things get stuck again
[17:22] <brainwash> afterwards "xfsettingsd --replace --no-daemon"
[17:22] <ochosi> yeah, it works as you suggested before
[17:23] <brainwash> it's like... we need to ask nick for help :)
[17:24] <brainwash> to explain this mystery
[17:25] <ochosi> who knows, maybe ali1234 has some tricks up his sleeve :>
[17:25] <ochosi> anyway, i have no idea how to debug this kinda dbus stuff
[17:25] <ali1234> check all the log files i mentioned, plus ~/.xsession-errors for anything even slightly related to dbus
[17:26] <ali1234> use dbus-monitor --session to watch dbus requests (very spammy though)
[17:26] <brainwash> already did
[17:26] <ali1234> use dfeet to see what is connected to the bus
[17:26] <brainwash> yea, d-feet for the xfsettingsd issue, I'll test that
[17:27] <ali1234> try to see at what point it joins the bus
[17:27] <ochosi> bbiab
[17:27] <ali1234> if all else fails get the source and fill it with printfs
[17:27] <ali1234> until you find the exact point where it is hanging
[17:27] <brainwash> yes, did exactly this for the appfinder
[17:28] <brainwash> and it gets stuck loading icon theme files
[17:28] <brainwash> doesn't make much sense
[17:28] <ali1234> are you both using the same theme by any chance?
[17:28] <ali1234> xfsettingsd is of course doing stuff with icon themes too...
[17:28] <ali1234> maybe there is a corrupt icon that stalls it
[17:29] <brainwash> but it works when not calling the daemonize function
[17:29] <brainwash> I should wash my brain and forget about this issue :)
[17:29] <ali1234> that could be just a side effect
[17:30] <brainwash> it's the default xubuntu icon theme
[17:30] <ali1234> "elementary Xfce"?
[17:31] <ochosi> hey – it's not my fault!
[17:31]  * ochosi hides
[17:31] <ochosi> but good idea to check whether it happens with other icon-themes too
[17:31] <brainwash> I'm pretty sure that I tried other themes too, but let me try again
[17:31] <ali1234> hmm i just noticed that when i run xfsettingsd --replace it does not background, ie it does not run as a daemon
[17:32] <brainwash> woooot
[17:32] <ali1234> wooot?
[17:32] <brainwash> it does not background?!
[17:32] <ali1234> yeah, weird huh?
[17:32] <ali1234> oh wait that's not true
[17:33] <ali1234> it outputs to the terminal still, but it is backgrounded
[17:33] <ochosi> other icon themes also don't work (just tested gnome)
[17:33] <ali1234> that's weird
[17:33] <brainwash> what did it output?
[17:33] <ali1234> a load of debugging messages
[17:33] <ali1234> TRACE[xfce-shortcuts-grabber.c:382] find_event_key(): Positive match for <Super>t
[17:33] <ali1234> and so on
[17:34] <brainwash> after pressing the key, right?
[17:34] <ali1234> i am using ubuntu-mono-light icon theme btw
[17:34] <ali1234> yes, after pressing the shortcut. there is loads more both before and after that
[17:34] <ali1234> couldn't reproduce with elementary xfce though
[17:34] <ali1234> maybe it is an icon for a program i don't have installed
[17:35] <elfy> I got the same outputs
[17:36] <ali1234> what about running it with strace -e file
[17:36] <elfy> and it's sent xchat back to 1999 again 
[17:38] <ali1234> strace -f -e file xfsettingsd --replace
[17:39] <ali1234> hmm interesting - i just ran it and i got a very short freeze - but the whole display froze for about 2 seconds
[17:40] <ali1234> you'll want the -r option on strace too to get timestamps
[17:59] <brainwash> ali1234: thanks for the valuable information, it will help a lot to find the cause of this faulty behavior
[18:10] <slickymaster> skellat, FYI -> https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/190739
[18:48] <knome> jjfrv8, from my point of view, we do not need a complete rewrite for T, we just need to make sure things are up-to-date
[19:56] <pjotr> Hello, I have a question about the merging of the translations. I noticed that the Dutch slideshow translation isn't in the daily build yet, although it has been completed some weeks ago....
[19:56] <pjotr> I mean the ubiquity slideshow
[19:57] <pjotr> for Xubuntu 13.10 Saucy
[19:58] <pjotr> knome: can you shed some light on this matter?
[20:22] <brainwash> ochosi: do you still have overlay scrollbars activated? need you to confirm something
[20:38] <brainwash> ochosi elfy ali1234: we have a winner, the overlay_scrollbar module is somehow causing the delay
[20:40] <elfy> which will be why I don't see it then 
[20:40] <brainwash> right, it explains a lot
[20:40] <brainwash> but still... What the heck?!
[20:40] <elfy> :)
[20:41] <brainwash> already filed bug 1236271
[20:41] <Unit193> Never used it.
[20:42] <brainwash> guess we should add it to the known issues list
[20:42] <brainwash> xubuntu not fully compatible with overlay scrollbar
[20:43] <elfy> ohhhh 
[20:43] <elfy> those fat arrow thingys that they use in ubuntu
[20:46] <brainwash> so it's time to get rid of this unity scrollbar invention
[20:47] <brainwash> ochosi: try LIBOVERLAY_SCROLLBAR=0 xfsettingsd --replace
[20:47] <brainwash> I assume you have them activated as well
[20:57] <ochosi> brainwash: i do have them active, yes
[20:58] <ochosi> and yes, deactivating them fixes the issue
[20:58]  * ochosi goes to purge the overlay-scrollbars
[20:58] <elfy> from the repositories ? 
[20:58] <elfy> :)
[20:58] <ochosi> if it were possible..
[20:58] <elfy> :)
[21:04] <ochosi> brainwash: another job well done, so the bug should be re-assigned to the silly overlay-scrollbars i guess
[21:06] <brainwash> yea.. uhm.. screw those scrollbars
[21:08] <brainwash> they glitch the theme, they prevent scrolling in gtk3 apps and they delay some xfce apps
[21:09] <elfy> good job we don't use them then :)
[21:09] <Unit193> Have xubuntu-desktop, or xfwm4 conflict with them. :----D
[21:09] <brainwash> ^ :D
[21:09] <ochosi> :}
[21:10] <brainwash> we could export the env var when logging into xubuntu
[21:11] <knome> pjotr, i will have to look at it.
[21:11] <brainwash> would that be a valid option? well, people would ask, why the overlay scrollbars are missing in xubuntu
[21:12] <brainwash> if they use unity side by side
[21:12] <Unit193> Eh, doesn't make things unusable or crash them, right?  Just a delay.
[21:13] <brainwash> the daemonized appfinder instance does get stuck
[21:13] <brainwash> zombie mode
[21:14] <brainwash> from now on appfinder starts delayed
[21:14] <brainwash> the new instances
[21:15] <brainwash> so, what about deactivating them?
[21:15] <pjotr> knome: thanks!
[21:15] <knome> brainwash, deactivating them would be an option.
[21:15] <brainwash> just like canonical disabled hibernate
[21:15] <knome> people can't expect us to work like unity, that's not our goal by any means anyway
[21:16] <brainwash> right
[21:16] <knome> and people should acknowledge that when told
[21:16] <knome> i don't think it's really a bug, it's just a differently working feature
[21:16] <elfy> that would certainly be my point of view
[21:17] <knome> by that argument people could start filing bugs like "xubuntu doesn't have left-hand panel" and expect us to think they are valid bugs
[21:17] <brainwash> it does cause faulty behavior
[21:17] <knome> which is?
[21:17] <brainwash> "they glitch the theme, they prevent scrolling in gtk3 apps and they delay some xfce apps"
[21:17] <knome> the overlay scrollbars?
[21:17] <brainwash> yes
[21:17] <brainwash> in saucy
[21:17] <knome> yeah, well then *having* them is the bug.
[21:18] <knome> getting rid of them is not a bug.
[21:18] <knome> even if that meant it was working a bit differently than in unity
[21:18] <brainwash> it should be added to the known issues list at least :)
[21:19] <knome> if there is an env var that can disable them, then we should look at using that
[21:19] <knome> that sounds fair
[21:19] <knome> feel free to link to http://pad.ubuntu.com/Xubuntu1310FinalRelease
[21:20] <knome> i mean, add a link to the bug in ...
[21:20] <knome> + people are still free to poke that document.
[21:20] <brainwash> yea, let me file a meta report first
[21:20] <knome> sure, thanks
[21:21] <brainwash> a "fix" can be shipped after release, if needed
[21:21] <elfy> knome: yep - I'll be on that pad in the next few days
[21:21] <knome> elfy, cheers :)
[21:22] <elfy> mostly bugs people might see during install/upgrade
[21:22] <knome> well...
[21:22] <knome> not necessarily
[21:22] <knome> just bugs that are going to be annoying
[21:22] <knome> including most visual bugs
[21:22] <knome> or bugs that make things lag
[21:23] <elfy> well ... 
[21:23] <elfy> I'd call a bug you might find during install annoying :)
[21:24] <knome> depends
[21:24] <knome> if it only happens at installation time, and isn't critical, meh
[21:25] <brainwash> does the pad save automatically or do you have to hit the save button all the time?
[21:25] <elfy> knome: okey doke
[21:25] <knome> brainwash, saves automatically
[21:25] <brainwash> ok
[21:26] <knome> elfy, but i don't mind if we list a dozen of bugs again, then pick the ones we think are worth mentioning
[21:26] <knome> elfy, and whatever pick i made is always debatable
[21:26] <elfy> I'd rather have them there and then we can remove - rather than each of us think oh that's not worth mentioning and finding it was 
[21:27] <elfy> lol 
[21:27] <knome> yep, that's good
[21:27] <knome> for pjotr (who left already) and others; slideshow translations are getting uploaded by stgraber
[21:31] <brainwash> add bug 1232363 too? it will get fixed after release
[21:31] <knome> will get fixed means what?
[21:31] <knome> do we have a working patch ready?
[21:32] <ochosi> yup
[21:32] <ochosi> brainwash did one
[21:32] <elfy> brainwash: add it to the pad please 
[21:32] <knome> brainwash, ochosi: would you like to beg at #ubuntu-release to get that fix sponsored/uploaded?
[21:32] <ochosi> someone already promised to SRU it
[21:33] <ochosi> (read the last comment)
[21:33] <ochosi> don't think we can get much more at this point...
[21:33] <knome> ok, that works for me.
[21:33] <knome> but yes, we should list that
[21:34] <brainwash> oh, the layout changed
[21:35] <brainwash> elfy: it's your bug report, so add it :P
[21:43] <elfy> ok - I'm off - cya when I cya 
[21:45] <knome> ok, ubiquity slideshow translations are uploaded and waiting to get in the images.
[21:52] <ochosi> brainwash: fwiw, i haven't seen the scrollbar problem again in firefox
[21:52] <ochosi> so it's possible i'll really flip the switch for 14.04 on that one
[21:52] <brainwash> ochosi: great news
[21:53] <brainwash> I switched to numix though =S
[21:53] <knome> ochosi, did you acknowledge we have https://blueprints.launchpad.net/ubuntu/+spec/topic-t-flavor-xubuntu with stuff on the whiteboard?
[21:53] <ochosi> brainwash: it's still one of our themes, so i don't mind ;)
[21:53] <ochosi> knome: i did, but haven't really had many new ideas yet
[21:54] <ochosi> the things i'm interested in are mostly there already (light-locker, mugshot, menulibre)
[21:54] <ochosi> also whiskermenu, gtk3-indicators and xubuntu-core metapackage
[21:56] <ochosi> ok, just added one item
[21:56] <knome> ugh
[21:56] <knome> there was an editing conflict
[21:56] <knome> shite :P
[21:56] <ochosi> hehe
[21:56] <ochosi> not for me i think :)
[21:56] <knome> well there was
[21:56] <knome> LP just doesn't notify about that
[21:56] <ochosi> my line is shown in my ff though
[21:56] <knome> yeah
[21:56] <knome> but meanwhile, i had done other updates
[21:57] <knome> and those are lost
[21:57] <knome> :P
[21:57] <knome> i'll poke that a bit
[21:57] <knome> dirty hands off!
[21:57] <ochosi> whoopsie :)
[21:58] <knome> that's okay, they were mostly formatting stuff
[21:59] <knome> we should separate the *discussion* from that to wiki or pad
[21:59] <Unit193> Heh, I don't really care about Whiskermenu, or else I'd use that mintmenu or KDE kickoff crap. :D
[22:00] <ochosi> Unit193: it's a nice alternative to appfinder if you bind it to a kb-shortcut
[22:00] <ochosi> i used it for a while to launch apps
[22:01] <ochosi> but yeah, it's not as clever as appfinder (no custom command system etc)
[22:01] <brainwash> ochosi: we don't have a gtk3 indicator (meta) bug report yet, or?
[22:01] <ochosi> possible that we don't
[22:01] <brainwash> only the soundindicator one
[22:02] <ochosi> yup
[22:03] <brainwash> yet another report I need to file :)
[22:08] <Unit193> knome: You can assign the core meta more or less to me since I'm already creating it. :P
[22:10] <Unit193> Or better yet, assign to someone else and I slip the information to them. :D
[22:11] <knome> Unit193, lol, assigning you.
[22:12] <knome> Unit193, do you think you can slip that kind of stuff without having to face the consequences? ;)
[22:13] <Unit193> I liked the second option better. :(
[22:14] <knome> nah. just ask for help if you need it.
[22:18] <skellat> Do I dare ask how we're doing with the sound/volume issue at this point?  Will we be shipping with working "conventional" sound controls or is that gonna be a Known Issue?
[22:26] <Noskcaj> bluesabre: It was about python3. Should we really be adding extra programs to the seed that aren't yet python3? I can help with converting them if you want
[22:27] <Noskcaj> And if you're trying to get added to xubuntu-dev i'd like to see what you had to do so i can get added in a few months
[22:35] <knome> instead of poking the LP blueprint, please poke: https://wiki.ubuntu.com/Xubuntu/Roadmap/Goals/T
[22:35] <knome> i'm going to more or less  have the edit lock in the next 15mins.
[22:39] <Noskcaj> knome: Do you think we are still going to try and get python3 only for 14.04?
[22:41] <knome> if it's not too much work, and if the things are convertable
[22:44] <Noskcaj> https://bugs.launchpad.net/bugs/1238997 just appeared
[22:44] <Noskcaj> Isn't that slightly reduntant
[22:44] <brainwash> Surprise!
[22:44] <brainwash> does another report already exist?
[22:45] <knome> i don't think there is a bug filed about that.
[22:45] <knome> the previous B/FFe was handled in -release ML
[22:47] <knome> ok, i'm done with the wikipage for now
[22:47] <knome> wait
[22:47] <knome> i'm not
[22:47] <knome> 1min
[22:53] <knome> done.
[23:00] <ochosi> brainwash: there is a tiny bug in xfwm4-settings currently – the checkbox for vsync doesn't seem to be hooked up to xfconf correctly (if you're looking for low-hanging fruit to dive into code a little)
[23:04] <brainwash> ochosi: how can this even happen? :P
[23:04] <ochosi> no clue
[23:04] <ochosi> but that seems to be the case in 4.11 (haven't checked whether it's fixed in git-master already)
[23:06] <bluesabre> Noskcaj: I've been developing my applications to work with python 2 or 3, so we can flip the switch for catfish and mugshot at any time
[23:06] <bluesabre> I think one of the big things is still gimp
[23:06] <Unit193> bluesabre: Nice, good forward thinking.  2to3?
[23:07] <bluesabre> nope, careful programming and if statements for python version
[23:07] <Noskcaj> bluesabre: It might be worth making them all python 3 by default at the next upload. gimp is python?
[23:08] <bluesabre> several of gimp's plugins are
[23:08] <Noskcaj> oh yeah, i think most of them are done though. I was looking at the gnome bug tracker and i think the last few just got fixed
[23:08] <knome> maybe it's worth seeing if the gimp core can run with 3, and see what's missing, and if that's reasonable
[23:09] <bluesabre> oh sweet
[23:10] <Unit193> knome: Run 2to3! :D
[23:10] <Unit193> Still gtk2 of course.
[23:13] <Noskcaj> Speeking of gtk2 and python3, is there anyone who has time to help with porting testdrive to gtk3 and python3? I lack the skills and no one else has the time
[23:14] <knome> off for today, see you all later (and nighty!)
[23:15] <bluesabre> Noskcaj: I've got the skills, and perhaps some time
[23:15] <bluesabre> all of my apps are a lot more stable than when I started :)
[23:16] <Noskcaj> bluesabre: yay. If you want to help, the code, along with dan and my attempts, are at code.launchpad.net/testdrive
[23:16] <bluesabre> k
[23:17] <bluesabre> wha
[23:17] <bluesabre> how do some of those files have a revision with a decimal point?
[23:18] <Noskcaj> bluesabre: I think it's from merges