My thoughts on Slackware, life and everything

Tag: current (Page 2 of 7)

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.

KDE 5_17.02 for Slackware-current is available

I am happy to announce my February 2017 release of the ‘ktown’ packages: KDE 5_17.02. What you get in this new release is: KDE Frameworks 5.31.0, Plasma 5.9.2 and Applications 16.12.2. All built on top of Qt 5.7.1.
Soon, I will compile this version of Plasma 5 on Slackware 14.2 (only 64bit) as well, but I gave priority last few days to the new LibreOffice packages and a new PLASMA5 Live image. The packages that I am releasing today are for Slackware-current only (both 32bit and 64bit). As stated in my previous post, I will no longer be releasing Plasma 5 packages for 32bit Slackware 14.2.

What you also need to know is that I removed all packages and sources from my ‘ktown‘ repository that it still contained for Slackware 13.37 and 14.1. These were using up disk space that I needed on my ‘bear’ server. People who want the latest & greatest in KDE should upgrade to Slackware 14.2 or -current.

I also emptied the ‘testing’ area of the ‘ktown‘ repository. The packages in there were outdated and no longer gave you a working desktop environment. I plan to re-add some packages for testing there, once I have rebuilt the mesa / xorg-server / qt5 stack against Wayland so I can again check out the status on Slackware of the Wayland compositor in the Plasma Window Manager (kwin). But that is for another time.

What’s new in KDE 5_17.02?

  • Frameworks 5.31.0 is an enhancement release. See https://www.kde.org/announcements/kde-frameworks-5.31.0.php
  • Plasma 5.9.2 is the second iteration of the 5.9 series with small fixes only. See https://www.kde.org/announcements/plasma-5.9.2.php . I am not sticking with the long term support (LTS) releases of Plasma 5.8, as I think LTS should be targeting stable Slackware. If you want to know more about the long term support plans, go read: https://www.kde.org/announcements/plasma-5.8.0.php .
    This is my first release with Plasma 5.9 so it is worth mentioning some of the changes:

    • You will experience various visual and usability improvements all across the board.
    • A new network configurator was added to System Settings.
    • Global menus have finally been implemented in Plasma. This means that the application menus can be separated from the application windows: the menu can now be shown either in a Plasma widget or via a handle tucked into the window bar.
  • Applications 16.12.2 is an incremental fix-release in the 16.12 series. See https://www.kde.org/announcements/announce-applications-16.12.2.php .
  • The ‘deps’ section has four updated packages: OpenAL, libxkbcommon, phonon, wayland; and one recompiled package: qt5. I will not upgrade qt5 to 5.8.0 until the KWin developer gives it the green light.
  • Also worth mentioning: the KF5 ports of calligra, krita, ktorrent, partitionmanager, skanlite and the KDE Development Suite can be found in “kde/applications-extra” subdirectory. Packages for kjots (previously contained in KDEPIM) and kuser (which has been orphaned) have been moved into “kde/applications-extra” as well.

This upgrade should be relatively straightforward if you already have Plasma 5 installed. See below for install/upgrade instructions. For users who are running slackware-current, the most crucial part is making sure that you end up with Slackware’s packages for ‘libinput‘ and ‘libwacom‘. Failing to do so, may render your input devices (mouse and keyboard) inoperative in X.Org.

You may want to check out the new Plasma 5 before installing. For this purpose, I have generated a new Live ISO for the PLASMA5 variant based on an intermediate liveslak-1.1.6.2 release. Look for that ISO on http://bear.alienbase.nl/mirrors/slackware-live/latest/ . The timestamp of the “slackware64-live-plasma5-current.iso” file should be Feb 26 16, 2017.

Multilib considerations

If you install a 32bit program on a 64bit Slackware computer with multilib and that program needs legacy system tray support (think of Skype for instance), you will have to grab the 32-bit version of Slackware’s ‘libdbusmenu-qt’ and my ktown-deps package ‘sni-qt’, and run the ‘convertpkg-compat32 -i‘ command on them to create ‘compat32’ versions of these packages. Then install both ‘libdbusmenu-qt-compat32‘ and ‘sni-qt-compat32‘.
Those two are mandatory addons for displaying system tray icons of 32bit binaries in 64bit multilib Plasma5.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

You can skip the remainder of the article if you already have my Plasma 5 installed and are familiar with the upgrade process. Otherwise, stay with me and read the rest.

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in several subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4“, “kde4-extragear“, “frameworks“, “kdepim“, “plasma“, “plasma-extra“, “applications“, “applications-extra” and “telepathy“.

