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.
I don't know, unless PV wants to release 15 with limited testing with Plasma
And what makes you think that Pat is going to add Plasma 5 and then immediately release Slackware 15.0? Ever heard of public betas? We have not seen any yet.
About the "limited testing" of Plasma 5 - I have been providing monthly updates to a Slackware Plasma 5 desktop for more than THREE years now, starting when the latest stable Slackware release was still 14.1. There has been a lot of feedback on those packages used by many, so I would not call it "limited testing".
As someone who replaces rc.inet1 with their own version it would be convenient for me to see rc.inet1 given the '.local' treatment just like rc.4 recently got, but I don't know whether it would be of benefit to anyone else so I'll stop short of asking for it outright and just throw the idea out there for contemplation.
As someone who replaces rc.inet1 with their own version it would be convenient for me to see rc.inet1 given the '.local' treatment just like rc.4 recently got, but I don't know whether it would be of benefit to anyone else so I'll stop short of asking for it outright and just throw the idea out there for contemplation.
Well it's as simple as:
Code:
eha@bigfoot:/stuff/slackware/non-public/alien/slackware64$ diff -u source/a/sysvinit-scripts/scripts/rc.M{.alien,}
--- source/a/sysvinit-scripts/scripts/rc.M.orig 2017-11-18 18:21:12.000000000 +0100
+++ source/a/sysvinit-scripts/scripts/rc.M 2017-12-29 14:28:02.408497854 +0100
@@ -95,7 +95,9 @@
fi
# Initialize the networking hardware.
-if [ -x /etc/rc.d/rc.inet1 ]; then
+if [ -x /etc/rc.d/rc.inet1.local ]; then
+ /etc/rc.d/rc.inet1.local
+elif [ -x /etc/rc.d/rc.inet1 ]; then
/etc/rc.d/rc.inet1
fi
... so I hope Patrick picks this up. I think it is a good addition.
I guess "Improve" means something different here.
I'd like a good answer to why anyone should have to patch a build system to support installing libraries to /usr/lib64 on x86_64 systems in 2017, especially when the project in question *just* switched to that build system because it's an "improvement" somehow. Not fussing at you, of course, but geez.
Yes, I filed an issue upstream: https://github.com/nih-at/libzip/issues/19
I was always wondering about this: why is MPlayer binary dynamically linked with libsmbclient.so? Do we really need this dependency? How common is it to play media from SMB shares over the network?
I don't know if other people consider it a problem. But for me it's inconvenient, because I don't need Samba at all, so I uninstall the package (or don't install it in the first place). But then it's necessary to recompile MPlayer, because it fails to start.
Could this dependency be avoided in MPlayer package shipped with the next Slackware release?
I was always wondering about this: why is MPlayer binary dynamically linked with libsmbclient.so? Do we really need this dependency? How common is it to play media from SMB shares over the network?
I don't know if other people consider it a problem. But for me it's inconvenient, because I don't need Samba at all, so I uninstall the package (or don't install it in the first place). But then it's necessary to recompile MPlayer, because it fails to start.
Could this dependency be avoided in MPlayer package shipped with the next Slackware release?
I was always wondering about this: why is MPlayer binary dynamically linked with libsmbclient.so? Do we really need this dependency? How common is it to play media from SMB shares over the network?
Believe or not, it is usual for those that have a Linux box at home, to have at least other one running Windows. Hence, the SAMBA is useful for MPlayer.
Just because you personally do NOT use the SAMBA, that does not make it "obsolete".
-1000000 for that. To intentionally broke even those small bits of compatibility with a Windows local network is a freaking bad idea.
That's not breaking too much, if you have samba you could still mount a Windows share and use mplayer with that. But there are other ways to do it, one would be to split samba into samba and samba-libs.
I wish mplayer did dlopen() for streams too, like it can do for AV plugins (if compiled with --enable-dynamic-plugins)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.