Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 374 other subscribers

My Favourites

Slackware

Calendar

April 2018
M T W T F S S
« Mar    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current

RSS SBo

Meta

Plasma5 – April 18 edition for Slackware

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!

New package for qbittorrent, now based on Qt5

Not related per se to the fall-out of last weekend’s update to the icu4c and poppler packages, my qbittorrent package for slackware-current had stopped working sometime ago – caused by an update in -current of the boost package on which the torrent library depends.

I needed to update qbittorrent too therefore, after having taken care of the icu4c/poppler breakage. The thing is, I had tried to delay the switch in qbittorrent from Qt4 to Qt5 for as long as possible. The ‘new’ 4.x series of qbittorrent have a hard dependency on Qt5, and Qt4 is no longer supported. So I bit the bullet and made packages for bittorrent-4.0.4 and its dependency, libtorrent-rasterbar-1.1.6.
Since the program uses Qt5 now, the dependencies have changed. If you were running qbittorrent 3.x on slackware-current previously then you have to ensure that you have libxkbcommon, qt5 and qt5-webkit packages installed now.

For good times’ sake, I have kept the old SlackBuild scripts and sources but I renamed them to libtorrent-rasterbar10.SlackBuild and qbittorrent3.SlackBuild. If you want the old Qt4 based interface back, then compile the two packages using these SlackBuild scripts (first libtorrent-rasterbar, then qbittorrent). You can install either the new, or the old versions. They can not be co-installed.

Fun and games in -current when ABIs break

Oh my.
It was not an April Fools joke when the ChangeLog.txt of slackware-current mentioned the following (I left out the non-relevant package updates):

 

+--------------------------+
Sun Apr 1 02:53:26 UTC 2018
...
l/icu4c-61.1-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.
...
l/poppler-0.63.0-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.

All of us  who follow Slackware’s development know that “shared library version bump” means ABI breakage. I.e. a lot of 3rd-party binaries will suddenly not find required library versions anymore. In particular icu4c and poppler are nasty beasts. Slackware’s own packages had been carefully updated and recompiled where needed of course, so there was no breakage in the distro itself. But many people do not run a bare Slackware installation… a lot of software is usually installed on top. And that is the software which will be affected by an incompatible change like this one on April 1st.

What’s this  version bump all about? How is it possible that it affects your computer so deeply?

Most programs depend on other programs. Software developers hate to re-invent the wheel if they can avoid it. Lots of lower-level or widely used functionality has been put into software libraries. Think of network access functionality, text rendering, encryption etc – smart people have created useful, efficient and robust software and stuffed that code into libraries. Your own program can link against these libraries at run-time and access the functionality they have to offer and your program needs.
If many programs link to the same libraries, that reduces the memory footprint because a library has to be loaded into memory only once even if many programs are using it. These libraries are therefore called ‘shared libraries‘ or ‘shared objects‘ (hence the extension ‘.so‘) or also dynamic libraries. For this dynamic linking to work, programs use binary interfaces at runtime that were established when the program was compiled and linked.
A shared library version only needs to change if the Application Binary Interface (ABI) changes. When that happens, all binaries that depend on the library need to be recompiled to adjust to the new ABI.
Among others, an ABI depends on the machine architecture, and on the toolchain (compiler, linker) used to generate the binary code from its sources. An ABI guarantees binary compatibility: the program will work on every machine with the same ABI, without a need for recompilation.

When will an ABI usually change?

One case is when the library’s API (Application Programming Interface, i.e. the way in which access to the library routines is defined in its source code) changes. This mostly occurs in software that is not yet stable and where its programmers add new functionality or revise the methods of calling the library’s functionality. Mature software on the other hand has a well-defined API which is rarely subject to change.

Another case is when the toolchain is updated. Slackware’s toolchain has been very stable and ABI changes have seldomly been introduced. As an example, Patrick talks about the a.out to ELF migration and the libc5 to glibc migration in a 2012 interview.