Upgrading to this KDE 5 is not difficult, especially if you already are running KDE 5_17.01. You will have to remove old KDE 4 packages manually. If you do not have KDE 4 installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.

What I usually do is: download all the ‘ktown’ packages for the new release to a local disk. Then run “upgrade –install-new” on all these packages. Then I check the status of my Slackware-current, upgrading the stock packages where needed. The slackpkg tool is invaluable during this process of syncing the package installation status to the releases.

Note:

If you are using slackpkg+, have already moved to KDE 5_17.01 and are adventurous, you can try upgrading using the following set of commands. This should “mostly” work but you still need to check the package lists displayed by slackpkg to verify that you are upgrading all the right packages. Feel free to send me improved instructions if needed. In below example I am assuming that you tagged my KDE 5 repository with the name “ktown” in the configuration file “/etc/slackpkg/slackpkgplus.conf“):
# slackpkg update
# slackpkg install ktown (to get the newly added packages from my repo)
# slackpkg install-new (to get the new official Slackware packages that were part of my deps previously)
# slackpkg upgrade ktown (upgrade all existing packages to their latest versions)
# slackpkg upgrade-all (upgrade the remaining dependencies that were part of my repo previously)

And doublecheck that you have not inadvertently blacklisted my packages in “/etc/slackpkg/blacklist“! Check for the existence of a line in that blacklist file that looks like “[0-9]+alien” and remove it if you find it!

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas. If you want to read them, here they are: http://alien.slackbook.org/blog/tag/kde5/

A note on Frameworks

The KDE Frameworks are extensions on top of Qt 5.x and their usability is not limited to the KDE Software Collection. There are other projects such as LXQT which rely (in part) on the KDE Frameworks, and if you are looking for a proper Frameworks repository which is compatible with Slackware package managers such as slackpkg+, then you can use these URL’s to assure yourself of the latest Frameworks packages for Slackware-current (indeed, this is a sub-tree of my KDE 5 repository):

The same goes for Frameworks for Slackware 14.2 (change ‘current’ to ‘14.2’ in the above URLs).

Where to get the new packages for Plasma 5

Download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ and  /14.2/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

Plasma 5_17.01 for Slackware

My previous post concerned itself with the question: what do I spend my time on? Keeping Plasma 5 working on Slackware 14.2 and -current, and for 32bit as well as 64bit architectures, is simply too time-consuming for a monthly release. I asked for your opinion and I was glad for all the feedback I have received. Predominantly, people are using 64bit Slackware and I saw both the stable 14.2 and the -current development tree mentioned. It looks like a small minority of people is running Plasma 5 on 32bit Slackware – not my target of choice but everyone has his or her own reasons and I am not here to doubt those.

So, here is the first 2017 release of the ‘ktown’ packages – KDE 5_17.01. I have updated the main package sets to their latest releases: KDE Frameworks 5.30.0, Plasma 5.8.5 and Applications 16.12.1. I have also updated the Qt  package to 5.7.1.
What can you expect of this and the future releases? You can still use this latest KDE 5 on Slackware 14.2 (only 64bit) but I will be focusing more on -current. After all, the ‘ktown’ development is all about getting the latest and greatest KDE software included in Slackware-current. This is how I think I am going to handle the releases:

I am going to do my releases first for Slackware64 14.2 and -current. During the days that follow, will compile the 32bit packages for Slackware-current. I will stop releasing Plasma 5 packages for 32bit Slackware 14.2.

