Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I made up ebuilds for FreeNX v0.4.4 and the Open Source Compents of NX v1.5.0. These ebuilds are are based on the others currently in portage, a patch submitted by a user in another bug, and a patch made by me to fix an error in FreeNX. I also included a diff file that has all the ebuilds, digests, and patches in it so it can be easily applied. I didn't include the manifests, change log, and metdata files. I have the ebuilds and patches uploaded for users to Download them. The nxproxy ebuild had to be heavily changed in order for it to compile. Reproducible: Always Steps to Reproduce:
Created an attachment (id=65365) [details] nx-x11 v1.5.0 ebuild ebuild for nx-x11 v1.5.0.
Created an attachment (id=65366) [details] Patch to add resume support for Windows clients.
Created an attachment (id=65367) [details] nxclient v1.5.0 ebuild
Created an attachment (id=65368) [details] nxcomp v1.5.0 ebuild
Created an attachment (id=65369) [details] nxproxy v1.5.0 ebuild It took me awhile to figure out why it wasn't compiling, but I finally got it. :)
Created an attachment (id=65370) [details] FreeNX v0.4.4 ebuild
Created an attachment (id=65371) [details] Patch to fix the "The group -d was not found" error. This is not an official patch, but one that is made by me. I need to submit it upstream next, but I need to see where to do that at, so it may take a few days, unless there is a patch already submitted.
Created an attachment (id=65372) [details] nxssh v1.5.0 ebuild
Created an attachment (id=65373) [details] All the new ebuilds, patches, and digests. This diff file contains all of the new ebuilds, digests, and patches. :)
*** Bug 98591 has been marked as a duplicate of this bug. ***
Hi Jon. Thanks for your input, but I must unfortunately inform you that most ebuilds and patches you have supplied contains serious errors, and you have posted in wrong bugs... As for your nxsetup patch ("The group -d"), I can't read it, as it wont download :( However, as it is a freenx bug, you should report it at the project page (http://developer.berlios.de/projects/freenx/). The patch should be uploaded at the same place, and if you realy want fabian to putt attention to it, you might want to send a notice to the mailing list (http://mail.kde.org/pipermail/freenx-knx/). As for your freenx 0.4.4 ebuild, the one from my bug #98591 is working perfectly, all you have done is added your patch. That should not have been part of the same bug as the 1.5.0 components, but rather my freenx version bug #98591). As Stuart doesn't like complete ebuilds when not nessesary it should have been subbmitted as an patch. Preferably it should not include my patch for 1.5.0 backend support, but be a seperate one that can be aplied on its own, or together with mine. To keep bugzilla clean I think you should add it there, and close this bug (see below) As for your 1.5.0 ebuilds, you have several errors in them: Firstly they will not work if you do use the commercial flag in nxserver-freenx, as you haven't created any nxclient ebuild. Secondly, you have three different ebuild building libXcomp.so (nxcomp, nx-x11, nxssh), and TWO EBUILDS INSTALLING THE SAME FILE (nxcomp and nx-x11). In adition you have not updated dependancies, both internaly (between packages) and externaly (some packages is required in newer versions). As a minor error, any digests isn't nessesary, as Stuart can create them just as well as you or I can. Jon, thanks however for you getting these ebuilds out, they made me to finnish my ebuilds (they are now pressent in bug #101715) As this bug is full off errors, and all issues but one have been adressed in other bugs, would you please close it.
First, I wanted to keep all the ebuilds in one place to make Bugzilla neater. You talk about keeping it neat and then you open up a new bug to post the same ebuilds. I also wanted to keep all the patches in one place as well because they are referenced in the ebuild. I thought FreeNX and the NX components went together, so I put them in the same bug. Also, the patch I created for nxsetup downloads for me. :S Third, the nxclient is the 3rd file down from the top. Look closely. They are in alphabetical order. ;) Fourth, the diff I included contains all the ebuilds and patches and I thought that is what the devs wanted. So, that is a screw up on my part. Aside from that one big diff mess up, there are no errors here, and all the patches do download and all the ebuilds are in one place. If there were bugs in them, you could have uploaded the new ebuilds here instead of a new bug to keep buzilla clean. ;) And, I already said that I am working on seeing if that bug has been fixed upstream or not. :) If not I will try and show where the bug is and my solution to it.
Created an attachment (id=65443) [details] nx-x11-1.4.0-r4-to-1.5.0.diff NOTE: This ebuild needs the above patch to add in resume support.
Created an attachment (id=65444) [details] nxclient-1.4.0-r5-to-1.5.0.diff
Created an attachment (id=65445) [details] nxcomp-1.3.2-r1-to-1.5.0.diff NOTE: This ebuild really isn't needed anymore. I think it can be removed completely. No other ebuild depends on this ebuild, like someone else has in their ebuild. Only the package is needed, but that is taken care of by the other ebuilds. :)
Created an attachment (id=65446) [details] nxproxy-1.4.0-r2-to-1.5.0.diff NOTE: This ebuild does not depend on nxcomp. It uses the files for nxcomp during compile. This is correct and works. I know because I have it installed with sound working and everything. This IS the correct ebuild and how it is suppose to be.
Created an attachment (id=65448) [details] nxserver-freenx-0.4.0-to-0.4.4.diff NOTE: This ebuild depends on the above patch to fix the adduser error in nxsetup. Yes, I am still trying to see if it is submitted upstream. That may take a bit and it may already be fixed now. Well, I hope it is. :P
Created an attachment (id=65449) [details] nxssh-1.4.0-r1-to-1.5.0.diff
Created an attachment (id=65467) [details] freenx-0.4.4-adduser-fix.patch I redid the patch a little bit more. The if statements now make a little more sense. Oh, I registered on Berlios so I could post this patch and I have not recieved my confirmation letter yet. -_-' So, as soon as that account is activated, I will post it. :D
Created an attachment (id=65555) [details] nx-x11-1.5.0-r1.ebuild I made a change which I think is logical and should be changed in portage. Previously, the nxclient ebuild would install the file 50nxclient to /etc/env.d. This would only be done if the user has selected the commercial use flag set. This file sets PATH, and LDFLAGS. I think it would be very useful if the nx-x11 ebuild would install that file instead so then a) nxserver can be called anywhere and LDFLAGS would be set with /usr/NX/libs, which helps other components to be compiled so that the nxcomp is no longer a dependency in the other ebuilds. The file 50nxclient would need to be removed from the /etc/env.d dir, but I do not know how to do that. To me, this makes a lot of sense setting those variables with this ebuild, so I went ahead and made the change. Users will just need to delete /etc/env.d/nxclient if it exists. I went ahead and changed the nxclient ebuild to delete the env.d file.
Created an attachment (id=65556) [details] nx-x11-1.4.0-r4-to-1.5.0.diff This is the new diff for the changes made.
Created an attachment (id=65558) [details] 50nxx11 This needs to go in $FILESDIR/1.5.0 of the nx-x11 directory. This is the same as the file "nxclient" in the $FILESDIR/1.3.0 of the nxclient directory. If you want, you can change the ebuild of nx-xll to use this file instead. It doesn't matter, but I think this info should be set with nx-x11.
Created an attachment (id=65559) [details] nxclient/nxclient-1.5.0.ebuild This removes the moving of the file 'nxclient' to the /etc/env.d directory.
Created an attachment (id=65560) [details] nxclient-1.4.0-r5-to-1.5.0.diff Updated patch to reflect the change.
*** Bug 102448 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > *** Bug 102448 has been marked as a duplicate of this bug. *** Jakub, I see why you marked it as a duplicate bug. However, I'm not certain that it really is a duplicate. When I went to search for similar bugs, I used "ALL nxserver-personal" as my search terms and found nothing. Which is why I opened a new bug to begin with. After reading this bug and comparing it with the one I entered, I realized that this bug is basically for the "nxserver-freenx" and "nxclient". The one I entered is for the commercial "nxserver-personal" product and the other two commercial nxserver variations. Is Jon taking responsibility for the commmercial version ebuilds as well? If not, you may want to reopen my bug. If so, then the bug summary for this bug should be updated to reflect this. THank you.
Is there any chance of seeing some of this get committed to portage? Seems like all the stuff is somewhere between a couple of bugs and getting stale. The last version in portage is pretty old (in particular the freenx stuff) Thanks
Created an attachment (id=67441) [details] nx-x11-1.4.0-r4-to-1.5.0-r2.diff There were three components that were upgraded: nxcomp was upgraded from version 63 to 65 nxagent was upgraded from version 87 to 90 nxdesktop was upgraded from version 59 to 61 I also made some changes to the ebuild itself so I hope the source info is a little easier to read. This ebuild requires that the resume patch above to be placed in the Files Directory. This ebuild also required that the 50nxx11 file be placed in the $FILESDIR/1.5.0 directory.
Created an attachment (id=67442) [details] nxclient-1.4.0-r5-to-1.5.0-r1.diff The NX Client was updated from version 103 to 106. I made a few minor ebuild changes, specifically to the source URL. Note: If you are updating from the 1.4.0 NX Client series, you need to delete the file: /etc/env.d/50nxclient
Created an attachment (id=67443) [details] nxcomp-1.3.2-r1-to-1.5.0-r1.diff Not that this ebuild is needed anymore. I still don't know why I have it. I modified all the other ebuilds to compile and install without the need of this installed directly. Anyways, nxcomp was updated from version 63 to 65. Also, a few ebuild changes.
Created an attachment (id=67444) [details] nxproxy-1.4.0-r2-to-1.5.0-r1.diff nxproxy was not updated, but it compiles against nxcomp, so it needs the new updated nxcomp in the source. I did make a few changes to the ebuild since I was releasing an update anyways.
Created an attachment (id=67445) [details] nxssh-1.4.0-r1-to-1.5.0-r1.diff nxssh was updated from version 19 to 21. the source to nxproxy needed to be updated. There were a few minor ebuild changes.
Created an attachment (id=67446) [details] NX and FreeNX Overlay This is a complete copy of my overlay and the updated ebuilds. It has all the needed patches where they are suppose to go. This will help users to get this going rather than trying to find and place all the patches. For changes read the new entries for the diffs above.
Created an attachment (id=67453) [details] nx-x11-1.4.0-r4-to-1.5.0-r2.diff All I can say is oops. I forgot to update one of the components in the ebuild. This is fixed now. :)
Created an attachment (id=67454) [details] NX and FreeNX Overlay Updated overlay with the error fixed. It's been a long week.
Works great. Thank you very much, Jon.
I recently tried out your overlay. Actually I've been keeping up on this and trying it out occasionally. I'm experiencing what I'm fairly certain is a bug. Here's a sample of the relavent section of the emerge log: i386-pc-linux-gnu-gcc -o nxviewer -O2 -fno-strength-reduce -fno-strict-aliasing -L../../nx-X11/exports/lib argsresources.o colour.o cursor.o desktop.o dialogs.o fullscreen.o listen.o misc.o popup.o rfbproto.o selection.o shm.o sockets.o tunnel.o vncviewer.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXp -lXext -lX11 ./libvncauth.a -L/usr/local/lib -lz -L/usr/local/lib -ljpeg -L../../nxcomp -lXcomp -L../../nxcompext -lXcompext [END OF COMPILE, START OF THE ERRORS] ../../nxcomp/libXcomp.so: undefined reference to `typeinfo for std::exception@GLIBCPP_3.2' ../../nxcomp/libXcomp.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char)@GLIBCPP_3.2' ../../nxcomp/libXcomp.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >::seekp(std::fpos<__mbstate_t>)@GLIBCPP_3.2' ../../nxcomp/libXcomp.so: undefined reference to `std::exception::~exception [in-charge]()@GLIBCPP_3.2' . . . AFAICT, this means is that nxcomp is referring to C++ libraries, but being compiled into nx-x11 using C, which is a no-no. The same thing happens on all the rest of the libraries that use nxcomp. I went through manually and changed the "CC" line in the make file for nxviewer to use C++, and compiling continued smoothly. I'm using a fairly new, up to date system (x86, not ~x86). Any idea how to change this so that it does the right thing? I can give you any info you think might be helpful in identifying the problem.
nxagent is now 93. 90 is no longer available.
Created an attachment (id=70221) [details] nx-x11-1.4.0-r4-to-1.5.0-r3.diff nxagent was updated from version 90 to 93 nxdesktop was updated from version 61 to 75. The notes on the nomachine website said that this is the second maintainace release for the 1.5 series. Supposedly a lot of bugs was fix. :) I hope this fixes issues people have been reporting in the forum thread.
Created an attachment (id=70222) [details] nxclient-1.4.0-r5-to-1.5.0-r2.diff nxclient was updated from version 106 to 113. Just a note: On Windows, I noticed some serious errors using version 114 of the client. I hope the errors are not present in the 113 release of the linux client. If you do have troubles, try to find the 106 version and use a previous ebuild and install that one. The 106 version is not available anymore on the nomachine servers, so the ebuilds need to be updated anyways.
Created an attachment (id=70224) [details] NX and FreeNX ebuilds Updated ebuilds in the overlay.
Thanks again, Jon. I would appreciate if your fine ebuilds can become part of ~x86. Just a little note: I had to remount /tmp with exec flag during the emerge. nx-x11 ebuild wants to execute a script there. I think this not desirable, at least unusual.
It sure looks like a lot of people are working hard on this, and a lot of folks are waiting. Is this anywhere close to being taken care of and committed? I am unable to get much help on freenode #nx because they are telling me nxserver-freenx in gentoo is too old for them to support. And I am having very nasty bugs where the keyboard doesn't work at all.
I have download the ebuild and it seems to work. Except, I need to change the URI_BASE to use 64.34.161.181 instead of nomachine.com
we have three bugs which are all about nx-1.5.0 and freenx-0.4.4 (98591, 101691, 101715) - maybe we could merge the results, clean a bit up and get the toys in portage :)
btw- the downloads in the latest ebuilds do not work for some reason or another.
jep - the 1.5.0 downloads dont work anymore - the latest version is 1.5.0 build 135 ...
Can we *please* get something working in portage? So many people are waiting on this...
I try both ebuild version (this post and the other one) and they didnt work. I modify the URL to be valid with new NX version but i still have some TEXTREL errors and no files is copy. Anyone know how to fix ?
Created an attachment (id=76744) [details] nx-x11-1.4.0-r4-to-1.5.0-r4.diff Updates some file versions to the latest release. comment further down for a list of all changes.
Created an attachment (id=76745) [details] nxclient-1.4.0-r5-to-1.5.0-r3.diff Update to the newest version. See comment further down for details.
Created an attachment (id=76746) [details] nxcomp-1.3.2-r1-to-1.5.0-r2.diff Update to the newest version. See comment further down for details.
Created an attachment (id=76747) [details] nxproxy-1.4.0-r2-to-1.5.0-r2.diff Updates to the newest versions. See comment further down for details.
Created an attachment (id=76748) [details] nxssh-1.4.0-r1-to-1.5.0-r2.diff Updates to the newest version. See comment further down for details. The next one actually. ;)
Created an attachment (id=76750) [details] NX and FreeNX overlay.tar.bz2 This is the overlay of all the updated ebuilds. Changlog: nxcomp updated from build 65 to build 80 nxcompext was updated from build 16 to build 20 nxssh was updates from build 21 to build 23 nx-X11 was updated from build 15 to build 21 nxagent was updated from build 93 to build 112 nxviewer was updated from build 14 to build 15 nxdesktop was updated from build 75 to build 78 Cosmetic changes in the ebuilds. You won't notice anything unless you look at the ebuild. :) Lots of changes. Happy compiling. Oh, since this bug report has a REALLY long list of obsoleted files, is there a way to hide them so I don't see them all? Or we can start a new bug report. :P
Oh, I forgot to mention. All ebuilds have been marked as ~ARCH, except for FreeNX. FreeNX is marked as ~ARCH in the overlay, but I didn't bother making a new diff for that. I decided that since all the NX ebuilds needed a version bump, that I might as well make them all ~ARCH because that's what they are suppose to be. :)
Wed Jan 11 17:25:46 CET 2006 Full build of XFree86 version 4.3.0 (27 February 2003) complete. imake -DUseInstalled -I/usr/X11R6/lib/X11/config In file included from /usr/X11R6/lib/X11/config/site.def:44, from /usr/X11R6/lib/X11/config/Imake.tmpl:45, from Imakefile.c:35: /usr/X11R6/lib/X11/config/host.def:51: NX-Linux.def: No such file or directory In file included from /usr/X11R6/lib/X11/config/site.def:146, from /usr/X11R6/lib/X11/config/Imake.tmpl:110, from Imakefile.c:35: /usr/X11R6/lib/X11/config/host.def:51: NX-Linux.def: No such file or directory imake: Exit code 1. Stop. !!! ERROR: net-misc/nx-x11-1.5.0-r4 failed. !!! Function src_compile, Line 52, Exitcode 1 !!! unable to create makefile for nxviewer !!! If you need support, post the topmost build error, NOT this status message. I have this errors message when i try.
>>> Install nx-x11-1.5.0-r4 into /var/tmp/portage/nx-x11-1.5.0-r4/image/ category net-misc /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/Xext /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/Xrender /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nxcomp /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nxcompext /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 man: prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded usr/NX/bin/nxagent usr/NX/bin/nxauth usr/NX/bin/nxviewer usr/NX/bin/nxpasswd usr/NX/bin/nxdesktop usr/NX/lib/libX11.so.6.2 usr/NX/lib/libXext.so.6.4 usr/NX/lib/libXrender.so.1.2 usr/NX/lib/libXcomp.so.1.5.0 usr/NX/lib/libXcompext.so.1.5.0 QA Notice: the following files contain runtime text relocations Text relocations require a lot of extra work to be preformed by the dynamic linker which will cause serious performance impact on IA-32 and might not function properly on other architectures hppa for example. If you are a programmer please take a closer look at this package and consider writing a patch which addresses this problem. TEXTREL usr/NX/lib/libXcomp.so.1.5.0 TEXTREL usr/NX/lib/libXcompext.so.1.5.0 >>> Completed installing nx-x11-1.5.0-r4 into /var/tmp/portage/nx-x11-1.5.0-r4/image/ I have a different error on my 2nd node (i compile actually on the third one)
>>> Install nx-x11-1.5.0-r4 into /var/tmp/portage/nx-x11-1.5.0-r4/image/ category net-misc /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/Xext /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11/lib/Xrender /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nxcomp /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nxcompext /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 /var/tmp/portage/nx-x11-1.5.0-r4/work/nx-X11 man: prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded strip: i686-pc-linux-gnu-strip --strip-unneeded usr/NX/bin/nxagent usr/NX/bin/nxauth usr/NX/bin/nxviewer usr/NX/bin/nxpasswd usr/NX/bin/nxdesktop usr/NX/lib/libX11.so.6.2 usr/NX/lib/libXext.so.6.4 usr/NX/lib/libXrender.so.1.2 usr/NX/lib/libXcomp.so.1.5.0 usr/NX/lib/libXcomp.so.1.5.0 will contain runtime text relocations Text relocations require a lot of extra work to be preformed by the dynamic linker which will cause serious performance impact on IA-32 and might not function properly on other architectures hppa for example. If you are a programmer please take a closer look at this package and consider writing a patch which addresses this problem. usr/NX/lib/libXcompext.so.1.5.0 usr/NX/lib/libXcompext.so.1.5.0 will contain runtime text relocations Text relocations require a lot of extra work to be preformed by the dynamic linker which will cause serious performance impact on IA-32 and might not function properly on other architectures hppa for example. If you are a programmer please take a closer look at this package and consider writing a patch which addresses this problem. >>> Completed installing nx-x11-1.5.0-r4 into /var/tmp/portage/nx-x11-1.5.0-r4/image/ And one the third, i don't have any idea of what is the problem, i m quite new with gentoo and never see this errors before
To be honest. I don't know what that error is. It compiled cleanly on my system. Did the install just stop there? Or did it install but give you that message?
Nothing install, it finish with this 3 messages. I don't know why it doesn t work on 3 computers (but it's the same install and exactly same hardware). Do you have any ideas what test can i do to find (and fix) this errors ?
(In reply to comment #57) > Wed Jan 11 17:25:46 CET 2006 > > Full build of XFree86 version 4.3.0 (27 February 2003) complete. > > imake -DUseInstalled -I/usr/X11R6/lib/X11/config > In file included from /usr/X11R6/lib/X11/config/site.def:44, > from /usr/X11R6/lib/X11/config/Imake.tmpl:45, > from Imakefile.c:35: > /usr/X11R6/lib/X11/config/host.def:51: NX-Linux.def: No such file or directory > In file included from /usr/X11R6/lib/X11/config/site.def:146, > from /usr/X11R6/lib/X11/config/Imake.tmpl:110, > from Imakefile.c:35: > /usr/X11R6/lib/X11/config/host.def:51: NX-Linux.def: No such file or directory > imake: Exit code 1. > Stop. > > !!! ERROR: net-misc/nx-x11-1.5.0-r4 failed. > !!! Function src_compile, Line 52, Exitcode 1 > !!! unable to create makefile for nxviewer > !!! If you need support, post the topmost build error, NOT this status message. > > I have this errors message when i try. > On this computer, see if you have the symlink /usr/X11R6 pointing to /usr. That's the only thing that I can think of. Also, what version of X do you have installed on all three systems?
Created an attachment (id=77184) [details] freenx-0.4.5.tar.gz This is a new version that I found on the SVN server. There is no package anywhere out there, but it is the next release. Here is what changed from version 0.4.4: 0?.09.2005 FreeNX 0.4.5 "aKademy Edition" * Made nxsetup more user-friendly and hopefully finally failsafe. * Added --agent to nxnode/nxserver to allow easier debugging. * Added addgroup/groupadd to nxsetup * Added --ignore-errors support on nxsetup/nxloadconfig * Added check for expect. The new nxsetup does contain a lot of bug fixes and no longer needs my fix like with version 0.4.4. They also changed it so it is more Gentoo friendly. :D It's very Gentoo friendly now, actually. So, this version should really go into portage, though it would need to be put on the Gentoo mirrors since it's not on the debian download site. The experimental 0.5.0 is though. :S Ah well. The ebuild will follow shortly after I test it more. :)
Created an attachment (id=77188) [details] nxserver-freenx-0.4.0-to-0.4.5.diff This is a diff to update the version 0.4.4 ebuild. I used the same source URI as the previous ones even though it's not on that server, because I don't know what else to put.
Created an attachment (id=77189) [details] nxserver-freenx-0.4.5.ebuild This is the new ebuild. It's not in the overlay because you need to downlad the compressed file above and put it in your distfiles directory. That package is not up on any mirrors. Then put this ebuild in your net-misc/nxserver-freenx overlay dir and digest it. :)
Created an attachment (id=77191) [details] nxserver-freenx-0.5.0.ebuild Here is the ebuild for the very experimental version 0.5.0. I do not recommend using this version. The download link actually works here, so you just need to DL the ebuild, put it in your overlay, and then digest it. :) I am not brave enough to use this version. They call this a LWE release, but I looked at the files on the SVN and it appears that this build is older than files tagged with 0.4.5. Also, the nxsetup is the older one with this release, so there may be some bugs in it. But, if you try this and find any bugs, submit them upstream. They do need testers and having an ebuild here will make this more readily available for those brave enough to try it out. :) BTW, I would recommend the current trunk if you do have any issues with a certain file. ;)
Created an attachment (id=77331) [details] This makes nxcomp compile with gcc4
When i try nxcomp, it s compile fine (i have to edit Makefile.in in nxcomp tarballs because it's missing -fPIC and then ld say an error about textrel) but nothing is install. No error at all but libXcomp aren t copy in /usr/NX/lib/ I use the last ebuild available here. I try to modify the ebuild and adding cp -rf libXcomp.so* but then i have an error about access violation. Anyone have an idea why it s no copying ? I have just try nxproxy, and i have the same problem, all work fine (except many warning errors but i think it's not a problem) but nothing is install (on /usr/NX/bin for nxproxy).
I fix my problem some invalid chmod from previous installation. For those, who have TEXTREL problem, download nxcomp in your distfiles directory, untar it, add -fPIC to GCC and G++ compilation flags, retar the directory to the same name, rebuild the digest file for nxcomp and reinstall it.
(In reply to comment #65) > Created an attachment (id=77189) [edit] [details] > nxserver-freenx-0.4.5.ebuild > > This is the new ebuild. It's not in the overlay because you need to downlad the > compressed file above and put it in your distfiles directory. That package is > not up on any mirrors. Then put this ebuild in your net-misc/nxserver-freenx > overlay dir and digest it. :) > The package no longer exists on the debian web page. Can you post the package somewhere please?
I have downloaded the nxserver-freenx-0.4.5.tar.gz package from this page, but when I try to emerge, I get the following error when it is extracted: >>> Unpacking freenx-0.4.5.tar.gz to /var/tmp/portage/nxserver-freenx-0.4.5/work tar: This does not look like a tar archive tar: Skipping to next header tar: Archive contains obsolescent base-64 headers tar: Error exit delayed from previous errors
Hi, I've started testing the attached ebuilds, and moving them into the Gentoo NX overlay. I'll post an update when the overlay is available for download. If anyone's interested in helping to maintain NX and FreeNX on Gentoo, please pop into #gentoo-nx on IRC and say hello :) Best regards, Stu
Both the 0.4.5 and the 0.5.0 ebuild create run enewuser with /bin/false as the shell. This gives me an error that says to specify -1 when wanting /bin/false. I just edited the ebuild, replacing -1 for /bin/false and it emerged fine creating a newuser with shell /bin/false.
Hi, All the components required for FreeNX 0.5.0 are now in Portage. They are currently package masked for further testing. Best regards, Stu
> All the components required for FreeNX 0.5.0 are now in Portage. They are > currently package masked for further testing. Can you please explain to us why you put an ancient 0.5.0 pre-release version as 0.5.0 into the tree when only now the FreeNX developers are releasing first snapshots? http://mail.kde.org/pipermail/freenx-knx/2006-March/003101.html http://mail.kde.org/pipermail/freenx-knx/2006-March/003107.html http://mail.kde.org/pipermail/freenx-knx/2006-March/003115.html Sorry, but I find that negligent.
(In reply to comment #75) > Sorry, but I find that negligent. Perhaps becouse when the ebuild was submitted it was the latest availible snapshot... Anyway, it's nice upstream is comming to live again.
I just caught Stuart on IRC - the confusion will be resolved by moving to a "0.5.0_preN" version number scheme based on the snapshots.
Well, 0.5.0.<date> which will update people who already have this installed. :) Or deleting it from portage would force them to downgrade, but people don't like to downgrade. :P
It was hard masked, so no one should be installing it if they don't follow bugzilla (or at the very least the Changelog), so I think the best would be to actually correct the problem. Thus imho Stuart should remove the current 0.5.0 ebuild and replace it with 0.5.0_pre3, and note in the changelog that it actually IS an upgrade (by 7 months of development), eventhough a lower version number.
Yeah, I think 0.5.0.<date> would indeed be better due to the upgrade path it enables. OTOH, there have been two snapshots today ... ;) Fabian just put out Snapshot 4: http://mail.kde.org/pipermail/freenx-knx/2006-March/003136.html
Check the ebuilds here: http://svn.gnqs.org/svn/gentoo-nx-overlay/ and see they work right for you all. I think they should, and I hope they are named right, if not, let me know. Snapshot 4 ebuild is already up there in that link. ;) Cheers
Adding the fix for this should definitely be considered: http://developer.berlios.de/bugs/?func=detailbug&bug_id=5448&group_id=2978 Plastik being the default window decoration for KDE 3.4 and 3.5.
(In reply to comment #81) > Check the ebuilds here: > http://svn.gnqs.org/svn/gentoo-nx-overlay/ > and see they work right for you all. I think they should, and I hope they are > named right, if not, let me know. freenx-0.4.4 on 1.5.0 backend works for me (on my gcc-3.4.5 box), after I applied this patch: epatch $FILESDIR/freenx-0.4.4-adduser-fix.patch - epatch $FILESDIR/$P-0.4.4-xorg7.patch + epatch $FILESDIR/$PN-0.4.4-xorg7.patch } Also nx-x11 didn't compile on my gcc 4.0.2 box unless I commented out nxesd. If I do so it works great, but I haven't tested sound yet...
Diff for the Plastik rendering issue: --- nx-X11/programs/Xserver/hw/nxagent/GCOps.c~ 2005-11-25 21:42:23.000000000 +0100 +++ nx-X11/programs/Xserver/hw/nxagent/GCOps.c 2006-03-08 11:28:43.000000000 +0100 @@ -2385,7 +2385,7 @@ { if ((pDrawable)->type == DRAWABLE_PIXMAP) { - miPolySegment(nxagentVirtualDrawable(pDrawable), pGC, nSegments, pSegments); + fbPolySegment(nxagentVirtualDrawable(pDrawable), pGC, nSegments, pSegments); } return; @@ -2423,7 +2423,7 @@ } nxagentGCTrap++; - miPolySegment(nxagentVirtualDrawable(pDrawable), pGC, nSegments, pSegments); + fbPolySegment(nxagentVirtualDrawable(pDrawable), pGC, nSegments, pSegments); nxagentGCTrap--; return; }
@Jon: I will fix that naming error with the patch, and the esd stuff compiled for me. I have GCC 4.1 final and a beta build of glibc. I think I might have either forgotten to add in another dependency, or it is compatible only with the 1.5.0 backend. Are you using 1.5.0 or 1.4.0? Do you have the esd flag set and all the esound packages installed (I am thinking that is the dependemcy I missed)? @Eric. I will add that patch. Thanks. :)
@Jon: Well, you were using 1.5.0. *whacks self in head* I need to wake up today. :P But, do you have the esd flag set and have all the esound stuff installed? Oh, are you using xorg 6.8 or 6.9/7.0?
(In reply to comment #86) > @Jon: Well, you were using 1.5.0. *whacks self in head* I need to wake up > today. :P But, do you have the esd flag set and have all the esound stuff > installed? Oh, are you using xorg 6.8 or 6.9/7.0? Yes, I'm using the 1.5 backend. I'm using xorg 6.8, and do not have regular esd installed, nor the esd USE flag set, but as I understand it nxesd is a modified *replacement* for regular esd nessesary for the nxclient to work. I've got all dependencies for media-sound/esound installed though, so I doubt it's a missing dep. I know for sure that freenx doesn't require nxesd, but rather requires the regular esd libraries to be on the server (no nead for esoundd to run though) for sound forwarding to an (nx)esd client to work (nxclient-1.4 on Linux uses standard artsd, not (nx)esd, in which case freenx needs the arts libraries, but not a running artsd, for sound forwarding to work). Of course you have to enable the correct line in node.conf first though.
Created an attachment (id=81689) [details] nxesd ebuild After some more digging I found it had nothing to do with GCC4. It was a missing dependency that was installed, but broken (triple error?). Re-installation of media-libs/audiofile solved the problem. However, as nx-x11 doesn't depend on nxesd, nor nxesd on nx-x11, I don't think they have anything to do in the same ebuild. In addition FreeNX doesn't depend on nxesd, so splitting the ebuild would reduce unnessesary dependencies on a server-only setup as well. I've attached an nxesd ebuild, based mostly on the current esound ebuild, that works great. If you use this you'll have to remove the nxesd bits from nx-x11, and add a dependency in nxclient on nxesd.
Thanks. :) I will look at your ebuild and definately try this out when I have time. :) But for now, I put the esd stuff in if statements and I have a use flag, so if someone doesn't want it, then can disable the use flag. :) Thanks for the ebuild. :)
Do these ebuilds provide resume support in windows/linux? I tried windows nxclient against kde-3.5.1 but on doing log-out there was only "End current session" and there was no resuming option.
Reaume has nothing to do with kde - just close the nx client window and a popup window will appear inside the window (ie on the kde desktop) with the suspend option. IF it dosen't appear it's not working properly.
Snapshot 5 is out: http://mail.kde.org/pipermail/freenx-knx/2006-March/003192.html Also, Jon added the Plastik rendering patch to the nx-x11 ebuild in the overlay. Can't wait for the overlay to be synched with the tree.
Okay. Snapshot 5 is in the overlay. :) And Yeah. I added that patch in there. :) I don't use plastik anymore, though. :P I am working on having nxesd separate. :) I will have that up tomorrow if there is no work again. Work is cancelled due to the bosses death. :( So, I don't know when there will be a new boss or how things will work out from here. So, maybe tomorrow, if not the weekend. :)
@Jon Severinsson: I was thinking about your nxesd ebuild and wondering about the people that have teh commercial version of the server. I think this is why nxesd was put into the nx-x11 ebuild to begin with. The depends need to be changed around so that if the commercial version is installed, then nxesd is not installed, or if nxesd is installed, the the commercial version cannot be installed. Or, it left in the nx-x11 ebuild. You can disable the building of it through a use flag. I will see how changing the depends about in the nxclient ebuild goes to see how that works out. :)
I've just finally switched to the overlay and FreeNX 0.5.0 snapshot 5, which is working out very well for me. Many of the issues that have plagued me with 0.4.4 and 0.4.5 (and were not present in the commercial server) are now gone: the Plastik window decoration rendering bug, my non-US keyboard layout being forgotten on resume and the Windows client resume malbehavior that would create two windows and ignore session size completely. Resuming sessions accross client platforms (i.e. using the Windows client to connect to a session initially created with the Linux client, or vice versa) still doesn't work at all, although that is apparently due to limitations in the Cygwin X server used by the Windows client and not specific to FreeNX.
Addendum: One little problem has appeared. I'm running KDE in my FreeNX session, and previously, the "Suspend / Terminate / Cancel" dialog used to be a nice-looking Qt window; now it's an ugly xmessage. It's a purely aesthetic and not functional issue, but I thought I should mention it ;).
It was always a xmessage window for me, i never see qt window for resume/suspend/terminate. Maybe do a ebuild with FreeNX SVN will help cause snapshot is just a tgz of subversion.
(In reply to comment #94) I don't quite see the problem. If one was to do a 100% binary install using the official !M rpms then libXcomp.so and nxesd will be provided by nxclient, and the rest of nx-x11 will be provided by nxserver. However, nxclient is a dependency of nxserver, so nxesd will be included in a !M nxserver installation. There is no problem with nxesd existing on the same computer as !M nxserver. If you mean that the !M nxserver ebuilds should install the binary nxesd from the !M nxclient rpm (and thus create a conflict), I must disagree, that just doesn't make sense. nxserver depends on nxclient which depends on nxesd, and you will get a locally compiled nxesd when installing !M nxserver, just as you get a locally compiled libXcomp.so. My impression from last time a separate nxesd was discussed is that it was included in nx-x11 because Stuart didn't know it wasn't used on Linux at all during the 1.4 live cycle (as the Linux client used standard arts instead). He saw it wasn't needed by the client, and assumed it was needed by the server, which wasn't true (it was only needed by the Win and Mac clients). And on a similar note: I'm currently experimenting with making a separate nxcomp ebuild (providing libXcomp.so) to work nicely with nx-x11 (now not compiling libXcomp.so). I'm not done jet, but I'm making progress. Probably just a few more makefiles that has to be sed-ed. If I get it to work the interdependencies of my nx ebuilds would be: nxesd: No interdependencies nxcomp: No interdependencies nxproxy: nxcomp nxssh: nxcomp nx-x11: nxcomp nxclient: nxesd nxssh nxserver-!M: nxclient nx-x11 nxserver-freenx-0.4*: nxproxy nx-x11 nxserver-freenx-0.5*: nx-x11 That way a nxclient install will only pull nxesd, nxcomp and nxssh, a freenx install (with USE=-commercial) will only pull nxcomp, nxproxy and nx-x11, while a !M nxserver install will pull nxesd, nxcomp, nxssh, nx-x11 and nxclient.
(In reply to comment #97) > It was always a xmessage window for me, i never see qt window for > resume/suspend/terminate. It's supposed to be a nice QT window if you have USE=commercial, but an uggly xmessage if you have USE=-commercial. If you have USE=-commercial you can get a sligtly less uggly Xdialog by "emerge x11-misc/xdialog" (pressence of /usr/bin/Xdialog is detected at runtime) It has aways worked for me since 0.3.0.
(In reply to comment #99) > It's supposed to be a nice QT window if you have USE=commercial, but an uggly > xmessage if you have USE=-commercial. Ah, thanks for clearing that up :). Looks like I'm quite happy, then.
Okay. Major update to the overlay. I messed up the commit log though. <_< Oh well, luckily it's only the overlay. :) Is there a way to change the logs for a revision after it's been submitted using svn? Changelog: -nxcomp is back in. -nxesd was split out of nx-x11 and is now depended upon by nxclient. (thanks to Jon Severinsson for suggesting that) -Changed the dependencies a bit to depend on nxproxy when needed and also changed to ~category/package-version format instead of the =category/package-ver* format for dependencies. Some clean ups. -Cleaned up the install section of nx-x11 a lot. It looks a lot nicer now. And it doesn't install nxcomp since it's already installed, by nxproxy. According to the NoMachine website, one of the programs needs it. I think it was nxauth. Either that, or the other one, I forget. :P So, I set that as a dependency and makefile finds it by the include and ldpaths. -The file with the paths gets installed by nxcomp. It is installed as 50nxpaths and it has all paths, so anything that has to do with /etc/env.d has been removed from all other ebuilds. :) Make sure that 50nxplaths is the only nx file in /etc/env.d. Just in case there are left overs. :P I think that is the changelog. TODO: The reason it took me so long was that I was trying to separate nxcomp, nxcompext, nxdesktop, and nxviewer from the nx-x11 ebuild, but all those programs are interdepended on each other. It's a bloody nightmare, so a lot of work needs to be done to sever those programs from that ebuild. I am going to write the devs of NX a nice email detailing how they break the rules of coding by what they did. :P Well, actually, it will be nice and I will explain to them that they should not hav edone things the way they did and need to change the makefiles around a lot. Hopefully, they can release another maintainace release that clears this up, or have it fixed by 2.0. :) I like the No Machine software, but they do need to change the install process a lot. It really should not be the way they have it. It's just wrong. My two cents. Cheers PS. Woot! This bug has over 100 posts now. :P Maybe we should start a new one. This is getting hard to read. :P
OK, I took a look at your ebuilds and compared them with mine. Here are some comments: General: * You use "dolib ... " fololowed by "preplib preplib /usr/NX/lib". I do "dolib.so ..." and getting .so permissions correct from the start. * You create a env.d file in nxcomp, specifying PATH, ROOTPATH and LDPATH. I only create it in nxclient, as they are not required in freenx. My env.d file dosn't contain LDPATH, as only !M nxserver requires it, and it can have a negative impact on your system. When you create ebuilds for !M nxserver add another env.d file with LDPATH that is only installed for those installing the !M nxserver. nxcomp: * I got version number on deps: * >=media-libs/jpeg-6b-r3 * >=media-libs/libpng-1.2.8 * >=sys-libs/zlib-1.2.1-r2" * I'm giving prefix to econf: * econf --prefix="/usr/NX/" || die "Unable to configure nxcomp" * I don't install any headers in /usr/X11R6/include, as the ones in /usr/NX/include is sufficient, if you sed some makefiles. nxproxy: * I don't list jpeg, png and zlib as deps, as they are pulled in by nxcomp * I have a compile time only dep on sys-apps/sed * I've got a more generic sed command: * sed -i '/^s/-I *..\/nxcomp/-I\/usr\/NX\/include/' Makefile.in nxssh: * I got version number on deps: * >=dev-libs/openssl-0.9.7d-r1 * >=sys-libs/zlib-1.2.3 * tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) * pam? ( >=sys-libs/pam-0.73 ) * I'm sed-ing configure so I don't have to put NX.h in /usr/X11R6/include * sed -i 's/-I *..\/nxcomp/-I\/usr\/NX\/include/' configure * I have a compile time only dep on sys-apps/sed nxesd: * As !M isn't exactly known for fixing makefiles I don't trust emake install Instead I use: * into /usr/NX * dobin nxesd nx-x11: * Download URL for nxviewer and nxdesktop should be conditional. * I'm positive nxproxy isn't needed by nx-x11. As of 1.5 it is a legacy program, not used at all by !M, and only required by freenx 0.4 (not 0.5). So I'm depending on nxcomp instead. * What is app-text/rman required for? It works without it for me. * I don't depend on jpeg, as it is pulled by nxcomp. nxclient: * amd64 is missing lots of deps: * app-emulation/emul-linux-x86-compat * >=app-emulation/emul-linux-x86-baselibs-2.1.4 * >=app-emulation/emul-linux-x86-xlibs-2.2.1 * >=app-emulation/emul-linux-x86-qtlibs-2.1.1 * my x86 deps list is shorter, as I don't pull stuff already pulled my nxcomp * sys-libs/lib-compat * >=dev-libs/expat-1.95.6-r1 * >=media-libs/fontconfig-2.2.0-r2 * >=media-libs/freetype-2.1.4 * >=x11-libs/qt-3.3.2 * corrected the comment regarding nxesd to "delivered by net-misc/nxesd" In adition keywords differ. My ebuilds has keywords so ~x86 and ~amd64 can install nxclient + deps (tested, it does work) and so ~x86 and ~ppc can install freenx + deps (not tested by me, as I don't own a ppc box, but stated to work by others, though that was ofcouse older versions). So my keywords is as follows: nxcomp & nxproxy: ~x86 ~amd64 ~ppc nxssh & nxesd: ~x86 ~amd64 nxclient: -* ~x86 ~amd64 nx-x11: ~x86 ~ppc
[quote] General: * You use "dolib ... " fololowed by "preplib preplib /usr/NX/lib". I do "dolib.so ..." and getting .so permissions correct from the start. * You create a env.d file in nxcomp, specifying PATH, ROOTPATH and LDPATH. I only create it in nxclient, as they are not required in freenx. My env.d file dosn't contain LDPATH, as only !M nxserver requires it, and it can have a negative impact on your system. When you create ebuilds for !M nxserver add another env.d file with LDPATH that is only installed for those installing the !M nxserver. [/quote] Wait until I release the experimental overlay, then you will see why I put the 50nxpaths file in nxcomp. ;) There are some _major_ changes in the experimental overlay. I hope to have that up this weekend, so we will see. :) If not, sometime during the week next week. It's a lot of hard work and patching. :P I will look into the dolib.so. Remember, my ebuild are based on the original ebuilds from portage. So thanks for that tip. ;) [quote] nxcomp: * I got version number on deps: * >=media-libs/jpeg-6b-r3 * >=media-libs/libpng-1.2.8 * >=sys-libs/zlib-1.2.1-r2" [/quote] media-libs/jpeg-6b-r5: is marked stable on all archs, there is nothing less than r4 in portage, so version number not needed. media-libs/libpng-1.2.8: is marked stable on all archs and there is no version less than this in portage, so version number not needed. sys-libs/zlib-1.2.1-r2: version 1.2.3 is the only version in portage, so version number not needed. So, the version numbers will not be added back unless versions that are marked ~ARCH or not in portage are needed as depends. :) [quote] * I'm giving prefix to econf: * econf --prefix="/usr/NX/" || die "Unable to configure nxcomp" * I don't install any headers in /usr/X11R6/include, as the ones in /usr/NX/include is sufficient, if you sed some makefiles. [/quote] Yeah, I can add the --prefix. It's just not needed though since the default seems to be /usr/NX/ and this is basically the ebuild from portage that Stu made, but I guess it wouldn't hurt to change to add that incase the configure script changes. [quote] nxproxy: * I don't list jpeg, png and zlib as deps, as they are pulled in by nxcomp * I have a compile time only dep on sys-apps/sed * I've got a more generic sed command: * sed -i '/^s/-I *..\/nxcomp/-I\/usr\/NX\/include/' Makefile.in [/quote] Yeah. This is minor cosmetic changes. I will clean up the depends a bit more in the next overlay release. :) [quote] nxssh: * I got version number on deps: * >=dev-libs/openssl-0.9.7d-r1 * >=sys-libs/zlib-1.2.3 * tcpd? ( >=sys-apps/tcp-wrappers-7.6 ) * pam? ( >=sys-libs/pam-0.73 ) [/quote] dev-libs/openssl-0.9.7d-r1: 0.9.7i is stable, so version numbers not needed. sys-libs/zlib-1.2.3: This version is stable and will be brought in in an emerge, so version numbers not needed. sys-apps/tcp-wrappers-7.6: That's the only version in portage. sys-libs/pam-0.73: pam 0.78 is stable. [quote] * I'm sed-ing configure so I don't have to put NX.h in /usr/X11R6/include * sed -i 's/-I *..\/nxcomp/-I\/usr\/NX\/include/' configure * I have a compile time only dep on sys-apps/sed [/quote] wait until the experimental release, until then there is no point in changing it. It doesn't hurt anything by having that file in /usr/X11R6/include right now. After the experimental release, there will be no need for this line at all. ;) All I will say. :P [quote] nxesd: * As !M isn't exactly known for fixing makefiles I don't trust emake install Instead I use: * into /usr/NX * dobin nxesd [/quote] I don't trust their ebuild either, but everyone knows that since my last paost in the bug thread. :P There are lot more files than just nxesd. There is a nxesd cofigure script, and a bunch of other things. So, some users may need all of that, so I am giving them all of that. :) As you can tell, it does actually install to the right directory for now. :) I will keep an eye out on the makefiles and make sure everything is installed right in the future, if they change the makefile too much, I will maually copy all those new files to the correct location. :) There are a lot of them too. <_< [quote] nx-x11: * Download URL for nxviewer and nxdesktop should be conditional. [/quote] Ooops. *turns red* Okay, I for got about that. Yeah, I will correct that one as soon as I can. There will be no revision bumb though since it really isn't major.;) [quote] * I'm positive nxproxy isn't needed by nx-x11. As of 1.5 it is a legacy program, not used at all by !M, and only required by freenx 0.4 (not 0.5). So I'm depending on nxcomp instead. * What is app-text/rman required for? It works without it for me. * I don't depend on jpeg, as it is pulled by nxcomp. [/quote] I only have nxproxy there because the !M website said too. :P I will change that later, but 0.5.0 is not fully released yet and users still use 0.4.X, so it will stay there until 0.5.0 is fully released. :) As for rman, I actually needed that. I got an error saying that something failed to compile and it said that rman could not be found. :S So, I added that. I am using xorg 7, so that may be part of it, I don't know. All I know is that it failed without it, I installed it, and the nx*forget which component* compiled fine. *shrug* yeah, like I said, I will clean up the depends later. It's hurting nothing by being there, so it's not high on the priority list. [quote] nxclient: * amd64 is missing lots of deps: * app-emulation/emul-linux-x86-compat * >=app-emulation/emul-linux-x86-baselibs-2.1.4 * >=app-emulation/emul-linux-x86-xlibs-2.2.1 * >=app-emulation/emul-linux-x86-qtlibs-2.1.1 * my x86 deps list is shorter, as I don't pull stuff already pulled my nxcomp * sys-libs/lib-compat * >=dev-libs/expat-1.95.6-r1 * >=media-libs/fontconfig-2.2.0-r2 * >=media-libs/freetype-2.1.4 * >=x11-libs/qt-3.3.2 * corrected the comment regarding nxesd to "delivered by net-misc/nxesd" [/quote] Okay, I will add them in. :) Thanks. ^^ In adition keywords differ. Okay, I will fix the keywords as well. :) Again not exactly high on the list of priorities. :P But it will be done. Thanks for your report. Cheers.
Just to clarify ... The testing directory on the svn is for the portage tree eventually. And I will update those ebuilds when I have the time with the suggestions. I need to do several things, so it will most likely be update late tonight or early tomorrow. The experimental directory will be for testing some major changes that are not due to be in portage until they are fully tested and moved to the testing directory. I know I was not too clear about that in the comment above. Sorry about that. I have a lot on my mind at the moment. :P I am thinking about the changes for the ebuilds amongst some other personal issues. :P So, I hope this explains it. :) Cheers.
Okay, while I am at it, I can add in the version numbers. Eike talked me into it on IRC. :P
Well, I got the changes to the ebuilds done. I hope I didn't leave anything out. I am really tired right now, but I tried to make the changes I said I was going to make. :) I am installing right now. All you need to do is type emerge nxserver-freenx, and it should bring in everything. It did for me. :) nx-x11 is still compiling right now as I type this, so all the other packages have installed successfully. ^^ These ebuilds work for me. The depends have been cleaned up and in nx-x11, nxdesktop and nxviewer DL only when the use flag is set. There are some other changes and even one not mentioned by Jon S. :P It's a monor one. :P Okay, let me know if there are any problems. Thanks!
Snapshot 6 is out, but the release notes say that it is not finished and may be unstable, so I have not wrote an ebuild for it yet. Maybe he will release another version soon that is fixed up more. :) Cheers.
Hi Jon I didn't mean you should do all changes I listed, I just listed the changes, so you could decide which was good or not. As for the env.d file I must point out that adding /usr/NX/lib to LDPATH can screw up the system pretty badly, and should be avoided if at all possible. So if it's not required by your major changes I would at least remove that line. It'll be interesting to see what major changes you are talking about. Anyway, some more comments: nxcomp: * I'm quite sure libc jpeg, png, zlib is required runtime as well as compiletime (eg. move from DEPEND to RDEPEND). * I don't think NX.h in /usr/X11R6/include hurts anything, it's just imho * unnecessary clutter, and as such should be avoided nxproxy: * Noticed a copy-past error in my sed command was broken. It should ofcource be sed -i 's/-I *..\/nxcomp/-I\/usr\/NX\/include/' nxesd: * I think all those extra files is actually unnecessary, as nxesd contains all components from original esd, but only esoundd is modified and used by !M (called nxesd). Part of why I don't trust the make install is because !M don't use it, and thus haven't fixed it to only install what it's needed (at the moment only the nxesd binary, though that might ofcourse change), nx-x11: * The nxproxy dep isn't a major, isue, but as freenx 0.4.4 and 0.4.5 ebuild already depends on nxproxy separately, that's no good reason for putting it in nx-x11. * rman: All I can say is that I have successfully installed nx-x11 on two machines without rman. Neither used xorg 7.0 though. * nx-x11 does NOT work on amd64, and will not do so until earliest 2.0, and that only if someone donates patches to !M. It was one of the packages I didn't give a ~amd keyword, and that due to a very good reason. When I'm satisfied with the rest of the ebuild I might create a nx-x11-bin package, and thus get freenx to work on amd64, but nx-x11 will not compile on amd64. All in all I must say you are doing a great job, nice to see Gentoo getting up to date with nx, in not a to distant future I might actually be able to dropp my own nx overlay...
Hello Gentlemen, I'm not a programmer but I'm a very interested party in getting nx/freenx working on amd64. I have a dual opteron {242} processor system {ASUS K8N DL} and a single opteron {244} processor system I can help test with. I do know how to set up local portage overlays and I can usually follow intructions. I also have freenx-server runnin on 3 athlon xp based systems. I access all three from work using the !m windows nxclient. I also access 1 from home using the linux nxclient. I'm currently up to date {from here} with the 1.5 / 0.5 {freenx} versions. The 2 opteron and 2 of the athlon xp based systems are local on my home network. The 3rd athlon xp system is ~1260 miles from home. I use nx/freenx to remotely administer my mother's gentoo linux pc. As an emerge addict, I generally keep all my systems pretty up to date.
(In reply to comment #109) Hello Guy If all you need in nxclient, it should work out of the box as long as you use the nx overlay (http://svn.gnqs.org/svn/gentoo-nx-overlay/testing). However, nx-x11 does not compile natively on amd64, so freenx won't work. The x86 binaries runs fine on amd64 however, and in due time we might do a binary ebuild for amd64 users, but untill then the easiest way to get freenx working on a amd64 is to install the ebuilds in a 32bit chroot (or on a x86 computer) and copy the /usr/NX directory. You'll have to install all deps (I think you'll need net-analyzer/gnu-netcat, app-emulation/emul-linux-x86-baselibs and app-emulation/emul-linux-x86-xlibs) and run "/usr/NX/bin/nxsetup --install --setup-nomachine-key" on your amd64 box, and then it should work. Regards - Jon Severinsson
There is a howto here: http://gentoo-wiki.com/HOWTO_FreeNX_Server It explains all about how to compile it for amd64. Hmm. Ebuilds have support for: chroots, changing flags, and changing other variabls listed in that howto. I will investigate doing chroots in ebuilds and see if this is possible. Snapshot 7 is out. I need to update the overlay anyways with a new ebuild and a few changes suggested by Jon S. that I agree on. :) Cheers.
@Jon Severinsson: These are the files that the nxesd ebuild installs, if only nxesd is needed then I will change the ebuild, but if only a few are needed, then I need to maunally install all those, so I need to adjust my ebuild to reflect that. list of files: /usr/NX/bin/esd-config /usr/NX/bin/esdcat /usr/NX/bin/esdctl /usr/NX/bin/esddsp /usr/NX/bin/esdfilt /usr/NX/bin/esdloop /usr/NX/bin/esdmon /usr/NX/bin/esdplay /usr/NX/bin/esdrec /usr/NX/bin/esdsample /usr/NX/bin/nxesd /usr/NX/lib/libesd.a /usr/NX/lib/libesd.la /usr/NX/lib/libesd.so /usr/NX/lib/libesd.so.0 /usr/NX/lib/libesd.so.0.2.36 /usr/NX/lib/libesddsp.a /usr/NX/lib/libesddsp.la /usr/NX/lib/libesddsp.so /usr/NX/lib/libesddsp.so.0 /usr/NX/lib/libesddsp.so.0.2.36 /usr/NX/lib/pkgconfig/esound.pc Long list. :P Cheers.
@Jon Severinsson: There is a downloads directory on the svn, if you get that nx-x11 built for amd64, then you can make a binary of it and I can place it in that directory and point the ebuild to it. :) Maybe then it can go in to the gentoo mirrors. :) Or, if you find out what needs to be done to make it work, I can write patches for it if you can tell me what specifically fails. I don't have an amd64 machine to play with. :P
Updated the overlay. Here's what's new: -New Snapshot 7 ebuild. Be careful, there is a reason this is pre-release. :P -Moved rman to the xorg 7 dependency list, so if you have xorg 6.8 it will not be installed. I need to go through and see why it was needed for me. I might have missed a dependency, but xorg 7 is still package masked, so it won't hurt to have this in portage and the dependencies change for xorg once I find the real dependency. -Deleted the need for nxproxy out of nx-x11 and added nxcom in, since nx-x11 doesn't actually install nxcomp anymore. -Modified the sed line of nxproxy. I need to check to see exactly how much of nxesd is needed before making changes to the ebuild. See the above comment post where I have the list of files. Maybe we can determine exactly what is needed from that list. :) I will be more than happy to change the ebuild once it is determined exactly what's needed. On a side note, I was looking at the freenx node.conf file and it mentions something about esddsp, but that line was commented out, but you can enable it, so maybe more than nxesd is needed? Cheers.
I got to playing around with the keyboard error patch and I remember a symlink from the forums: # ln -s /usr/share/X11/XKeysymDB /usr/lib/X11/XKeysymDB This fixed a lot of keyboard errors for people, including myself. freenx looks for /usr/lib/X11/XKeysymDB which isn't there. Point being, I am trying to get rid of two patch files which are virtually identical, just a minor change. I would like to have only one file and maybe sed the patch file? But, there is no need to patch it. Since this is only for xorg 7, I have if statements: if [ -f ${ROOT}/usr/share/X11/XKeysymDB ] && \ [ ! -f ${ROOT}/usr/lib/X11/XKeysymDB ] ; then mkdir -p ${D}/usr/lib/X11 dosym /usr/share/X11/XKeysymDB /usr/lib/X11/XKeysymDB fi mind the formatting. :P Good? bad?
I know for sure that the only one of the listed files that is installed by !M nxclient + !M nxserver is nxesd, and I have gotten sound forwarding to work with only nxesd and no standard esound on the client, and only standard esound no nxesd on the server, so I assume no other files are nessesary. esddsp on the nxserver is the standard esound one, and if you like to you can add a conditional media-sound/esound dep to freenx, as well as a conditional kde-base/arts dep. (It might also be useful to conditionally sed nxloadconfig and node.conf to enable them by default. Doing the same with cups might also be of interest.) I'll start work on a nx-x11-bin ebuild, and accompanying tarball, tomorrow.
That;s a good idea. :D I will change the nxesd ebuild when I wake up. :) It's 3 AM here. :P And look at adding the sed lines. to FreeNX. Although, I have thought about the symlink lines in my above comment. I like that better than having two patches, but it just isn't good, so I think I will add the patch back in, rename it, and in the FreeNX 0.4.4 ebuild, use a sed line to change the patch. I think that is the best solution. But, I am going to clean the patch up a bit. ;)
Thank you both @jon and @jon.s. The pointers are appreciated. I don't have an urgent need for running the freenx server on the AMD64 machines at the moment. I would just like to be able to run them from work. As it is, I can easily log into my firewall via putty and ssh to them as needed. Given how quickly and the extent of the changes you are making. I believe I'll wait a little bit. FWIW: This is where the emerge of nx-x11 breaks: rm -f nxviewer x86_64-pc-linux-gnu-gcc -o nxviewer -O2 -fno-strength-reduce -fno-strict-aliasing -L../../nx-X11/exports/lib argsresources.o colour.o cursor.o desktop.o dialogs.o fullscreen.o listen.o misc.o popup.o rfbproto.o selection.o shm.o sockets.o tunnel.o vncviewer.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXp -lXext -lX11 ./libvncauth.a -L/usr/local/lib -lz -L/usr/local/lib -ljpeg -L../../nxcomp -lXcomp -L../../nxcompext -lXcompext ../../nxcompext/libXcompext.so: undefined reference to `_NXContinueOnDisplayError' ../../nxcompext/libXcompext.so: undefined reference to `_NXUnsetLibraryPath' ../../nxcompext/libXcompext.so: undefined reference to `_NXSplitParams' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanAlloc' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanFlush' ../../nxcompext/libXcompext.so: undefined reference to `_NXLostSequenceFunction' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageFrame' ../../nxcompext/libXcompext.so: undefined reference to `_NXColorParams' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageSplit' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanImages' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageMask' ../../nxcompext/libXcompext.so: undefined reference to `_NXImageEnvironmentCached' ../../nxcompext/libXcompext.so: undefined reference to `_NXCleanupEnvironmentCached' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanGet' ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanSend' collect2: ld returned 1 exit status make[2]: *** [nxviewer] Error 1 make[2]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r5/work/nxviewer/nxviewer' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r5/work/nxviewer' make: *** [World] Error 2 !!! ERROR: net-misc/nx-x11-1.5.0-r5 failed. Call stack: ebuild.sh, line 1557: Called dyn_compile ebuild.sh, line 966: Called src_compile !!! unable to make nxviewer !!! If you need support, post the topmost build error, and the call stack if relevant. I had ACCEPT_KEYWORDS="~x86 ~amd64 amd64". I hope that it correct.
(In reply to comment #118) > FWIW: This is where the emerge of nx-x11 breaks: I know, I've tried it myself. Unfortunately this iproblem is known upstream but has no priority at all. So unless you are a savy xorg hacker and are willing to fix it yourself, it won't work. > I had ACCEPT_KEYWORDS="~x86 ~amd64 amd64". I hope that it correct. No, you should NOT use ~x86, as then it'll try to install stuff that won't work on amd64. Just using ACCEPT_KEYWORDS="~amd64" works just fine for everything you can get to work on amd64. I'm almost done with the nx-x11-bin ebuild now, so in a few days time I expect it'll hit the overlay, and then "emerge nxserver-freenx" will just work.
> FWIW: This is where the emerge of nx-x11 breaks: > > rm -f nxviewer > x86_64-pc-linux-gnu-gcc -o nxviewer -O2 -fno-strength-reduce > -fno-strict-aliasing -L../../nx-X11/exports/lib argsresources.o > colour.o cursor.o desktop.o dialogs.o fullscreen.o listen.o misc.o > popup.o rfbproto.o selection.o shm.o sockets.o tunnel.o > vncviewer.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXp -lXext -lX11 ./libvncauth.a > -L/usr/local/lib -lz -L/usr/local/lib -ljpeg -L../../nxcomp -lXcomp > -L../../nxcompext -lXcompext > ../../nxcompext/libXcompext.so: undefined reference to > `_NXContinueOnDisplayError' > ../../nxcompext/libXcompext.so: undefined reference to `_NXUnsetLibraryPath' > ../../nxcompext/libXcompext.so: undefined reference to `_NXSplitParams' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanAlloc' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanFlush' > ../../nxcompext/libXcompext.so: undefined reference to > `_NXLostSequenceFunction' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageFrame' > ../../nxcompext/libXcompext.so: undefined reference to `_NXColorParams' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageSplit' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanImages' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableImageMask' > ../../nxcompext/libXcompext.so: undefined reference to > `_NXImageEnvironmentCached' > ../../nxcompext/libXcompext.so: undefined reference to > `_NXCleanupEnvironmentCached' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanGet' > ../../nxcompext/libXcompext.so: undefined reference to `_NXEnableCleanSend' @ Jon S. and Guy: Can you try the overlay, disable vnc support, by: echo "net-misc/nx-x11 -vnc" >> /etc/portage/package.use And then try to compile it? If it gets to nxviewer, then it finished compiling actual nx-x11 stuff. nxviewer is only needed if you want to do vnc with NX compression. If this works, then if the ARCH is = to amd64, I will just force disable the vnc flag in the ebuild. :)
Yes, if you set USE="-vnc -rdesktop" it will install. Still won't work though... The same story is told upstream. Only known workaround is to install 32 bit binaries, thus my upcomming nx-x11-bin ebuild.
Oh ... Well, I don't know a thing about amd64 settings, so excuse me for asking this ... *turns red* ... but would compiling gcc with multilib support, setting that use flag and then adding -m32 to the compile flags make it compile 32 bit and thus work? I could easily add that to the ebuild. Sorry. I really don't know much about am64, just what I read on the project site.
Created an attachment (id=81991) [details] nx-x11-bin-1.5.0.ebuild Jon: No need to turn red. In therory it *should* work that way, all we should have to do is export ABI=x86 and make sure all library deps excist in 32 bit version and nx-x11 should work. Unfortunately it does not (or at least I didn't get it to work). With USE="-vnc -rdesktop" it installed, but didn't work, while with any of the useflags turned on it din't even compile. So I got the same result as with native compilation (though different error messages). Anyway, I'm now done with the nx-x11-bin-1.5.0.ebuild (attached). For amd64 it'll install a 32 bit version of nxcomp and nx-x11 into /usr/NX/lib32, while for x86 it'll just a drop in replacement for nx-x11.
Created an attachment (id=81992) [details] patch to nxserver-freenx-0.4.4-r1.ebuild to work with nx-x11-bin The freenx ebuild require some changes to work with nx-x11-bin. Diff attached.
The distfile nx-x11-bin-1.5.0.tar.bz2 for previous ebuild is temporarily availible at http://jon.severinsson.net/gentoo/. I'm not going to host it for real though... It was created by compiling nxcomp and nx-x11 in a 32bit chroot, using gcc-3.4.5 with CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer", so in theory it should work on amd64, emt64 and ia64 as well as x86.
I have also spent some time going through the diffs between Jon's and my ebuilds, as we both have changed our since last time I did it. This is not supposed to be a list of things to change, but a list of things to consider. General: Some of your euilds does not have the correct ebuild header from /usr/portage/header.txt I have moved the installation of the environment file from nxcomp to nxclient, as well as removed LDPATH from it. See comment #102 for my reasoning. nxcomp: libc, jpeg, png and zlib are required at runtime as well as compiletime. nxproxy: We are sed-ing so we should state a compiletime dep on sed. nxssh: I'm sed-ing to avoid to install NX.h twice in nxcomp sed -i "s/-I *..\/nxcomp/-I\/usr\/NX\/include/" configure nxesd: Imho "into /usr/NX" and "dobin nxesd" is nicer than "exeinto /usr/NX/bin" and "doexe nxesd", though this is a very minor point. You are missing a newline at end of file. nx-x11: You'll have to add "!net-misc/nx-x11-bin" to the deps if you include my nx-x11-bin ebuild. Why do you "dodir /var/lib/nxserver"? On Gentoo FreeNX doesn't even use it (it uses /usr/NX/var instead). nxserver-freenx Why do you sed the patch? Imho you should update it instead. If that mean you'll have diferent versions of the patch for different versions of freenx so be it. That is the normal procedure for other packages in portage.
@ Jon S.: Thanks for your ebuilds. :) I will add these to portage tomorrow when I get home from work. I also need to look over your suggestions. Also, there is a major bug with xorg 7 that prevents it from working at all, so I need to write up a patch for that. This is not an easy fix, so it will take a bit. I know the solution, but there are a lot of files to parse through. I can't use a simple sed command on this. :P I hope to finish it tomorrow. After this, all bugs should be closed and the ebuild are then xorg 7 safe. :D Completely. :D *dances* Cheers.
Overlay updated again. I added in the nx-x11-bin ebuild and fixed all the freenx ebuilds to use it right. On all the ebuilds I had to change amd64 dependencies to 1.5* since there is no 1.4.x binary available. Also, I included a very important bugfix for xorg 7. So, if you have xorg 7 and freenx would not work for you, then update your overlay, and reinstall nx-x11. The issue was that the fonts directy is hard coded in to a LOT of files. This directory has changed since 6.8, so since the fonts could not be found, the server would fail completely. The solution was to do this in the ebuild: # Fix the font issues with xorg 7 if has_version "x11-base/xorg-server"; then einfo "Applying fix to support xorg 7 font paths." einfo "This might take a while..." for file in $(find -type f); do sed -i 's/\/usr\/X11R6\/lib\/X11\/fonts/\/usr\/share\/fonts/g' ${file} done fi This works, but it is fairly slow. :( So, I may switch over to a patch. I can run this for loop in a bash script, then make a diff of this. I really like the sed command because it is small and dynamic, instead of a patch. The patch is faster though. What is everyone's thoughts on this? There was also a small number of changes to the other ebuilds. There is no need to recompile any of the other ones. Cheers.
(In reply to comment #128) Fonts has actually moved in xorg-6.8 as well, though a symlinc is provided. In adition /usr/share/fonts might exist, with fonts in them, without xorg-x11 being installes (especially in the 7.0, since the fonts packages doesn't pull the metabuild). So imho you should always seed (or patch, I think I prefer patch, but it's no big deal). I suppose this means I must remake the nx-x11-bin tarball...
(In reply to comment #128) One more thing, what is the harm of depending on >=1.4 when 1.5 is the only availible package, if there is no 1.4 for amd64 it will pull 1.5 automatically. Imho having a separate 1.5 dep for amd64 just unnessesarily clutter.
I have now uploaded nx-x11-bin-1.5.0-r1.tar.bz2 (compiled with the fontdir fix) to http://jon.severinsson.net/gentoo/ Also, playing with xorg 7.0 I found that there is no x11-libs/libXFS, which nxcomp depends on, and thus nxcomp wants to pull virtual/x11 instead...
(In reply to comment #129) > (In reply to comment #128) > Fonts has actually moved in xorg-6.8 as well, though a symlinc is provided. > In adition /usr/share/fonts might exist, with fonts in them, without xorg-x11 > being installes (especially in the 7.0, since the fonts packages doesn't pull > the metabuild). So imho you should always seed (or patch, I think I prefer > patch, but it's no big deal). > > I suppose this means I must remake the nx-x11-bin tarball... > Maybe it would be easier if the libXfont ebuild installed the symlink like the 6.8 ebuild does. :D That would fix a lot of issues and no need to patch. :P Thanks for the newnx-x11-bin. :) But, how is that done? Well, if a person has xorg 6.8, they will still have /usr/share/fonts, right? So, then I can eliminate the need for the check and just patch the files but a symlink would be nicer. -_- I will file a feature request when I get home from work. :) Anf I will look at the XFT thing too.
(In reply to comment #132) > Maybe it would be easier if the libXfont ebuild installed the symlink like the > 6.8 ebuild does. :D That would fix a lot of issues and no need to patch. :P In the short term it would be wonderfull with a symlinc. However, in the long term I think it'd be better if packages used the new locations, or even better, a ./configure flag, so upstreaming the fix to !M would be better (if you create a real fix, and not just a workaround). > Thanks for the new nx-x11-bin. :) But, how is that done? Well, if a person has > xorg 6.8, they will still have /usr/share/fonts, right? So, then I can > eliminate the need for the check and just patch the files but a symlink would > be nicer. -_- I will file a feature request when I get home from work. :) Yes, corg 6.8 users still has all their fonts installed in /usr/share/fonts, and /usr/lib/X11/fonts is a symlinc there. I rebuild my nx-x11 package with the sed-ing and it worked great on xorg-x11. In fact the tarball is done on xorg 6.8. It was when I was about to test it in a xorg7 chroot I stumbled on the libXFS problem. > Anf I will look at the XFT thing too. Not libXft, that one exists, but libXFS, which doesn't...
(In reply to comment #133) > > Anf I will look at the XFT thing too. > Not libXft, that one exists, but libXFS, which doesn't... > Yeah. I know that was a typo. Sorry.
Okay. I found the issue. I had a slight typo in the list of dependencies. I called it libXFS instead of libFS. So, the depends are correct now. :) Since it's an or statement, you can't have have "virtual/x11 x11-base/xorg-x11" in /etc/portage/profile/virtuals or you can't have done the trick with renaming the virtual file that is in the portage tree. This will be uploaded later after I look at Jon S.'s new nx-x11-bin file. :) Cheers.
I uploaded the new nxcomp ebuild which fixes the xorg dep issue. I also modified the FreeNX ebuilds slightly. @Jon S.: I could not download the new nx-x11-bin file. :( I got a permission denied error. Also, about the FreeNX deps. I know that if you depend on version 1.4, but it is not there that it will use a higher version. That is not the issue. The issue is that nx-x11 1.5.0 is the only bin available, so all the other files need to be version 1.5 as well, like nxssh, nxcomp, nxproxy, ... so forth. They depend on having nx-x11 be version 1.5. If you don't adjust the version numbers, then FreeNX will try to install 1.4.0 of nxproxy (if it is not unmasked) and that will cause issues. This is to double check to make sure all components are 1.5.0, since 1.5.0 is hard masked. :) I changed the ebuild a bit and I like the way it is now to eliminate that "or" depend and since it's like that, you might as well add the 1.5 version numbers. I hope I made my reasoning a bit more clear. :) Cheers.
Permison problems fixes. And regardng versions: No 1.4 ebuild excist form amd64, so mis-matches can't occur for amd64, even without separate deps. They can occur for x86 though, if you unmask/mask only selected packages. However, mis-matched version does works with freenx! As long as all versions is at leest 1.4, and you set ENABLE_1_5_0_BACKEND="1" if nx-x11 is 1.5, freenx-0.4.x does work. Also note that all nx components are API backwards compatible, and depends on >= their version, wich allows nx-x11 1.4 to use nxcomp 1.5 etc, and it'll still work. Whether this backwards compability will hold going from 1.x to 2.x is however unknown, so for the moment I recommend using >=1.4 (and >=1.3.2 if you still have it in portage) but ~1.5.0 (I'm assuming 1.4 will have left portage before 2.0 enters, otherwise 1.4 deps might have to change if 2.0 isn't backwards compatible) I have (obviously) not tested all possible combinations, but I have tested (on x86) nxcomp 1.5 with the rest 1.4, and all 1.5 but nx-x11 1.4, and it worked flawlessly.
@ Jon S.: Thanks for fixing the permission error. :) I will download that after work and get it in the overlay. The 1.5.0 components hard depend on other 1.5.0 components because of FreeNX 0.5.0. All support for 1.4.0 has been taken out of it, thus only 1.5.0 can be installed. So ... the previous ebuilds need to be forwards compatible. They need to work with either 1.4.0 or greater and since all the 1.5.0 components hard depend on each other, it just makes it easier. :) I can add the or statement back in the FreeNX 0.5.0 ebuilds, but it's just easier this way. It also makes debugging easier too if a user files a bug report. ;) Also, I need to change the 0.4.x ebuilds a bit tonight. I need to add a feature I just thought of. :) Cheers
I updated the FreeNX 0.4.x ebuilds with a new feature: It automatically sets the backend to 1.5.0 in node.conf if it's installed. :) I uploaded the new bin package from Jon S. :) Here is the code to updating the node.conf file. If you know of a better way, or if you see a problem with this code, let me know so I can change it. Thanks. if has_version "=net-misc/nxcomp-1.5*" ; then cat <<EOF > ${D}${NX_ETC_DIR}/node.conf # For more configure options see node.conf.sample ENABLE_1_5_0_BACKEND="1" EOF fi cheers.
(In reply to comment #139) > Here is the code to updating the node.conf file. If you know of a better way, > or if you see a problem with this code, let me know so I can change it. I see two problems with the code. Firstly freenx doesn't care what version of nxcomp you have, it's nx-x11 that matters (and as nx-x11 1.4 can use nxcomp 1.5 your code might detect 1.5 when it shouldn't). Secondly I see a problem when a user upgrades freenx, as you are overwriting his exsisting node.conf. The idea of autodetection is great, but I'd rather sed the sources in src_unpack instead: if has_version "=net-misc/nx-x11-1.5*" || has_version "=net-misc/nx-x11-bin-1.5*" ; then sed '/^ENABLE_1_5_0_BACKEND=/s/"0"/"1"' nxloadconfig sed '/^#ENABLE_1_5_0_BACKEND=/s/"0"/"1"' node.conf.sample fi
(In reply to comment #140) > (In reply to comment #139) > > Here is the code to updating the node.conf file. If you know of a better way, > > or if you see a problem with this code, let me know so I can change it. > I see two problems with the code. Firstly freenx doesn't care what version of > nxcomp you have, it's nx-x11 that matters (and as nx-x11 1.4 can use nxcomp 1.5 > your code might detect 1.5 when it shouldn't). > Secondly I see a problem when a user upgrades freenx, as you are overwriting > his exsisting node.conf. > The idea of autodetection is great, but I'd rather sed the sources in > src_unpack instead: > if has_version "=net-misc/nx-x11-1.5*" || has_version > "=net-misc/nx-x11-bin-1.5*" ; then > sed '/^ENABLE_1_5_0_BACKEND=/s/"0"/"1"' nxloadconfig > sed '/^#ENABLE_1_5_0_BACKEND=/s/"0"/"1"' node.conf.sample > fi You are right about it overwriting an existing file. That will be taken care of. :) I have been busy lately so I will get to it asap. :D And to further comment on what you said about a mixed install. It is not possible to do that. As I have explained. The NX 1.5 components depend on versions 1.5 andnot anything lower. This is due to the fact that FreeNX 0.5.0. This version of FreeNX has no support for 1.4 or lower, so all the ebuilds, in order to satisfy the needs of FreeNX, strictly depend on 1.5 components. So it is IMPOSIBLE for there to be a mixed 1.4/1.5 install currently. ;) So, having the check look for nxcomp is valid, since all 1.5 components depend on that. Also, there is another thing I have been thinking on. Gentoo has a lot of experienced and inexperienced users. Most of them will either go for a all 1.4 or a all 1.5 install and not mix and match anyways. Also, this is not a question of whether you can mix and match, but whether you should mix and match versions. In portage with all those users, I think it's best if you don't mix and match. It's for the greater good. Yeah, sure, you can mix and match, but what is the benefit of that? There is none. If someone wants to unmask one nx 1.5 ebuild, then they will most likely unmask all of them. The needs of FreeNX 0.5.0 will be satisfied and if a user chooses FreeNX 0.4.x, then it will be an all 1.5 install if they choose it, but 0.4.x really does play nicer with 1.5. I always thought that 1.5 support was a bit hackish, but that's me. Cheers.
(In reply to comment #141) > And to further comment on what you said about a mixed install. It is not > possible to do that. As I have explained. The NX 1.5 components depend on > versions 1.5 andnot anything lower. Yes, but 1.4 depends on >=1.4, so you can install nxcomp-1.5 + nx-x11-1.4, as nx-x11-1.4 depends on >=nxcomp-1.4, and thus is sattisfied with 1.5. I'm fully not aware that the oppisite isn't possible. > This is due to the fact that FreeNX 0.5.0. This version of FreeNX has no > support for 1.4 or lower, so all the ebuilds, in order to satisfy the needs > of FreeNX, strictly depend on 1.5 components. So it is IMPOSIBLE for there > to be a mixed 1.4/1.5 install currently. ;) You can't have nx-x11-1.5 with nxcomp-1.4, but nxcomp-1.5 with nx-x11-1.4 is fully possible, as nxcomp doesn't depend on nx-x11 at all. > So, having the check look for nxcomp is valid, since all 1.5 components depend > on that. You won't get false negative, but you will get false positives, as nx-x11-1.4 can build against nxcomp-1.5. > Also, there is another thing I have been thinking on. Gentoo has a lot of > experienced and inexperienced users. Most of them will either go for a all 1.4 > or a all 1.5 install and not mix and match anyways. Also, this is not a > question of whether you can mix and match, but whether you should mix and > match versions. In portage with all those users, I think it's best if you > don't mix and match. It's for the greater good. Yeah, sure, you can mix and > match, but what is the benefit of that? There is none. If someone wants to > unmask one nx 1.5 ebuild, then they will most likely unmask all of them. The > needs of FreeNX 0.5.0 will be satisfied and if a user chooses FreeNX 0.4.x, > then it will be an all 1.5 install if they choose it, but 0.4.x really does > play nicer with 1.5. I always thought that 1.5 support was a bit hackish, but > that's me. Yes, most likely a user will have a pure 1.4 or a pure 1.5 system, but imho emerge shouldn't be able to produce a broken system, that is kind of the main advantage of portage vs. compiling from source manualy. And btw, freenx-0.4.4 works better with 1.5 than with 1.4, so forcing a pure 1.4 install is imho not an option.
(In reply to comment #142) > Yes, most likely a user will have a pure 1.4 or a pure 1.5 system, but imho > emerge shouldn't be able to produce a broken system, that is kind of the main > advantage of portage vs. compiling from source manualy. > And btw, freenx-0.4.4 works better with 1.5 than with 1.4, so forcing a pure > 1.4 install is imho not an option. It's not a broken system if all of 1.5 or all of 1.4 is installed. :S And with 0.4.x, you can install 1.5 components and have it work. So, what is the issue here? So what if the 1.5 ebuilds only depend on 1.5? There is no major issue with that. It makes FreeNX 0.5.0 happy by doing that. With FreeNX 0.5.0, there can be NO 1.4 components installed. So, there is no issue here. It really doesn't matter if all 1.5 components get installed. And how is that a broken system? It's not a broken system. A user can use 1.4 or 1.5 with FreeNX 0.4.x and use 1.5 with freeNX 0.5.0. It all works. Since FreeNX 0.5.0 MUST have NX 1.5, the ebuilds NEED to reflect that. The depends in FreeNX 0.5.0 are correct, and so to pull in the other 1.5 components, the depends in those ebuilds are correct. It is not broken to force all 1.5 components to be installed. In fact, that is a less broken system than mixing 1.4 and 1.5 components. So, what is the big deal? Cheers.
The deal is that if someone unmasks nxcomp-1.5 but forgets to unmask nx-x11-1.5 he'll get a broken system with your ebuild, and it would be so simple to fix, by just changeing the if statement to mine.
(In reply to comment #144) > The deal is that if someone unmasks nxcomp-1.5 but forgets to unmask nx-x11-1.5 > he'll get a broken system with your ebuild, and it would be so simple to fix, > by just changeing the if statement to mine. > Yeah. I already have new plans for that if statement. :P Don't worry. It will be taken care of. :) I really did forget to add in a lot of checks to it and you reminded me of some, but there are some that are not in your checks as well, so I need to sit through it and think about it a lot. ;) I am trying to make it VERY robust. :D Okay. The depends on the 1.4 series need to be fixed as well. I will also fix those ebuilds as well. :) Well, they need to be changed a bit anyways. They really should match some of the changes I made to the 1.5 series. I think. Thanks for pointing that out. I finally get what you were trying to say. :D I completely overlooked nxcomp having no depends. -_-' This will all be fixed up. :D Cheers.
May I ask when the Portage tree will finally be synced with the overlay? I understand the overlay is not perfect (works for me, though), but the 0.4 and 0.5 in the tree are essentially not usable. The userbase is left hanging.
Okay, I think I finally got it. Please check the new overlay. Changes: I added config protect info to the 50nxpaths file, and LDFLAGS in that file is valid, btw. ;) I fixed some deped stuff. I added the blocker to previous versions because, all other versions in Portage install nxcomp and nxesd stuff, so that will be deleted during an update, so the previous versions MUST be uninstalled first. Changed the install of node.conf. Since config_protect is in effect, I can do it the way I have it, and if the file is not there, it will be put there, and if it is, it won't be overwritten. :) Well, those are the major changes. :) Let me know if I messed anything up or I need to change something.
Created an attachment (id=82793) [details] nx-overlay-howto.txt This is a howto on how to use the overlay. PS. NX backend 1.4 may be removed from portage. ;) The checks I have now are in place for users that don't update to the 1.5 backend. ;) @John S.: All I did was remove nxcomp from the nx-x11 build, so you do not need to redo the nx-x11-bin file. :) The files have been changed to point to the installed nxcomp and the build has been removed from the makefiles. That's it. And I also changed the sed line to a patch. I figured this was faster. That for loop and sed line take a really long time to do and I have a p4, so any slower machines will really feel the affect of that.
Hmm. No one has replied yet. :D So, I guess the ebuilds are fine? I am looking for any tweaks, errors, minor changes, fixes, ... so forth. Now that I have the main hacking done (namely taking nxcomp completely out of nx-x11 building) I have time to address anything else that may need looking after or should be changed. A lot was done the way it was just to get it out there and tested, and tweaked later. I may have forgotten something, so let me know. ^^ Cheers.
OK, here's a list with some minor issues I have with your latest installment. Headers: Most ebuilds have erroneus copyright notice. Its 2006 now, not 2005. sed deps: There should be a dep on sed in nxserver-freenx as well as compiletime deps on sed in nxproxy and nxssh. nxcomp: virtual/libc media-libs/jpeg media-libs/libpng and sys-libs/zlib should be listed in RDEPEND rather than DEPEND. nxcomp: I still don't like setting LDPATH in nxcomp, as it's only nessesary for !M nxserver, and can break stuff. nxesd: No newline at end of file. nx-x11: nx-x11-1.5.0-xorg7-font-fix.patch should always be applied, not only when the xorg meta ebuild is installed. nxserver-freenx: Your modifications of node.conf will add another line to the file every time freenx is upgraded. As later assignments override previous it'll work, but it's not a very elegant solution. I'd play with sed instead. Imho you should also move it to src_unpack(), alongside all other patching and seding. Before integrating into portage you should also consider the ~ppc keyword. As neither you nor me have tested it on a ppc machine you should perhaps remove the ~ppc keyword and file a bug to the ppc AT to add ~ppc to nxcomp, nxproxy, nx-x11 and nxserver-freenx-0.4.4 as soon as you remove them from package.mask. Speaking of package.mask, imho you should remove nx*-1.5 from there, but instead add >=nxserver-freenx-0.4.5, until they are released upstream.
(In reply to comment #150) > Headers: Most ebuilds have erroneus copyright notice. Its 2006 now, not 2005. > sed deps: There should be a dep on sed in nxserver-freenx as well as > compiletime deps on sed in nxproxy and nxssh. > nxcomp: virtual/libc media-libs/jpeg media-libs/libpng and sys-libs/zlib should > be listed in RDEPEND rather than DEPEND. Yeah. I will look at these after work. And I thought I fixed all the header stuff. -_-. I guess I missed a few. <_< Thanks. ^^ > nxcomp: I still don't like setting LDPATH in nxcomp, as it's only nessesary for > !M nxserver, and can break stuff. The nxcomp in portage has this, and nxcomp is needed by !M stuff, which will be done next week. :) So, it kinda needs to be there. ;) And there has not been a single breakage yet. :) I will talk to Stuart about it and see if there is another way. ;) > nxesd: No newline at end of file. > nx-x11: nx-x11-1.5.0-xorg7-font-fix.patch should always be applied, not only > when the xorg meta ebuild is installed. Hmm. But, what if a person has another server installed, like kdrive? Can this be used with those? I did this only because I knew xorg 7 messed up the paths. Staurt needs to contact !M anyways, so I will tell him about the font fixing patch and we can see if we can get it included upstream. :) > nxserver-freenx: Your modifications of node.conf will add another line to the > file every time freenx is upgraded. As later assignments override previous > it'll work, but it's not a very elegant solution. I'd play with sed instead. > Imho you should also move it to src_unpack(), alongside all other patching and > seding. It will add another line? :S Whoa. Okay. I will check this out. Thanks for pointing that out. :) > Before integrating into portage you should also consider the ~ppc keyword. As > neither you nor me have tested it on a ppc machine you should perhaps remove > the ~ppc keyword and file a bug to the ppc AT to add ~ppc to nxcomp, nxproxy, > nx-x11 and nxserver-freenx-0.4.4 as soon as you remove them from package.mask. > Speaking of package.mask, imho you should remove nx*-1.5 from there, but > instead add >=nxserver-freenx-0.4.5, until they are released upstream. Well, 1.5 will be unmasked, and 1.4 may disappear completely. *whistles* Yeah. FreeNX 0.4.4 is the latest stable, so it will be stable and 0.4.5 and 0.5.0 will be masked since they are not even released yet, officially. :) 0.4.5 is there only because it is the last version to support 01.4 of the backend in case someone doesn't want to upgrade. There are nurmerous amounts of bugfixes tehre, so one might want to consider running that if they want to use 1.4 still. :) Also, the 1.4 ebuilds will be modified as well and put into the overlay. They may not be in the tree anymore, but we will have them in case there is a demand for them for various reasons, and they will be modifed like the 1.5 ones are, so they will be completely compatible with the 1.5 ebuilds finally. :) Thanks. Cheers.
(In reply to comment #151) > (In reply to comment #150) >> nxcomp: I still don't like setting LDPATH in nxcomp, as it's only nessesary >> for !M nxserver, and can break stuff. > The nxcomp in portage has this, and nxcomp is needed by !M stuff, which will > be done next week. :) So, it kinda needs to be there. ;) And there has not > been a single breakage yet. :) I will talk to Stuart about it and see if > there is another way. ;) There has been breakages, a two second search found #44028 and duplicates, and I know the freenx mailing list have had similar reports. As xorg-x11-6.8 and libX11-1.0 now adds a redundant /usr/lib to LDPATH as a workaround it doesn't crash atm, but it's still a risk factor that can be eliminated. A simple improvement is to let !M nxserver install a separate /etc/env.d/50nxserver file with only LDPATH, and remove it from nxcomp. That way only users who actually *need* LDPATH set has it set, and breakage risk is reduced for everyone else. >> nx-x11: nx-x11-1.5.0-xorg7-font-fix.patch should always be applied, not only >> when the xorg meta ebuild is installed. > Hmm. But, what if a person has another server installed, like kdrive? Can this > be used with those? I did this only because I knew xorg 7 messed up the paths. > Staurt needs to contact !M anyways, so I will tell him about the font fixing > patch and we can see if we can get it included upstream. :) I havn't tested, so I don't know for sure, but considering all ebuilds installing fonts install them to /usr/share/fonts we should use the fonts from that directory. Also note that nxserver can be installed on a computer without any X server, as the *X server* runs on the *NX client*. The NX libraries must work with the same font paths as the X *libraries*, and as far as I know those are the same independent of which X server you run, if you run any at all. >> Before integrating into portage you should also consider the ~ppc keyword. As >> neither you nor me have tested it on a ppc machine you should perhaps remove >> the ~ppc keyword and file a bug to the ppc AT to add ~ppc to nxcomp, nxproxy, >> nx-x11 and nxserver-freenx-0.4.4 as soon as you remove them from >> package.mask. >> Speaking of package.mask, imho you should remove nx*-1.5 from there, but >> instead add >=nxserver-freenx-0.4.5, until they are released upstream. > Well, 1.5 will be unmasked, and 1.4 may disappear completely. *whistles* Yeah. > FreeNX 0.4.4 is the latest stable, so it will be stable and 0.4.5 and 0.5.0 > will be masked since they are not even released yet, officially. :) 0.4.5 is > there only because it is the last version to support 1.4 of the backend in > case someone doesn't want to upgrade. There are nurmerous amounts of bugfixes > tehre, so one might want to consider running that if they want to use 1.4 > still. :) Great. Just don't remove the 1.4 ebuilds until the 1.5 ebuilds are marked stable on all platforms (x86, amd64 and ppc). I think they need to co-excist for some time (at least a few weeks, giving time for ppc AT to mark ~ppc, and for all AT to move ~arch -> arch), so if you have any worries about 1.4 co-excisting with 1.5 you should resolve it in the overlay prior to portage integration.
Howdy. I installed nxserver-freenx-0.4.0 on server side and nxclient-1.5.0-r2 on client side. With 1.4, on the client side i could be in a window, click the X to try to close it, wait a few seconds and a dialog would appear asking if I wanted to terminate or suspend. Now I don't get that, am I missing something? Keep up the nice work :)
(In reply to comment #153) > Howdy. I installed nxserver-freenx-0.4.0 on server side and nxclient-1.5.0-r2 > on client side. > > With 1.4, on the client side i could be in a window, click the X to try to > close it, wait a few seconds and a dialog would appear asking if I wanted to > terminate or suspend. Now I don't get that, am I missing something? That dialog is created on server side, and displayed on the client over the NX protocoll. FreeNX-0.4.0 contains a bug resulting in nxclient 1.5 not displaying it. It is solved in FreeNX-0.4.2, so I recommend you use the overlay and install nxserver-freenx-0.4.4 on the server. You can continue to use a 1.4 backend on the server and still use a 1.5 client if you wich to, as long as the server is at least 0.4.2.
make[3]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xau' depending in lib/Xdmcp... make[3]: Entering directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xdmcp' ../../config/makedepend/makedepend -- -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DUSE_MAKEDEPEND -- A8Eq.c AA8.c AA16.c AA32.c AofA8.c CA8.c DA8.c DA16.c DA32.c DAofA8.c Fill.c Flush.c RA8.c RA16.c RA32.c RAofA8.c RC8.c RC16.c RC32.c RHead.c RR.c RaA8.c RaA16.c RaA32.c RaAoA8.c WA8.c WA16.c WA32.c WAofA8.c WC8.c WC16.c WC32.c Whead.c Alloc.c CmpKey.c DecKey.c GenKey.c IncKey.c make[3]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xdmcp' depending in lib/X11... make[3]: Entering directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/X11' make[3]: *** No rule to make target `/usr/NX/lib/libXcomp.so', needed by `depend'. Stop. make[3]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/X11' make[2]: *** [depend] Error 2 make[2]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib' make[1]: *** [depend] Error 2 make[1]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11' make: *** [World] Error 2 !!! ERROR: net-misc/nx-x11-1.5.0-r8 failed. emerge --info Portage 2.1_pre6-r5 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, 2.6.15.6 i686) ================================================================= System uname: 2.6.15.6 i686 Transmeta(tm) Crusoe(tm) Processor TM5800 Gentoo Base System version 1.12.0_pre16 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -ffast-math -march=i686" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -ffast-math -march=i686" DISTDIR="/usr/distfiles" FEATURES="autoconfig distcc distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://shapeshifter/gentoo-portage" USE="x86 X aim alsa ao apache2 asf audiofile avi bash-completion bitmap-fonts bittorrent bzip2 cairo cardbus cdda cddb cdparanoia cdrom cgi cli clock-screen css cups dbus dhcp dri dvd dvdr encode escreen exif fam fat ffmpeg firefox flac fontconfig ftp gcj gd gdb gdbm gif gimp glibc-omitfp gmail gpm gs gstreamer gstreamer010 hal http icecast icq ieee1394 input_devices_evdev input_devices_joystick input_devices_keyboard input_devices_mouse irc irssi jabber java java-external javascript jikes joystick jp2 jpeg jpeg2k kde lame libwww linuxthreads-tls lm_sensors logrotate lzo lzw mad mikmod mmap mmx mng moznoxft mozsvg mp3 mp4live mpeg mpeg2 mplayer mpm-prefork msn musepack ncurses net network nfs nntp nodrm nptl nptlonly ntfs ogg oggvorbis opengl openssh openssl oscar pam pcmcia pcre pdf pdflib perl php png python qt quicktime rar readline real reiser4 reiserfs rtc scp screen sdl search-screen session sharedmem shout sid sndfile speex spell ssl subversion svg svgz sysfs szip t1lib tcpd tga theora tiff timidity truetype truetype-fonts type1 type1-fonts udev unicode usb utf8 vfat video_cards_ati vidix vorbis win32codecs wma wma123 wordperfect xfs xft xine xv xvid yahoo zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #155) > make[3]: Leaving directory > `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xau' > depending in lib/Xdmcp... > make[3]: Entering directory > `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xdmcp' > ../../config/makedepend/makedepend -- -I../.. -I../../exports/include > -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L > -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE > -D_SVID_SOURCE -D_GNU_SOURCE > -DFUNCPROTO=15 -DNARROWPROTO -DUSE_MAKEDEPEND -- A8Eq.c AA8.c AA16.c > AA32.c AofA8.c CA8.c DA8.c DA16.c DA32.c DAofA8.c Fill.c > Flush.c RA8.c RA16.c RA32.c RAofA8.c RC8.c RC16.c RC32.c > RHead.c RR.c RaA8.c RaA16.c RaA32.c RaAoA8.c > WA8.c WA16.c WA32.c WAofA8.c WC8.c WC16.c WC32.c Whead.c > Alloc.c CmpKey.c DecKey.c GenKey.c IncKey.c > make[3]: Leaving directory > `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/Xdmcp' > depending in lib/X11... > make[3]: Entering directory > `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/X11' > make[3]: *** No rule to make target `/usr/NX/lib/libXcomp.so', needed by > `depend'. Stop. > make[3]: Leaving directory > `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib/X11' > make[2]: *** [depend] Error 2 > make[2]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11/lib' > make[1]: *** [depend] Error 2 > make[1]: Leaving directory `/var/tmp/portage/nx-x11-1.5.0-r8/work/nx-X11' > make: *** [World] Error 2 > > !!! ERROR: net-misc/nx-x11-1.5.0-r8 failed. I just did a fresh install of all the NX components. I removed my directories and all. It compiled fine. So, when you emerged this, did you do an upgrade from a previous version? Did you remove the line !<net-misc/nx-x11-1.5.0-r8? Did you do a fresh install? What was the previous version if you did an update? Thanks.
(In reply to comment #150) > sed deps: There should be a dep on sed in nxserver-freenx as well as > compiletime deps on sed in nxproxy and nxssh. I did a random sampling of ebuilds in portage. I opened a fair few ebuilds that sedded and all but one did not have a depend, so if I follow suite ... You really don't need that depend. Sed is installed as a base item. Many ebuilds require it so unless a user uninstalls it, then the ebuilds will work, but if a user did that, then more than just these NX ebuilds will cease to function. Thus, the user will reinstall sed and all ebuilds with sed will work again, including the NX ones. ;) Most of this has been fixed in my local overlay and will be uploaded tonight or tomorrow. :) Oh, and the commercial use flag is being renamed to nxclient to be more descriptive. ^^
New ebuilds uploaded. :) The minor cosmetic changes have been fixed. Also, I think I fixed the issues with node.conf auto installing. Well, I hope I did. If not, let me. :)
Created an attachment (id=83075) [details] Proposal on how to handle node.conf (In reply to comment #157) > (In reply to comment #150) >> sed deps: There should be a dep on sed in nxserver-freenx as well as >> compiletime deps on sed in nxproxy and nxssh. > I did a random sampling of ebuilds in portage. I opened a fair few ebuilds > that sedded and all but one did not have a depend, so if I follow suite ... > You really don't need that depend. Sed is installed as a base item. Many > ebuilds require it so unless a user uninstalls it, then the ebuilds will work, > but if a user did that, then more than just these NX ebuilds will cease to > function. > Thus, the user will reinstall sed and all ebuilds with sed will work again, > including the NX ones. ;) OK, you are the boss. However, imho this only means that all those ebuilds are broken, not that the NX ebuilds are correct. Also note that freenx requires sed runtime as well as during emerge, if this makes any difference to you. (In reply to comment #157) > Oh, and the commercial use flag is being renamed to nxclient to be more > descriptive. Nice move, but you should perhaps change it in the rest of the ebuild as well... (In reply to comment #158) > Also, I think I fixed the issues with node.conf auto installing. Well, I hope > I did. If not, let me. :) OK, correct me if I'm wrong, but now the ebuild will try to overwrite node.conf with a minimal file only containing the ENABLE_1_5_0_BACKEND directive, but will fail due to CONFIG_PROTECT, and the user will be told to use etc-update, which will let the user choose between keeping his old settings or use the new minimal settings. Wouldn't it be nicer if the new node.conf would be the original ebuild with only that variable changed? That way the user can easily keep his modifications, while still getting the correct backend. I have attached a diff for an example on how this could be done. I have intentionally written it genericly, so one can do more changes to node.conf. As a usefull example I have added esd, arts and cups use flags triggering relevant changes in nxloadconfig, node.conf.sample and node.conf
(In reply to comment #159) > OK, you are the boss. However, imho this only means that all those ebuilds are > broken, not that the NX ebuilds are correct. Also note that freenx requires sed > runtime as well as during emerge, if this makes any difference to you. I do understand what you are saying, but I am going by what other's have done. If you feel that the ebuilds are broken, you can open a generic bug saying that all ebuilds that have sed in them, must have a compile time dependency on sed. This will spark a debate and you can talk about this with others that are more knowledgable about things than I am. :) You don't need to do this, but if things are broken, then you should open a bug report about that. I don't know which category it would fall under since it applies to a _lot_ of ebuilds. One can write a scripte that searches all ebuilds for use of sed with no sed depend and have it generate a list. From the small search I did, I can tell that the list is quite long ... > (In reply to comment #157) > > Oh, and the commercial use flag is being renamed to nxclient to be more > > descriptive. > Nice move, but you should perhaps change it in the rest of the ebuild as > well... The rest of teh ebuilds? The FreeNX ebuilds are the only ones with the commercial flag, or do you mean the !M Server ebuilds? > (In reply to comment #158) > OK, correct me if I'm wrong, but now the ebuild will try to overwrite node.conf > with a minimal file only containing the ENABLE_1_5_0_BACKEND directive, but > will fail due to CONFIG_PROTECT, and the user will be told to use etc-update, > which will let the user choose between keeping his old settings or use the new > minimal settings. > Wouldn't it be nicer if the new node.conf would be the original ebuild with > only that variable changed? That way the user can easily keep his > modifications, while still getting the correct backend. > I have attached a diff for an example on how this could be done. I have > intentionally written it genericly, so one can do more changes to node.conf. As > a usefull example I have added esd, arts and cups use flags triggering relevant > changes in nxloadconfig, node.conf.sample and node.conf > Okay. You are right about this. I will look at your patch. :) Thanks!!! I will try t get this updated today.
(In reply to comment #160) > > (In reply to comment #157) > > > Oh, and the commercial use flag is being renamed to nxclient to be more > > > descriptive. > > Nice move, but you should perhaps change it in the rest of the ebuild as > > well... > > The rest of teh ebuilds? The FreeNX ebuilds are the only ones with the > commercial flag, or do you mean the !M Server ebuilds? *bangs head to desk* Yes. I found the error to this. *sigh* that was a stupid mistake.
(In reply to comment #150) > nxcomp: I still don't like setting LDPATH in nxcomp, as it's only nessesary for > !M nxserver, and can break stuff. removing LDPATH from nxcomp breaks revdep-rebuild (see also bug#126461) and prelink. IMHO if you remove LDLIB you should add something like this to env.d: PRELINK_PATH_MASK=/usr/NX SEARCH_DIRS_MASK=/usr/NX
(In reply to comment #162) > removing LDPATH from nxcomp breaks revdep-rebuild (see also bug #126461) and > prelink. Yes, removing LDPATH breaks revdep-rebuild, but I'd rather have a broken revdep-rebuild than a broken system. However, I can't agree that it breaks prelink, as prelink is broken whether LDPATH is set or not (as prelink will use the wrong libX11.so, libXext.so and libXrender.so in any case). > IMHO if you remove LDLIB you should add something like this to env.d: > PRELINK_PATH_MASK=/usr/NX > SEARCH_DIRS_MASK=/usr/NX Seems like a good workaround until upstream fixes all the library linking issues (which they say they don't intend to do at all, as they don't think it's a problem unless you do something stupid, such as using Gentoo).
Hi, Sorry I haven't been around much. I have been very busy as of late. I want to give you an overview on what I have been thinking seriously on. First, thanks to Bruno Redondi for that information. I added those lines to the local overlay on my computer and they work great. :D Second, I have beent hinking hard on that node.conf issue. I thought about changing this line: [ -f "/usr/NX/etc/node.conf" ] && cp /usr/NX/etc/node.conf to include an if statement, so if that file did not exist, cp the node.conf.sample to node.conf. This would eliminate the need for all the checks to see if the file is there. But, then I started to think on this really hard. What if the user has removed the needed lines from the conf file? The sed statements would find nothing and just return. So, Then I started to think that some checks would need to be done. Check to see if the option in in the file, if it is, change it so it's enabled, if not, add it to the file. You would not need to do those checks to disable, because the default is disabled so if it's not in the file, it's disabled. This would be a lot of code for all this. -_-' Not that I don't mind. It's just I was wondering if there is a nice way to do all the checks and everything needed to make this error proof. Also, in the nxloadconfig file. it said not to change anything but to do so in node.conf, so I dropped those lines. This is what I have so far: # Copy the the node.conf sample file so etc-update can show users the difference. cp node.conf.sample node.conf if has_version "~net-misc/nx-x11-1.5.0" || has_version "~net-misc/nx-x11-bin-1.5.0" ; then einfo "Enabling the NX 1.5.0 backend support." sed '/s/#ENABLE_1_5_0_BACKEND="0"/ENABLE_1_5_0_BACKEND="1"' node.conf fi if use arts ; then einfo "Enabling arts support." sed -i '/s/#ENABLE_ARTSD_PRELOAD="0"/ENABLE_ARTSD_PRELOAD="1"/' node.conf fi if use esd ; then einfo "Enabling esd support." sed -i '/s/#ENABLE_ESD_PRELOAD="0"/ENABLE_ESD_PRELOAD="1"/' node.conf fi if use cups ; then einfo "Enabling cups support." sed -i '/s/#ENABLE_KDE_CUPS="0"/ENABLE_KDE_CUPS="1"/' node.conf fi Questions? Comments? Is this the right way? I think this is how most devs do it. They cp the sample and modify it for you like this. Mainly because a normal user would not change this file and a power user that did would know how to do diffing when it came time to do an etc-update. :) So, any changes to the file would be perserved. What do you think? I hope to have this up this weekend. ;) Cheers.
Okay, this is odd. I am getting reports from people on the forum that say that they need to add the LDPATH line to 50nxpaths to make it work. -_-'So, now I have no clue what to do. Some people need it, and other's don't, and for others it messes up their system. *sigh* What to do what to do? This is a strange situation. Though, the system should work perfectly fine with the line in 50nxpaths, and if it doesn't then maybe something else is wrong with the system? So may possibilities. *dies*
(In reply to comment #164) > First, thanks to Bruno Redondi for that information. I added those lines to > the local overlay on my computer and they work great. :D I've done the same on mine, and it works great. I've also made 05nxpaths a separeate file in the files directory, instead of cat-ing it from the ebuild. Perhaps something for the ovelray as well. > Second, I have beent hinking hard on that node.conf issue. > I thought about changing this line: > [ -f "/usr/NX/etc/node.conf" ] && cp /usr/NX/etc/node.conf > to include an if statement, so if that file did not exist, cp the > node.conf.sample to node.conf. This would eliminate the need for all the > checks to see if the file is there. Yes it would. I thought of that as well, but found it unnessesary, though not nessesarily bad (if nothing else it would remove all those bogous error reports "I don't have a node.conf!") > But, then I started to think on this really hard. > What if the user has removed the needed lines from the conf file? The sed > statements would find nothing and just return. So, Then I started to think > that some checks would need to be done. Check to see if the option in in the > file, if it is, change it so it's enabled, if not, add it to the file. You > would not need to do those checks to disable, because the default is disabled > so if it's not in the file, it's disabled. This would be a lot of code for all > this. -_-' Well, if you patch nxloadconfig it won't matter, if the line is missing or commented out it will use the default, which we also changes. > Not that I don't mind. It's just I was wondering if there is a nice way to do > all the checks and everything needed to make this error proof. If we do patch nxloadconfig (which we imho should do, as it would be to easy for the user to break something otherwise) all checks that is needed is in my ebuild. > Also, in the nxloadconfig file. it said not to change anything but to do so in > node.conf, so I dropped those lines. It explicitly says that *users* should never change that, but we are packagers. Packagers are supposed to change the default values there, but let users override them in node.conf if they wish. So if there is any file we shouldn't touch it's node.conf, but as we have it protected by etc-update and don't just overwrite it for the user, I still think it's fair to the user to do so, especially since it prevents breakages. > This is what I have so far: > [...] > Questions? Comments? Is this the right way? I think this is how most devs do > it. They cp the sample and modify it for you like this. Mainly because a > normal user would not change this file and a power user that did would know > how to do diffing when it came time to do an etc-update. :) So, any changes to > the file would be perserved. What do you think? Some does, however other just changes/adds new values, and maintains a *.sample or *.default which is the file included in the new version. Imho both wasys are valid, and we can do either one. But we should keep to one of them, so if we copy node.conf.sample to node.conf we shouldn't install node.conf.sample. Personally I'd prefer my way, but it's no big deal. (In reply to comment #165) > Okay, this is odd. I am getting reports from people on the forum that say that > they need to add the LDPATH line to 50nxpaths to make it work. -_-'So, now I > have no clue what to do. Some people need it, and other's don't, and for > others it messes up their system. *sigh* What to do what to do? This is a > strange situation. Though, the system should work perfectly fine with the line > in 50nxpaths, and if it doesn't then maybe something else is wrong with the > system? So may possibilities. *dies* OK, here we go (again). I read the forum thread in question, and it looks like he manually tried to run nxagent from the command line (instead of from within freenx). That won't work! I'll take this from the beginnning, so stay with me. As you know nx-x11 installs two unique libraries in /usr/NX/X11 (libXcomp.so and libXcompext.so) as well as three modified X11 libraries (libX11.so, libXext.so and libXrender.so). The two NX libraries are no problems, they could be added to the global LD_LIBRARY_PATH without any problem. The problem is the modified X11 libraries. The binaries from nx-x11 (nxagent, nxath, nxviewer and nxdesktop) *must* be linked to these modified X11 libraries to work (if linked to the original X11 libraries they will run, but all compressed data it sends over the network will be garbage). However, if you link a standard X11 applicatrion to the modified X11 libraries, the application will break! So, applications don't need the NX libraries, and must be linked to the original X11 libraries. The easiest way to acomplish this is to never add /usr/NX/lib to LD_LIBRARY_PATH, but you can add them IFF you make sure the directory with the original X11 libriaries is listed priorly. Adding LDPATH to 50nxpaths will do this IFF /usr/lib is set in a previous file (currently in 10xorg) AND env-update adds the stuff to LD_LIBRARY_PATH in lexographically order. Both these requirements have been broken priorly, and might easily break again as, to my knowledge, only nx relies on either of these features. However, independent on whether LDPATH is set or not we still have to make sure that nxagent etc gets liked to the modified X11 libraries. This is handled by nxserver (both freenx and !M) setting LD_PRELOAD to /usr/NX/lib/libX11.so:/usr/NX/lib/libXext.so:/usr/NX/lib/libXrender.so:$LD_PRELOAD when running nxagent etc but not when running the applications in the NX session. The difference between freenx and !M nxserver is that freenx also sets LD_LIBRARY_PATH to /usr/NX/lib/:$LD_LIBRARY_PATH when running nxagent etc (but not when running applications), while !M nxserver don't. That is why freenx doesn't need LDPATH at all but !M nxserver needs it set, but after /usr/lib. Adding LDPATH to 50nxpaths may make nxagent look as if it was working when run from the command line, but it won't, you'll still have to prepend /usr/NX/lib to the beginning of LD_LIBRARY_PATH and/or prepend the modified X11 libraries to LD_PRELOAD (while making sure neither of these changes is affecting any applications you run). Hope this clarified the issue for you. PS. Neither freenx nor !M nxserver is ofcourse using hard coded paths, but is using PATH_LIB which is set in nxloadconfig and can be overwriten in node.conf. In fact the LD_PRELOAD is set from APPLICATION_LIBRARY_PRELOAD, which is set from APPLICATION_LIBRARY_PATH which defaults to PATH_LIB. So it might be possible to put the NX libraries and modified X11 libraries in different directories, set PATH_LIB to the dir with the NX libraries and APPLICATION_LIBRARY_PATH to the dir with the modified X11 libraries. If so you should be able to add the dir with the NX libraries to LD_LIBRARY_PATH safetly, but imho that is overkill.
I just updated the overlay. I ended up just messing around with the nxloadconfig and the sample file. No need to mess with node.conf. Now there is no messing around with something that users may have modified. :) The final code looks like this: # Change the defaults in nxloadconfig to meet the users needs. if has_version "~net-misc/nx-x11-1.5.0" || has_version "~net-misc/nx-x11-bin-1.5.0" ; then einfo "Enabling the NX 1.5.0 backend support." sed -i '/ENABLE_1_5_0_BACKEND=/s/"0"/"1"/' nxloadconfig sed -i '/ENABLE_1_5_0_BACKEND=/s/"0"/"1"/' node.conf.sample fi if use arts ; then einfo "Enabling arts support." sed -i '/ENABLE_ARTSD_PRELOAD=/s/"0"/"1"/' nxloadconfig sed -i '/ENABLE_ARTSD_PRELOAD=/s/"0"/"1"/' node.conf.sample fi if use esd ; then einfo "Enabling esd support." sed -i '/ENABLE_ESD_PRELOAD=/s/"0"/"1"/' nxloadconfig sed -i '/ENABLE_ESD_PRELOAD=/s/"0"/"1"/' node.conf.sample fi if use cups ; then einfo "Enabling cups support." sed -i '/ENABLE_KDE_CUPS=/s/"0"/"1"/' nxloadconfig sed -i '/ENABLE_KDE_CUPS=/s/"0"/"1"/' node.conf.sample fi Minus the stuff about the 1.5.0 backend for the 0.5.0 version. :) Cheers.
Just updated again. I had an error in the FreeNX ebuilds. ooops.
Created an attachment (id=83701) [details] Patch to fix deps on current 1.4.0 ebuilds Great work Jon! Imho you are almost done for portage integration. Right now I only have 3 very minor issues: 1) nxcomp doesn't need to inherit multilib, as it doen't use any of the helper functions anymore. 2) Imho 50nxpaths should realy be a separate file in the files directory, rather than doing that uggly "cat <<EOF > ${T}/50nxpaths" in the nxcomp ebuild to create it. 3) The freenx-0.5.0 ebuild mixes ~1.5.0 >=1.5.0 and >=1.5*. Imho they should all be ~1.5.0. Other than that I just urge you to consider the ~ppc keyword before doing portage integration. With the risk of repeating myself I'd like to point out that neither of us have tested the ebuilds on a ppc machine. Therefore you should imho remove the ~ppc keyword from all the ebuilds and then file a bug to the ppc AT asking them to add ~ppc to nxcomp, nxproxy, nx-x11 and nxserver-freenx-0.4.4. I've also looked at the ebuilds in portage. Imho you should drop all the nxserver-{enterprise,business,personal}-1.3* and nxserver-freenx-0.2* ebuilds as well as all but the last nxserver-personal-1.4 and nx-x11-1.4 ebuilds. Doing so you can also drop nxserver.eclass and nxserver-1.3.eclass (just keeping nxserver-1.4.eclass). This way you'll only have one stable version of 1.4 to worry about. I have then attached a diff that I think will take care of the deps on the remaining 1.4 ebuilds. The most drastic change is that nxclient and !M nxserver depends on >=1.4.0, and will thus use 1.5.0 when those are marked stable. This is intentionall, and will work as the comandline interface to the helper binaries (nxclient, nxprint, nxproxy, nxssh, nxagent, nxauth, nxviewer and nxdesktop) are backwards compatible. In the end it will alow us to keep !M nxserver 1.4 in portage without having to keep all the other obsoleted 1.4 components, just as we have kept !M nxserver 1.3.2 in portage longer than any other 1.3.2 components. As the patch doesn't touch anything but deps I think it's safe to apply it to the stable ebuilds, but to be sure you should copy them to the overlay and do some testing first.
(In reply to comment #169) > Created an attachment (id=83701) [edit] [details] > Patch to fix deps on current 1.4.0 ebuilds > > Great work Jon! Thanks. :) And thank you for your suggestions. > 1) nxcomp doesn't need to inherit multilib, as it doen't use any of the helper > functions anymore. Done > 2) Imho 50nxpaths should realy be a separate file in the files directory, > rather than doing that uggly "cat <<EOF > ${T}/50nxpaths" in the nxcomp ebuild > to create it. This seems to be the new way of doing things. A lot of ebuilds do this now. *shrug* I guess it cuts down on the number of external files. :P > 3) The freenx-0.5.0 ebuild mixes ~1.5.0 >=1.5.0 and >=1.5*. Imho they should > all be ~1.5.0. Done. :) > Other than that I just urge you to consider the ~ppc keyword before doing > portage integration. With the risk of repeating myself I'd like to point out > that neither of us have tested the ebuilds on a ppc machine. Therefore you > should imho remove the ~ppc keyword from all the ebuilds and then file a bug to > the ppc AT asking them to add ~ppc to nxcomp, nxproxy, nx-x11 and > nxserver-freenx-0.4.4. The ebuilds will be tested on a ppc machine before they are committed. ^^ If they are not tested in the time, there are options: Hard mask them as unstable using the package.mask file, or drop the flag. :) It will be done. Don't worry. Yeah. A lot of older versions will taken out of portage. That's been planned already. ^^ There are a lot of old versions in portage. Especially a lot of old FreeNX, so those are gone for sure. I think only 0.4 and above will be left, though, I am not too sure about 0.4. 0.4.4 should be the lowest version in there. But, even though 0.4.5 hasn't been officially released, and development seems to be completed on it, it could be stable. It is less buggy than 0.4.4 This is something to be decided. Stuart is working on the !M server ebuilds right now. :) So ... really soon this will get put into portage. So, people ... abuse these ebuilds and see if they fail. :P Once the ebnuilds hit portage, open a new bug report. This bug report should no longer be used then. *sniffs* I am going to miss this report. :P *laughs* I am in a good mood today. ^^
Minor update. I added a ewarn line to the FreeNX ebuilds warning them about the flag change. :) That's it. Cheers.
> So, people ... abuse these ebuilds and see if they fail. first, there seems to be missing a line in the nxesd ebuild "inherit libtool" second, why does nxclient-1.4.0 pull in nx-x11 as a dependency while nxclient-1.5.0-r4 doesnt? third, when i try to emerge nxclient, nxesd fails make all-recursive make[1]: Entering directory `/var/tmp/portage/nxesd-1.5.0/work/nxesd' Making all in docs make[2]: Entering directory `/var/tmp/portage/nxesd-1.5.0/work/nxesd/docs' jw -f docbook -b html -o html ./esound.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /var/tmp/portage/nxesd-1.5.0/work/nxesd/docs/./esound.sgml jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:53:65:W: cannot generate system identifier for public text "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:54:8:E: reference to entity "ISOamsa" for which no system identifier could be generated jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:52:0: entity was defined here and after a lot of similiar messages jade:/usr/share/sgml/docbook/dsssl-stylesheets-1.79/html/../common/../common/dbl1sr.dsl:2:66:W: cannot generate system identifier for public text "ISO 8879:1986//ENTITIES Added Latin 2//EN" jade:/usr/share/sgml/docbook/dsssl-stylesheets-1.79/html/../common/../common/dbl1sr.dsl:3:5:E: reference to entity "lat2" for which no system identifier could be generated jade:/usr/share/sgml/docbook/dsssl-stylesheets-1.79/html/../common/../common/dbl1sr.dsl:2:0: entity was defined here make[2]: *** [html/index.html] Error 8 make[2]: Leaving directory `/var/tmp/portage/nxesd-1.5.0/work/nxesd/docs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/nxesd-1.5.0/work/nxesd' make: *** [all] Error 2 !!! ERROR: net-misc/nxesd-1.5.0 failed. Call stack: ebuild.sh, line 1526: Called dyn_compile ebuild.sh, line 923: Called src_compile nxesd-1.5.0.ebuild, line 29: Called die Portage 2.1_pre7-r4 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, 2.6.16-suspend2-r1 i686) ================================================================= System uname: 2.6.16-suspend2-r1 i686 mobile AMD Athlon(tm) XP-M 2000+ Gentoo Base System version 1.12.0_pre16 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openjms/config /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" and the worst: nxclient-1.5.0-r4 doesnt work, where 1.4.0 works just fine. complains about authentication.
(In reply to comment #172) > first, there seems to be missing a line in the nxesd ebuild "inherit libtool" Sorry, my fault. It seemed I removed one inherit to much. Jon: will you fix it? > second, why does nxclient-1.4.0 pull in nx-x11 as a dependency while > nxclient-1.5.0-r4 doesnt? Becouse in nx 1.4 libXcomp is provided by the nx-x11 ebuild, while in 1.5it has been separated to the nxcomp ebuild, with the nx-x11 ebuild depending on it. nxclient doesn't depend on any part of nx-x11 but libXcomp, but in 1.4 you can't get it without geting all of nx-x11. This is originally due to a problem in the upstream buildsystem, which Jon (the other one, not me) has patched for nx 1.5. However, it's to much work to justify re-doing for 1.4, which we are phasing out. > third, when i try to emerge nxclient, nxesd fails > > [...] > > Portage 2.1_pre7-r4 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, > 2.6.16-suspend2-r1 i686) It works just fine for me, but I'm using neither gcc-4.1 nor glibc-2.4. Can you reproduce it with gcc-4.0 or gcc-3.4? > and the worst: nxclient-1.5.0-r4 doesnt work, where 1.4.0 works just fine. > complains about authentication. Without more information I can't say for sure, but were you using a non-standard ssh key? (eg did you run nxsetup --install without --setup-nomachine-key on the freenx server). The system for handling that on clientside has changed since 1.4. In nxclient-1.4 you had to replace the standard server.id_dsa.key, which would have been overwritten by the upgrade. In nxclient-1.5 you use the gui and select a different key file in the configuration dialog. Another posibility is that you are trying to connect to a freenx server prior to 0.4.2, they have a know bug preventing nxclient-1.5 to connect. !M nxserver 1.3.2 and 1.4.0 will accept nxclient-1.5, as will freenx-0.4.2 and later, but freenx-0.4.1 and earlier will not.
(In reply to comment #173) >> third, when i try to emerge nxclient, nxesd fails >> >> [...] >> >> Portage 2.1_pre7-r4 (default-linux/x86/2006.0, gcc-4.1.0, glibc-2.4-r1, >> 2.6.16-suspend2-r1 i686) > It works just fine for me, but I'm using neither gcc-4.1 nor glibc-2.4. Can > you reproduce it with gcc-4.0 or gcc-3.4? I just rebuild nxesd with gcc-4.1.0 (have it installed, but not as default). I've now tested gcc-3.4, 4.0 and 4.1 on amd64, and gcc-3.4 and 4.0 on x86, without failing a single time. No box has glibc-2.4 though, so that might be the problem.
I use glibc 2.4, gcc 4.1, and the latest beta binutils. Then on top of that, I use compiler flags and LDFLAGS that would make other devs cry and close a bug report automatically if they saw them. *whistles* It all compiles fine for me. @Kristian: What xorg version are you using? Are you just using nxclient on the computer that you are compiling nxclient on? The computer you are connecting to, what version of NX does it have? @Jon S.: Yes, I will fix that. :) Cheers.
well it works now. i guess i missed the part with public key encryption. my bad. im using the nx versions from the overlay on both computers. with latest unmasked xorg from portage. so only the esd problem remains.i did try different gcc versions myself, but that didnt help. no crosscompiling. the use flags dont change anything either. whats strange to me, its failing in nxesd/docs. will investigate this further, when i find the time.
(In reply to comment #176) > well it works now. i guess i missed the part with public key encryption. my > bad. im using the nx versions from the overlay on both computers. with latest > unmasked xorg from portage. > so only the esd problem remains.i did try different gcc versions myself, but > that didnt help. no crosscompiling. the use flags dont change anything either. > whats strange to me, its failing in nxesd/docs. will investigate this further, > when i find the time. > Do you have the virtual x11 set? Either in /etc/portage/profile/virtuals or the new virtual ebuild installed? If so, remove them. The or on the dependencied falls true to virtual x11 and does not install everything. So, if you have that and removed it it, type: emerge -auD world to see if anything is listed, if so, install it. Then try to install nxesd. :) Cheers.
(In reply to comment #177) > > whats strange to me, its failing in nxesd/docs. will investigate this further, > > when i find the time. > > > Do you have the virtual x11 set? Either in /etc/portage/profile/virtuals or the > new virtual ebuild installed? If so, remove them. The or on the dependencied > falls true to virtual x11 and does not install everything. So, if you have that > and removed it it, type: emerge -auD world to see if anything is listed, if so, > install it. Then try to install nxesd. :) well, that pulled in xdialog and sessreg as dependencies for nxcomp, but didnt do anything on the issue. i checked the Makefile. jw -f docbook -h html ./esound.sgml is called, and fails with $? = 8. if i call make in in the root dir, after i did remove that line from the Makefile, it will compile cleanly. So merging this ebuild manually might be possible, ignoring the doc.
(In reply to comment #178) > well, that pulled in xdialog and sessreg as dependencies for nxcomp, but didnt > do anything on the issue. i checked the Makefile. > jw -f docbook -h html ./esound.sgml > is called, and fails with $? = 8. if i call make in in the root dir, after i > did remove that line from the Makefile, it will compile cleanly. So merging > this ebuild manually might be possible, ignoring the doc. Sounds like (jet another) problem with the build system. The nxesd ebuild isn't actually interested in installing anything but the nxesd binary, so no documentation shouldn't be build. (Any documentation there is must be a leftover from the original esoundd sources nxesd is derived from, and thus be innacurate anyway.) Jon: you might have to patch it to get rid of any unnessesary parts.
(In reply to comment #179) > (In reply to comment #178) > > well, that pulled in xdialog and sessreg as dependencies for nxcomp, but didnt > > do anything on the issue. i checked the Makefile. > > jw -f docbook -h html ./esound.sgml > > is called, and fails with $? = 8. if i call make in in the root dir, after i > > did remove that line from the Makefile, it will compile cleanly. So merging > > this ebuild manually might be possible, ignoring the doc. > > Sounds like (jet another) problem with the build system. The nxesd ebuild isn't > actually interested in installing anything but the nxesd binary, so no > documentation shouldn't be build. (Any documentation there is must be a > leftover from the original esoundd sources nxesd is derived from, and thus be > innacurate anyway.) Jon: you might have to patch it to get rid of any > unnessesary parts. > *adds to list* Okay. Thanks. :)
New SVN commit. :) * Fixed the inherits for nxesd. * Wrote a patch that completely disables all compiling of all docs. I decided to co through all the Makefiles and configure files and took out all references to the docs dir. :) This way it's not configured, so it saves a bit of time there. ;) * fixed the description of the FreeNX ebuilds to match that of the !M servers. :) * I have a special treat for you all, a present if you will since you all have been a big help in testing these ebuilds and making suggestions, I decided to add in a use flag to nxclient that will allow one to install the xft version of the client. :) I noticed some people had to change the URL of the client to pull in the xft version. !M does something weird -- they gave the non-xft and the xft versions of the client the same name. :S So, you can't link to the RPMs. :( So, I had to link the XFT version to the tarball. We have not used the tarball before so this requires lots of testing to make sure it's binary correct. :) Let me know how it works. Thanks.
Also, the regular !M server ebuilds are being worked on so they pass QA. :) Using the tarball instead of the .rpm is kind of a work around for NXClient, I know, but it's the best we can do right now. :)!M needs to put "xft" in the name of it or something. :P But, this works, and it finally uses that small bit of code in the ebuild about the tarball only being in /usr instead of /usr/NX. That code has been in there for a long time and was never used. :P Now it is being used. ^^ It works too. :) So, kudos to Stuart for writing that small fix a long time ago. Cheers.
The xft nxclient is good except the tarball is missing these 3 files. /usr/share/applications/nxclient.desktop /usr/share/applications/nxclient-wizard.desktop /usr/share/applications/nxclient-admin.desktop I can only presume it came from the rpm only.
(In reply to comment #183) > The xft nxclient is good except the tarball is missing these 3 files. > > /usr/share/applications/nxclient.desktop > /usr/share/applications/nxclient-wizard.desktop > /usr/share/applications/nxclient-admin.desktop > > I can only presume it came from the rpm only. > I will change to the debian package since the tarball doesn't have that in there. Thanks for spotting that. :) Cheers.
I wrote an eclass to handle debian packages. :) It makes the ebuild simpler. :P Now anyone can use debian packages by including the eclass, so it helps all. ;) I tested the debian package of the xft version of nxclient and it seems to work. ^^ I will upload this eclass and the new ebuild later. I need to do some more testing on other things first. ;) Cheers.
I changed the nxclient to use the debian package. :) It works fine with my testing. ^^ I changed the !M slightly. The source URIs are a little different now. That is the only change over Stuarts work. :) I am trying out a new way to pass QA and have automatic DownLoads. nxserver-personal uses the .rpm nxserver-business uses the .tar.gz nxserver-enterprise uses the .dep I did a diff on the three download formats for the personal version and all that was different was the sample files, so there shouldn't be much of a difference. :) To fully update, you need to do an extra step: In the directory you did: svn co http://svn.gnqs.org/svn/gentoo-nx-overlay/testing/net-misc you also need to do: svn co http://svn.gnqs.org/svn/gentoo-nx-overlay/testing/eclass There are two eclasses you need. The debian eclass is needed by nxclient as well. So, you need to check out the eclasses. :) Also, review the eclasses and report back if you find anything. :) I made the debian eclass because there was none, when there is a RPM elcass and because it makes the ebuild neater. Now there is an automatic way to do extract ebuilds. :D Thanks. :D
If you synced between the time of the last message and the time of this one, then sync again, I finally fixed a couple bugs. :) So, I hope things are correct now. Any words?
I just fixed an issue with the nxclient ebuild. :) the xft flag allows you to use the xft version of nxclient instead of the non-xft version. In the past, it's always been the non-xft version that gets installed. To be honest, I don't know the difference between the two. But, a user requested it on IRC once, so it's there now. :) Enjoy. Cheers.
Created an attachment (id=84776) [details] nx-overlay-howto.txt Updated instructions. :)
Created an attachment (id=84778) [details] nx-overlay-howto.txt Updates with suggestions from IRC.
Hm, doesn't work for me :( While installing nxclient: askwar@hetzner ~ $ sudo emerge -1vat nxclient Password: These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] net-misc/nxclient-1.5.0-r4 USE="xft" 0 kB [2] Total size of downloads: 0 kB Portage overlays: [1] /Gentoo/Portage/local-tree/misc [2] /Gentoo/Portage/local-tree/overlays/nx [3] /Gentoo/Portage/local-tree/overlays/gentoo-de Do you want me to merge these packages? [Yes/No] >>> Emerging (1 of 1) net-misc/nxclient-1.5.0-r4 to / >>> checksums files ;-) nxclient-1.5.0-r4.ebuild >>> checksums files ;-) files/digest-nxclient-1.5.0-r4 >>> checksums src_uri ;-) nxclient_1.5.0-141_i386.deb >>> Unpacking source... >>> Unpacking nxclient_1.5.0-141_i386.deb !!! ERROR: net-misc/nxclient-1.5.0-r4 failed. Call stack: ebuild.sh, line 1532: Called dyn_unpack ebuild.sh, line 697: Called src_unpack nxclient-1.5.0-r4.ebuild, line 44: Called debian_src_unpack debian.eclass, line 70: Called unpack ebuild.sh, line 350: Called die !!! Nothing passed to the 'unpack' command !!! If you need support, post the topmost build error, and the call stack if relevant. What's wrong? I followed the latest overlay howto in attachment id=84778
(In reply to comment #191) > Hm, doesn't work for me :( > > While installing nxclient: > > askwar@hetzner ~ $ sudo emerge -1vat nxclient > Password: > > These are the packages that would be merged, in reverse order: > > What's wrong? I followed the latest overlay howto in attachment id=84778 > Ooooooops. Sorry about that. I had a very stupid typo in the eclass. :$ It's fixed now. If you must know, I misspelled this word: x Yep. I misspelled a one letter word. -_- It happens to the best of us I guess. :P Cheers.
I've now got a different error, when I try to emerge net-misc/nxclient-1.5.0-r4 which is *NOT* from the overlay: >>> Test phase [not enabled]: net-misc/nxclient-1.5.0-r4 >>> Install nxclient-1.5.0-r4 into /Gentoo/Portage/build/portage/nxclient-1.5.0-r4/image/ category net-misc cp: cannot stat `usr': No such file or directory rmdir: /Gentoo/Portage/build/portage/nxclient-1.5.0-r4/image//usr/NX/lib: No such file or directory !!! ERROR: net-misc/nxclient-1.5.0-r4 failed. Call stack: ebuild.sh, line 1525: Called dyn_install ebuild.sh, line 1002: Called src_install nxclient-1.5.0-r4.ebuild, line 73: Called die !!! leftover libraries in /Gentoo/Portage/build/portage/nxclient-1.5.0-r4/image//usr/NX/lib !!! If you need support, post the topmost build error, and the call stack if relevant. Before I did the emerge, I did "rm -rf /Gentoo/Portage/build/portage/*". Flags: [ebuild N ] net-misc/nxclient-1.5.0-r4 USE="xft" 0 kB
(In reply to comment #193) 1. This bug is dead. Open a new bug for each new issue. 2. Looking at hte paths in your report it looks like you are using some very weired setup. Are you using Gentoo/OSX or some such? nxclient only works on plain GNU/Linux x86 (and amd64, through emul-packages).
(In reply to comment #194) > (In reply to comment #193) > 1. This bug is dead. Open a new bug for each new issue. Okay. I added this here, as comment #191 and comment #192 also dealt with unpacking issues. > 2. Looking at hte paths in your report it looks like you are using some very > weired setup. Are you using Gentoo/OSX or some such? nxclient only works on > plain GNU/Linux x86 (and amd64, through emul-packages). No, nothing special at all. Just plain ~x86. Anyway, please see bug #132608
