## Building wine from source on 64-bit debian

If you need a particular version of wine to run a particular windows programme, you may well need to build wine from source. Most windows programmes need 32-bit wine so you can't simply build the package from source on your 64-bit installation of debian. The multi-arch feature of debian has matured a lot however there are still packages which can't have the 32-bit and 64-bit versions simultaneously installed. Because of this, you will need to build the 32-bit wine packages inside some kind of chroot environment. I am going to show you a fairly straightforward way of doing this with the help of lxc (Linux Containers).

## Outline

Install build dependencies, possibly substituting package versions if you're not running debian unstable.

Build 64-bit wine as normal.

Set up a 32-bit container, install build dependencies and build wine in it.

Find the version of wine you require at http://snapshot.debian.org/package/wine-unstable/ and download the three files that make up the make up the source package. There should be an orig.tar.bz2, a .dsg and an .xz. For example, wine-unstable_1.7.17-1.debian.tar.xz, wine-unstable_1.7.17-1.dsc and wine-unstable_1.7.17.orig.tar.bz2. For the rest of this post I shall use 1.7.17 as an example, but feel free to substitute any particular version of wine that you might prefer.

## Build dependencies

The version of wine in debian stable at the time of writing is 1.4 and the build dependencies have changed somewhat between that package and recent versions of wine-unstable. If you do "apt-get build-dep wine" it will install a lot of the build dependencies of wine-unstable but it won't get all of them, so you will have to install some manually. (If you are running debian unstable then you can probably just do apt-get build-dep wine-unstable and get all of them directly, but if you're running debian unstable I would question why you need help from this article!)

To find out the packages that are required to build wine-unstable, you can unpack the archive and look for the Build-Depends line in debian/control, or you can just attempt to build the package and wait for any error message!

$dpkg-source -x wine-unstable_1.7.17-1.dsc$ cd wine-unstable-1.7.17
$dpkg-buildpackage dpkg-buildpackage: source package wine-unstable dpkg-buildpackage: source version 1.7.17-1 dpkg-buildpackage: source changed by Michael Gilbert <mgilbert@debian.org> dpkg-buildpackage: host architecture amd64 dpkg-source --before-build wine-unstable-1.7.17 dpkg-checkbuilddeps: Unmet build dependencies: libgphoto2-dev libfreetype6-dev (>= 2.5.1) libgstreamer-plugins-base1.0-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) The build dependencies may vary from version to version of wine so I can't give you exact instructions here. In this case, none of the three packages exist in the version of debian that I have installed. I substituted libgphoto2-2-dev, an earlier version (2.4.9) of libfreetype6-dev, and libgstreamer-plugins-base0.10-dev. Close enough. Remember the packages you install here as you will also be installing them to build the 32-bit version of wine. You can now build the 64-bit version of the package with the -d option to ignore the build dependency problem: dpkg-buildpackage -d ## Building 32-bit wine Unfortunately, having the 64-bit wine packages aren't enough as most windows programmes are compiled against 32-bit windows, so you will need to build the 32-bit packages. You can set up a chroot environment by hand with debootstrap and do this, or you can use lxc to set up a container for you. Containers are somewhere between a chroot and a virtual machine. The advantage of using lxc is that it takes exactly one command to set it up: sudo lxc-create -n32bitwine -t debian -- --arch i386 This will set up a basic 32-bit debian environment in /var/lib/lxc/32bitwine/rootfs. Copy the 3 wine source packages to the location within this environment that you will build them - for example the /root folder. Then enter the container: sudo lxc-start -n32bitwine You will see a basic debian system booting, and you will be able to login as root with the password that was displayed at the end of the lxc-create command output. Set up your 32-bit build environment by addding a deb-src line to /etc/apt/sources.list and running apt-get update. You may need to run "dpkg-reconfigure locale" if you see a lot of errors about LC_ALL like this: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_GB:en", LC_ALL = (unset), LC_TIME = "en_GB.utf8", LANG = "en_GB.utf8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). You will need to set up your 32-bit build dependencies as before. So I would recommend running "apt-get build-dep wine" to get most of the dependencies installed, then install 32-bit versions of the same packages that you had to install to get 64-bit wine built. Then extract the source archives (that you previously copied into the container) and build the package: $ dpkg-source -x wine-unstable_1.7.17-1.dsc
$cd wine-unstable-1.7.17$ dpkg-buildpackage -n

If all has gone well, you can shut down the container with "sudo lxc-stop -n32bitwine" then copy the 32-bit packages out of your container filesystem. The 32-bit packages you need to install are wine32-unstable and libwine-unstable, while the 64-bit packages you need are wine-unstable, wine64-unstable and libwine-unstable.

Install those packages along with the 64-bit wine packages manually and you are good to go!

sudo dpkg -i libwine-unstable_1.7.17-1_amd64.deb libwine-unstable_1.7.17-1_i386.deb wine32-unstable_1.7.17-1_i386.deb wine64-unstable_1.7.17-1_amd64.deb wine-unstable_1.7.17-1_amd64.deb

# Or, Gigabyte BIOS considered harmful

After changing the motherboard, a computer became unbootable because the Gigabyte BIOS created a Host Protected Area (HPA) using sectors already allocated to a disc partition, corrupting the partition table and overwriting data.

What Gigabyte are trying to do is store a copy of the BIOS onto disc in order to secure the computer against viruses. The process is explained over here in the section titled "GIGABYTE Xpress BIOS Rescue™ Technology" (and is referred to in the specification of the motherboard as "Virtual Dual BIOS"). At boot time, a copy of the BIOS is stored into an unused section of the disc by creating a Host Protected Area. If a virus corrupts the BIOS then it can apparently detect this and restore the safe copy of the BIOS from the disc. Magical!

This process goes badly wrong when you have discs larger than 2TB. The traditional partition table format, which dates back to the early 80s, runs into a limit when discs reach 2TB. A new partition table format was created called GUID Partition Table (GPT) which handles much larger discs.

If you have certain Gigabyte motherboards with the Virtual Dual BIOS feature, then as the computer boots it will try and create an HPA on the first hard disc, and save the current BIOS there. One assumes that if the partition table indicates that the disc is already full, then the BIOS will avoid creating this HPA. What seems to be happening with large hard discs with GPT, is that the BIOS doesn't understand the partition table, doesn't realise that the all space on the disc is entirely accounted for already, then grabs some of the space from the end of the disc and overwrites it with a copy of the BIOS.

Once the HPA has been created, the size of the disc that is reported to the OS changes. This means that the values stored in the GPT structures don't match those reported by the disc so may make it impossible to boot from the disc - which is what happened to me.

## How do I tell if I have this problem?

You are likely to see this problem if you have a disc larger than 2TB that you partitioned with a GPT on a different motherboard then attached to the Gigabyte motherboard as the first hard disc.

For me, I had a 1.5 TB disc with a /boot partition and 2 3TB discs in raid-1 via Linux software raid (mdadm). I had partitioned these discs on a different motherboard and the computer would boot without problems, however when I switched to the Gigabyte motherboard it would no longer boot. Specifically, I would receive a grub error like this:

error: disk 'mduuid/3c620ba3b6ebc2ba2dec4bdc61f7191b' not found.
Entering rescue mode...
grub rescue>

When I booted from a usb stick and attempted to mount the raid partition it was only able to load one of the discs:

ubuntu@ubuntu:~$sudo mdadm --assemble /dev/md0 mdadm: /dev/md0 has been started with 1 drive (out of 2). ubuntu@ubuntu:~$


I then ran gdisk to inspect each of the two discs forming the raid array, gdisk printed various errors about the disc that the BIOS had interfered with:

ubuntu@ubuntu:~$sudo gdisk /dev/sdb GPT fdisk (gdisk) version 0.8.8 Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Warning! One or more CRCs don't match. You should repair the disk! Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged **************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** Command (? for help):  If one performs the recommended verification step, 5 errors are detected: Command (? for help): v Caution: The CRC for the backup partition table is invalid. This table may be corrupt. This program will automatically create a new backup partition table when you save your partitions. Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations. Problem: Disk is too small to hold all the data! (Disk size is 5860531055 sectors, needs to be 5860533168 sectors.) The 'e' option on the experts' menu may fix this problem. Problem: GPT claims the disk is larger than it is! (Claimed last usable sector is 5860533134, but backup header is at 5860533167 and disk size is 5860531055 sectors. The 'e' option on the experts' menu will probably fix this problem Problem: partition 2 is too big for the disk. Identified 5 problems! Command (? for help):  In fact there is only 1 error, which is that part of the disc has been co-opted by the BIOS. This can be seen with hdparm (contrast sdb which has been corrupted with sdd which is in its original state): ubuntu@ubuntu:~$ sudo hdparm -N /dev/sdb

/dev/sdb:
max sectors   = 5860531055/5860533168, HPA is enabled
ubuntu@ubuntu:~$sudo hdparm -N /dev/sdd /dev/sdd: max sectors = 5860533168/5860533168, HPA is disabled ubuntu@ubuntu:~$


## How do I fix the problem?

You must either live with the HPA, or remove it and ensure you never again boot with a the GPT disc as primary. Even if you decide to live with the HPA you will need to temporarily remove it so that you can backup your data or resize the partition and filesystem.

So regardless of what you choose to deal with this problem, you will need to disable the HPA and make the entire disc available. This can be done with hdparm, by setting the visible sectors to the full amount with the parameter "-N p<full amount of sectors>" as below:

ubuntu@ubuntu:~$sudo hdparm -N /dev/sdb /dev/sdb: max sectors = 5860531055/5860533168, HPA is enabled ubuntu@ubuntu:~$ sudo hdparm -N p5860533168 /dev/sdb

/dev/sdb:
setting max visible sectors to 5860533168 (permanent)
max sectors   = 5860533168/5860533168, HPA is disabled
ubuntu@ubuntu:~$ Now that this has been done, the GPT partition table will correspond to the number of sectors reported by the disc (although some data has been unavoidably lost when the BIOS overwrote the end of the disc). However if you reboot and this disc is still the primary disc then the BIOS will just create the HPA again! Posted in Linux | Leave a comment ## Monitoring several log files in one terminal window using screen When debugging website problems I often run tail on /var/log/apache2/error.log or on /var/log/apache2/access.log. Today I needed to monitor both at the same time. One solution is to open two terminal windows, however this uses up valuable entries in the alt-tab list. A better solution for this purpose was to create two windows with the screen utility. There are 3 key commands to use: • "Ctrl-a |" which splits the screen into two windows • "Ctrl-a <tab>" which sends focus to the next window • "Ctrl-a c" which opens a new shell in the current window So after running screen, I ran tail -f /var/log/apache2/error.log I then pressed "Ctrl-a" followed by "|" (after releasing the control key) to split the window, "Ctrl-a" followed by tab to switch focus into the window I just created, "Ctrl-a" followed by "c" to start a new shell, and finally: tail -f /var/log/apache2/access.log Posted in Linux | Leave a comment ## Steam Hardware Survey: All Linux distributions increase in popularity Valve's Hardware Survey for July 2013 shows an increase in usage for every recorded Linux distribution, with each distribution seeing increases between 7-22%. As every single distribution seems to be increasing in popularity, I interpret this to mean that as time goes on more people are trying gaming on Linux and they are staying with Linux. Distribution Proportion of users Increase as proportion of total users Relative increase Ubuntu 13.04 64 bit 0.43% +0.03% +7% Ubuntu 12.04.2 LTS 64 bit 0.20% +0.02% +10% Ubuntu 13.04 0.13% +0.01% +8% Ubuntu 12.04.2 LTS 0.11% +0.01% +9% Linux 64 bit 0.10% +0.01% +10% Linux Mint 15 Olivia 64 bit 0.09% +0.02% +22% Total 1.06% +0.10% +9% Note that due to the precision of data that is provided there are likely to be rounding issues, so the relative result in the right hand column could be +/- a few percent. Posted in Linux | 1 Comment ## dkms.conf: Error! No 'BUILT_MODULE_NAME' directive specified for record #0. I recently had an error crop up with an installation of Linux Mint Debian Edition. When upgrading a kernel, or adding/removing certain software packages, or typing "dkms autoinstall" the following error appeared: dkms.conf: Error! No 'BUILT_MODULE_NAME' directive specified for record #0. Error! Bad conf file. File: does not represent a valid dkms.conf file. The error message seemed to be complaining about a file called dkms.conf. Searching for files with that name led me to a file which clearly didn't have a BUILT_MODULE_NAME directive: /var/lib/dkms/ndiswrapper/1.57/build/dkms.conf $ cat /var/lib/dkms/ndiswrapper/1.57/build/dkms.conf
PACKAGE_NAME="ndiswrapper"
PACKAGE_VERSION="1.57"
AUTOINSTALL="yes"

This file came from the package ndiswrapper-dkms, so purging the package cleared out the problem and allowed modules to be built once again.
 dpkg --purge ndiswrapper-dkms 

## Dealing with website forms that disable pasting

Occasionally I run across a website that thinks its a good idea to arbitrarily restrict fundamental functions of my browser. Recently I signed a petition which asked for my email address twice. Obviously I'm not going to type it twice, I'm going to type it once, copy it, then paste it into the second box. Except nothing happens. Have I hit the wrong key? Try again. Nope still doesn't work. Frustration mounts.

I took a look at the code to see how they did it by right-clicking in the offending text box and selecting "inspect element".
It's easy to see that they have implemented this anti-feature with the piece of code that says:
onpaste="return false"

One of the great features about the Chrome/Chromium browser is that you can directly edit the page via Inspect Element and instantly see the results. So after double-clicking on the onpaste element, and deleting it - I was able to paste my email address into the form!

Posted in Uncategorized | 3 Comments

## Improving the fonts in Linux Mint Debian Edition with Infinality

It turns out that the fonts in LMDE look a bit different to those in say Ubuntu. This is partly because of Ubuntu's theme, and partly because Debian's font rendering is a little dated. There is a guy over at http://www.infinality.net/blog/ who has made some patches to the font renderer (freetype and fontconfig) which haven't yet been picked up by Debian. I installed these patches and it made quite a difference to some text in Firefox.

Notice how the text in the upper half has the C and u in "Currently" touching, and each letter is quite skinny. While in the lower half of the image which I took after installing infinalty, the letters are better spaced, and a bit denser.

This is how I did it:

sudo apt-get install devscripts quilt cd /tmp wget https://github.com/chenxiaolong/Debian-Packages/archive/master.zip unzip master.zip cd Debian-Packages-master cd fontconfig-infinality ./build.sh cd ../freetype-infinality ./build.sh cd .. sudo dpkg -i *.deb

## Copying Thunderbird settings from Windows to Linux (or vice versa)

One of the benefits of cross-platform software such as the Thunderbird mail client is that its often quite easy to transfer data from one platform to another. The data that Thunderbird creates (that contains your account settings, downloaded emails, mail filters etc.) seems to be identical whichever platform you run it on.

Under Linux, the data files live in "~/.thunderbird/". Under Windows 7, I found my settings in "C:\Users\<username>\AppData\Roaming\Thunderbird\". I suspect this location might move around a bit from one version of Windows to another. Searching for profiles.ini might be the best bet if you're trying to locate an existing installation.

So, once I had located the data files, all I had to do was mount the windows partition under Linux, and copy "profiles.ini" and the "Profiles" directory from the Windows location to "~/.thunderbird/".

You could also use this method to transfer your Thunderbird settings from one computer to another.

Posted in Linux | 1 Comment

## Installing Steam on 64-bit Linux Mint Debian Edition

One of my motivations for installing Linux Mint Debian Edition was to see for myself the efforts Valve have been making over the last few months, porting most of their games and their Steam platform to Linux.

It turns out that LMDE was not the best choice for this as the version of Linux that Valve primarily supports is Ubuntu, and there are a few differences between Debian and Ubuntu distributions - even though Ubuntu is more or less based on Debian.

One of the consequences is that the version of Steam distributed by Valve doesn't actually install on LMDE. Fortunately nearly all of the work to resolve this has been done already over here http://www.sarplot.org/howto/45/Steam_on_64bit_Debian_Wheezy_70. If you don't have an ATI graphics card those instructions might be all you need. If you do have an ATI card (like me) then when you try to launch steam, you may see the following error:

Error: You are missing the following 32-bit libraries, and Steam may not run: libGL.so.1

One final step is needed, to have steam launching correctly:

sudo apt-get install libgl1-fglrx-glx:i386

Posted in Linux | 7 Comments

## Removing Linux Mint Debian Edition's Chromium search page

When you install Chromium in the latest version of Linux Mint Debian Edition (LMDE), typing anything in the search/address bar takes you to an awful custom search engine that wastes loads of space and hurts my eyes.

So, how do we get rid of it? We go to the chromium settings via the triple line menu, then we choose Manage Search Engines, and observe that there are two "google" search engines. One has a url similar to google.com/cse (for custom search engine) and is marked as the default. All we do is set one of the other search engines as default, then click the X to delete Mint's one.

## Installing Linux Mint Debian Edition via a USB stick

I installed 64-bit Mint Debian Edition today (LMDE) but I had a problem getting the image onto the USB stick. I used LinuxLive (LiLi) Usb Creator version 2.8.22 released June 1st 2013, however the default settings resulted in a usb stick that wouldn't boot properly.

The symptom was a kernel panic due to the init process being terminated. It wasn't very easy to see what the cause was, as after the panic the kernel changed the graphics mode back to a text mode which got rid of the error messages. It turned out that after mounting the initrd, it had a problem finding /boot/casper.

This problem occurred because LiLi didn't recognise the iso file, and guessed that it should use its settings for 64-bit Linux Mint Olivia. The fix was to manually select the settings for the most recent version of 64-bit Mint Debian Edition that LiLi knew about.

I was then able to boot into live mode and install to disc from there. I was slightly surprised that there was no direct install link from the boot menu but you can't have everything!

Posted in Linux | 2 Comments

## Compiling Octave from source on Linux Mint Nadia (Ubuntu 12.10)

I recently needed to build GNU Octave from source, as the version available in the Ubuntu repositories (3.6.2) had a crash that reliably triggered when I attempted to run a matlab script from a lecture I had been watching (a Stanford lecture series called The Fourier Transforms and its Applications).

error: source: error sourcing file /home/frankster/Reference/TheFourierTransform/materials/lsoftaee261/sinesum2.m' *** glibc detected *** octave: corrupted double-linked list: 0x00000000020d6380 ***

I pulled the mercurial repository containing the source, and followed the build instructions in etc/HACKING which said to run the ./bootstrap script. Unfortunately, when I ran this script I got the error:

~/octave$./bootstrap ./bootstrap: one of these is required: glibtoolize libtoolize  It wasn't immediately clear to me what this error meant, and I couldn't find any answers with a quick search. After a little bit of trial and error, I realised that there might be some build pre-requisites that were not installed. Fortunately on debian-based distributions its incredibly easy to sort this out (for packaged software at least): sudo apt-get build-dep octave Development versions of octave have a new QT interface. In order to get this to compile I also installed some qt packages: sudo apt-get install libqt4-core libqt4-gui libqt4-network libqt4-dev Posted in Linux | Leave a comment ## grub-probe: error: not a directory. (grub 1.99 in Ubuntu Linux 12.04) I upgraded some packages earlier (including a kernel) and received an odd error from grub (version 1.99-21ubuntu3.9) $ sudo grub-install --recheck /dev/sda
/usr/sbin/grub-probe: error: not a directory.
Auto-detection of a filesystem of /dev/sdb1 failed.
Try with --recheck.
If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>

I couldn't complete the configuration of the updates that I had downloaded, and worse the machine was probably now unbootable. Poking around a bit, I find that the error reported by grub-probe could be reproduced with:

\$ sudo grub-probe -d /dev/sdb1 --target=fs_uuid
grub-probe: error: not a directory.

I didn't know where to go from here so the first thing I tried was to purge grub and reinstall it.

sudo apt-get purge grub*

sudo apt-get install grub-pc

Didn't make any difference, so the next thing I tried was to downgrade to an earlier version of grub (1.99-21ubuntu3).

sudo apt-get purge grub*

sudo apt-get install grub-pc=1.99-21ubuntu3 grub2-common=1.99-21ubuntu3 grub-pc-bin=1.99-21ubuntu3 grub-common=1.99-21ubuntu3

Unfortunately this made no difference either. So the next thing I tried was to install the version of grub from Ubuntu 12.10. There were some dependency conflicts which I had to manually fix as you can see here:

sudo apt-get remove apport-hooks-medibuntu apport-gtk apport

sudo dpkg -i liblzma5_5.1.1alpha+20120614-1_amd64.deb grub2-common_2.00-7ubuntu11_amd64.deb  grub-common_2.00-7ubuntu11_amd64.deb  grub-gfxpayload-lists_0.6_amd64.deb  grub-pc_2.00-7ubuntu11_amd64.deb  grub-pc-bin_2.00-7ubuntu11_amd64.deb

Finally, grub installed ok! Crisis averted.

## Strip audio from a video in Ubuntu Linux

Lets say you have a video you recorded on your mobile phone, and you want to send it to someone but there is a noisy audio track which is irrelevant to the subject. Stripping out the audio track is fairly simple using the libav-tools package.

sudo apt-get install libav-tools

avconv -i INPUT.3gp -an -c:v copy OUTPUT.3gp`

"-i INPUT.3gp" specifies the input file

"-an" specifies that there will be no audio track in the output file (or -vn would have no video track). Note that if "-an" appeared before "-i INPUT.3gp" we would copy no audio track from the input file (but there would still be an audio track in the output file, albeit empty possibly).

"-c:v copy" specifies the codec we use to encode the video track in the output file. Here we specify copy which means we don't transcode it. So rather than rendering the input video track to a buffer, then re-encoding it we are just copying it directly from the input file to the output file which means we don't lose any quality (whereas if we re-encoded it with a lossy codec then we would have a lower quality output file). Note that if we specified "-c:v <CODEC>" before the "-i INPUT.3gp" we would be specifying the codec used to decode the input file, rather than encode the output file.

"OUTPUT.3gp" specifies the output file. Obviously.

## How NOT to calculate daily compound interest rate

I wanted to work out how much interest I would gain by leaving some money in a certain account for a few days. I knew I could derive this myself using logarithms but I was too lazy, so I searched google and clicked on the top result which turned out to be completely incorrect.

The author David Ingram recommends calculating a weekly interest rate from an annual interest rate by dividing by 12 months then 4 weeks per month which is just plain stupid, as the correct answer might be to divide by 365 (or 366!) days, then multiply by 7 days per week.

David Ingram fails to consider this distinction again and compounds his error when he suggests calculating your daily interest rate simply by dividing the incorrect weekly rate by 7. His method of calculation causes an error of 8% which is pretty significant!

This is of course assuming that we are talking about simple rather than compound interest, although the author makes no mention of this distinction. Certainly in the UK its rare to see simple interest used in financial products.

So if we're actually interested in the compound daily interest rate that is equivalent to a particular annual interest rate, this is what we need:

$Daily Interest Rate = e^ {log (Annual Interest Rate) / 365}$

Posted in Uncategorized | 2 Comments