The what should be updated in -current thread

Originally Posted by ReaperX7 xf86-video-sis and various other drivers are probably not going to be maintained since Mesa3D dropped a lot of the drivers related to DRI1 support. It's really a sad state that support has been reduced to using the vesa/modesetting driver for many non-mainstream video cards over the lack of willingness by the developers to bring the drivers up to modern specs even for EXA.

Yeah, that's too bad. I'm considering learning how to write graphics drivers to keep several of my computers working.

If you think that running an old version of Mesa is possible, I'll help in some way.

I'd like to humbly request not adopting procps-ng. They sort of ruined top(1).

Here's a side-by-side comparison of procps top(1) and procps-ng top(1) (the latter on an ubuntu box):

http://i.imgur.com/OmdYjZh.png

Originally Posted by _gin d/rcs --> 9.3 l/readline --> 6.3 y/bsd-games --> 2.17

I already had readline here (lots of rebuilds for that one).
I just got rcs queued up.
I'm going to leave bsd-games alone for now. It's not obvious to me from some casual searching where the correct homepage/download link is, and while I could grab the archive from another distribution, I'd rather not do that without knowing that what they have is official (as well as it can be).

Originally Posted by rworkman I'm going to leave bsd-games alone for now. It's not obvious to me from some casual searching where the correct homepage/download link is, and while I could grab the archive from another distribution, I'd rather not do that without knowing that what they have is official (as well as it can be).

I don't know if this http://www.advogato.org/proj/bsd-games is the official homepage of the bsd-games for Linux...

Originally Posted by ttk I'd like to humbly request not adopting procps-ng. They sort of ruined top(1). Here's a side-by-side comparison of procps top(1) and procps-ng top(1) (the latter on an ubuntu box): http://i.imgur.com/OmdYjZh.png

Procps-ng's pkill does work a bit more effectively though and has more options when trying to kill the process tree. It'll be good to have pkill if alternative init systems can be imported into Slackware more effectively to supplicant killall5.

I have been using procps-ng for some time already instead of procps.
The new top shows atleast which process is its parent.
apart from that, a user will not notice the difference
I would like to see it actually adopted.

Originally Posted by rworkman Done, along with quite a few other changes to the LVM2 build since 14.1.

Thank you very much.

Originally Posted by rworkman I don't understand why this is needed - with all of the rundir stuff set to a subdir of /run, it's created automatically.

http://www.linuxquestions.org/questi...-a-4175431260/
The code in "dmeventd.c" simply calls "mkfifo". It does not check if the subdirectories exist. There is no call to "mkdir" in "dmeventd.c".

tmpfs /run tmpfs rw,relatime,mode=755 0 0

And since "/run" is a tmpfs these subdirectories will disappear at shutdown. And should therefor be re-created at boot time (in rc.S).

Originally Posted by rworkman Hrm, if this is still an issue after the new lvm2 changes go into the tree, let me know and we'll investigate.

Will do. Thank you.

Originally Posted by ReaperX7 SDL2 is mostly for Wayland

Not really. No.
Btw turns out that there are games that use it, so my first statement is incorrect (about the lack of usage).

I wanted to try 0ad (SDL2 support) and made some changes to the script at SBo.
Erik should merge them at some point, if he doesn't find the requirement of enet >= 1.3 as a no-go (which is incompatible with the old 1.2)

A thought but, shouldn't move the udev using tmpfs mount to /run and link /dev/shm to /run/shm?

Originally Posted by ReaperX7 A thought but, shouldn't move the udev using tmpfs mount to /run and link /dev/shm to /run/shm?

Robby already asked you in post #42:

What's wrong with /dev/shm/ as is? Is it merely that some other stuff is now expecting it in /run/shm/ (in which case that's easy to fix)?

Originally Posted by MadMaverick9 Thank you very much. http://www.linuxquestions.org/questi...-a-4175431260/ The code in "dmeventd.c" simply calls "mkfifo". It does not check if the subdirectories exist. There is no call to "mkdir" in "dmeventd.c". tmpfs /run tmpfs rw,relatime,mode=755 0 0 And since "/run" is a tmpfs these subdirectories will disappear at shutdown. And should therefor be re-created at boot time (in rc.S). Will do. Thank you.

Well, see if this patch will apply to whatever version you have (it's generated on 2.02.114) and then see if it fixes the problem properly; if so, I'll just carry it as a distro patch. My experience with upstream is that bug reports are ignored, even with patches.

http://www.slackware.com/~rworkman/c...m-run-dir.diff

Originally Posted by Didier Spaier Robby already asked you in post #42:

Yes, and you got your answer in a follow-up.

The point is, using the current design framework puts a tmpfs in /run by default already, but places a second tmpfs in /dev/shm. The modification to link /dev/shm to /run/shm negates using duplicate tmpfs mounts so that udev only mounts one time, and the init script to mount tmpfs creates all the appropriate directories in /run to which then, anything using the shared memory system uses the tmpfs which is then flushed completely upon dismount when /run is dismounted so that you avoid yet another redundant tmpfs dismount.

Accidental double post due to maintenance.

Originally Posted by rworkman Well, see if this patch will apply to whatever version you have (it's generated on 2.02.114) and then see if it fixes the problem properly; if so, I'll just carry it as a distro patch. My experience with upstream is that bug reports are ignored, even with patches. http://www.slackware.com/~rworkman/c...m-run-dir.diff

Your patch did not work, because "dmeventd.c" wants to create its pid file in "/run/lvm/" as well. I moved the "mkdir" into the main function and now it works.

--- LVM2.2.02.100/daemons/dmeventd/dmeventd.c.orig      2013-08-13 17:44:43.000000000 +0700
+++ LVM2.2.02.100/daemons/dmeventd/dmeventd.c   2014-12-09 10:53:24.744482356 +0700
@@ -1967,6 +1967,9 @@
        if (setenv("LC_ALL", "C", 1))
                perror("Cannot set LC_ALL to C");
 
+       /* Create rundir */
+       mkdir(DEFAULT_DM_RUN_DIR, 0700);
+
        if (_restart)
                restart();

I added an "ls" in "rc.S" for testing and it's ok now:

/run/lock/lvm/:
total 0
drwx------ 2 root root 40 Dec  9 18:16 .
drwx------ 3 root root 60 Dec  9 18:16 ..

/run/lvm/:
total 4
drwx------ 2 root root 100 Dec  9 18:16 .
drwxr-xr-x 6 root root 140 Dec  9 18:16 ..
prw------- 1 root root   0 Dec  9 18:16 dmeventd-client
prw------- 1 root root   0 Dec  9 18:16 dmeventd-server
-rw------- 1 root root   5 Dec  9 18:16 dmeventd.pid

Originally Posted by MadMaverick9 Your patch did not work, because "dmeventd.c" wants to create its pid file in "/run/lvm/" as well. I moved the "mkdir" into the main function and now it works. --- LVM2.2.02.100/daemons/dmeventd/dmeventd.c.orig 2013-08-13 17:44:43.000000000 +0700 +++ LVM2.2.02.100/daemons/dmeventd/dmeventd.c 2014-12-09 10:53:24.744482356 +0700 @@ -1967,6 +1967,9 @@ if (setenv("LC_ALL", "C", 1)) perror("Cannot set LC_ALL to C"); + /* Create rundir */ + mkdir(DEFAULT_DM_RUN_DIR, 0700); + if (_restart) restart(); I added an "ls" in "rc.S" for testing and it's ok now: /run/lock/lvm/: total 0 drwx------ 2 root root 40 Dec 9 18:16 . drwx------ 3 root root 60 Dec 9 18:16 .. /run/lvm/: total 4 drwx------ 2 root root 100 Dec 9 18:16 . drwxr-xr-x 6 root root 140 Dec 9 18:16 .. prw------- 1 root root 0 Dec 9 18:16 dmeventd-client prw------- 1 root root 0 Dec 9 18:16 dmeventd-server -rw------- 1 root root 5 Dec 9 18:16 dmeventd.pid

Much appreciated; I've updated the patch and pushed it into my pending queue.