[01:25] <Unit193> I'm kind of thinking "screw it" and backporting my xfconf to the backports PPA, but since it's not in groovy that's a bit... :3
[01:32] <Unit193> Dashboard is looking pretty good right now, actually.
[08:30] <Unit193> bluesabre: Ah crap, I got an email about stuff.  Can I give you a copy?
[10:13] <bluesabre> Unit193: sure?
[10:27] <jphilips> Unit193: if i remember correctly, you are a debian maintainer, right.
[11:01] <jphilips> these guys are looking for assistance to get their dock into debian https://github.com/M7S/dockbarx/issues/92
[12:38] <jphilips> anyone familiar with xdmcp, as a twitter user is saying its not working in 20.04
[12:38] <jphilips> https://twitter.com/hgdrn/status/1260586919077072896
[14:50] <ali1234> xdmcp is really really niche - it's the situation where the whole session runs on a remote machine, including the display/login manager
[15:00] <ali1234>  i'm surprised it even still worked in 16.04 to be honest
[15:18] <jphilips> ali1234: interesting technology, though seems similar to RDP, or am i mistaken
[15:19] <ali1234> i mean, its superficially similar
[15:20] <ali1234> it leverages remote X11, but typically when you use that your window manager is local and just one client is remote
[15:20] <ali1234> under Xdmcp the Xserver itself broadcasts a request for remote login managers and then *everything* runs remotely from the login window up through the session and window manager
[15:20] <ali1234> obviously there are a *lot* of things that can go wrong there
[15:21] <ali1234> especially wrt dbus because that has no remote capability, so if it runs in the wrong place, you can't connect - that seems to be the problem with xscreensaver
[15:22] <ali1234> but Xdmcp is tech from 20+ years ago, before dbus existed
[15:22] <ali1234> long before
[15:23] <ali1234> these days many components are relying on non-X services because they run under wayland too, and those components aren't network capable. pulseaudio being another example
[15:23] <jphilips> seems like something with the new screensaver is causing some of the issues
[15:23] <jphilips> https://pbs.twimg.com/media/EX6Aju7XYAU3FEp?format=jpg&name=medium
[15:23] <ali1234> not that audio ever worked with xdmcp
[15:24] <jphilips> also power manager as well
[15:24] <ali1234> in order for anyone to even begin to investigate this we're going to need a comprehensive guide on how to configure everything for Xdmcp, because i doubt any current developers know how to do it
[15:24] <ali1234> i certainly don't, i haven't done it for over 15 years at least
[15:24] <jphilips> what would you recommend i tell the person to upgrade to rather than use xdmcp
[15:25] <ali1234> i wouldn't, there is nothing that can replace it
[15:25] <ali1234> if you actually need it then you need it
[15:25] <ali1234> there is nothing more annoying than someone who doesn't understand the use-case recommending something completely unsuitable
[15:26] <jphilips> yep like people using excel as a database :D
[15:26] <ali1234> it's not like that at all....
[15:27] <jphilips> oh sorry, read your message wrong
[15:27] <ali1234> this person probably knows all the alternatives if they are experienced enough to even know what xdmcp is, so suggestions aren't going to help
[15:27] <jphilips> well i suggested the person join the IRC, so hopefully he can give his use-case
[15:35] <ali1234> btw, bugs found in ubuntu should always go to launchpad in the first instance
[15:36] <ali1234> if they are found to be upstream bugs then there are mechanisms to re-file there and keep the launchpad bug synced
[15:36] <ali1234> this is also important at the other end when it gets fixed, so the fix can be pulled into ubuntu
[15:38] <jphilips> yes i'm aware of that, as i've had a number of bugs happen in that case
[15:39] <jphilips> i normally file all my bugs upstream as they are xfce bugs more than xubuntu bugs
[15:40] <ali1234> it's fine to open a bug on launchpad and then immediately open the same bug upstream and link them
[15:41] <ali1234> preferred, even
[15:42] <jphilips> excuse my ignorance, but what would be the benefit of that
[15:42] <ali1234> ubuntu maintainers get notified automatically when the upstream bug gets fixed
[15:43] <ali1234> it isn't always a given that it is the same people
[15:45] <ali1234> it gets more eyes on the bug, and ensures it shows up whichever place someone searches
[15:46] <ali1234> suppose same bug affects ubuntu and fedora. fedora user searches their tracker and finds a bug linked to the upstream bug, and then on that bug they find a link to the ubuntu report. this way everyone has all the facts
[15:49] <ali1234> you should not worry much about making duplicate reports either
[15:50] <ali1234> consider that if you search and dont fond the bug, and then you make a dupe, you will phrase it in a different way. so the next person who searches may not find the original, but they may find your duplicate, which hopefully will have been marked as such
[15:52] <ali1234> consider that a bug report is not just a request to fix something. it's more like asking "does anyone else have this same problem?"
[15:59] <jphilips> interesting concept. i would presume then that all distro bug trackers follow the same recommended method
[15:59] <ali1234> i have no idea
[16:00] <ali1234> DBTS seems to be designed to be as difficult to use as possible, and fedora just mass closes everything every 6 months
[16:01] <ali1234> i have no experience with any of the others
[19:10] <jphilips> anyone here have OP status in #xubuntu, as we wanted to test a one-way telegram to irc bridge bot in preparation for it going live
[20:07] <Unit193> jphilips: http://bugs.debian.org/934659
[20:17] <jphilips> Unit193: thanks. so someone was requesting the same from august 2019. what is the way forward with it?
[20:17] <Unit193> Someone has to actually do it.
[20:21] <Unit193> Package it, upload it to NEW, of course finding a sponsor if needed.  All for something that hasn't seen a release since Feb '18? :P
[20:23] <jphilips> no release, but they've had patches come in during 2018 up to dec 2018
[20:25] <jphilips> its definitely a popular dock, though plank gets more attention as its in debian
[20:26] <Unit193> Also if it really is Python 2, that's a hard no for anyone.  Debian is working to remove Python 2 (as is Ubuntu)
[20:28] <jphilips> okay
[20:29] <Unit193> FWIW, with regards to 'rdp like thing', x2go is likely functioanlly more along those lines.
[20:42] <jphilips> definitely need to try x2go as wimpy was always mentioning how great it was on mate
[20:49] <Unit193> As I noted before, drop a file in /usr/local/bin/ with the right stuff and it'll look like Xubuntu, not default Xfce. :P
[21:09] <hgdrn> Good evening. Twitter brought me here, I'm the guy that ranted about the crappy XDMCP performance of my fresh Xubuntu 20.04 installation.
[21:10] <hgdrn> I've read the discussion of today in the channel logs, so I just want to add some words of how and why I use XDMCP.
[21:12] <hgdrn> First of all: I'm not a (Linux) developer, I'm just a Linux user. I use Win7 in the office next to a Xubuntu laptop (currently using 18.04). Two monitors are connected to the Windows PC.
[21:13] <hgdrn> The left monitor is used for all the Windows stuff. The right monitor shows a full screen XDMCP session of my Xubuntu laptop. Using this config I can use the best of two worlds with one keyboard/mouse just by switching the windows.
[21:16] <hgdrn> Why XDMCP: because everything works and looks nice (OK, no sound, but I don't need audio). The keyboard mapping works (German keyboard here). The fonts look perfect. It really looks the same as I use the laptop itself.
[21:18] <hgdrn> XDMCP runs much much better than VNC, RDP or x2go. It's faster, has less latency, the keyboard mappings work. I can watch YouTube videos in FullHD in an XDMCP session without problems.
[21:20] <hgdrn> I tried VNC, I tried RDP: both are a "pain in the ass" in comparison to XDMCP. I tried x2go long a go, it was OK, but not more, XDMCP is much better for me. 
[21:23] <hgdrn> I have been using XDMCP since 1998 or before. I currently use VcXsrv (https://sourceforge.net/projects/vcxsrv/), and I use its "XDMCP one window" mode. MobaXTerm is a nice solution, too. There has been XWin32 or Exceed, too.
[21:28] <hgdrn> Regarding the problems of 20.04: I guess  (sorry if I'm completly wrong) that there is some easy logic missing in theXubuntu code. The programs should check somehow if they are running on the local XServer or somewhere else.
[21:28] <Unit193> I have never used XDMCP, that being said I wonder what would happen if you selected 'Xfce' in the session menu rather than 'Xubuntu' (note, this could trash your Xfce settings)
[21:34] <hgdrn> I use an old Lenovo Thinkpad T410s for testing purposes. I used 18.04 with Plasma, Cinamon and Xfce. All of them worked well. Then I upgraded to 20.04 but the result was not good (Login took 2 minutes). So I made a clean install of Xubuntu 20.04 and found these problems when trying to access the Thinkpad via XDMCP.
[21:37] <hgdrn> One had to test it systematically, but I guess I don't have the time anymore to do that. So, before I write too much here: Where would be the right place to address problems? Please remember that I have never been in this Linux development world, and it is not so easy for me to know where to post bugs.
[21:41] <hgdrn> Good night from Germany. Keep on hacking, you are doing a good job and I love Xubuntu and XFCE. If XDMCP will die (at least with Wayland I guess), I'll find another way. If I can help I will try to do it. Bye.