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
Control: reassign -1 x2goclient
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
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
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}
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 | X | G (nonsense?) {32,64} | X | - | G {32,64} | - | X | B {64,32} | X || X | G {64}
| X | G {64,32} | X | X | G (nonsense?)| B {64,32} | -
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
Processing control commands:
reassign -1 x2goclient Bug #1393 [net-misc/x2goclient] sftp-server binary not found gentoo (profile 17.1) Warning: Unknown package 'net-misc/x2goclient' Bug reassigned from package 'net-misc/x2goclient' to 'x2goclient'. No longer marked as found in versions 4.1.2.1. Ignoring request to alter fixed versions of bug #1393 to the same values previously set
-- 1393: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1393 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
close #1393 thanks
Hello,
we are very hopeful that X2Go issue #1393 reported by you has been resolved in the new release (4.1.2.2) of the X2Go source project »src:x2goclient«.
You can view the complete changelog entry of src:x2goclient (4.1.2.2) below, and you can use the following link to view all the code changes between this and the last release of src:x2goclient.
http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=e70a27961cf391406c13e52fa54f4731fa8ca189;hp=84dcac55b72c6c09f2cdddcd5bde5137a441223d
If you feel that the issue has not been resolved satisfyingly, feel free to reopen this bug report or submit a follow-up report with further observations described based on the new released version of src:x2goclient.
Thanks a lot for contributing to X2Go!!!
light+love X2Go Git Admin (on behalf of the sender of this mail)
X2Go Component: src:x2goclient Version: 4.1.2.2-0x2go1 Status: RELEASE Timestamp: 1581543720 Date: Wed, 12 Feb 2020 22:42:00 +0100 Fixes: 1307 1320 1393 1418 1425 1428 Changes: x2goclient (4.1.2.2-0x2go1) RELEASED; urgency=medium . [ Oleksandr Shneyder ]
Processing commands for control@bugs.x2go.org:
close #1393 Bug #1393 [x2goclient] sftp-server binary not found gentoo (profile 17.1) Marked Bug as done thanks Stopping processing here.
1393: bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1393 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems