The what should be updated in -current thread

Well, I would like a more recent Git version (>= 2.x), the version provided by Slackware is very old (Aug 2013).

Also, I need to point this out... (and make a suggestion)

As of the latest xorg release of xserver-1.17.1, xf86-video-modesettings has been incorporated into the package as the default vesa driver. This means xf86-video-vesa is effectively deprecated as xf86-video-modesetting (included by default) duplicates these functions for cards featuring modesetting (intel, nvidia, and amd) and xf86-video-vesa should only be used as a fallback driver if you have a video card that does not support modesetting parameters such as those cards that require OpenGL support from LibMesa-7.11.2.

This means xf86-video-modesetting does not need to be included as a separate driver (unless needed to be re-packaged separately after-the-fact).

This coincides with the forementioned suggestion of repacking Mesa-7.11.2 as Mesa-legacy-7.11.2 for video cards supporting DRI1 standards only and this and other DRI1 only drivers could be effectively moved into /extra if needed.

Can be updated the kernel to add *in* it(huge & generic) the modules of virtio? Useful for Slackware in virtualization:

$ grep -i virtio config-generic-smp-3.14.33-smp
CONFIG_NET_9P_VIRTIO=m
CONFIG_VIRTIO_BLK=m
CONFIG_SCSI_VIRTIO=m
CONFIG_VIRTIO_NET=m
CONFIG_VIRTIO_CONSOLE=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_VIRTIO=m
# Virtio drivers
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
CONFIG_VIRTIO_MMIO=m
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

- Cheers

Originally Posted by ReaperX7 Also, I need to point this out... (and make a suggestion) As of the latest xorg release of xserver-1.17.1, xf86-video-modesettings has been incorporated into the package as the default vesa driver. This means xf86-video-vesa is effectively deprecated as xf86-video-modesetting (included by default) duplicates these functions for cards featuring modesetting (intel, nvidia, and amd) and xf86-video-vesa should only be used as a fallback driver if you have a video card that does not support modesetting parameters such as those cards that require OpenGL support from LibMesa-7.11.2. This means xf86-video-modesetting does not need to be included as a separate driver (unless needed to be re-packaged separately after-the-fact). This coincides with the forementioned suggestion of repacking Mesa-7.11.2 as Mesa-legacy-7.11.2 for video cards supporting DRI1 standards only and this and other DRI1 only drivers could be effectively moved into /extra if needed.

I'm not sure all of that completely makes sense, but I think I get the general idea. For now at least, we'll be staying with xorg-server 1.16.x, but I guess 1.17.x isn't off the table yet.

Originally Posted by hba Can be updated the kernel to add *in* it(huge & generic) the modules of virtio? Useful for Slackware in virtualization: $ grep -i virtio config-generic-smp-3.14.33-smp CONFIG_NET_9P_VIRTIO=m CONFIG_VIRTIO_BLK=m CONFIG_SCSI_VIRTIO=m CONFIG_VIRTIO_NET=m CONFIG_VIRTIO_CONSOLE=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_VIRTIO=m # Virtio drivers CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_VIRTIO_MMIO=m # CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set - Cheers

This is on my TODO already, but it may not be easily doable given the tradeoff in kernel size. I don't know what the size difference will be, as I've not actually checked, but know that it is on the radar (and has been for quite some time, as I too would like to have this).

As an aside, I'd like to consider closing this thread after the next -current update, and at that point, start a new one to address any missed items and such. This thread has gotten way too long and there's quite a bit of duplication in the requests and such.

Originally Posted by dugan I kept having show-stopping issues with 3.19.1. And I'm talking about things like X ceasing to take input from my USB mouse and keyboard, which happened at least once a day.

I think it's worth following up to say that my USB hub burned out shortly after that, so it might not have been the kernel's fault.

Not sure if this is the right thread, but maybe someone can look into this.
If root filesystem is jfs, it does not properly remount read only on shutdown.

mount : / is busy

Found this on Slackware64-current with vmlinuz-huge-3.14.33

Originally Posted by rworkman As an aside, I'd like to consider closing this thread after the next -current update, and at that point, start a new one to address any missed items and such. This thread has gotten way too long and there's quite a bit of duplication in the requests and such.

I think someone previously was keeping track of what has been suggested and/or what is being worked on it would be great if they can end this thread and maybe start the new thread with the list

Good point Robby. Right now compiling a list should take precendent and a freeze on updates in the submissions here should be warranted so things can be tested and then certified stable.

Originally Posted by rworkman As an aside, I'd like to consider closing this thread after the next -current update, and at that point, start a new one to address any missed items and such. This thread has gotten way too long and there's quite a bit of duplication in the requests and such.

Let us know when you want it closed. I'd suggest posting a link to the new thread before this one is closed.

--jeremy

Originally Posted by jeremy Let us know when you want it closed. I'd suggest posting a link to the new thread before this one is closed. --jeremy

I'll start the new thread once the currently queued updates have gone public; thanks, Jeremy! :-)

Whole distro !

Originally Posted by elcore Not sure if this is the right thread, but maybe someone can look into this. If root filesystem is jfs, it does not properly remount read only on shutdown. mount : / is busy Found this on Slackware64-current with vmlinuz-huge-3.14.33

I use BtrFS myself, but I have seen this before. I added this to rc.6 after the killall5 commands to force-collapse the process tree when I added Bartgymnast's releases for procps-ng and psmisc:

# Use this to force terminate any remaining processes not shutdown by killall5
# to prevent / from not dismounting properly due to uninterrupted executions.
echo "Sending TERM signal to processes..."
pkill --inverse -s0,1 -TERM
sleep 5
echo "Sending KILL signal to processes..."
pkill --inverse -s0,1 -KILL

Take note this ONLY works with procps-ng, not procps included by default with Slackware.

Often with JFS, the system is still in the write-back phase when / is dismounted which can cause an improper dismount at shutdown. This allows for a second more comprehensive termination of processes to occur as a clean-up of the process tree.

You will have to rebuild procps-ng to work without Dlackware's systemd, but it is doable.

I need to squeeze in one last update...

udev-182 > eudev-3.0

Gentoo released a newer version of eudev recently. Not sure what all was updated from the last releases, but from looking at the code they made some significant edits compared to the systemd version.