My thoughts on Slackware, life and everything

Tag: plasma (Page 4 of 4)

Last week’s harvest

I was a bit too busy and tired to write something on my blog during the past week, but now that it is weekend again, there is room for some updates.

Flash Player Plugin

There was yet another security update for Adobe’s Flashplayer Plugin. I updated my package to the latest version. Note that if you are using my Steam Client package, you will probably have installed the flashplayer-plugin in order to see all the news in the Steam Store. If you are on a 64-bit Slackware platform with multilib, you should not just update the 64-bit flashplayer-plugin but also convert the 32-bit package into a “compat32” version and upgrade the 32-bit package you will already have installed for Steam:

# convertpkg-compat32 -i flashplayer-plugin-11.2.202.285-i386-1alien.txz
# upgradepkg --install-new /tmp/flashplayer-plugin-compat32-11.2.202.285-x86_64-1aliencompat32.txz

KDE

The kdelibs package in my ktown repository (KDE 4.10.3) has been patched to prevent application crashes. Coincidentally this patch has also been applied to the kdelibs package in slackware-current.

Slackware Dependencies

A nice and fast tool to discover and query dependencies between Slackware packages is sbbdep which stands for “Slack Build Binary Dependencies”. Its author, a4z, released version 0.2.0 last week. I use this tool to assist me when determining the build order of packages for my ARM port.

ARM Port

Speaking of which, there is an interesting thread going on on LinuxQuestions, regarding ARMedslack and the Raspberry Pi. Someone who goes by the nick “Ahau” and comments on my blog from time to time, is working on a hard-float port to the armv6 hardware platform – the heart of the Raspberry Pi. He is using my ARM source tree for this, has given me good feedback which resulted in bug fixes, and his ultimate goal is to create a new ARM version of Porteus. The most recent part of the LQ discussion centered around my decision to split the libtinfo library (terminfo) out of the libncurses(w) library. This is the ncurses developers’ intention for the future, however it causes issues when compiling software which is not querying the system properly and assuming that only libncurses(w) is required for linking.

I had nearly decided to revert my decision and integrate libtinfo again into libncurses(w) when ponce pointed out a patch which I had already seen in Fedora’s ncurses package source. Perhaps I will apply that patch to my ncurses package because it seems to resolve all the linking issues we have been running into lately.

LibreOffice ARM?

And more good news – it took two days of compiling because I forgot to enable distcc, but I managed to create LibreOffice packages for my ARM port, using the SlackBuild script with which I already compiled LibreOffice 4.0.3 for x86 and x86_64 platforms last week (I needed one additional patch to work around the newer boost-1.53 which I have in my ARM tree). I have not had the chance to install the packages and run the LO Writer to see if I created working binaries… but the build log did not show errors which is promising!

Desktop Environments other than KDE or XFCE

Long ago, I created a package for razor-qt which is a minimal (lightweight may be the better word) desktop environment based on Qt. In other words, it looks beautiful (by not using GTK) and does not have the sluggishness people complain about when they run that other Qt based desktop environment (KDE). I was thinking about what I would have to add to a filesystem image for the ARM ChromeBook which I should finally get ready and distribute… I do have KDE packages, but KDE felt like just a bit overweight for the ChromeBook. I do not really like XFCE (don’t get me wrong, technically and functionally it’s not bad at all, but GTK does not have any visual appeal to me) and therefore I felt compelled to re-visit razor-qt.

Razor-qt does not come with its own window manager, instead it allows you to pick one of the available window managers it finds on your computer when it starts for the first time. Razor-qt will work well with KDE’s window manager KWin, but it works best with OpenBox. And since that is not part of Slackware, I added an openbox package as well to my repository (which was the moment that I found out I had never released my original razor-qt package… no idea how I could have forgotten that).

I decided that I am going to build armv7hl packages for razor-qt and openbox so that the ChromeBook has a nice and fast, good-looking desktop environment next to XFCE. They will be uploaded to my separate “alien” subdirectory of the ARM package tree, where I will upload the LibreOffice packages as well.

KDE Display Manager

The KDE Desktop Environment is transitioning to Plasma Workspaces 2. Two changes are worth mentioning because they will have a big impact: Many “user-interface centric” applications will be re-written in QML (Qt Modeling Language). More importantly, the X.Org display server of old will be abandoned for the Wayland protocol server. Wayland gives you a 3D-enabled display server from the start, instead of the current practice of running a 3D compositor (KWin, compiz) as an extension under the 2D X.Org display server. Future support of Wayland requires a rewrite of KWin (KDE’s window manager) but also forced a decision to say goodbye to the KDE Display Manager (KDM) which is the graphical login program which greets you when you boot Slackware in Runlevel 4. A blog post by Aaron Seigo gives a lot of insight in the process that preceeded this decision.

It looks like SDDM (Simple Desktop Display Manager) is a contender for replacing KDM in a future release of KDE. Initially, SDDM had a hard dependency on PAM, but thankfully the developer is friendly towards Slackware. After a short discussion on Google+ he created a preliminary “pam-less” version which I tested. Those tests went OK and the changes were added to the main source. So it is with pleasure that I announce the package which I added to my repository. You can already try it out, if you just add a couple of lines to Slackware’s “/etc/rc.d/rc.4” script. Directly below the line that says:

echo "Starting up X11 session manager..."

you add:

# ----8<----------------------------------------------------------------
# Use Simple Display Desktop Manager
 if [ -x /usr/bin/sddm ]; then
 exec /usr/bin/sddm
 fi
# ----8<----------------------------------------------------------------

Enjoy!

Eric

Upgrading the eeepc to 2.6.33

Last week I finally took the time to upgrade my Asus Eeepc 1000H to the latest Slackware-current.

I had two issues after the upgrade, which were related to the new 2.6.33 kernel.

  1. My WPA-secured wireless connections would not last longer than a few seconds. After days of despair, I finally found out that the 2.6.33 kernel has a new driver for my wireless card, the “rt2800pci”. This driver is being loaded by default now. Slackware’s kernel also ships the “rt2860sta” driver which is part of the Linux “staging area” i.e. not considered fully stable. This is the driver which would be used with Slackware kernels before 2.6.33. It is in fact a very stable driver which never failed me before.
    By coincidence I saw that both modules were mentioned as supporting the Eeepc’s wireless card in the output of “lspci -v”. After I added the line “blacklist rt2800pci” to the file “/etc/modprobe.d/blacklist.conf” and rebooted the Eeepc, I had fully functional and stable wireless connectivity again, now using the “rt2860sta” driver!
  2. My sound was gone, or at least working at a very very low volume… I could hear the KDE logout sound if I put my ear to the keyboard but that was about it. Getting normal sound output levels through my headphones was no problem at all, however.
    The ALSA troubleshooting guide for HDA Intel audio hardware pointed me in the right direction: not getting sound through the built-in speakers while the headphone output works well is quite common, and often caused by not raising the correct channel’s volume.
    It turned out that after the upgrade to the 2.6.33 kernel, I need to set the “speaker” channel’s output level to anything non-zero or else there would be no sound…

I have to mention one other piece of strangeness I experienced on my netbook:

It is an issue not related to Slackware-current but rather to my use of the new “netbook” interface of KDE 4.4’s plasma workspace manager. I toyed with the netbook interface a bit, because it lets you use the small screen more efficiently – by removing unnecessary stuff like window elements and task bars. One typical treat is that every application window in the plasma-netbook workspace runs full-screen exclusively – there is no “minimize” button but instead you have to use the application switcher in order to access other running applications’ windows. Unfortunately, when I switched back to the “normal” plasma workspace, the “minimize” buttons did not re-appear in the title bar!
I had to manually re-add this button through “system settings > appearance > windows > buttons” and drag the “minimize” button into the titlebar preview.

Just so you know.

Eric

It’s been released: KDE SC 4.4.0

The KDE community has announced the immediate availability of the KDE Software Compilation 4.4.0 (“KDE SC” is the new name of what used to be called just “KDE“). In preparation for this event, the kde.org website was re-vamped yesterday to reflect their “shift in marketing and promotion vocabulary”. Looks shiny and new! Also, I think that the new layout makes it easier for people to find information about the KDE community and the software compilation.

Users of small form-factor laptops will be interested to learn that the new Plasma desktop manager now offers two workspace choices. One is the usual desktop-oriented workspace. The interesting addition is a netbook-oriented workspace, with special consideration for the netbook’s smaller screen and typical mobile usage patterns. I have not yet installed KDE 4.4 on my own Asus EEE netbook but I will most certainly do so, later this week!

In order to fully appreciate the work that went into KDE SC 4.4 and learn what has changed since KDE 4.3, you should definitely take the visual tour. Lots of new functionality and usability improvements are hidden beneath this new desktop workspace and just waiting to be discovered and used to the fullest.

Slackware packages galore!

Like I did with the pre-releases of KDE 4.4, I have prepared new goodies for all you Slackers. Get those 32-bit and 64-bit packages for Slackware Linux and install them on your computers (or build them yourself using the accompanying SlackBuild scripts, patches and sources).

You will find all of those at http://alien.slackbook.org/ktown/4.4.0/ .

Please take good notice of the fact that these packages are built for Slackware-current. You can safely install the KDE 4.4.0 packages if you are running a slackware-current from around 01 february 2010 or newer. Do not try to install these packages on Slackware 13.0.

Slackware 64-bit:

  • Don’t forget to also install the updated or new dependencies! These “deps” packages can be found in the “x86_64/deps” directory.
  • The KDE 4.4.0 packages themselves can be found in “x86_64/kde
  • And of course, the localization packages (non-english language translations of KDE) are available in “x86_64/kdei“.

Slackware 32-bit:

  • Don’t forget to also install the updated or new dependencies! These “deps” packages can be found in the “x86/deps” directory.
  • The KDE 4.4.rc2 packages themselves can be found in “x86/kde
  • If you need a language pack, you can grab one from the 64-bit package tree “x86_64/kdei” since these packages are in fact architecture-independent.

Here are the steps on how you download the packages and install them. You can have an older version of KDE installed, but that is not required. You will end up with KDE 4.4.0 installed on your system.

Instructions are for the 64-bit packages, I think you can figure out how to change them if you want the 32-bit versions:

  1. Download everything in the directory http://alien.slackbook.org/ktown/4.4.0/x86_64/ :
    # lftp -c "open http://alien.slackbook.org/ktown/4.4.0/ ; mirror x86_64"
  2. Change into the directory “x86_64? which has just been created in your current directory:
    # cd x86_64
  3. Remove the no longer required kdelibs-experimental package if you still have that installed. It is part of KDE 4.3.x (i.e. Slackware 13.0 did not have this package). If you do not have kdelibs-experimental on your system, you will get a harmless error message that you can ignore:
    # removepkg kdelibs-experimental
  4. Install/upgrade the KDE 4.4 dependencies:
    # upgradepkg --reinstall --install-new deps/*.t?z
  5. Install/upgrade KDE4.4.0 packages:
  6. # upgradepkg --reinstall --install-new kde/*.t?z
  7. Install/upgrade a language package if you prefer to have the KDE interface in your local language (I used “nl” in the example command, you should substitute your own language code there):
    # upgradepkg --reinstall --install-new kdei/kde-l10n-nl-*.t?z

Of course, you should not run those commands while running KDE…!

If you want to compile the packages from source like I did, that is entirely possible using the provided sources and build scripts. It will take quite a while though…

Have fun, Eric

Note for users of any KDE 4.4 pre-releases:


If you never before installed and used one of the Betas or Release Candidates of KDE 4.4 , then you can safely remove one package,  virtuosoconverter. This package is only needed if you were using “nepomuk desktop search” before this final release of KDE 4.4.0.

# removepkg virtuosoconverter

If you ran any Beta or Release Candidate of KDE 4.4.0 prior to upgrading to 4.4.0, then you will notice that your nepomuk database will automatically be converted from virtuoso v5 to v6, the very first time you login to your KDE 4.4 desktop. This process will take a while (not too long) and will temporarily double the size of your nepomuk database (by default, this database consumes a maximum of 50 MB in your homedirectory below ~/.kde).

If this database is not valuable to you, you can also decide to skip this database conversion by just deleting the database before starting KDE:

$ rm -r ~/.kde/share/apps/nepomuk/repository/*

or by following the instructions in Sebastian Trueg’s tutorial: http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/TipsAndTricks#Remove_all_Strigi-indexed_data

If you manually remove the old nepomuk data, you can also remove the virtuosoconverter package of course.

If you do not have any clue about what I am talking about and what you should do, just don’t do anything… and all will be well.

A final remark about nepomuk and strigi – I think that KDE 4.4 finally has a desktop search which is optimized to a level that it no longer eats all your CPU cycles or claim a large chunk of your harddrive. Now I just wish that the strigi developer properly fixes the indexing of my PDF files!

Newer posts »

© 2024 Alien Pastures

Theme by Anders NorenUp ↑