Alien Pastures

My thoughts on Slackware, life and everything

Month: October 2017 (Page 1 of 2)

Chromium is now compiled using clang

October 30, 2017 / / 10 Comments

chromium_iconIn my previous blog post about Chromium 62, I described the issues I had while attempting to compile it on Slackware14.2. The gcc compiler suite on Slackware 14.2 is “too old” for Chromium because it lacks the required C++11 support. More to the point, the Google developers use clang instead of gcc for their own compilations and therefore gcc support is becoming stale. Response by Google developers when they encounter a gcc-related bug report is to ‘please switch to clang’.

Unfortunately, as previously noted, the chromium build framework will download Google’s own clang binaries in that case. I do not trust these binaries on my Slackware computer. I stated that I would not switch to clang until it became possible to either use Slackware’s own clang or else compile Google’s clang from source on my own computer.

I exchanged a couple of emails with Google developers and got enough hints to convince me that compiling Google’s clang was possible.

And indeed, after a week of trial and error (especially the 32bit build gave me headaches) I managed to add all the needed bits and pieces to my chromium.SlackBuild.

The updated packages for Chromium (version 62.0.3202.75) for which the sources were released last week, are compiled with clang instead of gcc, and that clang has been compiled from source first. Of course, this adds time to the package build… every time I compile the chromium package, the SlackBuild script has to download and compile clang as well. But, the process is fully automated and a separate “gcc5” package is not needed on Slackware 14.2. Also, we are future-proof now. And an added bonus is that the package size has decreased substantially, from 65 to 56 MB (a 14% decrement).

Note about the new Chromium release: it addresses CVE-2017-15396 (Stack overflow in V8) so it will be good to upgrade.

If you want to compile chromium using gcc nevertheless (to decrease the total build time for instance) then all you need to do is: set the variable “USE_CLANG” to “0”.
On Slackware 14.2 you still need my gcc5 package and apply the instructions from my previous post.

The packages for chromium are available for Slackware 14.2 and -current in my repository or one of its mirrors:

Have fun! Eric

Netsurf, a lightweight browser, works on the framebuffer too

October 25, 2017 / / 12 Comments

Someone asked me to build a package for Netsurf. I had never heard of Netsurf before. It turns out that Netsurf is a cross-platform web browser which also runs on Linux. Its rendering engine is written from scratch, therefore the browser does not share code with any of the big browsers. Netsurf is actively developed and has a healthy community. A new version was released last week – 3.7.
Functionally speaking, this browser is not as versatile or capable as other modern browsers, but its advantage is that it is small, fast, suited for low-end hardware, and more importantly: it works on the Linux framebuffer. This means that you can have a basic graphical web browser on your server console. It looks better than “links -g”.
Note: even though Netsurf comes with both a GTK version (netsurf-gtk) and a framebuffer version (netsurf-fb), even the framebuffer binary make heavy use of X.Org and freetype libraries. So if you want to use the framebuffer browser on a server console, you need to install the X series anyway.

How to make Netsurf work on the Linux framebuffer, i.e. on the console?

  • Add your user to the “input” group so you can use the mouse (i.e. the /dev/input/mice device node) using the command (as root):
    # gpasswd -a your_username input
    If you are currently logged on, you need to logout and login again to make this change effective.
  • Determine the width and height of your framebuffer console to make maximal use of your screen dimensions (netsurf on a framebuffer defaults to a window of 800×600 pixels) by querying the /sys virtual filesystem and look for the characteristics of the fb0 framebuffer device:
    # cat /sys/class/graphics/fb0/virtual_size
    This will return width and height in pixels, comma-separated. In my case I get “1920,1080”.
  • Read the available documentation to learn about the limitations.

With the above taken care of, start the Netsurf framebuffer browser with:
$ netsurf-fb -w <width> -h <height>
… where <width> and <height> are the values obtained from the command further up.

