Alien Pastures

My thoughts on Slackware, life and everything

Month: October 2011 (Page 1 of 2)

Integrating NetworkManager into KDE while keeping the Gnome out

October 11, 2011 / / 46 Comments

I think that I am not wrong when I say that Networkmanager is the de-facto way of network configuration management in Linux. Most Linux distributions have implemented it. Slackware on the other hand, traditionally encourages the use of “vi” for network configuration management (by editing “/etc/rc.d/rc.inet1.conf“)… but in recent times, the WICD daemon has been added to the “/extra” directory of Slackware, and that includes a graphical network configuration utility. A lot of (particularly mobile) users like WICD, and so do I.

WICD is for the most part a one-man exercise and the main developer has stated that he is not able to work on the program as much as it deserves. That is not too good news, but I still have hopes for the project.

In the meantime, switching to NetworkManager is not a decision that should be taken lightly. Not because NetworkManager itself will give us issues, but because NM is only the service framework and it does not come with configuration utilities (either GUI or cli oriented – I do not consider the nmcli program adequate) that allow you, the computer’s user, to configure your network connections.

Traditionally, distros will add the “nm-applet” aka “network-manager-applet” to that purpose. The nm-applet is a graphical configuration utility that lives in your desktop’s system tray area. It is being developed by the NetworkManager team. However it is is a Gnome applet, and as such it is riddled with Gnome dependencies. Precisely for that reason it is not trivial to add nm-applet  to Slackware, one of the few Linux distros that does not contain Gnome.

I think that if you are a Slackware GUI lover, you should consider yourself very lucky that the WICD developer team has one passionate Slackware user (NaCl) as member!

Having said all that, I do not have any issues with Networkmanager itself. It’s just the default configuration tool which sucks because of its Gnome allegiance. Hmm, that is not completely true… in the well-known take-a-blunt-knife-and-kill-your-software style of Redhat they managed to break API as well as ABI compatibility with the release of the 0.9 series of NM last august… where did I hear this story before? Like with PolicyKit, HAL and systemd, Redhat managed to cause a lot of fuss when developers decided to throw away their code and start over with fresh insights…

Applications which have been written to interact with the old  0.8 interface of NM have to be re-written and that takes time. At this moment, many NM-aware programs still do not support NM 0.9.

While all of that passed, I have been keeping an eye on what happens in the KDE camp. The KDE software compilation has never had a good network configurator for the 4.x series and the team which was developing KNetworkManager seems to have dissolved. But there is good news: a new networkmanagement plasmoid (KDE widget) plus accompanying KControl is available, it supports NM 0.8.x and is stable enough that I have come to prefer it over WICD.

I have built a set of supporting packages (many thanks to Robby Workman for some of these SlackBuild scripts):

  • NetworkManager (the actual network service framework)
  • cnetworkmanager (a commandline interface to NM if you don’t like the GUI)
  • mobile-broadband-provider-info (world-wide database of mobile access providers)
  • ModemManager (accompanying bradband modem management)

These packages allowed me to recompile the kde-workspace package and make it pick up support for NM in KDE’s solid device management. And finally I added the package for the required configuration GUI, networkmanagement

You can get these packages from my ktown repository or any of its mirrors, I built them for KDE 4.7.2 and you will find them inside the directory called “test“.

You can install these packages (kde-workspace needs to be upgraded of course, not installed a second time) with a single command after downloading the packages appropriate for your hardware architecture (32bit or 64bit). Run the following command in the directory which contains the six packages:

# upgradepkg –install-new *.t?z

And please read the README file which specifies in great detail how to enable NetworkManagement while at the same time disabling WICD!

How does it look in KDE after you rebooted? Well, here is a screenshot:

My goal for the next releases of KDE (in case I will still be building the packages for it) is to compile kde-workspace in the presence of NetworkManager and thus add support for NM to the kde-workspace package. Then it will be up to you if you want to actually switch to NM or keep using WICD. The kde-workspace package will work fine even if you did not install NetworkManager.

Give me feedback! Eric

 

KDE bugfixes and how to use my modular KDE.SlackBuild

October 9, 2011 / / 18 Comments

KDE 4.7.2 fixes

In the past week, fixes have been posted to the KDE packagers mailing list, asking us to apply those to our packages. Both fixes are important enough that I updated my kdelibs and kdepim-runtime packages.

There is a fix for kdelibs of which Sebastian Trueg states “Hi packagers, sadly I introduced a serious issue into kdelibs 4.7.2 which was intended to be a fix. This bug prevents any query which does NOT use wide unicode characters to fail. The attached patch provides a workaround for this issue and will make all queries work“. Another patch is for the kdepim-runtime package. It fixes bug 283467 “Kmail has duplicated folders after migration from previous version”

Both updated packages are now available in the KDE 4.7.2 section of my “ktown” repository.

The 32bit packages:

The 64bit packages:

KDE.SlackBuild HOWTO

Some people have asked how to work with the modularized KDE.SlackBuild script. It is not immediately clear to everybody for instance how to apply patches, or how to rebuild individual packages. I will use this  opportunity to explain a bit about the innards of the new framework.

The KDE.SlackBuild concept is loosely based on Patrick’s modular X.Org build. For a user of the script, there are not really that many differences compared to building X.Org. Let me tell you more:

The directory structure

  • KDE.SlackBuild :this is the script which you run to build the complete KDE Software Compilation, or any number of its individual packages.
  • KDE.options : this file contains common options for all packages. For instance, it contains the version of KDE we are compiling, and the overall build number (usually all the packages will get a build number “1”)
  • build/ : If a package needs another build number than defined in KDE.options, you should create a new file in the “build” directory that must carry the name of this package. Iinside the file you write the desired build number.
  • cmake/ : This directory contains the actual compilation script, called “cmake”.. The cmake program is used to configure the source code for Qt/KDE based applications (make will be called afterwards to compile the configured soiurces). If an application needs a non-standard set of cmake/make parameters or commands, you must create a new file in this directory, carrying the name of the application, and inside you add the custom compilation commands. Use the default “cmake” script as your starting point. The KDE.SlackBuild script will then use this custom file instead of the default “cmake” file.
  • docs/ : The KDE.SlackBuild script will add a couple of common documentation files from the source tarball into the resulting package’s “/usr/doc” diretory. Think of files like “AUTHORS* CONTRIBUTING* COPYING* HACKING* INSTALL* MAINTAINERS README* NEWS* TODO*“. If an application’s source tarball contains other documentation files that you want to have added instead, then you should create a new file in the “docs/” directory, containing the application’s name and inside you add the files that the KDE.SlackBuild should add to the package’s “/usr/doc” directory.
  • doinst.sh/ : To every package a generic “doinst.sh” script will be added. This is the script which is run by “installpkg” and “upgradepkg” after installing the package (for instance to refresh the KDE menu or to register new MIME types). If an application needs its own “doinst.sh” script “doinst.sh” then you add it to the “doinst.sh” directory, the file should carry the name of the application (I am repeating myself a lot but that’s because the concept is identical for all these subdirectories)
  • makepkg/ : Creating the actual package after its compilation has been completed is accomplished by calling the “makepkg” command. If you have a package that needs a custom makepkg commandline you can add that here.
  • modularize : KDE Software Collection is built out of modules (think of modules like “kdelibs”, “kdenetwork”, etc…). These modules used to be distributed as big “monolithic” source tarballs in the past, and we would create one Slackware package for every module. This has changed since KDE 4.7.0 where the sources of these modules were split off into a lot of separate tarballs. The KDE.SlackBuild still builds one package per module if you do not tell it to do otherwise. If you need/want to split up a module into sub-packages, then you edit section in the “modularize” file which applies to this module. Every name you add to the “modularize” file (which must correspond to a source tarball of the same name) will be built as a separate package. for instance, the “kdebase” section contains the following lines, which means that compiling the “kdebase” module will result in the additional packages: konsole, kate, kde-wallpapers, kde-workspace, kde-runtime: These separate programs used to be included in the kdebase package itself previously:

# kdebase:
konsole
kate
kde-wallpapers
kde-workspace
kde-runtime

  • modules/ : This directory contains the KDE modules, one file per module. Inside each file you will find the basenames of the individual source tarballs which make up this module. If a source tarball is listed inside one of these files but is not listed in the “modularize” file (see the previous bullet) then the binaries resulting from compiling this source will be included into the main module package and not be split off into its own separate package.
  • noarch : Most of the KDE packages will be built for a specific machine architecture (i486 or x86_4 for instance). If a package does not contain machine-dependant code then its architecture type should be “noarch“. In that case you should add the name of the package to the “noarch” file.
  • package-blacklist :  The collection of source tarballs is bigger than what we support on the Slackware Linux platform (some of the sources apply to other distros only or to MS Windows, such as the “csharp” tarball for instance). The “package-blacklist” file is where you enter the names of source tarballs to skip compiling  Just the application’s basename – no version.number is needed.
  • patch/ : This directory contains patch scripts for applications (see further down for more detail).
  • post-install/ : A few packages need additional work after the “cmake && make && make install” sequence. If you need that, you can add a file with the name of the application inside the “post-install” directory containing those commands.
  • pre-install/ : A few packages need additional preparation before the “cmake && make && make install” sequence. If you need that, you can add a file with the name of the application inside the “pre-install” directory containing those commands.
  • slack-desc/ : Every package that is going to be created needs a descriptive file (the package’s slack-desc file). They go into the “slack-desc” directory, each carrying the name of their application.
  • src/ : All the KDE sources go in here. It does not matter if you put some of the sources into their own subdirectory, the KDE.SlackBuild script will figure out where they are. For instance, I moved the “extragear” sources (these are the applications which do not belong to the core of KDE SC) into a subdirectory “extragear” but in fact the name can be arbirtrarily chosen.

Compiling one or more single packages

By default, the compilation script “KDE.SlackBuild” will compile all the packages for the KDE Software Compilation. If you want to build only one module, or only a few of a module’s sub-packages, then you have to call the script with the appropriate parameters. If you want to build a sub-package you have to specify to which module it belongs. A module and a sub-package are separated by a colon (:). Multiple sub-packages are separated by a comma (,).

The generic method is:

# ./KDE.SlackBuild [ module[:subpackage1,subpackage2,…] [ module[:subpackage1,subpackage2,…] …] ]

For instance:

  • To compile only the “kdelibs” module, you run:

# ./KDE.SlackBuild kdelibs

  • To compile the “kdelibs” module as well as the kdepim-runtime package which is a component of the “kdepim” module:

# ./KDE.SlackBuild kdelibs kdepim:kdepim-runtime

  • To compile packages for kalgebra, kstars and marble which are all components of the “kdeedu” module, you run:

# ./KDE.SlackBuild kdeedu:kalgebra,kstars,marble

You see that it is actually quite simple, although a bit different from the old method (until KDE 4.6) of building individual packages.

Applying a patch to a KDE package

If you need to patch a package in the KDE Software Compilation, then you must first create a subfolder in the “patch” directory with the name of the package. Then add the patch file into that subdirectory. Finally create a file <packagename>.patch (or edit the file if it already exists) in the “patch” directory, The file “<packagename>.patch” must perform the actual patching, and the patch command must be appended with the following series of commands in order for KDE.SlackBuild to determine if the patch failed or not:

 || { touch ${SLACK_KDE_BUILD_DIR}/${PKGNAME}.failed ; continue ; }

And to make the new package name differ from the old version, you have to update its BUILD number. Edit (or create) a file in the “build” directory for the package and write the new BUILD number in that file. Usually the new BUILD number is one higher than the previous if that was an integer value.

 

Checking if your sources match the build files

Suppose you are not certain if the source tarballs you added to the “src/” directory match the available slack-desc files and module files, you can run the build script with an additional environment variable. If you run the following command, the KDE.SlackBuild script will compare the content of the “src” directory with the content of the “slack-desc” directory and the content of the “modules” directory and will complain if it finds anything amiss (and abort the script):

# PRECHECK=yes ./KDE.SlackBuild

 

I hope this clears up things a bit for you!

Cheers, Eric

Recipe: Spanish chicken

October 8, 2011 / / 3 Comments

I cooked diner tonight and it was yummy… so I decided to write it down in the blog.

My son who was going to assist me in the kitchen asked to create “something with cheese” before I drove to the supermarket, so I complied and added cheese, but if you are going to cook this recipe, you will find that it works even better without the cheese.

This “spanish chicken with chorizo and potatoes” is a variation on a recipe originally published by Nigella Lawson in her book Kitchen and to which I added some of my own ideas. It will cost you a minimum of effort to prepare this meal, since most of your time will be spent sitting in front of the oven and watching the chicken crackle and pop.

The result tastes deliciously because the combination of the spicy chorizo and the orange peel does wonders. I used an oven-proof pyrex dish which makes for a nice presentation when you serve it at the diner table.

Don’t take the amounts too seriously… this dish can not fail you. If you want, just add more chorizo and onion, or try and leave the tomatoes out.

Ingredients (4 persons):

  • 8 chicken drumsticks
  • one onion, cut into rings
  • two table spoons of vegetable oil (olive or sunflower)
  • black pepper, paprika powder
  • 500 grams of chorizo sausages
  • 600 grams of potatoes
  • 300 grams of cherry tomatoes, cut in halves
  • one orange
  • grated young cheese
  • dried oregano

Preparation:

  • Pre-heat the oven to 220°C
  • Cook the potatoes for about 10 minutes. If you do not cook them before they go into the oven, they might not be fully cooked when it is time to serve the dish.
  • While you are waiting for the poratoes, you can continue with the preparations. Pour two table spoons of vegetable oil into a shallow roast pan or pyrex oven dish and mix in a generous sprinkle of paprika powder and ground black pepper.
  • Add the chicken drumsticks to the oily mixture and use your hands to rub the oil into the skin of the drumsticks. If you like to keep your hands clean, you can just as well put the oil, spices and drumsticks into a plastic bag and mix the ingredients thoroughly, then dump them into the roasting pan. Make sure that the skin side of the chicken is pointing upward.
  • Add the chorizo sausages in between the drumsticks. If you bought a large chorizo, chop it up into chunks of a centimeter first.
  • Use a grater or a vegetable peeler to scrape the outer skin off the orange. be sure not to cut into the white inner skin! That tastes foul. We only want the orange outer skin. You end up with orange peel, or zest. Keep the zest. If you want, you can squeeze the juice out of the orange and drink it, we won’t need the juice for this recipe.
  • By now the potatoes will have cooked long enough. Cut them into slices of half a centimetre and place them inbetween the drumsticks, preferable on the bottom of the roasting pan so that they will be fried in the oil (children will love that)
  • The onion rings and the halved cherry tomatoes are placed in between the other ingredients
  • Sprinkle the orange peel on top – the aromatic smell of the zest is enough to make my mouth water!
  • Sprinkle generously with dried oregano
  • Put the dish in the oven and let it cook for 40 minutes. Be sure to open the oven door from time to time and watch those chickens sizzle!
  • If you want to try this with cheese, you have to get the dish out of the oven after 30 minutes and spread grated young cheese on top, accompanied by another sprinkle of oregano.. The final 10 minutes of oven time will allow for a nice layer of molten cheese.

I served this with a green salad mixed with ground nuts, raspberries and spicy cheese (cut into small cubes) and a vinaigrette of raspberry-flavored balsamico (the salad was another idea from my son, which he executed while I was busy with the chicken).

Enjoy your meal!

Eric

Another maintenance release: KDE 4.7.2

October 5, 2011 / / 33 Comments

This time, the KDE release team was pretty quick with their KDE 4.7.2 source tarballs. Normally, distro packagers get a few days of headstart so that they can create packages in time for the source release, but this time I was not yet ready compiling.

Anyway, here they are, myKDE 4.7.2 packages for Slackware.

I guess all of you are used to the modularized KDE. Read my post about KDE 4.7.0 if you want to know more about the reasons for splitting KDE for Slackware into many more (and smaller) packages.

These packages were compiled on Slackware-current but there is a good chance that they will work problemfree on Slackware 13.37 too. I have received several reports from people who tried this and were happy. Still:

Read the accompanying README file for installation and upgrade instructions!

Some of the highlights of these KDE packages:

  • There are several updated dependencies compared to Slackware’s own KDE 4.5.5: PyQt, QScintilla, akonadi, attica, clucene, ebook-tools, hunspell, libdbusmenu-qt, phonon, polkit-qt-1, qt, raptor2, rascal, redland, shared-desktop-ontologies, sip, soprano, strigi, system-config-printer and virtuoso-ose.
  • In comparison with my previous 4.7.1 there are only two updated dependencies: libbluedevil and strigi. The upgrade of Qt to 4.7.4 which I did for the previous 4.7.1 package set added stability to the 4.7 series. I wish I had added an up-to-date Qt4 when I released 4.7.0 packages because I was quite unhappy with the desktop experience back then. However the new Qt4 package deals with the false SSL certificates issued after the CA authority DigiNotar got hacked which is another good thing to have.
  • KDE dpendencies that are not part of Slackware 13.37 at all (yet): grantlee, herqq, libatasmart, libbluedevil, libssh, phonon-gstreamer, phonon-xine, sg3_utils and udisks. Note that I added phonon-gstreamer and phonon-xine only after I had already released KDE 4.7.0 packages because people reported that they no longer had sound. These two packages solve that issue.

Not new since I added these to KDE 4.7.1 before (but you may be new to KDE 4.7 so I will repeat myself here):

  • You will find three useful new applications, compared to Slackware’s own version of KDE: I already added bluedevil to my 4.6.5 package-set. Bluedevil is the new KDE bluetooth stack with a nice GUI, based on the BlueZ libraries already present in Slackware. And with KDE 4.7.0, I included kplayer, a KDE front-end to MPlayer. This time, I added Quanta Plus, which disappeared from KDE4 because that migrated from Qt3 to Qt4. It is now being worked on again, but no longer as a standalone application – instead it is available as a plugin to the Kdevelop Platform.
  • I also added oxygen-gtk, which is not really an application, but a theme engine. It (optionally) makes GTK applications visually blend in with KDE’s own Oxygen theme. There is a README in its documentation directory which explains how to enable it.

The KDE 4.7.2 packages for Slackware-current are available for download from my “ktown” repository and several mirrors (taper is in sync when I post this, the other mirrors still have to catch up):

Have fun! Eric

Digitizing my paperback books

October 4, 2011 / / 12 Comments

Part one: what do I want?

I hinted at this topic in a previous post. I have a big collection of (mostly) paperback Science Fiction books – some hardcover books too. I used to read a lot more in the pre-Internet days, nowadays it’s just during my holidays that I get enough time to read whole books in a short enough time… so many of those old paperbacks are 20-30 years old and yellowed.

In this digital age it would be appropriate to have digital versions of my books and save them from crumbling to dust. I am in anticipation of Sony’s new e-reader, the PRS-T1 which I want to buy once it is out:

This is a very nice device. It is also a lot cheaper than the previous generation Sony e-reader (the PRS-650) while at the same time adding wireless connectivity. This device needs content once I have it in my possession.

A lot of the “newer” books, and those written by contenporary authors can be purchased online, or downloaded from fan sites where people scan their own collections into EPUB or MOBI e-books.  That is all good and well, but on my bookshelves I have many dozens good books that will probably never see a new life as an e-book. That is very unfortunate… I had a lot of fun reading them and do not want to see them go into oblivion.

I decided to do something about this. I am going to try and describe (and hopefully implement) how I am going to digitize my book library. Note: at the moment this is all just ideas, “dreams” if you wish, although I have already found quite a bit of information on the Internet that I will be sharing with you. I want it to be more than just a dream.

What does one need to get a paper book converted into an e-book?

  1. the book’s pages need to be scanned
  2. the scanned bitmaps may have to be cleaned-up digitally (enhancing the contrast between characters and background, de-skewing or rotating the text blocks, …)
  3. I need an Optical Character Recognition (OCR) program to convert the bitmap images into character text
  4. I need an e-book editor to layout the bare text that I got from the OCR program – the ebook has to look largely like the original paper version.
  5. I want to use a library program to make my book catalogue available, to myself of course, to my e-reader device, and possibly to other interested parties.

And I want this to be as low-cost as possible. Any software that I am going to use for this should preferably be Open Source and run on Slackware.

Those are the main topics I will write about. Each of these topics deserves its own separate article. Why is that?

I can already see how this project will confront me with interesting challenges. I am going to write a multi-post story with interlinked articles (this being the first) in order to preserve this hobby project of mine for posterity. Having separate topic articles allows me to split up your feedback as well (heh… I hope I do get some feedback!), so that discussions about, say, scanning techniques will not interfere with talk about what is the best OCR program for Linux.

The articles are not going to be “static” per se. I value your feedback and important new insights will find their way back into the main text.

Let’s see where this ends. It is probably going to take days, or weeks,  to write. It delends a bit on Slackware development – if that picks up speed again, I will have less time for this ebook side show. But for the moment , there is silence in the ChangeLog.txt and I have time to spare.

Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