[X2Go-User] NX Libs 3.5.99 OpenSuse

[Robert Dinse]

      I do have the artica project repo on these machines, was necessary to get
full display without manually setting xrandr from the command line.  This is
why I asked about artica project for opensuse.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
  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
>
>