Curious? Get the package from my regular repository (http://www.slackware.com/~alien/slackbuilds/) or any of its mirrors.

If you want to compile netsurf yourself, you’ll also need two dependencies, “perl-html-tagset” and “perl-html-parser“.

Plasma5 Wayland works on Slackware

October 24, 2017 / / 27 Comments

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.0 and Applications 17.08.2. All based on Qt 5.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.
It’s PAM.
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.

Caveats

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.

Note: check out the KDE page which documents the Wayland issues: https://community.kde.org/Plasma/Wayland_Showstoppers

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.

Live ISO of PLASMA5

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.

Have fun! Eric

Chromium 62 ready for download

October 20, 2017 / / 5 Comments

chromium_iconEarlier this week, Google released a security update for its chrome/chromium browser. The new version 62.0.3202.62 plugs the holes of 35 more or less serious issues, several of them have a CVE rating.
When the topic of Chromium 62 came up in the comments section of a previous post, I mentioned that I was unable to compile it on Slackware 14.2. Errors like “error: static assertion failed: Bound argument |i| of type |Arg| cannot be converted and bound as |Storage|” yield some results when looked up on the Internet, and they indicate that Slackware’s own gcc-5.3.0 package is too old to compile chromium 62.
The c++11 implementation in gcc-5.3.0 has issues which are fixed in gcc-5.4.0. Unfortunately we are stuck with what we have on Slackware 14.2; it will only get security fixes, no functional upgrades, so no gcc-5.4.0.

I posted on the chromium-packagers discussion group to see if there’s anything to be done about this and that lead to an e-mail discussion with a Google developer who is also a Slackware user. He told me that Google compiles its own Chrome with clang, and more specifically, using a modified bleeding-edge version of clang that does what Google wants it to do. Compiling with gcc is not tested all that much, which apparently is leading to a multitude of reports about gcc related compilation issues. It’s not just me.

There is a reason that I want to compile with gcc, even though the chromium.SlackBuild already has some (hopefully complete) support for using clang instead. Google does not want to use the system-clang of the distro and instead, forces a download of its own clang binaries. I am not ready to trust a binary black-box to compile my chromium package… after all I created the chromium package for Slackware so that we do not have to depend on Google’s Chrome binaries.
This entry on Google’s  reviewboard is encouraging though; there is an initiative to take distro packagers’ wishes more seriously. The idea is to work toward using the system toolchain to compile Google’s clang variant from source and then use that to compile chromium. I’ll wait for that to happen before I switch to clang. I have nothing against clang as compared to gcc – it’s only my unease at having to trust someone else’s binaries.
I hear you say “but what about NaCl?”… indeed in order to compile NaCl my chromium.SlackBuild is already downloading a binary toolchain from Google. But that downloaded PNaCl toolchain is not used to compile the complete browser, it’s used only for the NaCl sandbox. And even that is coming to an end. Google has deprecated (P)NaCl in favor of WebAssembly. As of April 2018, it will only support PNaCl in Chrome Apps and Extensions. Meanwhile, WebAssembly (a portable cross-platform and cross-browser solution for presenting web apps at near-native speed) is already fully functional in Chrome/Chromium, as can be seen by visiting http://webassembly.org/demo/

Back to the present day. I still needed to compile chromium 62 for Slackware 14.2 with its too-old compiler suite. Therefore I grabbed my gcc5.SlackBuild which I had originally meant to be installed alongside gcc7 on slackware-current. I polished it a wee bit, and then build packages for Slackware 14.2. My ‘gcc5‘ works by sourcing its “/etc/profile.d/gcc5.sh” script which sets several environment variables and points those to the gcc5 binaries (CC, CPP, GXX, AR, NM, RANLIB). Unfortunately, the chromium framework ignores these environment variables and uses the “which” command to look for gcc and g++. Therefore I had to be a bit more creative (i.e. break some stuff).

So, what is the drill on Slackware 14.2 if you want to compile Chromium 62?

  • Install gcc5, ninja and nodejs for which I have packages in my repository. Note that installing this ‘gcc5’ does not replace your Slackware gcc-5.3.0, it gets installed alongside and does not clash.
  • Download the chromium sources and scripts from my repository.
  • Make the ‘gcc’ and ‘g++’ symlinks in Slackware point to the ‘gcc5’ binaries:
    # cd /usr/bin
    # mv gcc gcc.orig
    # ln -s gcc-5 gcc
    # mv g++ g++.orig
    # ln -s g++-5 g++
  • Source the profile script (just to be sure). Note the ‘dot’ at the beginning, that dot is the ‘source’ command:
    # . /etc/profile.d/gcc5.sh
  • Compile chromium. Note that this requires lots of RAM and lots of diskspace, and if your CPU does not have many cores, you’ll need a lot of time too.
  • Restore Slackware’s gcc and g++ symlinks:
    # cd /usr/bin
    # mv gcc.orig gcc
    # mv g++.orig g++

Fortunately gcc5, ninja and nodejs are only needed for the compilation, not for actually running the browser. So if you do not fancy a re-compilation, you do not have to install any of those other packages.

The packages for chromium are available for Slackware 14.2 and -current in my repository or one of its mirrors:

Have fun! Eric

October updates for the Slackware Plasma5 desktop

October 14, 2017 / / 65 Comments

There’s been updates to all the major components of the KDE Software Collection (I know they stopped using that name but I think it is still fitting). So I tasked my build box to compile hundreds of new packages and today I have for you the October ’17 set of Plasma 5 packages for Slackware 14.2 and -current. KDE 5_17.10 contains: KDE Frameworks 5.39.0, Plasma 5.11.0 and Applications 17.08.2. All based on Qt 5.9.2 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 in the October release

There was a new Qt5 release just after my September packages, so this time the ktown repository comes with a ‘qt5‘ 5.9.2 package for Slackware-current.
The other major update is Plasma which had its first 5.11 release with lots of visual, UX and under-the-hood improvements. You can read the release announcement if you are curious. Most notable is a new functionality called “Plasma Vault” which enables you to add documents to an encrypted vault and hide that from sight. It’s not (yet) functional in my repository because plasma-vault depends on an external encryption program to do the job – and neither of the two candidates are part of Slackware or any of my own repositories. Install either ‘encfs‘ or ‘cryfs‘ to make this work.
The Frameworks and Applications updates are targeting stability and bugfixes.

I was unable to update KDE Partition Manager on Slackware 14.2, because its dependency ‘kpmcore‘ needs a newer ‘blkid‘ program than what’s available through the util-linux package. No problem for Slackware-current, it sports the latest ‘partitionmanager’ package.

I ran into an issue when I tried adding SDDM 0.16.0. SDDM is the graphical session manager aka login manager. It turns out that the new release is not compatible with ConsoleKit2 (which we have in Slackware) because the new code was only tested against systemd. Therefore I stuck with the 0.15.0 release which I know works well. We’ll just wait for a bug-fix release 0.16.1.

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

Live ISO of PLASMA5

A new Plasma5 Live ISO image (based on liveslak 1.1.9.2) has been uploaded to http://bear.alienbase.nl/mirrors/slackware-live/latest/ in case you want to try the new Plasma5 desktop out first in a non-destructive way.

Have fun! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