Ktown becomes Vtown

Posted on by

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

Posted on by

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.

Chromium 86 update resolves critical security issue

Posted on by

chromium_iconGoogle developers have released Chromium 86 to the public. Head over to the “Stable Channel” blog to read more details about this new major version.

And then get the fresh packages for chromium-86.0.4240.75 ! This is an urgent upgrade request, because the new release plugs a critical security hole in the online payments code which gives the attacker full access to your local machine (CVE-2020-15967: Use after free in payments).

Chromium 86 addresses 34 other security issues, none of the others are critical.

The 86 release comes with some nice new features, like:

  • Background Tab Throttling: the tabs that you have open in the background get ‘throttled’ after 5 minutes of inactivity, so that they consume at most 1% of the CPU time.
  • HTTP forms on a HTTPS page: Chromium will warn you if you are about to enter form data over an insecure connection embedded in a secure web page.
  • Quick password check enhancements: in the Settings page for passwords (chrome://settings/passwords) you’ll find a “password check” button which validates your stored passwords against the database of leaked passwords. And now in Chromium 86, it will attempt to automatically open the “password change” page for affected web sites that conform to the  “well-known URL for changing passwords” W3C draft specification which many web sites already adopted after Apple initially introduced the feature.

But also this is useful to know:

  • FTP protocol depreciation: In Chromium 86, support for FTP URLs will be disabled for 1% of users, but you can still re-enable FTP URL support via the “–enable-ftp” commandline parameter to chromium. In Chromium 87, the support for FTP will be disabled for 50% of the active users and Chromium 88 will no longer support FTP links.
    The expectation is that Chromium 88 hits the “stable channel” on January 19th, 2021. Be warned!

Slackware packages for Chromium 86.0.4240.75 are in my package repository as 64bit and 32bit versions for both Slackware 14.2 and -current. See: https://slackware.nl/people/alien/slackbuilds/chromium/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium/)

Enjoy! Eric

Liveslak new features, DAW Live, OBS Studio, logo contest

Posted on by

I wanted to update you about a couple of my projects that I was able to spend time on, now that I took some time off of work. I need to distance myself from my day job every so often to prevent a burn-out and this time I am dangerously close.
I baked bread for the first time in years and it was well-received in the family. The result was a tasty sourdough bread using the wild yeast culture that I am keeping healthy for many years now, even if I had not used it for making bread for a long time. Although a while ago I did share some of the sourdough culture with a friend who is also into baking bread. Even a tiny bit of “starter” can jumpstart your career of baking 🙂 It’s a tedious task to raise a healthy culture of wild yeast and suitable bacteria that create good bread.

But I would like to focus more on liveslak, on my Digital Audio Workstation spin, and some new software for which I created packages.

The liveslak project received some interesting new features.
Most importantly, the hard disk installer of the Slackware Live Edition – called “setup2hd” – was expanded. In the past, it used to allow only the installation of the Live OS to your hard drive. But I received requests to also make it possible for setup2hd to install regular Slackware like the official installer does. It sounded like a good idea, and starting with liveslak release 1.3.7 the “setup2hd” program will let you choose from more package SOURCES than just the Live OS. In addition to the Live OS, you can now choose to install regular Slackware from a NFS, HTTP, FTP or Samba server. In other words, Slackware’s network install feature was added.
Why is this different from the setup program on the official Slackware ISO? Well, the most obvious improvement is that you are working in a graphical desktop environment (the Live OS). You can run the setup2hd hard disk installation in an X terminal while you keep doing other stuff like reading online materials or watching a video to pass the time. Moreover, you can install stable Slackware 14.2 from the Live OS. That means MMC and NVMe drives are supported during installation (which is something the official Slackware 14.2 installer does not provide for).
And to top it off, I am now also adding “setup2hd” to the small XFCE ISOs. Word of caution: the XFCE ISOs do not contain a “huge” kernel which means if you want to install the stripped-down XFCE OS to your hard drive, you will have to do a manual “chroot” after installation completes and before you reboot, to edit /etc/lilo.conf and add a section for the “generic” kernel. and then run the “lilo” command to make it stick. Hopefully the “liloconfig” command will learn how to do that for you, sometime soon. You can always perform a Slackware network installation from the XFCE Live OS of course!

The second new feature is the ability of liveslak to configure a custom background image for Plasma5-based Live OS. The custom image is used when generating the Live ISO, as the background for the SDDM login greeter, your desktop wallpaper, and for the lock-screen backdrop.
What I still want to achieve is adding similar functionality to the XFCE and Gnome based Live variants. The snag is that the configuration needs to be scriptable, i.e. when the “live” user logs in everything must already be in place and pre-configured. For Plasma5 that was not trivial to work out, and I have zero Gnome and XFCE scripted desktop configuration knowledge. Suggestions and code snippets are welcome.

My Digital Audio Workstation project, called Slackware Live DAW, received some updates as well. The blog article I link to describes the generic process to tune and tweak Slackware for use as a real-time audio workstation, but I used that knowledge together with a whole lot of useful audio and music software to create a Slackware “spin-off” if you want – building on a lean Slackware package set plus the core of KDE Plasma5.
Since Slackware Live DAW  is based on liveslak, it profited from improvements in that area too. Most notably the DAW Live ISO now comes with a nice dark black & white themed background – which is better on the eyes if you work on your musical project in a room with low ambient light intensity.

Created with GIMP

The other improvement, or enhancement if you will, is that I have collected all the DAW specific programs in their own submenu “Applications > Multimedia > Slackware Live DAW” and removed them from the “Multimedia” menu. This lets you focus on the audio workstation purpose of this Live OS by having all your tools in one place.
And of course, the “setup2hd” program allows you to install the Live OS to your hard drive. One caveat though: the installation will be pristine, meaning you will get all the packages but not the “liveslak” customizations installed. What you won’t get is: the nice wallpaper, the “Slackware Live DAV” submenu, the real-time tweaks to the Operating System and the pre-configured JackQtl. On my TODO is to create a way (perhaps a package) to apply all of these customizations easily afterwards. For now, best is to run the Live OS directly from a persistent USB stick. If you have a bit of patience and at least 8 GB of RAM, you can load the whole Live OS into RAM when it boots up, and use the USB persistence to write your updates to the USB stick while you work, using the liveslak boot parameter “toram=os“. Loading into RAM will take a few minutes but then you have a lightning fast DAW OS that runs completely in memory.

I created a short video to show the boot sequence, the wallpaper and the new submenu:

Now that I am writing about my DAW project, I also want to use the opportunity to ask you – my readers – to participate in a small contest. I am not good with graphical tools, but I would really like a couple of graphics:

  • a logo for Slackware DAW Live. Higher up on this page I used a generic “tux with headphones” image but I want something special for the project. A SVG file would be best but I will settle for a nice PNG.
  • a user icon for the live account. Currently all Slackware Live editions use the purple Slackware “S” icon , but I want an icon that reflects both Slackware and making music.

I welcome your submissions and will create an overview page with all of the graphics I receive. Ultimately I will select the ones I like most and use then in the liveslak project. So please do  not share copyrighted material.
I came up with the wallpaper image myself, and I asked a friend of mine, who is also a producer and a dee-jay, to supply some of his own black & white photography as wallpapers for Slackware Live DAW.

Some of the packages I created or updated lately

I usually update the blog when I have something to share about my high-profile packages like chromium, libreoffice, openjdk, vlc and the likes. But I add stuff to the repository from time to time that serves a specific purpose – either because someone I know requested a new package, or because I expand the list of available software for my DAW Live project. Here are a couple that I did not mention yet.

OBS Studio (formerly known as Open Broadcaster Software) is video recording and streaming software. It is sometimes referenced by people when they email me with requests to create a package for it. Working out the dependencies and packaging those is not trivial. I realized that I could use this myself (to create the above video of booting DAW Live), and have added it to my slackbuilds repository along with a dependency that was not in there yet: mbedtls. The other dependencies for OBS Studio were already in my repository: jack2, vlc  and x264.
I chose not to add “luajit” as yet another dependency. Luajit meant to add Lua scripting support, but OBS Studio already supports scripts via Python3. If anyone needs Lua as well, let me know. I also did not add the suggested “fdk-aac” encoder dependency for AAC audio since Slackware’s ffmpeg package also has an AAC encoder and OBS Studio will use that instead.
I realize that Patrick recently added Simple Screen Recorder (ssr) to Slackware-current but OBS Studio is more powerful and has a lot of features which make it particularly suited for people who stream their video recordings directly to sites like Twitch or Youtube.

Geonkick is “a synthesizer that can synthesize elements of percussion. The most basic examples are: kicks, snares, hit-hats, shakers, claps”. Unfa has a video up on Youtube in which he shows a bit of the interface and the percussion sounds you can create. I added this one to my DAW package list so you can use its functionality as a plugin in Ardour or as a standalone app.

 

QTractor? My DAW package list already contains Ardour and Audacity to use as your main application to record, mix and process music. They serve different purposes and audiences – Audacity is a multi-track recorder with nice post-processing capabilities, and for some people that is all they need when Ardour has a long learning curve.
Qtractor is yet another digital audio workstation tool. It is a multi-track sequencer for audio and MIDI, with a nice QT5 interface and extensive plugin support. I guess it is comparable to Ardour but less complex and therefore suited for somewhat less experienced musicians and producers.

And here is MuseE, another audio and MIDI multi-track sequencer with an interesting feature list and a QT5 interface. Similar to QTractor you can use MusE as a your DAW studio interface or use it to pre-process your MIDI tracks before importing them into Ardour, as shown in this video tutorial sequence by LibreMusicProduction.

It will be a matter of preference which of these programs you are going to use. They are all part of Slackware DAW Live so go ahead and try them out! The Slackware DAW Live ISO image can be found at https://martin.alienbase.nl/mirrors/slackware-live/pilot/ https://slackware.nl/slackware-live/latest/ and I recommend to copy it to a USB stick as a persistent Live OS, using the iso2usb.sh script.
If and when I manage to migrate slackware.nl to a bigger server I will be able to finally host it there along with the other liveslak stuff (Update 2020-Nov-15: I finally migrated to a new server and the old server died in the process, but not before I managed to save all important stuff).

Have fun! Eric

Updates available for OpenJDK 7

Posted on by

icedteaAndrew Hughes (aka GNU/Andrew) announced a new release for IcedTea 2 on the distro-packager mailing list earlier this week.The new version 2.6.23 builds OpenJDK 7u271_b01. This release includes the July 2020 security fixes for Java 7 from Oracle.
It is recommended that you upgrade your OpenJDK 7 to the latest version. If you have already moved to Java 8 then this article is obviously not relevant for you.

Here is where you can download the latest Slackware packages for openjdk7 and openjre7 (Slackware 14.1 and newer):

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 OpenJDK7 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.

Enjoy! Eric