Hi Paul,
On So 23 Nov 2014 03:19:24 CET, paul.szabo wrote:
Dear Mike,
I know there is "one last remaining bug" in nxproxy; I have not been
able to find it. I will now stop working on nxproxy, and start using
"ssh -C" instead: seems to provide similar performance, is well tested,
and is less l
Dear Mike,
I know there is "one last remaining bug" in nxproxy; I have not been
able to find it. I will now stop working on nxproxy, and start using
"ssh -C" instead: seems to provide similar performance, is well tested,
and is less likely to cause problems seeing how it does not mess much
with th
Hi Paul,
- Original message -
> Dear Mike,
>
> > The nxproxy built for X2Go does not get built against libX11 from Xorg
> > but against libNX_X11 [1] from NoMachine.
> > Will this break the GenericEvents part of your patch? Or does it
> > simply require a patch in libNX_X11?
>
> Please
Dear Mike,
> The nxproxy built for X2Go does not get built against libX11 from Xorg
> but against libNX_X11 [1] from NoMachine.
> Will this break the GenericEvents part of your patch? Or does it
> simply require a patch in libNX_X11?
Please update your libNX_X11 file. (Seems you took a copy of s
Hi Paul,
On Fr 14 Nov 2014 21:40:26 CET, paul.szabo wrote:
Dear Mike,
Unfortunately, your patch does not build cleanly (FTBFS!).
https://jenkins.x2go.org:8443/view/NX/job/nx-libs+nightly+debian-sid/63/console
Any idea why?
The "actual error" is shown towards the end of that .../console :
Dear Mike,
Seems that I found a reproducible way of getting nxproxy confused: start
/usr/bin/chromium then (at some stage) use ctrl-W to close its window:
the window will not close but become "empty and transparent", and
"nxproxy -C" will show an (endless?) stream of complaints
Proxy: WARNING! H
Dear Mike,
> Unfortunately, your patch does not build cleanly (FTBFS!).
> https://jenkins.x2go.org:8443/view/NX/job/nx-libs+nightly+debian-sid/63/console
> Any idea why?
The "actual error" is shown towards the end of that .../console :
ClientChannel.cpp:5444:33: error: 'GenericEvent' was not d
Hi Paul,
On Do 13 Nov 2014 23:33:03 CET, Mike Gabriel wrote:
Dear Paul,
On Mi 12 Nov 2014 21:22:51 CET, Paul Szabo wrote:
Dear Mike,
My current patches, for BIG-REQUESTS and Generic Event Extension, below.
With these, nxproxy works well. (Though, once a crash was observed,
unfortunately n
Dear Paul,
On Mi 12 Nov 2014 21:22:51 CET, Paul Szabo wrote:
Dear Mike,
My current patches, for BIG-REQUESTS and Generic Event Extension, below.
With these, nxproxy works well. (Though, once a crash was observed,
unfortunately not "trapped" or de-bugged, yet...)
Some other patches, that make
Dear Mike,
> Do you mean, I should rather still wait with applying your patch
> upstream? Need more testing? Or do you actually say that the patch
> is stable and the crash has been related to something else?
I believe the patches I sent are correct and stable; but that there
lurks some other an
Hi Paul,
On Do 13 Nov 2014 04:19:24 CET, paul.szabo wrote:
A user just reported to me:
Just had an nxproxy crash, running Dropbox, nautilus, firefox, and gedit.
Didn't start any particular process when it crashed.
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this i
A user just reported to me:
> Just had an nxproxy crash, running Dropbox, nautilus, firefox, and gedit.
> Didn't start any particular process when it crashed.
>
> [xcb] Unknown sequence number while processing queue
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not
> bee
Dear Mike,
My current patches, for BIG-REQUESTS and Generic Event Extension, below.
With these, nxproxy works well. (Though, once a crash was observed,
unfortunately not "trapped" or de-bugged, yet...)
Some other patches, that make nxproxy more useful in my environment,
below also (hoping others
Hi Paul,
On Fr 07 Nov 2014 10:50:33 CET, paul.szabo wrote:
Dear Mike,
Maybe the issue is
X Generic Event Extension
http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html
of variable length, as yet un-supported by nxproxy?
Pre-empting anything below: I have now added code to nxpro
Dear Mike,
>> Maybe the issue is
>> X Generic Event Extension
>> http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html
>> of variable length, as yet un-supported by nxproxy?
Pre-empting anything below: I have now added code to nxproxy to
correctly handle (support) "X Generic Event Exte
Hi Paul,
On Mi 05 Nov 2014 21:43:15 CET, paul.szabo wrote:
I just wrote:
Further testing suggests that as nautilus is about to die, it gets a
GenericEvent opcode=35 and then an event with opcode=0, then it dies.
Maybe the issue is
X Generic Event Extension
http://www.x.org/releases/X11
I just wrote:
Further testing suggests that as nautilus is about to die, it gets a
GenericEvent opcode=35 and then an event with opcode=0, then it dies.
Maybe the issue is
X Generic Event Extension
http://www.x.org/releases/X11R7.7/doc/xextproto/geproto.html
of variable length, as yet un-su
Further testing suggests that as nautilus is about to die, it gets a
GenericEvent opcode=35 and then an event with opcode=0, then it dies.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustrali
On So 02 Nov 2014 22:12:00 CET, paul.szabo wrote:
Dear Mike,
While looking into the handling of sequence numbers, I notice:
http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
... Every request on a given connection is implicitly assigned
a sequence number, starting with o
Dear Mike,
While looking into the handling of sequence numbers, I notice:
http://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
... Every request on a given connection is implicitly assigned
a sequence number, starting with one ...
Does that mean that each connection should k
Hi Paul,
I will get you together with one of our NX adepts over the weekend. Could you
join us on IRC (#x2go at Freenode)?
I will be travelling during the day and only be scarce online...
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976148
GnuPG Key ID 0x
Dear Mike,
Could you explain to me, or point me to some documentation, about the
use of sequence numbers in X11 generally, and in nxproxy specifically?
Even more specifically, as noted in my latest patches:
ClientChannel.cpp:
// With outputOpcode=X_UnmapSubwindows mostly we get sequenceNum
Dear Mike,
I spoke too soon. I wrote:
... some bogosity with sequence numbers. ... [solved]
but just a little further testing shows:
psz@como:~$ nautilus
Initializing nautilus-open-terminal extension
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded
Dear Mike,
I wrote a few days ago about a crash with kile: was due to a too-tight
setting of some OVERFLOW limit.
Other testing showed some bogosity with sequence numbers.
The patch below (replacing the one sent previously) solves the above
issues; after some (but necessarily limited) testing, I
On Di 28 Okt 2014 12:46:10 CET, paul.szabo wrote:
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 x
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 a
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
> br
Hi Paul,
On Di 28 Okt 2014 08:09:16 CET, paul.szabo wrote:
Dear Mike,
You have the new, patched nxproxy on both ends of the connection?
The encoding of the data has changed.
...
nxagent and nxproxy are installed onto different systems from
different sources ...
So, this should be handled by
Dear Mike,
>> You have the new, patched nxproxy on both ends of the connection?
>> The encoding of the data has changed.
> ...
> nxagent and nxproxy are installed onto different systems from
> different sources ...
> So, this should be handled by your code then, I guess.
The encoding must change:
Hi Paul,
On Di 28 Okt 2014 00:17:55 CET, paul.szabo wrote:
Dear Mike,
I test your patch and it results in several nxproxy crashes ...
You have the new, patched nxproxy on both ends of the connection?
The encoding of the data has changed.
Cheers, Paul
Ah... Good point. No. And this would
Dear Mike,
> I test your patch and it results in several nxproxy crashes ...
You have the new, patched nxproxy on both ends of the connection?
The encoding of the data has changed.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and S
Dear Mike,
Thanks for the various infos, will follow up sometime.
> ... I decided not to package MDM for Debian ... [conflict] GDMv3 ...
Pity, I would be happy to ditch the buggy GDM3. On wheezy I still use
GDM2 from squeeze (replacing GDM3), unfortunately that does not work on
jessie anymore.
Hi Paul,
On Mo 27 Okt 2014 22:02:02 CET, paul.szabo wrote:
Dear Mike,
A MATE session is a session running the MATE desktop environment.
It is available in Debian jessie. MATE is GNOME desktop environment
(version 2) continued. It is _the_ recommended desktop environment for
remote desktop us
Dear Mike,
> A MATE session is a session running the MATE desktop environment.
> It is available in Debian jessie. MATE is GNOME desktop environment
> (version 2) continued. It is _the_ recommended desktop environment for
> remote desktop usage on Linux at the moment. ...
Where is that recommenda
Dear Paul,
On So 26 Okt 2014 22:38:57 CET, paul.szabo wrote:
Dear Mike,
with my test setup I simply launched an X2Go session and clicked here
and there in a MATE desktop session.
At some points (they don't seem to be predictable), the X2Go session
suspends (i.e. nxproxy dies) with earlier r
Dear Mike,
> with my test setup I simply launched an X2Go session and clicked here
> and there in a MATE desktop session.
>
> At some points (they don't seem to be predictable), the X2Go session
> suspends (i.e. nxproxy dies) with earlier reported error messages.
Ah, easy: I will just need to fin
Hi Paul
On So 26 Okt 2014 22:26:52 CET, paul.szabo wrote:
Dear Mike,
OK, so maybe I can build nxproxy and nxagent. (I certainly can, and
did, build nxproxy with my patches; so far do not have nxagent.)
But then, what do I do to elicit your crash: what do I run?
Thanks, Paul
Paul Szabo p..
Dear Mike,
OK, so maybe I can build nxproxy and nxagent. (I certainly can, and
did, build nxproxy with my patches; so far do not have nxagent.)
But then, what do I do to elicit your crash: what do I run?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
Schoo
Hi Paul,
(re-Cc:ing the bug, hope that is ok...)
On So 26 Okt 2014 21:02:18 CET, paul.szabo wrote:
Dear Mike,
Just in case I was not clear enough in my previous message:
Please send me instructions on how to reproduce the nxproxy crash,
and I will try to fix the problem.
Cheers, Paul
As t
Dear Mike,
> I test your patch and it results in several nxproxy crashes every 1-2
> minutes. The output of the session.log file you can find below.
> ...
> Error: Can't add a message of 3306686292 bytes to write buffer.
> Error: Assuming error handling data in context [B].
That comes from WriteB
Control: tag -1 moreinfo
Control: tag -1 - patch
Hi Paul,
thanks for helping with improving NX code. I am one of the Debian
maintainers of nx-libs-lite as well of the release manager of X2Go, a
terminal server solution that uses nxproxy and acts as upstream for
the packages in Debian.
I
41 matches
Mail list logo