So why does well-established software like icu4c and poppler change their ABI almost on every minor release, thereby pissing off a really large crowd? You tell me. Arrogance or sloppiness, but let’s attribute it to bad project management. Because it probably could have been avoided in many if not all cases.

Anyway, some of you upgraded first to this new batch of updates in -current, then found out that some 3rd party packages stopped working, and then started looking for a cause.
Folks: if you are running slackware-current, you always check the ChangeLog.txt first. And if you spot a “shared library version bump” you stop right there and assess the situation. Some friends on LinuxQuestions were a bit more vocal about the way they had found themselves at a dead Plasma5 screen… others understood the situation better and and realized they had to wait for 3rd party packagers to update their repositories instead of assuming ill will.
If you are unable to cope with this kind of occasional breakage, use a stable Slackware release. That’s what all of us have been telling you all along.

My packages have been affected as well:

  • Plasma 5 stopped working,
    The fix is to recompile several packages among which a number of big ones: qt5, qt5-webkit and calligra. That means, you will have to have patience. The 64bit repository has been updated in the meantime. After upgrading from my ‘ktown’ repository your Plasma5 will again be fully functional. The 32bit repository updates will hopefully follow tomorrow have been uploaded now. I had to restart the 32bit qt5 compilation because of an internal compiler error halfway.
    The updated Plasma5 will even have some new functionality – since i slipped in the KMymoney program which otherwise would have been introduced at the April update of ‘ktown‘.
  • LibreOffice stopped working.
    The 64bit packages have been recompiled. They have been updated actually since there was a micro source version bump from 6.0.3.1 to 6.0.3.2 yesterday – my luck! The 32bit packages have to wait until after ‘ktown‘ updates have been completed and then I will upload them. New libreoffice packages for -current are now available.
  • Pale Moon stopped working.
    I was able to recompile the packages inbetween the Plasma5 compilation because it only takes little time. The updated palemoon packages are already in my repository.
  • Calibre stopped working.
    This will have to wait until after all the other updates New calibre packages for -current are now available..

And probably other stuff is broken too but I have not yet spotted that. If you find breakage, please report it so that I can recompile the package.

What all happened in March so far

I realize I have been a wee bit silent on the blog (not counting my replies in the comments section). This was due to private issues that drained the desire for social interactions. Nevertheless there was quite a bit of activity on the Slackware packaging front.

So, what new stuff?

First of all: yesterday, Adobe released a security update for their Flash plugins for Mozilla-compatible (NPAPI) and Chromium-compatible (PPAPI) browsers. Check the version 29.0.0.113 installation status on http://get.adobe.com/flashplayer/about/. You are encouraged to upgrade.

Chromium browser was updated twice… last week I made the final release in the 64 series available and today (repositories have not been updated yet) I am updating again, to the 65 release. Version 65.0.3325.146 comes with a large list of 45 security fixes, read the release notes to get the gist. Unfortunately, this new release has cost me a full week of recompiles, day & night, all the time running into new compilation errors. It was not trivial to come up with a set of patches that eradicated all the compilation errors. I wrote a couple myself, reverted a chromium commit and borrowed from Gentoo – thanks as always for these guys’ code troubleshooting skills. The discussion on the Chromium Packagers list has given me some ideas for the next iteration of the SlackBuild script that may not require this much patching. But I am pushing this version to my repository anyway, even though I just spotted a newer version on the Google blog… released yesterday. Damn.

Pale Moon browser got an update to  27.8.1. Many improvements and fixes over the 27.7.x versions, check their release notes for the details. Despite the fact that the new Mozilla Firefox is much improved as well, and a lot speedier since Mozilla switched to the Quantum codebase, people may still prefer the older codebase of Firefox from which Pale Moon was forked.

LibreOffice 6.0.2 was released last week and I built packages for Slackware 14.2 as well as -current. Still the best office suite available. I should try to build the LibreOffice online version sometime…

