Summary: | Snap packages of KDE apps don't work on RHEL 7 | ||
---|---|---|---|
Product: | [KDE Neon] neon | Reporter: | scx.mail |
Component: | Snaps | Assignee: | Scarlett Moore <sgmoore> |
Status: | CONFIRMED --- | ||
Severity: | crash | CC: | ivo.cavalcante, jr, me, neon-bugs, scx.mail, sgmoore |
Priority: | NOR | Keywords: | regression |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://snapcraft.io/kde-frameworks-5-core18 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
scx.mail
2020-02-17 14:49:34 UTC
Do other KDE packages work such as kolourpaint? What happens if you run snap run cantor (In reply to Jonathan Riddell from comment #2) > Do other KDE packages work such as kolourpaint? No, kolourpaint is affected as well. $ /var/lib/snapd/snap/bin/kolourpaint kolourpaint: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory $ /snap/bin/kolourpaint kolourpaint: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory It seems to me that for some reasons snap's "connections" are broken on EL7. Or at least cantor:kde-frameworks-5-plug kde-frameworks-5-core18:kde-frameworks-5-core18-slot doesn't work as expected. https://bugs.launchpad.net/snapd/+bug/1863642/comments/2 (In reply to Jonathan Riddell from comment #3) > What happens if you run > snap run cantor The same error: $ snap run cantor cantor: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory I have an another theory! Is it possible that the kde-frameworks-5-core18:kde-frameworks-5-core18-slot slot is not mounted because it is not compatible with the system? Let's look at the Qt5 libs that it provides: $ find /var/lib/snapd/snap/kde-frameworks-5-core18 -xtype f -iname 'libQt5Core.so.5*' 2>/dev/null | xargs -I{} file '{}' /var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: symbolic link to `libQt5Core.so.5.12.3' /var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12: symbolic link to `libQt5Core.so.5.12.3' /var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=252fcd9f736251377f96e559b953f9cb4b8fbdec, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: symbolic link to `libQt5Core.so.5.12.3' /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12: symbolic link to `libQt5Core.so.5.12.3' /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=2742584b062a7248211733fb8a9365897d2db95a, for GNU/Linux 3.17.0, stripped As you can see, they are built for Linux 3.17.0. EL7, however, uses Linux 3.10.0-1062 by default (highly modified 3.10.0). $ uname -r 3.10.0-1062.9.1.el7.x86_64 The best way to check this would be using kernel-lt or kernel-lt from ELRepo. https://elrepo.org/tiki/kernel-lt https://elrepo.org/tiki/kernel-ml Actually, we've already hit a very similar problem with Flatpak in Jan 2019. https://github.com/flathub/flathub/issues/805 https://bugs.kde.org/show_bug.cgi?id=403042 As you can see, Debian 8 and Ubuntu 14.04 LTS should be affected as well. Anyway, neither core18, nor cantor itself should be a problem here. $ file /var/lib/snapd/snap/core18/current/lib/x86_64-linux-gnu/libc-2.27.so /var/lib/snapd/snap/core18/current/lib/x86_64-linux-gnu/libc-2.27.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=b417c0ba7cc5cf06d1d1bed6652cedb9253c60d0, for GNU/Linux 3.2.0, stripped $ file /var/lib/snapd/snap/cantor/current/usr/bin/cantor /var/lib/snapd/snap/cantor/current/usr/bin/cantor: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=7c98f936a4d8ccd35cda1c62e128c9d66e8c16d9, not stripped As you can see, they are built for Linux 3.2.0. Qt5, however, may use getentropy, so it requires Linux 3.17.0. https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/minimum-linux_p.h?id=4d9ac14bf8d1c1a33a2720c7f7dcaf8d912a592f#n77 However, it should be possible to build Qt5 without this feature. https://phabricator.kde.org/R257:a029f2957e947f6e32fe8a595edb0ac553654e90 Although I'm not completely sure, I think that rebuilding kde-frameworks-5-core18:kde-frameworks-5-core18-slot without getentropy should enough to fix it. Can you handle this? Just make sure that Qt5 won't use renameat2 neither, because it requires Linux 3.16. I can confirm that the following snaps are affected: - kde-frameworks-5-core18 - kde-frameworks-5-core18-sdk - kde-frameworks-5-qt-5-14-core18 - kde-frameworks-5-qt-5-14-core18-sdk $ find -L /var/lib/snapd/snap/kde-frameworks-5*/*/usr/lib/*-linux-gnu -type f -iname 'libQt5Core.so*' -print0 2>/dev/null | xargs -0 -I{} file '{}' | grep -Z 'ELF' | grep -Z 'for GNU/Linux ' | sort -z -fuV | grep -Z -Eva 'for GNU/Linux (2\.6\.[0-9]+|3\.2\.0)' /var/lib/snapd/snap/kde-frameworks-5-core18/30/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=252fcd9f736251377f96e559b953f9cb4b8fbdec, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=2742584b062a7248211733fb8a9365897d2db95a, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-core18/current/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=2742584b062a7248211733fb8a9365897d2db95a, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-core18-sdk/31/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=2742584b062a7248211733fb8a9365897d2db95a, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-core18-sdk/current/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.3: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=2742584b062a7248211733fb8a9365897d2db95a, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-qt-5-14-core18/1/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.14.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=71f6b46001655493cfef4fabf3a1afdea055f0af, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-qt-5-14-core18/current/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.14.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=71f6b46001655493cfef4fabf3a1afdea055f0af, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-qt-5-14-core18-sdk/1/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.14.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=71f6b46001655493cfef4fabf3a1afdea055f0af, for GNU/Linux 3.17.0, stripped /var/lib/snapd/snap/kde-frameworks-5-qt-5-14-core18-sdk/current/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.14.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=71f6b46001655493cfef4fabf3a1afdea055f0af, for GNU/Linux 3.17.0, stripped However, kde-frameworks-5 is not affected. $ find -L /var/lib/snapd/snap/kde-frameworks-5*/*/usr/lib/*-linux-gnu -type f -iname 'libQt5Core.so*' -print0 2>/dev/null | xargs -0 -I{} file '{}' | grep -Z 'ELF' | grep -Z 'for GNU/Linux ' | sort -z -fuV | grep -Z -Ea 'for GNU/Linux (2\.6\.[0-9]+|3\.2\.0)' /var/lib/snapd/snap/kde-frameworks-5/27/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=5e10a9ca057fb0497637959a6df4d07bfd8e9173, for GNU/Linux 2.6.28, stripped /var/lib/snapd/snap/kde-frameworks-5/current/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), BuildID[sha1]=5e10a9ca057fb0497637959a6df4d07bfd8e9173, for GNU/Linux 2.6.28, stripped (In reply to scx.mail from comment #7) > Is it possible that the kde-frameworks-5-core18:kde-frameworks-5-core18-slot > slot is not mounted because it is not compatible with the system? Actually, it may be mounted and incompatible libs will be still invisible - as if they didn't exist at all. https://github.com/flathub/flathub/issues/805#issue-397165614 https://bugs.kde.org/show_bug.cgi?id=403042#c0 (In reply to Jonathan Riddell from comment #3) Where is the snap repo for KDE apps (e.g. cantor, kolourpaint, okular, etc.) and runtimes (kde-frameworks-5, kde-frameworks-5-core18, kde-frameworks-5-core18-sdk, kde-frameworks-5-qt-5-14-core18, kde-frameworks-5-qt-5-14-core18-sdk)? I don't see the snap folder in app repositories. https://cgit.kde.org/cantor.git/tree/ What is worse, I don't see kde-frameworks-5* repos at all. Most of the KDE snaps get made in Neon and the snapcraft.yaml files are in neon git branches (all KDE devs have access to these too) https://packaging.neon.kde.org/kde/kolourpaint.git/tree/?h=Neon/release https://build.neon.kde.org/view/Snaps/ The kde-frameworks snaps are made with a fairly complex script that downloads and adds Neon .deb packages for Qt and KF5 etc https://cgit.kde.org/snap-kf5.git/tree/ The Snap devs agree this is a problem and are looking into it. Hi all, Some more Snaps failing on RHEL or RHEL-like version 7 systems, due to this bug. Could you please look into it? It's already been solved in Flatpak, maybe the same solution applies here? https://github.com/flathub/flathub/issues/805#issuecomment-453004369 Can someone with RHEL 7 please test https://snapcraft.io/blinken Much has changed since the last comment. Thank you Scarlett Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! Hello, I'm one of the snapd maintainers in Fedora and EPEL. I just tested several snaps on RHEL 7, running kernel 3.10.0-1160.105.1.el7 with snapd 2.58.3-1.el7 on x86_64 and they all fail on startup due to the use of `clone3` that fails with EPERM. The system call is allowed by the source seccomp profile but is, most likely, not supported by seccomp used in the distribution or by the kernel alike. Migrating "reproducible" keyword to "CONFIRMED" status. |