x2go-dev

x2go-dev@lists.x2go.org

2 participants
5403 discussions

Bug#714: Actually a packaging problem
by Michael DePaulo 03 Jan '15

03 Jan '15

This is actually a problem with our packaging. A 3rd-party RPM exists to provide a newer version of Sys::Syslog that is sufficient, and this is stated on the wiki. The bug is that yum is not informing the user of the need to install that newer version. The wiki states the following, and the 2nd sentence is false: "One approach is to download required packages manually. Yum will tell you what is needed, when you ask it to install x2goserver." http://wiki.x2go.org/doku.php/doc:installation:x2goserver?&#rhel_5 For reference: The RPM that I used (and tested successfully) was: http://flexbox.sourceforge.net/centos/5/x86_64/perl-Sys-Syslog-0.27-1.el5.x… Apparently 32-bit users should use this noarch RPM instead: http://flexbox.sourceforge.net/centos/5/i386/perl-Sys-Syslog-0.27-1.noarch.…

1 0

Bug#699: epel 5 repos have signature errors
by Michael DePaulo 03 Jan '15

03 Jan '15

Package: buildscripts Severity: normal As reported here: http://lists.x2go.org/pipermail/x2go-user/2014-December/002705.html A CentOS 5 user is getting these errors: error: nx-libs-3.5.0.28-0.0x2go1.1.git20141114.546.main.el5.centos: Header V4 RSA/SHA1 signature: BAD, key ID 5bfe2b6e error: libXcomp-3.5.0.28-0.0x2go1.1.git20141114.546.main.el5.centos: Header V4 RSA/SHA1 signature: BAD, key ID 5bfe2b6e etc.... The cause appears to be that CentOS 5 cannot handle V4 signatures, only V3. http://adminotes.blogspot.fr/2011/12/centos-6-rpm-sign-problem-v4-signature…

3 4

(Jenkins Question) Rebuilding "main" packages for EPEL 5.
by Michael DePaulo 03 Jan '15

03 Jan '15

Hi Mike#1 and others, I want to rebuild the "main" packages for EPEL 5 so that we can fix bug #699. I've already rebuilt and tested the "nightly" EPEL 5 packages; bug #699 was successfully fixed on them. However, it appears that in order to rebuild any package for EPEL 5, I must rebuild them for every release of every Linux distro. http://jenkins.x2go.org:8080/view/All%20Releases/?auto_refresh=false Should I just do that via Jenkins? Or would it be disruptive? For example, would users be prompted to update even when they do not have to? I think that would happen for EPEL users at least, because the nightly EPEL 5 nx-libs packages now have "git20141222" in their version strings. (nx-libs.git was last updated 2 weeks ago, but I rebuilt it under nightly on 2014-12-22 (UTC +1:00).) -Mike

2 2

Bug#712: x2goserver: armhf unfulfilled dependency - patch for debian/control
by Heinrich Schuchardt 25 Dec '14

25 Dec '14

Find here how the debian/control should be patched. The first hunk removes a trailing space. The second hunk makes the dependecy only relevant for amd64 and i386. Best regards Heinrich Schuchardt diff --git a/debian/control b/debian/control index 2fee7cb..43929a6 100644 --- a/debian/control +++ b/debian/control @@ -1,6 +1,6 @@ Source: x2goserver Section: x11 -Priority: optional +Priority: optional Maintainer: X2Go Developers <x2go-dev(a)lists.berlios.de> Uploaders: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de>, @@ -25,7 +25,7 @@ Depends: openssh-server, libconfig-simple-perl, pwgen, - libdbd-pg-perl, + libdbd-pg-perl [amd64], libdbd-pg-perl [i386], libdbd-sqlite3-perl, libfile-basedir-perl, libcapture-tiny-perl,

1 0

Season's greetings
by Heinz-M. Graesing 24 Dec '14

