x2go-dev

x2go-dev@lists.x2go.org

1 participants
5399 discussions

Bug#1222: Timeout of about 30s to start the x2go session
by Bruno CAPELETO 04 Oct '17

04 Oct '17

Package: <x2goserver> Version: <4.1.0.0-0x2go1.2~git20170806.1410+9.heuler.1> # uname -a Linux mtcie1 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1 (2017-06-18) x86_64 GNU/Linux # cat /etc/issue Debian GNU/Linux 9 \n \l When connecting to this x2go server - linux client and/or Windows client, I tested both - the session takes about 30s to start. I checked the /var/log/auth.log : the ssh connexion is pretty fast (1-2s) I checked the x2go session.log : it is finished about 30s later What happens during these 30s I do not understand. I have other installations on Debian 8, this does not take so long.

1 0

Bug#1018: The problem still exists
by Chessplayer 28 Sep '17

28 Sep '17

Hi guys, unfortunately, there has been no response to this bug report for over a year and also no answer to this question on the Ubuntu forum: https://forum.ubuntuusers.de/topic/x2go-und-path-variable/ The problem still remains ... Do you plan on doing something about it? Cheers, chessplayer

1 0

X2Go Developer Meeting 2017-09-28 20:30 CEST / 02:30pm EDT
by Stefan Baur 27 Sep '17

27 Sep '17

Dear $ALL, As you probably know from the Wiki and from previous announcements on the lists, X2Go: The Gathering 2017 took place last weekend. One of the things decided/agreed on at this event was that we should have Developer Meetings more regularly. The plan is to aim for one DevMeeting per quarter, though obviously additional ones can be set up if the need arises. The next DevMeeting is scheduled for tomorrow, 2017-09-28, 20:30 CEST / 02:30 EDT. We will gather in #x2go on irc.freenode.net and discuss the required X2GoServer code updates in preparation of the upcoming release, which we intend to finish by early December 2017. Future DevMeetings may take a "hybrid" form, with some people gathering in a hackerspace (or hackerspaces), and others joining in via IRC. Kind Regards, Stefan Baur X2Go Project/Community Manager -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

1 1

Bug#1172: Fwd: Modifier Keys not working as expected
by Ulrich Sibiller 26 Sep '17

26 Sep '17

On Tue, Sep 26, 2017 at 1:57 PM, Stefan Baur <X2Go-ML-1(a)baur-itcs.de> wrote: > Am 26.09.2017 um 12:20 schrieb Ulrich Sibiller: > >>> A certain application requires the following keypresses: >> >> Is the spplication's name secret? > > No, but closed-source/commercial/proprietary. > > >>> - Hold down ctrl, shift and alt >>> - while holding them down, press the space bar >>> - let go of shift and space bar, keep holding down ctrl and alt >> >> leaving you with ctrl-alt > > In theory, yes. But somehow the shift and space bar being pressed and > released first tell it to "keep" the keypresses to itself, rather than > sending them and the function key on to the X Server. No, it's the other way round. The X server gets the keypresses and passes them on to the client(s). This application probably instructs the xserver to send these keys only to the app and not to anyone else (and neither interpret them itself). https://tronche.com/gui/x/xlib/input/XGrabKeyboard.html states this: The XGrabKeyboard() function actively grabs control of the keyboard and generates FocusIn and FocusOut events. Further key events are reported only to the grabbing client. [...] If the keyboard_mode argument is GrabModeAsync, keyboard event processing continues as usual. If the keyboard is currently frozen by this client, then processing of keyboard events is resumed. If the keyboard_mode argument is GrabModeSync , the state of the keyboard (as seen by client applications) appears to freeze, and the X server generates no further keyboard events until the grabbing client issues a releasing XAllowEvents() call or until the keyboard grab is released. Actual keyboard changes are not lost while the keyboard is frozen; they are simply queued in the server for later processing. >> But for analysis we'd need the application to see what is doing. > > They offer a time-limited trial version [0], but IIRC, you still need to > register somewhere with your E-Mail address (and they'll send you promo > E-Mails during the trial phase, and possibly even afterwards). > > >> For the records: I think it is nx-libs so we should open an issue >> there. But I am not sure if we will be able to fix that at all. > > As I said, feel free to do so - you're way more knowledgeable about the > code involved than I am. I can do that eventually. Uli

