Tim Hardy

I thought I was going mad the first time the Delete key stopped working in Eclipse. This evening (early morning) the Control and Alt keys stopped working.

A quick browse through the readme revealed that this is a known bug:

Key bindings stop working (GTK+ only)
When using Eclipse, most key bindings will stop working. The only way to make the keys start working again is to restart Eclipse. This problem occurs on Debian, using libgtk+2.0 (2.6.4-2 or later). The problem is that a focus issue exists in GTK+ 2.6.7 and earlier, for which SWT has a workaround. This workaround is incompatible with the fix in GTK+. SWT detects the GTK+ version on start-up and decides whether to enable the workaround. Debian backported the focus fix into their libgtk+2.0 (2.6.4-2) package. To workaround this problem, either get the Debian unstable version of GTK+, compile your own GTK+ or hack Shell.gtk_realize(int) and change the version it checks. Please see either Eclipse’s or GTK+’s bugzilla for more information.

Coming on top of a dying mouse that re-interprets single clicks as double clicks at the most inappropriate moments, I’m beginning to think that my machine hates me…

Still, while looking online to verify that I wasn’t going insane, I stumbled upon the following useful Javaworld article: Become an Eclipse Hotkey Showoff. My favourite is “Hippie Completion” - just for the name. Once I get the control keys working reliably on my keyboard again I’ll have to try it

Bootlogd does not work out of the box on Debian 3.1 with a 2.6.8 kernel. If you enable it by setting the option to yes in /etc/default/bootlogd you’ll see the error message bootlogd: ioctl (/dev/ttyzf, TIOCCONS): Bad file descriptor scroll by on boot and the log is not created.

The problem lies with the version of udev used in Debian stable.

One solution is to upgrade the udev package to one from testing or unstable but that is not acceptable to someone who wants a pure system.

The alternative is to move the order the scripts are executed in /etc/rcS.d/. Remember, execution order is determined by the number in the filename so by renaming the bootlogd launching script you can get it to run before the udev script S04udev

mv /etc/rcS.d/S05bootlogd /etc/rcS.d/S03bootlogd-was-S05

The next time you boot, the log will be enabled for reading in /var/log/boot.

(Solution by Frans Pop on the debian-laptop mailing list)

I don’t really know my way around OS X but I know enough to get frustrated at how unnecessarily difficult it is to set up access to a shared printer on a CUPS server from an iBook.

John Fry’s advice to set up your CUPS server (in my case my Debian box) to broadcast services on the local subnet is a lifesaver.

Forget about printer setup on the Mac, and just let your print server broadcast its services on the local subnet (or to specific IP addresses). Your /etc/cups/cupsd.conf file should look something like this:

ServerName foo.bar.org
MaxLogSize 0
MaxJobs 10
Browsing On
BrowseProtocols cups
BrowseAddress @LOCAL
BrowseAllow from All
Listen 631
<location />
Allow from All
AuthType None
<location /admin>
AuthType Basic
AuthClass System
</location>

Remember to restart CUPS with /etc/init.d/cupsys restart after changing the cupsd.conf file and you should have no more trouble.

When I hit my “Press it” shortcut, I’m often frustrated by how long it takes for the Wordpress Admin section to load. Okay, I’m impatient. It’s only around 4.6 seconds on average but seeing as I often post from home and the installation is on my home server, there should be zero latency. Where’s the delay?

Looking closer at the problem, I realised that the culprit was the section of Dashboard that loads in headlines (and the most recent post?) from the blogs of Wordpress developers.

The file to edit is wordpress/wp-admin/index.php and the section that controls this is the part that begins <div id="planetnews"> (line 129 on a default installation of Wordpress 1.5.2) up to and including the closing </div> (line 141).

One quick edit later deleting the entire section and Dashboard loads in 0.48 seconds. Much better. Now for every 1000 posts I make, I’ll save myself an hour… I’ll be the first to admit, it’s not a productivity hack but it does makes Wordpress feel more responsive and more pleasant to use.

On the default Debian 3.1 setup, you need to be root to shut your computer down. This makes sense on a server but is a nuisance on a desktop machine.

To enable ordinary users to shutdown without having to type the root password, you need to use sudo which allows named users to run certain commands as if they were root.

The configuration file /etc/sudoers is edited by root with the tool visudo. Since visudo uses vi as the default editor you may want to change this unless you’re comfortable with its somewhat cryptic interface.

Your default editor is controlled by the $VISUAL variable. To permanently set your default editor as root edit /root/.bashrc and add the line export VISUAL=/usr/bin/joe, replacing joe (my favourite) with your own favourite console editor: /bin/nano is installed by default on Debian and is simple to use.

Now that you’re ready to edit, run visudo. You could edit the file directly but visudo has two added benefits: it prevents more than one person trying to edit the configuration file at the same time and more importantly it provides syntax checking when you finish editing and warns you if you’ve made any mistakes.

In the section headed # User privilege specification add: tim ALL = NOPASSWD:/sbin/shutdown -[hr] now (Obviously replace “tim” with your own username!)

Now you will be able to run shutdown as an unprivileged user without having to enter a password. Remember that /sbin will not be in your $PATH so type /sbin/shutdown -h now to run it.

Once this is working, you are ready to enable shutdown in gdm. Edit /etc/gdm/gdm.conf and change the line SecureSystemMenu=true to read SecureSystemMenu=false. You will no longer need to enter the root password when you select the Shutdown or Restart options in the gdm drop down menus.

When I booted my system today, I found that mail had stopped working (by which I mean the unix command line utility “mail”).

Using verbose mode revealed that the problem was to do with name resolution.

tim@withnail:~$ echo hello | mail -v -s "Test" nobody@example.com
LOG: MAIN
< = tim@example.com U=tim P=local S=331
delivering 1EIDKX-00021e-VF
R: dnslookup for nobody@example.com
LOG: MAIN
== nobody@example.com R=dnslookup defer (-1): host lookup did not complete


I checked my /etc/resolve.conf into which I’d hand-coded the ip addresses of my ISP’s name servers and found that my entry had been replaced with the local address of my router/dhcp client.

A bit of googling later and I realised that it was the dhclient that was changing the file during the boot process. My router was supplying itself as the DNS and dhclient was doing its job and accepting this as true.

To prevent this happening, edit /etc/dhclient.conf and add the line:

supersede domain-name-servers a.b.c.d, e.f.g.h;

where a.b.c.d and e.f.g.h are the ip addresses of the DNS servers you wish to use in place of the address(es) supplied by your dhcp server. Separate multiple addresses with commas and terminate the whole sequence with a semi-colon.

man dhclient.conf for more information on syntax and options.

This has also fixed my problem with Exim4 taking 10-20 seconds to start - clearly that was a DNS issue - so I’ve disabled yesterday’s hack in case it leads to problems further down the line.

My MTA (exim4) was taking about 10-20 seconds to start, holding back the boot process so I’ve tried this simple hack: Make Debian boot faster

Edit the startup script /etc/init.d/rc.
Changing the line:

startup $i start

to the following:

startup $i start &

Launching the startup scripts in parallel rather than waiting for each to complete first before running the next could cause problems with dependencies but on a vanilla 3.1 install it hasn’t caused any trouble (so far) and the system boots noticeably faster.