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 369 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

Meta

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.

New Live ISOs for Slackware-current 20180209

blueSW-64pxI have uploaded a fresh set of ISOs for the Slackware Live Edition. They are (of course) based on the ‘liveslak‘ scripts and contain the latest Slackware-current dated “Fri Feb 9 19:59:54 UTC 2018“), which sports the new 4.14.18 kernel which is mitigated against the Meltdown and Spectre v1 vulnerabilities.
The ISO variants you will find at the download URL https://slackware.nl/slackware-live/latest/ (remember to add support for CACert to your system if you see certificate warnings!) are:

  • Full unmodified Slackware (32bit and 64bit).
  • Stripped-down XFCE (32bit as well as 64bit), this ISO will fit on a CDROM medium.
  • Slackware with MATE instead of KDE4 (64bit) to showcase the new 1.20 release of just 2 days ago. Thanks to Willy Sudiarto Raharjo for the packaging!
  • Slackware with Plasma 5 instead of KDE4 (64bit) to showcase the Plasma 5.12 Long Term Support (LTS) release. This ISO also contains LibreOffice 6.0.1 and VLC 3.0.0.

The new liveslak version 1.1.9.6 has seen only a few updates since the previous tag, they are related to the package additions in Plasma 5.

Wayland and X.Org

The PLASMA5 ISO image does not feature Wayland support this time, but if you want you can build an ISO version that does! Download my liveslak scripts and use the following command to generate a PLASMA5 ISO (you will find it in /tmp afterwards) with the additional packages from my ‘testing’ repositories that add Wayland support:

# git clone --depth 1 git://bear.alienbase.nl/liveslak.git
# cd liveslak
# ./make_slackware_live.sh -d PLASMA5 -m plasma5wayland -M -X

If you run a Wayland-enabled Slackware Live, you can login to a regular X.Org Plasma5 session but you can also choose the “Plasma – Wayland” session from the SDDM dropdown menu.

Refreshing your USB stick instead of re-formatting

If you already use a Slackware Live USB stick that you do not want to re-format, you should use the “-r” parameter to the “iso2usb.sh” script. The “-r” or refresh parameter allows you to refresh the liveslak files on your USB stick without touching your custom content. If you want to modify other parameters of your USB stick, use the script “upslak.sh“. It’s main feature is that it can update the kernel on the USB stick, but it also can replace the Live init script. As with most (if not all) of my scripts, use the “-h” parameter to get help on its functionality.

Historical info on liveslak

More detail about the features of Slackware Live Edition can be found in previous posts here on the blog.

Have fun!