[pkg-x2go-devel] Bug#766299: nxproxy: BIG-REQUESTS patch builds but fails at runtime

Mike Gabriel mike.gabriel at das-netzwerkteam.de
Tue Oct 28 11:51:57 UTC 2014


Hi Paul,

On  Di 28 Okt 2014 12:46:10 CET, paul.szabo wrote:

> Dear Mike,
>
>> If it is not possible to dynamically detect if 16 or 32 bit encoding
>> is used on the server-side (the client-side should be the flexible
>> part), then your patch has to wait for that rewrite to come (a design
>> change then is absolutely ok and wanted). I don't think we should
>> break compatibility within the 3.5.0.x release series.
>>
>> So again, do you see an option for detecting the server-side encoding
>> (or querying it or triggering/enforcing it via a nxagent cmdline
>> option)?
>
> That would be do-able, but probably not practical. The two nxproxy-ies
> could somehow try to detect whether the other is also capable of
> BIG-REQUESTS, and if so use 32-bit encodings and not use the
> HIDE_BIG_REQUESTS_EXTENSION setting; but if not then fall back to 16-bit
> and to hide. That would make the code even more messy (and likely,
> buggy) than it is now.
>
>> PS: How do you test if the BIG-REQUESTS implementation works? With
>> TexPower, you said. What do I have to do to trigger the BIG-REQUESTS
>> bug if nx is not patched?
>
> It is texworks from
>   http://tug.org/texworks
>   http://code.google.com/p/texworks/wiki/Building
> All you need to trigger the bug is to run texworks. Having scrutinized
> things, it does QueryExtension on BIG-REQUESTS; if not getting it
> (because of nxproxy hide as now), then sends "broken" (ill-formatted)
> X11 stream that crashes the "nxproxy -C" side. With my patches, it uses
> BIG-REQUESTS just fine.
>
> ---
>
> One of my users told me that my patched nxproxy would crash when using
> kile (on his special TeX file), seems it is the "nxproxy -S" side that
> crashes. I am now working on reproducing this, and intend to fix.
>
> I have asked my users to test nxproxy, and will attempt to fix all
> issues as they become apparent. When nxproxy seems "stable", I intend to
> make it the default: start "nxproxy -S" with Xorg on the thin client,
> and start "nxproxy -C" and do the xauth and DISPLAY "switcheroo" within
> the GDM2 Xsession.
>
> I will report back here as I go.
>
> Cheers, Paul

While working on that (have I mentioned this before? Have written too  
many mails today already...):

A generic nxproxy has to be Big+Little Endian safe. The X2Go project  
is about to start a cooperation with IBM and we are about to get  
sponsored a PowerPC64 build machine (BE afair). So while juggling with  
bits and bytes, please consider Endianness during your awesome patch  
work!!!

(NX is a complete pile of patches, actually, but the nx-libs repo is  
far more advanced than anything else out there derived from the NX3.5  
series).

Greets,
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/attachments/20141028/8133a5b3/attachment-0001.sig>


More information about the Pkg-x2go-devel mailing list