[00:01] wait so the fork of ayatana is called ayatana? i'm confused [00:03] :) [00:29] ali1234: The Ubuntu versions are just 'indicators', though it was referred to as 'Ayatana'. The actual fork is named 'ayatana' and that's the internal name as well. They're entirely compatible right now, so patches like http://paste.openstack.org/show/fW34wv9fff7zKbsxi4dW work. [00:31] For the past several years, the libs in Ubuntu have been rolling from git, no actual releases since ~2016 so convincing upstreams and other distros to pick it up was a bit annoying. Now, Debian has pretty much switched to the ayatana stack so all derivs benefit as well (Except Ubuntu, which reverts it all in main.) remmina and nm-applet as well as others have upstream support to select which [00:31] stack or autodetect. [00:32] A lot of them have gone to kstatusindicator. [00:33] ....No, a lot of KDE/Qt things have since it's built-in, we're talking GTK here. [00:35] Unfortunately, for GTK you used to only have Ubuntu's libs for that stuff. [00:36] For Ubuntu/GNOME users, this is even more useful as trayicons have been deprecated and the topicons (or whatever it is) is under bitrot, whereas the gnome-shell extension to re-add Indicator support is currently maintained. [00:37] Though since you say Canonical might no longer be interested in such things, I wonder if https://github.com/ubuntu/gnome-shell-extension-appindicator will still remain maintained. [00:37] ...Anywho. [00:37] what is the ayatana position on text next to icons? [00:39] i mean, which version of the spec are they following? [00:41] Not sure. [00:41] Unit193: That's what I'm talking about. gnome-shell-extension-appindicator makes use of kstatusindicator in addition to other methods. [00:42] ...OK? [00:42] So, no, it's not going anywhere. [00:44] Right, up until I specifically mentioned it, I wasn't talking about gnome-shell. [00:46] Well, Canonical is interested in gnome-shell, since their Ubuntu desktop uses that extension by default, they don't want it going anywhere. But, the older Unity indicators are being depricated. [00:46] Or anything that takes advantage of that method. [00:47] And when you say 'indicators', you mena indicator-application type things or libappindicator3? [00:48] indicator-application. [00:48] so confusing... [00:48] Yeah no, I'm talking about the actual libraries, libappindicator. [00:49] Oh, no. The libraries are sticking around. [00:49] Though, getting rid of indicator-application is very good. [00:49] That's unfortunate. [00:55] Eickmeyer: Just about everything from above is about the libraries. [00:55] Yeah, it was a misunderstanding. I was referring to the indicator-* stuff. === brainwash_ is now known as brainwash [05:38] bluesabre: apologies that i couldnt make it yesterday, will try to catch up by reading tonight [05:40] ochosi: It's OK, we assigned everything to you. [06:00] lol thanks :) [11:20] bluesabre: and I will carry on reporting things when I find them :) [11:20] thanks for the thanks peeps too :D [11:27] Did we already thank you for sticking around even when you're not sticking around? :D [11:38] Unit193: :D [11:38] different now - I'm just this guy :D [11:49] Unit193: when the ppa's have new stuff perhaps you could let me know <- or bluesabre :p [12:04] flocculant: will dooooo [22:25] anyone have expertise around xfce4-power-manager? Re-hit by bug #1759950 on uprading several laptops to 19.04 from 18.04 [22:25] bug 1759950 in light-locker (Ubuntu) "Lid-close suspend: blank screen when switching to user session" [Undecided,Confirmed] https://launchpad.net/bugs/1759950 [22:30] TJ-: you tried without light-locker? [22:33] I've just solved it :D [22:33] It's a fight with logind; changing default settings for logind [22:37] I wish I'd discovered that when I first reported it. wasted days tracking light-locker! [22:37] Is there a way to tag a bug as a task for Xubuntu specifically? [22:51] TJ-: report the bug against xubuntu-default-settings will do :) [23:02] bluesabre: thanks ... I've tracked it down to a 2105 commit in x-p-m that integrated light-locker/logind support [23:04] Sounds more like a xfce4-power-manager bug. [23:04] Unit193: ^^^ I've tracked it down to a commit in x-p-m [23:05] Yes, I can see that, given the text was right above mine. [23:05] but that commit is pretty invasive/large so hard to reason about what is going on [23:05] Debian #840570 looks fun... [23:05] Debian bug 840570 in xfce4-power-manager "xfce4-power-manager: Attempts to suspend again after opening lid" [Important,Open] http://bugs.debian.org/840570 [23:10] this looks to be related to the underlying "logind-handle-lid-switch" value, which is "true". I wonder if disabling that and leaving logind's properties alone would work. Time to test [23:11] Unit193: I get that too; I've always read it as a left-over from closing the lid because policykit doesn't allow it - I do recall some time ago altering the policykit settings one one system to allow it. I'd forgotten I'd done that until you mentioned that bug [23:19] Here it is on 19.04: org.fredesktop.login1.suspend https://i.imgur.com/H0xSzW2.jpg [23:24] yes; I think this is the policy I added: https://paste.ubuntu.com/p/9BJ793XSj6/ [23:35] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758771 sounds like that one. [23:35] Debian bug 758771 in xfce4-power-manager "xfce4-power-manager conflicts with default settings of systemd/logind" [Normal,Open]