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.
Uh, is "xf86-video-vboxvideo" what I think it is? Is it going to cause problems when I update the version of VirtualBox that's running my Slackware guest?
I'm used to to just reinstalling it from the "VirtualBox Additions CD" after each host-VirtualBox or guest-kernel upgrade.
It doesn't appear to offer any changes compared to the existing VirtualBox X.Org driver bundled for years as part of the VirtualBox Guest Additions, just now it's being treated as a proper/formal X.Org driver.
Well, an interesting idea for reverse engineering the offending packages list. Thanks you! Brilliant!
Then you can do a fresh install of Slackware 15 sets that you know that don't have KDE in them. Then use slackpkg with the blacklist to install the rest without Plasma 5. That is what I would do. Now Plasma 5 can be added to Current and everyone will be satisfied!
Then you can do a fresh install of Slackware 15 sets that you know that don't have KDE in them. Then use slackpkg with the blacklist to install the rest without Plasma 5. That is what I would do. Now Plasma 5 can be added to Current and everyone will be satisfied!
That would be everything else excluding the L, KDE and KDEI series, which would leave me with a broken installation (by lack of L set), maybe able to rise to console.
That would be everything else excluding the L, KDE and KDEI series, which would leave me with a broken installation (by lack of L set), maybe able to rise to console.
All you need is enough to get internet & slackpkg working. If that is possible then I think that would be the solution.
That would be everything else excluding the L, KDE and KDEI series, which would leave me with a broken installation (by lack of L set), maybe able to rise to console.
Or you could install all of l/ (just leaving out kde/ and kdei/) and then once you start Slackware and set up the slackpkg blacklist, you could then just run slackpkg clean-system. That means you will end up with qt5 installed for a bit, but it will be removed as soon as you run clean-system.
/var/games/emacs needs to be 775 root:games for the high-score updates for the games to work properly. You get error messages with it in its current state.
Also, AIUI sticky-bit on files is ignored on linux, so the chmod 1755 seems pointless, so I've removed that too.
patch for slackbuild:
Code:
diff -Nurp a/emacs.SlackBuild b/emacs.SlackBuild
--- a/emacs.SlackBuild 2017-09-12 18:31:50.000000000 +0100
+++ b/emacs.SlackBuild 2017-12-03 20:59:50.111134012 +0000
@@ -140,10 +140,9 @@ make $NUMJOBS || make || exit 1
# Install the non-x version:
cat src/emacs > $PKG/usr/bin/emacs-${TARBALLVER}-no-x11
chown root:root $PKG/usr/bin/emacs-${TARBALLVER}-no-x11
-chmod 1755 $PKG/usr/bin/emacs-${TARBALLVER}-no-x11
+chmod 755 $PKG/usr/bin/emacs-${TARBALLVER}-no-x11
# I don't care for broken permissions.
-chmod 755 $PKG/var/games/emacs
chown -R root:games $PKG/var/games/emacs
chmod 664 $PKG/var/games/emacs/*
The save files will be owned by whichever user was last to run the game so cheating is possible, but the alternative approach using --with-gameuser=games will result in /usr/libexec/emacs/25.3/x86_64-slackware-linux/update-game-score being suid and owned by 'games' which will prevent cheating, but is risky from a security standpoint, so probably best avoided.
BTW, I like to rebuild mine with --with-x-toolkit=lucid (if only to prevent the spurious gtk+ warnings on stderr). Don't know whether others prefer this or the gtk toolkit.
I tried a half-hearted search about updating to rsyslog. Has there been any recent conversations about moving from syslog to rsyslog? Any advantages or disadvantages?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