What’s new in KDE 5_17.01?

  • Frameworks 5.30.0 is an enhancement release and contains one new framework compared to my previous release: prison. See https://www.kde.org/announcements/kde-frameworks-5.30.0.php
  • Plasma 5.8.5 is an incremental bug fix release for the 5.8 series. See https://www.kde.org/announcements/plasma-5.8.5.php and if you want to know more about the long term support (LTS) for Plasma 5.8, go read: https://www.kde.org/announcements/plasma-5.8.0.php
  • Applications 16.12.1 contains many changes. In these 16.12.x releases, some of the big packages have been split into many smaller ones: ‘kde-baseapps’, ‘kdepim’ and ‘kdewebdev’ (and these three packages are gone now).
    Two other packages have been removed: ‘gpgmepp’ (whose functionality has been integrated into ‘gpgme’), and ‘kuser’ (for which there is no replacement and therefore I have kept it as part of applications-extra).
    Formerly part of ‘kdepim‘, the ‘kdgantt2′ program has been removed and it is replaced by a new package ‘kdiagram‘. Another new package ‘kwave‘ was added in 16.12.0 (which I never built). See https://www.kde.org/announcements/announce-applications-16.12.1.php .
  • I have removed ‘kactivities‘, ‘nepomuk‘ and ‘nepomuk-widgets‘ from the kde4 package subset. These kdelibs4-based packages are no longer used by other packages.
    I also added a package there: ‘libcddb4‘ is the old kdelibs4 based version and it is needed to keep ‘k3b‘ running. The latest libkcddb is Frameworks5 based and incompatible with k3b.
    Unfortunately ‘kdepimlibs4‘ is still required by ‘kopete‘ and ‘klinkstatus‘. I had to recompile ‘kdepimlibs4‘ to remove gpgme++ files that are now part of the ‘gpgme‘ package. If you want to repeat this at home, make sure you only have ‘akonadi4‘ installed, not the newer ‘akonadi‘ from Applications.
  • In applications-extra, I upgraded ‘calligra‘ to the recently released Frameworks5 based version; a recompilation would have been needed anyway in order to ditch ‘kactivities‘. The new ‘calligra‘ has shed some of its code and no longer contains ‘krita‘ or ‘kexi‘, they are developed independently now. ‘Flow‘ and ‘Stage‘ have also been removed from the code but here the reason is that their code is un-maintained. Therefore I have added ‘krita‘ as a new package. If anyone needs ‘kexi‘ as well, let me know so I can add it (and its dependencies) next time. Also, ‘partitionmanager‘ (along with its dependency ‘kpmcore‘)  was upgraded and is now Frameworks5 based. Note: ‘partitionmanager‘ has issues using kdesu to gain root access to the disks even though it will ask for the root password. If all actions are greyed out, start it from the commandline with “sudo -s partitionmanager”.
  • The ‘kdeconnect-framework‘ package in plasma-extra was upgraded.
  • The ‘deps’ section has two new packages (three in the Slackware 14.2 repo as you can read below): ‘libdmtx‘ and ‘qrencode‘, both of which are requirements for the new ‘kdiagram‘ package. The ‘libinput‘ package was upgraded to the same version as was recently added to slackware-current (and compiled against the new package ‘libwacom‘ just like in slackware-current). Note that libinput and libwacom are not part of the ‘deps’ for Slackware-current since these are already covered by your Slackware install.
  • The ‘qt5‘ package was upgraded to 5.7.1, and accompanying upgrades were done for ‘qt5-webkit‘, ‘sip‘ and ‘PyQt5‘. Note that qt5’s dependencies have increased again: it now requires libinput, libwacom, libxkbcommon. I did not upgrade qt5 to 5.8.0 – it is too new and currently seems to have issues with KWin.

This upgrade should be relatively straightforward if you already have Plasma 5 installed. See below for install/upgrade instructions. For users who are running slackware-current, the most crucial part is making sure that you end up with Slackware’s packages for ‘libinput‘ and ‘libwacom‘. Failing to do so, may render your input devices (mouse and keyboard) inoperative in X.Org.

You may want to check out the new Plasma 5 before installing. For this purpose, I have generated a new Live ISO for the PLASMA5 variant. Look for that ISO on http://bear.alienbase.nl/mirrors/slackware-live/latest/ . The timestamp of the “slackware64-live-plasma5-current.iso” file should be Jan 27, 2017.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

You can skip the remainder of the article if you already have my Plasma 5 installed and are familiar with the upgrade process. Otherwise, stay with me and read the rest.

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in several subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4“, “kde4-extragear“, “frameworks“, “kdepim“, “plasma“, “plasma-extra“, “applications“, “applications-extra” and “telepathy“.

Upgrading to this KDE 5 is not difficult, especially if you already are running KDE 5_16.12. You will have to remove old KDE 4 packages manually. If you do not have KDE 4 installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.

What I usually do is: download all the ‘ktown’ packages for the new release to a local disk. Then run “upgrade –install-new” on all these packages. Then I check the status of my Slackware-current, upgrading the stock packages where needed. The slackpkg tool is invaluable during this process of syncing the package installation status to the releases.

Note:

If you are using slackpkg+, have already moved to KDE 5_16.12 and are adventurous, you can try upgrading using the following set of commands. This should “mostly” work but you still need to check the package lists displayed by slackpkg to verify that you are upgrading all the right packages. Feel free to send me improved instructions if needed. In below example I am assuming that you tagged my KDE 5 repository with the name “ktown” in the configuration file “/etc/slackpkg/slackpkgplus.conf“):
# slackpkg update
# slackpkg install ktown (to get the newly added packages from my repo)
# slackpkg install-new (to get the new official Slackware packages that were part of my deps previously)
# slackpkg upgrade ktown (upgrade all existing packages to their latest versions)
# slackpkg upgrade-all (upgrade the remaining dependencies that were part of my repo previously)

