A story of remembrance and gratefulness towards Joe Mann.
Today 76 years ago, on September 19th 1944, a young US soldier called Joe Mann gave his life to save that of his comrades. He jumped on a grenade thrown by a German soldier and died a hero. This was the day after Eindhoven was liberated from the Nazis.
No one knew at the time, but the war in the Netherlands would not end until 8 months later, causing countless civilian deaths during the “hunger winter” of 44/45.
A monument was erected for Joe Mann a few years back, and my wife and I walk the surrounding area a lot, so yesterday we stopped at the monument to contemplate the bravery and fate of this young man. This is a picture of the place:
The inscription reads: “On 19 September 1944, Joe E. Mann as soldier at this place gave his young life to save the lives of his comrades.“
The Document Foundation recently released version 7.0.0 of their Libre Office suite of applications. The packages for Slackware-current can be found in my repository. But the situation for Slackware 14.2 used to be different – I got stuck after LibreOffice 6.2 because the newer source releases (6.3 and onwards) require versions of system software that our stable Slackware 14.2 platform does not offer.
From time to time during the last year, when there was time and the build box was not compiling packages, I messed around with the libreoffice.SlackBuild script in futile attempts to compile recent versions of LibreOffice on Slackware 14.2. I failed all the time.
Until last week. After I had uploaded the new KDE Plasma5 packages to ‘ktown‘, I had an epiphany and decided to use a new approach. What I did was: question all the historic stuff in the SlackBuild script that got added whenever I needed to work around compilation failures; and accept that the compilation needs newer versions of software than Slackware 14.2 offers. The first statement meant that I disabled patches and variable declarations that messed with compiler and linker; and for the second statement I stuck to a single guideline: the end product, if I were able to compile a package successfully, has to run out of the box on Slackware 14.2 without the need to update any of the core Slackware packages.
So I ended with a script that only has two new compile-time requirements: use the ‘unsupported‘ gcc 9.2.0 compilers instead of Slackware’s ageing gcc-5.5.0. And update gperf to the version you find in Slackware-current. The rest of the required supporting libraries will be compiled into LibreOffice automatically. And this time, the LibreOffice sources compiled without errors.
The resulting binaries would however fail to run on a regular Slackware 14.2 (with the stock versions of gcc and gperf packages) because of missing symbols in the dynamically linked system libraries.
I managed to get around that issue, by adding the two runtime support libraries that come with gcc-9.2.0 (libgcc_s.so.1 and libstdc++.so.6) into the ‘program’ directory of LibreOffice. Those libraries contain the symbols LibreOffice is looking for; a simple runtime dependency on gcc.
By the way: you cannot expect everybody to install a set of compilers just to run programs, Slackware solves this dilemma by adding the GCC runtime libraries to the ‘aaa_elflibs‘ package which is usually one of the first packages to get installed on a new system.
That worked! LibreOffice 6.4.5 for Slackware 14.2 is now available in my package repository. And I even built LibreOffice 7.0.0 in the same manner. I stuck with 6.4.5 because I want people to be able to use a stable and well-established version of an office suite on the stable Slackware platform. The more experimental 7.0.0 release is for Slackware-current.
Guess what! Today, just when I uploaded the 6.4.5 packages I noticed that the release of LibreOffice 6.4.6 has been announced (and in October we’ll see the final release in the 6.4 cycle – being 6.4.7).
I will try to find some time to compile those fresh tarballs; but first I do like feedback about the new 6.4.5 packages that are now downloadable for Slackware 14.2.
The release announcement gives a concise overview of the new features and enhancements all over the board – among which a much improved support for Microsoft Office document file formats. I will not repeat all of that here on the blog, so please check out the content behind above link.
Amazing that even with several big companies driving the development of this Open Source office suite, still 26% of LibreOffice’s code contributions come from non-corporate individuals.
LibreOffice and KDE Plasma5
The libreoffice.SlackBuild script is now defaulting to building KDE5 (aka Plasma5) support. It will generate errors if you try to compile on a system that does not have KDE Frameworks5 and libdbus-qt5 installed. See the README.kde5 in the source: you can get all of them from my ‘ktown‘ repository.
Or, if you do not want to install KDE5 components, you set the value of the “ADD_KDE5” variable in the script to “NO”.
Note that you can safely install the KDE support package on a system that does not have any trace of KDE; it will simply do nothing.
Java support dropped from the libreoffice Slackware package
One caveat with the new packages is that to build Java support into them, one will need Oracle JDK 9 or higher. I do not have OpenJDK 9 or higher in my repositories and I will not, until IcedTea adds support for these versions. Until then, I stick with Java 8 and that means I had to disable Java support in the libreoffice packages that I compile from source. There’s a new variable in the libreoffice.SlackBuild script, “USE_JAVA“, and it defaults to “NO”. If you want to recompile the packages adding Java support, get a recent enough JDK from Oracle and be sure to also install Apache Ant.
What is Java used for in LibreOffice? LibreOffice is written primarily in C / C++, a language that generates programs called “native” designed for specific platforms. There are versions for Windows, Linux or Solaris, but not for all three at the same time. However, some modules can be written in other languages, including Java.
Specifically, currently (as of version 6.3) at least these components/functionality require Java:
HSQLDB (optionally used for embedded database in Base; default is Firebird that doesn’t depend on Java)
Some wizards (particularly, Table/Query/Form/Report Wizards in Base)
ReportBuilder (used to generate actual reports from report templates in Base)
Non-Linear solvers built-in extension (DEPS and SCO) in Calc (there is an experimental Swarm solver that doesn’t depend on Java)
MediaWiki extension (Wiki Publisher)
Support for scripts and extensions written in Java/Beans
I hope none of you are in dire need of this functionality, in that case I would suggest installing the official binaries from the Document Foundation and a Oracle JDK (or JRE) version 9 or higher.
Also, this is a .0.0 release – do you feel that you can use this release as your daily driver? Should I make the previous 6.4.5 available somehow (not that I would like that)? Note that these packages are available only for Slackware-current anyway, and that is a testing ground already.
New Plasma5 packages for Slackware-current are ready for download & installation. I skipped July (holiday season) and so here is KDE-5_20.08 aka my August 2020 release. Be sure to read the upgrade instructions very carefully to prevent breakage, because starting with my June batch the goal is to remove Slackware’s ConsoleKit2 and replace it with elogind!.
It would not harm if you (re-)read my previous blog article about Plasma5, “Replacing ConsoleKit2 with elogind – first steps“. It has a lot more detail about the reasons for this move as well as guidance on using the Wayland Window Manager (as a test) instead of regular X.Org. Note that Wayland sessions still need a lot of maturing and X.Org will remain Slackware’s default choice.
A repeat from that article: with elogind as the session/seat manager instead of ConsoleKit2, you’ll see some new behaviour. A quite obvious change: if you run ‘startx’ or ‘startkwayland’ at the console, you won’t see a VT (virtual terminal) switch. In the past, your console TTY would usually be tty1 but your graphical session would start on tty7 and you would automatically be switched from tty1 to tty7. This is no longer true – the graphical session will re-use your console TTY.
SDDM is still starting on tty7 but only because I make it do so via its configuration file.
Deps: The ‘deps’ section got a bit smaller again this month:
pcaudiolib, espeak-ng, hack-fonts-ttf, noto-fonts-ttf, and noto-cjk-fonts-ttf were moved into the actual Slackware distro. Things are progressing nicely in that regard.
flite has been removed since Pat decided we will go with just espeak-ng.
a new package ‘pipewire’ was added as a dependency for krfb and xdg-desktop-portal-kde.
The elogind-aware dbus package was upgraded to match the Slackware version.
Finally, qca-qt5 was upgraded and I recompiled mlt (to fix the broken kdenlive) and speech-dispatcher.
Frameworks 5.72.0 is an incremental stability release, see: https://kde.org/announcements/kde-frameworks-5.72.0. A new ‘kdav’ source tarball got added but that is actually the same package you’ll find in KDEPIM. Next batch, the actual kdav package will be built from Frameworks sources.
For applications-extra, I updated digikam, krita, libktorrent and ktorrent, and skanlite.
Note that the size of the digikam source tarball ‘blew up’ due to the addition of new neural network facial recognition data files, but the actual package ‘only’ grew from 97 to 108 MB.
KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.
Not so visible but important nevertheless is this month’s contribution of Patrick Volkerding who validated all the KDE slack-desc files and enhanced/polished a lot of them. He also cleaned out the ‘patches’ directory and removed all the obsolete patches that are not being applied anymore. As you also will have noticed, Pat is slowly picking packages out of my ‘deps’ and adding them to Slackware. Even espeak-ng which I had not expected to happen.
Where to get KDE Plasma5 for Slackware
It should be obvious, but these packages will not work on Slackware 14.2. The old (KDE 5_17.11) Plasma5 packages that were still in my ‘ktown’ repository for Slackware 14.2 were removed in May 2020 because they were un-maintained and had security issues.
Check out the README file in the root of the repository for detailed installation or upgrade instructions.
BIG FAT WARNING: Read these README instructions carefully if you do not yet have elogind installed (i.e. if you did not install the ktown June 2020 release previously)!
UPGRADE TO THE LATEST slackware-current first.
Then, REMOVE the ConsoleKit2 package if you had not installed my June ktown batch before.
Next, install or upgrade the KDE5 package set.
Change to directory /usr/share/sddm/scripts/ and move the Xession.new & Xsetup.new files into place (remove the .new extension) after carefully checking that you are not overwriting your own customizations in the Xsession & Xsetup scripts. Note: because “slackpkg new-config” only looks inside the /etc/ directory it will miss the two scripts in /usr/share/sddm/scripts/.
You’ll still have to manually check /etc/ for some critical *.new files that need to be put into place if you are not using slackpkg (which does this *.new check at the end of its run).
Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ and this month’s development took place in the ‘elogind‘ branch. I will fold these elogind developments back into the master branch soon.
Here is a new program for inclusion into my DAW package collection. It is Sonic-Pi, a ‘code-based music creation and performance tool’ as its web site states. My DAW collection already features Supercollider, which at its core is a powerful audio synthesis engine, but it also features a graphical user interface which you can use for live-coding music. Sonic-Pi has similar capabilities but it is more intuitively accessible (compare it to vi and notepad for instance).
Therefore Sonic-Pi would be better suited for introducing people to the concept of creating music through writing code, and letting that music evolve during a live performance by updating on-the-fly the code which represents the audio synthesis.
Sam Aaron is the creator of Sonic-Pi and uses it as a musical instrument in its own right with his band. He did a TEDx talk about programming as performance a couple of years ago:
He explains how Sonic-Pi was conceived as an educational tool. By making a free and open-source program like Sonic-Pi available to schools (and it runs on the Raspberry Pi – now you know where the program got its name from), you will gently introduce young kids to the art of computer programming while at the same time infusing them with a love for music – because they will be able to create the music they like in no time.
Sonic-Pi uses the synthesis engine of Supercollider, which means that that has to be installed as well. Both Sonic-Pi and Supercollider use JACK to route the audio and let it come out of your speakers.
The graphical user interface allows easy access to a large collection of example code snippets, sound samples and synthesizer definitions, so you will be listening to music in a few seconds after starting the program – after which you can begin modifying that code and hear live what your programming does to the generated music. The GUI also contains a nice visualization of the music you are generating.
The software is usually distributed as an ‘appimage’ which simply bundles everything you need into an archive. This is not really Slackware-like, so I wrote a SlackBuild script which brings some order into the directory structure, removing a lot of redundant megabytes and creating a proper package with a nice menu item.