The Linux Experiment

I’ve decided to try and upgrade my LFS system to the latest version of KDE (4.7.3 as of the time of this writing) and correspondingly needed to upgrade phonon-backend-gstreamer. Unfortunately, following the previous version’s compilation instructions provided this nasty message:

[ 4%] Building CXX object gstreamer/CMakeFiles/phonon_gstreamer.dir/audiooutput.cpp.o
In file included from /sources/phonon-backend-gstreamer-4.5.1/gstreamer/audiooutput.cpp:22:0:
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:38: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:38: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:200:69: error: template argument 1 is invalid/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:262:42: error: template argument 1 is invalid
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:263:45: error: ‘Phonon::MediaController::NavigationMenu’ has not been declared
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’
/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:11: error: ‘NavigationMenu’ is not a member of ‘Phonon::MediaController’/sources/phonon-backend-gstreamer-4.5.1/gstreamer/mediaobject.h:317:42: error: template argument 1 is invalid
make[2]: *** [gstreamer/CMakeFiles/phonon_gstreamer.dir/audiooutput.cpp.o] Error 1make[1]: *** [gstreamer/CMakeFiles/phonon_gstreamer.dir/all] Error 2make: *** [all] Error 2

To fix this issue, make sure you have the latest GStreamer and phonon-backend-xine installed. Then I followed some of the advice from this KDE forum topic.

If, like me, you installed Qt into /opt/qt, create a symbolic link into the qt directory pointing to your system’s latest version of phonon. For later success with kde-runtime, create links to the libphonon libraries in /opt/qt-4.7.1/lib to your recently compiled /usr/lib64 versions (adjust paths to /usr/lib on 32-bit systems):

# mv /opt/qt-4.7.1/include/phonon /tmp
# ln -snf /usr/include/phonon /opt/qt-4.7.1/include/phonon
# cd /opt/qt-4.7.1/lib
# rm -rf libphonon*
# ln -snf /usr/lib64/libphonon.so libphonon.so
# ln -snf /usr/lib64/libphonon.so.4 libphonon.so.4
# ln -snf /usr/lib64/libphonon.so.4.5.1 libphonon.so.4.5.1
# ln -snf /usr/lib64/libphononexperimental.so libphononexperimental.so
# ln -snf /usr/lib64/libphononexperimental.so.4 libphononexperimental.so.4
# ln -snf /usr/lib64/libphononexperimental.so.4.5.1 libphononexperimental.so.4.5.1

Then rerun the compilation process for phonon-backend-gstreamer and voila, no more errors. (You’ll probably still have more issues to work out, but this gets past the phonon-backend-gstreamer blockade.)

Seriously, I’d like to know, because this is a bit ridiculous.

For all the heavily encouraged coding styles out there, nearly all the open source software packages I’ve had to compile for Linux from Scratch have either

1. Insanely chatty defaults for compilation; that is, GCC provides ‘notices’ about seemingly minor points, or
2. A large number of warnings when compiling – unused variables, overloaded virtual functions, and deprecated features soon to disappear.

In the worst case, some of these warnings appear to be potential problems with the source. Leaving potentially uninitialized variables around seems to be a great way to run into runtime crashes if someone decides to use them. Overloading virtual functions with a different method signature has the same possible impact. And comparing signed and unsigned numbers is just a recipe for a crash or unpredictable behaviour down the line.

I just don’t get it. In my former development experiences, any compiler notifications were something to pay attention to. Usually when first developing an application, they were indicative of a typo, a forgotten variable or just general stupidity with the language. If a warning was absolutely unavoidable, it was specifically ignored in the build scripts with a clear explanation as to why.

So what’s the case with your programs? Have you noticed any stupid or insightful compiler messages scrolling past?

I’ve now been actively using my (Beyond) Linux from Scratch installation for about a week now, and it’s actually pretty neat to have something working that I built with just a general outline. Granted, the LFS guide is very well put together, but going beyond the basic console of a system requires a bit of time and effort.

In really any other distro, the package manager should really be your best friend (except when it breaks.) Even in a source-based Linux like Gentoo, Portage gives you a pretty decent idea of what’s installed and is able to keep track of dependencies. With LFS, there are really some times where I don’t want to have to locate and download seventeen .tar.bz2 files, and ./configure –prefix=/usr; make; make install to each one in sequence. What’s worse is when you run into three dependencies for a particular piece of software, and the first two install properly, but the third one depends on ten additional packages.

This is what building software in LFS looks like.

There are also some libraries that despite being built on an x86_64 system will come out as 32-bit, and require special compiler or configure flags in order to build a pure 64-bit version. LFS x86_64 does not really have patience for anything 32-bit. This is generally fine because you’re building most of the applications yourself, but you can’t “just run” any typical application unless it’s taken the architecture into account.

In summary, while it’s awesome to go to SourceForge and have the very latest version of a package, sometimes I just don’t feel like going through all those hoops and satisfying twenty conditions for a compile to take place. Perhaps I’m OK if your application uses a built-in library rather than relying on whatever happens to be installed in /usr/lib.

The takeaway from this is that besides providing the source, considerate developers should try and build an i686 and x86_64 binary from that same source. If your build system has issues or you find it painful to produce binary releases, remember that anyone attempting to follow the INSTALL file will run into the same pain points. Firefox, for example, has both i686 and x86_64 release tarchives. The 64-bit version works quite well on my LFS installation and it’s how I’m writing this post.

Since the install of Linux From Scratch, one of the main issues I’ve been having is the playback of audio and video files. VLC does both quite well, so I decided to install it.

Like most of my installs in Linux From Scratch, there are millions of dependencies, and you have to install each one manually. I found that the CBLFS VLC page was a great help in determining which packages were required.

One thing I noticed, is that even though it lists some packages as “Optional,” VLC will not compile without a few of them. The easiest way to deal with this is to just install the optional packages as required.

I only ran into one issue while compiling:

D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

The quick fix for this is to just run:

dbus-uuidgen > /var/lib/dbus/machine-id

Now that VLC is compiled, you can run it anytime by using vlc from the command-line. Make sure you don’t pull a Jake and run it as root. It will yell at you.

So I’m a big Dropbox user. I primarily use it to keep my personal info synchronized between my machines (don’t worry, I encrypt my stuff before dumping it into Dropbox, I’m not dumb), but it’s also handy for quickly sharing files with others.

Unfortunately, Dropbox doesn’t exist in the Gentoo portage tree.

To get started, head over to the Dropbox website and download the source tar.bzip file for your platform. Unzip it to your desktop, open a root terminal and cd into the resulting directory. Before you can actually install Dropbox, you’ll need to satisfy a few dependencies.

First, make sure that you’ve got python by typing emerge python into the aforementioned root terminal. Next, install docutils by typing emerge docutils in that same terminal. Now you should be able to install the dropbox stub by typing ./configure && make && make install.

At this point, Dropbox will have installed a stub of an application on your machine. You should be able to find it under Applications > Internet > Dropbox. When you launch this application, Dropbox will attempt to automatically download and install the binary portion of the application.

Optional: Verifying Binary Signatures

When dropbox downloads binary files, it verifies their legitimacy by calculating a digital signature and comparing it to a known value. In order for it to perform this task, you’ll need to have the pygpgme library installed on your system. Note that this is not the same as the python-gpgme library. They are different, and Dropbox requires the former. Like most Python libraries, pygpgme is a wrapper around a c-based library, in this case, GPGME. As such, the installation takes two steps. First, run emerge gpgme in your root terminal.

Second, you’ll need to install the pygpgme wrapper. It can be found on the project’s homepage at Launchpad. Unpack the tar.bzip, cd into the resulting directory, and run python setup.py build && python setup.py install from a root terminal. If the installation fails with an error message like

fatal error: gpgme.h: No such file or directory

then check the location of your gpgme.h file. It should have been included with the emerge gpgme command, but pygpgme expects it to live in /usr/include/. On my system, it was living in  /usr/include/gpgme/. I solved this problem by running cp /usr/include/gpgme/gpgme.h /user/include/. The only catch is that if you upgrade GPGME, you’ll need to remember that you copied the header file in order to make the python wrapper work. Once the file is copied, you should be able to run the setup script above.

Finally, run Dropbox and check to ensure that the warning message about binary signatures has gone away. You should now be good to go!

Edit: After I had figured all of this crap out, I realized that Dropbox actually is available in the Gentoo tree, but it’s called gnome-extra/nautilus-dropbox. You should be able to skip all of these steps and install Dropbox with the command emerge nautilus-dropbox, although I haven’t tried it myself.

I’ve decided to roll Kubuntu 11.10 for this round of The Linux Experiment. Why Kubuntu? Well, a while back one of my teachers used xubuntu on his laptop, and I thought it looked interesting. Before Googling the distribution, I saw a picture of a koala on imgur and the letter “k” was in my head, so now I’m stuck with Kubuntu. No seriously, that’s pretty much the logic behind the decision.

If you’ve never read this site before, I ran Linux Mint with GNOME in the original experiment and survived. Obviously this time I’ll be going with KDE so that in itself will provide a change.

Installation

The installation was very easy. I downloaded a torrent of the distribution (don’t worry, I’m still seeding!) and then used Linux Live USB Creator to create a USB stick I could boot from. I estimate the entire process took me less than 30 minutes. The only part that required any sort of thought was selecting the installation partition: either the entire drive, or a partition consisting of the entire drive. I’m still not entirely sure what I did, but I went with the entire drive. I bet that won’t bite me in the ass at all!

First impression

Kubuntu is a little odd – it looks sleek, but it sounds straight out of 1996. What I mean is that it looks fantastic, but the default sounds remind me of Windows 95. For example, this is the startup sound. There were other system sounds that made me nostalgic for Heroes of Might and Magic II – not necessarily a good thing. On the other hand, it has a very crisp layout, and although I haven’t done too much customization or organization yet, it looks promising.

My first installation was Firefox. It was easy enough to do. I hit Windows (“Meta”) + Spacebar, typed in Firefox and the OS located the browser installation for me. Thunderbird required going into the software manager, but really once Firefox is installed you can just Google everything anyway.

As for other minor comments: the keyboard shortcuts aren’t as intuitive. The Meta key on its own doesn’t seem valid as a shortcut (I’m used to bringing up my menu this way), and Meta + D doesn’t bring up the desktop like it did in Mint. The screenshot application also takes some figuring out, but I’ll get the hang of it.

Oh, and I ran into an integer overflow right off the bat. It’s from the comic widget – I’m not sure if this is a Kubuntu thing or something to do with the widget itself. Anyway, I don’t think there are that many Spanish-speaking readers of xkcd.

Ay Dios mio!

I wrote a simple script that you can download here that makes it easy to update your Gentoo system. It first re-syncs your portage tree so that you are pointing to the newest source files. Then it performs a deep update including build dependencies on all packages that have new versions or could be rebuilt because you have modified your USE flags. It also upgrades any build dependencies and tools. Finally it removes unused dependencies and attempts to fix any broken packages that now have new dependencies.

#!/bin/bash
emerge –sync
emerge –update –deep –with-bdeps=y –newuse –ask world
emerge –depclean
revdep-rebuild

I also found this excellent website that makes it very easy to search for Gentoo packages and see what use flags you can apply to them.

Hi Everyone,

Now that I have a relatively stable environment, I just wanted to write an update of how things went, and some issues that I ran into while installing my desktop environment.

No Sound

Not that I was expecting anything different from LFS, but I had no sound upon booting into KDE. I found this quite strange, as alsamixer was showing my sound card fine. One thing I can tell you, is that alsaconf is a filthy liar. My sound is now working, and it still says it can’t find my card. I’m not sure how I got it working, but here are a few tips.

• Make sure your sound is un-muted in alsamixer.
• Check your kernel to make sure that either support is compiled in for your card, or module support is selected.
• If you selected module supprt, make sure the modules are loaded. For me, this was snd-hda-intel.

Firefox and Adobe Flash

I’m not going to go into too many details about Firefox, as Jake covered this in his post here, but I’d like to note that installing Flash into Firefox was quite easy. All I had to do was download the .tar.gz from Adobe, and do the following:

tar -xvf flash.tar.gz (or whatever the .tar.gz is called)

cd flash

cp libflashplayer.so ~/.mozilla/plugins (make sure plugins is created if it does not exist.)

KDE Crash On Logout

The first time I tried to logout of KDE, I noticed that it crashed. After doing some investigations, I found a solution here. You want to edit your $KDE4_PREFIX/share/config/kdm/kdmrc to reflect the following:

[X-:*-Core]
…
TerminateServer=true

What’s Next?

I’m actually not sure what I’m going to do next. I suppose I should get VLC running on the system, but that shouldn’t be too difficult. I now have a working web browser, flash, and sound, which should be fine until I can get other things working.

Using the instructions from the BLFS book with the latest available 3.6 build of Firefox, I was able to achieve success. I figured I’d try out 3.6 before going onto something with a terribly inflated version number, and as per usual, ran into some problems:

• Rebuild libpng-1.5.5 with APNG support. This is actually optional as I ended up commenting out the –with-system-png option in mozconfig.
• In the suggested mozconfig, comment out the last two lines:
  

  #ac_add_options --with-system-libxul
  #ac_add_options --with-libxul-sdk=/usr/lib/xulrunner-devel-1.9.2.13

  to create a standalone build.

• Apply the GCC patch from this Bugzilla report (direct download).
• Apply a partial patch from the Chromium project of all places. I’ve customized it here:
  

  
  # TLE Patch for Firefox/LFS

  diff -u a/gfx/ots/src/os2.cc b/gfs/ots/src/os2.cc
  — a/gfx/ots/src/os2.cc 2011-11-02 07:10:17.000000000 -0400
  +++ b/gfx/ots/src/os2.cc 2011-11-02 07:10:30.000000000 -0400
  @@ -5,6 +5,7 @@
  #include “os2.h”

  #include “head.h”
  +#include <cstddef>

  // OS/2 – OS/2 and Windows Metrics
  // http://www.microsoft.com/opentype/otspec/os2.htm

• Apply a GCC4.6-specific patch to fix various .cpp files. Some parts of the patch will fail; that’s expected.
• Manually edit layout/style/nsCSSRuleProcessor.cpp and go to line 1199. Change the source code as follows:
  
  const nsCaseInsensitiveStringComparator ciComparator;
  should become
  
  const nsCaseInsensitiveStringComparator ciComparator = nsCaseInsensitiveStringComparator();
  
• For the toolkit/components/places/src/SQLFunctions.cpp file, change line 126 to:
  const nsCaseInsensitiveStringComparator caseInsensitiveCompare = nsCaseInsensitiveStringComparator();
• In toolkit/crashreporter/google-breakpad/src/common/linux/language.cc, make sure line 51 is changed to:
  const CPPLanguage CPPLanguageSingleton = CPPLanguage();
• In toolkit/xre/nsAppRunner.cpp, line 990:
  
  static const nsXULAppInfo kAppInfo = nsXULAppInfo();
  
• While this is resolved in newer Firefox versions, copy security/coreconf/Linux2.6.mk to security/coreconf/Linux3.1.mk to add support for the 3.1 kernel.

Your reward will be a working Firefox installation:

Tonight, I finally got X11 working on my Gentoo machine. For those who are following along, on Tuesday night I managed to get my machine up to a command line. The next logical step is a graphical window manager.

I’ve chosen to give Gnome3 a spin, but before I can dive into all of it’s shiny UI-goodness, I need an X11 server installed on my machine. Because I have an nVidia graphics card in my machine, and I’ve had great luck with Ubuntu’s proprietary nVidia drivers in the past, I decided to skip over the open-source Nouveau drivers this time around. I started out the installation by following Gentoo’s nVidia guide, supplementing with info pulled from the nVidia entry on the Gentoo Wiki.

Although X is supposed to configure your system automagically, it couldn’t find my screens or devices on my first run of startx. I looked about the internet for a bit, and found out that you can force X to automatically configure itself. Simply run Xorg -configure and copy the file that it creates into your Xorg config directory (you can find it in the log file, mine is at /usr/share/X11/xorg.conf.d/).

In my case, these automagical settings still needed a bit of tweaking. I noticed in the log file (again, mine is at /var/log/Xorg.0.log, your mileage may vary) that X was failing to load GLX, which is essentially for 3D acceleration. In my case, GLX was installed, but it NVIDIA’s version wasn’t being loaded. Once again, the Gentoo Wiki came through for me, instructing me to run eselect opengl set nvidia. This worked like a charm.

Finally, I had to install twm and xterm so that I could see X working. That was a quick and painless process. Now on to Gnome!