What I've done for Mint, Debian, and Ubuntu, all the most current
releases, that works is to remove EVERYTHING related, all the x2go stuff,
all the libnx stuff, nxagent, etc.
Then with artical repository added and nightly builds repository added:
apt install x2goserver x2goclient
And that pulls everything including libnx 3.5.99 and everything works
mostly. It sizes the screen properly etc.
The one problem I am having is nxagent does core dump from time to time
on all of these platforms and also on Fedora.
For some reason vi file in a terminal often seems to trigger the core,
though afterwards I can reconnect and vi the same file and it will be fine.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting.
Knowledgeable human assistance, not telephone trees or script readers.
See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Tue, 7 Feb 2017, Mihai Moldovan wrote:
Date: Tue, 7 Feb 2017 00:40:03 +0100
From: Mihai Moldovan <[email protected]>
To: Robert Dinse <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [X2Go-User] NX Libs 3.5.99 OpenSuse
On 06.02.2017 11:22 PM, Robert Dinse wrote:
Odd, the nightly build resolved that issue with 1.3 on all of the debian
machines.
Hum... really? There has been *no* changes related to that in nx-libs for the
past 6 months, so I really wonder why you're seeing that. Again, with the X2Go
nx-libs, not Arctica.
As for Arctica: no, we currently do not provide RPM packages yet, AFAIK
there's only Debian and Ubuntu packages.
How did they build an x2go server that requires 3.5.99 libs on OpenSuse
then? There is the server there in the repository but says no source for the
libs it needs.
I'm pretty sure I explained that before, but here we go again:
X2Go Server essentially is a collection of shell and perl scripts, aiming at
session management and all that's necessary to get the job done. It has run-time
dependencies on nx-libs (and its various subcomponents), but no build-time
dependencies on nx-libs.
Hence, if I wanted, I could change X2Go Server's dependencies to require nx-libs
82.3 and the package would still build fine. Mind you, it wouldn't be
installable without forcing your package manager to accept a broken state, but
the binary packages would make it to the repository just fine...
Now, nx-libs is the entirety of our virtual X server, including nxagent (the X
server itself), nxproxy (a piece of software that connects a client's X server
to nxagent's virtual X server and compresses X calls) and its various support
libraries and data. In X2Go-realm, we rebrand nxagent as x2goagent. Thus,
whenever something is not working correctly within an already established
graphical session, likely chances are that nx-libs is at fault.
Just like above, nx-libs do not need X2Go Server to be built, but may require
subcomponents at run time.
That was the easy part, now for the difficult one...
Since Arctica is the new home of nx-libs development, we tried to purge X2Go
references in nx-libs and make it more generic. One part of that was deleting
the "x2goagent" branding stuff from nx-libs and moving that over to X2Go Server,
which makes a lot of more sense. These changes were backported to the legacy
nx-libs line we're using in X2Go... but package moves are tricky.
It seems as though something is amiss, as X2Go Server should be installable with
both nx-libs from the X2Go Nightly and Arctica repositories. Obviously though, I
messed something up, if it doesn't work properly for you.
To be a bit more graphical, this was the old situation (related to x2goagent):
nx-libs (3.5.0.x) <--includes--> [ x2goagent (branding), nxagent (real binary),
other packages ... ]
x2goserver <--depends--> [ x2goagent, other packages ... ]
New situation :
nx-libs (3.5.99.x - Arctica) <--includes--> [ nxagent (real binary),
other packages ... ]
x2goserver <--includes--> [ x2goserver-x2goagent (branding), other packages ...]
<--depends--> [ x2goserver-x2goagent OR x2goagent,
other packages ... ]
The tricky thing is that x2goserver is supposed to work with both nx-libs
versions, but it EITHER needs x2goagent from the 3.5.0.x-legacy X2Go nx-libs
package OR its own x2goserver-x2goagent package when used with the
3.5.99.x-Arctica nx-libs package. And that seems to still blow up and needs
fixing...
To make the situation worse is that we'll also need a working upgrade path for
X2Go Server stable to X2Go Server nightly (as the current nightly version is
bound to become the new stable version at some time.) The stable X2Go Server
version requires x2goagent specifically at the moment. Package managers will
thus update nx-libs packages first. If you happen to also update to Arctica's
nx-libs packages, the x2goagent package will be removed (as it's gone there) and
all hell breaks loose.
TL;DR: bug in X2Go Server, as it's *supposed* to work with X2Go's and Arctica's
nx-libs packages alike, but currently leaves you with a broken mess, I guess.
Theoretically, it should work if you install the "x2goagent" package manually if
you want to use X2Go's nx-libs nightly packages, or make sure that Arctica's
nx-libs packages are installed and pull-in x2goserver-x2goagent manually. Not
both at the same time.
I really need to work on that again, but it's difficult without enough hardware
resources to spin up virtual machines for all theses distros and test
thoroughly.
Mihai
_______________________________________________
x2go-user mailing list
[email protected]
http://lists.x2go.org/listinfo/x2go-user
