Packages

X2Go Client, GNOME 51 (VNC) variant -- a SEPARATE package from packages/x2goclient (installs to /usr/lib/x2goclient-gnome51vnc/ + /usr/bin/x2goclient-gnome51vnc, doesn't touch or replace the already-verified-working plain x2goclient), built for the LinuxDoors GNOME 51 push. Same upstream 4.1.2.3 source + the same LinuxDoors Qt5->Qt6 port patch as packages/x2goclient, plus a second, LinuxDoors-authored patch (source_packages_versions/x2goclient-gnome51vnc/x2goclient-gnome51vnc.patch, generated by diffing a hand-edited copy of the ALREADY-qt6-patched tree, not the pristine one -- so it must be applied second, after x2goclient-qt6.patch, exactly as build.sh does). || The real problem this solves: GNOME 51 removed its X11 backend entirely (confirmed directly from Mutter's own source -- no src/backends/x11/ at all in 50.5/51.0), so x2go's own nxagent (an X11-based remote-display proxy) can never show it, unlike every other session type (KDE/GNOME-48/XFCE/MATE/...) this client already supports. The patch adds a 'GNOME 51 (VNC)' entry to the Session-type combo in both the load and save paths of sessionwidget.cpp/.h (inserted right after ICEWM in the shared enum -- every existing RDP/XDMCP/SHADOW/OTHER/APPLICATION/PUBLISHED comparison elsewhere in that file uses named enum constants, never raw indices, confirmed by grep, so they all shift down automatically). || REAL, HAND-WON DESIGN, after three rounds of live debugging against a real connection attempt (2026-09-19), not guessed: the FIRST implementation intercepted late (inside ONMainWindow::SlotRunCommand, after nxagent/the tunnel/nxproxy had already run) -- this was WRONG, because a real connect attempt got stuck forever at 'Status: connecting' for EVERY session type, GNOME51VNC included, since x2goclient's own pre-existing nxproxy QProcess::start() call (used by ALL session types, not something this patch touches) fails outright in a portable AppImage runtime with 'Child process set up failed: execve: No such file or directory' for ANY target whatsoever -- confirmed via standalone test binaries built the identical way that a plain fork()+execve() and a plain posix_spawn() both work fine for the identical target in the identical environment, narrowing the fault specifically to Qt6's own internal QProcess launch path (likely its vfork/clone fast path), not anything reachable from application code, and not fixable without either a full non-QProcess rewrite of nxagent's own deeply-integrated proxy-management code or a Qt rebuild without vfork support -- both out of scope here. The CORRECT, final design instead intercepts MUCH earlier, in ONMainWindow::startNewSession() right after 'command'/'host' are read from settings, BEFORE nxagent/the tunnel/nxproxy ever start at all -- so GNOME51VNC sessions never touch that broken pipeline in the first place. From there it: (1) runs /opt/gnome51/bin/linuxdoors-gnome51-vnc on the remote host via the ALREADY-open sshConnection (SshMasterConnection::executeCommand -- the exact same primitive x2golistsessions/x2gogetservers/etc. already use), (2) opens a local TCP tunnel to the remote 127.0.0.1:5900 via SshMasterConnection::startTunnel(...) -- the exact same primitive x2goclient's own NX-proxy-port and sound tunnels already use, and (3) spawns packages/linuxdoors-vncviewer via plain posix_spawn() -- deliberately NOT QProcess, for the same broken-QProcess reason above; this is genuinely new code, not shared with nxagent's, so it was free to just avoid the whole bug outright. A SECOND real bug was found and fixed getting the remote command to actually take effect: SshMasterConnection::executeCommand()'s default overridePath=true wraps every command in a hardcoded 'export PATH="/usr/local/bin:/usr/bin:/bin";' (see SshProcess::startNormal()) -- the remote script itself still ran fine (invoked by absolute path, so PATH-independent), but every command IT calls internally (systemctl/grdctl/gsettings/gnome-keyring-daemon) is a bare name relying on PATH, n