The what should be updated in -current thread

Does mpv also have a DE friendly user interface or is it CLI only? Plus because mplayer uses xv rather than gl by default, it's more compatible with more systems.

Also, ivandi, ldd is part of glibc so it's not reinventing anything.

Originally Posted by ReaperX7 Does mpv also have a DE friendly user interface or is it CLI only? Plus because mplayer uses xv rather than gl by default, it's more compatible with more systems.

CLI only, which makes it perfect for Slackware.

(seriously, though, the Arch wiki lists three frontend projects, two of which are Qt 5. So waiting until the next, next Slackware release for Qt 5 might be appropriate if the lack of a GUI frontend is a dealbreaker. I also need to mention that I've always found MPlayer's frontends to be unuseably ugly and bad).

As for the XV issue, well, first, gl works better with the current NVidia drivers, so xv is not "more compatible with more systems". Second, setting it to use XV by default instead is, of course, something that a package maintainer can easily do if it's desired.

CLI only would make it a deal breaker as mplayer packages gmplayer as it's GUI frontend. It boils down to what can support more instances honestly. Because mplayer supports both CLI and GUI it's technically a better package, plus mencoder might still be useful to some folks.

It's like how do you kill two birds with one stone? You break the stone in half and use each half to kill each bird. Even though technically you used two stones, equally both stones came from the original stone.

Mplayer is no different. By packaging a GUI and CLI interface you kill two birds, and by packaging an encoder utility, you kill yet another two birds equally.

'mpv' has a GUI if you build it against LUA. Personally I don't bother though. I'm quite happy to use hotkeys to control it.

Well, giving up the (awful) GUI and Mencoder (which has been superceded by ffmpeg and handbrake) wouldn't be a dealbreaker for me, especially considering what I'm getting in exchange.

But of course I don't speak for all Slackers, and I can't offer anything other than my opinion here. ReaperX's opinion is directly opposed to mine. What does everyone else think?

Originally Posted by ivandi So how am I supposed to run a container in Slackware[?]

Simple: do it the Slackware way, or choose another platform and do it the yum/apt-get way. Are we all supposed to accept dependency resolution now just because a single user demands it? The vast majority don't want it. We've been happily running Slackware for years without it. But if dependency resolution becomes too much of a chore some of us just fire up a virtual machine and install Salix, NetBSD, Crux, FreeBSD, Debian, or CentOS, all of which will allow you to easily install packages with dependencies more or less satisfied.

Originally Posted by dugan (seriously, though, the Arch wiki lists three frontend projects, two of which are Qt 5. So waiting until the next, next Slackware release for Qt 5 might be appropriate if the lack of a GUI frontend is a dealbreaker. I also need to mention that I've always found MPlayer's frontends to be unuseably ugly and bad).

SMPlayer added mpv support, so this could be an easy way to ease the transition, since it supports both mplayer and mpv. There is a slackbuild for it, which I'm using, but I don't have mpv installed (I compiled my own mplayer before I found out about mpv and was too lazy to attempt building that as well), so I don't know if mpv support works on the version on SBo.

Originally Posted by gezley Simple: do it the Slackware way, or choose another platform and do it the yum/apt-get way. Are we all supposed to accept dependency resolution now just because a single user demands it? The vast majority don't want it. We've been happily running Slackware for years without it. But if dependency resolution becomes too much of a chore some of us just fire up a virtual machine and install Salix, NetBSD, Crux, FreeBSD, Debian, or CentOS, all of which will allow you to easily install packages with dependencies more or less satisfied.

How a tool like tracepkg goes against the Slackware way. It's made especially for Slackware. It's an addon to pkgtools. It uses ldd. It's a bash script and can be run on any Slackware version and is easily maintainable.

The project looks abandoned by the author, but the tool has been recently dicussed. I maintain a version that works for me. I didn't ask exactly for tracepkg because there are also other similar tools. Not all Slackware users choose the most stupid way.


