[00:00] Oh, right. Words. :( [00:01] saxx_: cool, how do you like it? [00:01] I've always loved it, but finally made the move and started using is as main OS [00:01] ochosi: I don't use it, so I'd not be the best example. [00:02] ochosi: I think we could likely spruce up bluesabre's file a tad? [00:02] sounds good [00:02] saxx_: awesome, welcome to full-time xubuntu usage :) [00:02] we just need an assignee to be able to track it [00:03] Thanks blue :) I'll be on here a lot for sure :) [00:03] we switch to compton in 14.10?! [00:04] cool, welcome saxx_ :) [00:04] Thanks ochosi :) [00:04] brainwash: no, but considering to provide a default config for ppl who wanna use it [00:04] brainwash: weren't you one of the compton advocates? :) [00:04] well, yes and no [00:05] people don't seem to wanna decide today [00:05] what kind of default config? hardware differs and demands special configuration options [00:05] brainwash: So easier usage, but not shipped. [00:05] or you mean shadow settings and so on? [00:05] yeah [00:06] exceptions for xfce4-notifyd and tabwin [00:06] whatever can be generically pre-configured [00:06] that's why we need a person in charge of that [00:06] i'm happy with anyone stepping up to do that tbh :) [00:06] I don't like the fancy stuff [00:07] so I don't feel like messing around with it [00:08] bluesabre: fwiw, the stuff i pushed to your phone wrt the lid-lock bug was relevant :) [00:08] i can repeat it here though, if you wnat [00:08] want/need [00:08] ochosi: I got it [00:09] ok cool [00:09] I'll try to hack on that a bit tonight [00:09] btw, caveat: could be that the xfconf variable isn't working so great even in the current patch [00:12] woot [00:12] :) [00:12] need to sit down and really hack on this [00:12] I wish the issue affected me so I could verify :D [00:13] hah, you wish?! :D [00:13] just get your old computer from the drawer [00:14] anyway, i gotta hit the sack now [00:16] seeya ochosi [00:16] night bluesabre [00:16] oh btw, there's still a parole branch (goto-feature) waiting for your review in case you're bored or something ;) [00:17] or yeah [00:18] I need to stop slacking! [00:18] hehe [08:31] heh, first one to complain about desktop wallpapers on login screen ;) [08:32] nah, there is even a bugreport about that [08:32] aha, haven't seen that [08:32] what'cha gonna do? [08:33] and we have a branch with a fix, i.e. an option to disable it [08:33] :) [08:33] oki [08:33] sounds good [08:33] so in 14.10 ppl will be able to switch it off [08:33] i now have way less hair [08:33] we should probably get the greeter-settings UI installed by default [08:33] just FYI [08:33] you mean then before you became XPL? [08:33] mhm, sounds sane [08:33] hah! [08:33] nah, since yesterday ;) [08:34] it's literally so *cool* [08:34] :} [08:35] what's up with the black screen fix? [08:35] well bluesabre returned a bit late last night, so we couldn't work on it together [08:35] right [08:36] wasn't there one ready already? [08:36] or didn't that fix it? [08:36] yeah, but one with drawbacks that was mostly a proof-of-concept [08:36] hmmh [08:36] it should test whether not inhibiting logind solves the problem [08:36] (and it does) [08:36] right [08:36] doing a proper fix is (as always) more work [08:36] of course [08:37] the main issue being not breaking xscreensaver [08:37] is it completely triaged now though? [08:41] i dunno, i'm less worried about the bug status then about fixing it [08:41] also the comments are still flowing in for it (which is annoying and a bit useless), so i stopped checking the bugreport [08:42] heh, well, it's not really about the bug status [08:42] i'm worried about fixing it too, and being completely triaged is a good thing for that === brainwash_ is now known as brainwash [15:42] omg, i wonder how ppl can think this is a good thing... http://worldofgnome.org/running-gtk-applications-different-themes-per-app/ [16:37] ochosi: no chance of that in xfce then :p [16:38] well you can do that already anyway [16:38] it's just a very silly thing imo [16:38] (even in gtk2) [16:41] well I'm glad I've never seen it ;) [16:46] ochosi, why would it be silly? don't the themes reside already in the system? is loading the themes for each applications counter productive? [16:57] why would you implicitly want to make your system not look consistent/integrated? [17:07] because not everyone like things to look the same all the time? [17:07] because some people might want to visually differentiate some applications from others visually? [17:07] i don't know [17:08] i used visually twice [17:10] :) [17:11] well anyway, ppl could and did always do this, i still think it's the worst [17:43] lost the sound indicator :( [17:50] :( [19:27] elfy: how did you lose it? [19:28] no idea ochosi [19:28] the others are there [19:29] not got around to checking updates [19:30] nothing apparent [19:30] odd [19:30] checked any logs yet? [19:31] just checked apt history log for today [19:31] so it just happened today? [19:31] yea - was there last night [19:31] humm [19:31] I know that - had recoccurence of the last 20% vol change making no difference [19:32] I'll check I didn't cause it === cyphermox_ is now known as cyphermox [19:38] ochosi: I guess that it did cause it :p [19:38] so it's back nowÃ [19:39] current choice is vol control that works from 20% -100% or no indicator [19:39] err, what? [19:40] I've got this again bug 1321485 [19:40] bug 1321485 in pulseaudio (Ubuntu) "No change to volume in lowest 20% of control" [Undecided,New] https://launchpad.net/bugs/1321485 [19:40] oh :/ [19:40] i wasn't aware of such a bug [19:41] hw related? [19:41] I had it some time ago - for time read couple of years - came back [19:41] ochosi: same hardware I have had since I started using ubuntu in 2007 :p [19:41] right [19:41] odd [19:41] and the ignore_dB does what exactly? [19:42] I have no idea what it does exactly software wise but it allows the vol keys to work properly down to mute [19:43] possibly something not matching in alsa and pulse [19:43] *shrug* [19:44] hmyeah, shrugging would also be my reaction :) [19:45] heh [19:45] I ought to really check in 14.04 [19:45] low volumes via keyboards isn't something I often do [19:57] pleia2, cool, xubuntu talks [19:57] well. almost [19:58] shall I remove (TODO: Link to docs for it). from the lightlocker article :p [19:58] yeah... [19:58] :P [19:59] good job reviewers! [19:59] * knome looks in the mirror [19:59] knome: haha, just a little xubuntu [19:59] ;) [19:59] screenshots and all! [19:59] hehe, indeed [20:00] done that then [20:00] lol [20:00] ta elfy [20:08] fwiw, is there a docs-link now? [20:14] http://docs.xubuntu.org/1404/guide-keeping-safe.html#lock-your-screen ? [20:19] mm, sounds okay to me [20:19] * knome tries to squeeze any sound of the URL but in vain [20:19] Clearly not using espeak. [20:20] mm [20:33] on a more serious note, is anyone here (apart from me) interested in setting up some sort of bug-bounty programme for xubuntu? [20:35] it's not a bad idea, but the bounty and target will be clearly defined and generally accepted by the team [20:35] what would the bounty be? some of the mag money? [20:35] I've just got some vague unease that's very hard to put into words [20:36] apart from a vague sense of unease ;) [20:36] way too much work to set it up and maintain such a system [20:37] does it need a high-leve bureaucratic system? [20:37] it should be fair and transparent [20:37] in what sense fair? [20:37] if the target is to fix a bug, it isn't fair for people who only have artistic talent [20:37] people should not abuse the system [20:38] which is why i said the bounty and target should be clearly specified [20:38] i think that elementary are using a third party site [20:38] i don't understand what kind of "system" we need here [20:38] just list things we want to be fixed, set bounties, and go [20:38] so i think there it is up to the users that can pledge bounties [20:39] right... [20:39] ochosi: like a "I want this fixed - here's x £'s" ? [20:39] social bounty then? [20:39] elfy: pretty much [20:39] knome: nope, $$$ [20:39] i mean, [20:39] mmm [20:39] social in the way that the xubuntu team isn't participating in paying the bounty [20:40] yea [20:40] i'd imagine there to be sites that allow doing that [20:40] yeah, i can find the elementary site... [20:40] just pick one that seems to work well, create a xubuntu tag or sth and announce it being "official", as far as there is anything official... [20:40] yeah, that could already be sufficient [20:40] and we can still advertise it as a team [20:40] that would be much better than getting involved with the system itself really [20:41] i mean "advertise"... [20:41] exactly [20:41] yeah, as much as we advertise other social media outlets etc [20:41] one downside being - with a finite amount of people looking at bugs - the emphasis could shift from xfpm to some random thing [20:41] sure [20:41] it's very democratic [20:41] if people want silly things.. who cares? [20:41] as long as it doesn't involve "by default in xubuntu" [20:41] but generally speaking it could also be that we lose interest in the fix and just give up on it :) [20:42] which i guess is something we should make a statement about [20:42] hang on [20:42] that's a bit premature [20:42] what is? [20:43] knome> which i guess is something we should make a statement about [20:43] well, i obviously meant if we set something up [20:43] that just assumes that ochosi> on a more serious note, is anyone here (apart from me) interested in setting up some sort of bug-bounty programme for xubuntu? is going to happen [20:43] https://www.bountysource.com/issues/357765-load-foreground-tab-from-cache-when-restoring-session [20:43] to state that there is no guarantee that pledges like "please install libreoffice by default in xubuntu" are not really valid... [20:43] this is an example ^ [20:44] so we stop fixing bugs until this bug bounty program goes live :) [20:44] one option is a system where the team can approve/decline any possible pledge [20:44] I think we should install libreoffice-calc and -writer by default [20:44] and this is how they do it in launchpad: https://bugs.launchpad.net/elementary/+bugs?field.tag=bounty [20:44] brainwash: hehe, or we pledge team funds instead of fixing annoying bugs ourselves ;) [20:45] i guess we need to vote on me registering the xubuntu project on that page [20:46] however, most/many bugs are Xfce upstream ones [20:46] oh, we can actually use "our" facebook account (in case we have one) for logging in [20:46] i think we should have a broader discussion before that :) [20:46] brainwash: yeah, sure, but we can always push them upstream [20:47] maybe get the Xfce devs and maintainers involved too? [20:48] https://www.bountysource.com/teams/midori/issues [20:48] as another example [20:48] brainwash: which xfce devs? :D [20:48] ochosi, https://lists.ubuntu.com/mailman/listinfo/community-announce [20:48] ochosi, ^ subscribe PLZ, it's a *very* low-traffic list [20:48] ochosi, last email in february [20:48] all of them.. show them some $$$ and they will start working again :P [20:48] knome: what for then? [20:48] ochosi, before that, november [20:49] ochosi, uds announcements and such [20:49] brainwash: unfortunately i doubt that... [20:50] but these people are usually the ones who can "easily" fix bugs in their software [20:52] we'll see, maybe they'll notice the bug bounty program and start fixing some bugs [20:52] the thing about bugs is that bugs are easy to fix [20:52] figuring out how to reproduce them is hard [20:53] and getting upstream to commit a patch is hard [20:53] so i think that a bug bounty site should roll over at each of these steps [20:53] ali1234: well the most effective way is becoming an upstream contributor [20:53] or fork [20:53] or talking to upstream devs directly somehow [20:53] meh, forking is meh [20:54] but it works.. sometimes [20:54] so for a new bug, the bounty would go up as people donate. once it can be 100% reproduced, whoever figured that step out gets the current bounty [20:54] then the counter starts again at zero until someone submits a patch [20:54] then it starts again at zero, whoever commits the patch upstream gets that bounty [20:54] right, i'm not sure users get that... [20:54] mmh [20:55] most ppl have no idea how these processes work [20:55] keep it simple [20:55] well you know what they say about fools and money [20:55] and they'd be frustrated to see their money go away without a fix [20:55] ali1234: there's a lot of both? :p [20:55] * ochosi actually doesn't know what they say about them... [20:55] they are soon parted [20:56] anyway the point is that this system rewards the actually hard part [20:57] if a bug is hard to reproduce and easy to fix, then whoever reproduced it gets the most reward [20:57] if it's easy to reproduce and hard to fix, the counter will go higher during the fixing stage [20:58] it's also intended that this is a system where anyone can donate to any bug at any time [20:59] yeah, but why wouldnt the person doing the hard part also do the simple part of fixing the bug? [20:59] that's a sort of logic that is over my head... [20:59] unable to? [20:59] maybe, but in that case they won't get any donations for the fix [21:00] only for reproducing it [21:00] ali1234, wouldn't *that* open room for playing the system? [21:00] if they try to game it by posting the reproduction steps and not the fix, then someone else can snipe them [21:00] "i reproduced it, now i'll wait until more pledges land until i fix it" [21:00] ali1234, except that the fixer "wouldn't get any donations for the fix" [21:00] as you said [21:01] so why would somebody *else* fix it? immediately? [21:01] -? [21:01] this sounds like things are going to slow down [21:01] ali1234: i dunno what bugs you have in mind specifically, but those you were working on lately are *technically* so hard to reproduce that i agree, that was the hardest part... [21:01] that will always be a problem with bounties [21:01] while it's not always fair, there should be just one bounty, for landing the final fix [21:02] that will result in many bounties never being paid [21:02] people who are experiencing the issue are most probably also willing to help debug/reproduce [21:02] well, too bad... [21:02] yeah, i guess that's okayish [21:02] it's not like people *want* to part with their money [21:03] anyway, i think that in the bountysource.com programme you can't set such finegrain control [21:03] but i can ask kalikiana, he has obviously used it [21:04] the problem with requiring landing the fix is what happens when someone posts a bounty that the upstream project will never accept? [21:04] well that's where xubuntu comes in imo [21:04] those bounties will just clog up the system [21:05] that's why i said something about the team accepting/rejecting new pledges [21:05] if it's a distro patch that gets applied in xubuntu and the money was pledged in the xubuntu project... [21:06] and if landing the fix gets the bounty, then project owners can game the system, by rejecting patches from others and fixing it themselves [21:07] i'd suggest we ask ppl who have used this system [21:07] or: one of these systems [21:07] also, note that the bounties mostly have symbolic value [21:07] xubuntu will never draw so much attention that we get substantial bounties (i guess) [21:08] getting 50$ for a fix is not a great incentive to "play the system" [21:08] also, you'll know as a maintainer that you'll probably never get a patch again from that person if you trick them out of their bounty [21:08] (it's like falsely attributing a patch to yourself in vcs) [21:08] What about bugs with no bounty? Won't those get ignored? [21:09] ali1234, err, are you suggesting we will create a system to be able to play it? [21:10] if anybody in the team did that, they should kicked hard in the lower back [21:10] money does weird things to people :( [21:10] like we are all here to make money :P [21:10] soon [21:10] just look at bitcoin [21:11] yes... but that hardly changed people who were working on things *already* [21:11] i don't really understand the argument [21:11] if xubuntu developers just wanted to make money out of xubuntu, they would have found a way already [21:11] or got lost [21:16] Some of us are very lost... [21:20] Unit193: they won't get ignored more than they do now i think === ubott2 is now known as ubottu === lderan_ is now known as lderan === dkessel_ is now known as dkessel [23:22] bluesabre: so let me summarize again... [23:22] what happens is this (as far as we know) [23:22] 1) user closes the lid [23:22] 2) xfpm notices the event and handles it [23:22] 3) it fires off xflock4, which calls light-locker [23:23] 4) light-locker initiates a VT switch by locking [23:23] 4) system goes to suspend [23:23] so as you can see, there are two 4)s [23:23] that is not accidental, but actually the problem [23:23] lol [23:24] these two things aren't handled well by a "stupid" bash script as xflock is one [23:24] logind always seems to handle the VT switch + suspending correclt [23:24] y [23:25] ok, so that's part of the story, now for the patch [23:25] it introduces a new xfconf-setting inhibit-logind [23:25] which does what, exactly? [23:26] so, we can mitigate this problem by *not* inhibiting logind in terms of handling the lid-close event (but only if 1) lid-close > lock settings is true in xfpm and 2) light-locker is in use) [23:26] the patch introduces a BIG logind-inhibit killswitch. so you can only decide whether logind handles all or none of these events: power-button, suspend-button, hibernate-button, lid-event [23:27] so we only want to make it take effect on the lid-event [23:27] the rest should be controlled by xfpm, because there's at least a settings UI for it (which there isn't for logind) [23:28] and last but not least, xscreensaver... [23:28] xscreensaver *needs* the xflock4 call from xfpm before suspending on lid-close, it doesn't listen to logind's lock signal (which light-locker does, if it's started with --lock-on-suspend) [23:30] yeah [23:30] all "clear"? :) [23:30] it's really quite the kerfuffle... [23:30] which is why I feel like light-locker should in fact be a bit smarter and toggle the setting itself [23:31] i only hope that we don't create a new problem with this [23:31] because: [23:31] 1) light-locker is set to lock the session on suspend [23:31] And for all purposes, gnome-screensaver == xscreensaver? [23:32] 2) xfpm is set to lock the session on suspend/lid-close [23:32] so if the lid-close event is inhibited i guess xfpm should also *not* actively lock the session [23:33] Unit193: no, i think gnome-screensaver actually *does* listen to the logind lock signal [23:33] (btw, don't hit me with the rod if it's not logind sending the dbus lock signal but something else) [23:33] Ah. I take it newer xscreensaver still doesn't? [23:34] yup [23:35] xscreensaver only does something if you call it specifically (or the timeout runs out) [23:35] I'd be in favor of the string option [23:35] or multiple bools [23:35] yeah, i think the string option is the sanest [23:35] xfce4-power-manager/logind/ [23:35] multiple bools have the advantage of not having to evaluate the string... [23:35] and then each of the possible settings there [23:36] yup [23:36] this seems more painful than ripping mate's display dialog out of mate [23:37] yeah, mostly because there are so many actors that need to react to one another [23:37] if only light-locker wouldn't have to switch VT [23:37] i wonder though [23:37] actors like hugh grant? [23:37] is eric around? [23:37] would it all be solved by using late-locking? [23:37] * knome hides and laughs [23:37] nope [23:38] late-locking still locks on lid-close I believe [23:38] yeah, true, it doesn't apply in this case [23:38] silly ochosi [23:38] eric is only around at very specific times of day, much like yourself ;) [23:39] :) [23:39] around 3-5PM UTC [23:39] so, how would you like to proceed, or knome/Unit193, thoughts? [23:39] well, fix it..? :) [23:40] :D [23:40] super-constructive as always :) [23:40] well, what do you expect from a non-technical guy at almost 3am? [23:40] bools sound sane to me [23:41] but i'm unable judge if there are drawbacks or not [23:41] kI think he's tired, he asked me too. [23:41] and whether they are bad enough to make the option not viable [23:42] bluesabre: the bools are easier to handle in settings-editor [23:42] yes [23:42] for those that need to re-enable logind-inhibition for xscreensaver [23:42] or actually [23:42] and easier to understand on the code level as well. [23:42] and no wondering what the possible options are [23:43] logind can still be switched to ON in xfpm with xscreensaver [23:43] or syntax, in some cases [23:43] it just needs to call xflock in this case [23:43] hah [23:43] i got it [23:43] finally [23:43] ok, listen up [23:43] :P [23:43] yes sir! [23:43] * ochosi hopes he'll make sense now... [23:43] * ochosi feels his hands are getting sweaty [23:43] probably not sir [23:44] ok, so the problem is not logind in a way [23:44] it's the lock signal [23:44] light-locker -> logind [23:44] xscreen-saver -> xflock4 [23:44] but, for xscreensaver it doesn#t matter whether logind sends the lock signal [23:44] it doesnt listen [23:45] * knome faints with "xscreen-saver" [23:45] so we can *always* uninhibit logind if the lid-close event is set to suspend and lock on suspend is on [23:45] in xubuntu, that is [23:45] upstream it'll be a different story [23:46] but i'll think about that tomorrow after multiple hours of sleep [23:46] sounds promising [23:47] well it should make things less compley [23:47] complex [23:47] less compley would be good [23:47] hehe [23:49] bluesabre: so, we need xfpm patched that if (lid-close-event=suspend && lock-on-suspend=TRUE) { !inhibit_logind } [23:49] and we need to re-enable --lock-on-suspend in light-locker(-settings) [23:49] fun [23:50] well the latter you've already done, no? [23:50] I think yes [23:50]