The source code of KDE Plasma package plasma-firewall 5.21.3 is hard-coded to use systemd. However, plasma-firewall-5.21.3.ebuild does not include a dependency on sys-apps/systemd. Given that kde-plasma/plasma-firewall-5.21.3 is unusable in a Gentoo Linux installation that does not have sys-apps/systemd installed, surely the plasma-firewall-5.21.3 ebuild should declare a dependency on sys-apps/systemd. Reproducible: Always Steps to Reproduce: 1. emerge kde-plasma/plasma-meta-5.21.3 (USE="+firewall") with USE="ufw" or USE="firewalld" in an installation that uses OpenRC+elogind+eudev. 2. Log in to KDE Plasma. 3. Select System Settings in the Plasma Application Menu and click on Firewall in the Network section. Actual Results: Plasma displays an error message indicating it does not find the active service. From the error message it is org.freedesktop.systemd1 See https://forums.gentoo.org/viewtopic-p-8577522.html#8577522 Expected Results: Given that plasma-firewall source code is hard-coded to use sys-apps/systemd, I would have expected Portage to prevent users of an installation that has USE="-systemd" from merging kde-plasma/plasma-meta-5.21.3 which has USE="+firewall", and to inform the user of the required dependency of kde-plasma/plasma-firewall-5.21.3 on sys-apps/systemd.
Without looking at the code in question, the "hard coding" sounds like a D-Bus service not being found. In general it is against Gentoo guidelines to provide USE flags for runtime dependencies that do not affect building of the binary. That having been said, having such warnings can be annoying. And, if it really is not going to work on OpenRC, then kde-plasma/plasma-firewall should be set to have an RDEPEND on sys-apps/systemd.
(In reply to Niklāvs Koļesņikovs from comment #1) > Without looking at the code in question, the "hard coding" sounds like a > D-Bus service not being found. In general it is against Gentoo guidelines to > provide USE flags for runtime dependencies that do not affect building of > the binary. That having been said, having such warnings can be annoying. > And, if it really is not going to work on OpenRC, then > kde-plasma/plasma-firewall should be set to have an RDEPEND on > sys-apps/systemd. The dependency on systemd is more than just a D-Bus service not being found. The hard-coded use of systemd in the firewalld backend is significant - see: https://invent.kde.org/plasma/plasma-firewall/-/tree/master/kcm/backends/firewalld The hard-coded use of systemd in the ufw backend is less extensive than the firewalld backend but still renders the KCM unusable without systemd installed. To give a couple of examples: Excerpt from /kcm/backends/ufw/ufwclient.cpp: bool UfwClient::isCurrentlyLoaded() const { QProcess process; const QString name = "systemctl"; const QStringList args = {"status", "ufw"}; process.start(name, args); process.waitForFinished(); // systemctl returns 0 for status if the app is loaded, and 3 otherwise. qDebug() << "Ufw is loaded?" << (process.exitCode() == EXIT_SUCCESS); return process.exitCode() == EXIT_SUCCESS; } Excerpt from /kcm/backends/ufw/helper/helper.cpp: QStringList getLogFromSystemd(const QString &lastLine) { QString program = "journalctl"; QStringList arguments {"-xb","-n", "100","-g", "UFW"}; QProcess myProcess; myProcess.start(program, arguments); myProcess.waitForFinished(); auto resultString = QString(myProcess.readAllStandardOutput()); auto resultList = resultString.split("\n"); // Example Line from Systemd: // Dec 06 17:42:45 tomatoland kernel: [UFW BLOCK] IN=wlan0 OUT= MAC= SRC=192.168.50.181 DST=224.0.0.252 LEN=56 TOS=0x00 // PREC=0x00 TTL=255 ID=52151 PROTO=UDP SPT=5355 DPT=5355 LEN=36 // We need to remove everything up to the space after ']'. QStringList result; for(const QString& line : resultList) { if (!lastLine.isEmpty() && line == lastLine) { result.clear(); continue; } result.append(line); } return result; } The KDE link above allows detailed inspection of the KCM's source code. The KCM is never going to work on OpenRC, as you can see from the couple of source code excerpts above.
Indeed, unless there's some very dedicated maintainer/developer, the firewalld backend is probably beyond porting to OpenRC. How to proceeding with regard to the Ufw backend and the package as a whole, I'm not really in the position to say. I'd make a PR, adding sys-apps/systemd to RDEPEND, but I suspect that the ebuilds in Portage tree are not the ones from which new versions are made, so there's high chance the changes would get lost. Fow now I'll leave it at this, and see if I can get in touch with people involved, should this bug report not get the attention it deserves. Thank you for reporting this.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=cfdb4d0a485c1373297a59205cba5406680f96dd commit cfdb4d0a485c1373297a59205cba5406680f96dd Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-04-06 10:28:58 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-04-06 10:28:58 +0000 kde-plasma/plasma-firewall: Add sys-apps/systemd to RDEPEND Both firewall backends are currently using systemd functions in code, and there is no solution in sight at least for the Plasma 5.21 cycle. Reported-by: Fitzcarraldo <fitzcarraldo1@hotmail.com> Bug: https://bugs.gentoo.org/778527 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-firewall/plasma-firewall-5.21.49.9999.ebuild | 1 + kde-plasma/plasma-firewall/plasma-firewall-9999.ebuild | 1 + 2 files changed, 2 insertions(+) https://gitweb.gentoo.org/proj/kde.git/commit/?id=32bc4ab698afd21dbf7cf4f3ff418c5a7da03cb1 commit 32bc4ab698afd21dbf7cf4f3ff418c5a7da03cb1 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-04-06 10:25:18 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-04-06 10:25:18 +0000 kde-plasma/plasma-meta: Move IUSE=firewall behind IUSE=systemd Bug: https://bugs.gentoo.org/778527 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-meta/plasma-meta-5.21.49.9999.ebuild | 2 +- kde-plasma/plasma-meta/plasma-meta-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=67ad4966b4cf9b0c6f36bdc94b35f5a738684227 commit 67ad4966b4cf9b0c6f36bdc94b35f5a738684227 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-04-06 13:26:08 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-04-06 14:10:06 +0000 kde-plasma/plasma-firewall: 5.21.4 version bump Closes: https://bugs.gentoo.org/778527 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-firewall/Manifest | 1 + .../plasma-firewall/plasma-firewall-5.21.4.ebuild | 50 ++++++++++++++++++++++ 2 files changed, 51 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=62a723a36278a0f613ec8c88144df9560e9a83ba commit 62a723a36278a0f613ec8c88144df9560e9a83ba Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-05-09 11:52:09 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-05-09 12:10:15 +0000 kde-plasma/plasma-firewall: Replace systemd RDEPEND w/ postinst ewarn For administrative reasons we can't have a package pulling in systemd, this would render it essentially unsupported. Instead make clear that it will not work properly. Whoever wants to install/play around with it on openrc can now do so with that roadblock removed. Bug: https://bugs.gentoo.org/778527 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-firewall/plasma-firewall-5.21.5.ebuild | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fefd1ea8b2f03d4c33e31b845f0da98d650bbc94 commit fefd1ea8b2f03d4c33e31b845f0da98d650bbc94 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-05-09 09:41:21 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-05-09 12:10:15 +0000 profiles: targets/systemd: Unmask kde-plasma/plasma-meta[firewall] Bug: https://bugs.gentoo.org/778527 Bug: https://bugs.gentoo.org/780648 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/targets/systemd/package.use.mask | 6 ++++++ 1 file changed, 6 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e16b0062328764431421da88d8f31887faddb78d commit e16b0062328764431421da88d8f31887faddb78d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-05-09 09:39:39 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-05-09 12:10:14 +0000 profiles: Mask kde-plasma/plasma-meta[firewall] by default Bug: https://bugs.gentoo.org/778527 Closes: https://bugs.gentoo.org/780648 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/base/package.use.mask | 4 ++++ 1 file changed, 4 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=9ee1529db2cfe395c122c9675476784e32893a55 commit 9ee1529db2cfe395c122c9675476784e32893a55 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-05-09 11:52:02 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-05-09 11:52:02 +0000 kde-plasma/plasma-firewall: Replace systemd RDEPEND w/ postinst ewarn For administrative reasons we can't have a package pulling in systemd, this would render it essentially unsupported. Instead make clear that it will not work properly. Whoever wants to install/play around with it on openrc can now do so with that roadblock removed. Bug: https://bugs.gentoo.org/778527 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-firewall/plasma-firewall-9999.ebuild | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