1 0

Bug#1220: Modifier Keys not working as expected
by Stefan Baur 26 Sep '17

26 Sep '17

package: x2goclient (devs: feel free to reassign this to nx-libs/arctica, if the cause is not in X2GoClient) A certain application requires the following keypresses: - Hold down ctrl, shift and alt - while holding them down, press the space bar - let go of shift and space bar, keep holding down ctrl and alt - with ctrl and alt pressed, press a function key (F1-F6) - let go of all keys This works when the application is run on :0 - the "ctrl-alt-Fx" is not passed down to X, so no switch to tty1-tty6 occurs, which is the intended and expected behavior. However, with the application running in an X2Go session, the same sequence of keys will trigger a switch to tty1-tty6 on the local client. -Stefan -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

2 2

Bug#1208: Messed up session when resuming from Published Apps mode to Fullscreen desktop mode in thinclient mode
by Walid MOGHRABI 26 Sep '17

26 Sep '17

Package: x2gothinclient Version: 4.1.1.0-0~1634~ubuntu16.04.1 Let's say you suspended a session in "Published Apps" mode from a local desktop (might be Linux or Windows, it doesn't matter) then try to resume it from a TCE running the client in thinclient mode. This will work, you can resume the session but the display is completely broken : no desktop, no decorations, corrupted display and no widget to logoff so you're stuck there unless someone kills your session from the server. It would be better to simply block the ability to resume a Published Apps session in a mode where it just can't be done such as the thinclient mode. Regards, Walid Moghrabi TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3 --- DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you

3 5

Bug#1218: Improve User Experience when connecting to a session that is supposed to use agent-cached credentials or a keyfile
by Stefan Baur 25 Sep '17

25 Sep '17