24 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear X2Go Community, Contributors, Developers, Friends, The first Ideas of X2Go were made about 10 years ago. There was no name for this project and only one use case. With the first people using it, it started to grow. In the past years more and more people joined the project, fixed bugs, contributed code and helped to make it usable for more and more people. X2Go now has been growing to something we all really should be proud of - - something we should keep care of. The first step was to start this project. This milestone can be seen as done. The second step from now on will be to keep it running. This will be a real challenge, because this project has a history. Every story of history is something we can learn from and we really should do this to avoid already appeared mistakes and problems. It is really nice to stumble upon screen-shots of X2Go all over the world in different localizations! For the future of this project, we really need to find more and more people helping us to spread the word, to control our work and to translate it for new audiences! Furthermore we really should be aware that communication is the key of cooperation and sharing. Sharing ideas, concerns and problems will be the key to work on our next step -> keep the project running! To all #FriendsOfX2Go: Season's greetings and best wishes for the New Year! Heinz-M. Graesing -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUmlOoAAoJEKRUbBMT/NRx45QQALkX08epw1mHzC/ALi4EGl6s cYmgS+FlT7wBsAkA5yi0OXR/Dma5eD+ZbdhlXRfXM9KHZEAJq2K6x6b+7HQ49zsu /StPeRNggoyWzSX8i9u2yxoANi1vswYPd4710oL5uVkY8gm+Dew0ja1iKdLwojOY WeiGK8SGnlVkDZj6RSBmRL7tLe01kBaqgZhjQ+ixaxIkwfNz+XZJj7m+wyhpjaGw i8y667mouzgqh3XB+Ghb/Vv6HgYcwK4R4FPIheKXRkVsCTa/DPoKdIXxlcAOB3/g ak0WTVtgqJO/XbFEbCFV2WrTWqPeknY+8GiR3H0fT1Ao1OyEhygvj6WcGNa5VqsR vaxoeLe1GHa86qevaiyTElKvESqvPJhYnLJ61OCSN2MRtLKN0fPCyRqjD6SjlYKM Ex8H3biKEuN8wkmLZZ4mk99S9rfAID5PRpUNcPjQXl20k50lfSl1n9Bztj3CY7Jv 0PbSeJwDkq+09uIWwjzBMUE2UofyQNHfRoQmo1KOExO+ElRSsPNxkLLM2Rzny7jT z1lVVT/q1DpFW/0AgqbHWJtDW1r4htEvn3HV0SXWZ9tLIrdXgzkq3m5HgI41aXW2 RCaKYBosjDQkRVB3m8q+kPNTuKDxLd5jgHx10rZXTA8+WFqcBmPeAiTsOgVc0YkG 2TsD/e2rr4Fu71vWS8sJ =FYsf -----END PGP SIGNATURE-----

1 0

RFC: Future coordination of events and contest participations
by Stefan Baur 23 Dec '14

23 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi List, I'm posting this here as we don't have a list for organisational matters (yet - maybe we should create one? Opinions, anyone?). Recently, there have been two occasions where people related to X2Go have signed up/applied in X2Go's name, without letting the others know about it. Since in most cases, it doesn't make sense to apply twice, this means some people have spent time working on an application that had to be scrapped, so as not to collide with the earlier one written by an individual. I don't want to point any fingers in public or name names - those responsible have already hung their heads in shame off-list - however, I would kindly ask *everyone* that knows about contests where X2Go could take part, fairs where we could get a free booth, etc. to post such info on this list (at least until we have a separate list dedicated to that purpose), and tag it "RFP: <YYYY-MM-DD> <Eventname>". That way, we can coordinate our efforts in public and aren't wasting time and end up working against each other and to the disadvantage of the project (two independent applications look unprofessional, IMO). Spending one and a half days on an application that ends up scrapped really sucks, especially if the time dedicated to it could have been spent earning money. *Everybody, please help us avoid this in the future by going public with your info _before_ you apply in X2Go's name.* Kind Regards, Stefan Baur X2Go Lead Evangelist and Event Organizer - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUmWISAAoJEG7d9BjNvlEZiL0H/2noiCfQHs2/OdmAeEjqDfIp HGN3CRcV5sYCd1SAxrtr0OAzg3rLBCwPXQchy10dpuVJ6sFKOFxV3gauBnFnISa0 F8Cfh3Shi8hDIRoh705E/N4X3dC7oZps2JfyLqZZUdkXG7h3YHArw4JsriMQYcuU 5u15VkT3AEsFLcY+93PeqmkcjfC+xuAGG0CAvr3dEt/HfO9yxOVEZyfJCOxcuEcd pr/wVJWQgEj1v8VrVUi2oPXnrPnIOp+D2mIUYXKwz9uu1VfCmdK/a9a3y4CKy8Aj 77ZPyG/uoKIPJYPapExW0arwx9s81DhJauAThFm0lo3wZgRf0tDZd94oyB2UKZA= =lHfJ -----END PGP SIGNATURE-----

2 1

Bug#699: Fix committed, but only the nightly repo is fixed yet
by Michael DePaulo 22 Dec '14

22 Dec '14

I committed the fix to buildscripts.git and updated buildscripts.git on japsand.x2go.org (which builds & uploads the packages.) However, for reasons explained in the linked email, I have only rebuilt the "nightly" packages with the key, not the "main" (stable release) packages yet. And the 4.1.0.0 x2goserver nightly package is very unstable. http://lists.x2go.org/pipermail/x2go-dev/2014-December/008891.html To any users affected by this bug, I hope to have the main packages rebuilt (and therefore fixed) ASAP.

1 0

Bug#710: Error connecting to CentOS 5 Server: Connection Failed "Undefined subroutine &X2Go::Server::DB::PostgreSQL::LOG_UPTO
by Michael DePaulo 22 Dec '14

22 Dec '14

