SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
3. plasma-nm doesn't import private keys from ovpn profiles. Suggestion: Patch plasma-nm with upstream patch
I ran across this problem when I tried to import my employer's ovpn profile. I sorted through the plasma-nm source code and wrote a patch, which just got accepted upstream: https://invent.kde.org/plasma/plasma...48e17c1a7e460f Is there any chance that such a patch could also be applied to plasma-nm in Slackware-15?
Regardless of what will happen, I am really curious for some reactions to the above three suggestions, and I hope this is the best place to report them. Let me know!
Code:
Sun Dec 19 18:57:11 UTC 2021
kde/plasma-nm-5.23.4-x86_64-2.txz: Rebuilt.
Applied patch:
[PATCH] OpenVPN: Import tls-crypt keys
Thanks to PJ Beers.
mit introducing the systemctl call: https://github.com/KDE/plasma-firewa...3ed85d4cf10d49
It seems that in the case where systemctl is not present (which produces the same result as when systemctl finds the firewall application not loaded) Plasma-firewall will poke the ufw or firewalld binary instead. So this is why it still works on Slackware according to LuckyCyborg.
That commit indeed does not seem to do any harm on Slackware. It's the systemd dependency in the backend code for firewalld especially that might be bothersome.
To be precise (I just reinstalled firewalld) -
When firewalld is _not_ running, plasma-firewall prompts the user to enable it by checking the firewall enabled checkbox. If I do that, I get ¨
Code:
Error enabling firewall: The name org.freedesktop.systemd1 was not provided by any .service files
Also, it doesn't get firewalld running.
If I then start firewalld from the commandline and restart plasma-firewall, I get prompted for my root password (twice), and see that firewalld is running. I seem to be able to add firewall rules. However, when I then change the default incoming policy from allow to ignore, I get
Code:
Please restart plasma firewall, the backend disconnected.
If I do so, default policy is reset to allow.
All in all, my experiences with plasma-firewall's firewalld backend are not good. Firewalld has its own gui, which seems much better. Ufw does indeed seem to work, so some of plasma-firewall does work. Finally, when I click the View Connections button, I get:
Code:
could not find iproute2 or net-tools packages installed.
(I have both installed?!?) It looks for /usr/sbin/ss, which is not in the path. Linking it to /usr/bin/ss makes it work.
I personally would rather see plasma-firewall gone, it only adds a moderately functional gui, while both ufw and firewalld appear to have excellent guis themselves. Anyway, one's mileage may vary! I.e., my
EDIT
Quote:
Originally Posted by marav
Code:
Sun Dec 19 18:57:11 UTC 2021
kde/plasma-nm-5.23.4-x86_64-2.txz: Rebuilt.
Applied patch:
[PATCH] OpenVPN: Import tls-crypt keys
Thanks to PJ Beers.
Ah... ... perhaps I'm too impatient....
marav, Windu, thanks very much for your replies!
Last edited by PJBrs; 12-19-2021 at 02:05 PM.
Reason: Saying thanks; adding not about /usr/sbin/ss
I personally would rather see plasma-firewall gone, it only adds a moderately functional gui, while both ufw and firewalld appear to have excellent guis themselves. Anyway, one's mileage may vary! I.e., my
If every time we had been removed a software which does not work properly, probably today Slackware will be composed from kernel and bash.
Okay, you found a functionality issue. Did you even thought to patch it?
Eventually to start a thread, to try to fix it, considering that on this forum are people capable to create patch for the KDE software?
After all, this plasma-firewall does not depends "hard" on systemd, as you claim, because this would mean impossibility to compile by the requirements of linking against /usr/lib{,64)/libsystemd.so
What you eventually describe is "a soft dependency" to systemd.
Last edited by ZhaoLin1457; 12-19-2021 at 02:12 PM.
Don't mind the explosion from LuckyCyborg, with this level of expletives he's bound to follow where his companion hysteric igadoter went before him.
Excuse my ignorance about English, but about what "expletives" you talk?
Because he said that the claim that it hard depends on systemd is bullshit?
But how plasma-firewall compiles without systemd, if it hard depends on it?
Or you talk about the reference to the famous quarrel between Catholic and Orthodox churches regarding the accuracy of gospels translation? Even a Buddhist like me heard about this thing, so I guess this is not a secret for the Western people.
Quote:
Originally Posted by Windu
I looked up the commit introducing the systemctl call: https://github.com/KDE/plasma-firewa...3ed85d4cf10d49
It seems that in the case where systemctl is not present (which produces the same result as when systemctl finds the firewall application not loaded) Plasma-firewall will poke the ufw or firewalld binary instead. So this is why it still works on Slackware according to LuckyCyborg.
So, I should understand that you explain that there's a fallback, and it still works without systemd?
Last edited by ZhaoLin1457; 12-19-2021 at 02:26 PM.
If every time we had been removed a software which does not work properly, probably today Slackware will be composed from kernel and bash.
Nah, it would probably be just what it is today, minus plasma-firewall Just kidding!
Quote:
Okay, you found a functionality issue. Did you even thought to patch it?
Eventually to start a thread, to try to fix it, considering that on this forum are people capable to create patch for the KDE software?
I did look at the code. It seems to have at least two relatively major issues. One I would surely be able to patch, although I'm not sure whether I would be able to do so according to upstream's requirements. Or just put /usr/sbin/ in your user's path.
That other bit I would probably also be able to patch, but probably not to upstream's standards, nor to Slackware's standards. And it would be rather difficult for me anyway. What about you?
Quote:
After all, this plasma-firewall does not depends "hard" on systemd, as you claim, because this would mean impossibility to compile by the requirements of linking against /usr/lib{,64)/libsystemd.so
What you eventually describe is "a soft dependency" to systemd.
Hmm, maybe that's a matter of definition? I'd agree that systemd isn't a hard compile time dependency, but I do see it as a hard runtime dependency in the sense that plasma-firewall explicitly calls systemd components that don't exist on Slackware.
Quote:
Originally Posted by ZhaoLin1457
So, I should understand that you explain that there's a fallback, and it still works without systemd?
Like I said, your mileage may vary. It works with ufw. In my opinion, it doesn't with firewalld. LuckyCyborg thinks differently. Please just try it and see for yourself.
Nah, it would probably be just what it is today, minus plasma-firewall Just kidding!
Many software malfunctioned in the past on this Slackware -current. Let's say Firefox, as it's a casual suspect.
According with you, we should have removed it long time ago at first sign of malfunctioning, instead of patching it?
Quote:
Originally Posted by PJBrs
I did look at the code. It seems to have at least two relatively major issues. One I would surely be able to patch, although I'm not sure whether I would be able to do so according to upstream's requirements. Or just put /usr/sbin/ in your user's path.
That other bit I would probably also be able to patch, but probably not to upstream's standards, nor to Slackware's standards. And it would be rather difficult for me anyway. What about you?
Unfortunately, I am not a C/C++ programmer, but in this forum are people who are capable to patch the KDE software, as demonstrated by the past.
But you come in the requests thread with a sentence like a judge: "shall be executed by the fire squad!" instead of opening a thread regarding plasma-firewall issues or its perceived malfunctioning. Or trying to fix it. Or finding a patch for it, if you really care about this particular software. That's it.
No offense intended, but there you are quite wrong, because you are not a System Architect on Slackware. Neither I am.
Quote:
Originally Posted by PJBrs
Hmm, maybe that's a matter of definition? I'd agree that systemd isn't a hard compile time dependency, but I do see it as a hard runtime dependency in the sense that plasma-firewall explicitly calls systemd components that don't exist on Slackware.
From what I know, a "hard dependency" is a compile time dependency, linked against and which must exists on system for the software be even capable to start.
While a "soft dependency" is a runtime dependency, which may or may not exists, but which presence affects the functionality of the particular software.
Last edited by ZhaoLin1457; 12-19-2021 at 03:38 PM.
Even better an ISO can include only a minimum set of packages beyond the installer to start the installation, then complete it fetching the other packages from a remote mirror. That is what is called a net install. This is easy to do, and this mini ISO can be an additional one, provided after the release of Slackware 15 not to delay it. It is also possible that the installer in this mini ISO fetches remotely packages it includes in case newer are available. Then this ISO would not need to be rebuilt during the life of the version, or very rarely. It is also possible to provide an already installed mini Slackware as an image, including just what is needed to run and be able to expand and complete itself after installation. Hint. Maybe these things could be handled by members of the community, as Eric does for liveslak.
That would be fine, an "net-install-upgrade" ISO that would be easy to dump to a pendrive, allow to leave the system installed up to date, and even be able to install itself as a minimal Slackware system.
No offense intended, but there you are quite wrong, because you are not a System Architect on Slackware. Neither I am.
You don't have to be a system architect on slackware to suggest a removal on this thread.
PJBrs posted some valuable input, even provided a patch for kde which was honored in the changelog.
I don't see a value in discussing if someone was wrong or right.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Just kidding!
