[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