LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   The what should be updated in -current thread (https://www.linuxquestions.org/questions/slackware-14/the-what-should-be-updated-in-current-thread-4175526322/)

ReaperX7 11-27-2014 12:04 AM

Quote:

Originally Posted by turtleli (Post 5275734)
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.

turtleli 11-27-2014 02:01 AM

Quote:

Originally Posted by ReaperX7 (Post 5275755)
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.
Quote:

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)

franzen 11-27-2014 02:35 AM

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

ReaperX7 11-27-2014 02:55 AM

Quote:

Originally Posted by turtleli (Post 5275795)
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?

turtleli 11-27-2014 03:30 AM

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

Quote:

Originally Posted by ReaperX7 (Post 5275808)
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.

ReaperX7 11-27-2014 04:24 AM

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?

bartgymnast 11-27-2014 11:40 AM

Quote:

Originally Posted by Alien Bob (Post 5275604)
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

OldHolborn 11-27-2014 04:14 PM

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.

ReaperX7 11-27-2014 07:16 PM

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.

hba 11-27-2014 10:27 PM

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

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

sbolokanov 11-28-2014 04:52 AM

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.

Speek 11-28-2014 05:27 AM

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

ReaperX7 11-28-2014 06:56 AM

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

the3dfxdude 11-28-2014 10:26 AM

Quote:

Originally Posted by heiser891 (Post 5276254)
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.

Quote:

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

Please qualify your statement better.

hotchili 11-28-2014 06:10 PM

Quote:

Originally Posted by hba (Post 5276165)
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.


All times are GMT -5. The time now is 01:36 AM.