My thoughts on Slackware, life and everything

Month: February 2017 (Page 1 of 2)

I added Chromium 56 for Slackware 14.1 with a caveat

chromium_iconA while ago, Chromium 56 ‘stable’ was released. It took a while for me to release Slackware 14.1 packages because of a crash bug in XFCE (and probably other non-KDE desktops too). I have been trying to find ways around the crash and been looking for patches, but there does not seem to be a solution for Slackware 14.1 other than working around it and losing some functionality.

So, what’s the issue?

Chrome/Chromium can optionally store credentials (user accounts, passwords) that you type in to access online secure web sites. The Password Store is a sqlite database. On Linux, its location is “~/.config/chromium/Default/Login Data” for Chromium and  “~/.config/google-chrome/Default/Login Data” for Chrome.
Chromium/Chrome on Linux wants to store your online credentials in a safe way, but it does not have the code itself to encrypt its own Password Store. Instead, it tries to rely on the availability of an external encryption provider. On KDE desktop environment, it will use the KDE Wallet system, while on other desktops it will try to use Gnome Keyring. If none of these are found, then Chrome/Chromium will fall back to storing unencrypted passwords in the above sqlite file.

Coming back to Slackware 14.1: there is a bug in it – probably in glib2 because that is where the segmentation faults are reported – which prevents recent versions of Chromium from using the Gnome Keyring. Within seconds of accessing the first web page in Chromium on Slackware 14.1, the browser will crash if you are running XFCE or some other non-KDE desktop. Note that you can use Chromium just fine in KDE on Slackware 14.1!

This issue does not exist in Slackware 14.2 or -current, probably because all the package updates between 14.1 and 14.2 solved the underlying issue. Therefore this bug is not something that will be solved in the chromium code by reporting it to Google… it is a OS related bug.

This means, if you are running XFCE you have to prevent Chromium from trying to use gnome-keyring. I tried to enforce the use of kwallet when running XFCE but that did not work, so you need to entirely disable the use of an encryption provider by adding the parameter “–password-store=basic” to the chromium commandline. The consequence will be that your online passwords will be stored unencrypted and anyone who gets hold of a copy of that sqlite file, will be able to extract all your credentials.

So here are some strategies for working with Chromium and not get bitten by the gnome-keyring induced crashes and keep your passwords safely encrypted:

  1. Encrypt your homedirectory or even your complete filesystem. With your files encrypted (using a password only you know) you reduce the risk of having Chromium store your credentials in plain-text in a sqlite file.
    Disk encryption using LUKS is something which Slackware supports during the installation. Full disk encryption is always recommended if you are using a laptop.
    If you did not opt for disk encryption during installation, but you still have more free disk space available than your /home directory tree is currently using, then you can create a new – encrypted – /home and move your existing data in there. This is an exercise that requires knowledge about cryptsetup and goes beyond the scope of this blog post.
  2. Switch to KDE. The kwallet storage is encrypted and it will not crash chromium like gnome-keyring does.
  3. Upgrade to Slackware 14.2. The gnome-keyring of this version of Slackware (and newer) will not crash chromium , so you can encrypt your online credentials in XFCE too.

And here is a chromium configuration file for Slackware 14.1 which will detect your Desktop Environment and will automatically add the parameter “–password-store=basic” to Chromium’s commandline for you if you are not using KDE. Copy the text below into a file called (for instance): “/etc/chromium/10-passwordstore.conf”:

# Use the basic (un-encrypted) password store,
# unless we are running KDE:
if [ ! "$XDG_SESSION_DESKTOP" = "KDE" ]; then
 CHROMIUM_FLAGS="$CHROMIUM_FLAGS --password-store=basic"
fi

Encrypting the passwords of your online identities will not make you 100% safe of course… even when your passwords are encrypted, Chrome/Chromium will make them plainly visible inside a browser window, by visiting the URL chrome://settings/passwords .

Note 1: The Windows version of Chrome encrypts the passwords it stores in “%UserProfile%\AppData\Local\Google\Chrome\User Data\Default\Login Data” because it makes use of a Windows API which requires the logged-in user’s password for the decryption.

Note 2: When you use the browser’s sync feature to store a copy of your online credentials in your Google Account, then those copies will be encrypted with your sync password, that only you know.

 

Download the Chromium packages for Slackware 14.1 (they were already available for 14.2 and -current for some time) from a mirror like these:

Have fun! Eric

New Slackware PLASMA5 Live ISO (with Plasma 5.9)

