X2Go Bug report logs - #1393
sftp-server binary not found gentoo (profile 17.1)

version graph

Package: x2goclient; Maintainer for x2goclient is X2Go Developers <x2go-dev@lists.x2go.org>; Source for x2goclient is src:x2goclient.

Reported by: Tobias Ehrig <me@t0by.eu>

Date: Tue, 18 Jun 2019 07:20:02 UTC

Severity: normal

Tags: pending

Found in version 4.1.2.1

Fixed in version 4.1.2.2

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to x2go-dev@lists.x2go.org, owner@bugs.x2go.org:
Bug#1393; Package net-misc/x2goclient. (Tue, 18 Jun 2019 07:20:02 GMT) (full text, mbox, link).


Acknowledgement sent to Tobias Ehrig <me@t0by.eu>:
New Bug report received and forwarded. Copy sent to owner@bugs.x2go.org. (Tue, 18 Jun 2019 07:20:02 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Tobias Ehrig <me@t0by.eu>
To: submit@bugs.x2go.org
Subject: sftp-server binary not found gentoo (profile 17.1)
Date: Tue, 18 Jun 2019 09:12:48 +0200
Package: net-misc/x2goclient
Version: 4.1.2.1

On Gentoo (eselect profile 17.1) the x2goclient can't find the binary
sftp-server which is located at

/usr/lib64/misc/sftp-server


Here is a patch

diff --git a/x2goclient-4.1.2.1/src/onmainwindow.cpp b/x2goclient-
4.1.2.1/src/onmainwindow.cpp
index 405b124..16eeeb5 100644
--- a/x2goclient-4.1.2.1/src/onmainwindow.cpp
+++ b/x2goclient-4.1.2.1/src/onmainwindow.cpp
@@ -10444,6 +10444,7 @@ void ONMainWindow::generateEtcFiles()
                      << "/usr/lib/ssh" /* Mageia, OpenSUSE, SLE{S,D} <
12 x86, SLE{S,D} 12, Arch */
                      << "/usr/lib64/ssh" /* SLE{S,D} < 12 x86_64 */
                      << "/usr/lib/misc" /* Gentoo */
+                     << "/usr/lib64/misc" /* Gentoo 17.1 x64 */
                      << "/usr/libexec"; /* Slackware, OS X */
 
 #if QT_VERSION < 0x050000



Information forwarded to x2go-dev@lists.x2go.org, owner@bugs.x2go.org:
Bug#1393; Package net-misc/x2goclient. (Tue, 18 Jun 2019 09:15:01 GMT) (full text, mbox, link).


Acknowledgement sent to Mihai Moldovan <ionic@ionic.de>:
Extra info received and forwarded to list. Copy sent to owner@bugs.x2go.org. (Tue, 18 Jun 2019 09:15:02 GMT) (full text, mbox, link).


Message #10 received at 1393@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>
To: Tobias Ehrig <me@t0by.eu>, 1393@bugs.x2go.org
Subject: Re: [X2Go-Dev] Bug#1393: sftp-server binary not found gentoo (profile 17.1)
Date: Tue, 18 Jun 2019 11:04:31 +0200
[Message part 1 (text/plain, inline)]
Control: reassign -1 x2goclient

* On 6/18/19 9:12 AM, Tobias Ehrig wrote:
> Package: net-misc/x2goclient
> Version: 4.1.2.1
> 
> On Gentoo (eselect profile 17.1) the x2goclient can't find the binary
> sftp-server which is located at
> 
> /usr/lib64/misc/sftp-server
> 
> 
> Here is a patch

I was inclined to NAK this at first.

/usr/lib on a multilib Gentoo system is typically a symlink to /usr/lib64, while
on non-multilib systems, as far as I remember, it's just a normal directory
containing all library files.

The entry containing /usr/lib/misc should hence cover your use case as well. Did
the 17.1 profile remove the /usr/lib symlink? I'm currently still on 17.0, but
it looks like the whole point of 17.1 is to remove the compat symlink, so you
seem to be on the right track.


I think I'll apply a slightly modified patch that favors /usr/lib64/misc instead
(mostly because that's the more common arch now, we want to avoid calling 32-bit
binaries on 64-bit systems even if they are installed and it's highly unlikely
to have a 32-64-bit multilib system [i.e., main system 32-bit, with 64-bit as an
additional architecture]).



Mihai

[signature.asc (application/pgp-signature, attachment)]

Bug reassigned from package 'net-misc/x2goclient' to 'x2goclient'. Request was from Mihai Moldovan <ionic@ionic.de> to 1393-submit@bugs.x2go.org. (Tue, 18 Jun 2019 09:15:02 GMT) (full text, mbox, link).


No longer marked as found in versions 4.1.2.1. Request was from Mihai Moldovan <ionic@ionic.de> to 1393-submit@bugs.x2go.org. (Tue, 18 Jun 2019 09:15:02 GMT) (full text, mbox, link).


Marked as found in versions 4.1.2.1. Request was from Mihai Moldovan <ionic@ionic.de> to control@bugs.x2go.org. (Tue, 18 Jun 2019 09:35:01 GMT) (full text, mbox, link).


Information forwarded to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>:
Bug#1393; Package x2goclient. (Tue, 18 Jun 2019 09:40:02 GMT) (full text, mbox, link).


Acknowledgement sent to Mihai Moldovan <ionic@ionic.de>:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>. (Tue, 18 Jun 2019 09:40:03 GMT) (full text, mbox, link).


Message #21 received at 1393@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>
To: 1393-submitter@bugs.x2go.org
Cc: control@bugs.x2go.org, 1393@bugs.x2go.org
Subject: X2Go issue (in src:x2goclient) has been marked as pending for release
Date: Tue, 18 Jun 2019 11:39:35 +0200 (CEST)
tag #1393 pending
fixed #1393 4.1.2.2
thanks

Hello,

X2Go issue #1393 (src:x2goclient) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:

    http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=567223f

The issue will most likely be fixed in src:x2goclient (4.1.2.2).

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
commit 567223f5b55fb0398322f01cb0f158da6eb2a524
Author: Mihai Moldovan <ionic@ionic.de>
Date:   Tue Jun 18 11:38:29 2019 +0200

    src/onmainwindow.cpp: add (and prefer) non-compat-symlink scp server location for 64-bit-based Gentoo distros (17.1+ profiles).
    
    Fixes: #1393.

diff --git a/debian/changelog b/debian/changelog
index 284692b..ed1b3ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -102,6 +102,9 @@ x2goclient (4.1.2.2-0x2go1) UNRELEASED; urgency=medium
       version available in EPEL 6.
     - src/onmainwindow.cpp: unbreak builds by fixing syntax error.
     - src/onmainwindow.cpp: also unbreak old EPEL 6 builds.
+    - src/onmainwindow.cpp: add (and prefer) non-compat-symlink scp server
+      location for 64-bit-based Gentoo distros (17.1+ profiles). Fixes:
+      #1393.
   * debian/control:
     + Add build-depend on pkg-config.
   * x2goclient.spec:


Added tag(s) pending. Request was from Mihai Moldovan <ionic@ionic.de> to control@bugs.x2go.org. (Tue, 18 Jun 2019 09:40:03 GMT) (full text, mbox, link).


Marked as fixed in versions 4.1.2.2. Request was from Mihai Moldovan <ionic@ionic.de> to control@bugs.x2go.org. (Tue, 18 Jun 2019 09:40:03 GMT) (full text, mbox, link).


Message sent on to Tobias Ehrig <me@t0by.eu>:
Bug#1393. (Tue, 18 Jun 2019 09:40:03 GMT) (full text, mbox, link).


Information forwarded to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>:
Bug#1393; Package x2goclient. (Tue, 18 Jun 2019 13:40:02 GMT) (full text, mbox, link).


Acknowledgement sent to Lars Wendler <polynomial-c@gentoo.org>:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>. (Tue, 18 Jun 2019 13:40:02 GMT) (full text, mbox, link).


Message #33 received at 1393@bugs.x2go.org (full text, mbox, reply):

From: Lars Wendler <polynomial-c@gentoo.org>
To: Mihai Moldovan <ionic@ionic.de>
Cc: 1393@bugs.x2go.org, Tobias Ehrig <me@t0by.eu>, voyageur@gentoo.org
Subject: Re: [X2Go-Dev] Bug#1393: Bug#1393: sftp-server binary not found gentoo (profile 17.1)
Date: Tue, 18 Jun 2019 15:27:11 +0200
[Message part 1 (text/plain, inline)]
Hello,

On Tue, 18 Jun 2019 11:04:31 +0200 Mihai Moldovan wrote:

>Control: reassign -1 x2goclient
>
>* On 6/18/19 9:12 AM, Tobias Ehrig wrote:
>> Package: net-misc/x2goclient
>> Version: 4.1.2.1
>> 
>> On Gentoo (eselect profile 17.1) the x2goclient can't find the binary
>> sftp-server which is located at
>> 
>> /usr/lib64/misc/sftp-server
>> 
>> 
>> Here is a patch  
>
>I was inclined to NAK this at first.
>
>/usr/lib on a multilib Gentoo system is typically a symlink
>to /usr/lib64, while on non-multilib systems, as far as I remember,
>it's just a normal directory containing all library files.

IMHO you should NAK such a patch as this is definitely an issue coming
from our 17.1 profile's new lib directory structure.
If you commit the suggested patch, all 32bit 17.1 profile installations
will suffer from the bug our 64bit 17.1 profile installations currently
suffer from.


>The entry containing /usr/lib/misc should hence cover your use case as
>well. Did the 17.1 profile remove the /usr/lib symlink? I'm currently
>still on 17.0, but it looks like the whole point of 17.1 is to remove
>the compat symlink, so you seem to be on the right track.

We changed the following directories on 64bit arches with the 17.1
profile:

17.0:

# ls -ld /lib*
lrwxrwxrwx 1 root root    5 May 17 10:24 /lib -> lib64
drwxr-xr-x 1 root root 1174 May 17 10:26 /lib32
drwxr-xr-x 1 root root 5078 Jun 13 18:50 /lib64


17.1:

# ls -ld /lib*
drwxr-xr-x 1 root root 1382 May 13 22:54 /lib
drwxr-xr-x 1 root root 5340 Jun 18 10:23 /lib64


As you can see, "lib32" became "lib" and "lib" is no longer a symlink
pointing to "lib64".

My suggestion is to let the Gentoo package maintainers handle this in
the affected x2go package's ebuild files. We have a function called
"get_libdir" that can be used with sed to set the correct lib dir
name in the affected code. 

>I think I'll apply a slightly modified patch that
>favors /usr/lib64/misc instead (mostly because that's the more common
>arch now, we want to avoid calling 32-bit binaries on 64-bit systems
>even if they are installed and it's highly unlikely to have a
>32-64-bit multilib system [i.e., main system 32-bit, with 64-bit as an
>additional architecture]).
>
>
>
>Mihai
>

Kind regards

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>:
Bug#1393; Package x2goclient. (Wed, 19 Jun 2019 10:55:02 GMT) (full text, mbox, link).


Acknowledgement sent to Mihai Moldovan <ionic@ionic.de>:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>. (Wed, 19 Jun 2019 10:55:02 GMT) (full text, mbox, link).


Message #38 received at 1393@bugs.x2go.org (full text, mbox, reply):

From: Mihai Moldovan <ionic@ionic.de>
To: Lars Wendler <polynomial-c@gentoo.org>
Cc: 1393@bugs.x2go.org, Tobias Ehrig <me@t0by.eu>, voyageur@gentoo.org
Subject: Re: Bug#1393: sftp-server binary not found gentoo (profile 17.1)
Date: Wed, 19 Jun 2019 12:52:18 +0200
[Message part 1 (text/plain, inline)]
* On 6/18/19 3:27 PM, Lars Wendler wrote:
> IMHO you should NAK such a patch as this is definitely an issue coming
> from our 17.1 profile's new lib directory structure.
> If you commit the suggested patch, all 32bit 17.1 profile installations
> will suffer from the bug our 64bit 17.1 profile installations currently
> suffer from.

Can you elaborate on that, please? I understand that there's potential for
breakage with a compat symlink. One example would be software that is not
correctly trimmed to using lib32 instead of lib and hence trying to use the
wrong, 64-bit, directory at compile time, unless additional patching is done.

I fail to see a lot of breakage potential with the current patch I applied that
favors lib64. Let's create a matrix:

 System | 32-bit OpenSSH installed | 64-bit OpenSSH installed | [G]ood/[B]ad
--------+--------------------------+--------------------------+---------------
{32}    |           X              |             -            |       G
{32}    |           -              |             X            | B (nonsense)
{32}    |           X              |             X            | B (nonsense?)
{64}    |           X              |             -            | B (nonsense)
{64}    |           -              |             X            |       G
{64}    |           X              |             X            | G (nonsense?)
{32,64} |           X              |             -            |       G
{32,64} |           -              |             X            |       B
{64,32} |           X              |             -            |       B
{64,32} |           -              |             X            |       G
{64,32} |           X              |             X            | G (nonsense?)

The failure cases are pretty rare and mostly boil down to users messing up their
system - for instance, why would anyone install a 64-bit version of OpenSSH on a
32-bit non-multilib system? The only cases that would be bad is having a 32-bit
OpenSSH version installed on a {64,32} multilib system or a 64-bit OpenSSH
version on a {32,64} multilib system - i.e., when the installed OpenSSH version
does *not* match the primary arch. These cases should be very rare and indicate
a hosed system to begin with.

Additionally, none of these failure cases are actually fatal. A 32-bit OpenSSH
sftp-server binary should work fine on a 64-bit system. As long as we actually
find a binary, we should be mostly good to go.


> We changed the following directories on 64bit arches with the 17.1
> profile:
> 
> 17.0:
> 
> # ls -ld /lib*
> lrwxrwxrwx 1 root root    5 May 17 10:24 /lib -> lib64
> drwxr-xr-x 1 root root 1174 May 17 10:26 /lib32
> drwxr-xr-x 1 root root 5078 Jun 13 18:50 /lib64
> 
> 
> 17.1:
> 
> # ls -ld /lib*
> drwxr-xr-x 1 root root 1382 May 13 22:54 /lib
> drwxr-xr-x 1 root root 5340 Jun 18 10:23 /lib64
> 
> 
> As you can see, "lib32" became "lib" and "lib" is no longer a symlink
> pointing to "lib64".

Hmm, that's just nitpicking maybe and too late for any change now that the
profile went on to be stable, but I don't get why lib32 was renamed to lib.
Wouldn't it have been better to just keep lib32 and lib64 around (which
describes both directories's purpose vividly) and just remove the compat
symlink? Just using "lib" is ambiguous and can be confusing.


> My suggestion is to let the Gentoo package maintainers handle this in
> the affected x2go package's ebuild files. We have a function called
> "get_libdir" that can be used with sed to set the correct lib dir
> name in the affected code.

I could implement a Makefile variable that is being passed down via CFLAGS (no
sed hackery) and add it as the first option. I'd like to keep the fallback list,
though. Not sure if that would actually be really useful to anyone, though.



Mihai

[0] {primary arch,secondary arch}

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to x2go-dev@lists.x2go.org, X2Go Developers <x2go-dev@lists.x2go.org>:
Bug#1393; Package x2goclient. (Wed, 19 Jun 2019 11:35:02 GMT) (full text, mbox, link).


Acknowledgement sent to Lars Wendler <polynomial-c@gentoo.org>:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.x2go.org>. (Wed, 19 Jun 2019 11:35:02 GMT) (full text, mbox, link).


Message #43 received at 1393@bugs.x2go.org (full text, mbox, reply):

From: Lars Wendler <polynomial-c@gentoo.org>
To: Mihai Moldovan <ionic@ionic.de>
Cc: 1393@bugs.x2go.org, Tobias Ehrig <me@t0by.eu>, voyageur@gentoo.org
Subject: Re: Bug#1393: sftp-server binary not found gentoo (profile 17.1)
Date: Wed, 19 Jun 2019 13:30:16 +0200
[Message part 1 (text/plain, inline)]
On Wed, 19 Jun 2019 12:52:18 +0200 Mihai Moldovan wrote:

>* On 6/18/19 3:27 PM, Lars Wendler wrote:
>> IMHO you should NAK such a patch as this is definitely an issue
>> coming from our 17.1 profile's new lib directory structure.
>> If you commit the suggested patch, all 32bit 17.1 profile
>> installations will suffer from the bug our 64bit 17.1 profile
>> installations currently suffer from.  
>
>Can you elaborate on that, please? I understand that there's potential
>for breakage with a compat symlink. One example would be software that
>is not correctly trimmed to using lib32 instead of lib and hence
>trying to use the wrong, 64-bit, directory at compile time, unless
>additional patching is done.

I was reading the suggested patch wrong. I thought it
replaces /usr/lib/misc with /usr/lib64/misc bit I just saw that the
latter path was rather added to the list.

>I fail to see a lot of breakage potential with the current patch I
>applied that favors lib64. Let's create a matrix:
>
> System | 32-bit OpenSSH installed | 64-bit OpenSSH installed |
> [G]ood/[B]ad
>--------+--------------------------+--------------------------+---------------
>{32}    |           X              |             -            |       G
>{32}    |           -              |             X            | B
>(nonsense) {32}    |           X              |
>X            | B (nonsense?) {64}    |           X
>|             -            | B (nonsense) {64}    |
>-              |             X            |       G {64}
>|           X              |             X            | G (nonsense?)
>{32,64} |           X              |             -            |
>G {32,64} |           -              |             X
>|       B {64,32} |           X              |
>-            |       B {64,32} |           -
>|             X            |       G {64,32} |
>X              |             X            | G (nonsense?)
>
>The failure cases are pretty rare and mostly boil down to users
>messing up their system - for instance, why would anyone install a
>64-bit version of OpenSSH on a 32-bit non-multilib system? The only
>cases that would be bad is having a 32-bit OpenSSH version installed
>on a {64,32} multilib system or a 64-bit OpenSSH version on a {32,64}
>multilib system - i.e., when the installed OpenSSH version does *not*
>match the primary arch. These cases should be very rare and indicate a
>hosed system to begin with.
>
>Additionally, none of these failure cases are actually fatal. A 32-bit
>OpenSSH sftp-server binary should work fine on a 64-bit system. As
>long as we actually find a binary, we should be mostly good to go.
>
>
>> We changed the following directories on 64bit arches with the 17.1
>> profile:
>> 
>> 17.0:
>> 
>> # ls -ld /lib*
>> lrwxrwxrwx 1 root root    5 May 17 10:24 /lib -> lib64
>> drwxr-xr-x 1 root root 1174 May 17 10:26 /lib32
>> drwxr-xr-x 1 root root 5078 Jun 13 18:50 /lib64
>> 
>> 
>> 17.1:
>> 
>> # ls -ld /lib*
>> drwxr-xr-x 1 root root 1382 May 13 22:54 /lib
>> drwxr-xr-x 1 root root 5340 Jun 18 10:23 /lib64
>> 
>> 
>> As you can see, "lib32" became "lib" and "lib" is no longer a symlink
>> pointing to "lib64".  
>
>Hmm, that's just nitpicking maybe and too late for any change now that
>the profile went on to be stable, but I don't get why lib32 was
>renamed to lib. Wouldn't it have been better to just keep lib32 and
>lib64 around (which describes both directories's purpose vividly) and
>just remove the compat symlink? Just using "lib" is ambiguous and can
>be confusing.

IIRC it was an attempt to remove the lib symlinks. Unfortunately I
haven't found the original post about why that change was introduced
anymore or why it was done this way. All I can remember is some talking
about "other distros are doing it likewise".

>
>> My suggestion is to let the Gentoo package maintainers handle this in
>> the affected x2go package's ebuild files. We have a function called
>> "get_libdir" that can be used with sed to set the correct lib dir
>> name in the affected code.  
>
>I could implement a Makefile variable that is being passed down via
>CFLAGS (no sed hackery) and add it as the first option. I'd like to
>keep the fallback list, though. Not sure if that would actually be
>really useful to anyone, though.

Not necessary. If both paths are present I suppose there will be no
more regressions.

>Mihai
>
>[0] {primary arch,secondary arch}
>

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39
[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


X2Go Developers <owner@bugs.x2go.org>. Last modified: Fri Sep 20 03:40:48 2019; Machine Name: ymir.das-netzwerkteam.de

X2Go Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.