When Slackware 14.2 was graced with an updated set of gcc packages in the “patches” section (gcc-5.5.0 with a series of patches related to retpoline countermeasures for the recent Meltdown/Spectre vulnerabilities) I took the opportunity not only to give the multilib repository for Slackware 14.2 a refresher to gcc-5.5.0_multilib, but I also updated the gcc5 package for slackware-current in my regular repository to that 5.5.0 release – including the retpoline patches. Remember, my gcc5 package for slackware-current contains just the C, C++ and Java compilers and has two purposes: first it re-introduces  the GCC Java compiler which was removed in gcc-7; and second, compiling Pale Moon on slackware-current can not be done with its gcc-7 compiler… you need this gcc5 package.

E-book lovers with a fondness for organizing their collection using open source software will find a new Calibre package in my repository. Calibre 3.x for Slackware 14.2 and -current depends on libxkbcommon, podofo, qt5, qt5-webkit and unrar, and for Slackware 14.2 two additional dependencies are libinput and libwacom. All of those can be obtained from my repository as well. If you are not in need of an e-book catalogue and library program, then Calibre still has its usefulness as it includes a versatile E-book reader and a powerful EPUB editor.

Last but not least: I released a new set of Plasma5 packages. The KDE-5_18.03 release of ‘ktown‘ for Slackware-current offers the latest KDE Frameworks (5.44.0), Plasma (5.12.3) and Applications (17.12.3). Read the README file for more details and for installation/upgrade instructions. If you are adventurous, check out the ‘testing‘ variant of the ktown repository as opposed to the ‘latest‘ variant. In ‘testing’ you will find Wayland support. Note that this is experimental (hence the ‘testing’ tag of course) and not fit for day-to-day production work. The ‘latest’ repository contains a stable and productive, complete, and fun to use, Plasma 5 desktop environment.
One thing I want to mention is that I have added the new Falkon browser to the applications-extra section. Falkon is the renamed Qupzilla browser, based on Qt5, and it is destined to be added to the core Applications (not sure when precisely, probably later this year) and it will take the place of the venerable Konqueror. If you are using slackpkg with the slackpkg+ extension, don’t forget to run “slackpkg install ktown” to get the new falkon package installed, because “slackpkg install-new” will not catch new packages in 3rd-party repositories like ‘ktown’.

I promise to get a new PLASMA5 variant of the Slackware Live ISO image out soon, containing all this new stuff! Stay tuned for more.

Security updates for OpenJDK 7 and 8

icedteaAs you know, I use the IcedTea framework to compile my openjdk/openjre packages. Andrew Hughes (aka GNU/Andrew) who is the release manager has announced new versions of IcedTea: 2.6.13 which builds Java7 (OpenJDK 7u171_b02) and also icedtea-3.7.0 for Java8 (OpenJDK 8u161_b12). These releases sync the OpenJDK support in IcedTea to the January 2018 security fixes for Java.

The announcements will surely be posted on Andrew’s blog soon, but for now I leave you with the posts to the “distro-pkg-dev” mailing list: icedtea-2.6.13 and icedtea-3.7.0. These posts contain the list of security issues that have been fixed.

As always, it is very much recommended that you upgrade your OpenJDK or OpenJRE packages to the latest version.

Here is where you can download the Slackware packages for openjdk and openjre (this is Java8):

And the Slackware packages for openjdk7 and openjre7 (Java7 for those who still need this):

Note that the “rhino” package (implementation of the JavaScript engine used by OpenJDK) is an external dependency for OpenJDK 7, you can find a package in my repository.

If you want to compile OpenJDK (Java 7 or 8) yourself you will need apache-ant as well.

Note about usage:

My Java 7 and Java 8 packages (e.g. openjdk7 and openjdk… or openjre7 and openjre) can not co-exist on your computer because they use the same installation directory. You must install either Java 7 or Java 8.

Remember that I release packages for the JRE (runtime environment) and the JDK (development kit) simultaneously, but you only need to install one of the two. The JRE is sufficient if you only want to run Java programs (including Java web plugins). Only in case where you’d want to develop Java programs and need a Java compiler, you are in need of the JDK package.