blueSW-64pxTo conclude this week’s batch of updates in my repositories I have re-generated the ISO for PLASMA5 Slackware Live Edition – it is based on liveslak 1.1.6.2 and using Slackware-current dated “Mon Feb 13 06:21:22 UTC 2017“.

If you already use PLASMA5 Live on a USB stick that you do not want to re-format, you should use the “-r” parameter to the “iso2usb.sh” script. The “-r” or refresh parameter allows you to refresh the liveslak files on your USB stick without touching your custom content.

What to expect from the PLASMA5 ISO

 

This ISO is a showcase for the latest Plasma 5 release “KDE-5_17.02” as found in my ktown repository and in particular the new Plasma 5.9 with lots of improvements – plainly visible as well as under the hood. Read my previous post about the new Plasma 5 if you are interested. Now that I have Plasma 5.9 I was able to move the Slackware entry on https://community.kde.org/Plasma/Live_Images significantly upwards.
The recently released LibreOffice 5.3.0 was added to this ISO as well. See my recent post about this 5.3.0 release.
A ffmpeg package with version 3.2.4 from my restricted repository (i.e. including mp3 and aac encoders) is also bundled with the ISO. It replaces the ffmpeg-3.2.3 package which is part of the Slackware core. This should not cause issues but please let me know if some Slackware program stopped working because of it.
The rest of my bunch of packages from my regular repository is again present: chromium (with the latest flash and widevine plugins), vlc, veracrypt, qbittorrent, openjdk, handbrake, dropbox-client, calibre and more.
This ISO also contains the LXQT and Lumina Desktop Environments. Both are light-weight DE’s based on Qt5 so they look nice & shiny.
This PLASMA5 Slackware Live OS is 64bit multilib. By default, no 32bit programs are loaded into the Live environment but if you want to load Wine or Skype into PLASMA5 Slackware Live, all you need to do is add a parameter to the boot commandline in Grub or syslinux. Add “load=wine” to make Wine available. Add “load=skype” to make Skype available in the Live OS. Of course to get them both, you add “load=wine,skype”. Also check out the paragraph below called “Multilib considerations“.

The changes between liveslak scripts 1.1.6 and 1.1.6.2

Not much has changed really – the “1.1.6.2” tag is primarily meant to differentiate the new PLASMA5 ISO from older versions. The boot screen of Slackware Live Edition mentions the version of liveslak it was based on which is useful for bug reports.

  • Fixed the “sed” logic in ‘make_slackware_live.sh‘ script to get rid of hardcoded ‘/mnt‘ paths in the modified Slackware installer files which are used by ‘setup2hd’. I tested harddisk installation onto an UEFI computer and that went fine.
  • Danish is a new language choice in the boot menu (Grub and syslinux).
  • unrar is added to the PLASMA5 variant.

Multilib considerations

I added a live module to enable multilib support out of the box in the PLASMA5 variant of Slackware Live. Inside the ISO that module-file is called “/liveslak/system/0020-slackware_multilib-current-x86_64.sxz”.
I host a copy of that module online as “0050-multilib-current-x86_64.sxz” so that you can download it and add it to the ‘addons‘ or ‘optional‘ subdirectory of your non-Plasma5 Live OS.
Multilib is something would not need except for running stuff like Wine or Skype, so I also added live modules for Wine (including the 32bit OpenAL libraries) and Skype as separate modules in the ‘optional‘ subdirectory of the PLASMA5 ISO and made copies of these available in the aforementioned ‘bonus’ directory online.
This is how I created that live module for wine: by installing the 32bit OpenAL libraries on top of my 64bit wine package for Slackware (which contains both 32bit and 64bit wine), and then using the “makemod” script which is part of liveslak:

# SCRATCHDIR=$(mktemp -t -d makesxz.XXXXXX)
# installpkg --root $SCRATCHDIR wine-1.9.23-x86_64-1alien.txz
# installpkg --root $SCRATCHDIR OpenAL-compat32-1.17.1-x86_64-1aliencompat32.txz 
# ./makemod $SCRATCHDIR ./optional/0060-wine-1.9.23-current-x86_64.sxz 
# rm -r $SCRATCHDIR

Remember, the modules in the ‘optional‘ subdirectory of liveslak are not loaded into the live OS on boot unless you use the “load=” boot parameter in syslinux or grub. Loading the optional wine module for instance, needs this as additional boot parameter: “load=wine” and if you would be using a non-plasma5 based Live OS and have added the multilib module in the ‘optional‘ subdirectory also, then the boot parameter needs to load both multilib and wine: “load=multilib,wine”.
Of course, if you place these live modules in the ‘addons‘ subdirectory instead, they will always be loaded on boot unless you want to prohibit that using the “noload=multilib,wine” boot parameter in syslinux or grub.

