From mikedep333@gmail.com Mon Sep 15 18:38:23 2014 Received: (at 566) by bugs.x2go.org; 15 Sep 2014 16:38:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham version=3.3.2 Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 5ED845DB54 for <566@bugs.x2go.org>; Mon, 15 Sep 2014 18:38:23 +0200 (CEST) Received: by mail-we0-f178.google.com with SMTP id q58so4369087wes.9 for <566@bugs.x2go.org>; Mon, 15 Sep 2014 09:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VYNJeUZr0VICGLZn5b5ArTmjnfraxuWyDVHsfhZS5EM=; b=yqO1gBhE1rbH6Ap3QrZ/cPNnzZ+eK8H7XSTzZRYQL6x7DHqIkWiREFAPE8+dxg3bIg gz9sL5S3AwAdyRSoXxr1oscobO4bIk3S5A/QaPX/diebLKRCwznzGx/jW12uSJzpD4WC TAArK2/bz8wjKzDsbeDlXvfjr994ZYXG8M1ylWjrBdd0f9JuvL21FUa9w/DMwK5L1ipZ aNYt1Q/5HeY8+jP/3QEi2c3hVhySk6IWvrLdoZiAqk61zzsGMVceL+Pqv0gAqpf9l5JM VIFSFvafnPSTvoKhnRMGW+Fua/US6tniSZhEv+dGpUBDWCluPpYB/TcCwR6BPPWN5/86 +JuQ== MIME-Version: 1.0 X-Received: by 10.194.122.169 with SMTP id lt9mr35365440wjb.29.1410799102711; Mon, 15 Sep 2014 09:38:22 -0700 (PDT) Received: by 10.180.106.39 with HTTP; Mon, 15 Sep 2014 09:38:22 -0700 (PDT) In-Reply-To: <000001cfd0a5$a1fe42d0$e5fac870$@edu.gr> References: <000001cfb552$3193a8a0$94baf9e0$@gr> <000001cfc60a$32831de0$978959a0$@gr> <20140901195103.Horde.HOAd34FDzvE7MwwNBCtaAg1@mail.das-netzwerkteam.de> <000001cfca83$2b11d830$81358890$@edu.gr> <20140908085833.Horde.1KVN9LjgQ3GOkz4EX-JZjA1@mail.das-netzwerkteam.de> <000001cfd0a5$a1fe42d0$e5fac870$@edu.gr> Date: Mon, 15 Sep 2014 12:38:22 -0400 Message-ID: Subject: Re: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot create C:\Users\\ssh\known_hosts file when the local Windows account username has non-Ascii characters From: Michael DePaulo To: 566@bugs.x2go.org Cc: Michael Frederick , George Trakatelis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Control: severity 566 grave Dear George, Thank you for your research. Over the next day or so, I will apply bug566.test.v2.patch, which will then be included in both the MinGW 4.4 and the MinGW 4.8 nightly builds. Once you (or someone else) confirms that the patch fixes this bug for said installations, I will mark this bug as fixed. I've already cloned this bug. The clone will be for handling languages other than the "Language for non-Unicode programs"; i.e., using Unicode. I am marking this original bug as severity "grave" because it "makes the package in question unusable or mostly so"[1] for a significant number of users. Getting this original bug fixed for x2goclient 4.0.3.0 will be a high priority for me. Also, I tried to shorten the title of this bug (and correct a typo: cannon -> cannot) but I ran into a bug with the debbugs software. I'm trying to correct the title. -Mike [1] http://bugs.x2go.org/Developer.html#severities On Mon, Sep 15, 2014 at 1:26 AM, George Trakatelis wrote: > Dear Mike, > > I have built libssh 0.6.3 in Visual Studio 2013 (with UNICODE and _UNICOD= E defined in all projects) > and debugged a tiny test app with function calls analogous to those used = in x2goclient. > I'm afraid preprocessor definitions are not enough to make an application= /program/library support Unicode. > One could migrate existing programs following a list of guidelines > > http://msdn.microsoft.com/en-us/library/cc194801.aspx > > For example, a function that fails in libssh (used in ssh_path_expand_til= de(), > which is always called to replace a ~ with the actual home folder path in= a string) is strdup. > To make libssh unicode-friendly strdup has to be replaced by _strdup > > http://msdn.microsoft.com/en-us/library/y471khhc.aspx > > _strdup would benefit from preprocessor definitions for Unicode support > as it would be converted to the proper Unicode function. > > Imho, the only option for now is patch "bug566.test.v2.patch" > as it corrects the problem in the vast majority of Windows installations. > Remember that foreign Windows installations set by default the > "Language for non-Unicode programs" to that particular foreign language. > > -George > > -----Original Message----- > From: Michael DePaulo [mailto:mikedep333@gmail.com] > Sent: Tuesday, September 9, 2014 4:16 PM > To: 566@bugs.x2go.org > Cc: George Trakatelis; Mike Gabriel > Subject: Re: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot c= reate C:\Users\\ssh\known_hosts file when the local Windows accou= nt username has non-Ascii characters > > [...] > > Hi Mike#1 and George, > > 1. > > I believe the best approach is to try to compile libssh with unicode supp= ort, and pass unicode values to it. There is no guarantee that a user's use= rname (and home dir path) is in the same language as the language that is s= et for non-Unicode programs. After all, the "Language for non-Unicode progr= ams" is called the "system locale", it applies to all users on the system. > > If we have to for the 4.0.3.0 release of x2goclient, we should fix this b= ug for the system locale only, and then fix the bug for all languages/local= es later. > > 2. > > See bug 474 for George's patch for compiling libssh with MinGW 4.8.2. > It worked :) > > 3. > > I made some progress compiling libssh 0.6.3 with Unicode support. > > With MinGW 4.4, when I specified the following values in CMAKE, libssh bu= ilt successfully, but it did not seem to change anything. > CMAKE_EXE_LINKER_FLAGS:STRING=3D-municode > CMAKE_MODULE_LINKER_FLAGS:STRING=3D-municode > CMAKE_SHARED_LINKER_FLAGS:STRING=3D-municode > CMAKE_STATIC_LINKER_FLAGS:STRING=3D-municode > > With MinGW 4.8.2, when I specify those values, libssh fails to build. > I've attached the output. > > This is a positive sign because it implies that MinGW 4.8.2 supports -mun= icode, whereas MinGW 4.4 did not. > > I plan to try to resolve this build failure later tonight. > > -Mike#2 >