package: x2goclient priority: wishlist Whe an X2Go session is set to use agent-cached credentials or a keyfile, clicking on the session tile will automatically start a connection (unless a keyfile is used and it is password-protected - in that case, a small pop-up is shown that asks for the keyfile's password). If the connection is suspended - be it by a user-initiated suspend command or due to loss of connection - X2GoClient shows the same login/password dialog that is shown on initial connect for a session that is not set up to use agent-cached credentials or a keyfile. This is confusing to the user - as simply clicking "OK" without using the password field is enough to reconnect. There's no need to show an editable user name field and a password entry field. Suggested change: When the client detects a connection loss/suspend, it should return to its default "select a tile" screen, if the session was using agent-cached credentials or a keyfile. If logging in with the agent-cached credentials/keyfile does not work, a popup similar to the one asking for the keyfile password should appear, only with a different visual design and textual description, so users have a chance to understand they are being prompted for the login password, rather than the keyfile password. -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

2 1

Bug#1219: Bug: After Session starts on server&client, message appers on client: "The remote proxy closed the connection while negotiating the session. This may be due to the wrong authentication credentials passed to the server."
by dood0240skpw33＠toothandmail.com 25 Sep '17

25 Sep '17

Package: x2goserver Version: 4.0.1.20 I guess it's the x2goserver package that has the bug?? I don't know about what package precisely!... ***How to Reproduce the bug:*** Install, following the correct and proper instructions, the x2goclient and the x2goserver on respectively your client and your server. (My client is Kali Linux 2017 latest version) (My server is a Raspberry Pi Version 3) Once the server packages are correctly installed in the server, and once the client package(s) is correctly installed in the client: open your x2go client by issuing "x2goclient" in your terminal (my client terminal is root, so I actually issue the command to open the client as root, but I don't get any kind of problem) create a new session with the correct details, and select LXDE protocol. (My rpi3 has lxde package installed and correctly working) Keep in mind the rpi is booted on the cli environment, that's why I'm using the LXDE protocol. Ok then start the connection (after insterting the proper password) Status "connecting" will show up in the x2go client. wait a few minutes and a window from the x2go client will pop up saying: "The remote proxy closed the connection while negotiating the session. This may be due to the wrong authentication credentials passed to the server." Looking at the logs at /var/log/syslog on the x2go server, the output is: root@myrpithree:~# tail -f /var/log/syslog | grep x2go Sep 24 14:11:56 myrpithree /usr/sbin/x2gocleansessions[3591]: myrpithree-50-1506280314_stDLXDE_dp24: state file for this session does not exist: /tmp/.x2go-myrpithree/C-myrpithree-50-1506280314_stDLXDE_dp24/state (this can be ignored during session startups) Sep 24 14:12:00 myrpithree /usr/sbin/x2gocleansessions[3591]: myrpithree-50-1506280314_stDLXDE_dp24: state file for this session does not exist: /tmp/.x2go-myrpithree/C-myrpithree-50-1506280314_stDLXDE_dp24/state (this can be ignored during session startups) Sep 24 14:12:03 myrpithree /usr/sbin/x2gocleansessions[3591]: myrpithree-50-1506280314_stDLXDE_dp24: state file for this session does not exist: /tmp/.x2go-myrpithree/C-myrpithree-50-1506280314_stDLXDE_dp24/state (this can be ignored during session startups) Sep 24 14:12:40 myrpithree /usr/bin/x2gostartagent: successfully started X2Go agent session with ID myrpithree-50-1506280314_stDLXDE_dp24 ^C The session has been successfully started, however I still get that boring message on the client and thus I do not get the RDP window (meanwhile the connection is still on both in the server and in the client, in fact if I try once again the the client it will say that the previous connection is still on.)! I've see this bug is around for quite some years, ANY TEMPORARY SOLUTION PLEASE? DO YOU WANT ME TO POST MORE OUTPUTS OR SOMETHING? PLEASE LET ME KNOW. ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!

1 0

Bug#1216: Issue with minimizing X2GoClient via minimize button in window decoration (Windows)
by Stefan Baur 25 Sep '17

25 Sep '17

package: x2goclient With "Display icon in system tray" and all of its sub-checkboxes checked, x2goclient is supposed to minimize to the system tray. It correctly does so when a connection starts, but an error occurs if one tries to minimize the application manually using the minimize button in the window decoration. Expected behavior: X2GoClient only displays a tray icon. Actual behavior: While the tray icon remains, X2GoClient momentarily vanishes from the task bar, only to return to the task bar a fraction of a second later. Clicking on that task bar entry pops up a "wireframe" of the X2GoClient window with no content. Content only becomes visible once you right-click the tray icon and select "Restore". -Stefan -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

1 0

Bug#1062: X2Go issue (in src:pyhoca-cli) has been marked as closed
by X2Go Release Manager X2Go Release Manager 24 Sep '17

24 Sep '17

close #1062 thanks Hello, we are very hopeful that X2Go issue #1062 reported by you has been resolved in the new release (0.5.0.4) of the X2Go source project »src:pyhoca-cli«. You can view the complete changelog entry of src:pyhoca-cli (0.5.0.4) below, and you can use the following link to view all the code changes between this and the last release of src:pyhoca-cli. http://code.x2go.org/gitweb?p=pyhoca-cli.git;a=commitdiff;h=e116c404a9f1036… If you feel that the issue has not been resolved satisfyingly, feel free to reopen this bug report or submit a follow-up report with further observations described based on the new released version of src:pyhoca-cli. Thanks a lot for contributing to X2Go!!! light+love X2Go Git Admin (on behalf of the sender of this mail) --- X2Go Component: src:pyhoca-cli Version: 0.5.0.4-0x2go1 Status: RELEASE Date: Sun, 24 Sep 2017 09:55:15 +0200 Fixes: 1062 Changes: pyhoca-cli (0.5.0.4-0x2go1) RELEASED; urgency=medium . [ Mihai Moldovan ] * New upstream version (0.5.0.4): - man/man1/pyhoca-cli.1: drop incorrect short option -p as an alias for --pack. Fixes: #1062. -p is already used as the short option for --remote-ssh-port. * debian/control: - Maintainer change in package: X2Go Developers <x2go-dev(a)lists.x2go.org>. - Uploaders: add myself. Also, force a rebuild due to the changed versioning. * pyhoca-cli.spec: - Add support for EPEL5 and (older) SLE versions by using the BuildRoot tag. - SLE support: add --prefix to setup.py install call. Otherwise, data will land in /usr/local/.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev