How-To: Install the latest version of Wine in LMDE

Wine Logo transparent backgroundFeb 2013 Update: More recent versions of Wine are now available in the standard LMDE repositories, so skip all the headache below and just install Wine with a s swift sudo apt-get install wine and you’re done!

The Wine “not-emulator” allows you to run Windows software under Linux, but the version in the Debian testing repos (themselves cutting edge) is pretty old, at time of writing it’s a 1.3.6 variant, while Wine 1.5.0+ is now available. Unfortunately, upgrading can be a bit of a pig if you want to build Wine yourself, so a far better solution is to find some Debian binaries and install them. So let’s do that…

Getting the Debian binaries

Wine binaries are available for a whole heap of different platforms, distros and architectures from, but in this case I’m installing on Debian, so if you are too, head on over to and grab the following packages (either 32 or 64 bit, depending on your architecture – I’m using 64-bit LMDE so I’ll use the 64-bit package names for this quick guide):

  • libwine-alsa-unstable_1.5.0-0.2_amd64.deb
  • libwine-bin-unstable_1.5.0-0.2_amd64.deb
  • libwine-capi-unstable_1.5.0-0.2_amd64.deb
  • libwine-cms-unstable_1.5.0-0.2_amd64.deb
  • libwine-dbg-unstable_1.5.0-0.2_amd64.deb
  • libwine-dev-unstable_1.5.0-0.2_amd64.deb
  • libwine-gl-unstable_1.5.0-0.2_amd64.deb
  • libwine-gphoto2-unstable_1.5.0-0.2_amd64.deb
  • libwine-ldap-unstable_1.5.0-0.2_amd64.deb
  • libwine-openal-unstable_1.5.0-0.2_amd64.deb
  • libwine-oss-unstable_1.5.0-0.2_amd64.deb
  • libwine-print-unstable_1.5.0-0.2_amd64.deb
  • libwine-sane-unstable_1.5.0-0.2_amd64.deb
  • libwine-unstable_1.5.0-0.2_amd64.deb
  • wine-bin-unstable_1.5.0-0.2_amd64.deb
  • wine-unstable_1.5.0-0.2_amd64.deb

Satisfying Dependencies

jp helpfully provided details that for the above packages to install without issue, you’ll first need to install the packages:

  • libc6-i386
  • lib32asound2
  • libc6-dev-i386

So do that via your mechanism of choice, for example, if you use apt-get then you can install them though a simple:

Replacing Wine

Before you can install any new Wine stuff, you’ll first have to uninstall the wine package. Do that through whatever means you feel most comfortable with, ya know, synaptic, apt, dpkg etc.

Once that’s done, you’ll want to install all the libwine packages through dpkg (to be honest, you might not need them all – but it doesn’t hurt, and you’ll certainly need most of them).

To install all the libs, open up the location you saved all the .deb files to in the console, and run:

Once that’s completed successfully, in the same location run:

And finally, in the same location again, run:

Almost done!

Getting the gecko engine

At this point we’re 99% complete, we just need to launch winecfg and let it install the Gecko engine for web-browser shenanigans (again, you might not need this – but there’s no harm in it, and Wine’ll moan at you about it if you don’t). So just run:

And when it prompts you about gecko, just click on [Install].


New cutting-edge Wine goodness is now yours to play with, although from this point on you won’t get automatically updated as wine won’t be installed from any repository. For this reason, it’s worth holding onto all the debs so you can uninstall them with ease via a swift sudo dpkg -P *.deb (-P for purge) if at a later date you want to go back to the repo version.

As Bryant would say – Drink some for me, eh, pal? ;)

How-To: Fix LMDE Repo Hell

LMDE is a great distro, but the repo situation is a bit of a mess, what with all the update packs and tracking testing or sid or romeo or wheezy or… yeah, it gets confusing. As I wanted to build openFrameworks the other day and it was moaning about libavcodec and libavcodec-dev mismatches I did a bit of searching around and found this thread over on the mint forums, and making the following changes fixed up the repo issues in no time:

Change your main repos (in /etc/apt/sources.list) to:

If you wanted to then make sure the Mint repos take precedence over the Debian ones, put something like the following in /etc/apt/preferences:

Once you perform an update to get the new package listings and upgrade, all package mismatches should be fixed and you can actually build stuff! Woo! =D

Update May 2012: Getting a large number of packages to be removed when you contemplate updating/upgrading? Pin all repos to 500 (i.e. level the playing field) to fix! Source: Thanks, ZeroZero!

How-To: Install the Liquorix kernel in LMDE

