This week, Google released the first 78 version in the “stable” channel of their Chromium sources – the basis of Chrome, Opera, Vivaldi and even the Edge browsers, and of course the Chromium open-source browser itself. The release notes contain a fairly long list of security issues (CVE’s) which were taken care of.
I built packages for you today, so that you can enjoy the latest&greatest Chromium browser on Slackware 14.2 or -current.
What’s new in Chromium 78?
Tab hover cards. If you have a multitude of browser tabs open, it becomes difficult to recognize which tab has what page open. From now on, if you move your mouse over a tab you will see a small ‘hover card’ showing the title and the hostname of the page you have open in there.
Dark mode. You can now force ‘dark mode’ on every web site, whether the web site supports it or not. The web site code is not changed at all, and Chromium will perform a smart color inversion. You can choose between several algorithms. This is an experimental feature still, so you will have to enable it via chrome://flags like so:
Chrome Password Safety tool which was available as an extension since February of this year has now been folded into the core of the browser. This feature will inform you of weak, leaked or re-used passwords in your list of saved passwords. Later on, Google is going to add functionality that will warn you when you try to use a password which is leaked online – even if you do not save your passwords in the browser.
Still an experimental feature in this version of Chromium, you will have to enable it first via chrome://flags:
A new extended menu which appears if you click “customize” in the lower right corner of the ‘new tab‘ page. Decorate the ‘new tab’ with your own background image or a different theme. This is still an experimental functionality so you have to enable it explicitly via chrome://flags :
Just missed the deadline for Chrome 78: DNS-over-HTTPS (DoH): Google has started a field test of its newly developed technology to tunnel your DNS queries through regular HTTPs requests. This security feature will be invaluable to those of you who do not want to risk 3rd parties to sniff your DNS requests for instance on a public Wi-Fi network. It will also prevent potential DNS spoofing attacks.
This Google blog article about DoH explains the caveats of using their implementation and the difference with the Mozilla Firefox implementation of DoH. Firefox enables DoH by ecapsulating your DNS requests in HTTPs and sending those to a CloudFlare server, while Chrome honours your existing DNS configuration (like paternal controls and safe browsing). The Chrome browser will check if your DNS provider is among a list of DoH-compatible providers, and swiches to your DNS provider’s equivalent DoH service. If the DNS provider isn’t in the list, Chrome will keep using regular DNS requests. Therefore, you’ll have to actively check whether this feature is going to work for you.
As said, that same blog page mentions that this feature did not make Chrome 78 at the last moment.
Also good to know is that the field trial is only going to be enabled for a small percentage of Chrome users (and not on Linux or iOS at all) – once it gets enabled. Not sure if this is going to be available to all of us Linux Chromium users any time soon.
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 184.108.40.206 to 220.127.116.11 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.
Last year August 2016 I experimented with Wayland, the alternative to the X Window system. My goal was to see if it is possible to run a Plasma5 desktop session on a Wayland compositor instead of using X.Org.
There was one big showstopper at the time. Kwin_wayland has a dependency on the ‘logind’ DBus API and at that time last year, this API was only provided by systemd-logind. Luckily, someone treated the logind component of systemd similarly to its udev component. Where Slackware already uses “eudev” which is a standalone udev source extracted from the systemd source, there’s also “elogind” which is the standalone logind sourcecode, extracted from systemd sourcecode. With some difficulty I managed to create a Slackware package for elogind and everything compiled. I just could not get a working Wayland session.
As it turns out today, that failure to get Wayland working was an omission on my side… more on that later.
Shortly after, IBM told me I would lose my job, I found another job at ASML and life was hectic and remained so. I never got another opportunity to research the root cause of my Wayland failure.
Now that I have a week off, I decided to revisit the old Wayland disaster. After last year’s frustration over the need for elogind, I talked to the ConsoleKit2 developer and to the KWin developer, to see if CK2 could be extended with the required logind DBus API (parts of that API were already incorporated) and to get CK2 accepted as an alternative to systemd-logind on systems that don’t ship with systemd. Both wishes were fulfilled this summer, so I could drop elogind from my package set. I still needed to recompile / upgrade some other packages to add wayland support to them, but the fact is: Slackware does not need PAM or systemd to get Wayland working.
Therefore, my KDE 5_17.10_testing repository contains mostly what you already know and love: KDE Frameworks 5.39.0, Plasma 5.11.0and Applications 17.08.2. All based on Qt5.9.2. Just with 17 differences in the package list.
Why does Wayland work now, while it did not last year?
Well, that was entirely my perception of things. Probably would have worked last year as well, if only I had recognized the signs. Last year, and yesterday as well, all the puzzle pieces seemed to be OK, but their integration failed. The signs (using strace and gdb to find out why the Wayland session would not start) were telling me that KWin was trying to find a logind provider on the DBus and no-one was answering. It took a sudden insight this morning, the realization that there is one difference between Slackware and all those other distros. And I have been using a workaround for ages, and I just did not think about that.
When you login on a system running PAM, a login session is registered on the bus using either ConsoleKit2 or systemd-logind. Our PAM-free Slackware needs an additional “ck-launch-session” command in front of the “dbus-launch” command to connect a new ConsoleKit2 session to the bus and let KWin find it there… when I fixed that, my Wayland session just sprang into existence!
How to start a Plasma5 Wayland session
Runlevel 3 (console): run the ‘startkwayland‘ command as your regular user.
Runlevel 4 (SDDM): select “Plasma (Wayland)” from the session dropdown and then proceed to login.
Of course… nothing works 100% the first time. So what have I ran into? Note that I have been running Wayland for a couple of hours only, so I can say little about its stability.
Dropbox does not start, unless you ‘unset’ the QT_QPA_PLATFORM variable first. This is caused by the fact that Dropbox uses its own internal Qt5 libraries and it does not come with Wayland support.
Gnome-keyring does not start for some reason, so you can not auto-login to skypeforlinux for instance
HP-tray was eating 100% CPU at some point and draining my battery. I had to kill the process.
Yakuake does not work (I know, it is not part of my ‘ktown’ package set)
Unlike an X.Org session, the Wayland session does not require an additional <Ctrl> keypress to switch to a virtual console. Therefore, when I wanted to invoke krunner with <Alt><F2>, instead I was switched to the second virtual console, tty2. Upon returning to the Wayland session (which was running on VT4 as opposed to VT7 for X.Org) the krunner window was waiting for me. Apparently both the OS and KWin process the <Alt><FunctionKey> combos.
A note about NVIDIA: I know that there are issues between the binary driver and Wayland. Please do your research if you use the binary Nvidia blob. My laptop has an Intel GPU which runs on the open source kernel driver, and has no issues.
What’s needed to make Plasma5 work with Wayland in Slackware
We need Wayland support in the core of the OS as well as in the dependencies for Plasma5. Also we need a version of ConsoleKit2 that works with Kwin_wayland. Which means:
add a wayland-protocols package (wayland is no longer sufficient)
add an upgraded ConsoleKit2
recompile Slackware’s mesa using a slightly modified SlackBuild script (change the package tag from ‘alien’ to ‘wayland’)
write a xorg-server.SlackBuild script based on the code in the x11.SlackBuild framework of Slackware, and recompile xorg-server with that script (change the package tag from ‘alien’ to ‘wayland’)
recompile libxkbcommon (change the package tag from ‘alien’ to ‘wayland’)
recompile qt5 (change the package tag from ‘alien’ to ‘wayland’)
With the ‘deps’ taken care of, proceed to Frameworks:
recompile kwayland and plasma-framework (change the package tag from ‘alien’ to ‘wayland’)
And finally the Plasma packages that use Wayland in some way or other:
recompile kinfocenter, kscreenlocker, kwayland-integration, libkscreen2, plasma-desktop, plasma-integration,plasma-workspace, powerdevil and kwin (change the package tag from ‘alien’ to ‘wayland’)
You will have noticed that the packages I tagged with ‘wayland‘ instead of the usual ‘alien‘ tag, are the ones that picked up Wayland support as compared with their originals. This makes it quite easy for you to switch back to the original packages (mesa and xorg-server in Slackware and the other 13 in ‘ktown’) if you are done with your testing. The remaining ‘alien’ packages (wayland-protocols and ConsoleKit2) can be kept without penalty.
A final note about this updated xorg-server package. My version of that package is a 4-into-1 package; it contains xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb as well. If you decide to remove the testing packages and want to go back to Slackware’s non-wayland version of xorg-server, you must also re-install the other three xorg-server-x* packages.
Installing or upgrading Frameworks, Plasma and Applications
Please use the README file in the ‘latest’ repository for the installation & upgrade instructions. I reserved the README.testing in the ‘testing’ repository to highlight the differences between the two repositories.
Where to get these ‘testing’ packages for Plasma Wayland
Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/testing/ subdirectory). Only “bear” has the packages for now, the mirrors should follow within 24 hours. If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too. There is now only one source tree to create both ‘latest‘ and ‘testing‘ repositories.
There will probably not be a Plasma5 Live ISO image based on the ‘testing’ repository with working Wayland support. My ‘bear’ server just does not have the disk space to host an additional 4 GB ISO file. Nevertheless, you can tranfer the existing Plasma5 Live ISO to USB stick, change the ‘latest‘ ktown repository to ‘testing‘ in the slackpkg+ configuration file “/etc/slackpkg/slackpkgplus.conf” and run “slackpkg update ; slackpkg install ktown ; slackpkg upgrade ktown” to get the 4 new packages and upgrade the 13 other packages. If you do not use slackpkg with slackpkg+ then simply look at the short list of packages to be installed or upgraded, higher up on this page.
To celebrate I have created some goodies for you. Nothing you can eat or drink…
First, Plasma 5 updates.
I have uploaded the July ’17 set of Plasma 5 packages for Slackware 14.2 and -current to the ‘ktown’ repository. KDE 5_17.07 contains: KDE Frameworks 5.36.0, Plasma 5.10.3and Applications 17.04.3. All based on Qt5.9.0 for Slackware-current and Qt 5.7.1 for Slackware 14.2. NOTE: I will no longer be releasing Plasma 5 packages for 32bit Slackware 14.2.
What’s new this time
Apart from the usual upgrades to the Frameworks, Plasma and Applications subsets, there is only one interesting piece of news: I added ‘kile’ to the applications-extra directory. Kile is a LaTex editor and the port to the KDE Frameworks 5 is well underway. I based the package on a git snapshot of its repository. One more KF5 application in “applications-extra”.
The goal of the KDE community is that the Applications 17.12 release (i.e. end of this year) will not have any application that is still kdelibs4 based. Everything in Plasma 5 Desktop should then finally be based on KF5.
Installing or upgrading Frameworks 5, Plasma 5 and Applications
As always, the accompanying README file contains full installation & upgrade instructions.
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/
Where to get the new packages for Plasma 5
Package 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.
A Plasma5 Live ISO image will follow shortly on http://bear.alienbase.nl/mirrors/slackware-live/latest/ in case you want to try it out first (check the timestamp of the ISO on the web page). I am currently testing it, looks fine. Here is a screenshot showing the QtAv player (a proper QT5 and QML based video player so that you can forget about kplayer or gmplayer):
What else is in stock
The PLASMA5 Live ISO is crammed with all my relevant big packages (libreoffice, vlc and friends) and I refreshed a few of these packages:
A package is available for the latest MKVToolnix 13.0.0 – Slackware 14.2 and -current.
I built the latest Calibre 3.4.0 for Slackware 14.2 and -current, adding several internal modules which I omitted in my first Calibre 3 release. As a consequence, Calibre now also depends on unrar for which I also compiled the latest release (5.5.6) into a Slackware package.
Podofo is another dependency for Calibre that received a long overdue update, and my repository now contains version 0.9.5.
And I am also preparing Live ISO images for the variants SLACKWARE (64bit and 32bit), XFCE (64bit and 32bit) and MATE. They should go online at the same time as the PLASMA5 ISO.
The Pale Moon browser was forked off the Mozilla Firefox codebase a couple of years ago, before Firefox switched to the Australis User Interface. Since then, the project has steadily been diverging from the Firefox codebase, optimizing its Gecko layout engine and rebranding that to ‘Goanna’ (which is the name of just another lizard). The community has a large vote in the direction the Pale Moon browser’s features are taking.
People are drawn to Pale Moon because it promises to be a browser that is leaner than the modern-day Firefox. Pale Moon has the look and feel of Firefox like it was years ago, which has a certain appeal. Firefox and Chrome are both plagued by code bloat. The Australis UI ruined Firefox for many people. Also, Pale Moon supports the old Mozilla Sync (Weave 1.x). You can easily setup your own private sync server at home.
Yet, Pale Moon promises to give you a contemporary user experience regardless.
The lead developer of Pale Moon is also very strict about the use of his official branding by 3rd party source builds that are re-distributed as unofficial binaries. Builds that do not conform to these policies, must use unofficial branding (a monochrome logo, and the name “New Moon”). The scripts on slackbuilds.org do not re-distribute binaries so they are not affected by these policies.
I decided that I was curious enough to write a SlackBuild of my own, and see what I thought of Pale Moon. I took inspiration from Slackware’s mozilla-firefox.SlackBuild and then did two things crucially different from the official recommendations. I used the default gcc compiler of the Slackware release I built the package on (Slackware 14.2 has gcc-5.3.0 and -current had 5.4.0 at the time when I ran the compilation… of course, now -current has gcc-7.1.0). And the optimization I chose is “-Os”; a conservative optimization with a focus on smaller code size, instead of better speed.
The resulting package seems to be stable, and it is not crashing on web sites where other 3rd party builds seem to falter. See this LQ thread for more details about problematic web sites which my binary shows without issue. Also – judging from the forum posts – it appears that many crashes are triggered when running Pale Moon in KDE4 with the oxygen theme selected for your GTK+2 programs. I fixed that instability by applying a patch to oxygen-gtk2 that can be found in its code repository but was never included in an official release. That patched oxygen-gtk2-18.104.22.168 package is available in my SlackBuild repository, and is also included in my ‘ktown‘ repository for the Plasma 5 desktop environment. I urge you to upgrade your Slackware package to this version.
Moonchild, the lead developer, gave his approval to use official branding in a series of private conversations we had, but being a Windows person he wants his Linux developer to check my package out. I told him that I will have a Pale Moon package in my repository, or none at all – I will not use unofficial “New Moon” branding. My package should give you a stable browsing experience – if not, let me know and do not bother the Pale Moon developers. So, if you see the palemoon package disappear from my repository, you’ll know that I have fallen out with the project and am not agreeing to their requests.
So far so good of course – this is Slackware, and we offer a nice & stable OS to run this browser on. I hope that some of you will find your new favorite browser in Pale Moon.
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!