[CentOS-devel] Re: New nx/freenx RPMS for CentOS-4 i386 in the Testing Repo

Sat Dec 9 16:52:49 UTC 2006

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.sig>