[20:00] <skellat> belkinsa, jrgifford__, Unit193: ¡PING!
[20:00] <jrgifford__> Pong
[20:00] <skellat> jrgifford__: Did you read the e-mail about hosting from jacob?
[20:01] <jrgifford__> I did.
[20:01] <jrgifford__> Not in depth though
[20:02] <skellat> Pending the announcement that Councilor Rubianes is sitting on which will lead to major reorganization, I want to just hoover up the binary data from the site and switch over to a re-direct to the wiki for the moment
[20:03] <skellat> I have no familiarity with MySQL to speak of, though, to do that
[20:04] <skellat> I vaguely remember that file attachments (the old audio podcasts) are all stored as files in a single directory and not in a database table so a straight scp might work there
[20:04] <jrgifford__> Ok.
[20:04] <skellat> Beyond that, I'm not sure what else we would need to retrieve for safe-keeping from the old Drupal
[20:04] <jrgifford__> Remind me later this week to figure it out.
[20:05] <skellat> I'll probably write up an e-mail to all three of you discussing intentions
[20:05] <skellat> Especially the stuff I can't openly say in a logged channel as Councilor Rubianes is stalling writing a blogpost
[20:25] <jacob> skellat: I can zip up mysql dumps & site content, if it helps.
[20:26] <skellat> jacob: I'm copying you on the e-mail that's being written up that's explaining some of my intentions :-)  Gimme a couple moments to finish it up
[20:26] <jacob> cool cool
[20:27] <skellat> jacob: Sent.  Now you can see what's cooking backstage.  I do want to wait for input from the other three.
[20:29] <jacob> sounds good. i'll read up more later and throw in some technical comments as necessary
[20:38] <skellat> Thank you jacob
[23:25]  * Unit193 ponders if he was supposed to pong.
[23:48] <belkinsa> skellat, jrgifford__, Unit193: I replied to the e-mail, hopefully what I said about the planet makes sense.
[23:50] <Unit193> Worst part about a redirect, when was the last time you visited the wiki without thinking "Man this is slow..."
[23:51] <belkinsa> Well, to edit and save changes, yes, but NOT to view.
[23:51] <Unit193> View too.
[23:52]  * belkinsa never had that much issue
[23:54] <Unit193> As far as editing, you're doing good to even login.  I've had to get someone else to edit it before because I couldn't even log in (and he leaves it logged in for precisely that reason). :D
[23:54] <Unit193> Anywho, time to go back.
[23:54] <belkinsa> I'm always logged in.
[23:54] <belkinsa> See ya Unit193.
[23:57] <belkinsa> skellat, Unit193, jrgifford__: Okay, I grabbed what I needed from the web site and stuck it on the wiki.  (wan't anything that I needed, really)


[00:00] <ochosi> knome: we should discuss the light-locker default settings i think
[00:00] <ochosi> currently the timeout for the screensaver is 10mins, and after that, light-locker locks
[00:00] <ochosi> that might be considered too short or inconvenient
[00:08] <brainwash> should locking be enabled by default?
[00:09] <brainwash> does xscreensaver automatically lock with default settings?
[00:10] <knome> ochosi, i think something like 15-20min is sane
[00:10] <knome> ochosi, i guess locking is turned on when you have fullscreen stuff open?
[00:10] <knome> ochosi, also, is there an easy way to temporarily turn that off? (or just l-l-s)
[00:11] <ochosi> just l-l-s i guess
[00:11] <ochosi> not sure the screensaving-inhibition works currently with parole
[00:11] <ochosi> haven't tested tbh
[00:12] <knome> bluesabre,
[00:19] <bluesabre> knome,
[00:19] <bluesabre> ochosi: it should work
[00:20] <ochosi> yeah, haven't tested :)
[00:20] <ochosi> but i'll test now
[00:23] <jjfrv8> knome, I was going to mark menulibre done. bluesabre did the upstream docs and I added the paragraph to settings-preferences
[00:23] <ochosi> bluesabre: didn't work right now
[00:23] <jjfrv8> knome, unless you were thinking we needed more
[00:24] <knome> jjfrv8, ok, cool. feel free to mark it done, just checking if there's something you think needs more work
[00:25] <jjfrv8> I didn't think so
[00:33] <bluesabre> ochosi: huh
[00:33] <bluesabre> well, thats odd
[00:33] <ochosi> in case that's any consolation, even vlc fails at that
[00:36] <bluesabre> and you were playing a video, right?
[00:38] <ochosi> yup
[00:38] <bluesabre> laaaaame
[00:38] <bluesabre> I'll experiment with it
[00:39] <ochosi> heh, yeah, i totally second that ("laaaame")
[00:48] <jjfrv8> knome, I pulled the latest version of docs and when I run 'make' I get a bunch of errors: http://paste.ubuntu.com/7076726/
[00:48] <jjfrv8> any significance to that?
[00:49] <Unit193> Well.
[00:49] <Unit193> jjfrv8: Precise?
[00:49] <jjfrv8> affirmative
[00:50] <Unit193> basename --help 2>&1 | pastebinit
[00:50] <Unit193> http://paste.openstack.org/show/JZCkRK72KUyYG7GOkZmN <--- That's standard.
[00:52] <Unit193> 8.17 (2012-05-10) required.
[00:52] <Unit193> !info coreutils precise
[01:06] <Unit193> jjfrv8: Err, same ones?
[01:08] <jjfrv8> looks like it
[01:08] <Unit193> pwd ?  And where are you running make?
[01:08] <slickymaster> Unit193: this is the error I get building th docs.I'm getting a permission error when it attempts to run the translate script -> Unit193 http://pastebin.com/Vx1aV7km
[01:08] <knome> !team | note that we have a meeting exceptionally *tomorrow*, on wednesday, at 19utc
[01:09] <Unit193> slickymaster: Looks like it's not set executable.
[01:09] <slickymaster> most probably I won't be able to make knome. I have to go up north to fix a server
[01:10] <Unit193> Oh wait.
[01:11] <knome> slickymaster, no problem. just pinging that you don't just "forget"
[01:11] <slickymaster> I'll get the backlogs by the time I get home
[01:11] <knome> yep
[01:11] <Unit193> slickymaster: Pulled from head and it's working here.   bzr status  ?
[01:11] <knome> doesn't look like we have anything too important
[01:12] <knome> UIF on thursday, so last check-up
[01:13] <jjfrv8> Unit193, it says desktop-guide/po/LINGUAS is modified
[01:13] <Unit193> That's fine.
[01:13] <jjfrv8> bzr status, that is
[01:14] <Unit193> `make` should work if you have that file.
[01:14] <Unit193> Ah, nope.  I see it.
[01:14] <slickymaster> Unit193: also pulled from head. bzr status -> http://pastebin.com/td7e4WRP
[01:15] <Unit193> knome: So yes, can't exactly build properly on precise.
[01:15] <Unit193> slickymaster: bzr revert scripts/ debian/
[01:15] <knome> Unit193, you mean, can't precisely build on precise?
[01:16] <Unit193> knome: Exactly!  Added the dep in debian/control: coreutils (>= 8.20-3ubuntu1)
[01:16] <Unit193> (17 is required, but jumps from 13 -> 20)
[01:16] <slickymaster> bah Unit193, already had rm -r xubuntu-docs/
[01:16] <ochosi> sergio-br2: i think as long as we don't add new icons, but only new sizes of existing icons, it's no problem to update the theme even after UIF
[01:16] <ochosi> sergio-br2: so if you wanna work on that, go ahead!
[01:16] <Unit193> slickymaster: It's showing chmods on the scripts  ls -lh scripts/  to see what I mean.
[01:17] <sergio-br2> ok, thanks
[01:18] <slickymaster> going to pull knome's revision 139
[01:19] <Unit193> jjfrv8: So yes, back to too old version of basename, you can either ignore those errors or pull the one from saucy (should cause no issues.)
[01:20] <jjfrv8> ok, I was going to ask if I could ignore. It doesn't interfere with what I want to see but I wanted to make sure I wouldn't corrupt things when I pushed.
[01:20] <Unit193> jjfrv8: Translations won't work.
[01:21] <Unit193> Speaking of which, fi and pt have validation errors. :)
[01:21] <Unit193> settings-preferences.xml:294: element guimenuitem: validity error : Element guiicon is not declared in guimenuitem list of po
[01:21] <Unit193> ssible children
[01:21] <Unit193> 7 in each.
[01:21] <knome> hr hr.
[01:21] <knome> i noticed that
[01:21] <knome> but thought i'd push anyway
[01:21] <knome> and wonder about that later.
[01:22] <knome> lderan, you might want to update https://wiki.ubuntu.com/meetingology#Meeting_minutes with #done
[01:25] <Unit193> slickymaster: Got yours fixed?
[01:26] <slickymaster> going to check U
[01:26] <slickymaster> going to check Unit193
[01:27] <Unit193> (FWIW: http://git.savannah.gnu.org/cgit/coreutils.git/tree/NEWS#n562 )
[01:27] <Unit193> .16
[01:28] <Unit193> knome: It builds in a clean saucy chroot.
[01:28] <knome> aha.
[01:28] <knome> why would i need one?
[01:29] <Unit193> (It means it's not just my system it works on, just broken in precise)
[01:29] <knome> :P
[01:29] <knome> yep, understood that
[01:29] <knome> not worried about it
[01:29] <knome> we aren't porting that to precise :P
[01:29] <Unit193> Exactly.
[01:29] <knome> anyway, i'm off for now
[01:30] <knome> will be back later
[01:30] <knome> have fun!
[01:30] <Unit193> Thus, I'd think his best bet is to ignore or get the saucy coreutils.
[01:30] <Unit193> OK, adios.
[01:30] <knome> yep.
[01:30] <knome> or run it in a vbox.
[01:30] <knome> ->
[01:30] <Unit193> s/vbox/chroot/
[01:31] <jjfrv8> can I just ignore, pretty please?
[01:31] <Unit193> jjfrv8: It should be alright to ignore, yeah.  Just don't break translations. :P
[01:32] <jjfrv8> well, if there's a danger of that, then I'd better get it from saucy
[01:32] <Unit193> knome: In case I didn't say, thanks for the merges.
[01:32] <Unit193> I think you should be safe, yeah.
[01:33] <slickymaster> Unit193: are you referring to this paragraph -> xfwm themes - control how your window borders look. To change your xfwm theme, go to <application><menuchoice><placeholder-1/><guimenuitem>Settings Manager</guimenuitem><guimenuitem>Window Manager</guimenuitem></menuchoice></application>. In the <guilabel>Style</guilabel> tab, select a new theme to change the window borders appearance.
[01:37] <Unit193> If that's one of the lines breaking it. :P
[01:39] <slickymaster> that one is settings-preferences.xml:94
[01:40] <slickymaster> but in that paragraph there's no 'Element guiicon'
[01:40] <slickymaster> I'm confused :P
[01:41] <Unit193> slickymaster: No, look at the po file.
[01:47] <slickymaster> Unit193: I haven't found settings-preferences.xml:294 in po file, also
[01:49] <slickymaster> wait, I'm looking at the wrong version of the docs
[01:51] <slickymaster> Unit193: are you sure it's settings-preferences.xml:294 ?
[01:52] <Unit193> http://paste.openstack.org/show/tLdVNGxSWvkwH4neLpvx
[01:52] <Unit193> slickymaster: It's in the po, not the actual xml file.
[01:54] <slickymaster> I've just downloaded the po file from LP and settings-preferences.xml: ends at 138
[01:54] <slickymaster> Unit193: yes, and I've been referring to the po all the time
[01:55] <slickymaster> thing is I'm not getting any line settings-preferences.xml:294 in the po file
[01:55] <Unit193> slickymaster: Right, it merges into an xml file, so it's not going to be exactly there, unless you merge it in too.
[01:56] <slickymaster> besides that soltution, can you think of anything else to catch those errors?
[01:57] <slickymaster> s/soltution/solution
[01:59] <Unit193> Normally grep, but I don't see it.
[01:59] <slickymaster> bah, I'll leave it for tomorrow
[02:00] <slickymaster> Unit193: I'm off, I'll have a early morning and a lot of miles to drive
[02:01] <slickymaster> cy tomorrow
[02:01] <Unit193> Alrighty, g'night.
[02:01] <jjfrv8> night, slickymaster
[02:02] <Unit193> jjfrv8: Anything else I can help you with?
[02:02] <Unit193> s/else //
[02:02] <jjfrv8> Unit193, don't think so. thanks for what you've done.
[02:02] <Unit193> Breaking your build? :)
[02:02] <jjfrv8> :)
[02:04] <jjfrv8> I think I'll just avoid running make on the real copy of my changes before I push
[02:05] <Unit193> Remember: bzr status/diff is your friend, make shouldn't be a problem.
[02:08] <jjfrv8> ok. I'm off too. I'll see what other damage I can do tomorrow.
[02:09] <Unit193> Heh, saaame to the breakage.  Working on breaking more of it now. :P
[07:12] <elfy> ty knome
[08:02] <ochosi> morning everyone
[08:02] <elfy> morning ochosi
[08:03] <ochosi> hey elfy
[08:03] <ochosi> how's it going?
[08:03] <elfy> could be worse :)
[08:04] <elfy> sun's out at least \o/
[08:05] <elfy> bluesabre: just exactly what do you want people to test in menulibre
[08:05] <ochosi> hehe, same here
[08:05] <elfy> and if you say everything - look for it during the Unreal Unicorn cycle ...
[08:07] <elfy> ochosi: nice to see things merging
[08:08] <ochosi> yeah, actually our progress-graph would look really clean and nice if it weren't for the linked bugreports
[08:08] <elfy> I'm a bit concerned with this keyboard EN issue though - as far as I can see anyone in the UK will install and have a buggared keyboard layout
[08:09] <elfy> ochosi: lol - looks ok on the qa blueprint :p
[08:10] <elfy> bug 1284635
[08:12] <ochosi> right, but i already mentioned that what you see in the greeter is only the locale, not the keyboard layout
[08:12] <ochosi> those two are theoretically completely independant
[08:12] <elfy> yea - I'm not concerned about that - but about the fact that it's wrong :)
[08:12] <elfy> I'm not saying it's something we can fix
[08:12] <elfy> or should
[08:12] <ochosi> did you set it to en_US in ubiquity?
[08:13] <ochosi> (i mean: when installing)
[08:13] <elfy> no
[08:13] <ochosi> so you set the keyboard layout to UK when installing
[08:14] <ochosi> and it was ok in the running session, but not in the greeter?
[08:18] <elfy> lol
[08:18] <elfy> no - it's fine in the greeter
[08:19] <elfy> say you set password to test# - works in greeter, login and sudo something and the keyboard will be doing test/ instead
[08:19] <elfy> pretty sure that ali1234 and lderan confirmed it
[08:20] <elfy> so you have to go to settings - where layout is set to US and change it - pita
[08:22] <ochosi> yeah, that blows
[08:22] <ochosi> so it really is filed against the correct package
[08:23] <lderan> yup confirmed it
[08:23] <elfy> ochosi: I don't know if it's the right package
[08:24] <ochosi> well, at least it isn't the greeter, which was what concerned me most
[08:24] <elfy> bdmurray didn't change it - I'd guess he'd know
[08:24] <ochosi> because that'd mean we'd have to fix it
[08:24] <elfy> yea :)
[08:26] <elfy> if nothing else we'll need to make sure it's on the known issues list
[08:27] <elfy> when I get the time I'll check lubuntu and kubuntu as well for it
[08:28] <ochosi> yeah, that'd be good
[08:28]  * elfy suspects it will be fine in kubuntu and possibly not in lubuntu
[08:30] <elfy> bbl
[08:30] <ochosi> sounds plausible to me
[08:36] <andrzejr_> I've noticed some problems with Japanese keyboard on 13.10+gtk3 indicator plugin - the keyboard does not do anything when I switch the language.
[08:36] <andrzejr_> but ibus keyboard switcher (in systray) seems to work fine.
[08:48] <ochosi> andrzejr_: what method of kb-layout switching does not work? indicator-keyboard?
[08:49] <ochosi> elfy: you could try whether installing indicator-keyboard fixes things for you. if so, we can consider either 1) installing that to make sure things work for everyone by default or 2) at least recommending that as a simple solution in our "known issues" section
[09:03] <ali1234> hmmmmmm..... google aura anyone?
[09:07] <brainwash> 35
[09:08] <brainwash> http://www.phoronix.com/scan.php?page=news_item&px=MTYyNzM
[09:08] <brainwash> "...it's running great on Xubuntu 14.04 LTS with the major exception being the HiDPI support."
[09:09] <brainwash> more and more people will complain about the missing HiDPI support, can we address this somehow?
[09:24] <ali1234> what is HIDPI support?
[09:25] <ochosi> support for displays with high resolution
[09:25] <ochosi> like the macbook pro retina
[09:25] <ali1234> yes and what does it mean?
[09:25] <ochosi> which is 13'' but has very high resolution
[09:25] <ochosi> so the elements on the screen seem very tiny
[09:25] <ochosi> unless you bump stuff like DPI, which can lead to fuglyness
[09:26] <brainwash> yeah, some next-gen apple technology
[09:26] <brainwash> :D
[09:26] <ali1234> so what are we supposed to do about it?
[09:26] <ochosi> brainwash: i don't think we have a good way of addressing that now, the main issue being gtk2's lack of support for it
[09:26] <ochosi> usually gtk would take care of it somehow
[09:26] <ochosi> or that's what gtk3 should do
[09:27] <ali1234> gtk3 is somewhat worse at handling different DPI than gtk2
[09:27] <ochosi> we can only make sure the "shell" (i.e. panels etc) scale appropriately when manipulating a single variable
[09:27] <ochosi> would be best to just look at what ubuntu did for unity to support that
[09:27] <brainwash> right, I'm just a bit concerned that more people will avoid Xfce and use something else instead
[09:28] <ochosi> (part of it was the indicator-change to support icon-names, because they also scale it up by a factor of 2 i think)
[09:28] <ochosi> yeah, but HiDPI is still a bit of a corner case (right, bluesabre ? :))
[09:28] <brainwash> 14.04 is LTS :P
[09:29] <ali1234> fonts in gtk2 scale correctly with dpi, unless you set override dpi
[09:29] <ochosi> yeah, but it's not just fonts
[09:29] <ochosi> e.g. xfwm4's window controls would also have to scale
[09:30] <ali1234> right. nothing else scales at all, anywhere
[09:30] <ochosi> yup
[09:30] <brainwash> I was able to reproduce the indicator plugin blank window problem, if you continue using the "close" button, it will work fine until you use "X" to close the window
[09:30] <ali1234> and in gtk3 the fonts don't even follow dpi
[09:30] <ochosi> possibly a problem of different ways of setting dpi and xfce4-settings not accounting for it?
[09:31] <wickz> brainwash, reproduces here as you said
[09:32] <brainwash> wickz: 14.04 right?
[09:32] <wickz> brainwash, yes
[09:32] <brainwash> want to add another comment to the report?
[09:33] <wickz> brainwash, I thought I had tried that several time but now it won't  give me back anything but a blank window
[09:34] <brainwash> yeah, something is odd here, should be fixable now that we know how to trigger the faulty behavior
[09:35] <brainwash> can you try something else please? create an empty file on the desktop and then cut&paste it into some folder (thunar)
[09:36] <wickz> brainwash, will do...
[09:37] <wickz> just pasted your entry above into the comment
[09:37] <brainwash> thanks
[09:38] <brainwash> so the file will stay visible on the desktop after the cut&paste event -> visual glitch
[09:40] <wickz> yes, it does
[09:40] <brainwash> you can even continue to perform file operation (context menu)
[09:40] <brainwash> like deleting the file
[09:40] <wickz> delete the file from thunar?
[09:40] <brainwash> via the glitched icon on the desktop
[09:40] <brainwash> no, desktop
[09:41] <brainwash> and it will disappear from thunar
[09:41] <wickz> yes, as you say
[09:41] <brainwash> thanks for confirming
[09:42] <wickz> glitched icon remaiins on desktop
[09:45] <wickz> When I trash the glitced icon: Error trashing file No such file or directory
[10:07] <brainwash> Unit193: so xfce4-session should have the line "Recommends: xscreensaver | light-locker"?
[10:07] <brainwash> light-locker is already present in the seed, so it won't pull xscreensaver then, right?
[10:13] <brainwash> bug 1291019
[10:32] <bluesabre> elfy: I dunno, the simple things?
[10:32] <bluesabre> add a launcher
[10:33] <bluesabre> add a directory, add a launcher to that directory; do they show up?
[10:33] <bluesabre> click "hide from menus", is that launcher now missing?
[10:33] <bluesabre> click it again, do you see it again?
[10:33] <bluesabre> :)
[11:00] <starrats> good morning everyone.  I still had a little trouble logging on with the latest kernel, went to the earlier one to get on and decided to try the new one and got on finally, I did mt usual updat/dist-upgrade, skipped upgrade but i'm back on the latest kernel and so far all is working fine.  This is just an FYI for brainwash but others might wan t to know, just trying to be helpful.
[11:01] <starrats> sorry for the spelling and space bar things
[11:45] <bluesabre> ochosi, lderan, knome: https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291324
[11:48] <bluesabre> ochosi, knome: I've pinged the folks over at #ubuntu-devel as well
[11:49] <knome> ok
[11:54] <brainwash> bluesabre: any idea how to resolve the light-locker-settings - power-manager conflict? both set the screen suspend timings and are not in sync
[11:56] <brainwash> maybe detect if xfpm is running (and handling dpms)
[11:56] <brainwash> and if yes, show some informative message
[11:57] <brainwash> bug 1290737
[11:59] <brainwash> xfpm saves the timings for bat and a/c, so it may override the settings even after session start -> delaying light-locker would not help in this case
[12:12] <bluesabre> gotta run, bbl
[12:12] <bluesabre> ochosi, knome, lderan: pitti uploaded it
[12:12] <bluesabre> :)
[12:13] <knome> nice
[12:15] <lderan> \o/
[12:29] <ochosi> cool
[12:29] <ochosi> that was quick, thanks bluesabre
[12:29] <ochosi> brainwash: frankly, xfpm
[12:30] <ochosi> brainwash: frankly, xfpm's timeout settings dont do anything here
[12:30] <ochosi> if they did influence the X11 screensaver we wouldn't have had to include those settings in light-locker-settings
[12:30] <brainwash> dpms settings
[12:31] <ochosi> yeah, those were included so it wouldn't be too weird, setting one setting here and another there
[12:32] <ochosi> anyway, now that you reported a bug about it, we could theoretically put it in as bugfix
[12:32] <brainwash> it's not my report :)
[12:34] <brainwash> so an informative message would be OK?
[12:34] <brainwash> check for xfpm, show message
[12:35] <brainwash> a message that tells the user to use the xfpm settings dialog
[12:35] <ochosi> nah, that's annoying
[12:35] <brainwash> if he want to change the dpms settings
[12:36] <ochosi> yeah, if you want the more sophisticated distinction that xfpm makes (on ac,batt) you have to use that and simply set the light-locker-settings thing to never
[12:36] <ochosi> it should be overridden anyway
[12:36] <ochosi> because it's only set and session-start
[12:38] <brainwash> we know that, but the average xubuntu does not
[12:38] <ochosi> well those that see the conflict (who knows how many) will hopefully make sense of it
[12:39] <ochosi> not sure what else to say, mapping 4 settings to 1 doesnt make sense either
[12:39] <ochosi> ideally xfpm will handle all of this again
[12:41] <brainwash> ok, can you please add some comment to the report to clarify the situation
[12:41] <brainwash> I assume that it is a "low" priority bug then
[12:42] <ochosi> light-locker-settings is not bound to stay in its current form...
[12:42] <ochosi> yeah, already wrote one, havent hit save yet :)
[13:03] <jjfrv8> ochosi, I don't really know my way around github. do you have a link you could point me to so I could get the svgs for the new whiskermenu icons?
[13:05] <ochosi> jjfrv8: which ones do you need?
[13:06] <ochosi> and do you need them in svg, png
[13:06] <ochosi> the lock and log-out icons?
[13:06] <knome> ochosi, 16x16 png
[13:07] <knome> lock, logout, yeah
[13:07] <jjfrv8> ochosi, ^^
[13:10] <ochosi> jjfrv8: ok, coming up...
[13:11] <ochosi> note that the 16px icon is slightly different from the 24px icon used in whiskermenu
[13:11] <ochosi> (the logout-icon)
[13:12] <jjfrv8> will it look enough the same that ppl won't know the diff when we show it in the docs?
[13:13] <knome> ochosi, as long as it is "the same icon", it's okay
[13:13] <knome> different sizes vary anyway, nothing we can do about that
[13:13] <ochosi> lock icon: http://bazaar.launchpad.net/~xubuntu-art/xubuntu-artwork/trusty/download/head:/locked.png-20130125111841-yl4a77lk07r0je0d-7644/locked.png
[13:13] <ochosi> knome: the 16px variant hasn't been added to the darker variant yet
[13:14] <ochosi> in elementary-xfce it has a light grey background (the logout icon), in the -darker variant a dark grey background
[13:14] <ochosi> it's the same icon though
[13:14] <ochosi> if you give me until tomorrow, i can do the 16px version of the -darker version too
[13:14] <ochosi> or maybe later tonight
[13:14] <knome> that would be cool
[13:15] <ochosi> sure, no problem
[13:15] <knome> yeah, np, tomorrow works
[13:15] <ochosi> who do i ping? you or jjfrv8?
[13:15] <knome> either works for me
[13:15] <jjfrv8> thanks, ochosi
[13:15] <ochosi> as you wish/prefer
[13:15] <ochosi> the lock icon is the same btw, so you can already use that one
[13:15] <knome> i have no preference except "ping soembody" :)
[13:15] <ochosi> hehe
[13:15] <ochosi> ok
[13:16] <ochosi> i'll probably just ping you both then ;)
[13:17] <knome> works
[13:17] <knome> re: lock icon, easier to drop them in at the same time
[13:18] <jjfrv8> knome, should have another MP for you shortly. updated links to xfce docs for ristretto and parole and some other minor changes to guide-default-apps
[13:18] <ochosi> ok, well anyway, you h62;9;cave the
[13:18] <ochosi>
[13:18] <ochosi> crap, whatever happened to my ssh connection
[13:18] <ochosi> it's somehow garbled
[13:18] <knome> jjfrv8, yeah, cool
[13:19] <knome> jjfrv8, i merged all the pending stuff yesterday, as you probably noticed
[13:19] <ochosi> anyway, you have the link now to lock
[13:19] <jjfrv8> yup, thanks
[13:31] <ochosi> nice, all xubuntu-related packages in the sponsors queue were uploaded today
[13:31] <ochosi> (there were 5)
[14:12] <ochosi> knome: just pushed the 16px version to -darker/actions/16/system-log-out.svg on github, can you do the honours of converting it to png for the docs yourself?
[14:12] <elfy> ochosi: I'll check that indicator-keyboard thing
[14:12] <ochosi> i'll wait a bit longer until i refresh xubuntu-artwork with that
[14:12] <ochosi> thanks elfy
[14:13] <elfy> though ...
[14:13] <elfy> how do I put in the password when the keyboard's not set up properly ;)
[14:20] <ochosi> you'll figure it out ;)
[14:20] <elfy> ochosi: so ...
[14:21] <elfy> it fails in Lubuntu too
[14:22] <ochosi> add them to the affects-list
[14:22] <ochosi> hey micahg
[14:23] <knome> ochosi, i can
[14:23] <ochosi> ty
[14:24] <micahg> hi ochosi
[14:24]  * micahg is disappearing in a little bit
[14:24] <micahg> I still need to look at your stuff
[14:26] <elfy> ochosi: frankly I'm not sure I can be bothered - I'm more likely to believe that it'll end up being exactly the same on April 18th
[14:27] <elfy> installing kubuntu now
[14:27] <elfy> then that'll be all the official flavours
[14:30] <elfy> the bug got marked as incomplete way back - added information he wanted
[14:35] <ochosi> micahg: yeah, those -default-settings merges would be nice!
[14:36] <ochosi> elfy: right, i'm not saying i can fix that bug for you, but i'd like to see whether we can at least offer a workaround
[14:36] <ochosi> if the keyboard indicator helps (it can also be added/shown in the greeter if necessary), we can add it
[14:47] <jjfrv8> back later for the meeting
[15:06] <knome> ochosi, jjfrv8: icons updated in docs
[15:09] <slickymasterWork> knome: the po files grow fat in the last two hours :P
[15:11] <slickymasterWork> Finnish untranslated -> 160; Portuguese unstranslated -> 108 (still ahead :P)
[15:24] <knome> slickymasterWork, i know, but LP hasn't imported my .po file
[15:24] <knome> slickymasterWork, i don't translate via rosetta, i edit the .po file directly and then push
[15:24] <slickymasterWork> I think I'll start to use that method, also
[15:43] <knome> slickymasterWork, it's a bit easier to translate like that, yeah
[15:44] <knome> slickymasterWork, poedit is a good editor and has sane shortcut keys, so unless you have to check something (like the exact translated string) you can advance pretty fast
[15:45] <slickymasterWork> knome: just a question though. working directly in the .po file, do we have to break the translated strings to match the original, or can it be a continuous string and afterwards LP will deal with it and correctly format it?
[16:38] <knome> slickymasterWork, poedit will show it as one string, "breaking" in the files is automatical
[16:42] <knome> ochosi, so who can approve me to the whisker menu finnish translators group?
[16:50] <slickymasterWork> ok knome, thanks
[16:51] <slickymasterWork> Whisker portuguese translation is absolutely lousy
[17:05] <ochosi> knome, slickymasterWork: https://www.transifex.com/projects/p/xfce4-whiskermenu-plugin/
[17:14] <slickymasterWork> thanks ochosi
[17:14] <slickymasterWork> gotta run now, work meeting :P
[17:14] <slickymasterWork> ->
[17:37] <elfy> ochosi: so now I've installed all the official flavours the 2 not affected are ubuntu and kubuntu
[17:48] <ochosi> right but have you tested the keyboard-indicator at all?
[17:48] <knome> ochosi, i didn't ask that... :P
[17:50] <ochosi> knome: i guess you can leave a message there in transifex and whoever is admin can approve you
[17:54] <elfy> ochosi: not yet - only just got in from work - kubuntu was installing while I was out ;)
[17:54] <ochosi> elfy: ah, hehe
[17:54] <ochosi> so how did you like the other flavors?
[17:54] <ochosi> anything that did strike you?
[17:55] <elfy> other than being able to use the password :p
[17:55] <elfy> I've not looked at all today - all I was doing was checking this kbd issue
[17:56] <elfy> but ... I like kubuntu as much as I always did, and ubuntu is still unity ... and lubuntu I've never liked ...
[17:56] <ochosi> huhu
[17:56] <elfy> for names - read DE
[17:57] <elfy> just installed a new xubuntu - installing indicator
[18:01] <elfy> ochosi: nothing that indicator-keyboard does to help, the keyboard plugin does the job
[18:01] <ochosi> keyboard-plugin?
[18:02] <ochosi> you mean the xfce keyboard plugin?
[18:02] <elfy> yea
[18:02] <ochosi> hmm
[18:02] <ochosi> strange that the indicator doesn't work/help
[18:02] <knome> ochosi, yeah, too slow, i was already accepted
[18:03] <knome> ochosi, and already translated the rest of the strings
[18:03] <elfy> ochosi: all it does is indicate what keyboard layout is in use
[18:03] <ochosi> elfy: so you can't use it to switch to another layout?
[18:03] <elfy> taking no notice of what the xfce plugin is set to
[18:04] <elfy> ochosi: seemingly not
[18:04] <ochosi> you could try to restart your session just to be sure
[18:04] <elfy> I wish I'd taken more notice of when it went wrong - we might be able to track it down
[18:04] <ochosi> in case you haven't done that yet
[18:04] <elfy> yep
[18:05] <elfy> actually I logged out after I installed it
[18:05] <ochosi> ok
[18:05] <elfy> rebooting it
[18:06] <elfy> nothing different
[18:06] <ochosi> hm
[18:06] <ochosi> ok, well it was worth a shot
[18:07] <ochosi> maybe the keyboard indicator only works with gnome-settings-daemon
[18:07] <knome> anybody else willing to chair the meeting today?
[18:08] <ochosi> gotta run to the store now, but i think i'll be back in time for the meeting
[18:08] <ochosi> if so, i can
[18:08] <knome> ochosi, ok, thanks
[18:08] <ochosi> bbiab
[18:08] <knome> bluesabre, any reason bug 1281536 isn't "released" ?
[18:11] <knome> Unit193, have you had any new ideas how to attribute translators since the last time i asked you that?
[18:12] <knome> jjfrv8, slickymaster: can you think of anything major that will land into the docs between now and release?
[18:12] <knome> jjfrv8, slickymaster: or in other words, are we pretty much good to start calling for translators now?
[18:12] <elfy> ochosi: I remember when it happened ... at the same time as ibus turning up in notification area
[18:13] <elfy> installing gnome-settings-daemon makes no difference
[18:13] <elfy> hope to be back in time for meeting
[18:13] <knome> i'm off for a while as well
[18:53] <ochosi> arr, sry, i'll be a little late again for the meeting (~20min), will try to come back asap
[18:59] <knome> #startmeeting Xubuntu community meeting
[18:59] <meetingology> Meeting started Wed Mar 12 18:59:53 2014 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:59] <meetingology> Available commands: action commands idea info link nick
[18:59] <knome> who's here for the meeting?
[19:00] <elfy> just
[19:00] <jjfrv8-work> o/
[19:00] <knome> #topic Open action items
[19:01] <knome> #action ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:01] <meetingology> ACTION: ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:01] <knome> anything new up with this?
[19:01] <ali1234> it's fixed upstream, not sure if it landed in trusty yet
[19:02] <knome> okay
[19:02] <knome> #info Issues fixed upstream, landed or landing in Trusty soon
[19:02] <knome> #action lderan to create the individual merge proposals for the basic Xubuntu tests
[19:02] <meetingology> ACTION: lderan to create the individual merge proposals for the basic Xubuntu tests
[19:02] <ali1234> if there's any indicator bugs, assign them to me (if you can)
[19:02] <knome> #nick michag
[19:02] <knome> #undo
[19:02] <meetingology> Removing item from minutes: ACTION
[19:02] <knome> hmm
[19:03] <ali1234> or just send me the link
[19:03] <knome> #action lderan to create the individual merge proposals for the basic Xubuntu tests
[19:03] <meetingology> ACTION: lderan to create the individual merge proposals for the basic Xubuntu tests
[19:03] <knome> #nick micahg
[19:03] <knome> #info if anybody notices any bugs with indicators, point ali1234 to them
[19:03] <knome> #action micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:03] <meetingology> ACTION: micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:04] <knome> #action Noskcaj to be in touch with elfy on xkb-plugin testing
[19:04] <meetingology> ACTION: Noskcaj to be in touch with elfy on xkb-plugin testing
[19:04] <knome> elfy?
[19:04] <elfy> not heard anything
[19:04] <knome> okay
[19:04] <knome> #action pleia2 starts working on getting the Processes wikipage updated and cleaned
[19:04] <meetingology> ACTION: pleia2 starts working on getting the Processes wikipage updated and cleaned
[19:04] <knome> pleia2?
[19:05] <knome> #action knome to work on the desktop of the week -stuff
[19:05] <meetingology> ACTION: knome to work on the desktop of the week -stuff
[19:05] <knome> carrying
[19:05] <knome> #topic Team updates
[19:05] <knome> please use #info, #action AND the new one, #done as appropriate
[19:05] <knome> #done knome merged documentation and slideshow stuff
[19:06] <knome> #done knome fixed docs translation validation issues
[19:06] <elfy> #info elfy not much to report in qa - only planned calls for testing left are beta and rc
[19:06] <jjfrv8-work> I don't have any, knome did it all :)
[19:06] <knome> #done knome pushed a new start page for docs
[19:07] <elfy> #info xubuntu-qa to get menulibre testcase up within the next week
[19:07] <knome> cool
[19:07] <knome> finally ;)
[19:07] <elfy> mmm
[19:07] <lderan> :P
[19:07] <knome> i mean, with all the hurdles in many many teams
[19:08] <knome> anything else?
[19:08] <elfy> not from me
[19:08] <lderan> nope
[19:08] <Noskcaj> just a few updates, not really worth a #info
[19:08] <knome> hmm right,
[19:08] <elfy> lderan to create the individual merge proposals for the basic Xubuntu tests - what's going on with that?
[19:09] <knome> #done knome and pleia2 worked on the flyer, almost ready
[19:09] <knome> also Noskcaj, ACTION: Noskcaj to be in touch with elfy on xkb-plugin testing
[19:09] <lderan> elfy, for the autopilot tests
[19:10] <elfy> yep
[19:10] <knome> he was asking "what's the progress" :P
[19:10] <elfy> lol - yea :)
[19:10] <lderan> ah, need to start doing it :(
[19:10] <knome> oki, np
[19:11] <knome> #topic Announcements
[19:11] <knome> #info UI freeze is tomorrow
[19:11] <GridCube> o/
[19:11] <knome> #info We will most probably need at least one UIFe for the new wallpaper and possibly other artwork packages unless we can get them uploaded/sponsored today/tomorrow
[19:12] <knome> #info Documentation String Freeze is on March 20th
[19:12] <elfy> what about changes to default whiskerment items?
[19:12] <knome> elfy, probably those too, but i'd imagine they are in the pending uploads
[19:13] <knome> jjfrv8, slickymaster: i asked you before, but i ask you again:
[19:13] <elfy> so we decided what they'd be?
[19:13] <knome> is there something more or less major that needs to be landed before call for translators?
[19:13] <knome> elfy, "everything that's in the slideshow" :)
[19:13] <knome> elfy, as mentioned last week, or so
[19:13] <elfy> oh yea
[19:13] <knome> we think it's fair to do that, because we're advertising that stuff
[19:14] <elfy> sorry - ignore me
[19:14] <knome> heh, np
[19:14] <knome> good to have any doubts cleared ;)
[19:14] <jjfrv8-work> knome, not major, afaik, but there will still be minor updates to later chapters
[19:14] <jjfrv8-work> should be done before 20th
[19:14] <knome> jjfrv8-work, can you give me an oversight on the scale/subject of those?
[19:15] <jjfrv8-work> before the end of the day?
[19:15] <knome> i was thinking, like, now
[19:15] <knome> if you had something specific in mind that we need to do
[19:15] <jjfrv8-work> sorry not even able to look at work
[19:15] <knome> if not, then it's probably not major enough to be worried about
[19:16] <knome> the quicker we have the docs stuff ready, the better for us
[19:16] <jjfrv8-work> I've been through the rest of the chapters and didn't see anything stand out
[19:16] <pleia2> sorry, was pulled into a meeting, here now
[19:16] <knome> yep, that's good
[19:16] <knome> so basically, we will get a new docs upload on march 20
[19:16] <knome> and then we can just call for translators
[19:16] <knome> but practically we can tell translators to start translating now, if we're only going to do minor changes
[19:17] <knome> and give translators one more week to work
[19:17] <knome> i've even updated the translation template today, and it's already visible in launchpad
[19:17] <knome> so everything that was proposed before yesterday is now translatable
[19:17] <pleia2> hooray
[19:18] <Unit193> I have one more proposal, but it's more backend.
[19:18] <knome> yeah, that's not something to worry about for the translators
[19:18] <knome> actually, there's more of the docs stuff i want to go through, but let's move on, and then get back to that shortly
[19:18] <knome> #topic Agenda
[19:18] <knome> #subtopic Start the discussion on the technical review for the Strategy Document
[19:19] <knome> i'm dropping this from the agenda since this is postponed in our blueprints; we should add it back when we are actually ready to talk about it
[19:19] <knome> #subtopic 12.04 > 14.04 upgrades, removing xscreensaver
[19:19] <knome> who added this?
[19:19] <elfy> ochosi
[19:19] <knome> what's the thing to discuss
[19:19] <knome> aha...
[19:19] <knome> ochosi, you around?
[19:19] <Noskcaj> That it needs to be removed while upgrading
[19:19] <Noskcaj> i'm guessing
[19:20] <GridCube> he said he be back >20 mins on the meeting knome
[19:20] <elfy> yep - that - I'm pretty sure
[19:20] <knome> yes... but wouldn't that just be a work item
[19:20] <knome> i'm wondering if ochosi added it, if there was something else to discuss
[19:20] <knome> GridCube, yeah, noticed that
[19:20] <elfy> knome: possibly
[19:20] <knome> from my POV, the plan sounds good as long as it "works"
[19:20] <GridCube> i guess it was added to discuss if using lightdm locker
[19:21] <knome> 14.04 should use light-locker, yes
[19:21] <knome> and not have xscreensaver
[19:21] <GridCube> for me it should be removed
[19:21] <GridCube> it adds problems to viewing videos and such
[19:21] <knome> i could imagine the discussion was about the technical side
[19:21] <elfy> though - I'd guess we'd need to do the same for 13.10 upgrade too
[19:22] <knome> GridCube, again, please, rather file bugs about problems than switch to the "i'm not using it because it's broken and you'll never fix it" -mode
[19:22] <knome> elfy, yep.
[19:23] <knome> i'm carrying this, and encouraging any off-meeting discussion on it, if one can help the progress
[19:23] <knome> #subtopic Documentation stuff
[19:23] <GridCube> no, im not saying that, i just say that thats a reason im for the drop, there are plenty of bugs regarding the xscreensaver issue with video if you want me to search them, but that was not the point of my comment
[19:23] <knome> GridCube, right, xscreensaver...
[19:23] <knome> yeah, we adgree
[19:23] <knome> *agree
[19:23] <knome> that's why we want to use light-locker anyway
[19:23] <knome> or, one of the reasons
[19:23] <knome> so, docs stuff
[19:23] <GridCube> :)
[19:23] <knome>  [xubuntu-doc] Investigate how to attribute translators: INPROGRESS
[19:24] <knome> anybody have a good idea?
[19:24] <knome> the translation string that launchpad adds is a bit lame, and we're unable to theme it
[19:24] <elfy> not even aware of it being a thing
[19:24] <knome> basically:
[19:24] <knome> we want the translated docs to tell: X contributed to this translation
[19:25] <ochosi> o/
[19:25] <knome> hey ochosi
[19:25] <knome> ochosi, we can get back to stuff after the docs stuff
[19:25] <knome> Unit193, pleia2: ideas?
[19:25] <ochosi> knome: sure, i'll read the backlog meanwhile
[19:26] <pleia2> unfortunately I'm really weak on translations stuff, I don't know best policies here
[19:26] <knome> from my POV, it's more of a technical issue
[19:26] <knome> i *want* to attribute the translators :)
[19:26] <knome> i'm just thinking what's the best way
[19:26]  * pleia2 nods
[19:27] <pleia2> how are they tracked in lp?
[19:27] <knome> LP creates a translation string in a .po
[19:27] <knome> where the source string is "translator-credits" or so
[19:27] <knome> and the translated string is a list of people and LP urls
[19:27] <knome> ...which is not a list
[19:28] <knome> but just names and urls after each other
[19:28] <GridCube> can't we ask them to sign some kind of registry?
[19:28] <pleia2> it scares me to look at it again, but I wonder if launchpadlib has a way to pull out the names
[19:28] <ochosi> sounds like a job for a regexp?
[19:28] <knome> Unit193, maybe we could semi-dirtily hack that off from the translation, and add them to a translated xml file
[19:28] <GridCube> like "i translated x" and then we check if they did
[19:28] <knome> GridCube, no, LP is tracking that
[19:29] <knome> the problem is not that we need to check if people actually translated stuff
[19:29] <knome> the problem is that we need to show it in a sensible way somewhere
[19:29] <knome> or, want
[19:29] <knome> pleia2, as i said, they *are* in the .po fiels
[19:29] <GridCube> yes, thats why i say, we ask them to say to us if they want their names, and if they do, they sign a registry
[19:30] <pleia2> knome: so just grep? :)
[19:30] <knome> GridCube, the problem that we have is still around. how to show the registry?
[19:30] <knome> pleia2, something like that, but should be automatic and build-time
[19:30] <GridCube> oh, maybe a news on our site?
[19:31] <pleia2> a lot of translators just look at laucnhpad and do translations, I doubt they'd find our registry
[19:31] <knome> pleia2, and should be able to push the names to a translated file after grepping :)
[19:31] <GridCube> pleia2, true
[19:31] <pleia2> knome: yeah
[19:31] <knome> and news on the site... we can do that as well, but the point is we want to attribute people ON the documentation
[19:31] <knome> the information is available
[19:31]  * pleia2 nods
[19:31] <knome> Unit193, want to look at that?
[19:32] <GridCube> well i have to go :)
[19:32] <Unit193> Eh.
[19:32]  * GridCube pokes knome and ask him to remember the desktop of the week project
[19:32] <knome> GridCube, done.
[19:32] <GridCube> bye
[19:32] <knome> Unit193, that's a yes?
[19:33] <Unit193> I don't even see what you're talking about, so you'd likely be better.
[19:34] <knome> Unit193, in a Makefile, strip a certain translation string off a translation, grep it and turn it into HTML markup, inject it into a translated file.
[19:34] <knome> Unit193, i can help with that.
[19:35] <knome> #action Unit193 and knome to look at attributing translators
[19:35] <meetingology> ACTION: Unit193 and knome to look at attributing translators
[19:35] <knome> :))
[19:35] <knome>  [xubuntu-doc] Update the installer slideshow: INPROGRESS
[19:35] <knome> can we schedule a sprint for this?
[19:35] <Unit193> If it's with makefiles, that's up to you.
[19:36] <knome> Unit193, well scripts in makefiles. probably nothing too weird...
[19:36] <knome> ochosi, jjfrv8-work, slickymaster, pleia2: what time would work for you?
[19:36] <knome> something on the weekend?
[19:37] <pleia2> I'm traveling these next couple weekends
[19:37] <jjfrv8-work> saturday, 13 to 20 or so
[19:37] <knome> what about friday then?
[19:37] <knome> or monday
[19:38] <knome> tomorrow is a bit bad for me
[19:38] <jjfrv8-work> friday's okay for me, monday not so much
[19:38] <pleia2> I can try for friday
[19:38] <knome> wouldn't want to push this after monday though
[19:38] <knome> is 19UTC bad?
[19:38] <pleia2> fine by me
[19:38] <jjfrv8-work> me too
[19:38] <knome> ochosi, slickymaster: ?
[19:39] <ochosi> slideshow sprint
[19:39] <knome> yep
[19:40] <ochosi> hm, i'm away for the weekend...
[19:40] <ochosi> taking a trip
[19:40] <knome> starting from friday?
[19:40] <ochosi> so no interwebs and no sprint
[19:40] <ochosi> from saturday early on
[19:40] <knome> aha
[19:40] <knome> we're talking about friday 19utc
[19:40] <ochosi> the current meeting-time is kinda meh for me because it's dinner/movie/going-out time
[19:40] <ochosi> so it coincides with lots of things potentially
[19:40] <ochosi> just saying
[19:40] <knome> propose a time later or earlier :)
[19:40] <pleia2> earlier is ok for me too
[19:41] <knome> both work for me too.
[19:41] <ochosi> could be that i'm around, but earlier would certainly be more likely to work for me
[19:41] <knome> ochosi, hour or two earlier? or more?
[19:41] <ochosi> so something like 16 or 17utc would work just fine
[19:41] <pleia2> ok
[19:41] <knome> 17utc works for pleia2, jjfrv8-work ?
[19:41] <jjfrv8-work> good
[19:41] <knome> slickymaster, hallö?
[19:42] <knome> #info Slideshow sprint: Friday, March 14 @ 17UTC
[19:42] <knome> ochosi, want to discuss the lts->lts upgrade?
[19:43] <ochosi> i mostly put that there as a reminder
[19:43] <knome> aha
[19:43] <ochosi> i personally don't know how this would be implemented
[19:43] <knome> okay
[19:43] <ochosi> but there are a few things that should be removed on upgrades to trusty
[19:43] <knome> maybe we can ask for some help in #ubuntu-devel or sth
[19:43] <ochosi> one of them is xscreensaver, another is gtk2-indicators
[19:43] <knome> would it be better as a work item?
[19:44] <ochosi> both of those conflict with the stuff we ship in trusty
[19:44] <ochosi> so i guess asking micahg would be step 1 for me
[19:44] <ochosi> (frankly, i had hoped he'd read it there on the whiteboard)
[19:44] <ochosi> if he doesn't know how we can do this, we need to ask around
[19:44] <knome> yep
[19:44] <ochosi> and sure, it can also be made a workitem
[19:45] <ochosi> just didn't want to assign it to me ;)
[19:45] <ochosi> (better assign it to someone with more technical knowledge)
[19:45] <knome> not sure which blueprint is the best for that, but i'll get it up today
[19:45] <knome> #topic Schedule next meeting
[19:45] <ochosi> there was also another question/thing i wanted to raise
[19:45] <knome> aha
[19:45] <ochosi> if there's still a minute
[19:45] <knome> #undo
[19:45] <meetingology> Removing item from minutes: TOPIC
[19:45] <knome> #subtopic ochosi's question
[19:46] <ochosi> I saw we have a bugs blueprint now
[19:46] <knome> yep
[19:46] <ochosi> so i was wondering whether you wanna link *all* bugs that affect xubuntu trusty there
[19:46] <ochosi> even e.g. bugs in gtk
[19:47] <ochosi> (there is one i'm thinking of in particular, https://bugzilla.gnome.org/show_bug.cgi?id=710909)
[19:47] <knome> no, only everything that we are committed to fix
[19:47] <ochosi> i don't think any of us can or is going to fix that
[19:47] <knome> or very critical bugs otherwise
[19:47] <knome> anything we want to track
[19:47] <ochosi> right, well it's just a visual nuisance
[19:47] <ochosi> ppl will see it anyway, so we probably dont even need to track it :)
[19:47] <ochosi> (and i'm personally tracking it for a while already)
[19:47] <knome> sure
[19:48] <knome> no hard policy
[19:48] <ochosi> ok
[19:48] <ochosi> guess i wasn't around when you introduced that blueprint, so i wanted to make sure
[19:48] <knome> they are just there to track the status on the work items tracker
[19:48] <knome> added all bugs that were reported against xubuntu in the QA trackers after beta1
[19:48] <ochosi> right, feel free to move along then
[19:48] <knome> so that's where that list came from
[19:49] <ochosi> ah ok
[19:49] <ochosi> basically the one elfy compiled
[19:49] <knome> yeah, pretty much that
[19:49] <knome> #topic Schedule next meeting
[19:49] <knome> so
[19:49] <knome> let's get back to normal schedule
[19:49] <knome> what do people think of making the meeting one hour earlier?
[19:50] <pleia2> is fine
[19:50] <knome> pleia2, is that worse for you?
[19:50] <knome> oh, good
[19:50] <pleia2> hooray for DST :)
[19:50] <ochosi> for me it's a bit better
[19:50] <jjfrv8-work> better here too
[19:50] <Unit193> So we're putting it back at 2pm?
[19:50] <elfy> that'd be a pain for me atm - but there's not much I need to be worrying about atm
[19:50] <knome> 2pm what time :P
[19:50] <knome> we're proposing 18UTC
[19:51] <knome> just to try out if it works any better for people
[19:51] <elfy> did it not get moved from there ?
[19:52] <knome> it was there because DST :P
[19:52]  * knome shrugs
[19:52] <elfy> anyway - as I said - not much for me to be about for anyway
[19:53] <knome> ok
[19:53] <knome> #info Next community meeting: Thursday, March 20 at 18UTC
[19:53] <knome> #endmeeting
[19:53] <meetingology> Meeting ended Wed Mar 12 19:53:30 2014 UTC.
[19:53] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-03-12-18.59.moin.txt
[19:53] <ochosi> thanks for chairing after all knome
[19:53] <pleia2> thanks knome
[19:53] <knome> np
[19:53] <knome> lderan, bug!
[19:53] <elfy> though I'll not be working next week so can make it lol
[19:53] <knome> lderan, see the output, no #done itmes :)
[19:53] <elfy> thanks knome
[19:55] <lderan> knome, interesting shall check
[19:55] <pleia2> ok, added sprint and meeting to our calendar
[19:55]  * pleia2 back2work
[19:57]  * elfy was asleep - thought that sprint thing was something to do with translations ...
[19:57] <pleia2> hehe
[19:57] <knome> elfy, lol
[19:57] <knome> elfy, slideshow content
[19:57] <knome> elfy, i didn't think you were "critical" attendee, but by all means, feel free to join us :)
[19:57] <elfy> yea - see that now I'm awake
[19:58] <elfy> yep - if I can I will
[19:58] <elfy> talk of translations made elfy go zzzzzzzzzzzzzzzz
[19:59] <Unit193> ^
[20:05] <Unit193> http://goo.gl/FRPehU
[20:07] <elfy> that's right - it's the same as the one already on the calendar :p
[20:07] <elfy> [19:55] <pleia2> ok, added sprint and meeting to our calendar
[20:08] <elfy> Unit193 was still zzzzzzz'ing after the translations ...
[20:09] <Unit193> Doh, I was paying attention. >_<
[20:10] <elfy> :)
[20:21] <elfy> lderan: is there a known issues with light-locker-settings? ImportError: No module named psutil
[20:23] <lderan> shall check that now
[20:23] <Unit193> jjfrv8: Not that it matters too much, but figured I'd work up http://paste.openstack.org/show/K6gWcqgQaL9REKQv0rdY for you, will propose in the next merge.  It doesn't entirely remove the use of -s, but if you have the LINGUAS file it does.
[20:23] <ali1234> Noskcaj: i've refreshed the thunar bookmarks patch
[20:24] <ali1234> (and hopefully fix the directory creation)
[20:24] <Noskcaj> ali1234, Are you going to package it or do you want me to?
[20:25] <ali1234> i would prefer if you do it tbh
[20:25] <Noskcaj> ok
[20:25] <ali1234> i don't understand how that packaging stuff works
[20:26] <ali1234> i always mess up the changelog or the version number
[20:26] <Noskcaj> branching thunar now
[20:27] <ali1234> xfce4-places-plugin also needs a patch to handle the new bookmarks
[20:28] <Noskcaj> Can i have a link to the patch please?
[20:29] <ali1234> https://bugzilla.xfce.org/show_bug.cgi?id=10626
[20:29] <Noskcaj> thanks
[20:29] <Noskcaj> And for thunar?
[20:29] <ali1234> https://bugzilla.xfce.org/show_bug.cgi?id=10627
[20:34] <lderan> elfy, its not on the bug list. ochosi & bluesabre ^^ looks like psutil isn't installed by default.
[20:37] <elfy> that worked
[20:41] <elfy> knome ochosi - small point - I agree that default apps should be those we show in slides - but not settings - there's a button for that already
[21:11] <lderan> knome, found the issue and have a mp up for it now :)
[21:11] <Noskcaj> ali1234, all done
[21:11] <ochosi> lderan: i guess bluesabre forgot to update the packaging
[21:17] <knome> Unit193, gettext -d xubuntu-docs -s 'translator-credits'
[21:18] <knome> Unit193, though you need to have xubuntu-docs.mo in /usr/share/locale/LANG/
[21:18] <knome> and the LANGUAGE env var must be set to LANG
[21:18] <knome> can overwrite the "TEXTDOMAINDIR", but is hacky
[21:19] <knome> and you'd need to change the LANG anyway, so more hacky.
[21:19] <knome> and you'd need to create .mo fiels, so even more hacky
[21:21] <lderan> ochosi, do not know where to add it, having a look now
[21:23] <ochosi> lderan: my guess would be debian/control
[21:23] <ochosi> but i have no clue, i always leave packaging to other ppl :)
[21:25] <lderan> now launchpad dies
[21:32] <Unit193> knome: Did you test that?
[21:36] <knome> test what? that command?
[21:36] <knome> yeah.
[21:36] <knome> but you need to have those prerequisites.
[21:37] <knome> which is a bit overkill
[21:37] <knome> convert the whole translation category to a machine readable format and change an env var for each translation? nah...
[21:38] <Unit193> Why?  (not real) for lang in language;do mkdir lang/LC_MESSAGES && msgfmt -o $lang/LC_MESSAGES/xubuntu-docs.mo  then parse them, and delete them.
[21:38] <Unit193> :D
[21:39] <Unit193> Prefer my hackage with grep? :P
[21:39] <knome> grepping could be prettier.
[21:40] <Unit193> More hacky.
[21:40] <knome> but faster.
[21:41] <Unit193> (msgfmt is fast.)
[21:42] <knome> what feels most hacky is modifying the LANG var.
[21:43] <Unit193> You don't need to export it.
[21:45] <Unit193> grep translator-credits -A16 es.po | grep launchpad | sed -e 's/"  //' -e 's/ https.*//'   :P
[21:45] <knome> msggrep --msgid -F -e 'translator-credits' fi.po
[21:52] <Unit193> real    0m1.558s
[21:52] <Unit193> Ahh, riiight. msggrep. >_<
[21:52] <knome> but that outputs a full po file.
[21:53] <Unit193> Anyway, that time output is to compile and get the information for all the languages.
[21:53] <Unit193> (On the slowest computer, P4.)
[21:53] <knome> yeah, but does it involve changing the LANG var?
[21:55] <Unit193> Changing?  Nope, just runs that command with the lang var.  LANGUAGE=fi cat --help;cat --help
[21:55] <knome> ah, right.
[21:55] <knome> but meh.
[21:56] <knome> how's msggrep compared?
[21:57] <knome> msgexec is supposed to edit MSGEXEC_MSGID, so should be able to do with msggrep piped to that, but it doesn't affect the variable.
[21:57] <knome> which sucks
[21:58] <Unit193> msggrep: 0m0.947s, msgfmt: 0m0.734s
[21:59] <knome> bah.
[21:59] <Unit193> Like it matters? :P
[21:59] <Unit193> At this point, it's less than what it takes to format one doc, so I don't care about speed.
[22:00] <knome> i'm fine with either way tbh
[22:01] <knome> just trying to find out the "right" way, if you know what i mean
[22:04] <knome> but yeah...
[22:04] <knome> now that we have sorted out how we get the string out of the .po, let's discuss what we want to do with it
[22:07] <knome> and how...
[22:07] <knome> we want to edit the ln-id....html file.
[22:07] <knome> sounds fun? :)
[22:08] <knome> wondering if there is a way to leave a html comment with docbook
[22:17] <Unit193> knome: Just make sure to grep -v Pasi. :----------D
[22:17] <Unit193> Also, you need to learn oc, that's the only one you're not in. :P
[22:19] <Unit193> Again, if you do it with a makefile, I'm out. :P
[22:23] <knome> how else?
[22:23] <knome> but seriously...
[22:24] <knome> doing it with a makefile is pretty much the same as doing it with a script.
[22:24] <Unit193> Not in my experience.  I can create a bash script and hand it off to be turned into a makefile, or just give the logic needed, but makefiles don't make sense to me.
[22:25] <Unit193> knome: Which method are we going for?
[22:25] <Unit193> grep or fmt?
[22:26] <knome> i guess either works.
[22:27] <knome> grep seems a bit more clean to me, but i don't know
[22:27] <knome> we can always tweak it later
[22:27] <Unit193> Heh, other seemed cleaner. :P
[22:27] <Unit193> I could make it for both, but..
[22:28] <Unit193> Biggest problem, is where to put them and how, though.
[22:29] <knome> the grepped data?
[22:29] <ochosi> crap, some dialogs in gtk3.10 look awful.. http://www.zimagez.com/zimage/screenshot-2014-03-12-232831.php
[22:29] <knome> heh
[22:30] <Unit193> knome: Looking to keep the LP link?
[22:31] <knome> i'm thinking do the same as in the other lists
[22:31] <knome> strip name then put the LP *ID* on parenthesis
[22:33] <Unit193> http://paste.openstack.org/show/42GVWEmqZ9RjbHq8AgP8
[22:34] <knome> hmm.
[22:34] <knome> i was thinking we should do the attributing per-language.
[22:34] <Unit193> Sure, makes sense, but that is one language. :D
[22:34] <knome> uhu
[22:34] <knome> okay...
[22:34] <Unit193> It's why I picked es, because it has the best example.
[22:48] <brainwash> iso image size: 949M
[22:48] <brainwash> wow
[22:52] <ochosi> that's pretty much expected, what's wow about it?
[22:52] <brainwash> I did not expect that
[22:53] <brainwash> but we do include many packages
[22:55] <brainwash> and we can reduce the size by dropping xscreensaver :)
[22:58] <knome> Unit193, for this, and the other
[22:58] <knome> would it help to merge stuff i was able to drop a html comment in a file where you needed to drop stuff?
[22:59] <knome> and could we avoid having to have multiple files per thing then
[22:59] <knome> because i just found out how to leave comments.
[23:03] <Unit193> Hmm?
[23:03] <Unit193> ochosi: Normal size is within 800, 900+ is kind of big.
[23:04] <knome> Unit193, i can make xsltproc output html comments which you could then regex-replace
[23:05] <Unit193> Is that the best way we can do? :/
[23:07] <knome> the other option is to replace the translator-credits -string with a new, docbook markup one
[23:07] <knome> and let xsltproc then create the html from that
[23:08] <knome> either way, we need to do some replacing.
[23:08] <knome> but that obviously doesn't apply for the language listing.
[23:08] <knome> or, well, it could
[23:08] <knome> in some funky way.
[23:14] <ochosi> Unit193: dunno, i just expect something <1gb :)
[23:15] <ochosi> think i might've finally found a viable workaround for the cut buttons bug
[23:20] <brainwash> this really seems to bother you
[23:20] <ochosi> yeah, it does
[23:20] <ochosi> but i think i've fixed it now
[23:20] <ochosi> (i hope9
[23:20] <ochosi> )
[23:20] <ochosi> it's not like things never bother me
[23:21] <brainwash> :P
[23:22] <brainwash> so the greeter runs fine now?
[23:22] <brainwash> well, exits fine I mean
[23:22] <ochosi> i dunno, i haven't had time to look at that at all
[23:23] <brainwash> and the seamless transition?
[23:23] <brainwash> should be enabled if your system is up-to-date
[23:24] <ochosi> yeah, i have autologin on though
[23:24] <ochosi> and i use an external monitor, so i rarely see i
[23:24] <ochosi> t
[23:25] <brainwash> oh :/
[23:28] <brainwash> any idea why we even ship ibus?
[23:29] <Unit193> I purge it. :P
[23:29] <ochosi> no, actually i have been wondering about that myself
[23:29] <ochosi> it's a bit annoying and uncalled for, having it sit there in the systray by default
[23:30] <brainwash> and it behaves strange sometimes
[23:30] <Unit193> http://paste.openstack.org/show/VbqkpoXnQlgAH1DJfZIF <<< purgelist
[23:30] <ochosi> yeah, i've been wondering whether it's part of elfy's keyboard-layout headache
[23:31] <brainwash> it should be optional in my opinion, so disabled by default
[23:32] <ochosi> you could do a merge-request for xubuntu-default-settings with that
[23:32] <ochosi> so at least the trayicon is hidden by default
[23:34] <brainwash> maybe, but I'm not sure about the pros and cons
[23:34] <brainwash> there are people out in the world who benefit from ibus
[23:34] <brainwash> well, I hope
[23:36] <brainwash> Unit193: gnome-bluetooth?
[23:36] <brainwash> and what is the deal with gnome-themes-standard?
[23:36] <brainwash> do we need that?
[23:37] <Unit193> Not installed, only thing that is close to that name: libgnome-bluetooth11
[23:38] <Unit193> Also, purgelist will change from computer to computer, I can pull my other one later.
[23:38] <brainwash> gnome-bluetooth <IP_ADDRESS>-0ubuntu4
[23:38] <brainwash> daily iso
[23:39] <brainwash> it does not get installed?
[23:39] <ochosi> i think we need gnome-themes-standard for a11y
[23:39] <ochosi> it contains the contrasty themes
[23:39] <slickymaster> knome: regarding your question, I don't see anything major raising between now and doc freeze, besides your revamp of the start page
[23:39] <Unit193> brainwash: Maybe I misunderstood, why were you pinging me with it?
[23:40] <slickymaster> so, IMO I think a call for translators is something to be thinking about
[23:40] <Unit193> brainwash: Also, the size should drop (as I've been told) because we'll lose py3.3, just keeping 3.4.
[23:40] <brainwash> Unit193: saw the package on the iso package list and not on your purge list
[23:41] <knome> slickymaster, that's landed already though
[23:41] <Unit193> OK, right.  Yes, it wasn't installed so I didn't purge it.  Double checked and isn't installed now.  In do-release-upgrade, it gives you a list of what it's doing, I keep that list and review while it's updating (but, could have missed it.)
[23:41] <brainwash> ah ok
[23:42] <slickymaster> answering as I go through the logs
[23:43] <Unit193> brainwash: Thanks, any other thoughts?
[23:46] <brainwash> Unit193: maybe some unneeded fonts
[23:47] <slickymaster> so knome, regarding translator credits we are definitely going with the Makefile solution, right>?
[23:49] <slickymaster> knome: as for the installer slideshow sprint, for me, monday would be the best solution
[23:51] <slickymaster> hmm I see now that it's scheduled for friday at 17:00 UTC. No problem, I'll moce some things around to be able to make it
[23:52] <knome> slickymaster, thanks
[23:52] <knome> slickymaster, re: translator credits: yeah, we want them to be built always when the package is built
[23:52] <knome> to keep them current
[23:53] <jjfrv8> knome, I've been through all the remaining chapters. seven of them need the settings manager entity change...
[23:53] <jjfrv8> two chapters need to have refs to screensaver removed...
[23:53] <knome> okay
[23:53] <knome> that sounds fair
[23:53] <knome> but nothing too major in the way i was thinking
[23:54] <jjfrv8> doesn't look like it
[23:54] <knome> but let's get it done ASAP so people do not need to translate sections that we will then delete
[23:54] <jjfrv8> I can knock some of them out tonight
[23:54] <knome> nice
[23:55] <slickymaster> jjfrv8: if you cab't manage to do them all, ping me here and tomorrow I'll do the remaining ones
[23:56] <slickymaster> s/cab't/can't
[23:56] <jjfrv8> slickymaster, will do
[23:58] <brainwash> ochosi: bug 1289563
[23:59] <brainwash> but shouldn't light-locker recommend -settings?
[23:59] <brainwash> or suggest


[18:42] <erle-> which kernel module is in charge for cpu frequency nowadays
[18:42] <erle-> ?
[18:42] <erle-> (recent i7)
[18:57] <apw> intel-idle


[00:00] <brainwash> because people might install light-locker on non xubuntu systems
[00:05] <brainwash> I would like to revert the "invalid" status, just not sure what your thoughts are
[00:07] <ochosi> personally i'm not sure whether people really *need* the UI
[00:07] <ochosi> the settings are actually quite simple
[00:07] <ochosi> and anyway, that would be up to the ubuntu packagers who maintain light-locker
[00:08] <brainwash> so it's "whishlist"
[00:08] <ochosi> i don't see any trouble in adding it as a recommend
[00:08] <ochosi> so if you want, re-assign it to light-locker as wishlist and comment on why you do it
[00:09] <brainwash> because of the initial bug description :D
[00:27] <brainwash> ochosi: can you please remove light-locker-settings from the Affects list
[00:38] <brainwash> bluesabre: do you consider to fix bug 1280607 for trusty?
[00:38] <brainwash> or are there some drawbacks when you switch to python3?
[00:39] <bluesabre> brainwash: a lack of python3-zeitgeist
[00:39] <bluesabre> but thats not a necessary item
[00:39] <bluesabre> so I am going to discuss that with Noskcaj
[00:39] <brainwash> no one likes zeitgeist anyway :)
[00:40] <brainwash> but maybe the problem could be fixed in python2
[00:41] <bluesabre> maybe, just need some investigation
[00:41] <brainwash> yeah, worth a try
[01:11] <bluesabre> lderan: https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1291699
[01:40] <jjfrv8> knome, pushed the MP with screensaver removed from chapters 11 & 12. That latest MP includes the changes in my earlier one...
[01:41] <jjfrv8> so if they look good, I guess you only have to merge the latter one.
[01:42] <jjfrv8> slickymaster, I think all that's left to do is fix the settings manager references in the following chapters:
[01:42] <jjfrv8> 2, 7, 8, 9 & 13
[01:47] <jjfrv8> slickymaster, chapter 7 has an 'ndisgtk' entity for which I haven't yet created the 'wm-' counterpart.
[01:48] <jjfrv8> slickymaster, so if you get around to doing that chapter, you will have to create that entity.
[01:50] <jjfrv8> knome, all those ^^ changes should only be adding icons and shouldn't affect translations - unless I've overlooked something.
[01:53] <knome> i'll do a test build
[01:53] <knome> the entities file messed up some of the translations earlier, but that's now fixed
[01:53] <Unit193> jjfrv8: See my ping?
[01:53] <knome> was something easy to overlook, inheriting in multiple levels
[01:59] <jjfrv8> Unit193, yes, thanks for the offer. I haven't been running makes on the final versions before I push, though.
[02:22] <Unit193> jjfrv8: That'll be in the next proposal anyway, so some testing there might be good.
[02:23] <jjfrv8> ok, will check it out.
[02:34] <micahg> hrm, sorry I miseed the meeting
[02:39] <bluesabre> hey micahg, are you terribly busy?
[02:40] <bluesabre> I've created the package for shimmer-themes-1.7.1
[02:40] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1291739
[02:40] <bluesabre> I don't suppose you could upload it?
[02:43] <micahg> I think I have to reproduce that one to upload since it needs the orig tarballs
[02:44] <micahg> hrm, that's an interesting branch
[02:45] <micahg> bluesabre: is there somewhere I can verify the tarballs?
[02:47] <Unit193> bluesabre: I just attached everything to the bug with those type of things.  Sometimes they'll work if you can  uscan  the orig.
[02:48] <bluesabre> micahg: what do you mean?
[02:48] <bluesabre> this package has always been complicated, I had to do the same with shimmer-themes-1.6.2
[02:49] <micahg> bluesabre: are the tarballs tagged somewhere like git?
[02:49] <Unit193> Oooh, there was a way to work with multi-origs, if I could just remember how...
[02:49] <bluesabre> oh yes, https://github.com/shimmerproject
[02:49] <bluesabre> each tarball is based on the latest download
[02:50] <bluesabre> https://github.com/shimmerproject/Greybird/releases
[02:50] <micahg> ok, great
[02:50] <bluesabre> https://github.com/shimmerproject/Albatross/releases
[02:50] <bluesabre> https://github.com/shimmerproject/Bluebird/releases
[02:50] <bluesabre> https://github.com/shimmerproject/Numix/releases
[02:50] <bluesabre> https://github.com/shimmerproject/Orion/releases
[02:51] <bluesabre> the wallpapers one is carried from 1.7.0
[02:52] <Unit193> create-empty-orig, that's the one.
[02:52] <bluesabre> yeah, that's what we've got there
[02:52] <bluesabre> and from the last time I had to do this, https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402
[02:53] <bluesabre> I'll work at getting developer/upload rights before 14.10 :)
[02:53] <micahg> well, to prevent issues of mismatched tarballs, I have to verify the signatures against the originals
[02:54] <micahg> s/signatures/hashes/
[02:54] <bluesabre> makes sense
[03:12] <micahg> actually, let me do this in the morning, I need to be up early anyways
[03:14] <Unit193> Good rest, micahg.
[03:15] <bluesabre> thanks micahg, have a good night
[06:17] <Mirv> once again it's my patch pilot turn and there'a bunch of Xubuntu stuff here :)
[06:18] <Unit193> I didn't do it this time!
[06:18] <Unit193> \o.
[06:18] <Unit193> Mirv: Anything I can assist with, sir?
[06:26] <Mirv> at the rate pitti is doing what I believed to be preparing, no :)
[06:27] <Mirv> Unit193: maybe tell if you've checked throuh lp:~smd-seandavis/xubuntu-artwork/shimmer-themes-1.7.1 ? I'll be building and smoke-testing it, but I'm unfamiliar with it otherwise
[06:27] <Mirv> thunar and xfce4-places-plugin seem clear enough, I'll try to test the claimed fix somehow too
[06:32] <Unit193> Mirv: I am not, but could glance at http://irclogs.ubuntu.com/2014/03/13/%23xubuntu-devel.html#t02:43 for a little background.
[06:33] <Unit193> Wow, that's an amazingly small queue.
[06:40] <Mirv> Unit193: thanks for the background link, that should be enough
[06:41] <Unit193> Great!  (Mica may not have time, he's been under time constraints at work all this cycle.)
[07:01] <Mirv> ok, the tarballs match bit for bit the git upstream sources, check.
[07:04]  * Unit193 slips something else in. :P
[07:36] <elfy> ochosi: I posted in the testing forum re the keyboard thing - try and get more eyes on it
[07:37] <Unit193> elfy: See the short note about ibus and your issue?
[07:37] <elfy> yea fleetingly
[07:38] <elfy> which is great - but if it is ibus causing it - then that needs fixing
[07:43] <Unit193> Good to find out first, though.
[07:44] <elfy> no idea how we could do that
[07:50] <brainwash> elfy: purge it
[07:51] <elfy> yes - but ...
[07:51] <elfy> will the damage have already been caused
[07:51] <elfy> and you could purge the world and still be left with US layout
[07:51] <elfy> conspiracy theorists ...
[07:52] <brainwash> well, it's ibus.. you know, ipad, itunes,...
[07:52] <brainwash> so it has to be bad :D
[07:53] <elfy> didn't think of that iHype side to it :p
[07:55] <Unit193> Hah. :P
[08:09] <elfy> purging ihype works
[08:09] <elfy> I should have guessed at this poor attempt at world domination
[08:11] <elfy> not sure how to change what package the bug should be against
[08:12] <brainwash> ibus?
[08:12] <elfy> too early
[08:12] <elfy> what I meant was - I can't change the package that the bug is filed against :p
[08:13] <brainwash> which package is it?
[08:13] <elfy> at the moment console-setup
[08:14] <brainwash> mmh, isn't that used primary for the console..
[08:15] <elfy> couldn't tell you - I asked people at the time - best guess was that
[08:15] <brainwash> does your keyboard layout problem also affect the login greeter?
[08:16] <elfy> no
[08:17] <elfy> so - how to change the package? or is it because I'm not in some lp group that I can't
[08:18] <brainwash> or simply add ibus to the list
[08:18] <elfy> which I don't know how to do
[08:18] <brainwash> first time lp user? :D
[08:18] <elfy> you know what - sod it
[08:18] <elfy> bbl
[08:18] <brainwash> can you please link the report, so I can read it
[09:24] <ochosi> brainwash_: it's this one: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1284635
[09:25] <ochosi> yay, we really got a lot of stuff sponsored, we seem to be doing ok for UIF
[09:50] <bluesabre> yup, it's been moving pretty smoothly here lately :)
[09:51] <bluesabre> micahg, looks like you're off the hook :)
[10:04] <brainwash_> oh snap, greeter screen remained visible for some additional seconds after login.. now I got 2 window entries in my windowlist
[10:10] <brainwash_> ^ ochosi
[10:11] <bluesabre> brainwash_, I think the release I am working on should fix that, no?
[10:16] <brainwash_> well, I thought that it was caused by the indicator stack not exiting properly
[10:17] <brainwash_> checking logs now, noticed that lightdm runs this command: lightdm-unity8-session startxfce4
[10:17] <bluesabre> oh, that might be a fancy new regression
[10:18] <brainwash_> and unity-compositor is running too
[10:18] <brainwash_> o.o
[10:19] <brainwash_> I don't recall switching to mir/xmir
[10:20] <brainwash_> so it's xmir, on top of that the indicator stuff did not terminate properly
[10:20] <brainwash_> what a mess
[10:37] <brainwash_> bluesabre: so we maybe need to re-assign bug 1290575
[10:37] <bluesabre> d'awwww I just marked it as fixed
[10:37] <brainwash_> rebooted my system and now everything looks fine
[10:38] <brainwash_> partially fixed :)
[10:39] <brainwash_> the greeter is not the main target now (hopefully)
[10:39] <bluesabre> gppd
[10:39] <bluesabre> good
[10:39] <ochosi> haha, fun
[10:42] <brainwash_> no way.. I did not even notice that xmir is now activated on my system
[10:43] <brainwash_> but it may be unrelated and there is something wrong in lightdm itself
[10:44] <brainwash_> ochosi: do you have xmir activated?
[10:44] <ochosi> nope, i can't imagine
[10:44] <brainwash_> because you've also confirmed this problem with the 2 empty windows
[10:45] <ochosi> yeah, but i don't have xmir installed
[10:45] <ochosi> so how would i have it activated
[10:45] <ochosi> but yeah, it does seem like a lightdm regression
[10:45] <brainwash_> nice
[10:46] <brainwash_> finding the culprit is not that easy in this case :)
[10:50] <ochosi> anyhoo, please report your findings on the bugreport and then let's ask robert about it
[11:19] <knome> forestpiskie, commented on bug 1277154
[11:21] <brainwash_> maybe we could drop bug 1271883 from the blueprint list
[11:22] <knome> bug 1271979 too
[11:22] <brainwash_> yeah, that's minor stuff and upstream needs to decide
[11:23] <knome> bug 1271883 would be nice to get fixed though
[11:24] <knome> it's minor too, but it's still... annoying
[11:24] <brainwash_> it has been always like this
[11:24] <knome> does it mean it's not a bug?
[11:25] <brainwash_> I think it's not editable to prevent the user to add like 100 workspaces at once and crash the whole thing
[11:25] <knome> maybe it should be a different kind of widget then
[11:27] <brainwash_> I don't expect any change
[11:27] <knome> i don't expect either, but it's not an invalid bug either
[11:27] <brainwash_> no, more like "wishlist" :)
[11:28] <brainwash_> the context menu of xfdesktop also only allows the user to add/remove workspaces one by one
[11:29] <brainwash_> that's fine for 99.9% of all users
[11:30] <knome> that's not the point
[11:30] <brainwash_> I know
[11:30] <knome> the point is that if there is a widget that normally allows inserting numbers, people would expect it to allow it now
[11:30] <brainwash_> I mean that no one will complain about this bug
[11:30] <knome> and if it doesn't...
[11:31] <brainwash_> it's not a deal breaker
[11:31] <knome> no
[12:00] <brainwash_> Unit193: xmir is now enabled by default here, lightdm does not seems to respect the 10-unity-blabla.conf file
[12:02] <brainwash_> I've installed it manually ofc
[12:03] <brainwash_> and disabled it via the conf file long time ago
[12:39] <Unit193> #type=unity no longer works?  Hah, either bug or #ubuntu-mir
[12:41] <Mirv> I noticed there was recently an update to move the unity conf file to a location from where it actually gets removed when the package gets removed
[12:41] <Mirv> right, this one https://lists.ubuntu.com/archives/trusty-changes/2014-March/011557.html
[12:42] <wickz> after install autoresize the system won't restart.  Vm seems to freeze.  Happens intermittently on i386 test.
[12:42] <Unit193> brainwash_: ^
[12:44] <Unit193> Needs a better disable method, that way moving the file wouldn't matter. :/  (not that it'll likely happen again, but every upgrade in theory will override if it's not marked as a conffile.)
[12:45] <slickymasterWork> hey Unit193
[12:45] <Unit193> slickymasterWork: Howdy.
[12:45] <Unit193> Mirv: Thanks for linking.
[12:46] <brainwash_> ah, thanks
[12:46] <Unit193> (I only checked the mir package, not that one. >_>)
[12:49] <Unit193> Uhh, it's not marked as a conffile, I'd purge it.
[12:51] <Unit193> Mirv: Because it's in /usr/share, and not otherwise marked as a conffile, that means any changes to it are ignored as the file is "reset" with any updates, right?  Or, is that any updates where the file is different?
[12:51] <Unit193> (sorry for bugging.)
[12:55] <knome> anybody who can explain thoroughly what you need to do in order to be able to translate our docs?
[12:56] <knome> http://pad.ubuntu.com/Xubuntu1404DocCallTranslators
[12:57] <Mirv> Unit193: your understanding is as good as mine, the conffiles always require some pondering :) maybe that particular conf file is thought to always remain constant
[12:59] <Unit193> It's in the instructions for how to disable it, but perhaps.
[13:00] <Unit193> Thanks.
[13:34] <brainwash_> knome: bug 1260341 is a high priority one, is this really appropriate?
[13:36] <brainwash_> we can fix it easily in ubuntu, not sure what upstream thinks about it and how long it will take to get it approved
[13:38] <brainwash_> and it's not a regression or something like that
[13:42] <Unit193> Hmmm, got  xfdesktop crashed with SIGSEGV in xfce_desktop_refresh()  on login last night.
[13:45] <brainwash_> Unit193: create a report
[13:45] <Unit193> Could, but can't report to LP, PPA'd.
[13:46] <brainwash_> update your ppa
[13:47] <brainwash_> http://git.xfce.org/xfce/xfdesktop/commit/?id=6583a1a632779e72ba6ecfa32a10f30980081876
[13:50] <Unit193> Dowh.
[13:51] <elfy> knome: yes - saw that
[13:53] <Mirv> ok, thanks folks, see you again probably during my next patch pilot or so ;)
[13:54] <Unit193> :)
[13:54] <Unit193> Plan is to stick with .10 appfinder, right?
[13:58] <Unit193> http://git.xfce.org/xfce/xfce4-appfinder/commit/?id=8ef194e8fbf1652b27cf26c0a519c9be08631964 needless to say, this interests me.
[14:23] <Unit193> Debugging. \o/
[14:23] <Unit193> brainwash_: Have a beginners guide to debugging, or anything else written on the subject.
[15:10] <schproodle>  bug 1260341
[15:11] <schproodle> testing ristretto: http://packages.qa.ubuntu.com/qatracker/milestones/306/builds/55995/testcases/1600/results
[15:12] <schproodle> several problems:  do I file a bug for the testcase or for ristretto?
[15:13] <GridCube> did you had a problem with the testcase?
[15:14] <schproodle> well what fo you mean by "testcase".  The instructions seem OK but there were many progblems with ristretto according to the instructions
[15:14] <schproodle> I am here: https://bugs.launchpad.net/ubuntu-manual-tests/+filebug
[15:15] <GridCube> then the bug should be on ristretto
[15:15] <schproodle> looks like the place to list problems
[15:16] <GridCube> if you find a typo on the testcase, or it makes a reference to something that you can't find, or makes no sense, then thats a testcase bug, if you find a bug in the program the testcase asked you to test, then the bug is in the program and should be reported accordingly
[15:16] <GridCube> :)
[15:16] <slickymasterWork> schproodle: what GridCube was asking you is if you think the issue concerns the testcas per si or oth the problem is specific to ristretto
[15:17] <schproodle> both, probably
[15:17] <schproodle> Bug 1292025
[15:18] <GridCube> exactly, if the testcase says "click on the + icon" but the plus icon is not there, then the bug can be in either, now if the + icon is there and the program fails, then the bug is on the program
[15:18] <schproodle> oh, status new
[15:18] <GridCube> schproodle, you have to give it a time to process
[15:19] <schproodle> yeah
[15:19] <schproodle> gotta do both then eh
[15:20] <schproodle> I will try to sort that.
[15:22] <schproodle> OK 'Ubuntu Manual Tests" bug AND ristretto bug with ubuntu-bug
[15:22] <schproodle> that it?
[15:23] <GridCube> i would guess, remember to add those numbers to your report on the tracker
[15:24] <schproodle> OK will do.  Thanks :)
[16:02] <schproodle> Bug #1292073
[16:03] <schproodle> Bug #1292073
[16:42] <slickymasterWork> schproodle: updated https://bugs.launchpad.net/ristretto/+bug/1292073
[16:45] <slickymasterWork> elfy: ^^^
[16:53] <elfy> slickymasterWork: see pm windows
[16:54] <knome> windows 8 prime minister edition?
[16:55] <elfy> brainwash_: I see you're aware of which bug I was talking about
[16:56] <brainwash_> yes
[16:59] <brainwash_> so lets blame ibus?
[16:59] <schproodle> Bug 1292070
[17:00] <schproodle> where does this report belong as it is not a testcase problem per se
[17:00] <schproodle> seems to involve several systems let alone ristretto
[17:02] <elfy> brainwash_: seems to be the case
[17:03] <elfy> purging ibus - then keyboard layout works fine without an mucking about with keyboard settings
[17:03] <brainwash_> bug 1291587 seems to be a similar case
[17:04] <brainwash_> ibus acting weird
[17:04] <elfy> yea I saw that one this morning - japanese one?
[17:07] <brainwash_> no
[17:08] <elfy> ok - sure I saw it - also saw a similar one but japanese
[17:09] <slickymasterWork> elfy: I'll have a MP for you to review, about what we were talking, by tomorrow
[17:10] <elfy> it'll be the weekend
[17:10] <slickymasterWork> thank god ;)
[17:16] <slickymasterWork> bbl ->
[17:19] <elfy> brainwash_: mmm - I'll boot todays daily and see if that's occuring - it definitely wasn't previously occuring
[17:19] <elfy> and I still have no idea how to change affected package in a bug
[17:19] <elfy> ;)
[17:20] <elfy> https://launchpadlibrarian.net/169356804/Screenshot%20-%2003132014%20-%2001%3A49%3A24%20PM.png
[17:21] <elfy> when I was fiddling about yesterday with that - I never actually saw the GB option - just the US one
[17:27] <brainwash_> so GB could not be added via "Add"?
[17:27] <elfy> not seeing that here
[17:28] <brainwash_> what about other variants of "en"?
[17:28] <elfy> brainwash_: no - you can add it fine via keyboard settings - and it works
[17:28] <elfy> but doesn't show in that ibus notification
[17:29] <brainwash_> so we need to discuss the pros and cons of ibus in xubuntu
[17:29] <brainwash_> and why it is enabled by default
[17:30] <elfy> I've just added GB and Belgian - neither show - looks like it's trying to
[17:30] <brainwash_> run "ibus-setup"
[17:31] <elfy> http://imagebin.org/299150
[17:31] <elfy> see above the US - looks like an odd area of white above a seperator
[17:31] <brainwash_> but the settings dialog is from Xfce, the tray icon from ibus
[17:31] <brainwash_> both are not in sync
[17:31] <brainwash_> so please run "ibus-setup"
[17:32] <elfy> and do what?
[17:32] <brainwash_> try to add another kb layout
[17:32] <elfy> ok that works
[17:33] <elfy> but that's a side issue in my opinion - my issue is that I install xubuntu or the other 2 - and the system then completely ignores what I've set it to
[17:34] <elfy> I don't care what ibus says - I want my installed system to be how I installed it - as would anyone else :)
[17:34] <brainwash_> because ibus knows better and ignores the user
[17:34] <brainwash_> :)
[17:35] <elfy> this has got indicator-sound-gtk2 for saucy written all over it :(
[17:36] <elfy> so how do you change the package affecting a bug then?
[17:36] <brainwash_> so it needs be discussed in the next meeting
[17:36] <brainwash_> you click on the little arrow next to the package name
[17:37] <brainwash_> now you can edit the package name
[17:37] <elfy> I guess so - not sure what other languages it affects
[17:38] <elfy> I can't click on arrows - only the text
[17:39] <brainwash_> https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1284635/+editstatus
[17:39] <elfy> yea - can see that
[17:39] <brainwash_> so the arrow is filtered in your browser?
[17:39] <elfy> filtered?
[17:40] <brainwash_> well, triangle pointing east
[17:40] <brainwash_> it's missing in your browser, or?
[17:40] <elfy> no triangle - I see for instance ibus>>Bugs>>blah
[17:41] <elfy> hover over the >> and nothing :) hover over ibus or Bugs and it's selectable
[17:41] <brainwash_> =S
[17:41] <brainwash_> no clue
[17:42] <elfy> http://imagebin.org/299153 http://imagebin.org/299154
[17:42] <elfy> :)
[17:43] <brainwash_> not there
[17:43] <brainwash_> the yellow line
[17:43] <elfy> oooh
[17:43] <brainwash_> :D
[17:43] <elfy> I see that now lol
[17:43] <brainwash_> the little triangle
[17:43] <elfy> yep - ok got it :)
[17:44] <brainwash_> but I already changed it some minutes ago :P
[17:44] <elfy> yea I saw that :)
[17:48] <elfy> added it to the agenda
[18:04] <elfy> brainwash_: what I'm unsure of is whether we had ibus and everything was fine and then we got it in notification area
[18:04] <elfy> all I know is I remember it going wrong when it showed up :)
[18:07] <knome> brainwash_, you at all familiar with ristretto?
[18:09] <knome> bug 1270894 sounds like just a redraw in the sidebar might be good
[18:10] <knome> the bug is nasty because when you scroll after changing the sort more (== advance to next image), the next image is shown correctly in the main area, but the sidebar has a wrong image highlighted
[22:37] <ochosi> sergio-br2: hey!
[22:37] <sergio-br2> hey! hello
[22:38] <ochosi> saw you're working on some stuff again :)
[22:38] <sergio-br2> yeah
[22:38] <sergio-br2> a little :)
[22:38] <ochosi> the file-roller icon is really not a prime concern of mine
[22:38] <ochosi> but i think it's just too much work if the icon is going to be more or less the same
[22:38] <ochosi> i talked to jimmac today about how they're maintaining the gnome-icon-theme
[22:39] <ochosi> it's a really interesting system
[22:39] <ochosi> they have all icons from one app in one file
[22:39] <ochosi> and then a script cuts them apart and puts them in the right place
[22:39] <ochosi> i think it'd be pretty neat, cause you always see the sizes next to each other
[22:39] <ochosi> only problem is migrating there
[22:39] <sergio-br2> is it possible do this with svg? or it's other type of file?
[22:39] <ochosi> it's all svg
[22:40] <ochosi> but i have to look into it a bit more before i can tell whether we can do it
[22:40] <sergio-br2> inside a tar or like that?
[22:40] <sergio-br2> ah, ok
[22:40] <sergio-br2> interesting
[22:40] <ochosi> it's one svg per icon-type
[22:40] <ochosi> e.g. one svg for all sizes of web-browser.svg
[22:42] <ochosi> and then the script chops them apart and puts them into the correct place as png
[22:43] <sergio-br2> are they in github?
[22:44] <ochosi> yeah
[22:44] <sergio-br2> found it
[22:44] <ochosi> also need to clone it
[22:45] <ochosi> haven't had time yet
[22:45] <bluesabre> brainwash_, Unit193: is there an existing bug for xscreensaver still being installed in trusty?
[22:47] <brainwash> bluesabre: bug 1291019
[22:47] <brainwash> 2 issues, 1 report
[22:48] <bluesabre> fair enough
[22:48] <bluesabre> suppose I can try to fix both at once
[22:48] <sergio-br2> dowloaded it, very interesting ochosi
[22:48] <ochosi> sergio-br2: yeah, i think it'd make maintenance a lot easier
[22:48] <ochosi> but we have to see whether we can get a hold of the migration script
[22:49] <ochosi> cause converting elementary-xfce to this format by hand would take ages...
[22:49] <bluesabre> time to make light-locker #1 :)
[22:49] <Unit193> Eh. :/
[22:49] <ochosi> yeah
[22:49] <brainwash> bluesabre: but calling light-locker-command also launches it, so I'm not sure if we should change the order
[22:49] <Unit193> ^
[22:51] <bluesabre> going to change it to light-locker-command, xscreensaver, gnome-screensaver
[22:51] <bluesabre> that should make it work more as expected, even with alternative environments
[22:52] <Unit193> bluesabre: See above, please.
[22:52] <brainwash> sergio-br2: I've uploaded a patched version of xfce4-settings to https://launchpad.net/~thad-fisch/+archive/test
[22:53] <bluesabre> brainwash: what do you mean by that?
[22:53] <brainwash> sergio-br2: it "should" fix bug 1260341
[22:53] <sergio-br2> great
[22:54] <sergio-br2> need help to test?
[22:54] <brainwash> sergio-br2: please test, you might need to toggle tap to click once, so the new settings take effect
[22:54] <sergio-br2> ok
[22:55] <sergio-br2> is it in repo?
[22:55] <brainwash> in my PPA
[22:56] <brainwash> bluesabre: I meant that if you run light-locker-command, it will start the light-locker process and use it to lock the screen
[22:57] <ochosi> does xscreensaver do the same?
[22:57] <bluesabre> ok... is that somehow a problem?
[22:57] <ochosi> (i personally think it's desirable that it starts the process btw)
[22:58] <brainwash> not sure, if it's a serious problem
[22:59] <Unit193> xscreensaver-command -lock
[22:59] <Unit193> xscreensaver-command: no screensaver is running on display :0.0
[22:59] <Unit193> So, xscreensaver first.
[22:59] <brainwash> xubuntu user A prefers xscreensaver and enabled the autostart launcher, but xflock4 will call light-locker
[23:00] <Unit193> brainwash: Thanks for pointing this out, I was unaware ll did this.
[23:01] <bluesabre> so, clicking the "lock screen" button should do nothing if the daemon is, for some reason, not running?
[23:02] <bluesabre> I prefer gnome and light-locker's aggressive, "if somebody tells me to lock, I am going to do it"
[23:02] <ochosi> yeah, i mean if ppl really wanna stick to xscreensaver they should uninstall light-locker anyway
[23:03] <ochosi> it's either: break light-locker if xscreensaver is installed as well
[23:03] <ochosi> or: break xscreensaver if light-locker is installed as well
[23:03] <Unit193> bluesabre: Perhaps, but then xscreensaver should be tried first, or else you may easily get stuck with light-locker (which was disabled), and xscreensaver running, and double locking.
[23:03] <ochosi> depending on whatever you put first in xflock
[23:04] <Unit193> Not precisely, if xscreensaver isn't running, it'll move on to light-locker.
[23:04] <brainwash> exactly
[23:04] <brainwash> the user can disable xscreensaver easily
[23:04] <brainwash> startup apps
[23:04] <ochosi> brainwash: the same is true for light-locker
[23:04] <Unit193> Whereas lightlocker will just launch, later after unlocking and walking away, the computer now will lock twice.
[23:05] <Unit193> ochosi: Clearly not.
[23:05] <ochosi> Unit193: there's a simple settings dialog for it, i don't know what else you'd want
[23:05] <ochosi> the same is true for xscreensaver
[23:05] <brainwash> light-locker-command -l launches light-locker
[23:05] <ochosi> in that sense they're on par
[23:05] <Unit193> ochosi: But if I disable it there, it won't disable then.
[23:06] <ochosi> who would have both installed? mostly upgraders i'd say
[23:06] <Unit193> killall light-locker;killall xscreensaver; light-locker-command -l && xscreensaver-command -l
[23:08] <sergio-br2> brainwash, even without your ppa, it now works. I'll try after, without virtualbox
[23:09] <brainwash> sergio-br2: ok, I'll wait for your test results then
[23:11] <Unit193> brainwash: hoho!  It's not quite as terrible as it sounds, light-locker-command -l doesn't seem to launch light-locker, just lock.
[23:11] <bluesabre> "lock"
[23:12] <ochosi> oh great, so brainwash has been bullshitting us again ;)
[23:12] <knome> oops.
[23:12] <bluesabre> goes to vt8, with session unprotected if light-locker is not running
[23:12] <Unit193> ochosi: No, he's still right, but just not terrible.
[23:12] <Unit193> bluesabre: Right.
[23:12] <bluesabre> ugh
[23:13] <Unit193> :D
[23:13] <brainwash> this whole screen locking discussion :D
[23:13] <Unit193> Indeed.
[23:13] <bluesabre> ochosi: can you and cavalier try to detect if light-locker is running, and not kick to vt8 if it is not?
[23:13] <bluesabre> then return error exit(1)
[23:14] <Unit193> bluesabre, brainwash, ochosi: Therefore, found a security bug before release, I'd call it a plus!
[23:14] <bluesabre> :)
[23:15]  * bluesabre will see if its easy to add
[23:15] <brainwash> Unit193: security bug? the lubuntu guys don't agree
[23:16] <Unit193> brainwash: Err, not sure if that's right, the actual dev did switch back to xscreensaver. :P
[23:16] <Unit193> (Saucy.)
[23:17] <brainwash> impressive
[23:19] <brainwash> Unit193: had to deal with xmir earlier today and it did not work properly with light-locker
[23:20] <sergio-br2> ochosi, the git repo from gnome-icon has the png too, did you see?
[23:20] <Unit193> Meh.  One thing though, must have gotten better since it took you a bit to notice.  Not that it matters in the least, but updated the xmir isos since .6 is out. :P
[23:20] <Unit193> brainwash: Did you see my chat with Mirv?
[23:20] <brainwash> about the conf file?
[23:21] <Unit193> And it being reverted on upgrade, yeah.
[23:21] <brainwash> xmir does indeed work better now, but I've noticed some strange screen flickering too
[23:22] <brainwash> so I was like "go away xmir!"
[23:23] <Unit193> Oooooh!  Can you try something for me with that? :D
[23:23] <brainwash> you are looking for test results?
[23:23] <bluesabre> :D
[23:24] <Unit193> http://sigma.unit193.net/configs/conkyrc_xmir
[23:25] <brainwash> you want me to test the shell command?
[23:26] <Unit193> Well, more the conky output, should be quite clear.
[23:29] <brainwash> it will take some time until I can give you some feedback
[23:29] <brainwash> test system is currently being abused for "linux" gaming
[23:30] <Unit193> Hah, nice.  (Also, the idea is displaying red and text for no mir, green and text for xmir.)
[23:31] <brainwash> I like the idea
[23:31] <ochosi> bluesabre: will have to check how or gnome-screensaver handled this
[23:32] <bluesabre> gnome-screensaver launches itself
[23:33] <ochosi> yeah, but *how* ;)
[23:33] <ochosi> i didn't consciously bump that part out
[23:33] <bluesabre> good question
[23:34] <bluesabre> the lazy solution, use a singleton
[23:34] <bluesabre> thats probably how they do it :)
[23:34] <ochosi> a singleton?
[23:35] <bluesabre> https://en.wikipedia.org/wiki/Singleton_pattern
[23:36] <ochosi> oh meh, lotsa reading
[23:36]  * ochosi goes back to snacking
[23:37] <Unit193> Snack, food, good plan.
[23:37]  * Unit193 ->
[23:37] <ochosi> :)
[23:40] <bluesabre> ugh, attempting to do this without boost looks like a beast
[23:40] <ochosi> i don't seem to understand what you're saying well tonight :)
[23:41] <bluesabre> :)
[23:41] <bluesabre> short version, I'd much rather do this in python
[23:41] <bluesabre> :)
[23:42] <ochosi> haha
[23:43] <brainwash> Unit193: http://en.zimagez.com/zimage/xmir.php
[23:43] <brainwash> and red when it's not running
[23:44] <ochosi> so where do you have this label?
[23:44] <Unit193> Just how it should be. :D
[23:46] <brainwash> ochosi: on the desktop
[23:51] <ochosi> is it that hard to tell initially whether XMir is running?
[23:52] <ochosi> (it lead to such disturbing behavior here last time i tried that i'm sure i'd notice)
[23:57] <brainwash> notice visually?
[23:57] <ochosi> two cursors, laaaaags, this sort of stuff
[23:57] <brainwash> not anymore
[23:58] <ochosi> also with nvidia propr drivers?
[23:58] <brainwash> but there is some screen flickering
[23:58] <brainwash> only KMS drivers are supported
[23:59] <ochosi> hmyeah, nouveau doesn't work well for me