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. Reproducible: Always Steps to Reproduce: 1. emerge nxclient Actual Results: nx-x11 is compiled Expected Results: only nxcomp should be installed
Created attachment 58016 [details] nxcomp ebuild
Created attachment 58017 [details] nx-x11 ebuild
Created attachment 58018 [details] nxproxy ebuild
Created attachment 58019 [details] nxclient ebuild
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. Best regards, Stu
Hi, 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 ;-) Best regards, Stu
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. Best Regards - Jon
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.
Hi, 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'. Thanks. Rumen
Hi Jon, 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? Best regards, Stu