Just because all GNU/Linux distros come with a kernel, it doesn’t mean that it’s the best kernel to use. This was made quite clear to me recently when I discovered that whenever I safely removed a USB drive from my machine it caused a kernel panic in the present LMDE kernel ( which promptly hung the machine. I figured out I could work around the issue by unmounting USB drives through gparted, but that’s pretty weak sauce, so I decided to cut to the root of the problem and change kernels.

In the past I’ve spent a long time picking specific kernel options, building the kernel, and then it hasn’t worked at all – so this time I wanted something I was pretty sure would work, and I didn’t want to spend forever on it, so what are the options?

Zen and the art of kernel maintenance

The official Linux kernel lives at, and is the reference design if you will for all existing kernels. The new stuff generally gets added to the mainline kernel, and then other kernels add or remove bits and pieces to become their own kernels such as the Ubuntu kernels or the Debian kernels or what have you.

The process of adding or removing bits and pieces is pretty much open ended, and if you don’t know exactly what you’re doing you can spend a long time reading and experimenting, so I’ve opted to pick something pre-customised from the Zen kernels:

From the zen kernel about page:

The Zen Kernel is a the result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for every day systems. We include code that is not included in the mainline kernel in an attempt to create an all-around better kernel for desktops (although it can be compiled otherwise). This is done by including new features, supporting latest hardware, and including various code and optimizations to better suit desktops. Zen is a 100% community oriented project so, as a result, everybody can contribute to the project.

Who mods the modders?

Liquor up front, poker in the rearA chap going by the handle of Damentz, who seems to have the black art of kernel crafting down to a tittle, takes that zen-kernel source and (I think) tweaks it some more to produce the Liquorix kernel.

What does he do exactly? I’ve absolutely no idea – maybe it’s in the forums somewhere, but I think the main thing he does is make it compatible with Debian, and provide a repository so we can grab and use his pre-built pre-modded zen kernel on Debian or any Debian-compatible distro such as LMDE. He’s also nice enough to build both 32-bit and 64-bit kernels so the repo should provide whichever version is appropriate for your system at install time.

Installing the liquorix kernel

Note: It’s a really good idea to make sure you have the dkms package is installed at this point so that any proprietary third-party kernel modules like graphics card drivers (nvidia/ati official drivers), virtualbox modules etc. get rebuilt as part of the kernel install.

1.) Add the liquorix repository to your apt sources file at /etc/apt/sources.list:

2.) Update your system package list:

3.) Get and install the liquorix repository key to authenticate the packages:

4.) Install the liquorix kernel and header sources (you’ll want the sources so that DKMS can automatically rebuild kernel modules for you as required when you update the kernel) – it’s probably best to do this through synaptic/package manager so you can see what’s there:

Liquorix packages

Apart from the keys for package authentication, you really just need the linux-image-liquorix-amd64 and linux-headers-liquorix-amd64 meta-packages (or suitable 32-bit versions) which will then drag in the most recent version of the kernel, whatever that happens to be at the time.

While the packages are installing it’s best to keep an eye on the output to ensure that your dkms modules successfully rebuild – but as long as you’ve opted to install the kernel headers package along with the kernel there shouldn’t be a problem – it’s just nice to be confident that when you reboot you’re not going to be booting into a black screen with a flashing white cursor…

Liquorix DKMS module rebuild successful
Liquorix DKMS module rebuild successful

What now?

Reboot and choose your new kernel from the grub boot menu! (it’ll be the new default). Once you’re up and running you can always run uname -r or uname -a to confirm your kernel version, then take that bad-boy for a spin…

Liquorix uname -r

I only installed mine this morning, but the first thing I did was mount and then unmount a USB drives – and what happened? It kernel panicked. Turns out that the bug seems to be quite widespread among distros (Debian Bug 631187), but you can work around it by manually unmounting using umount (or by using gparted, as I found).

Still, it’s a new, multimedia/gaming optimised kernel (3 series, no less!) – which has its faults, but it seems a lot of kernels at the moment do, and it looks like I’d have to go back to 2.6.38.something to find a kernel which hasn’t had this bug introduced.

I’ve read good things about zen kernels in the past, so I’m glad to finally run one. Once I’ve had a chance to play around with it and that unmount wrinkle’s ironed out I’m sure it’ll be a nice, responsive kernel. And if it isn’t, then I’ll write another post that calls it names =P


Update 21/09/2011: I’ve read on the Liquorix forums that DKMS is not a great package, and although it might do useful things, it does them in bad, non-standard ways, so they highly recommend you uninstall DKMS entirely, and install things like graphics drivers and wifi drivers from the manufacturer’s sites directly (using sgfxi) because if DKMS screws it up, it can get pretty scrappy to fix.

How to: Build GLEW on Debian

GLEW - The GL Extension WranglerI’ve just jumped ship from Ubuntu to Linux Mint Debian Edition (20011-08 RC1, 64-bit Gnome version) because as much as I tried, I just couldn’t get along with Xfce and Thunar, and I’ve had it up to my eyeballs with the Ubuntu desktop experience *@&%ers making decisions for me.

So now I need to be able to build the latest version of a few packages. Again. In this case, it’s GLEW 1.7.0 – but thankfully this one’s pretty do-able:

1.) Install some GLEW build pre-req’s with:

2.) Get the GLEW source and extract it.

3.) If you want to install in /usr/local/ instead of /usr/ (which is generally a good idea for packages you’ve built yourself so you can easily distinguish them from “system packages”) then edit the Makefile in your extracted glew folder and make the following change:

Should be modified to read:

4.) On Debian it appears that /usr/local/lib64 doesn’t already exist as a symlink to /usr/local/lib (which means that you could end up with some of your stuff in the local/lib folder and some in the local/lib64 folder – which would be rubbish), so create the symlink yourself first with:

5.) Run make then sudo make install

6.) Finally, once you have your GLEW stuff installed, don’t forget to link in to your OpenGL projects, which if you’re making the switch from Ubuntu to Debian like I am, have now moved from /usr/lib/ to /usr/lib/x86_64-linux-gnu/, at least on my 64-bit setup.

Fun, eh? Sheesh!