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

Full log

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

Received: (at 1393) by bugs.x2go.org; 19 Jun 2019 11:30:45 +0000
From polynomial-c@gentoo.org  Wed Jun 19 13:30:42 2019
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,SPF_HELO_PASS
	autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (localhost [127.0.0.1])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 9775F5DAEA
	for <1393@bugs.x2go.org>; Wed, 19 Jun 2019 13:30:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de
Received: from ymir.das-netzwerkteam.de ([127.0.0.1])
	by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id hP0DA4aWddgR for <1393@bugs.x2go.org>;
	Wed, 19 Jun 2019 13:30:36 +0200 (CEST)
X-Greylist: delayed 79388 seconds by postgrey-1.35 at ymir.das-netzwerkteam.de; Wed, 19 Jun 2019 13:30:32 CEST
Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id A9AB25DAF4
	for <1393@bugs.x2go.org>; Wed, 19 Jun 2019 13:30:31 +0200 (CEST)
Received: from abudhabi.paradoxon.rec (p54A9DFFB.dip0.t-ipconnect.de [84.169.223.251])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: polynomial-c)
	by smtp.gentoo.org (Postfix) with ESMTPSA id 33B913464A5;
	Wed, 19 Jun 2019 11:30:27 +0000 (UTC)
Date: Wed, 19 Jun 2019 13:30:16 +0200
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)
Message-ID: <20190619133016.42d8adb1@abudhabi.paradoxon.rec>
In-Reply-To: <513afe70-9488-eb94-4bbb-351aa268be3d@ionic.de>
References: <6f820bb96ef55175c50465dbaa2d98408f1b598c.camel@t0by.eu>
	<10915935-0dfc-e0f2-9db2-41058a5f1a3d@ionic.de>
	<20190618152711.2f05b797@abudhabi.paradoxon.rec>
	<513afe70-9488-eb94-4bbb-351aa268be3d@ionic.de>
Organization: Gentoo
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 boundary="Sig_/ldTnziEpBsJgb2yKudBFsNx"; protocol="application/pgp-signature"

[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.