Cheers

Originally Posted by ivandi How a tool like tracepkg goes against the Slackware way. It's made especially for Slackware. It's an addon to pkgtools. It uses ldd. It's a bash script and can be run on any Slackware version and is easily maintainable. The project looks abandoned by the author, but the tool has been recently dicussed. I maintain a version that works for me.

Fine. You use a tool that works for you. In your own words, it can be run on any Slackware version and it's really maintainable. You even maintain a version of it for yourself. And "it works for me".

So what exactly is the problem? You have what you want. Now stop imposing it on everyone else. I've really had enough of this "me me me" attitude lately. Now please return to the theme of this thread: what should be updated in -current.

Originally Posted by gezley Fine. You use a tool that works for you. In your own words, it can be run on any Slackware version and it's really maintainable. You even maintain a version of it for yourself. And "it works for me". So what exactly is the problem? You have what you want. Now stop imposing it on everyone else. I've really had enough of this "me me me" attitude lately. Now please return to the theme of this thread: what should be updated in -current.

Running ldd with or without a script used by tracepkg and other utilities is "your" problem, not Slackware's. And Ivandi... nobody gives a rat's fat ass what you feel is "stupid" or the "stupid way"... It's the Slackware way, so either like it, or change distributions to something else if you feel the Slackware way is the stupid way. We've all had enough of this. Yes, get the topic back on topic, for the 2nd request of this... NOW!

As far as mpv versus mplayer... there is another problem. Plugins and libraries used against it. Mplayer can dynamically load several libraries as needed as well other encoder/decoder plugins... such as libdvdcss. How well does mpv handle these functions?

As far as the lua UI goes... I'd rather have a GTK based UI than a lua based one. Don't ask, just preference. Until mplayer itself isn't maintained I doubt there will be a switch to another generalized media player. For now, it's in SBo, and if it's not, someone can reign it in and craft a build script for it. If needed you can try asking in the "Package Request" thread.

Originally Posted by ReaperX7 As far as mpv versus mplayer... there is another problem. Plugins and libraries used against it. Mplayer can dynamically load several libraries as needed as well other encoder/decoder plugins... such as libdvdcss. How well does mpv handle these functions?

libdvdcss is handled the same way as in MPlayer, of course.

If you're talking about the win32codecs, they haven't been relevant for around a decade (especially on 64-bit machines). If you're not then you'll have to be more specific.

I was thinking along the lines of things like Xvid, FFMpeg, and other external plugins.

Isn't there a Win64Codec pack now?

Also, I think we need to have a look at possibly using something such as a cache-update script started from inittab as a sort of update to how Slackware's startup proceeds.

I referenced this work from GazL's post about it sometime back:

inittab line 66~69

+
+# Maintenance for cache files
+m1:2345:once:/etc/rc.d/rc.cache-update
+

New file /etc/rc.d/rc.cache-update
Lines 1~55

#!/bin/sh
#
# rc.cache-update		This file is executed by init(8) when the system is being
#				initialized for one of the "multi user" run levels (i.e.
#				levels 3 and 4).  It updates all cache files, icon databases,
#				and other caches used by the system for various purposes in the
#				background during session startup.
#
# Version:			@(#)/etc/rc.d/rc.cache_update 0.1 Mon Mar 2 18:36:33 PST 2015
#
# Author:			James Powell <james4591@hotmail.com>
#				Inspired and referenced from GazL of LinuxQuestions.org's
#				rc.app_update script with edits for checks of existence.

# Create a log for the cache updater.
exec >/var/log/cache_updates.log 2>&1

# Update the X font indexes:
if [ -x /usr/bin/fc-cache ]; then
  /usr/bin/fc-cache -f &
fi

