Never fear though, if you are willing to do a little bit of work . . . → Read More: Backporting new code to Debian packages]]> I like Linux distros packaging systems, especially Debian’s. It makes it trivial to install, remove and change to different versions of programs. The only problem is that sometimes there is a delay in packaging the latest version of an app.

Never fear though, if you are willing to do a little bit of work you can shoehorn the latest code into a package yourself without needing any special knowledge of how to create packages. Note this will only work with programs that already have been packaged since it re-uses the old packaging info with the new code.

I refer to Debian, but the exact same procedure will work on any deb based distro, such as Ubuntu.

Before starting make sure you have the devscripts and build-essential packages installed. These will install all the tools needed to build debian packages.

First download the source package of the old version.

apt-get source $NAME

Then, as a sanity check cd into the created directory and run

debuild -i -us -uc

This will probably complain about missing packages needed for building, so go ahead and install them with apt-get or aptitude or whatever. Then re-run the build command. Assuming that works you should end up with some .deb files in the parent dir.

Now grab the code for the latest version from its website. If it is not already in a tarball you’ll want to make one from it with

tar czf application_version-1.orig.tar.gz applicationdir

If it is a tarball already then just rename it to match the formatting application_version-1.orig.tar.gz. For example when backporting mesa I name the tarball mesa_7.7.0-1.orig.tar.gz.

Next copy the debian dir from the old application directory to the new one.

cp -a application-debianversion/debian application-newversion/

Then cd into the new directory and run

debchange -v version-1 "Updated code to latest version"

It is vital that the version number used in this command matches the naming of the .orig.tar.gz file you created earlier. For example for mesa I use 7.7.0-1. This is the magic that will make everything work.

The final step is to build the new package.

debuild -i -us -uc

and tada! With a bit of luck your shiny new version should be packaged up and ready to be installed.

By using the strace command I found it was hanging on a futex call, starting in safe-mode and even deleting .mozilla didn’t fix . . . → Read More: Firefox 3.5 startup problem (solved)]]> Firefox^[1] 3.5 has been out for a while now, but I’ve only recently managed to switch due to the program not starting up unless I use a weird command line hack.

By using the strace command I found it was hanging on a futex call, starting in safe-mode and even deleting .mozilla didn’t fix it. I found a forum thread on the mozilla forum that shows I’m not the only one to come across this. There was a fix described in a post linked from there, but it only worked by editing the launch command, and I’m not prepared to dig through the OS and replace every instance of the launcher to make it work.

Yesterday though I found the real culprit, it was padsp! A long time ago I had set Firefox to use padsp in order to get flash sound to work correctly with pulseaudio. I had totally forgotten I had done this, because I had made the change in /etc not in my home folder.

So if you find Firefox 3.5 won’t start on linux even though 3.0 works fine then check if you have a FIREFOX_DSP (or ICEWEASEL_DSP if on Debian) set somewhere. For me the fix was this:

In file /etc/iceweasel/iceweaselrc:

# which /dev/dsp wrapper to use
ICEWEASEL_DSP="padsp"

See the ICEWEASEL_DSP line, delete it or comment it out and Iceweasel starts working. If you are using vanilla Firefox then obviously replace every instance of the word iceweasel with firefox to implement the fix on your system.

Hope this helps someone. Oh and flash now works fine with pulseaudio without the padsp thing too.

Perhaps the most important changes have to to with auto-scaling. Synaptics obtains the touchpad dimensions from the kernel and adjusts speed, acceleration, the edges and more depending on these dimensions.

via Who-T: Synaptics 1.1 and what . . . → Read More: Who-T: Synaptics 1.1 and what your touchpad can do now]]> The synaptics driver. So, here’s a list of things that have changed recently with version 1.0 and 1.1.

Perhaps the most important changes have to to with auto-scaling. Synaptics obtains the touchpad dimensions from the kernel and adjusts speed, acceleration, the edges and more depending on these dimensions.

via Who-T: Synaptics 1.1 and what your touchpad can do now.

There has been some interesting progress on the open-source drivers for ATI graphics cards recently. It has long been a goal of mine to have a completely Free kernel, it’s why I bought this laptop rather than an NVidia-based one. I want better 3D performance than Intel . . . → Read More: Let my kernel be Free]]>

Playing a movie using Free driver

