One of my previous posts discussed “ABI breakage” and how that affects software to the point where it breaks and you need to recompile stuff to un-break it. Well… last week was most likely another, bigger, surprise to many of you. The Slackware-current ChangeLog.txt update of “Thu Apr 19 01:04:06 UTC 2018” started with:
Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the longest ChangeLog entry in project history). There were two primary motivations for rebuilding everything in the main tree. The first was to switch to the new C++ ABI. The second was to get rid of all the .la files in the LD_LIBRARY_PATH.
That was fun, seeing 1365 lines of ChangeLog and realizing how long the upgrade would take!
But in the end, this was a painless migration. WIth a simple “slackpkg update ; slackpkg upgrade slackpkg” to upgrade the slackpkg package itself. Don’t forget to check the new /etc/slackpkg/mirrors file to see if your mirror is still configured there! Followed by “slackpkg update ; slackpkg install-new ; slackpkg upgrade aaa_elflibs ; slackpkg upgrade-all” and a lot of patience. That’s about all there was to it and after a reboot the Slackware-current system would run as well as ever. A big accomplishment and hats off to Patrick Volkerding who used the past months to (mostly under the radar) update all the SlackBuild scripts and write wrappers to enable him to recompile all of Slackware from scratch, while gaining a lot on the efficiency and time management front. Kudos!
Ah well, a painless migration you heard me say…
Unless you have a ton of 3rd party software bolted onto your Slackware – like my Plasma5… because that came out pretty much broken. On the Slackware forum as well as here on the blog I already advised to hold off with upgrading for a day or so to give me the opportunity to at least recompile Plasma5.
And it so happened that the KDE developers already had all-new source code tarballs waiting for us. I compiled that on the freshly rebuilt Slackware-current and yesterday evening I uploaded my new set of Plasma5 packages to the ‘ktown‘ repository.
The KDE-5_18.04 release of ‘ktown‘ for Slackware-current offers the latest KDE Frameworks (5.45.0), Plasma (5.12.4) and Applications (18.04.0). The Qt5 was upgraded to 5.9.5. Read the README file for more details and for installation/upgrade instructions. Enjoy the latest Plasma 5 desktop environment.
So, what’s new?
- I had to deal with a couple of packages that were broken after the massive upgrade in Slackware, so I took the opportunity to upgrade gpgme, mlt, poppler and qt5 to a newer version; and I added QScintilla to extend the package (already available in Slackware) with support for Qt5.
- In plasma-extra the kdeconnect-framework package was updated.
- Applications 18.04.0 is the start of a new round of improvements. Two new packages are available starting with 18.04: kamoso which is a webcam recorder, and a backup program kbackup. The instant messenger client Kopete was ported to KF5 and is contained in the source distribution, but I was unable to compile it. Perhaps more luck next month.
Finally, the hex editor okteta moved to the ‘applications-extra’ section because its developer no longer wants to be tied to Application release windows. - In applications-extra I have upgraded the kdiagram and krita packages.
If you want to read more about the history of Plasma5 development for Slackware, with lots more detail, check out my older blog posts. If you think a git log is easier to read, check out my ktown git repository instead 🙂
If you are using slackpkg with the slackpkg+ extension, don’t forget to run “slackpkg install ktown” to get any new packages installed, because “slackpkg install-new” will not catch new packages in 3rd-party repositories like ‘ktown’.
I hope to get a new PLASMA5 variant of the Slackware Live ISO image out soon, containing all this new stuff! This depends on my ability to recompile LibreOffice 6.0.3 for 64bit. I ran into a bit of a snag there with gpgme-related compilation errors I have as of yet not been able to fix. Also, VLC3 needs a rebuild since that broke too… and I have not been able to find the time to address that.
Enjoy the new batch!
Thanks Eric, work here 😉
Just a little thing, ‘kholidays’, is in frameworks; now.
Ok,’kholidays’ is in frameworks, but two versions appear here, (17.12.3 and 5.45.0) , in gslapt 😉
Sorry for the noise, Eric, it’s because, my gslapt is on wayland mirror 😉
Thank you very much.
I have found some old libpoppler in kile and calligra.(visualcompare)
you an asshole to my people grow up. People that code are real. treat them nice.
Eric, basically he blame you for “pushing” the Qt5 builds for Slackware, which in his very opinion, in the final “polluted” the “innocent minds” of SBO contributors, resulting in his business issues.
Folks, doing business on some software downloaded or built from whatever scripts downloaded from Internet, who are distributed with NO GUARANTEE of properly work or whatever, and without being able to manage them yourself or your own employees, it is plain ridiculous.
Even the Slackware itself comes with NO GUARANTEE. Use in your business at your very own risk.
Yeah, after another beer and having read the thread on LQ, that still doesn’t make sense. Maybe I need a third beer? ¯\_(?)_/¯
The response from “Ginni,” that is.
cryfs is also linked with the old version of boost
Looks like digikam needs a bit of TLC. Am getting digikam: symbol lookup error: /usr/lib64/libdigikamcore.so.5.9.0: undefined symbol: _ZN5Exiv213XmpProperties10registerNsERKSsS2_
Can I just take this opportunity to reiterate my thanks to you, Eric, for the hours and hours you give so that users like me can enjoy and benefit from an excellent distribution. It is hugely appreciated. Kudos. Ta.
Matt
To address all the reports about packages in ‘ktown’ that still had issues:
Sun Apr 22 12:54:32 UTC 2018
current/deps/cryptopp: updated.
current/deps/cryfs: rebuilt.
current/kde/applications-extra/calligra: rebuilt.
current/kde/applications-extra/digikam: rebuilt.
current/kde/applications-extra/kile: updated.
Soon coming to a repository near you.
Thanks, Eric!
Now everything looks OK on Plasma.
And specially thanks for the LibreOffice and VLC3 updates.
With all, RE thank you, Eric 😉
Thanks Eric for all your work.
Just one note regarding the changes to -current, Patrick is now building his packages without any .la files. Most of your packages follow this but some of them this do.
Here is a list the packages with .la file in /usr/lib64/ that are installed on my system (mostly ktown but also a few for your sborepo and restricted:
/var/log/packages# grep *alien -lo -Ee “usr/lib64/.[^/]*\.la$”
accountsservice-0.6.45-x86_64-1alien
cracklib-2.9.6-x86_64-1alien
farstream-0.2.8-x86_64-1alien
libaccounts-glib-1.23-x86_64-2alien
libappindicator-12.10.0-x86_64-2alien
libburn-1.4.8-x86_64-1alien
libdbusmenu-gtk-12.10.2-x86_64-2alien
libdmtx-0.7.4-x86_64-2alien
libindicator-12.10.1-x86_64-2alien
libnice-0.1.14-x86_64-1alien
libotr-4.1.1-x86_64-1alien
libpwquality-1.4.0-x86_64-1alien
libsignon-glib-1.14-x86_64-1alien
libxkbcommon-0.8.0-x86_64-1alien
openconnect-7.08-x86_64-3alien
qrencode-3.4.4-x86_64-1alien
qt5-webkit-5.9.1-x86_64-3alien
telepathy-farstream-0.6.2-x86_64-3alien
telepathy-glib-0.24.1-x86_64-4alien
telepathy-logger-0.8.2-x86_64-5alien
telepathy-mission-control-5.16.4-x86_64-2alien
vlc-3.0.2-x86_64-1alien
wayland-1.14.0-x86_64-1alien
Hope this helps
Cheers
Greg
Is it possible to include this qt5 path for this bug?
https://bugreports.qt.io/browse/QTBUG-52616
It’s hard to work without this fix with KRDC
Well… it is a two-year old bug, so I am not exactly in a hurry to fix it, now that you mention it.
I’ll think of it next time qt5 needs a recompile.
Edit: on second thought after having read a related bug report https://bugreports.qt.io/browse/QTBUG-62542 – the developers state “This is an intrusive patch that adds QPA apis. It won’t be backported to Qt 5.9“. I will skip this one. Sorry.
I fixed the kopete compilation issue and uploaded a package for it to my repository.
If you are using slackpkg+ and have my repository configured as ‘ktown’ all you need to do is “slackpkg update ; slackpkg install ktown” to get the new package(s).
Eric, maybe you want to update the GPGME again?
As you probably know, Patrick Volkerding updated it to version 1.11.1
Yeah, but no time. Too busy with work.
Hi Eric…
My scenario is: 64–current syncronized wih all Pat’s new things, your multilib and ktown packages. Nvidia prop drivers ( 64-390.48 version).
When I fire “startx”, a little bit time after i have one of my 8 cores-cpu at 100%, due to a kwin_x11 –session (htop monitored).
If i kill it, all becomes fine with no fans screaming in my computer case. After killing that, obviously some other kwin_x11 sessions remain in bacground.
Other issue: every time “kscreenlocker_greet” starts after some minutes, i receive a black screen with something similar to “kscreenlocker had crashed; flip over a console and give *loginctl –unlock* and return to graphic session ( ok, i dont’ remember the right words but the above is a good approx. The program “loginctl” des not exist in my system….
Any suggestion?
Till now i have give a “chmod -x kscreenlocker_greet” as a workaround.
Thanks (again and again…) for your work…
HP
Hubert Phava, what repository URL are you using for my ktown? The error message about “loginctl” should never occur with my “latest” repository. It is triggered by the existence of the login1 service, which is only offered by systemd-logind and elogind. Those are not in my repository.
The CPU stress issue and kscreenlocker crashes also hint at a software incompatibility, whether it is the Nvidia driver or the Plasma5 software I can not tell.
I use the “latest” repo from your ktown, downloaded with wget and installed with “upgradepkg –install-new –reinstall” in init1 mode. Done this from your very first plasma release and no problems at all, with screensaver till now.
Boh…. I’ll try nvidia-beta stuff…
Thanks Eric
Hubert, did you follow my ktown README from release to release where I tell you what packages to remove (when relevant)? You may have ended up with obsoleted cruft.
Darth Vader, tonight I found time. I updated gpgme and patched a bug out of powerdevil.
Thank you for your efforts, Eric!
Eric: your ktown-Readme hab been my bile till my first installation of your packages.
Now, setting the -x flag to kscreenlocker_greet seems to be a good choice: i have a blank screen and no crashes
🙂
HP
Eric, I got the same ‘loginctl unlock-sessions’ mention by Hubert Phava. I only use packages from Slackware itself and from your ktown, with the exception of VirtualBox and slackpkg+. I left my virtual machine(virtualbox), which runs Slackware Current, upgrading while I went to work, and I just came back and saw that message.
I did ‘slackpkg update’ > ‘install-new’ > ‘upgrade-all’ and went work, and didn’t run yet the ‘clean-system’ neither ‘install ktown’. I will do now, only posting as notation. Cheers and ty for your hard work!
I ran ‘slackpkg clean-system'(lots to be removed) >> ‘install ktown'(some to install) and the previous message didn’t showed again, appears was either a obsolete package or a missing one.
Gustavo – I assume your problem was the same as with Hubert – a left-over package (perhaps elogind, or else ConsoleKit2 from my wayland-testing repository). When you removed that, the loginctl error was gone and so were the incompatibilities.
I noticed in the logs of the Freenode ##slackware channel that people are wondering why I release a package for Falkon without the SlackBuild script.
Those people are wrong.
I always release my packages along with their build scripts.
For the Plasma5 packages in ‘ktown’ I use an evolved version of the kde.SlackBuild script which you can find in Slackware itself. That single SlackBuild script generates all of the KDE packages.
If you want to know more about how that script works, read an older article of mine: https://alien.slackbook.org/blog/kde-bugfixes-and-how-to-use-my-modular-kde-slackbuild/
If you can’t read or you’re simply can’t be arsed to take the time to read, but still want to compile falkon, simply run:
# ./kde.SlackBuild applications-extra:falkon
Hi Eric,
Somewhere between Mar 21st (the last time I used Kdenlive) and now, I’ve lost the ability to render to mp4 (h264). Prior to the last 2 kde updates, I was building melt and kdenlive myself. I’m updated with slackware-current, and latest kde and multilib.
melt -query “video_codecs” shows:
– h261
– h263
– h263p
– h264_nvenc
– h264_vaapi
– nvenc
– nvenc_h264
– nvenc_hevc
… but no h264 and
ffmpeg -formats shows:
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp2 MP2 (MPEG audio layer 2)
DE mp3 MP3 (MPEG audio layer 3)
E mp4 MP4 (MPEG-4 Part 14)
and ffmpeg -codecs shows:
DEV.L. mpeg4 MPEG-4 part 2 (decoders: mpeg4 mpeg4_v4l2m2m mpeg4_vdpau mpeg4_cuvid ) (encoders: mpeg4 mpeg4_v4l2m2m )
D.V.L. msmpeg4v1 MPEG-4 part 2 Microsoft variant version 1
DEV.L. msmpeg4v2 MPEG-4 part 2 Microsoft variant version 2
DEV.L. msmpeg4v3 MPEG-4 part 2 Microsoft variant version 3 (decoders: msmpeg4 ) (encoders: msmpeg4 )
I’m not sure if Kdenlive is using melt or ffmpeg for the encoding support … but I’ve rebuilt x264 from SBO, and mlt/kdenlive from your build scripts and problem still occurs: when trying to render to mp4 I get a red x next to mp4 render option. Also Settings -> Config Wizard shows:
“the following codecs were not found on your system: aac, libx264, libx265”
Here are my libs:
ls -al /usr/lib64/libx264*
lrwxrwxrwx 1 root root 14 Apr 30 12:34 /usr/lib64/libx264.so -> libx264.so.148*
-rwxr-xr-x 1 root root 1011272 Apr 30 12:34 /usr/lib64/libx264.so.148*
Sorry for the long message. Any ideas?
Robby – I think that the slackware ffmpeg package lacks support for x264 and x265. It’s supported by my own ffmpeg packages. Could it be that your computer has reverted to the stock ffmpeg packages?
Grrrr Argh Whah! Not only possible but actual! I forgot to put ffmpeg in my slapt-get exclusion list. Thanks Eric!
Hi Eric, I just would like to tell you that today’s -current update updated poppler and thus kile, texstudio and other packages cannot use texlive. Can you rebuild your poppler package if possible? Thanks!
Eduardo, see my repository: https://slackware.nl/alien-kde/current/latest/
Master Eric-wan Kenobi, speaking of Devil, in your latest build is something strange:
Looks like that the SDDM read the config file from “/etc/sddm.conf” WHILE the associated KCM handle “/etc/kde/sddm.conf”, so it has zero effect. 😉
I talk about your fresh build, to be announced.
Darth, that would be strange.
Straight from the commit https://cgit.kde.org/sddm-kcm.git/commit/?id=c879e4fa438f4cb029f1e73784489869b0d48314 comes this comment:
Hmmm on the other hand, the cmake script for plasma packages defines “KDE_INSTALL_SYSCONFDIR=/etc/kde” so perhaps that overrides that “/etc/” default… investigation is needed.
Yes, the SDDM do its job as expected. SO, it really reads the “/etc/sddm.conf”, and I guess that’s what this pull request expects too.
BUT, the Login Manager (for SDDM) page from the System Settings will read and write the config file “/etc/kde/sddm.conf”, which is ignored by SDDM at all.
So, whatever configurations you make on System Settings will not be used by SDDM at all.
How I found that?
I have the habit to create a new fresh user in my “playground” computer, when I upgrade your Plasma5.
However this computer is also used by family (and contains nothing important, if we ignore my younger son claims overs his precious cartoons), then I have the habit to use the auto-login to that particular user.
So, I proceeded today as root (if have importance), intending to switch the auto-login to the brand new user.
And followed a WTF moment…
OK I fixed the sddm-kcm package and it will appear in the repository soon.
OK, thank you!