its time for ... Current (pre-release)

I am using openbox slackbuild and startx (kdm won't start here, complains about a missing library), and after update to pre-release I noticed that when I startx, xfce power manager and xfce screensaver start mysteriously. I am not really worried about kdm, that's something I can totally live without, but the X start-up weirdness I really want to solve

At any rate, kdm log says

/usr/lib64/kde4/libexec/kdm_greet: error while loading shared libraries: libqca.so.2: cannot open shared object file: No such file or directory

Oh, hehe, I think I just found where this comes from: /etc/xdg/autostart/

Originally Posted by qweasd I am using openbox slackbuild and startx (kdm won't start here, complains about a missing library), and after update to pre-release I noticed that when I startx, xfce power manager and xfce screensaver start mysteriously. I am not really worried about kdm, that's something I can totally live without, but the X start-up weirdness I really want to solve At any rate, kdm log says /usr/lib64/kde4/libexec/kdm_greet: error while loading shared libraries: libqca.so.2: cannot open shared object file: No such file or directory Oh, hehe, I think I just found where this comes from: /etc/xdg/autostart/

Looks like you're missing the qca package.

I have this: /var/log/packages/qca-2.3.1-x86_64-1
I notice that the lib names are different, the package has libqca-qt5

PACKAGE NAME:     qca-2.3.1-x86_64-1
COMPRESSED PACKAGE SIZE:     716K
UNCOMPRESSED PACKAGE SIZE:     
PACKAGE LOCATION: ./qca-2.3.1-x86_64-1.txz
PACKAGE DESCRIPTION:
qca: qca (Qt Cryptographic Architecture)
qca:
qca: QCA aims to provide a straightforward and cross-platform cryptographic
qca: API using Qt datatypes and conventions. The library and plugins
qca: support a range of cryptographic features, including SSL/TLS, X.509
qca: certificates, SASL, OpenPGP, smartcards, and much more.
qca:
qca: Homepage: https://github.com/KDE/qca
qca:
qca:
qca:
FILE LIST:
./
install/
install/doinst.sh
install/slack-desc
usr/
usr/doc/
usr/doc/qca-2.3.1/
usr/doc/qca-2.3.1/COPYING
usr/doc/qca-2.3.1/INSTALL
usr/doc/qca-2.3.1/README
usr/doc/qca-2.3.1/TODO
usr/include/
usr/include/qt5/
usr/include/qt5/Qca-qt5/
usr/include/qt5/Qca-qt5/QtCrypto/
usr/include/qt5/Qca-qt5/QtCrypto/QtCrypto
usr/include/qt5/Qca-qt5/QtCrypto/qca.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_basic.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_cert.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_core.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_export.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_keystore.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_publickey.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_safetimer.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_securelayer.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_securemessage.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_support.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_textfilter.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_tools.h
usr/include/qt5/Qca-qt5/QtCrypto/qca_version.h
usr/include/qt5/Qca-qt5/QtCrypto/qcaprovider.h
usr/include/qt5/Qca-qt5/QtCrypto/qpipe.h
usr/lib64/
usr/lib64/cmake/
usr/lib64/cmake/Qca-qt5/
usr/lib64/cmake/Qca-qt5/Qca-qt5Config.cmake
usr/lib64/cmake/Qca-qt5/Qca-qt5ConfigVersion.cmake
usr/lib64/cmake/Qca-qt5/Qca-qt5Targets-release.cmake
usr/lib64/cmake/Qca-qt5/Qca-qt5Targets.cmake
usr/lib64/libqca-qt5.so.2.3.1
usr/lib64/pkgconfig/
usr/lib64/pkgconfig/qca2-qt5.pc
usr/lib64/qt5/
usr/lib64/qt5/bin/
usr/lib64/qt5/bin/mozcerts-qt5
usr/lib64/qt5/bin/qcatool-qt5
usr/lib64/qt5/mkspecs/
usr/lib64/qt5/mkspecs/features/
usr/lib64/qt5/mkspecs/features/crypto.prf
usr/lib64/qt5/plugins/
usr/lib64/qt5/plugins/crypto/
usr/lib64/qt5/plugins/crypto/libqca-cyrus-sasl.so
usr/lib64/qt5/plugins/crypto/libqca-gcrypt.so
usr/lib64/qt5/plugins/crypto/libqca-gnupg.so
usr/lib64/qt5/plugins/crypto/libqca-logger.so
usr/lib64/qt5/plugins/crypto/libqca-nss.so
usr/lib64/qt5/plugins/crypto/libqca-ossl.so
usr/lib64/qt5/plugins/crypto/libqca-softstore.so
usr/man/
usr/man/man1/
usr/man/man1/qcatool-qt5.1.gz

Originally Posted by garpu So how many of y'all on current stay on current? I normally do the stable branch of Slackware, because I need things reliable, but with newer hardware, newer firmware, kernels and such is nice. (And newer versions of things help with gaming.) Like how broken is current in the first few months after a stable release?

Started testing -current on my desktop alongside my main 14.2 when v came to town, to see what it will look like and in case I can help in any way with feedback.

On my desktop: once 15 lands, I intend to install it, migrate everything from -current and 14.2, then blow them away.

On my Raspberry Pi 4: I have to run SlackwareARM -current with Sarpi provided kernel packages, since 14.2 doesn't support it. If 15 works there, then I will move to 15, otherwise fine with sticking with -current.

TKS

Originally Posted by qweasd I am using openbox slackbuild and startx (kdm won't start here, complains about a missing library), and after update to pre-release I noticed that when I startx, xfce power manager and xfce screensaver start mysteriously. I am not really worried about kdm, that's something I can totally live without, but the X start-up weirdness I really want to solve At any rate, kdm log says Oh, hehe, I think I just found where this comes from: /etc/xdg/autostart/

kdm is no longer a part of Slackware. It was chopped when KDE4 was removed and Plasma5 became primetime. While -current had vtown, it contained qca-2.1.3 and qca-qt5-2.3.1. When vtown was promoted to the main tree and KDE4 removed, qca-qt5 became the qca package, which removed the file required by kdm.

If you want KDM to run, you'd need to grab the older qca from the cumulative mirror, but it might become quite the hunt for matching all dependencies.

If you don't want to deal with that, the better option is to probably switch to sddm, which is what replaced kdm.

Not all that excited. The next version will arrive when it arrives. With the exception of two virtual machines that run 14.2, I have -current installed on three laptops and two desktops. I've been using -current for many years. When the next version arrives I will already be there.

Openbox supports XDG autostart, if selecting 'xinitrc.openbox-session' in xwmconfig script, any *.desktop apps in /etc/xdg/autostart will startup with it. There are two ways to disable a system-wide entry. Create an overriding entry containing 'Hidden=true' into ~/.config/autostart/. Or, removepkg pyxdg.

ps. I am running openbox, I use xfce4-session-settings to disable some xdg autostarts. However, extra packages needed.
xfce4-session,libxfce4ui,libxfce4util,xfconf

Originally Posted by chrisretusn Not all that excited. The next version will arrive when it arrives. With the exception of two virtual machines that run 14.2, I have -current installed on three laptops and two desktops. I've been using -current for many years. When the next version arrives I will already be there.

+1
I've been using the next release on all my machines for a very long time
(Except for one VM running the rock solid 14.2)

Originally Posted by bassmadrigal kdm is no longer a part of Slackware. It was chopped when KDE4 was removed and Plasma5 became primetime. While -current had vtown, it contained qca-2.1.3 and qca-qt5-2.3.1. When vtown was promoted to the main tree and KDE4 removed, qca-qt5 became the qca package, which removed the file required by kdm. If you want KDM to run, you'd need to grab the older qca from the cumulative mirror, but it might become quite the hunt for matching all dependencies. If you don't want to deal with that, the better option is to probably switch to sddm, which is what replaced kdm.

Ohhh that makes sense... I forgot to run slackpkg clean-system Thanks!

Thanks also to zhl, your tip about ~/.config/autostart/ worked perfectly

Just a word of caution with "clean-system". If you've done any modifications or installed any addon packages, be certain to review the list of what will be "cleaned". It's time well spent.... a stitch in time.

Originally Posted by enorbet Just a word of caution with "clean-system". If you've done any modifications or installed any addon packages, be certain to review the list of what will be "cleaned". It's time well spent.... a stitch in time.

Agree.

This one of the reasons /etc/slackpkg/blacklist exist. Add your non-slackware (3rd party) packages to blacklist and clean-system will no process them.

Another alternative is to use the slackpkg+ add-on.

Originally Posted by enorbet Just a word of caution with "clean-system". If you've done any modifications or installed any addon packages, be certain to review the list of what will be "cleaned". It's time well spent.... a stitch in time.

And if your...friend...happens to blindly run clean-system, you can sort packages that were removed by date in /var/log/removed_packages.

clean-system wasn't the worst mistake I've ever made. When I was newb to Linux, I deleted all of glibc. I didn't know that user-installed/compiled things lived in /usr/local/lib, and I did a "rm *libc*" in /lib, hoping to delete csound libraries hanging around. (Debian--before I'd discovered slackware--so I just reinstalled the package.) And then...a few months later, I accidentally deleted bash. That messes a lot up. (I simlinked bash to zsh, ftp'ed over a binary from my best friend's brother's box, who was running the same version of Debian, and then reinstalled bash.)

And then tonight I didn't change the image of the kernel in elilo.conf, and had a minor freakout when trying to boot the new kernel. Oops. Figured out what I did when I could boot the old one and I double-checked elilo.conf. Seeing your boot go from elilo prompt to bios was one of those "oh crap" moments. (I realize I could keep that from happening again by renaming the old kernel in /boot/efi to vmlinuz-old, and new one is always vmlinuz. I keep meaning to change things, but never get around to it.)

Originally Posted by Thom1b I decided to use current on all my desktop. But on my servers I only use stable.

This is my practice today as well. My desktop and laptop are running current, as is "amp" (a dedicated current testing system), but my remote office workstation is running 14.2. My servers are running a mix of 14.1 and 14.2.

When 15 is released, I expect to install it on my desktop and laptop, and then only amp will run current.

Some servers will likely trickle over to 15 eventually, but 14.2 is still great for everything I need them to do, so most of them will likely stay 14.2 (much like how most of my servers remained 14.1 and were only slowly replaced with 14.2).