Download the ISO

Download liveslak sources

The liveslak project can be found in my git repository: http://bear.alienbase.nl/cgit/liveslak/ . That’s all you need to create a Slackware Live ISO from scratch. Documentation for end users and for Live OS developers is available in the Slack Docs Wiki.

Have fun! Eric

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

LibreOffice 5.3.0 for slackware-current

libreoffce_logoIn a previous post I mentioned that  LibreOffice 5.3 was released the first of February. At that time, I provided you with a LibreOffice 5.2.5 package instead, because I was rebuilding the 5.2 packages anyway and usually I need a bit of research time to make new releases compile.

And indeed… I hit a snag along the road which initially prevented me from compiling 5.3.0 packages, but a patch was shared by orbea on the blog which pointed the way to solving my issue with harfbuzz. For your information, the Slackware version of harfbuzz is not compiled with graphite support (because Slackware does not have a package for graphite) and the new LibreOffice requires this – so my libreoffice package has to compile an internal version of harfbuzz.

As said previously on the blog, the new LibreOffice 5.3 series introduces Collaborative editing which to me is the major highlight. A Docker image is available if you want to experience LibreOffice Online on your own private server.
Better text rendering is another highlight, hence the new requirements for harfbuzz (which is used as the rendering engine).
A detailed description of new features was made available as a web page:  http://www.libreoffice.org/discover/new-features/.

Get my fresh libreoffice packages for Slackware-current from a mirror like this one: http://bear.alienbase.nl/mirrors/people/alien/slackbuilds/libreoffice/.

Note: the LibreOffice browser plugin (NPAPI based) has been removed in LibreOffice 4.4.0:  https://skyfromme.wordpress.com/2014/09/25/killing-the-npapi-plugin/

I also added LibreOffice 5.3.0 to a re-spin of my PLASMA5 Live ISO which I uploaded last night, so if you want to play with the new features in a safe environment, try it on Slackware Live Edition. I will write more about the new PLASMA5 ISO in another post.

As a closing remark, I advise you to read the statement issued by the Document Foundation on the intentions of the Munich City Counsel to replace their version of Linux (LiMux) and LibreOffice with MS Windows 10 and MS Office by 2021. A sad example of how behind-the-scene lobbying of Microsoft and its partners is threatening to overturn one of the most well-known Open Source success stories in Western Europe.

Cheers! Eric

OpenJDK 7 security update Jan ’17

icedteaAndrew Hughes (aka GNU/Andrew) has created a new release for IcedTea 2.6.x (which is the series targeting Java7) to allow the creation of an OpenJDK 7 package with the Java security fixes for January 2017 included.

I do realize that Java8 is the more popular version currently but as long as there are security updates for OpenJDK 7, I will try to put those into Slackware packages. So today, here’s OpenJDK 7u131_b00 – or “Java 7 Update 131 Build 00” for you. In fact two packages as always: the JRE and the JDK (which includes the JRE).

As is customary, Andrew provides release notes on his blog that list the vulnerabilities (CVE’s) which are being plugged with the new release. I used to paste those into my own blog articles but I rather give Andrew the credits, so please visit his latest post dubbed “[SECURITY] IcedTea 2.6.9 for OpenJDK 7 Released!“.

If you are still in need of Java 7 and have my older package installed, please upgrade your OpenJDK 7 to this new release. Here is where you can download the Slackware packages:

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.

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.

Optionally: If you want to use Java in a web browser then you’ll have to install my icedtea-web package too. Oracle’s JDK contains a browser plugin, but that one is closed-source. Therefore Icedtea offers an open source variant which does a decent job.

Plugin support in Web Browsers:

Note that icedtea-web is a NPAPI plugin – this prevents the use of Java in Chrome & Chromium because those browsers only support PPAPI plugins, but you’ll be OK with all Mozilla [-compatible] browsers of course. For how long, I do not know. Mozilla have announced they will deprecate NPAPI in their browsers back in 2015.
And even though the plugins are still supported (but require manual activation now) there’s a very recent post on the blog of Firefox software engineer Mike Kaply where he mentions that Firefox 52 will be the first release that will no longer support NPAPI plugins at all (except for Flash but only for a few more releases to come). Remember, we are currently at Firefox version 51. Mike Kaply also mentions that the ESR releases of Firefox (i.e. the Extended Support Releases) will continue to support the NPAPI plugins!
So: Firefox 52: no more plugins. And Firefox ESR 52: plugins still supported.

Have fun! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