On Thu, 2006-11-23 at 22:49 +0100, Kay Diederichs wrote:

Johnny Hughes wrote:

...

There are new versions of nx and freenx for CentOS-4 i386 in the testing repo:

freenx-0.5.0-11.c4.i386.rpm nx-2.1.0-2.c4.i386.rpm

I am using this on 3 servers and it seems at least as stable as the previous versions. These RPMS roll in the latest nx-2.1.x server components from nomachine.org (current CentOS-4 version has nx-1.5.x server components).

The full screen patch was retained across versions and seems to work OK here as well.

If you are using the CentOS version of NX / FreeNX, please test this version and provide feedback on this list. Barring any show stopping negative feedback, these RPMS will replace the current versions in CentOS extras in 2 weeks.

Testing repository .repo file: http://dev.centos.org/centos/4/CentOS-Testing.repo

Packages can be download manually here: http://dev.centos.org/centos/4/testing/i386/RPMS/

Thanks, Johnny Hughes

---

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

I have been using the 32bit CentOS-provided freenx / nx successfully on x86_64 systems. I believe they require nxsetup --purge --uninstall nxsetup after the initial install, but then they work just fine. Now I'd like to update them to the testing ones, using yum. How can I do this - the .repo file in your posting does not work - my $basearch is wrong !? I think yum should have an option to override $basearch, or the i386 packages should somehow be visible in the x86_64 repo.

Clearly I can download the .rpms and run yum or rpm directly, but there ought to be a more elegant way ...

Kay

Kay,

They are both .i386 packages and I could put them in the x86_64 repo ... but I haven't checked that all the dependancies are meet in the other parts of the x86_64 repo.

I will test that now and see if that is the case.

The source from No Machine will not compile on x86_64, or we would have an x86_64 version. Since the source did not work for x86_64, I was concentrating on making that work and I didn't think to try to make the i386 version work on x86_64 :)

For the purposes of testing, could you please manually download them and install ... and if everything i386 required to support NX/FREENX is in the base x86_64 repo already, then when we move these into production, I can also put it into the x86_64 repo too.

I am going to start looking at that aspect of it right now.

Thanks, Johnny Hughes

Johnny Hughes wrote:

On Thu, 2006-11-23 at 22:49 +0100, Kay Diederichs wrote:

...

Johnny Hughes wrote:

...

There are new versions of nx and freenx for CentOS-4 i386 in the testing repo:

freenx-0.5.0-11.c4.i386.rpm nx-2.1.0-2.c4.i386.rpm

I am using this on 3 servers and it seems at least as stable as the previous versions. These RPMS roll in the latest nx-2.1.x server components from nomachine.org (current CentOS-4 version has nx-1.5.x server components).

The full screen patch was retained across versions and seems to work OK here as well.

If you are using the CentOS version of NX / FreeNX, please test this version and provide feedback on this list. Barring any show stopping negative feedback, these RPMS will replace the current versions in CentOS extras in 2 weeks.

Testing repository .repo file: http://dev.centos.org/centos/4/CentOS-Testing.repo

Packages can be download manually here: http://dev.centos.org/centos/4/testing/i386/RPMS/

Thanks, Johnny Hughes

---

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

I have been using the 32bit CentOS-provided freenx / nx successfully on x86_64 systems. I believe they require nxsetup --purge --uninstall nxsetup after the initial install, but then they work just fine. Now I'd like to update them to the testing ones, using yum. How can I do this - the .repo file in your posting does not work - my $basearch is wrong !? I think yum should have an option to override $basearch, or the i386 packages should somehow be visible in the x86_64 repo.

Clearly I can download the .rpms and run yum or rpm directly, but there ought to be a more elegant way ...

Kay

Kay,

They are both .i386 packages and I could put them in the x86_64 repo ... but I haven't checked that all the dependancies are meet in the other parts of the x86_64 repo.

I will test that now and see if that is the case.

The source from No Machine will not compile on x86_64, or we would have an x86_64 version. Since the source did not work for x86_64, I was concentrating on making that work and I didn't think to try to make the i386 version work on x86_64 :)

For the purposes of testing, could you please manually download them and install ... and if everything i386 required to support NX/FREENX is in the base x86_64 repo already, then when we move these into production, I can also put it into the x86_64 repo too.

I am going to start looking at that aspect of it right now.

Thanks, Johnny Hughes

---

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

Johnny,

manual installation of the i386 packages (freenx used to be a .noarch package which seems more appropriate, why did that change?) on x86_64 worked well. A few moments ago, "yum update" to today's versions (now that they are in the x86_64 directory) also worked well.

One thing that does not function as it used to is color management: the new nxserver produces the wrong colors in the client's window for some apps (I use xosview - all the colours in the bars are the same). This was no problem with the old version of nxserver.

