From polynomial-c@gentoo.org Wed Jun 19 13:30:42 2019 Received: (at 1393) by bugs.x2go.org; 19 Jun 2019 11:30:45 +0000 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 To: Mihai Moldovan Cc: 1393@bugs.x2go.org, Tobias Ehrig , 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" --Sig_/ldTnziEpBsJgb2yKudBFsNx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. =20 > >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: >>=20 >> 17.0: >>=20 >> # 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 >>=20 >>=20 >> 17.1: >>=20 >> # 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 >>=20 >>=20 >> As you can see, "lib32" became "lib" and "lib" is no longer a symlink >> pointing to "lib64". =20 > >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. =20 > >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 --=20 Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 --Sig_/ldTnziEpBsJgb2yKudBFsNx Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWCOBmo8i7LhvVmNAVx3S0DQ8YDkFAl0KHMgACgkQVx3S0DQ8 YDkItg/+P7oinAk3BLPAp7vVvJNof496WaPlX4AsOHsb5fwGTDv1uT9Ll8ssRTxh kiRE7yxcYyCSX4kC2GtasBJ4NjBYYvFt4JADjrTboLaI4fqXNWSRa35eOIJQozab KABobIO36o888g9oEPnFkfV9MaN8sMOgXPIUMkmUXHMNaPckkcXmBRWQmJ4yut0i p0+4BtEUZi4ztKquQjYzJJ/CGnmIXkEpMsQCC1x4pHYZZ/Z6lDYZVMJfgDBxNc7u c5PpelzceSXlKIRPG1ojlSQ/c6fVJJ9yJyqml1uXt8kqoMgoOaEBzatkTdcnQ++u Q9vw5/H5OJ/3w+L/6KcjqqIWr1Zvr4HeeHW83w5PuRxxWb5zLXcDgyWE2UHDmQRZ M6W+6mJY7Mjy/Vzw4+bJRKYf5tF6Cpf2E/fN4md1M7QkmKlcECJ0JAw0ERzAwv0k nEhZV7u9SS9mGdsgZICqSV+Fok2HndHtgcegIonFZTYTf7sU210xW32S1OlBgF7b DwdqT58sQpxBexnp+VN/gWCA/6PrkQE04czj056U6/I++d7XPTZxLLLxhqXCOqNX iOdWzHmp3MuwGjPhQ5oFINOMpCYc1robtuwqBBKQ3sRakIvu9OiT+VwaX+E1XA+v VtW5FKXTkn4rZBGZMlryZ+7AJJ9Gw5IvuYV7GC7s/BvQtEAezM0= =j5dJ -----END PGP SIGNATURE----- --Sig_/ldTnziEpBsJgb2yKudBFsNx--