x2go-dev February 2021

x2go-dev@lists.x2go.org

5 participants
82 discussions

Bug#1427: Update Tumbleweed packages for Perl 5.30
by Tristan Miller 28 Sep '21

28 Sep '21

Package: x2goserver Version: 4.1.0.4 Tags: rpm-packages Various openSUSE Tumbleweed packages for the X2Go server are built in such a way that they require Perl 5.28.1. However, Tumbleweed no longer distributes that version of Perl; it now distributes only Perl 5.30.1. This means that it is impossible to install these X2Go server packages on the most recent release of Tumbleweed, and for Tumbleweed systems where those X2Go server packages were already installed, it is impossible to upgrade Tumbleweed without removing the X2Go server: $ sudo zypper dup [sudo] password for root: Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... 9 Problems: Problem: x2goserver-common-4.1.0.4-0.0x2go1.0.git20191106.1811.heuler.x86_64 requires perl(:MODULE_COMPAT_5.28.1), but this requirement cannot be provided Problem: perl-5.28.1-3.4.x86_64 requires perl-base = 5.28.1, but this requirement cannot be provided Problem: perl-X2Go-Server-DB-4.1.0.4-0.0x2go1.0.git20191106.1811.heuler.x86_64 requires perl(:MODULE_COMPAT_5.28.1), but this requirement cannot be provided Problem: perl-X2Go-Server-4.1.0.4-0.0x2go1.0.git20191106.1811.heuler.x86_64 requires perl(:MODULE_COMPAT_5.28.1), but this requirement cannot be provided Problem: perl-X2Go-Log-4.1.0.4-0.0x2go1.0.git20191106.1811.heuler.x86_64 requires perl(:MODULE_COMPAT_5.28.1), but this requirement cannot be provided Problem: x2goserver-4.1.0.4-0.0x2go1.0.git20191106.1811.heuler.x86_64 requires perl(:MODULE_COMPAT_5.28.1), but this requirement cannot be provided Simply telling zypper to keep the obsolete packages doesn't work as this ends up in a rabbit-hole of seemingly irresolvable dependency issues.

1 4

Bug#1520: Proxy-Server - SSH - strong Cipher crash x2Go-Client
by Marian.Schwarcz＠dlr.de 20 Sep '21

20 Sep '21

Package: x2goClient Version: 4.1.2.2-2020.02.13 Host-System: Windows 10, und Windows Server 2012 R2 (German Language) Installations-Typ: Recommended (Default) *** Problem Description *** When using x2GoClient via jumpserver (as SSH-Proxy-Server), then is X2GoClient automatic closed (without any Information). Problem are the SSH-Strong-Ciphers, which are configured in SSHd on Jumpserver. Strong Ciphers => x2GoClient crashed. If default Ciphers => x2GoClient and connection works. *** X2GoClient - Configuration *** Sitzungsname: test Pfad: / Host: ziel-server Login: test_ye SSH-Port: 22 Proxy-Server für SSH-Verbindung verwenden SSH Host: jumpserver Port: 22 Gleiche Anmeldung wie für X2Go-Server Gleiches Kennwort wie für X2Go-Server XFCE *** Jumpserver Configuration) *** Jumpserver SSHd Config: /etc/ssh/sshd_config (CentOS 7) Ciphers aes128-ctr,aes192-ctr,aes256-ctr The ciphers are used for strong Encryption. Then access from x2GoClient via jumpserver cannot handle this. ------ When the Cipher-Restriction is not configured: Jumpserver SSHd Confg: (CentOS 7) #Ciphers aes128-ctr,aes192-ctr,aes256-ctr then the connection from x2GoClient via jumpserver to Destination X2Go-Server does work. I hope I provided all needed information for you. Let me know if this can be patched, or does our Company need to search for other solution. Thank you. Best regards, Marián Schwarcz

4 5

Bug#913: Inaccurate scaling of dialog boxes and fonts for large DPI screen in Windows 10
by Alves-Foss, James (jimaf＠uidaho.edu) 02 Aug '21

02 Aug '21

Package: x2goclient for windows Version: 4.0.5.0 Downloaded new version of x2goclient for a new Dell Laptop. Screen resolution 3200x1800. OS Windows 10 (just checked, same problem on similar machine in Windows 8.1) When I open the main program, the fonts and windows do not scale well in the session selection boxes When I create a new session and try to open it, I can not see the list of open sessions to connect to. This appears to be a scaling issue for high DPI systems. I tried Windows 7, Windows 8 compatibility modes. I tries to disable display scaling on high DPI systems (see attached images)

3 2

Bug#581: VirtualBox Clipboard Sharing does not work when accessing the host over X2Go
by Michael DePaulo 18 Jun '21

18 Jun '21

Package: nx-libs Version: 3.5.0.27 Severity: normal If you run a VirtualBox VM with its display running under X2Go, the VM's clipboard sharing fails to work in either direction. You cannot copy and paste text between the VM and an app running under X2Go server, nor can you copy and paste text between the VM and an app running on the X2Go Client system. (I believe VirtualBox VMs use SDL to interact with the X server, which in this case is nxagent. This differs from the VirtualBox GUI, which is written in QT.) Specifically, when the X sesssion starts on the guest, a VirtualBox-provided script for X calls "VBoxClient --clipboard" to start the clipboard service. The service runs as the user logged into the guest. However, this service fails to stay running, and thus the clipboard sharing does not work. If you launch the VirtualBox VM on the local X.org X server, the guest's clipboard service stays running and clipboard sharing works. You can also launch the VM in RDP headless mode from x2go (so the VM does not render its display to any nxagent). In this use case, the clipboard service stays running and clipboard sharing works. The strange part is that the configuration of the host affects the behavior of the guest. It makes sense though because it's a bug in the guest's code to integrate with the host. Also, when you do call "VBoxClient --clipboard", it returns 0. And if you call it after the X11 session has already started, the problem still occurs. In x2goclient, I tried turning on and off the following setting, but it had no effect: Options -> Settings -> X-Server settings -> do not use primary clipboard My theory is that this is a bug in nx-libs, and that the bug is probably related to nx-libs being forked from such an old X.org codebase. It is worth looking into whether other SDL apps have clipboard trouble with X2Go on Ubuntu 14.04. (It's also worth testing an older release of Ubuntu as the host OS, since it would have an older release of SDL.) Host system: OS: Ubuntu 14.04.1 64-bit with latest bugfix & security updates nxagent: 2:3.5.0.27-0~446~ubuntu14.04.1 x2goserver: 4.0.1.15-0~847~ubuntu14.04.1 x2goserver-xsession: 4.0.1.15-0~847~ubuntu14.04.1 VirtualBox 4.3.14 (from download.virtualbox.org) "Shared Clipboard" is set to "Bidirectional" for the VM $ cat /etc/x2go/x2goagent.options | grep -v '^#' | grep -v '^$' X2GO_NXAGENT_DEFAULT_OPTIONS="" X2GO_NXAGENT_DEFAULT_OPTIONS+=" -extension XFIXES" X2GO_NXAGENT_DEFAULT_OPTIONS+=" -nolisten tcp" Guest OS: Ubuntu 12.04.5 64-bit with precise HWE stack, the virtual kernel, and all the latest bugfix & security updates OS-provided XFCE virtualbox-guest-dkms: 4.1.12-dfsg-2ubuntu0.6 virtualbox-guest-utils: 4.1.12-dfsg-2ubuntu0.6 virtualbox-guest-x11: 4.1.12-dfsg-2ubuntu0.6 Configured according to: https://github.com/mikedep333/duckpan-vagrant/tree/duckduckhack-vm The aforementioned script is: /etc/X11/Xsession.d/98vboxadd-xclient (I'm sure a different script would be used for distros like CentOS which lack the /etc/X11/Xsession.d/ folder). Client system: Windows 8.1 64-bit with Update 1 and all the minor/monthly updates available X2GoClient 4.0.2.1+hotfix1+build3

2 1

Bug#1369: Keys do not release when using Emacs in X2GO Client
by Yan Zhang 03 May '21

03 May '21

Package: x2goclient Version: 4.1.2.0 I am using Emacs 24.5.1 with x2go client version 4.1.2.0 in Windows 10. My server OS is Ubuntu 16.04 and the x2goserver comes from the PPA repo. The problem happens if I hit "ctrl+space" to start mark region in Emacs and then press down "ctrl+n" to scroll down the region for a few seconds. Usually after I release "ctrl+n", Emacs will leave the currently marked region for further commands. But in the reported version of client, Emacs keeps scrolling down until it reaches the end of the file. There is no way to stop it within Emacs (e.g., "ctrl+g"). I have tried to move the cursor by keeping "ctrl+n" pressed down. This issue does not happen after I release the key. This issue happens when the session type is either "XFCE" or "published application". I have not tested other session types as I do not have an environment for that. And client version 4.1.1.1 does not seem to have this issue. Thanks and regards, Yan

4 4

GitLab Install LXC - Update (issue)
by Melroy van den Berg 01 Apr '21

01 Apr '21

Hi all, I tried to omnibus GitLab install on the VM. Failed on: Expected process to exit with [0], but received '255' ---- Begin output of sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf ---- STDOUT: STDERR: sysctl: setting key "kernel.shmmax": Read-only file system ---- End output of sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf ---- Ran sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf returned 255 Due to: command "sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf" causing the error: sysctl: setting key "kernel.shmmax": Read-only file system Read-only of the /sys/ directory is typical the case with LCX containers... But the advice value of the shmax is: cat /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf kernel.shmmax = 17179869184 I can complete the setup if you want, by using a workaround by commenting-out the related section in: /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/gitlab_sysctl.rb. And run: gitlab-ctl reconfigure. But I rather like to get this working in a correct manner. Maybe somebody add at this shmmax statement above to the host /etc/sysctl.conf file? Let me know if somebody can help me with this or which direction you want to go. Ps. where are not the only one on the internet: http://letmegooglethat.com/?q=STDERR%3A+sysctl%3A+setting+key+%22kernel.shm… Thx! Kind regards, Melroy van den Berg

5 14

x2goagent segfaults with x2goclient from ubuntu 20.10
by Kenneth Johansson 01 Apr '21

01 Apr '21

so I have been using x2go for years and its works fine for what I need but today it stopped working. the error message was not really clear so I deleted and reinstalled (server and client) but still no go. Turns out its the x2goagent that segfaults on the server side. The client is an ubuntu 20.10 and the servers I tested with is debian 10 and ubuntu 20.04. To make sure that there was no version mismatch I then installed the server on the ubuntu 20.10 computer and tried to connect to localhost and still get the segfault. how to debug this ?? what I try to do is use a single application and start "command=/usr/bin/xterm" since its not working even to localhost this should be something that a lot more people have a problem with than just me. I have deleted all configurations for both server and client and the only thing I change when I create a new session is the host login session type. So I do not see how I could have made something wrong here.

2 2

Bug#1386: Popup plasmoids flicker and disappear when a remote application is in focus
by Tristan Miller 23 Mar '21

23 Mar '21

Package: x2goclient Version: 4.1.1.1 I use X2Go to run single applications remotely and have them appear on my local Plasma desktop. When such a remote application window has focus, it prevents me from opening most pop-up plasmoids on my local machine. The plasmoids flicker and then disappear. STEPS TO REPRODUCE 1. Use X2Go to launch a single application remotely. 2. Give the remote application focus (for example, by Alt-Tabbing to it or clicking on it). 3. Do some action that causes a local plasmoid window to pop up. For example, click on the Application Launcher to try to show the application list, or click on the Digital Clock to try to show the calendar, or click on a group entry in the Task Manager to try to show the list of windows, or press Alt+F2 to try to bring up KRunner. OBSERVED RESULT 4. The popup window appears for a few milliseconds and then disappears. EXPECTED RESULT 4. The popup window should appear and then persist. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.45.0 Qt Version: 5.9.4 OS: openSUSE Leap 15.0 x2goclient: 4.1.1.1 x2goserver: 4.1.0.4 ADDITIONAL INFORMATION The video at <https://bugs.kde.org/attachment.cgi?id=119625> shows the bug. It shows a portion of my Plasma panel that includes the Application Launcher, the Pager, and part of the Task Manager. Claws Mail is running remotely via X2Go and one of its composer windows has focus. I am clicking repeatedly on the Application Launcher. You can see the pop-up window briefly flickering and disappearing. As far as I can tell, the problem happens only when an application run via X2Go has focus. The problem is not reproducible with applications run remotely via plain SSH. Not sure if this is a KDE/Plasma problem or an X2Go problem, so I have reported this also on the KDE Bugzilla: <https://bugs.kde.org/show_bug.cgi?id=406882>

1 1

Bug#1527: native X11 fonts stop being rendered as the desktop is shared; functionality is restored on unsharing.
by Enrico Bertocchi 27 Feb '21

27 Feb '21

Package: x2goserver Version: 4.1.0.3-4 (amd64, devuan Beowulf) Running, let's say "xfd -fn fixed" or any other sofware whose GUI is based on native X11 fonts (mwm) from within a remote x2go session (DISPLAY=:50), strings are rendered correctly until a second connection to such display (via the "x2go/x11 Desktop Sharing" facility) is established on the same :50 display, even with the same user. As soon as the connection is established, X11 fonts rendering stops for both the clients and all X11 clients which rely on such feature (e.g. mwm, or xfd) are shown with blank text boxes; applications which rely on different font technologies (e.g. the sakura terminal) are not affected. As soon the second connection is closed, font rendering is restored for the initial client, and writings reappear on the next window refresh. Such behavior is consistently reproduced at every attempt. Both client connections are originated from the same Centos 8 machine, with x2goclient 4.1.2.2 and disabled "set display DPI setting" option. Sincerely -- Enrico Bertocchi

2 3

Bug#1072: X2Go Client: top 24 pixels in fullscreen session do not respond to mouse clicks
by Chris Martin 09 Feb '21

09 Feb '21

Package: x2goclient Version: 4.0.5.1 I am trying to start a full screen X2Go session which 1. takes up the entire display, and 2. responds to my mouse clicks everywhere in the session, but cannot accomplish this with any combination of settings. Client OS: Debian Jessie / 8 / Stable, GNOME 3 desktop environment Client X2Go Client: 4.0.5.1 and 4.0.3.1 Server OS: Xubuntu 16.04 LTS Server x2goserver version: 4.0.1.19 Server x2goserver-xsession version: 4.0.1.19 When I choose "fullscreen", I get different behavior intermittently: 1. The client spawns across the entire screen but the *top panel inside the X2Go session* does not respond to any mouse clicks. I suspect the panel in my GNOME session running the X2Go client (which occupies the same pixels behind the panel inside the X2Go session) is stealing mouse focus. My mouse pointer turns black instead of white when I hover over the top 24 pixels or so, inside the X2Go session. 2. The client spawns what I would call a "maximized window". The top of the screen is still consumed by the title bar of the X2Go window, and the panel of the enclosing GNOME session in which the X2Go client is running. I have observed both cases 1 (most common) and 2 with X2Go Client 4.0.5.1, and only case 1 with X2Go client 4.0.3.1. When I choose "Display 1" in the Input/Output settings, the X2Go session displays only in the upper-left quadrant of my display; the rest of the screen is black. Thank you, Chris Martin

4 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev February 2021