My thoughts on Slackware, life and everything

Tag: kde (Page 12 of 28)

KDE 5 (Plasma 5.2.0) available for Slackware -current

qt-kde-620x350And yes – let me get this clear right from the start: this Plasma 5.2.0 desktop environment will replace the KDE 4 packages you have installed.

What is this new ‘Plasma 5’

Plasma 5 is the “next-gen” KDE desktop. It has been in development for a long long time, with the goal of providing a gradual migration path away from the well-known KDE 4 desktop. All of this with the KDE 4.0 “debacle” in mind. You may recall that the KDE community released KDE 4.0 as a “tech preview” i.e. not ready for production, however some distributions upgraded their KDE from 3.x to 4.0 regardless of that. The backlash from the user community was understandable of course, because they went from a stable KDE 3 desktop to a buggy and crippled KDE 4 desktop. This was often blamed upon KDE itself, but that does the developers and their software grave injustice – it was the distros who forced their users to a non production-ready version of KDE,so it should be those distros who should be criticized for their bad judgement. Still, even to this day, harsh words about KDE 4.0 are targeted at its developers, not at the distros who made a strategic error.

Nevertheless, here we are, with a shiny KDE 5 desktop environment!

KDE 5 makes a switch from Qt 4 to Qt 5 as the base graphical toolkit. The old KDE 4 libraries have been ported to become the Frameworks: Qt 5 modules with no dependencies except Qt 5 and optionally, other Frameworks. This allows non-KDE developers to adopt the Frameworks in order to provide an expanded Qt 5 feature set. This porting effort has been going on for a long time now (its first technology preview for Frameworks was little more than one year ago) and the Frameworks are mature technology now. Plasma 5 is the set of packages that provide the core Desktop experience, built on top of the Frameworks.

The release of Plasma 5.2.0 earlier this week was the turning point for me – this release is the first one that I actually consider ready for prime-time, capable of replacing the KDE 4 Workspace. The KDE Applications (currently at version 14.12.1) are the collection of software which used to be grouped in meta-packages like kdebase, kdeedu, kdegraphics, kdemultimedia etcetera. The Applications currently get huge attention from the developers, because that is where the hard work is being done the coming year. Slowly, all individual Applications are being ported away from Qt 4 and the KDE 4 libraries, to Qt 5 and the Frameworks. In Applications 14.12.1, the only ported apps to date are kate, konsole, analitza, gwenview, kalgebra, kanagram, khangman, kig, parley, kapptemplate,  and okteta. As you can see, still a long way to go.

These KDE 5 packages of mine are going to be your only KDE desktop. The “kde-workspace” package which provided the well-known KDE 4 workspace has been replaced by “plasma-workspace” and the good old KDM graphical login manager has been retired and replaced with SDDM. While you will be presented with a pretty Plasma 5 workspace, most of the KDE applications you’ll be using are the familiar KDE 4 versions (with updates and bugfixes), nicely blending in to the new Breeze theme.

Some Plasma 5 highlights I mentioned in last year’s preview: Plasma 5 improves support for high-DPI displays and comes with a “converged shell”, i.e. one Plasma codebase for different target devices like desktop computers, laptops, tablet, phones etc. Plasma 5 uses a new fully hardware-accelerated OpenGL(ES) graphics stack. And with the Breeze themed artwork and its own Oxygen font, this desktop looks clean and modern.

Plasma 5 follows the same trend you can also witness in Android 5, Windows 8 and OS X: gone are the colourful, exuberant 3D-ish icons, buttons and other graphical design elements.  Flat and monochrome is the new dogma. The result is too clean in some regards, is my personal opinion: the monochrome system tray icons are just plain ugly and I get flashbacks of Windows 3.1 sometimes. Judge for yourself.

What to expect from these Slackware packages

These packages are only going to be useful if installed on top of Slackware -current. They are replacing the KDE 4 packages (plus adding/upgrading a lot of dependencies) that you might have installed. There is no co-installable option. Therefore if you rely on your KDE desktop for your daily productive work, please consider your upgrade carefully. The upgrade/migration should be painless if you follow the README instructions, but I can not guarantee that there will be no deal-breakers for you (missing functionality or persistent crashes).