There has been some interesting progress on the open-source drivers for ATI graphics cards recently. It has long been a goal of mine to have a completely Free kernel, it’s why I bought this laptop rather than an NVidia-based one. I want better 3D performance than Intel can offer and was originally going to go NVidia because their Linux support was better. Then ATI released the first load of specs for their cards and I switched my preference. In the end I bought a Toshiba laptop with a Radeon Mobility 2600 graphics chip (also known as an M76 chip).

I’m not a zealot when it comes to Free software, I am a pragmatist, I use whatever works best for me. But experience has taught me that when it comes to Linux kernel code the non-free stuff is always problematic. Practically every kernel crash I’ve ever had can be traced back to some non-free driver I had in there. Who is to blame for this I’m not going to go into, there are arguments on both sides, but the fact is that if you want a completely stable Linux system you are better off keeping the kernel Free.

Of course it takes time to write drivers for something as complex as a graphics card, so up till now I’ve been using the proprietary fglrx drivers from ATI. A necessary compromise, since when I first installed Debian they were the only thing that would get X to even run. It works well enough once you learn to avoid doing the things that cause it to crash (like logging out of KDE), but it adds a hassle to upgrades (having to recompile a kernel module, which often fails and needs custom patches) and is rather finicky about its settings. I’ve periodically tested the state of the Free drivers, both radeon and radeonhd, and seen steady progress.

Today I found that they have finally reached the good-enough point where I can switch. The must-have feature for me is tear-free video playback that doesn’t cause my CPU usage to skyrocket (and hence kick the fan up to unacceptable noise levels). This means the driver needs accelerated 2D and xv support, which has now been achieved.

One quick point for anyone else wanting to switch to the Free driver from fglrx. It won’t work unless you uninstall fglrx, if you just install them side-by-side and tell X to use the Free driver it will show a corrupted image or a black screen then hang. I thought there had been a major regression until I tried removing fglrx, after which both free drivers worked perfectly.

I’m using the xserver-xorg-video-radeon driver from Debian sid, along with a custom kernel to get the required DRM support. The latest (2.6.29) kernel in sid doesn’t have the right versions of radeon.ko and drm.ko that are needed for the 2D acceleration to work. There are two ways to get these, you can either compile a new kernel using the drm-rawhide branch of Dave Arlie’s kernel http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary. Or you can just use the instructions on the X wiki to just compile new versions of those two modules.

I’m using a whole new kernel because I also want to experiment with kernel mode setting. Since radeonfb has never worked on this hardware and the best resolution vesafb can give me is 1024×768 (native res of the LCD is 1280×800), KMS is the only hope I have of getting a VT at the proper resolution.

There is no 3D support in the version of the driver I’m using, but support for that is being written as I type so I’m hopeful I won’t have to do without for long. It isn’t a huge loss for me since I only use it for playing KotOR under wine and if I get desperate I can reinstall it in Windows (I dual-boot the laptop). 3D would be good for when I switch to KDE4 but again, I can live without it for a while. I’m happy with what I have for now, and it won’t be that long before full 3D support comes along (and I won’t have to fiddle with code to get it, just aptitude upgrade).

I’ve had a virtual machine running KDE4 from the Debian experimental repos for a while now. Every few months, when I notice some announcement of a point release I update it and give it another try. Up till now I’ve always been disappointed in some way.

I first tried it . . . → Read More: KDE 4 finally ready for Prime time?]]>

KDE 4.2 desktop

I’ve had a virtual machine running KDE4 from the Debian experimental repos for a while now. Every few months, when I notice some announcement of a point release I update it and give it another try. Up till now I’ve always been disappointed in some way.

I first tried it on my EeePC 701 netbook, back when 4.0 first launched. I was impressed that it ran at all on that hardware, even with desktop effects enabled, some of them at least. This is on a machine that struggles to run Windows XP, let alone Vista. While it was okay from a performance perspective, it was horribly unstable. I can live with applications crashing (as long as I don’t lose data), but parts of the desktop going boom is unacceptable. I eventually gave up on the netbook and put KDE 3.5 on it instead.

That is when I setup a VM on my main Debian laptop, at that time running Lenny, so I could keep track of KDE’s progress. I’m not one of those people who baulk at change, who objects to learning new interfaces irrespective of whether they are better or worse than what they replace. On the other hand I absolutely need my desktop to be rock-solid, any flakiness in any essential part of the OS I will not abide. On the gripping hand I want to be in control, this is why I use Linux and KDE in the first place. They allow me to configure the OS to work the way I want. I’d really like to run KDE4 on my production machines ‘cos of the shiny, but until I can be sure of its stability I won’t risk it.