# Update any existing icon cache files:
if find /usr/share/icons -maxdepth 2 2> /dev/null | grep -q icon-theme.cache ; then
  for theme_dir in /usr/share/icons/* ; do
    if [ -r ${theme_dir}/icon-theme.cache ]; then
      /usr/bin/gtk-update-icon-cache -t -f ${theme_dir} 1> /dev/null 2> /dev/null &
    fi
  done
  # This would be a large file and probably shouldn't be there.
  if [ -r /usr/share/icons/icon-theme.cache ]; then
    #/usr/bin/gtk-update-icon-cache -t -f /usr/share/icons 1> /dev/null 2> /dev/null &
    rm -f /usr/share/icons/icon-theme.cache
  fi
fi

# Update mime database:
if [ -x /usr/bin/update-mime-database -a -d /usr/share/mime ]; then
  /usr/bin/update-mime-database /usr/share/mime 1> /dev/null 2> /dev/null &
fi

# These GTK+/pango files need to be kept up to date for
# proper input method, pixbuf loaders, and font support.
if [ -x /usr/bin/update-gtk-immodules ]; then
  /usr/bin/update-gtk-immodules > /dev/null 2>&1 &
fi
if [ -x /usr/bin/update-gdk-pixbuf-loaders ]; then
  /usr/bin/update-gdk-pixbuf-loaders > /dev/null 2>&1 &
fi
if [ -x /usr/bin/update-pango-querymodules ]; then
  /usr/bin/update-pango-querymodules > /dev/null 2>&1 &
fi
if [ -x /usr/bin/glib-compile-schemas ]; then
  /usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas >/dev/null 2>&1 &
fi

This effectively forks these services to the background to run behind the scenes rather than in the foreground at boot and allows them to be started only during runlevels 2, 3, 4, and 5.

Changes made to the original contribution include the existence check references.

This would move these services out of rc.M and push them into an instance based startup helping the boot process especially for Single User Mode.

Per sanity, a log would be created for this service as with the original.

Originally Posted by ReaperX7 I was thinking along the lines of things like Xvid, FFMpeg, and other external plugins.

FFMPEG is not an external plugin. MPlayer and MPV both use FFMPEG as the video decoding backend. The decoders for all of the supported video formats for both players are included as a standard part of FFMPEG.

The optional dependencies for MPlayer (e.g. --enable-xvid) are not for playback. They're for mencoder to use for encoding. MPlayer has always played back Xvid even if you don't have the Xvid installed. Of course MPV does too.

Isn't there a Win64Codec pack now?

It's never been relevant.

I actually just downloaded it to have a look. It untars to a directory named w64codecs-20071007 (for when it was last updated, of course). It contains only three files:

• cook.so
• drvc.so
• sipr.so

The Realplayer codec represented by cook.so is part of FFMPEG and therefore cook.so is not needed for either player. I understand that the other two are also for Realplayer files. I've never had trouble playing Realplayer files without having Windows codecs installed (well, I might have at one point, but it wasn't this decade).

Ah, thanks for clearing that up Dugan. Well, in any case MPlayer is possibly a wider hitting package though the limits of it are noted, but however, keeping the traditional MPlayer package will probably take precedent. I see a few reasons to upgrade to another (maybe better) media player, but not enough to replace two parts of the whole and relegate them out to other packages (namely gmplayer and mencoder).

Anyways, let's discuss now at this time, unless Bart and anyone else has any other additions, what the status of -Current is, and if any, testing of proposed packages has been going.

At current I'm still running ConsoleKit2-0.9.2 without any issues and there have been no problems with log in sessions other than a reciprocating login bug with sddm from (PDE) Plasma Desktop Environment (aka KDE 5.x), but I suspect that's a limitation of sddm whereas gdm, kdm(kde4), xdm, and lxdm all work as intended.

I am confident enough to report to Robby, and possibly Patrick, the package is stable enough for deployment within the distribution, and unless further testing is needed, I would recommend updating pushing ConsoleKit-0.4.x out to /pasture and upgrading it to ConsoleKit2 respectively.

I really hope the new XFCE 4.12 makes it to the next version of Slackware!