Highlights:

  • Lots of packages in the ‘deps’ department which are completely new to Slackware. Since KDE 5 is built on Qt5 (KDE 4 had Qt4 as its base) you’ll find many Qt5 related packages. Also, in order for Qt4 and GTK based applications to dock into the Plasma 5 system tray, more dependencies were needed. So, apart from updates to regular Slackware packages, these are the new ones (some of them will be familiar if you are already running my KDE 4.14.3):
    LibRaw, OpenAL, akonadi-qt5, eigen3, gst1-plugins-base, gst1-plugins-good, gstreamer1, json-glib, libappindicator, libdbusmenu-gtk, libdbusmenu-qt5, libepoxy, libfakekey, libindicator, orc, polkit-qt5-1, qca-qt5, qt-gstreamer, qt-gstreamer1, qt5, sni-qt, wayland and xapian-core.
  • Qt 4.8.6 of Slackware was patched to support the docking of Qt 4 application icons into the Plasma 5 system tray (and the ‘sni-qt’ package actually implements this support). While I was at it, I also added some patches which Libreoffice requires for native KDE file-open dialog support.
  • Note for users of multilib Slackware64 and also using Skype: you will have to grab the 32-bit version of Slackware’s “libdbusmenu-qt” and my “sni-qt” packages and run “convertpkg-compat32” on them and then install both “libdbusmenu-qt-compat32” and “sni-qt-compat32”, or else Skype won’t be able to dock its icon in the Plasma 5 systray.
  • A bit sneakily, I built phonon-vlc for you. You will also need a VLC package to be able to use phonon-vlc though.
  • I added the latest Calligra 2.8.7 office suite.
  • Even though I compile a ‘kde-workspace’ package as part of the whole set (otherwise kdeartwork refuses to compile), I do not actually ship that package. It conflicts with the new plasma-workspace package.
  • Several source tarballs in Plasma 5.2.0 have not been compiled to Slackware packages: libbluedevil and bluedevil (they need BlueZ 5 which is not part of Slackware), muon (a debian/ubuntu package manager), libkface (needs opencv which I was not willing to add as a dependency).
  • One dependency which you’ll probably find curious, is wayland. It is required in order to compile KWin’s X11 driver, but it is apparently not needed at runtime. Nevertheless, I left the package in, just in case you want or need to recompile kwin.
  • Graphical login: KDM has been replaced with SDDM. Installation of the sddm-qt5 package triggers the creation of a “sddm” user and group. The “sddm” user is then also added to the “video” group. If you already have a local “sddm” account, then all of that will be skipped. You’ll have to add the “sddm” user to the “video” group manually if you experience graphical glitches.

Testing Repository URL

I still consider KDE 4.14.3 the “latest stable” version for Slackware-current, and therefore the repository URLs http://taper.alienbase.nl/mirrors/alien-kde/current/latest/x86_64/ (for 64-bit) and http://taper.alienbase.nl/mirrors/alien-kde/current/latest/x86/ (for 32-bit) will keep pointing to KDE 4.14.3. You can use this repository URL for slackpkg+ or slapt-get or whatever package manager you use.

The URL http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86_64/ (for 64-bit) and http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86/ (for 32-bit) is pointing to my KDE 5 testing ground. I consider Plasma 5.2.0 as a “testing” release, with potential to be your next stable desktop, but with some caveats and reservations. The URL itself will remain permanent, even when the versions of the software components get updated. Currently “testing” points to version “5” in the repository because versions of Frameworks, Plasma and Applications are not co-ordinated and package updates may appear in the next months for these sub-sets. The “5” is a good middle ground. You should use this “testing” URL when you configure slackpkg+ or slapt-get if you want to upgrade to Plasma 5.

You must use only one of these URLs! I remind you that the KDE 5 preview I released last August was meant to be installed in parallel with KDE 4.14… but these new KDE 5 packages I am releasing today are going to replace the majority of KDE 4 packages. Therefore, the upgrade from KDE 4 to KDE 5 must be done manually, by closely following the provided README . Reading that README is even more important than before!

Enabling SDDM in runlevel 4 instead of KDM

Runlevel 4

If you want to see the new graphical session (login) manager SDDM in action, add the following lines to the Slackware file “/etc/rc.d/rc.4” right after the line: echo “Starting up X11 session manager…”

# — 8< ————————————–
if [ -x /usr/bin/sddm ]; then
exec /usr/bin/sddm
fi
# — 8< ————————————–

… and then switch to runlevel 4 by typing at the command prompt (as root):

# init 4

Select “Plasma” from the SDDM session dropdown. Alternatively, if you prefer good old runlevel 3, you can type this at the command prompt (logged in under your own regular user account):

$ xwmconfig

… and select “xinitrc.plasma” as your default window manager for X11. Then run:

$ startx

To enter your desktop session.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in three subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4”, “frameworks” “plasma”,  “plasma-extra” and “applications”.

Upgrading to this KDE 5 is non-trivial. You will have to remove old KDE packages manually. If you do not have KDE installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.

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/ subdirectories). Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Notes

  • In earlier preview release, HPlip would show an error message about not finding a system tray area. The reason is because the Plasma 5 workspace does not implement the X11 “Xembed” protocol. The system tray area works differently now. Not just HPlip, but all other applications that are not part of  Plasma  5, would have this issue, but only HPlip shows an error. Therefore some additional work was required to make the icons for Dropbox, Skype, Chromium, etc show in the Plasma 5 systray. This was done in the form of several notification support packages in the “deps/” directory and a patched Qt 4.
    • There is a solution for applications like SCIM who still can’t show a systray icon even with these added packages –  which is not elegant, but it works. Use a third-party Xembed system tray implementations like stalonetray or wmsystemtray . I have stalonetray and wmsystemtray in my own repository (I like wmsystemtray better). Both are also available at SBo.
  • Certain conditions may crash your Plasma Shell. I noticed this in a QEMU virtual machine where it was reliably reproducible: The crash occurs every time you move your mouse pointer into an Application Window placeholder in the taskbar. A crash of plasmashell makes your desktop go black and you are left with only the application windows that were currently open. Automatic restart should happen, but not for me unfortunately. You can fix it if you had a Konsole window open at the time of the crash. Type “plasmashell –shut-up &” and your desktop will re-appear.
  • The updated harfbuzz package breaks the library’s ABI. As a result, LibreOffice 4 will no longer work (error looks like “symbol lookup error: libvcllo.so: undefined symbol: hb_icu_script_to_script“).
    • Solution: Downgrading to the original Slackware harfbuzz package solves it, which is a pity because I thought I had taken care of the ABI breakage by applying a patch which re-adds that missing symbol.
  • The hardware keys for altering volume and mute still do not work on a global level (at least on my Lenovo T400 laptop). They seem to work for some applications – VLC is one of them. Sound is working fine though.
    • Solution: How dumb of me… just run “kmix” and a systray icon will appear, and the support for on-screen display of your hardware volume buttons will be enabled.
  • KRunner (Alt-F2) will still not save your command history.
  • When you try SDDM in runlevel 4 and the screen stays black with a blinking cursor in the upper left, this is probably caused by a missing homedirectory for the “sddm” user.
    • Solution: Check the output of command, it should return “/var/lib/sddm” and that directory must exist and be owned by the “sddm” user:

      $ getent passwd sddm | awk -F ‘:’ ‘{print $6}’

  • Even though you’ve selected “Plasma” as your desktop in the SDDM dropdown or in “xwmconfig”, the KDE 4 desktop is still starting up instead of the Plasma 5 desktop.
    • Solution: Remove the kde-workspace package and re-install the plasma-workspace package.
  • I have installed slackpkg+ and configured it as instructed. After installing KDE 5, when I run “slackpkg upgrade-all” it tries to pull in or upgrade all sorts of original Slackware packages. What’s up?
    • Solution: none yet… you’ll have to be careful for a while until I figure out what to do with all those packages.
  • The shutdown and reboot options are missing from the Leave menu.
    • Solution: a simple patch which removes the use of “kwrapper5” to start the KDE services will bring back both options. Kwrapper is meant to speed up the start of the Desktop Workspace and be a bit friendlier on resource usage but if you really do need shutdown and reboot options present, then apply the following patch to “/usr/bin/startkde”:
    • --- /usr/bin/startkde.orig       2015-01-31 18:09:25.744173291 +0000
      +++ /usr/bin/startkde    2015-01-31 17:49:18.938578280 +0000
      @@ -380,7 +380,7 @@
       # lock now and do the rest of the KDE startup underneath the locker.
       KSMSERVEROPTIONS=""
       test -n "$dl" && KSMSERVEROPTIONS=" --lockscreen"
      -kwrapper5 ksmserver $KDEWM $KSMSERVEROPTIONS
      +ksmserver $KDEWM $KSMSERVEROPTIONS
       if test $? -eq 255; then
         # Startup error
         echo 'startkde: Could not start ksmserver. Check your installation.'  1>&2
  • Please report any other issue you encounter and I will add it here if it is serious enough.

Have fun! Eric

Waiting for KDE 5 (Plasma 5)?

The KDE community released the source code to Plasma 5.2.0 today, and some of you are dying to see what it looks like.

Plasma5_locked

You just need to wait a little longer.
I have built all the packages, and I am doing a final quality check. Then I’ll have to write a proper README generate the repository files (time-consuming).

One note in advance:

The Plasma 5.2.0 desktop packages (completed with Frameworks 5.6.0 and Applications 14.12.1 accompanied by some of the “old” KDE 4.14.x libraries) are built to replace your current KDE 4.x desktop! My KDE 5 preview, posted in August 2014, was meant to be co-installed with an existing KDE 4 desktop and was built so that its configuration files would be written to different directories than your existing KDE 4 configuration. This allowed the curious among you to have a sneak peak of KDE 5 with the option of completely removing it again afterwards, with no pain. The new KDE 5 release I will be presenting tomorrow, means that you have to choose: do you want to stick with KDE 4 or migrate to KDE 5 (Plasma 5.2.0)?

If you are not willing to swap a stable KDE 4 desktop environment for an adventure with KDE 5 (stable enough, with exciting new features, but may have bugs or missing features that are deal-breakers for you), it may be better to wait a bit and let the early adopters tell their story of the upgrade before you decide to join them.

If you are using slackpkg+ to manage your 3rd party packages and have added my “testing” repository http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86/ or http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86_64/ , then please double-check your /etc/slackpkg/slackpkgplus.conf file and make sure that you remove one of the following:

  1. http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86_64/ (or http://taper.alienbase.nl/mirrors/alien-kde/current/testing/x86/)
  2. http://taper.alienbase.nl/mirrors/alien-kde/current/latest/x86_64/ (or http://taper.alienbase.nl/mirrors/alien-kde/current/latest/x86/)

Having the first in your slackpkg+ configuration means that your KDE 4.14.3 will be migrated to Plasma 5.2.0. Keeping the  second repository will ensure that you keep KDE 4.14.3 installed.

If you want to know when KDE 5 will be added to the Slackware core distro… my guess is that that will at least take another year. The stable Slackware release which we are working towards, will likely see its ageing KDE be refreshed with the latest KDE 4.14.3 enhanced with the LTS (Long Term Support) versions of kdelibs, kdepim* and kde-workspace, but not with KDE 5.

Also, remember that this release of KDE 5 is meant to be run on slackware-current. If you are running Slackware 14.1 or even one of the older stable releases, then KDE 5 is something you will only be reading about. By the way, I still have KDE 4.13.3 for Slackware 14.1 of course, if you think Slackware’s own KDE 4.10.5 is getting stale.

The git history of my development process towards a “stable enough for daily work” Plasma 5 desktop is here: http://taper.alienbase.nl/cgit/ktown/log/?h=5_15.01

I hope to have packages no later than tomorrow, and proper instructions in a blog article no later than thursday.

Eric

Using git while working on KDE 5

Even though I caught a bad cold (luckily, it was not the flu as I feared at first) I managed to do a lot of prepping for new KDE 5 packages (Frameworks, Plasma, Applications) since last week.

The way I tackled KDE updates in the past, was to update the sources, check the continued need of patches used for prior releases, and then start compiling and checking the build logs for errors – and responding to errors with fixes to the scripts, new patches or even new or updated dependencies. The core of the KDE.SlackBuild framework would remain largely unchanged, and it never took lots of going back and forth to recompile packages and get rid of errors or missing dependencies. KDE 4 has always been very easy to update (well, easy – experience helps a lot, plus the fact that I wrote the KDE.SlackBuild framework and know its ins and outs).

Working with the first test release of KDE 5, last summer, was a bit of a challenge, but I took it like I did with every change to a new release cycle of KDE 4 (4.11 -> 4.12 etc…): finding all available documentation on the available sources, their inter-dependencies as well as their other needs, and reading the comments and patch proposals on the KDE packagers mailing list. Going from KDE 4 to 5 was a heck of a lot more work than I initially anticipated (the hardest part was figuring out the tiering concept of the Frameworks, and of course there was a lot of cursing at the immaturity of the Plasma sources) but I considered that first release for Slackware as nothing more than a play-test. The preview packages were designed not to mess up your existing KDE 4 configuration, and easily un-installable. For me the important thing with this proof of concept was to convince myself that the updates to the KDE.SlackBuild framework were sound and I understood and was able to respond to the new reality of fragmented release cycles.

This last week, I have been targeting a more serious outcome. The upcoming KDE 5 packages for Slackware which I will be releasing sometime later this month, are meant to replace your good old KDE 4 installment, and therefore I need to deliver something that you can work with on a daily basis – a full set of applications in a functional Desktop Environment.

For that reason, I decided to call upon git to guide me through the process of making changes to the build framework. I needed to be able to reproduce my previous build environments in order to back-track after encountering errors or dead ends, and take a fork from there and try again. Putting the whole KDE.SlackBuild tree in a git repository was something I did in advance – see my previous post on KDE 5 – and since then, I have been pushing my changes to the repository continuously.

Definitely, this has saved me from finding myself in a dead end. What sometimes happened was that some application would compile into a package one time, and fail to compile the next iteration. Usually the cause would be an update of a dependency, the introduction of a patch to another package and more of that vague stuff. My git updates enabled me to inspect all updates I had done since a previous compilation attempt, and revert or adapt some of the changes I had made. In some other cases, the changes I could track graphically in the ktown cgit web interface showed cause and effect with more ease than back in the time when I would keep multiple directory trees of past attempts. A time saver!

I am currently compiling the last couple of packages that are part of the Applications. If they succeed, it means that the KDE.SlackBuild is ready and I have a full set of packages. If you ask whether they produce a wonderful Desktop Environment… I do not know yet 🙂 That will be the next step: when all packages are conceptually OK, I will fire up an X session in the virtual machine and see if the stuff I compiled works at all. If I get into a functional KDE 5 environment, that will be cause for celebration. But I expect that I will have issues in the VM (with sddm and/or kwin). If I see failure, I will try installing the packages on a real computer and see how it fares there.

I won’t release any packages until I am fully satisfied, but feel free to tinker with the KDE.SlackBuild in advance.

Eric

KDE update: 4.14.2. No KDE5 updates yet – devs need to get their act together

qt-kde-620x350Remember when everybody was so excited that the KDE developers abandoned their “monolithic” release schedule where all the software was stamped with the same version number and released as a “Software Compilation”…

There have been a number of releases for the KDE Frameworks 5 and Plasma 5 (which depend on the Frameworks) in decoupled release schedules. To me it is clear  that the developers are not (yet) ready for this. Their workflows appear to be such that they write code which depends on other modules’ code which only exists in a Git repository. With the old “Software Compilation” that was never an issue since all these sources would be released simultaneously. Nowadays we are facing independent release schedules and what is the (expected) result? Software starts breaking down because not all of the git code is being released at the time when the dependent code gets released.

Therefore I refuse to build and release Slackware packages for the latest/pending “KDE 5” software set, consisting of Frameworks 5.3.0 (in part 5.3.1 now, apparently) and Plasma 5.1.0. It is a freaking mess with updates, reverts and apologies all abound on the mailinglists. Get your act together! In emergency and disaster responce training, you’ll learn that it’s all about communication. IT is no different in software development. In the “bazaar” model, it is still required of people to coordinate the joint effort or else you’ll end up with a pile of loose sand instead of something solid and useful. Coordination is communication during, not after the events.

Knowing the KDE community, the future releases of the KDE 5 components will gradually reach mature levels again.

And hey! There still is the good old KDE4. A set of Slackware packages for KDE 4.14.2 is ready for you to download and install as of now. The source release was made public  earlier today. As expected from KDE4, it is all about bugfixes and stability enhancements.

None of the dependencies I maintain for KDE 4 had to be upgraded in comparison with my previous release of KDE 4.14.1 packages. KDE 4.14.2 bundles the sources of kactivities-4.13.3 (taken from the KDE 4.13 major release) because no new tarball is being made available. For kde-workspace, an update to 4.11.13 was provided by the developers. I promise that I will have gstreamer-1 packages done for the KDE 4.14.3 release and build artikulate (fingers crossed)!

How to upgrade to KDE 4.14.2 ?

You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script.

You are strongly advised to read and follow these installation/upgrade instructions! Note that this is only useful for you if you are running slackware-current, i.e. our development version. If you are running SLackware 14.1 then there’s still a fairly recent KDE 4.13.3 for you.

Where to find Slackware packages for KDE ?

Download locations are listed below.

You will find the KDE 4.14.2 sources in ./source/4.14.2/ and packages in /current/4.14.2/ subdirectories.

Note that I have symlinks in place (useful for users of a package manager and running slackware-current) so that ./current/latest/ will always point to the latest stable KDE release, and ./current/testing/ will always point to the most recent testing release (currently that’s Frameworks 5 and Plasma 5). Let’s hope there will be something fresh in that “testing” area soon.

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

What you do when it rains

alien

I had a great week in Bruges, Belgium. Visited the brewery “De Halve Maan” and had a tour of the new brewing hall as well as the museum with all the ages old brewing equipment. It ended with a free “Brugse Zot” blonde beer, unfiltered (you can get the unfiltered version only in the brewery’s own restaurant on-site). It really tasted great, more flavors than the bottled version.

I will try to post some of the pictures I took while roaming the city of Bruges (I nearly took 200) because it is a very pretty – Bruges is one of Unesco’s World Heritage sites. But anyway, we did not have rain during our stay (a few small showers perhaps). The rain started when we went back home. With that rain, I was less inclined to go out and walk for a bit, or work in the garden. Bread making is one of the things I am doing today (using my sourdough starter which survived a week in the fridge exceptionally well). But after a week of no computing, I wanted to do something again when I got home.

So I uploaded the KDE 4.14 packages and posted the blog article, all of which I had already prepared before traveling to Bruges. And then I looked at what else had been happening during my absence. Not much really 🙂 Some new systemd related threads on LinuxQuestions.org, which I am trying to stay out of (it’s a pretty hairy discussion in there), and some more talk about Skype 4.3 which needs PulseAudio now.

Perhaps I will pick up zerouno’s successful effort to package all the required 32-bit libraries along with the Skype binaries (he did not have to bother with PulseAudio then, so I think it will be more complex to make it work now)… if I find the time.

On Google+ I had attempted to find some answers to creating an OpenVZ container template for Slackware. I had hoped there would be updates during my holidays, but unfortunately the one guy (who also reads this blog of mine I believe) who has worked professionally with openvz and Slackware and whom I asked for advice did not answer. Probably too busy with his girl friend. Anyone who can help me out, please leave me a note. The G+ post contans a link to the script I wrote for the creation of that Slackware template.

kde44 I did have time this weekend to package KDE 4.13.3 for Slackware 14.1 – as promised when I wrote about KDE 414 for Slackware-current.

The KDE 4.13.3 packages for Slackware 14.1 are available at the usual location,  http://taper.alienbase.nl/mirrors/alien-kde/14.1/latest/. Those of you who like (or need) to use a stable Slackware version will now have the opportunity to enjoy a much-improved KDE. It includes the latest Calligra office suite and also the kdeconnect package (to interface with your Android phone from within KDE)  has been upgraded and has a lot more functionality now.

calibreico I also looked at the weekly update of Kovid Goyal’s Calibre package.

To my surprise he has promoted his beta version of Calibre 2 to production sooner than I expected which creates a dilemma for me. The new version 2.0.0 is no longer based on Qt4 but instead Kovid uses Qt5 for Calibre now, which allowed him to eliminate several longstanding Qt4 related bugs. My dilemma is, how should I treat the transition to Qt5 ? Should I embed the Qt5 libraries into the Calibre 2 package like I used to do long ago for Qt4 (which will greatly increase the package size) or should I request of you (users of my Calibre package) to install my Qt5 package along with the new Calibre? I would like your feedback before I decide to start building a Calibre 2 package. In the meantime, the “old” calibre-1.48.0 package will remain available in my repository.

ARM_powered_300px There were two questions in my old blog pages about the status of my hardfloat ARM port. I must say, the economical crisis and the condition of our remaining parents have resulted in me having a lot less free time, and the ARM port was a victim of that. I am at a point with that port that I need to re-sync to the latest stable Slackware and then transfer the packages to a real machine… I am a bit scared of that last part. Stuart’s Slackwarearm is very successful at installing onto ARM devices, because he uses a (modified version of the) real Slackware installer for that. WIth my ARM port I am noy yet sure if I want a “Slackware-like” installation using the setup script, or create an image file which you just have to copy to your ARM device. Note that the hardware which I had in mind for my port, is the Chromebook, or tablets even, Unlike the older embedded Linux devices, those are typically equipped with a ready-made OS image instead of running an installer. But the ARM port is not dead! I just need to get my act together.

Have fun! Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders NorenUp ↑