A while ago (Bug #72698) Roie Kerstein complained that nxcomp was compiled twice when installing a nxserver, once in it's own ebuild and once in nx-x11. The result was that Stuart removed the individual ebuild and had nx-x11 install the libXcomp.so it compiled. The problem is that nxproxy does depend on nxcomp but not the entire nx-x11, and nxclient depends on nxproxy, but not nx-x11. The result is that when you only wants the nxclient and not a nxserver you will compile nx-x11 unnecessarily.
This can only be solved by making nxcomp its own package again, but that would take us back to where we started (prior to bug #72698). I think have found a better solution to that bug. If the nx-x11 ebuild unpacks the nxcomp sources and symlinks the already installed libXcomp.so into it nx-x11 will not compile nxcomp. That way nxcomp can be it's own ebuild without having to compile it twice.
To fixed this problem the nxcomp, nxproxy, nx-x11, and nxclient ebuilds has to be updated. Proposed ebuilds is attached.
Other changes to my proposed ebuilds are:
The old nx-x11 ebuild downloaded, but didn't install, nxesd, and stated that nxesd support was going to be added in a future release. It will not be, as nxesd is only used by the *Windows* nxclient! It is removed from the new ebuild.
The old nxproxy ebuild downloaded and unpacked (old) nxcomp sources. They are however not necessary to compile nxproxy, so the new ebuild does not do this.
The old nxclient ebuild didn't copy the nxprint binary, which breaks printer support. The new ebuild does copy the nxprint binary.
Steps to Reproduce:
1. emerge nxclient
nx-x11 is compiled
only nxcomp should be installed
Created attachment 58016 [details]
Created attachment 58017 [details]
Created attachment 58018 [details]
Created attachment 58019 [details]
I've tried the 0.4 ebuild, and the installed freenx server doesn't work for me. I've run out of time tonight to figure out why; I'll have a look later in the week and see if I can see what's wrong.
At the moment, I'm not comfortable with linking files from the live filesystem
into the build directory. I'll have a chat with other Gentoo devs before I can
agree to that.
Thanks for the other fixes; they are now in Portage, and will be appearing on
your local rsync mirror in about an hour. If you could give them a test, and
confirm that they're okay, that'd be much appreciated.
I probably should have pointed this out earlier; please posts diffs rather than
complete ebuilds, as it makes it a lot quicker to assess your changes ;-)
Hi again Stuart
I have been busy for a while, but now I'm back pestering you again ;)
I can not agree that this bug really is "resolved", as my main issue has not yet
been addressed (nx-client still erroneously depends on nx-x11).
You also missed two of my other fixes as well:
The current nx-x11 ebuild downloads, but don't install, nxesd, and stated that
nxesd support is going to be added in a future release. It will not be, as nxesd
is only used by the *Windows* nxclient! My first patch simply removes this
unnecessary download, unpacking and ebuild clutter.
The current nx* ebuilds has erroneous dependencies. Except for a missing libpng
the problem was mostly that wrong nx* package had the dependency listed, which
is no big matter if you install one of the toplevel packages (nxclient or
nxserver-*) as you'll get everything you need, but if you are interested in some
low-level package (if you for example are building your own high-level
packages), this might be a problem.
I have also updated the interdependencies of the nx* package to reflect that
nxproxy and nxssh always is backwards compatible, and should thus be stated as
>=net-misc/nx*-1.x, while nx-x11 isn't, and should thus be stated as
=net-misc/nx-x11-1.x*). This will not be very of importance until nx 1.5 finds
it way into portage, but is useful for people like me having private nx 1.5
snapshot ebuilds in a portage overlay. My second patch fixes all dependencies.
My third patch, which depends on the previous two, makes nx-x11 depend on nxcomp
instead of compiling nxcomp itself, and makes nxproxy depend on nxcomp rather
than nx-x11, which will automatically make nxclient stop depending on nx-x11, as
nxclient only depends on nxproxy.
You can apply patch 1 and 2 without having to link any files from the live
filesystem into the build directory, which you stated as the reason not using my
previous ebuilds, but you can't really close this bug until you have applied
patch 3, or found another way of doing the same thing.
Created attachment 63089 [details, diff]
Patch for nx-x11 to fix the nxesd error
Created attachment 63090 [details, diff]
Fixes all the dependencies errors
Created attachment 63091 [details, diff]
Patch to use the new nxcomp ebuild
Created attachment 64190 [details, diff]
Patch to use the new nxcomp ebuild
Due to a recent update to portage you can not follow symlinks to the live
filesystem if you use the sandbox feature. Copying libXcomp.so to the working
directory works perfectly though.
Used the ebuilds from BUG-101715 with some editing (corrections).
The error about missing 'libXcomp.so' still exists (while compiling
nxssh-1.5.0), but copying manually fixes it.
Evidently it's some bug with sandbox (as mentioned).
nxclient still depends on 'nx-x11' not 'nxcomp'.
My apologies for having ignored you (and all things NX-related) for the past half year or so.
I've applied your fixes to the nx-1.5 ebuilds in Portage. Could you take a look, and let me know whether you're happy with them or not?