KDE 4.2 just recently transitioned from Debian experimental to unstable, so I fired up the VM to give it another whirl. As I had already played with 4.2 a few weeks earlier I was expecting to have the same nearly there experience. Things mostly working but still the odd crash, but I was wrong.

KDE 4.2 Calculator plasmoid.

It’s the little things that make me want to switch though, like the calculator plasmoid that can be stuck on the panel for incredibly fast access. A dictionary right on the desktop and many other useful widgets. Previous attempts at widgets on KDE (superkaramba I’m looking at you) have been mediocre at best, glorified system monitors is the best you could hope to run. The plasmoids seem to be the real deal from the built-in examples, if the community starts writing these things we should be in for some real treats.

The application launchers are a little different, and I have to say at the moment I prefer the old “start menu” style one, the fixed height of the new designs mean I have to keep scrolling to find what I want which is icky. But I’m going to give them a while, it may be just one of those things that you have to get used to, and if it turns out I still hate them the old style is still available.

Being in a VM means I can’t use the desktop effects, so I’m missing a lot of the fun stuff. So the next step is to sacrifice my netbook again to try those out. I’m hopeful that by the time it transitions to testing (squeeze), which my main laptop now runs, I will be completely happy to switch to it, it is certainly looking positive at the moment.

What I do is seperate . . . → Read More: Home in subversion]]> I’ve mentioned previously that I’ve started putting my /home in subversion. I thought I’d go into how I handle things, as it takes a little adjustment in your thinking to get maximum benefit from this. I used this guide to get me started, and stuck pretty close to it.

What I do is seperate settings files into two groups, common and local (I don’t have any other data in home, that all lives on it’s own partition). Local settings are unique to each machine. Common settings are identical across all the machines the programs are used on. There are a few special cases that live in both worlds, like bash, but I’ll get to how I handle those later.

Each machine on my network has it’s own branch in the svn repo, and in each of those branches are two extra dirs, called “.svncommon” and “.svnlocal”. Inside these there are category dirs like “Bash”, “Devel”, “Internet” etc. that allow me to group together the settings for programs to make management easier. The .svnlocal one is not really necessary, I could just keep all the settings for the local group in the root of home instead of having them in .svnlocal and symlinks to those files in home but I like the symmetry of handling local files the same way as common ones.

Anyway, the category dirs in the common group are setup to use the svn:externals feature, so that they are actually connected to dirs in the trunk of the repo. So the files in ~/.svncommon/Devel are actually located in /trunk/Devel in the repo.

Here is the basic procedure I use to add a new machine to the shared setup (I assume the repo exists already).

1. First we need to add a branch for the new machine “svn mkdir svn://server/Repo/branches/MACHINE“
2. Then link the homedir to that branch so we can add the files “svn co svn://server/Repo/branches/MACHINE .“
3. Create the two dirs for the local and common files “svn mkdir .svnlocal .svncommon“
4. Setup the links to the common stuff”svn propedit svn:externals .svncommon”
   Bash/ svn://$REPO/trunk/Bash
GuiInternet/ svn://$REPO/trunk/GuiInternet
Internet/ svn://$REPO/trunk/Internet
Devel/ svn://$REPO/trunk/Devel
5. “svn ci .“
6. “svn up“

To add stuff to the repository you simply move it into one of the subdirs of .svnlocal or .svncommon. Then create a symlink to it in ~/ so the program can still access the file. Then “svn add” both the file and the symlink.

(the thingy at the bottom of the image) It’s achieved using the following magic incantation in my .screenrc

Oh, and each window gets automatically named after . . . → Read More: Screen hardstatus]]> GingerDog saw my screen and was curious about the status line I have. The entire screenrc I use.

(the thingy at the bottom of the image) It’s achieved using the following magic incantation in my
.screenrc

Oh, and each window gets
automatically named after the program running in it using the
following.

(Update 17/04/2006:
This appears to only work in a linux terminal, not any of the
X-terms. The X-terms seem to set the window title instead and I’m
not sure how to change this at the moment. I’m going to carry on
looking in to it though.) (Update 18/04/2006: Got it, for gui
terminals instead of “lastline” use “alwayslastline”)