[X2Go-User] NX Libs 3.5.99 OpenSuse

[Robert Dinse]

      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 <ionic at ionic.de>
> To: Robert Dinse <nanook at eskimo.com>
> Cc: "x2go-user at lists.x2go.org" <x2go-user at lists.x2go.org>
> 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
>
>