On Sat, 2006-12-09 at 17:29 +0100, Kay Diederichs wrote:
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
I have been looking at this, and I get the exact same problems, but only with a couple applications.
I have recompiled and looked at the logs, but can't seem to fix this issue.
I am still looking at it, and will do so again today.
I also noticed that somehow these programs seem to think the color is 8 bit.
Thanks, Johnny Hughes