And doublecheck that you have not inadvertently blacklisted my packages in “/etc/slackpkg/blacklist“! Check for the existence of a line in that blacklist file that looks like “[0-9]+alien” and remove it if you find it!

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas. If you want to read them, here they are: http://alien.slackbook.org/blog/tag/kde5/

A note on Frameworks

The KDE Frameworks are extensions on top of Qt 5.x and their usability is not limited to the KDE Software Collection. There are other projects such as LXQT which rely (in part) on the KDE Frameworks, and if you are looking for a proper Frameworks repository which is compatible with Slackware package managers such as slackpkg+, then you can use these URL’s to assure yourself of the latest Frameworks packages for Slackware-current (indeed, this is a sub-tree of my KDE 5 repository):

The same goes for Frameworks for Slackware 14.2 (change ‘current’ to ‘14.2’ in the above URLs).

Where to get the new packages for Plasma 5

Download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ and  /14.2/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric

Updates for LibreOffice, Chromium, Calibre, QBittorrent, Veracrypt

I have been preparing a stable release of liveslak, and I wanted the PLASMA5 ISO to have up-to-date software taken from my own “alien” package repository. So I downloaded the latest sources and have prepared new packages for Slackware-current on which the Live ISOs are based, for the following:

  • LibreOffice:
    LibreOffice 5.1.3 is a minor update, focusing on bug fixes.
  • Chromium:
    Chromium 50.0.2661.102 is a security fix, addressing 5 CVE’s. Some days earlier I already uploaded a newer version of the PepperFlash plugin for Chromium. Note that Google no longer releases 32bit versions of its Chrome browser, so that the PepperFlash and Widevine plugins will see only 64bit updates.
  • Calibre:
    Nothing really exciting about the new 2.56.0 version. Kovid Goyal keeps improving this e-book library management program at a steady rate. Its GUI uses Qt5 so this is a natural inclusion for the Plasma5 Live ISO.
  • QBittorrent:
    Version 3.3.4 is the latest of this great bittorrent client with a Qt4 based GUI (I have not switched to its new Qt5 based GUI yet)
  • Veracrypt:
    The successor of TrueCrypt when that program stopped being developed. VeraCrypt fixes many (security) bugs that were still present in TrueCrypt. Its development continues with the 1.17 release while remaining compatible with older TrueCrypt containers.

Now we just need to cross fingers and hope that there will be a release of Slackware 14.2 soon, so that I can create definitive versions of Slackware Live Edition.

Packages for the aforementioned software can be obtained from these mirror sites and probably others too:

Cheers! Eric

Package recompilation effort underway

alienHey folks! Two things recently happened to Slackware-current that you need to be aware of if you are using my Plasma5 packages from the ‘ktown‘ repository.

  1. libical was upgraded. The new shared library has a different version number, breaking several applications in my Plasma 5 package set. Mostly these are KDEPIM related.
  2. the openssl upgrade  dropped support for the obsolete OpenSSL SSLv2 protocol (by eliminating the ‘SSLv2_client_method’ symbol) in order to address the “DROWN” vulnerability. This broke applications that are linking against openssl using this symbol.

This means I have to recompile several packages; the PIM related ones are kcalcore, kcalutils, kblog, ktnef, kalarmcal, akonadi-calendar, kdepim-runtime, kdepim and kdepimlibs4 (I did kdepimlibs earlier this week). Packages linking to the removed SSLv2 symbol are qt5 and qca-qt5.

This will take some time on my trusty old build-box. The 64-bit PIM packages are done, Qt5 is compiling, qca-qt5 is next. Then I need to repeat for 32-bit and be aware that compiling Qt5 is quite a lengthy process… I won’t have new packages to upload until friday evening probably.

Then I intend to compile new Plasma 5.5.5 (just released, it’s the last in the 5.5 series) and generate new Slackware Live ISO images. Don’t stay up for those… will probably be on the other side of the weekend before you see those, because I need to test some updates to the liveslak scripts first.

Somewhere inbetween I should also take care of the new Chromium sources which were just released, addressing several vulnerabilities. By the way, this new 49.0.2623.75 release is the first where Google is only releasing 64-bit binaries for Linux, so I am afraid that at some point the 32-bit plugins I used to extract from the Chrome binaries (pepperflash and widevine plugins) will stop working for the 32-bit chromium packages which I will of course keep compiling for you. The most recent versions of these binary-only plugins remain in my repository until they break.

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders NorenUp ↑