The what should be updated in -current thread

Originally Posted by turtleli Upgrade xf86-video-mach64 driver to git version? Or at least use this patch - Someone had trouble on 14.1 in this thread and this patch solved the issue. Should probably also be fixed for 14.1 now that I think about it.

Isn't there an experimental drm module for Mach64 to enable some video acceleration?

https://wiki.archlinux.org/index.php/mach64

Also, just morbid curiosity but would be bad to think about trying to keep a functional build of libmesa such as the last version of 7.11.x that supported all the legacy video cards in /extra or on SBo? That is if it would still work.

@Robby We probably should also update UPower:

upower-0.9.17 > upower-0.9.23

Not sure if this will help xfce4-power-manager, but might be worth investigating. However, another key package might be needed as well:

udev-182 > eudev-2.1(udev-217)

Didier had a Slackbuild for this with the updated handlers for /dev/shm linking to /run/shm properly. I wouldn't prioritize this update if udev-182 can build upower effectively.

Originally Posted by ReaperX7 Isn't there an experimental drm module for Mach64 to enable some video acceleration? https://wiki.archlinux.org/index.php/mach64

It's not in the mainline kernel, so does it fix anything for anyone who uses it? The page you linked to also says it's not very reliable. I don't know much about the Mach64 stuff, it doesn't personally affect me, I'm just reporting an issue that another Slackware user had and solved.

Also, just morbid curiosity but would be bad to think about trying to keep a functional build of libmesa such as the last version of 7.11.x that supported all the legacy video cards in /extra or on SBo? That is if it would still work.

What legacy video cards are you talking about? (EDIT: Never mind, was sure it said 9.x when I read it. Guessing it would be too much hassle since xserver-1.15.2 seems to require libmesa >= 9.2 to work according to Gentoo)

proftpd -> 1.3.4e

Here's a patch that enables the filebased Quota-support in proftpd,
there were no compile issues.
I built/testet it on slackware64 14.0, no messages about "Quotas off".

Franzen

--- proftpd.SlackBuild.orig 2014-11-27 09:29:49.370789253 +0100
+++ proftpd.SlackBuild 2014-11-27 09:32:15.662474554 +0100
@@ -21,8 +21,8 @@
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


-VERSION=1.3.4c
-DIRVER=1.3.4c
+VERSION=1.3.4e
+DIRVER=1.3.4e
BUILD=${BUILD:-1}

NUMJOBS=${NUMJOBS:-" -j7 "}
@@ -81,11 +81,8 @@
--enable-ctrls \
--enable-ipv6 \
--localstatedir=/var/run \
- --with-modules=mod_radius:mod_ban:mod_readme:mod_ratio:mod_tls:mod_wrap:mod_ctrls_admin \
+ --with-modules=mod_radius:mod_ban:mod_readme:mod_ratio:mod_tls:mod_wrap:mod_ctrls_admin:mod_quotatab:mod_qu otatab_file \
--build=$ARCH-slackware-linux
-# This caused funny messages about "Quotas off" with every FTP command,
-# and mod_wrap gets a compile error:
-# --with-modules= ... mod_quota ...

make $NUMJOBS || make || exit 1
make install DESTDIR=$PKG || exit 1

Originally Posted by turtleli It's not in the mainline kernel, so does it fix anything for anyone who uses it? The page you linked to also says it's not very reliable. I don't know much about the Mach64 stuff, it doesn't personally affect me, I'm just reporting an issue that another Slackware user had and solved. What legacy video cards are you talking about?

All of the older cards that used DRI-1 like those from Intel such as the 828x0 series, SiS, Matrox, 3dfx, and others had support ripped out when libmesa-8.0 arrived. Since 8.0 if you want a driver you're stuck with llvmpipe, vesa, or the software rasteriser. Specifically the removal list from 8.0 consisted of:

i810
mach64 (provided you had the drm module built)
mga
r128
sis
savage
tdfx
unichrome

Because Slackware still supplies drivers for x11 for a number of older video cards having a proper hardware accelerated OpenGL driver might be beneficial if you have one of these cards. The only question is, does libmesa-7.11.2 still build?

xorg-server shouldn't have libmesa as a direct dependency, only a runtime.

Franzen, can you please wrap that in a code tag?

tmux -> 1.9a
Builds/runs on Slackware 64-14.1, no changes to SlackBuild necessary.