Package: x2goserver Version: 4.1.0.0-preview Server: CentOS 5.11 64-bit with latest updates [batmin@centos-5 ~]$ x2goversion Undefined subroutine &main::LOG_UPTO called at /usr/lib64/x2go/x2gosyslog line 28. x2goagent: 3.5.0.29 x2goserver: 4.1.0.0-preview x2goserver-common: 4.1.0.0-preview x2goserver-extensions: 4.1.0.0-preview x2goserver-xsession: 4.1.0.0-preview X2go Client for Windows: 4.0.3.1-20141214-debug After fixing bug #699, when I attempt to connect to the CentOS 5 server with X2Go Client, I get this "Connection Failed" error pop-up window: x2go-DEBUG-onmainwindow.cpp:3382> "Undefined subroutine &X2Go::Server::DB::PostgreSQL::LOG_UPTO called at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB/PostgreSQL.pm line 42. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB.pm line 40. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB.pm line 40. Compilation failed in require at /usr/bin/x2golistsessions line 27. BEGIN failed--compilation aborted at /usr/bin/x2golistsessions line 27. Clicking "OK" results in you not connecting. I've attached the full log from x2goclient.exe --debug

1 0

Problems with x2goplugin.js
by Niklaus Giger 20 Dec '14

20 Dec '14

Hi I am trying to setup a demo for our Eclipse based RCP application Elexis, letting our application run in a docker container. On my development I manage to run some as I seem to have in my firefox cache an downloaded version of x2goplugin.js. The x2goplugin.html has in it header > <script src="http://plugin.x2go.org/media/x2goplugin.js" > > >type="text/javascript"></script> Which fails to download properly as an Authorization is required. Same when trying to get it via wget > wget http://plugin.x2go.org/media/x2goplugin.js > --2014-12-20 11:32:21-- http://plugin.x2go.org/media/x2goplugin.js > Resolving plugin.x2go.org (plugin.x2go.org) 188.40.28.16 > Connecting to plugin.x2go.org (plugin.x2go.org)|188.40.28.16|:80... > connected. HTTP request sent, awaiting response... 401 Authorization > Required > Reusing existing connection to plugin.x2go.org:80. > HTTP request sent, awaiting response... 401 Authorization Required Could you fix this problem or put a copy of it to public accessible place? Once everything is working, I will publish this project on github and announce it here. Best regards Niklaus

1 0

Bug#708: Bug#708: x2gosqlitewrapper.pl reports "unable to open database" on session-resume, while the database is there.
by Zuck, Daniel 19 Dec '14

19 Dec '14

Hello Mike Thanks for your quick feedback. In a nutshell: I was as well assuming, that a hard fix would be at the end "x2godbadmin --createdb" - however, it would be good to trace the reason why it came to there. Related the Perl modules on SLES, I am not 100% sure, as I am not a "Perl guy", and resolved dependencies if they have been specifically raised via " "make_path" is not exported by the File::Path module" (see http://wiki.x2go.org/doku.php/doc:installation:x2goserver) which was causing me to lift the version of this module (the SLES provided version was too old, so this issue was sorted after the upgrade; same for the RHEL install as described on the Wiki). In more details: >First thing: please note that shortly the X2Go upstream team will provide a new source for SLES packages. The x2goserver version you are using is a >little outdated already. The version is "backported" from OpenSuSE RPM spec's, satisfying the dependencies on SLES. Notably dependencies included to upgrade some of the SLES-provided Perl modules. >I am not sure what perl-Syslog package version is shipped with SLES 11.3, but it seems it cannot handle the "error" logging facility. This is weird in >the first place and maybe you can investigate your system a bit more on this. (What version of perl-Syslog is installed, etc.) The version of Perl is 5.10.0-64.67.52, and there is no specific syslog installed besides the OS-Perl-package (there is a separate perl-Unix-Syslog from SuSE, where I do not know its specific use); it must be a subsequent fault of something else, because syslog and its facilities should be well known since a couple of "decades"... As we have likely a corrupted DB-file, I would try to lift the version of Perl-DBI (maybe the SLES-version is a bit older and has some errors). >Next question is: what file permissions are set on > /var/lib/x2go/x2go_sessions > /usr/<lib>/x2go/x2gosqlitewrapper ls -la /var/lib/x2go/x2go_sessions /usr/lib/x2go/x2gosqlitewrapper -rwxr-sr-x 1 root x2gouser 11978 Nov 4 17:53 /usr/lib/x2go/x2gosqlitewrapper -rw-rw---- 1 root x2gouser 25600 Dec 19 10:35 /var/lib/x2go/x2go_sessions >Next question: > getent passwd x2gouser > getent group x2gouser getent passwd x2gouser x2gouser:x:404:405:x2go server/user:/var/lib/x2go:/bin/false getent group x2gouser x2gouser:!:405: After removing the DB-file and recreating a new one, I can connect without any error. As expected my "old" session was stale. Note: This is the behavior where the system was working since a couple of weeks; the error was raised on two systems at a time. What made me a bit perplex is, that it was visible on two systems, since about the same time. Regards Daniel The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev