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 at 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 at 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 at turn13:-cns/ms686% xclock > Warning: Color name "black" is not defined > kay at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20061209/93f07b16/attachment-0007.sig>