[00:39] <Unit193> That sounds important to pick up.
[05:12] <flocculant> ali1234: :)
[06:40] <flocculant> ali1234: also - 3 dbus timeouts on daily today 
[06:48] <flocculant> knome: not sure what the craic is, but bug 1754836 is refusing to show up on the tracker
[06:48] <ubottu> bug 1754836 in bluez (Ubuntu) "Xubuntu: ERROR:dbus.proxies:Introspect error on org.bluez:/org/bluez: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)" [Critical,Confirmed] https://launchpad.net/bugs/1754836
[08:14] <EASTERBUNNY__> IRC.SUPERNETS.ORG #SUPERBOWL BEST IRC NETWORK FUCK YOUR NETWORK
[08:14] <EASTERBUNNY__> NO SOFTCHATS HUGBOX TRANNIES BIBLETHUMPERS OR OPALS ALLOWED HERE
[08:14] <EASTERBUNNY__> YOU'VE SPENT YOUR ENTIRE LIFE HIDING IN SHITTY CHANNELS FOR WHAT
[08:14] <EASTERBUNNY__> YOUR IRC NETWORK IS TERRIBLE NO ONE CHATS THERE COME CHAT HERE 
[08:14] <EASTERBUNNY__> GET THE FUCK ON THIS IRC NETWORK RIGHT NOW YOU FUCKING PUSSY ASS
[08:14] <EASTERBUNNY__> THIS ISNT YOUR DADS FOOTBALL CHANNEL THIS IS REAL CHATS 24/7 365
[08:14] <EASTERBUNNY__> WE TAKE CHATS TO A NEW LEVEL, SOMETHING YOU'VE NEVER SEEN BEFORE
[08:14] <EASTERBUNNY__> DalekSec GridCube hggdh finsternis ali1234 Zren knome aaronraimist J21 bluesabre cruxeternus pleia2 ninetls benoliver999 acheronuk yofel cyphermox ubottu vinzv flexiondotorg akxwi-dave dkessel meetingology WillDuckworth nikow1 ubuntulo1 schuelle1 micahg Woowoo678 el wxl sakrecoer ochosi harrow nanotube mhall119 Logan SwissBot ubot9 paolo flocculant andrzejr sorinello alynpost donofrio hilpv torv 
[08:17] <flocculant> if only I wasn't an adult
[09:51] <bluesabre> Pretty sure I have in fact seen that before
[10:01] <flocculant> hi bluesabre 
[10:05] <bluesabre> hi flocculant 
[10:15] <flocculant> seen what before btw? idiots or tracker :p
[10:15] <bluesabre> both of course
[10:15] <flocculant> :D
[13:51] <TJ-> Is there a way, from console, to query/set xfce4-power-manager settings? Specifically, the current monitor backlight brightness ?
[13:52] <ali1234> yes there is
[13:52] <ali1234> i forgot what it is though
[13:52] <TJ-> Is it something via DBus ?
[13:53] <ali1234> it's a command line tool that operates with dbus
[13:53] <TJ-> i'm looking at the x.p.m. source but not found it yet.
[13:54] <ali1234> xfconf-query
[13:54] <TJ-> I've discovered the issue I've been debugging is due to the user-session, after a lid-close suspend has resumed, is setting the backlight to 0, so from a console I want to 'poke' it back to visible to get some more idea where the problem is
[13:55] <ali1234> that bug still exists huh?
[13:55] <ali1234> i thought that was fixed a couple of times...
[13:56] <ali1234> xfconf-query -c xfce4-power-manager -l
[13:58] <ali1234> also there is the raw kernel interface /sys/class/backlight/*/brightness
[13:59] <TJ-> it's not the kernel setting that's the problem, it's just the user session on resume
[14:00] <TJ-> E.g. when this happens the greeter/lock-screen is fine on vt8, consoles on ttys, but as soon as I authenticate and it switches back to vt7 it goes blank (which I now know is because it is setting the backlight brightness to 0 when switching to tty7)
[14:00] <ali1234> yes but if you just want to override it, the kernel is the fastest way
[14:01] <ali1234> whatever controls the backlight knows when you switch vt
[14:01] <TJ-> Doesn't look like x.p.m. has an actual 'brightness-now' setting, I wonder if the taskbar icon's display brightness has a node I can poke
[14:02] <TJ-> you're missing my point. I can be on a visible tty1-6 no problem, the moment I switch to tty7 (vt7) it resets the backlight brightness to 0, when I switch back to the tty1-6 it sets the original brightness
[14:02] <ali1234> yes, because it knows what vt you are on
[14:03] <ali1234> it just has the wrong idea about what the brightness should be
[14:03] <TJ-> it feels like - only for the lid-close event - it's not clearing the visible flag in some instances
[14:03] <ali1234> you can't control that externally
[14:04] <TJ-> I'll drop some debug on the state of the priv->visible flag to track if that's the problem
[14:04] <TJ-> Thanks for the pointer to xfconf-query, that's really useful
[14:05] <TJ-> I'm going to try changing the sysfs brightness from SSH whilst vt7 is active
[14:07] <TJ-> this is interesting; sysfs brightness can be set but actual_brightness doesn't change from 0
[14:08] <TJ-> ahhh! it's affecting bl_power. =0 when on vt7 and =4 when on a console
[14:13] <TJ-> ha, got it back-to-front. bl_power=4 when its blank, bl_power=0 when a console is visible. Still don't seem to be able to override the vt8 setting though, it's changing it back from 0 to 4 immediately
[14:32] <TJ-> ahh, xfpm-brightness.c is writing to .xsession-errors "No outputs have backlight property" ... I'll drop a delay loop in there see if it is a timing issue
[15:54] <pleia2> support ticket open on our dev.x.o vps, it's having sadness this morning
[15:54] <pleia2> "We have detected an issue affecting the physical host your Linode resides on."
[15:58] <TJ-> Hmmm, not sure what's going on here. Noticed that sometimes, when on a console or SSH, if I do 'systemctl restart lightdm' it kills the console/ssh session and I have to log-in again.
[16:04] <ali1234> could be seat confusion
[16:04] <ali1234> lightdm had some race conditions a long long time ago, where it would re-use the seat before it was freed, leading to it getting freed after you logged in
[16:05] <ali1234> let me see if i can find the bug, it might be useful to look at the lightdm logs
[16:07] <TJ-> thanks... seems like I'm collecting more bugs than I'm fixing right now!
[16:08] <TJ-> I've done something that is causing light-locker to exit prematurely but not sure what; nothing in the log to say. 
[16:08] <ali1234> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1256150
[16:08] <ubottu> Launchpad bug 1256150 in lightdm (Ubuntu Trusty) "Xorg guest session fails to start if the user has logged out and logged in again" [High,Fix released]
[16:08] <ali1234> also this https://i.imgur.com/miVHGTP.gifv
[16:14] <pleia2> vps has recovered
[16:15] <TJ-> No, that bug doesn't match. Can't see one that matches right now but I'll leave that to one side whilst I chase this missing backlight issue
[16:18] <ali1234> it is possible that the two are related
[16:19] <ali1234> like, maybe it's confused about which vt woke up, so doesn't set the backlight properly and also logs you out of the one it thinks it should set the backlight on... something weird like that
[16:19] <ali1234> it's a long shot but worth keeping in mind
[16:20] <ali1234> there's also that bug where sometimes the installer doesn't correctly switch to the vt where the message "please remove the install media and reboot" is displayed
[16:20] <ali1234> it seems to switch to a different one instead
[16:28] <TJ-> the lid-close>suspend>resume>vt7-no-backlight  definitely feels like some kind of race condition. Proving very difficult to debug
[16:48] <TJ-> hmmm, so light-locker exiting was actually a core-dump because I tried to deference a null pointer with a gs_debug() statement. So now I have resumed and VT7 is showing the "This session is locked, You'll be redirected to the unlock automatically in a few seconds" but it isn't doing that, and the mouse pointer is not movable!
[16:50] <TJ-> restart lightdm, it works fine now, doesn't make vt7 invisible. 
[16:59] <hilpv> I keep experiencing this as well, when I switch away from my PC with my KVM
[17:00] <hilpv> screensaver kicks in, and it seems unresponsive, switch to VT1, switch back to VT7 and it just says "This session is locked..."
[17:00] <hilpv> Then, darkness.
[17:01] <TJ-> My debug code is reporting, when switching /TO/ vt7: gs_manager_set_session_visible()=0 but I'm sure that should be 1, based on how the code handles the manager->priv->visible as a boolean
[17:01] <TJ-> which, if I'm interpreting that correctly, that it's doing the wrong thing
[17:16] <TJ-> ahh, false alarm, I'm printing the existing value not the value being passed into the function. Damn, that'd have been easy to fix.
[17:20] <TJ-> hilpv: Something for you to try. Before closing lid to suspend, switch to tty1 so vt7 is not visible. Close lid > suspends ... Open lid > resumes ... see if it behaves differently
[17:26] <TJ-> hilpv: need to do that from a restart of lightdm; once the session has problems it won't cure it