[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