x2go-dev January 2015

x2go-dev@lists.x2go.org

46 participants
246 discussions

Bug#716: python-x2gobroker web/plain module strips passwords breaking passwords that start or end with a space
by Jason Alavaliant 05 Jan '15

05 Jan '15

Package: python-x2gobroker Version: 0.0.2.3 Tags: patch One of my users was getting their authentication failing when connecting to an x2go broker using the http plain backend. Testing revealed that their password ended with a space which the web/plain module default code was automatically stripping off before passing through to the authservice. The attached patch disables stripping for the password argument so passwords starting/ending with spaces are no longer incorrectly rejected. Thanks Jason

1 0

Processed: 714 not grave
by owner＠bugs.x2go.org 03 Jan '15

03 Jan '15

Processing commands for control(a)bugs.x2go.org: > severity 714 normal Bug #714 [x2goserver] Cannot connect to epel5 servers: Undefined subroutine &main::LOG_UPTO Severity set to 'normal' from 'grave' > End of message, stopping processing here. Please contact me if you need assistance. -- 714: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=714 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Bug#715: Cannot create X2Go Session Database on EPEL 5
by Michael DePaulo 03 Jan '15

03 Jan '15

Package: x2goserver Version: 4.0.1.18 Severity: grave Server OS: CentOS 5.11 64-bit Client: 4.0.3.1 When you attempt to connect to a CentOS 5 server, you get a "Connection failed" error. The error includes the text "unable to open database file(1)" . This bug prevents EPEL 5 users from using X2Go Server at all. The underlying problem appears to be that x2godbadmin fails to create the session database: [batmin@centos-5 log]$ sudo /usr/sbin/x2godbadmin "make_path" is not exported by the File::Path module Can't continue after import errors at /usr/sbin/x2godbadmin line 25 BEGIN failed--compilation aborted at /usr/sbin/x2godbadmin line 25. Newer versions of File::Path provide "make_path", but I was unable to find an EPEL 5 RPM that provides a sufficiently new version of File::Path . This bug appears to be a regression that was introduced by commit bad455e : http://code.x2go.org/gitweb?p=x2goserver.git;a=commit;h=bad455edefdce83da6a…

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev January 2015