[00:00] <TJ-> Unit193: thanks. I was going through the mass of packages that using --install-recommends pulls in. Shame it isn't possible to set that to only operate at the first level, rather than applying to all packages identified
[00:00] <Unit193> TJ-: Try: sudo apt install xubuntu-core^  and go through that list insead (or same with xubuntu-desktop), even with --no-install-recommends.
[00:01] <Unit193> But if you install via bootstrap, I'd *highly* recommend using the task over meta, even with --no-install-recommends.
[00:03] <TJ-> I was just exploring the options for slim vs fat; I've got 5 18.04 xubuntu laptops here and was checking what is really needed
[00:06] <Unit193> Oh, and there's an appendix in the Xubuntu docs you may want to see.
[04:36] <flocculant> !team | can people watch for final beta mail today and mail update to threads in dev and users please - I'll likely not see it till late today - thanks :)
[04:38] <flocculant> ochosi: if you're unable to do a meeting let me know and I will :)
[04:42] <flocculant> ochosi bluesabre - also apparently Laney was looking at various timeouts(said jibel) if either of you could ask sometime this week ?
[05:33] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 18.04 - i386 - i386 built.
[05:57] -SwissBot:#xubuntu-devel- ATTN: Xubuntu Core 18.04 - amd64 - amd64 built.
[07:51] <ochosi> flocculant: i think i can only ask someone else to schedule a meeting, i have no more wiki edit rights anymore
[07:51] <ochosi> -more
[07:52] <ochosi> we can schedule one for 10utc (so bluesabre can also make it) tomorrow or on thu this week
[07:57] <Unit193> Well, that's early.
[08:35] <ochosi> Unit193: ehat i meant was 22utc
[08:35] <ochosi> 10utc would actually be complicated for me with work
[08:40] <bluesabre> :)
[08:52] <ochosi> bluesabre: what would work best for you - tonight, tomorrow or thu? (always at 22utc)
[08:53] <bluesabre> ochosi: I think thursday would work well.
[08:54] <ochosi> k, then i only need to find someone with wiki edit rights...
[08:58] <bluesabre> ochosi: looks like I still have them
[10:20] <knome> ochosi, wait, what, why?
[10:25] <Unit193> Logged out?
[10:25] <knome> yeah, must be some kind of slackery
[10:26] <Unit193> Well, logged out is nearly the same as lost rights sometimes. :3
[10:27] <knome> :)
[10:30] <Unit193> subprocess call was too simplified, doesn't manage stderr so kind of wanders off.  This ends up somehow...Sounds like some sort of old, dark magic, but seems to apply.
[10:30] <Unit193> ...This may be the wrong channel.
[10:30]  * knome shrugs
[10:33] <Unit193> FWIW, I'm going with some sort of dark magic, because nothing makes sense of how this is actually happening, but seems to fix it.
[10:33] <knome> good good
[11:07] <ochosi> knome: i was only looking for someone to help me schedule the meeting for thu 22utc as i dont have edit rights in the ubuntu wiki anymore
[11:07] <ochosi> not sure if blues already took care of it
[11:07] <knome> i mean i can do it but i don't understand how you could not have the permission
[11:08] <knome> to 5 april?
[11:08] <knome> err, thu
[11:09] <knome> wiki updated as well as the team calendar
[11:09] <knome> (does anybody really use that btw?)
[11:09] <knome> also, it's after end of march and we still haven't published the results...
[11:09] <knome> of the wallpaper contest
[11:10] <ochosi> i use the calendar
[11:10] <knome> good
[11:10] <knome> then i'll keep on updating it
[11:10] <ochosi> thanks, i'll send out the announcement in a bit then
[11:11] <ochosi> hmright, the wallpaper contest
[11:11] <ochosi> i think i at least 'did my bit' by voting on all of them
[11:11] <knome> yes
[11:12] <knome> i think we just live with the fact that not everybody voted for each submission
[11:27] <knome> pleia2, did we want to send/offer paper certs for winners?
[11:35] <akxwi-dave> Well I voted for the ones I liked and didn't.. those that I wasn't bothered about I didn't vote
[11:38] <knome> akxwi-dave, the idea was to vote on all submissions :P
[11:38] <knome> but...
[11:38] <knome> i mean at this point you can either go do that or tell me to sod off
[11:38] <knome> ;)
[11:38] <knome> nothing is sent yet
[11:38] <knome> and my bluetooth mouse stopped working
[11:38] <knome> mehhh
[11:43] <knome> brb
[11:47] <akxwi-dave> oh ok, i'll go and vote on the rest then..  :-)  
[11:49] <knome> thanks
[11:50] <knome> i'll check if i need to change my mailing routine then
[11:50] <knome> (but it's ok)
[11:56] <akxwi-dave> all done
[11:56] <knome> thanks akxwi-dave 
[11:56] <ochosi> meeting mail sent
[11:57] <ochosi> weird, now i can in fact edit that page again
[11:57] <ochosi> sry bout the noise then
[11:58] <knome> akxwi-dave, and sorry, there was no change in the top 10 :P
[11:58] <knome> i mean technically there could have been.. but not in the order
[11:58] <knome> slickymaster: ping? :P
[12:28] <akxwi-dave> :-)
[15:12] <pleia2> knome: I don't think so
[16:50] <flocculant> ochosi: thanks :) I would have run one about the same time of week and at a time to suit bluesabre too - would have if you were busy
[18:03] <flocculant> bluesabre: well - that's just awesome then ;)
[18:05] <flocculant> not sure how you removed the packages - I tried from recovery session - that worked well ... friendly-recovery decided to not be and not respond to kbd - tried in a vm - same thing, managed to do it all prior to first login when there was no .xsession-errors
[18:05] <flocculant> and found the same as you 
[18:09] <flocculant> pleia2 knome - could you give beta testing some love on social stuff
[18:09] <flocculant> thanks :)
[18:10] <pleia2> yep
[18:10] <flocculant> I can do facepalm in a bit
[18:12] <pleia2> facepal...oh, hah!
[18:12] <flocculant> :)
[18:13] <pleia2> should I wait until they show up at http://iso.qa.ubuntu.com/qatracker/milestones/388/builds ?
[18:13] <pleia2> (was just looking at the mailing list post)
[18:13] <flocculant> nah - that's where they will be 
[18:13] <pleia2> people have short attention spans, if they see it now and click on it and empty, they won't come back until reminded ;)
[18:13] <flocculant> if we wait for that - who knows - we're not even re-building yet
[18:14] <pleia2> but there's nothing for them to do yet, right? or ..?
[18:14] <flocculant> pleia2: not at the moment
[18:14] <pleia2> I could do a "things will show up here, so get your testing systems ready!" tweet now
[18:14] <pleia2> then follow-up when it's alive
[18:14] <flocculant> ok 
[18:20] <willem> pleia2, flocculant If I  may be so bold: I think it's good strategy to first get a "process" signal out (we're about to do rebuilds, be prepared...kind of thing) and then when the builds are live the actual mails with links
[18:20] <willem> it would get my attention anyway :-)
[18:21] <pleia2> email I totally agree :) it's just hard with social media since people seem to click and act, if there's nothing to do right away we lose their attention
[18:22] <flocculant> I assume pleia2 meant willem there :p
[18:22] <flocculant> and even before they've rebuilt there's talk of respins
[18:23] <flocculant> and new kernel in -proposed
[18:23] <pleia2> https://twitter.com/Xubuntu/status/981235511674126336
[18:23] <pleia2> did similar on G+
[18:23] <flocculant> pleia2: thanks :)
[18:23] <flocculant> I'll likely wait for facepalm 
[18:24] <flocculant> that's even worse for involvement
[18:25] <willem> just liked the twitter message; so my 3 followers will be awake now ;-)
[18:25] <pleia2> hehe
[18:26] <flocculant> willem: I agree - though I have to say that ever the last 3 or 4 years we have tried many different approaches and unfortunately what I've taken from that is that generally our users think there is a software fairy that does it all for them while they sleep
[18:27] <willem> flocculant, I don't really blame them I think,
[18:27] <willem> : you are fairies of sorts. We, end users, don't see your processes, we don't see you work
[18:27] <flocculant> mmm
[18:27] <willem> we don't look you up here on irc
[18:28] <willem> because that's not a "natural" place to go for end users like me
[18:28] <flocculant> right
[18:28] <flocculant> but you can read e-mails?
[18:28] <willem> yes, that's true
[18:28] <flocculant> because all the people on both the lists - get those ;)
[18:28] <willem> yeah, forgot about that... hmmm 
[18:28] <flocculant> and we do the social media things 
[18:29] <willem> so, that's my theory down the drain then
[18:29] <flocculant> ha ha 
[18:29] <flocculant> mostly it's about catching people at the right time and engaging - like with you
[18:30]  * willem heading over to G+ to see whether it still exists and then like the testing message
[18:30] <flocculant> anyway - enough of this 6 monthly cyclical gripe from me :p
[18:30] <willem> no, no, I understand your frustration
[18:31] <flocculant> :)
[18:31] <willem> ((just woke up my 2 G+ followers..))
[18:31] <pleia2> hehe, thanks
[18:31] <flocculant> I don't mean you - I say the same things every cycle - and I'm likely as bored by it as everyone else is
[18:33] <willem> I experience the same thing at work: people enjoy the ride until you ask them to do stuff, then they look at their watches: jeez, is that the time?
[18:33] <flocculant> :)
[18:34] <willem> What did it for me: your message about testing to keep the community alive came just after I had (again) ditched KDE Neon to again get back to Xubuntu, and felt relieved to be back
[18:35] <willem> because xubuntu is just what I need for my daily work
[18:35] <flocculant> that's what I mean by the right time - but that's impossible to gauge ;)
[18:36] <willem> yeah, you're right. 
[18:37] <willem> ((good grief: just discovered I have 17 G+ followers; are you guys sure your server will cope? ;-))
[18:38] <pleia2> lol
[18:38] <flocculant> :)
[18:38] <pleia2> willem: what is your twitter handle?
[18:38] <flocculant> biab - dad taxi
[18:38] <willem> pleia2, uhm.. have to look that up ;-(
[18:39] <pleia2> hehe
[18:39] <willem> brb
[18:42] <willem> pleia2, @hoblem
[18:43] <pleia2> oh, secrets secrets
[18:43] <willem> pleia2, your Dutch any good? ;-)
[18:43] <pleia2> haha
[18:43] <pleia2> I can barely speak English ;D
[18:51] <willem> I think I have now my 4th twitter follower :-)
[18:52] <pleia2> :D
[18:52] <willem> BTW: thunderbird thought I was sent an emailscam. 
[18:53] <willem> And gmail didn't like the link to twitter either :-(
[18:54]  * flocculant giggles at bug 1760955 then toddles off
[18:55] <knome> pleia2, ok, then i won't mention that :)
[18:58] <knome> willem, i'm not really sure what the actual scope of the bug you showed is (ping ochosi) but does this happen with the elementary-xfce-* icon themes as well?
[19:02] <willem> Adwaita and elementary xfce dark: http://i.imgur.com/a2wz4Jo.png
[19:03] <willem> Adwaita and elementary xfce darker: http://i.imgur.com/8dMSDlL.png
[19:04] <willem> adwaita and elementary sxfe darkest: http://i.imgur.com/37uZcpn.png
[19:06] <willem> Are these links helpful?
[19:38] <ochosi> willem: sry from the screenshots alone i dont get the bug - is there a report/description already?
[19:40] <willem> ochosi, no, apart from the screen cast I posted earlier, I have no report yet; I was trying to find out where to report this and asked flocculant for help; he ppinted to you and knome. You have seen the screen cast? 
[19:41] <willem>  https://www.dropbox.com/s/hinzabgbx7yb4x7/Schermopname%202018-03-29%2015%3A24%3A13.mp4?dl=0 
[19:45] <willem> knome, ochosi I'll be offline for quite some time now; I'm not certain I've set up my znc bouncer correctly, so I may miss any queries you may post from now on.
[19:46] <willem> I'll check in tomorrow, or the day after. Let me know where to report this bug (if it is a bug), and against which package or theme or what have you.
[19:54] <ochosi> okeydokey
[19:54] <flocculant> pleia2: aaand - it's built ;)
[19:54] <flocculant> at least this version is ...
[19:55] <ochosi> willem: thats not default adwaita, by default it has a bright panel
[19:56] <ochosi> did you use something like gtk-theme-config..?
[19:56] <ochosi> anyway, thats only a theme bug
[19:57] <flocculant> ochosi: evening :)
[19:58] <ochosi> heya
[19:59] <flocculant> thanks for doing meeting - useful timing just after beta finishes \o/
[19:59] <ochosi> no worries
[20:00] <ochosi> would have scheduled earlier, but it was a tight easter weekend
[20:00] <flocculant> I shall be about - but likely a bit sleepier than normal ;)
[20:00] <ochosi> hehe, good good
[20:00] <flocculant> ack - I was in and out most of the weekend
[20:00] <ochosi> i need to try to reproduce the LL issue i guess
[20:00] <ochosi> and check where xfpm and xfsettingsd handle lid stuff
[20:01] <flocculant> the resolution one?
[20:01] <flocculant> oh that - yea good luck there ;)
[20:01] <ochosi> no, that one i'm not too concerned about
[20:01] <ochosi> its not pretty but at least it doesnt break stuff
[20:01] <flocculant> indeed :)
[20:01] <ochosi> plus its actually the driver at fault (at least probably)
[20:02] <flocculant> and also I believe that nvidia is putting up a bit of a struggle around the place this cycle 
[20:02] <flocculant> ha ha - more or less snap there :p
[20:02] <ochosi> the backlight issue sucks far more
[20:02] <ochosi> and bluetooth is a little out of scope for me
[20:02] <flocculant> yea for sure 
[20:03] <ochosi> i only have devices *with* bt, so as far as i understood i have no way to reproduce anyway
[20:03] <ochosi> plus its not just our problem
[20:03] <flocculant> though the lappy I managed to resurrect seems ok - though battery is fubar, so if it's that making it worse - can't test
[20:04] <flocculant> yea - that helps, though I'm not even sure if flexiondotorg looked there since I mentioned it
[20:04] <TJ-> someone mention bluetooth?
[20:04] <ochosi> yeah, and light-locker issue 108 ;)
[20:05] <TJ-> 108 is mine
[20:05] <TJ-> what's this BT issue, don't think I've spotted that
[20:05] <TJ-> I've been hacking on BT for about 10 years so might have some insight
[20:05] <flocculant> bug 1754836
[20:05] <flocculant> that one
[20:06] <flocculant> that we're not even sure of now
[20:06] <flocculant> idling for a while
[20:11] <TJ-> do we know if bluesabre, when removing those packages, did a purge? Because I'm wondering if some DBus activation conf files were left behind
[20:12] <TJ-> I could try reproducing here by pulling the BT module's connection.
[20:14] <TJ-> The Introspection is the interesting part - something is trying to reverse-engineer the interface presented by bluez. I'd be focusing on the DBus activation side since I'd assume bluez won't publish an interface is there isn't a BT HCI 
[20:21] <TJ-> what is VERY interesting is the system config doesn't run, it has "Exec=/bin/false" -- /usr/share/dbus-1/system-services/org.bluez.service
[20:30] <TJ-> Ahh, that's because it's left to systemd to activate it via /lib/systemd/system/bluetooth.service
[20:31] <ochosi> TJ-: i know thats your bugreport, btw are you still working on debugging that one?
[20:32] <ochosi> if so i can at least add the relevant parts from the xfce side as references
[20:33] <TJ-> ochosi: working on it but it's intermittent so I have to 'catch' it :)
[20:33] <TJ-> I've got an LP bug for it too
[20:34] <TJ-> Bug #1759950
[20:35] <TJ-> ochosi: I'm leaning towards the fact that it only affects very fast systems (race condition) all my less capable laptops are fine
[20:38] <ochosi> right
[20:38] <ochosi> was there a patch or anything from your side already?
[20:39] <TJ-> ochosi: My current hypothesis is that the lid-close events causes light-locker to disable baclklight... but on resume A new display server is launched for the greeter on vt8, and that starts so quickly that the user session is switched away from light-locker before it receives the activate event so light-locker never re-enables it's internal backlight tracking variable. Thus, on each switch back to vt7
[20:39] <TJ-> it resets the state of the backlight to 'off'
[20:40] <TJ-> No, my patches are just inserting debug messages to gain additional insight
[20:41] <TJ-> In my next session I'm going to figure out how to insert a long delay in starting the display server on vt8 for the greeter
[21:02] <ochosi> TJ-: sounds like a plan
[21:53] <bluesabre> TJ-: ah, didn't purge
[21:54] <TJ-> I've added some comment and a manual DBus test you can do to simulate the issue
[22:04] <bluesabre> flocculant: when I was testing, I created a new user, removed the packages, and rebooted. Seemed sufficient since I could reproduce on first login for any user
[22:06] <TJ-> I think it is what I've mentioned in the bug report ... the other flavours don't ship apps using DBus to talk to blueze
[22:07] <bluesabre> I think blueman does it directly, and the other flavors utilize gnome-bluetooth or other bt libraries
[22:11] <pleia2> knome: hold up for a moment
[22:11] <knome> pleia2, what?
[22:11] <pleia2> knome: the URLs are correct when you look at them with your eyes, but they're all *linking to* the tree one
[22:11] <knome> pleia2, 4/6 mails are gone already :|
[22:11] <knome> really?
[22:11] <knome> hmm...
[22:11] <pleia2> yes, clicky
[22:12] <knome> ughy ughy
[22:12] <knome> well
[22:12] <knome> i'll fix that for the rest two
[22:12] <pleia2> k
[22:12] <knome> and send replies to the other ones :)
[22:12] <pleia2> sgtm
[22:13] <knome> the reason why you should never send html mail
[22:14] <pleia2> ++
[22:15] <knome> and also, mailing list archive even shows this correctly (of course)
[22:15] <pleia2> omnomnom html email
[22:17] <knome> ok, does that fix it for you (too)?
[22:17] <pleia2> yes, good job
[22:18] <knome> thank you
[22:18]  * knome bows
[22:18] <pleia2> and thanks for taking care of this :)
[22:18] <knome> good thing that we spotted that now
[22:18] <knome> no problems
[22:18] <knome> now we wait anxiously
[22:23] <TJ-> bluesabre: yes, blueman uses Dbus, the others I think use libbluetooth
[22:23] <TJ-> bluesabre: which would explain why it's the user session that suffers most
[22:24] <knome> hozzah, first reply!
[22:25] <ochosi> TJ-: i presume you already found the part where there is already a delay in the switching to greeter
[22:25]  * pleia2 starts making note of people to send stickers to
[22:26] <knome> pleia2, great, i'll also let you know if somebody sends me their address in private
[22:26] <pleia2> kk
[22:26] <knome> ochosi, do we want to ask for as big as possible resolution or are we content with 2560x1440/1660?
[22:26] <knome> ochosi, since you're the artwork boss
[22:27] <ochosi> i guess we won't run into sizing issues, but i'd go with a realistic resolution (e.g. 4k?) instead of the "random biggest resolution" for each pic
[22:27] <knome> i mean of course
[22:28] <knome> but the question was if we wanted to even ask for >2k
[22:28] <TJ-> ochosi: yes
[22:29] <TJ-> ochosi: but it looks like there could be two DBus clients, one reported in syslog (pre-greeter) and those in .xsession-errors
[22:29] <knome> i guess 4k is really the only bigger "realistic" resolution
[22:30] <ochosi> knome: i'd ask for biggest and if it turns out that only few reach 4k we go with the 2560x1440 one
[22:31] <TJ-> ochosi: the obvious solution is to have a startup job that checks whether org.bluez is activate-able and if not disables them, so stops blueman from autostart-ing, disables which-ever system client is trying to access it. Needs doing each boot in case a BT device is added
[22:31] <knome> for sensibility, i'd ask "do you have 4k" and if they do, include that even if not all of them do
[22:31] <knome> because why not?
[22:31] <knome> it's the best possible service we can offer
[22:31] <ochosi> TJ-: oh, you're talking about bt again while i was talking about light-locker :)
[22:31] <TJ-> ochosi: oh! Right now BT looks easier to solve :D
[22:32] <ochosi> knome: yeah, that's what i'd go with
[22:32] <ochosi> TJ-: lol, ok ok :)
[22:32] <knome> ochosi, ok, that's what we'll do then
[22:32] <TJ-> ochosi: I don't see any delay in the greeter, is that some other bug I'm not seeing or a config setting
[22:33] <ochosi> TJ-: the delay is when resuming to the greeter
[22:33] <ochosi> it's currently hardcoded to 1s
[22:33] <TJ-> yeah... i saw that with associated comments about trying to avoid a race condition
[22:34] <ochosi> https://github.com/the-cavalry/light-locker/blob/master/src/gs-monitor.c#L354
[22:34] <ochosi> but tbh i don't see light-locker deactivating the backlight anywhere
[22:34] <TJ-> it asks lightdm to do; l-l does the interfacing but the heavy lifting is delegated to lightdm
[22:36] <ochosi> hm, i must've overlooked that part then
[22:36] <ochosi> this one does it too btw: https://git.xfce.org/xfce/xfce4-settings/tree/xfsettingsd/displays.c#n1337
[22:36] <TJ-> I'm still hypothesising, but from what I've seen so far and the code, it won't make the user session visible if it's not active. If I'm correct and the vt8 greeter is active before that point it won't do priv->visble = TRUE 
[22:37] <TJ-> I'll try to reproduce it again tomorrow, which likely means having to do a cold boot 
[22:38] <ochosi> tbh i'm not sure who catches the lid event first
[22:38] <ochosi> both services are listening to upower
[22:38] <TJ-> right... that's why I have to drop debug code in all over... makes my mind go numb trying to keep track
[22:39] <TJ-> I wish userspace were more like the kernel and I could attach probes just as easily
[22:43] <ochosi> TJ-: here is another one: https://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n450
[22:45] <ochosi> put it all into the issue as well
[22:45] <TJ-> I've been monitoring the DPMS state externally and it isn't incorrect
[22:45] <ochosi> in which sense?
[22:45] <TJ-> the only value that changes is the bl_power on the backlight device
[22:47] <ochosi> right, but who changes it?
[22:47] <TJ-> That's what I'm trying to find out :)
[22:48] <TJ-> it's obviously related to vt switch otherwise all VTs would be dark
[22:48] <ochosi> or lid close?
[22:49] <ochosi> although that should be easy to test
[22:49] <TJ-> and the 'off' only gets triggered by lid_close 
[22:49] <ochosi> yeah
[22:49] <ochosi> so lid close
[22:50] <ochosi> anyway, gotta get some sleep
[22:50] <TJ-> lid_close causes backlight off for that VT. Resume and blacklight is fine on all VTs but the user session on VT7
[22:50] <ochosi> yeah
[22:50] <ochosi> so either lightdm fails
[22:50] <TJ-> ha, it is a blacklight too... I meant backlight :D
[22:51] <TJ-> lightdm is firing up the greeter on VT8 isn't it?
[22:51] <ochosi> actually it must be lightdm
[22:51] <ochosi> because nothing in the session gets the lid open event
[22:51] <ochosi> because the seat is locked
[22:51] <TJ-> but it get's told what to do by light-locker for the VT, so if l-l on VT7 says 'off' whenever VT7 is selected that state is restored
[22:51] <ochosi> (at least if i remember how lightdm worked correctly)
[22:52] <ochosi> right
[22:52] <ochosi> so if e.g. xfsettingsd switches off the backlight (or xfpm) within the session
[22:52] <ochosi> then lightdm would restore that
[22:52] <TJ-> light-locker gets the the lid_open event, but it seems to get it whilst VT7 is not in use, so it doesn't react properly to it (due to visible == false)
[22:52] <ochosi> but neither xfsettingsd nor xfpm would restore the backlight because they only do that when they get the lid_open event
[22:53] <ochosi> yeah, light-locker has the same problem as xfsettingsd and xfpm ^
[22:53] <ochosi> all of them are "trapped" in the locked seat
[22:53] <TJ-> I've not seen any indications of xfpm reacting - I've dropped debug code in there
[22:53] <ochosi> yeah, i'm not surprised
[22:53] <ochosi> i think it should be halted during the locked session
[22:54] <ochosi> as pretty much everything else (nice indication is music playback pausing)
[22:54] <ochosi> i wouldn't expect it to receive signals or act on them
[22:54] <TJ-> without light locker enabled there's never a problem so it must be something l-l is missing
[22:54] <ochosi> without light-locker you remain in the same VT
[22:55] <TJ-> the 'close' side looks fine, the 'open' side has a problem. 
[22:55] <ochosi> so xfsettingsd and xfpm can react
[22:55] <ochosi> mhm, sounds reasonable to suspect
[22:55] <TJ-> Well yes, but ... with the screensaver enabled, I did think I noticed a couple of times a brief sign of the screensaver before the greeter showed up
[22:55] <TJ-> and screensaver is on VT7 
[22:56] <ochosi> that may depend on your graphics driver even
[22:56] <TJ-> we're talking a fraction of a second, but if I recall correctly, it looked to be animating, so it wasn't just an old framebuffer image
[22:56] <ochosi> sometimes even on wakeup from lid_close some people would see their desktop for the fraction of a second
[22:57] <ochosi> (those without an additional screensaver)
[22:57] <TJ-> right, first thing I checked was the i915
[22:58] <TJ-> Anyhow, as I said, I'll try to provoke it tomorrow and get some more accurate debug output
[22:58] <ochosi> alrighty
[22:58] <ochosi> good plan
[22:58] <ochosi> and with that - > good night! :)
[22:58] <TJ-> it's not a major issue since I can suspend from CLI or the power button before closing the lid, then it resumes fine
[22:58] <TJ-> good night and thanks for all your donated brain power!
[23:47] <TJ-> Got another interesting issue here; just resumed 1 PC and it's stuck in a loop constantly starting and failing a greeter Xorg on VT8, such that it's not possible to switch VTs via keyboard. I'm on via SSH trying to figure out how to stop it spawning new Xorg endlessly
[23:49] <ali1234> stopping lightdm will do it
[23:53] <TJ-> Not a good idea, there's an active user session I don't want to lose :)
[23:56] <ali1234> oh, is the beta iso out?