Category Archives: Software

Google muzzles all Chromium browsers on 15 March 2021

Ominous music

A word of caution: long rant ahead. I apologize in advance.
There was an impactful post on the Google Chromium blog, last friday.  I recommend you read it now: https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

The message to take away from that post is “We are limiting access to our private Chrome APIs starting on March 15, 2021“.

What is the relevance I hear you ask.
Well, I provide Chromium packages for Slackware, both 32bit and 64bit versions. These chromium packages are built on our native Slackware platform, as opposed to the official Google Chrome binaries which are compiled on an older Ubuntu probably, for maximum compatibility across Linux distros where these binaries are used. One unique quality of my Chromium packages for Slackware is that I provide them for 32bit Slackware. Google ceased providing official 32bit binaries long ago.

In my Slackware Chromium builds, I disable some of the more intrusive Google features. An example: listening all the time to someone saying “OK Google” and sending the follow-up voice clip to Google Search.

And I create a Chromium package which is actually usable enough that people prefer it over Google’s own Chrome binaries, The reason for this usefulness is the fact that I enable access to Google’s cloud sync platform through my personal so-called “Google API key“. In Chromium for Slackware, you can logon to your Google account, sync your preferences, bookmarks, history, passwords etc to and from your cloud storage on Google’s platform. Your Chromium browser on Slackware is able to use Google’s location services and offer localized content; it uses Google’s  translation engine, etcetera. All that is possible because I formally requested and was granted access to these Google services through their APIs within the context of providing them through a Chromium package for Slackware.

The API key, combined with my ID and passphrase that allow your Chromium browser to access all these Google services are embedded in the binary – they are added during compilation. They are my key, and they are distributed and used with written permission from the Chromium team.

These API keys are usually meant to be used by software developers when testing their programs which they base on Chromium code. Every time a Chromium browser I compiled talks to Google through their Cloud Service APIs, a counter increases on my API key. Usage of the API keys for developers is rate-limited,  which means if an API key is used too frequently, you hit a limit and you’ll get an error response instead of a search result. So I made a deal with the Google Chromium team to be recognized as a real product with real users and an increased API usage frequency. Because I get billed for every access to the APIs which exceeds my allotted quota and I am generous but not crazy.
I know that several derivative distributions re-use my Chromium binary packages (without giving credit) and hence tax the usage quota on my Google Cloud account, but I cover this through donations, thank you my friends, and no thanks to the leeches of those distros.

Now, what Google wants to do is limit the access to and usage of these Google services to only the software they themselves publish – i.e. Google Chrome. They are going to deny access to Google’s Cloud Services for all 3rd-party Chromium products (i.e. any binary software not distributed by Google).
Understand that there are many derivative browsers out there – based on the Open Source Chromium codebase – currently using a Google API key to access and use Google Cloud services. I am not talking about just the Chromium packages which you will find for most Linux distros and which are maintained by ‘distro packagers’. But also commercial and non-commercial products that offer browser-like features or interface and use an embedded version of Chromium to enable these capabilities. The whole Google Cloud ecosystem which is accessible using Google API Keys is built into the core of Chromium source code… all that these companies had to do was hack & compile the Chromium code, request their own API key and let the users of their (non-)commercial product store all their private data on Google’s Cloud.

Google does not like it that 3rd parties use their infrastructure to store user data Google cannot control. So they decided to deliver a blanket strike – not considering the differences in usage, simply killing everything that is not Google.
Their statement to us distro packagers is that our use of the API keys violates their Terms of Service. The fact is that in the past, several distros have actively worked with Google’s Chromium team to give their browser a wider audience through functional builds of the Open Source part of Chrome. I think that Google should be pleased with the increased profits associated with the multitude of Linux users using their services.
This is an excerpt from the formal acknowledgement email I received (dating back to 2013) with the approval to use my personal Google API key in a Chromium package for Slackware:

Hi Eric,

Note that the public Terms of Service do not allow distribution of the API
keys in any form. To make this work for you, on behalf of Google Chrome
Team I am providing you with:

    -
    Official permission to include Google API keys in your packages and to
    distribute these packages.  The remainder of the Terms of Service for each
    API applies, but at this time you are not bound by the requirement to only
    access the APIs for personal and development use, and
    -
    Additional quota for each API in an effort to adequately support your
    users.

I recommend providing keys at build time, by passing additional flags to
build/gyp_chromium. In your package spec file, please make an easy to see
and obvious warning that the keys are only to be used for Slackware. Here
is an example text you can use:

# Set up Google API keys, see
http://www.chromium.org/developers/how-tos/api-keys .
# Note: these are for ... use ONLY. For your own distribution,
# please get your own set of keys.

And indeed, my chromium.SlackBuild script contains this warning ever since:

# This package is built with Alien's Google API keys for Chromium.
# The keys are contained in the file "chromium_apikeys".
# If you want to rebuild this package, you can use my API keys, however:
# you are not allowed to re-distribute these keys!!
# You can also obtain your own, see:
# http://www.chromium.org/developers/how-tos/api-keys

It effectively means that I alone am entitled to distribute the binary Chromium packages that I create. All derivative distros that use/repackage my binaries in any form are in violation of this statement.

On March 15, 2021 access to Google’s Cloud services will be revoked from my API key (and that of all the other 3rd parties providing any sort of Chromium-related binaries). It means that my Chromium will revert to a simple browser which will allow you to login to your Google account and store your data (bookmarks/passwords/history) locally but will not sync that data to and from your Google Cloud account. Also, location and translation services and probably several other services will stop working in the browser. Effectively, Google will muzzle any Chromium browser, forcing people to use their closed Chrome binaries instead if they want cross-platform access to their data. For instance, using Chrome on Android and Chromium on Slackware.
Yes, Chrome is based on Chromium source code but there’s code added on top that we do not know of. Not everybody is comfortable with that. There was a good reason to start distributing a Chromium package for Slackware!

Now the one million dollar question:

Will you (users of my package) still use this muzzled version of Chromium? After all, Slackware-current (soon to become 15.0 stable) contains the Falkon browser as part of Plasma5, and Falkon is a Chromium browser core with a Qt5 graphical interface, and it does not use any Google API key either. Falkon will therefore offer the same or a similar feature set as a muzzled Chromium.
If you prefer not to use Chromium any longer after March 15, because this browser lost its value and unique distinguishing features for you, then I would like to know. Compiling Chromium is not trivial, it takes a lot of effort every major release to understand why it no longer compiles and then finding solutions for that, and then the compile time is horribly long as well. Any mistake or build failure sets me back a day easily. It means that I will stop providing Chromium packages in the event of diminishing interest. I have better things to do than fight with Google.

Please share your thoughts in the comments section below

FYI:

There are two threads on Google Groups where the discussion is captured; the Chromium Embedders group: https://groups.google.com/a/chromium.org/g/embedder-dev/c/NXm7GIKTNTE  – and most of it (but not all!) is duplicated in the Chromium Distro Packagers group: https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM – I advise you to read the cases made by several distro packagers and especially take good care of how the Google representatives are answering our concerns. There’s more than a tad of arrogance and disrespect to be found there, so much that one poster pointed the Googlers that take part in the discussion (Director level mind you; not the friendly developers and community managers who have been assisting us all these years) to the Chromium Code of Conduct. I am so pissed with this attitude that I forwarded the discussion to Larry Page in a hissy fit… not that I expect him to read and answer, but it had to be done. Remember the original Google Code of Conduct mantra “Don’t be evil”?

December updates and a Christmas goodie for cable geeks

The silent treatment?

Hi there.
I know I have not been posting a lot the past few months. Sorry for that, really.
The last quarter is always a busy time at work and especially so during Corona; my mother fell ill; I sort of crashed when I ran out of energy; and it was a lot of work to clean up shop after my Plasma5 ‘ktown’ first got adopted as Slackware ‘vtown’ in testing and a bit later replaced the old KDE4 in the core distro. Lots of package recompilations and upgrades to work with the newer stuff in Slackware.

I also worked on (finally) migrating the old ‘bear’ server which was hosted in France, to a newer and more powerful server running in an Amsterdam Data Center. The new server ‘martin’ was mostly ready when I thought, let’s reboot ‘bear’ after applying the latest Slackware security fixes. And then it did not come back up… that was not a comfortable moment, since ‘bear’ not only hosts my own package and git repositories, but also The Slack Docs Wiki, the Slack Docs mailing lists, my own personal Wiki and some private family sites. I opened a support ticket and it turned out that the hard drive had crashed and all data on it were irrecoverable.
Luckily I had just finished making a set of backups and right before that fateful reboot, had discovered that my backup scripts omitted part of the server data… which I had also fixed just in time before  that crash.
It took some additional energy to get the services up and running on ‘martin’ again as soon as possible. I had made some new designs for the new server OS configuration and the new configs were un-tested… I hope not too many people noticed the partial down during the second half of November.
The new server runs fine now, has more disk space especially, so I can finally host the full history of Slackware releases and also the DAW and CINNAMON Live ISO images for which there was no room on ‘bear’.
Thanks again to those people who send me money un a regular basis so that I can pay the monthly rent of ‘martin’!

Despite that stress I have been enjoying myself still, just not in the spotlights. The semi-sudden switch in Slackware from KDE4 to Plasma5 and refreshing its XFCE Desktop had some consequences for my liveslak project. It took some time to work out a new optimal package set for the small XFCE image, and in particular the DAW Live image which is based on a bare Plasma5 Desktop needed attention to make it tick again.

So what’s new in Slackware DAW Live?

Remember: DAW = Digital Audio Workstation.
Read my original article documenting the research into a comprehensive collection of musician/producer oriented free and open source software, and a follow-up article on how to transform a Slackware system into a powerful Digital Audio Workstation.

Art work

I asked you in a previous post to come up with ideas for artwork to use in my Slackware Digital Audio Workstation. Thanks for those who contributed graphics and ideas – all of that creativity has been preserved here on the blog.
I decided to use the image to the left of this paragraph – a Slackware ‘S’ with headphones – as the icon to use for the “Slackware Live DAW” submenu. Contributed by Daedra and slightly colored by me.

I needed a second icon as well, to represent the ‘face’ of the Live user account, and for that I picked one of the contributions from Bob Funk: a Slackware ‘S’ with a TRS jack. You’ll see this one when you boot up the ISO and are asked to login at the SDDM graphical session chooser.

More art work was contributed by Sceptical-C, a friend of mine who doubles as a DJ, musician and producer. His black and white photography are the basis for several Plasma5 wallpapers and one of his photographs is also used as the background in the login and lock screens.

DAW_base package

I decided to move the configuration  of the DAW Live OS’ realtime capabilities out of the liveslak scripts and into a new Slackware package. This package called “daw_base” can be installed on any Slackware computer (preferably Slackware-current with PAM). It configures the OS in such a way that a user who is a member of the Slackware “audio” group is allowed to start applications with real-time scheduling priority. You’ll need that if you want to prevent sound drop-outs (also called XRUNs) during performing, recording and mixing. Some more tweaks are being made, they are documented in the package’s README.1st file. This package also contains the Plasma5 wallpapers which are created from the original Sceptical-C black-and-white artwork.
The package creates a new sub-menu in “Applications > Multimedia” called “Slackware DAW” and collects all my DAW related software in there. The submenus in “Multimedia” for the X42 and LSP plugins are moved into the “Slackware DAW” menu to keep it all closely together. This is very similar to what DAW Live also contains. Just the word “Live” is not present in the name of that menu installed by ‘daw_base‘.

The daw_base package also installs a template file for Slackware’s package manager ‘slackpkg‘. The template called “daw” contains a list of all DAW related software in my package repository and it allows for an easy installation and maintenance of that software collection.

New additions to the musician’s toolkit

Several packages needed a recompilation after the recent Slackware upgrades that are related to the new requirements for XFCE and Plasma5. I used that opportunity to upgrade software to their latest versions instead of recompiling – like Ardour, Mixxx, Jamulus, Guitarix for instance. But I also looked into some new stuff, mostly because people asked me about it. Here they are:

Zrythm.
An intuitive digital audio workstation all in itself. It’s under heavy development and nearing a 1.0.0 release. It supports LV2 plugins, offers a high level of automation, and looks really good. Perhaps an alternative for those who feel Ardour’s learning curve is too steep.

VCV Rack.
VCV Rack by the VCV project is a software emulation of the Eurorack Modular Synthesizer.
The project’s mission statement contains this line which resonated with me: “… the principle behind modular synthesizers is identical to the UNIX philosophy, where stable, minimal modules working together are preferred to a monolithic platform controlled by a single vendor (like portable synthesizer keyboards)“.

A short intermezzo first. My first experience with modular synths was as part of the audience when attending a concert by Pere Ubu, 1981 in De Effenaar in EIndhoven. Alan Ravenstine handled a huge contraption full of patch wires that produced all sorts of weird and interesting sounds. It’s what gave Pere Ubu their uniquely distinctive sound. I read later that he worked with EML modular synthesizers a lot but at the time I didn’t know. Damn impressive, but I decided that industrial sounds were more to my liking. This was during the early rise of Electronic Body Music, and that got me hooked for a while. If you can find the documentary “I dream of WIres” I recommend you watch it. The web site http://idreamofwires.org/ is dedicated to documenting the history of electronic music. An excerpt of a little more than 20 minutes is freely available, it contains an interview with Pere Ubu synth players Alan Ravenstine and Robert Wheeler.

Anyway – back in May 2019, a blog comment by ‘Hank’ already referenced VCV Rack with a question whether I would perhaps consider it for inclusion to my DAW software collection. At the time, my focus was on other things and a modular synthesizer is not the easiest instrument to work with, so I let that pass. But some recent youtube footage sparked my interest and here is the result – a Christmas present of sorts for you: packages for VCV Rack, and three free and open source plugins that expand the collection of available modules in Rack: vcvrack, vcvrack-audible-instruments, vcvrack-befaco and vcvrack-bogaudio.

Note that my VCV Rack package ‘vcvrack‘ contains the Fundamental plugin already. The software is quite useless without it so I decided to bundle it, just like the dev’s binary distribution. It is the only plugin which is automatically loaded by VCV Rack. If you install any other plugin, you need to execute one manual command to add the plugin to your user-directory: this will create a symbolic link to the ZIP file containing the modules and Rack will then automatically find and unzip this plugin and make it available to you.

$ ln -s /usr/share/vcvrack/Pluginname.zip ~/.Rack/plugins-v1/

All ZIP files in the VCV Rack system directory (/usr/share/vcvrack/) are module plugins – this is the format for distributing them.

Here is a Youtube tutorial series that you can use as an introduction to modular synthesis and VCV Rack in particular:

Enjoy! Eric

Today, Plasma5 replaces KDE4 in Slackware

Finally. It’s the major step towards a first Beta release of Slackware 15.0!

Pat used this past weekend to merge the ‘vtown’ packages in the Slackware-current testing area into the core distro. The result is a ChangeLog.txt entry that is 680 lines long… lots of package removals due to KDE4 having been replaced with Plasma5.

Mon Dec 7 21:49:58 UTC 2020
Goodbye vtown... we hardly knew you.
It is indeed the day of the Big Merge(tm) leaving nothing left in /testing (but
I'll try to work on that soon). In addition to merging packages from /testing,
Qt4 and related packages have gone away, along with some other libraries that
were only used by KDE4. Perhaps someone will want to take up maintenance of Qt4
(but I'm also pretty sure that SBo wouldn't touch that build script with a ten
foot pole). ConsoleKit2 is gone, replaced by elogind (which also takes over for
cgmanager and pm-utils).
Huge thanks to Eric Hameleers, Heinz Wiesinger, and Robby Workman for all the
help making this possible.
There's still more cleanup to do here, but that'll be easier with everything in
the main tree instead of maintaining side installs running the /testing
packages.
I'll look into what can be done about extra/pure-alsa-system/ soon.
Enjoy! :-)

Let’s see how quickly the remaining rough edges are smoothed out.
I don’t know when I’ll find the time to clean up the ‘ktown’ repository and generate new Slackware Live ISOs. At least, I prepared the liveslak sources already for the event. If only daytime job did not eat up all my energy. Also please tell me which packages in my repository need recompiling due to this major upgrade.

Addendum 2020-12-08 19:21 CET: How to upgrade?

Option 1:

If you never installed my ‘ktown’ Plasma5 packages before, and if you never installed the ‘vtown’ version of Plasma5 in the testing area of Slackware-current, then the upgrade is trivial if you are using slackpkg (the slackpkg+ extension is not needed):

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

The final “slackpkg clean-system” may be challenging for people who installed a lot of custom / 3rd-party packages, since those will be mixed into the output. See below for a one-liner command that will remove all packages from your system that are no longer part of Slackware since the switch from KDE4 to Plasma5.

Option 2:

If you installed Slackware’s ‘vtown’ version of Plasma5 from Slackware’s own testing area you will probably have edited “/etc/slackpkg/slackpkg.conf” to give the ‘testing’ packages priority over the regular packages. You need to revert this edit now. Meaning that this line:

PRIORITY=( testing patches %PKGMAIN extra pasture )

needs to be changed back to:

PRIORITY=( patches %PKGMAIN extra pasture testing )

If in addition you are using the slackpkg+ extension, you also need to edit “/etc/slackpkg/slackpkgplus.conf” to remove the priority for ‘testing:vtown’  by changing the PKGS_PRIORITY line. Suppose that line looks like this:

PKGS_PRIORITY=( multilib testing:vtown mylocal64 mylocal32 restricted alienbob mate )

then you only need to remove the ‘testing:vtown’ string:

PKGS_PRIORITY=( multilib mylocal64 mylocal32 restricted alienbob mate )

If you removed my ‘ktown’ repository from slackpkgplus.conf (check PKGS_PRIORITY, REPOPLUS and MIRRORPLUS statements) you can re-add it safely now. I cleaned the ‘ktown’ repository and it contains just one package now: phonon-vlc which did not get added to Slackware since that does not have vlc either.
This is all the preparation you need.
Next run the standard commands to perform a regular upgrade:

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

Again, that last command will scare some people who have a lot of 3rd-party packages installed and don’t want to check many tens of entries one by one to see what needs to be kept.

Clean-system?

The final step is to remove all packages that got removed when KDE4 gave way to Plasma5. The ChangeLog.txt entry for this “Big merge” shows all of those with the tag “Removed.” at the end of the line. So here is a single very long commandline which fetches the ChangeLog.txt from the official mirror, finds the ChangeLog entry for the “Big Merge”, locates all “Removed.” lines and extracts the package names from them. That is then fed into a “removepkg” command so that all these packages are actually removed from your computer. This is a safe move.
Here we go. As root. run a test first (the ‘warn does not actually remove anything, it just shows you what it would remove):

# wget -q -O - http://slackware.osuosl.org/slackware64-current/ChangeLog.txt | sed -n -e '/Mon Dec  7 21:49:58 UTC 2020/,/Sat Dec  5 20:36:27 UTC 2020/p' |grep 'Removed.' |cut -d: -f1 | rev |cut -d/ -f1 |cut -d- -f4- |rev |sort |xargs removepkg --warn

You will probably notice some “No such package: XXXXX. Can’t remove.” messages, those are harmless, you obviously did not have some (KDE4) packages installed anymore.

If you are confident about the command (ensure that there are TWO spaces after ‘Dec’ for instance) you run this:

# wget -q -O - http://slackware.osuosl.org/slackware64-current/ChangeLog.txt | sed -n -e '/Mon Dec  7 21:49:58 UTC 2020/,/Sat Dec  5 20:36:27 UTC 2020/p' |grep 'Removed.' |cut -d: -f1 | rev |cut -d/ -f1 |cut -d- -f4- |rev |sort |xargs removepkg

Have fun – Eric

Ktown becomes Vtown

So it is finally happening.
On US Election Day 2020, Pat Volkerding added “vtown” into the ‘testing’ directory of Slackware-current.

The “vtown” in Slackware is essentially my ‘ktown’ repository containing KDE Plasma5 plus its dependencies, with a few exceptions, a number of my packages removed, some caveats and a couple of renamed packages.

A lot of useful information from early adopters can already be found on linuxquestions.org in the dedicated thread about vtown.

One of the benefits of this testing version of Plasma5 in Slackware is the merging of several Slackware and ktown packages.
Mostly because I needed to provide Qt5-supporting versions of existing Slackware packages, I needed different names for the ‘ktown’ versions that I was going to provide. I could not risk that people would end up with old Slackware Qt4 based packages which would break Plasma5.
So to avoid clashing with packages like “plasma-nm”, “attica”, “baloo”, “kscreen” etc… I had to use alternative package names like “plasma5-nm”, “attica-framework”, “baloo5”, “kscreen2” and several (actually, many) more.
Here is the full list of my packages that got merged back into packages with the original Slackware names:

attica-framework -> attica
baloo5 -> baloo
baloo5-widgets -> baloo-widgets
grantlee-qt4 -> grantlee
kactivities-framework -> kactivities
kfilemetadata5 -> kfilemetadata
kscreen2 -> kscreen
libdbusmenu-gtk -> libdbusmenu (dropping Qt4 support)
libdbusmenu-qt5 -> libdbusmenu-qt
libkscreen2 -> libkscreen
phonon-qt4 -> phonon (dropping Qt4 support)
plasma5-nm -> plasma-nm
polkit-kde-framework -> polkit-kde-agent-1
polkit-qt5-1 -> polkit-qt-1

There’s also some packages that are new, but given a different name than I did for ‘ktown’: my “qtav” becomes “QtAV’, “phonon-gstreamer” becomes phonon-backend-gstreamer” and “sddm-qt5” becomes “sddm”.

Here’s a list of the packages that did not make it into ‘vtown’ at all:

ddcutil (nothing uses it anymore)
drumstick (only used by vmpk now, and that is not part of Slackware)
freecell-solver (needed by kpat)
kaudiocreator (obsoleted, use k3b or soundkonverter instead)
kblog (no longer included in Applications)
kdelibs (KDE4 - no longer relevant)
klettres (future maintenance will be in ktown, no external deps)
kpat (needs freecell-solver, maybe rename to kpatience if I keep maintaining it)
ktuberling (future maintenance will be in ktown, no external deps)
kwebkitpart (lost its relevance)
labplot (future maintenance will be in ktown, no external deps)
md4c (no longer needed, was a past dep for building qt5)
perl-path-tiny (dep for freecell-solver)
perl-template-toolkit (dep for freecell-solver)
phonon-qt4-gstreamer (obsoleted)
phonon-vlc (needs VLC and I will keep maintaining this in ktown)
python3-random2 (dep for freecell-solver)
sni-qt (nice to have for Qt4 apps with systray icon? Needs libdbusmenu-qt4 which will no longer be in Slackware)
user-manager (deprecated)

Now the big question: how to upgrade?

Assuming you use slackpkg to manage Slackware updates, first edit “/etc/slackpkg/slackpkg.conf and ensure that the line:

PRIORITY=( patches %PKGMAIN extra pasture testing )

is changed to:

PRIORITY=( testing patches %PKGMAIN extra pasture )

This gives higher priority to those new ‘vtown’ packages. Then run:

slackpkg update

The next steps depend on what you currently have installed.

Upgrade from Slackware’s KDE4 to the ‘vtown’ Plasma5 in Slackware’s testing:

That should be easy. If you still have KDE4 installed, run

slackpkg remove kde
slackpkg remove ConsoleKit2
slackpkg install vtown
slackpkg upgrade vtown

I have not tested those “slackpkg install vtown; slackpkg upgrade vtown” commands so if that does nothing, then instead, you need to download the whole testing/packages/vtown directory from an internet mirror and then run:

upgradepkg --install-new --reinstall testing/packages/vtown/deps/*.t?z
upgradepkg --install-new --reinstall testing/packages/vtown/kde/*.t?z

Upgrade safely from my ‘ktown’ to the ‘vtown’ in Slackware’s testing:

That is a good question! I am still running ‘ktown’ because due a medical emergency in the family I do not have enough free time to test this properly. People asked for a blog post so that’s about all I can manage and it has eaten most of today’s free time already unfortunately. Share your experiences in the comments section below and I will update the main article with better info as it becomes available.

What I think will work is this (assuming you are also using slackpkg+ to manage your 3rd party repositories) and thanks to akimmet who posted these instructions in another blog post after having gone through the upgrade himself:

slackpkg update
slackpkg upgrade-all
slackpkg remove ktown kde kdei ConsoleKit2

Now, edit “/etc/slackpkg/slackpkgplus.conf” to remove (or de-activate) all definitions of “ktown”, and instead add “testing:vtown” to your PKGS_PRIORITY list. Then run:

slackpkg update
slackpkg install vtown
slackpkg upgrade vtown
slackpkg install LibRaw autoconf-archive exiv2 poppler

The last line will re-install the few packages that were in my ‘ktown’ but also part of Slackware core. They were upgraded by Pat in Slackware core instead of in ‘vtown’ and thus the “slackpkg remove ktown” removed those permanently.

Remember: perform this upgrade from a console in runlevel 3!
Tell me how it went! Remember, this stuff is now in Slackware ‘testing’ not because the Plasma5 software sucks and crashes but because this means a big and intrusive update to Slackware and it is best to give way to the early adopters to find the remaining kinks in the new packages.

Eric

 

Warning about Python3 update in latest -current

Warning for people running Slackware-current and have 3rd party packages installed (who doesn’t) that depend on Python3. That includes you who are running KDE Plasma5!

The “Sun Oct 25 18:05:51 UTC 2020” update in Slackware-current comes with a bump in the Python3 version (to 3.9) which is incompatible with software which already has been compiled against an older version of Python3 (like 3.8).

I found 26 of my own packages on my laptop that depend on Python3 and they are all probably going to break when upgrading to the latest slackware-current. This includes Plasma5 ‘ktown’ packages but also several of my DAW packages.

I suggest that you wait with upgrading to the latest -current for a short while. Give Pat a chance to add Plasma5 to Slackware, because I am not going to recompile any ‘ktown’ package over this.
I will however look at my other packages (cecilia5, wxpython to name but a few) and recompile those against the newer Python. Watch this space for more news.