Originally Posted by ReaperX7 All of the older cards that used DRI-1 like those from Intel such as the 828x0 series, SiS, Matrox, 3dfx, and others had support ripped out when libmesa-8.0 arrived. Since 8.0 if you want a driver you're stuck with llvmpipe, vesa, or the software rasteriser. Specifically the removal list from 8.0 consisted of: i810 mach64 (provided you had the drm module built) mga r128 sis savage tdfx unichrome Because Slackware still supplies drivers for x11 for a number of older video cards having a proper hardware accelerated OpenGL driver might be beneficial if you have one of these cards. The only question is, does libmesa-7.11.2 still build? xorg-server shouldn't have libmesa as a direct dependency, only a runtime.

Don't think it'd work, see my previous post, I edited it slightly just before you posted. And as stated before, page you linked to says the drm driver is not very reliable. Hardware accelerated possibly crashy system, vs non-accelerated, stable system.

Very true on the mach64 drm. It is said to be somewhat unstable, but as always, that can vary system to system. I don't have a mach64 series chip though to test it, but feedback on it by anyone with a card with those chips might be useful to determine if it might be good for inclusion via SBo maybe.

I'll try downloading a copy and backtracking an older Slackbuild to do a test build.

As far as ConsoleKit2, I can't find any direct ties with it to Xfce4 other than a runtime dependency for xfce4-session when you use

startxfce4 --with-ck-launch

So maybe its a upower issue with pm-utils?

Originally Posted by Alien Bob Libinput does not seem of any use, as long as we do not add Wayland or KDE 5 to Slackware. Libepoxy looks like it might ultimately replace GLEW. It is considered for kde-workspace but likewise that will not happen in KDE 4. Eric

libepoxy is a dep for xorg-1.16
libinput is indeed for Wayland, KDE 5, Gnome 3.14+, and not sure what else might use it.
In vmware and gnome-3.14 it is using libinput for my mouse, very handy and precise, dont even need vmtools anymore to switch to original desktop with my mouse

Both the following tested on 32 and 64 bit and Slackwarearm all 14.1, albeit using the stock SlackBuild scripts rather than the Slackwarearm build method.

xfce4-terminal-0.6.3
Remembers window positions
requires only the most trivial change to the SlackBuild
61c61
< tar xvf $CWD/$PKGNAM-$VERSION.tar.xz || exit 1
---
> tar xvf $CWD/$PKGNAM-$VERSION.tar.?z* || exit 1

smartmontools-6.3
updates for newer drives
requires no changes to SlackBuild although slack-desc may want updating
15,18c15,17
< smartmontools: failures. SMARTMONTOOLS Version 5.x is designed to comply to the
< smartmontools: ATA/ATAPI-5 specification (Revision 1). Future releases of
< smartmontools: SMARTMONTOOLS (Versions 6.x and 7.x) will comply with the ATA/ATAPI-6
< smartmontools: and ATA/ATAPI-7 specifications.
---
> smartmontools: failures, and to carry out different types of drive self-tests.
> smartmontools: This version of smartd is compatible with ACS-3, ACS-2, ATA8-ACS,
> smartmontools: STA/ATAPI-7 and earlier standards.

It does however have a marmite feature. On startup it will send a mail for each drive that contains permanent errors. This includes relocation errors for which a little of is not a great worry but a lot of is.

I just thought about this...

Why not add one package to Slackware that is very beneficial, yet small, but can be helpful?

sbotools > 1.8 (new request)

This way, Slackware would have not just slackpkg at it's disposal by default, but also a tool to add SBo packages using a BSD ports-like toolkit. This way, the SBos can be fetched, installed, and maintained within Slackware unofficially, yet with an official tool, and if packages go in and out of SBo and the main system, they can still be traced and all, yet still separate?

This would/could allow less packages to be actually in the installation media, effectively allowing downsizing of Slackware if need-ever-be while still maintaining the system effectively.

dnsmasq-2.72 - I'm using it in -current, no problem so far.

libusb-1.0.19 - Also, in -current for qemu.

xf86-video-nouveau -> 1.0.11
flac -> 1.3.1
lzip -> 1.16
SDL2 ? - I can't think of anything that use it yet, but I don't see a reason for not including it.

libogg 1.3.2
libvorbis 1.3.4
wavpack 4.70.0
audacious (+ plugins) 3.5.2
xf86-video-intel 2.99.916
cdrtools 3.01a25

SDL2 is mostly for Wayland, so it's safer in SBo.

Originally Posted by heiser891 xf86-video-nouveau -> 1.0.11 flac -> 1.3.1 lzip -> 1.16 SDL2 ? - I can't think of anything that use it yet, but I don't see a reason for not including it.

I use it, but it is fine to leave it out on this cycle.

Originally Posted by ReaperX7 SDL2 is mostly for Wayland, so it's safer in SBo.

Please qualify your statement better.

Originally Posted by hba libusb-1.0.19 - Also, in -current for qemu.

+1 for libusb, I have 1.0.19 installed since a month or so and it just works no problem so far.