best, Kay

Kay Diederichs wrote:

Johnny Hughes wrote:

...

On Thu, 2006-11-23 at 22:49 +0100, Kay Diederichs wrote:

...

Johnny Hughes wrote:

...

There are new versions of nx and freenx for CentOS-4 i386 in the testing repo:

freenx-0.5.0-11.c4.i386.rpm nx-2.1.0-2.c4.i386.rpm

I am using this on 3 servers and it seems at least as stable as the previous versions. These RPMS roll in the latest nx-2.1.x server components from nomachine.org (current CentOS-4 version has nx-1.5.x server components).

The full screen patch was retained across versions and seems to work OK here as well.

If you are using the CentOS version of NX / FreeNX, please test this version and provide feedback on this list. Barring any show stopping negative feedback, these RPMS will replace the current versions in CentOS extras in 2 weeks.

Testing repository .repo file: http://dev.centos.org/centos/4/CentOS-Testing.repo

Packages can be download manually here: http://dev.centos.org/centos/4/testing/i386/RPMS/

Thanks, Johnny Hughes

---

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

I have been using the 32bit CentOS-provided freenx / nx successfully on x86_64 systems. I believe they require nxsetup --purge --uninstall nxsetup after the initial install, but then they work just fine. Now I'd like to update them to the testing ones, using yum. How can I do this - the .repo file in your posting does not work - my $basearch is wrong !? I think yum should have an option to override $basearch, or the i386 packages should somehow be visible in the x86_64 repo.

Clearly I can download the .rpms and run yum or rpm directly, but there ought to be a more elegant way ...

Kay

Kay,

They are both .i386 packages and I could put them in the x86_64 repo ... but I haven't checked that all the dependancies are meet in the other parts of the x86_64 repo.

I will test that now and see if that is the case.

The source from No Machine will not compile on x86_64, or we would have an x86_64 version. Since the source did not work for x86_64, I was concentrating on making that work and I didn't think to try to make the i386 version work on x86_64 :)

For the purposes of testing, could you please manually download them and install ... and if everything i386 required to support NX/FREENX is in the base x86_64 repo already, then when we move these into production, I can also put it into the x86_64 repo too.

I am going to start looking at that aspect of it right now.

Thanks, Johnny Hughes

---

---

CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel

Johnny,

manual installation of the i386 packages (freenx used to be a .noarch package which seems more appropriate, why did that change?) on x86_64 worked well. A few moments ago, "yum update" to today's versions (now that they are in the x86_64 directory) also worked well.

One thing that does not function as it used to is color management: the new nxserver produces the wrong colors in the client's window for some apps (I use xosview - all the colours in the bars are the same). This was no problem with the old version of nxserver.

best, Kay

The error messages for xclock and xosview when using the new nx/freenx packages are below, in case someone could look into this.

I know this kind of message from old times when using 8-bit colormaps. But e.g. "xwininfo" tells me Depth: 24 Visual Class: TrueColor

I'd also like to mention that this problem occur no matter if I use a Linux or Windows NX client. So it seems that it's a server-only problem. Going back to the old nx/freenx package fixes the colormap problems.

kay@turn13:-cns/ms686% xclock Warning: Color name "black" is not defined kay@turn13:-cns/ms686% xosview XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine

On Sat, 2006-12-09 at 10:52 -0600, Johnny Hughes wrote:

On Sat, 2006-12-09 at 17:29 +0100, Kay Diederichs wrote:

<snip>

...

...

manual installation of the i386 packages (freenx used to be a .noarch package which seems more appropriate, why did that change?) on x86_64 worked well.

I did not answer that question before :) ... there is a c program that needs to be compiled now (nxserver-helper) so there is more than just bash scripts and the package is now arch dependent ... where as before is was only text files, batch scripts, and docs.

<snip>

...

The error messages for xclock and xosview when using the new nx/freenx packages are below, in case someone could look into this.

I know this kind of message from old times when using 8-bit colormaps. But e.g. "xwininfo" tells me Depth: 24 Visual Class: TrueColor

I'd also like to mention that this problem occur no matter if I use a Linux or Windows NX client. So it seems that it's a server-only problem. Going back to the old nx/freenx package fixes the colormap problems.

kay@turn13:-cns/ms686% xclock Warning: Color name "black" is not defined kay@turn13:-cns/ms686% xosview XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : yellow XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : orange XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : seagreen XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : SkyBlue XWin::allocColor() : failed to alloc : SlateBlue1 XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine XWin::allocColor() : failed to alloc : red XWin::allocColor() : failed to alloc : aquamarine

<snip>

This is now corrected with the latest versions, which are available now:

freenx-0.5.0-12.el4.centos.i386.rpm nx-2.1.0-4.el4.centos.i386.rpm

========================================================================

The NX and FreeNX RPMS in the testing Repository have been upgraded. Here is what has changed:

NX:

1. Incorporated the latest No Machine releases from this announcement: http://www.nomachine.com/news-read.php?idnews=188

FreeNX:

1. Upgraded to the latest SVN version (revision 282) to fix the xosview / xclock issues that are noted before.

2. Renamed (and modified) the former patch named fc5patch.diff to CentOS-4-patch.diff

3. Removed nxclient.diff as that functionality was rolled in already with SVN revision 282.

4. Added nxnode slave mode (and nxserver-helper).

I think this version is more stable than the last ... please test and provide feedback so we can roll this out.

Thanks, Johnny Hughes

On Wed, 2007-01-03 at 12:19 +0100, Kay Diederichs wrote:

Johnny Hughes wrote: ...

...

The NX and FreeNX RPMS in the testing Repository have been upgraded. Here is what has changed:

NX:

1. Incorporated the latest No Machine releases from this announcement:

http://www.nomachine.com/news-read.php?idnews=188

FreeNX:

1. Upgraded to the latest SVN version (revision 282) to fix the

xosview / xclock issues that are noted before.

2. Renamed (and modified) the former patch named fc5patch.diff to

CentOS-4-patch.diff

3. Removed nxclient.diff as that functionality was rolled in already

with SVN revision 282.

4. Added nxnode slave mode (and nxserver-helper).

I think this version is more stable than the last ... please test and provide feedback so we can roll this out.

Thanks, Johnny Hughes

My feedback for the new packages:

a) nxsetup is overly smart because it requires --override even for --help

b) On the server I had to

1. nxsetup --uninstall --purge --override
2. nxsetup --override
3. then accept the defaults
4. the resulting error messages

---

Error: Invalid value "APPLICATION_LIBRARY_PRELOAD=/usr/lib/libX11.so.6.2:/usr/lib/libXext.so.6.4:/usr/lib/libXcomp.so.1:/usr/lib/libXcompext.so.1:/usr/lib/libXrender.so.1.2" Error: Could not find 1.5.0 or 2.0.0 version string in nxagent. NX 1.5.0 or 2.0.0 backend is needed for this version of FreeNX.

---

do not appear to be harmful because the server works ok. I know this _should_ not be necessary but it _is_ necessary for me because otherwise my client says "NX server disabled or not installed", or something to that effect. I guess this may be a "local problem" of some kind (i.e. me not understanding the "client key" business), and not related to the new nx version or package.

Not sure why you would need to rerun nxsetup. On install there is a client ID key that is in /etc/nxsever and that key just needs to be cut and pasted into the key section on the client machines ... nxsetup should never need to be run.

There are directions here:

http://wiki.centos.org/FreeNX

That override section was specifically added by Rick Stout of Fedora Extras to make it difficult to run NX setup as many people were killing their installs. I could remove it, but would rather not.

c) the problems with the color maps are indeed fixed

d) a new problem (at least compared to nx-1.5.0-1.centos4.i386) is that the session cannot be terminated or suspended by signalling the client (on a CentOS-4 machine): clicking the "X" of the client's window or even ALT-F4 does not result in a "xmessage" window where "suspend", "terminate" or "cancel" can be chosen. Rather, I had to kill the nxssh process.

I can use the "X" of the client window with no problems, maybe it has something to do with rerunning nxsetup???

Also, there are known issues if the NoMachine Linux client is not installed on the server, so you might give that a try (Though I added a patch to fix that problem).

Thanks, Johnny Hughes

Johnny Hughes wrote:

...

after the initial install, but then they work just fine. Now I'd like to update them to the testing ones, using yum. How can I do this - the .repo file in your posting does not work - my $basearch is wrong !? I think yum should have an option to override $basearch, or the i386 packages should somehow be visible in the x86_64 repo.

They are both .i386 packages and I could put them in the x86_64 repo ... but I haven't checked that all the dependancies are meet in the other parts of the x86_64 repo.

not working for me, on a clean x86_64 box, i did a yum install nx freenx, and its setup fine ( pulls in openssl.i686 and a few more deps - nothing X related ). I can use a client ( again from a x86_64 machine ) and login, the auth goes through fine, the desktop comes up too. But I get no window borders in the nx session, and using the mouse is a hit and miss situation, the pointer seems to be offset by about 80 px X 30 px, making it effectively unusable.

Is there something that I might have missed here ? I am a NX Noobie, so if anyone has words of wisdom to shed, please do so.

- KB

Hi!

Does anybody interesting my adaptation of ALTLinux excellent terminus font (http://www.is-vn.bg/hamster/jimmy-en.html) RPM/SRPM/spec?

Ken Simons