Shallow Thoughts

Akkana's Musings on Open Source, Science, and Nature.

Wed, 16 Jul 2008

Running a second X: Xnest, Xephyr and xinit

I had a silly problem: I needed to make some screenshots, but my window borders were too pretty.

The problem isn't actually that they're pretty; it's that the theme I wrote for openbox is very different from the much simpler theme I used to use in fvwm, and I needed new screenshots that matched the old fvwm look. Preferably without actually going back to using fvwm -- I'm quite happy with openbox these days.

Anyway, the obvious solution is to run a second X. I had done that in the past (when I needed to test something repeatedly, like a wacom tablet, and didn't want to be restarting X all the time) so I knew that was possible. But then someone told me about Xnest. It's a way to run an X server embedded in a window of the current X session. What a neat idea! I wanted to try it.

I made a simple .xinitrc.xnest file that starts fvwm after loading .Xdefaults. It took some fiddling to find a combination of arguments that worked. In the end, this was it:
xinit ~/.xinitrc.xnest -- /usr/bin/Xnest -ac :1 -geometry 1024x768
And indeed, a 1024x768 window popped up with an fvwm running inside it. Cool! Except it turned out to be not so cool -- because as soon as I switched desktops, I found that the Xnest window wouldn't repaint itself. Not even after being covered with another window then uncovered -- it just didn't seem to get any expose events. Bummer!

Next I tried Xephyr -- I heard that it was similar to Xnest, a little more heavyweight but a little more reliable. It turned out the arguments were just the same, so I ran it exactly like Xnest:
xinit ~/.xinitrc.xnest -- /usr/bin/Xephyr -ac :1 -geometry 1024x768
but Xephyr was even worse about window redrawing, plus it had some problems with the mouse pointer, which kept jumping to random places.

Too bad! They both sounded fun, and I'm sure they'll improve and will eventually become usable. But for now, I'm back to the simpler solution, running a second X server. Here's how that works: first I have to log in on console 2 (ctl-alt-F2). For some reason, I can't run a second X except from there. Then I run:
startx ~/.xinitrc.xnest -- :1 and I get a new X session, on ctl-alt-F8 (with my regular session still accessible on ctl-alt-F7).

Tags: ,
[ 20:01 Jul 16, 2008    More linux | permalink to this entry ]

Sun, 22 Jun 2008

Custom ringtones on a Motorola phone, from Linux

I decided to stick a tentative toe into the current millennium and get myself a cellphone.

I sense your shock and amazement -- from people who know me, that I would do such a thing, and from everybody else at the concept that there's anybody in 2008 who didn't already have one.

I really don't think cellphones are evil, honest! (Except in the hands of someone driving a car -- wouldja please just put the phone down and pay attention to the friggin' road?) The truth is that I just don't much like talking on the phone, and generally manage fine with email. The land-line phone works fine for the scant time I spend on the phone, and I have to have the land line anyway (as part of the DSL package) so why pay another monthly bill for a second phone?

Prepaid plans looked like just the ticket, and that's what I got. With a cute little Motorola V195s. New toy! Rock! It can take custom MP3 ringtones and Java games ... but of course I don't want theirs, I want to make my own. So I wanted to talk to the phone from Linux.

The charger plug was a familiar shape -- looked a lot like a standard mini USB connector. Could the hardware be that easy? Sure enough, it's a standard mini USB. Kudos to Motorola for making that so easy! Now what about software?

My initial web searches led me down a false trail paved with programs like wammu and gnokii. I learned that I needed to enable ACM in my kernel (that's the modem protocol most cellphones use over USB), so as long as I was building a new kernel anyway, I grabbed the latest tarball from kernel.org (2.6.25.7). With that done, I was able to talk to the phone with gnokii, but the heavily Nokia-oriented program didn't show me much that looked useful.

Moto4lin is the answer

I set the project aside for a while. But half a week later while looking for something else, I stumbled across moto4lin, which turned out to be exactly what I needed. I had to run as root, or else when I try to connect, it prints on stderr:

sendControl Error:[error sending control message: Operation not permitted]
) but I'm sure that can be solved somehow.

So run as root, click Connect, click File Manager if you're not already in that mode, then click Update List and it reads the files. Once they're there, you can click around in the folder list on the left looking for the audio files (on my phone, they're in a directory called audio somewhere under C, not A). Excellent!

Creating a ringtone leads to a kernel debugging digression

Okay, now I needed a ringtone. I wanted to use a bit of birdsong, so I loaded one of the tracks I use for tweet into Audacity and fiddled semi-randomly until I figured out how to cut and save a short clip. It would only save as WAV, but lame clip.wav clip.mp3 solved that just fine.

(Update: the easiest way is to select the clip you want, then do File->Export Selection...)

Except ... somewhere along the way, the clips stopped playing. I couldn't even play the original ogg track from tweet. It *looked* like it was playing ... it found the track, printed information about it, showed a running time-counter for the appropriate amount of time ... but made no sound.

It eventually turned out that the problem was that shiny new 2.6.25.7 kernel I'd downloaded. A bug introduced in 2.6.24 to the ymfpci sound card driver makes Yamaha sound cards unable to play anything with a bitrate of 44100 (which happens to be the typical CD bitrate). After a lot of debugging I eventually filed bug 10963 with a patch that reverts the old, working code from 2.6.23.17.

Ringtone success

Okay, a typical open source digression. But while I was still trying to track down the kernel bug, I meanwhile found this Razr page that tipped me off that I might need a different bitrate for ringtones anyway. So I converted it with:

lame -b 40 mock.wav mock.mp3
(which also made it playable on the new kernel.) I also found some useful information in the lengthy Ubuntu forums discussion of moto4lin.

In the end, I was able to transfer the file easily to the motorola phone, and to use it as my nifty new ringtone. Success! Too bad nobody ever calls me and this phone is mostly for outgoing calls ...

Now to look for some fun Java apps.

Tags: , ,
[ 19:27 Jun 22, 2008    More linux | permalink to this entry ]

Sat, 31 May 2008

How to fix usbview and /proc/bus/usb in Ubuntu Hardy

Ah, I so love progress. I was working with powertop to try to make my system more efficient, and kept seeing a USB device I didn't recognize showing up as a frequent source of wakeups. lsusb didn't show it either, so I tried firing up usbview.

Except it didn't work: on Hardy it brings up an error window complaining about not being able to open /proc/bus/usb, which, indeed, is not mounted despite being enabled in my kernel.

A little googling showed this was an oft-reported bug in Ubuntu Hardy: for instance, bug 156085 and bug 151585, both with the charming attitude I so love in open source projects, "No, we won't enable this simple fix that reverts the software to the way it worked in the last release; we'd prefer to keep it completely broken indefinitely until someone happens to get around to fixing it right."

Okay, that's being a little harsh: admittedly, most of the programs broken by this are in the "universe" repository and thus not an official part of Ubuntu. Still, why be rude to users who are just trying to find a way around bustage that was deliberately introduced? Doesn't Ubuntu have any sort of process to assign bugs in universe packages to a maintainer who might care about them?

Anyway, the workaround, in case you need usbview or qemu/kvm or anything else that needs /proc/bus/usb, is to edit the file /etc/init.d/mountdevsubfs.sh and look for the line that says:

# Magic to make /proc/bus/usb work
Uncomment out the lines immediately following that line, then either reboot or run the last command there by hand.

(In case you're wondering, usbview showed that the USB device causing the powertop wakeups was the multi-flash card reader. I'm suspecting hald-addons-storage is involved -- powertop already flagged hal's cdrom polling as the number-one power waster. I don't know why the flash multicard reader shows up in usbview but not in lsusb.)

Tags: ,
[ 20:45 May 31, 2008    More linux | permalink to this entry ]

Thu, 22 May 2008

Fixing scanner permissions on Hardy

Dave needed something scanned. Oh, good! The first use of a scanner under a new distro is always an interesting test. Though the last few Ubuntu releases have been so good about making scanners "just work" that I was beginning to take scanners for granted. "Sure, no problem," I told Dave, taking the sketch he gave me.

Ha! Famous last words. For Hardy, I guess the Ubuntu folks decided that users had had it too easy for a while and it was time to throw us a challenge. Under Hardy, scanning works fine as root, but normal users can't access the scanner. sane-find-scanner sees the scanner, but xsane and the xsane-gimp plug-in can't talk to it (except as root).

It turns out the code for noticing you plugged in a scanner and setting appropriate permissions (like making it group "scanner") has been removed from udev, the obvious place for it ... and moved into hal. Except, you guessed it, whatever hal is supposed to be doing isn't working, so the device's group is never set to "scanner" to make it accessible to non-root users. Lots of people are hitting this and filing bugs (search for scanner permissions), in particular bug 121082 and bug 217571.

Fortunately, the fix is quite easy if you have a copy of your old gutsy install: just copy /etc/udev/rules.d/45-libsane.rules from gutsy to the same place on hardy. (If you don't have your gutsy udev rules handy, I attached the file to the latter of the two bugs I linked above.)

Then udev will handle your scanner just like it used to, and you don't have to wait for the hal developers to figure out what's wrong with the new hal rules.

Tags: , , , ,
[ 15:56 May 22, 2008    More linux | permalink to this entry ]

Fri, 16 May 2008

How to set your time zone

My laptop's clock has been drifting. I suspect the clock battery is low (not surprising on a 7-year-old machine). But after an hour of poking and prodding, I've been unable to find a way to expose the circuit board under the keyboard, either from the top (keyboard) side -- though I know how to remove individual keycaps, thanks to a reader who sent me detailed instructions a while back (thanks, Miles!) -- or the bottom. Any expert on Vaio SR laptops know how this works?

Anyway, that means I have to check and reset the time periodically. So this morning I did a time check and found it many hours off. No, wait -- actually it was pretty close; it only looked like it was way off because the system had suddenly decided it was in UTC, not PDT. But how could I change that back?

I checked /etc/timezone -- sure enough, it was set to UTC. So I changed that, copying one from a debian machine -- "US/Pacific", but that didn't do it, even after a reboot.

I spent some time reading man hwclock -- there's a lot of good reading in that manual page, about the relation between the system (kernel) clock and the hardware clock. Did you know that you're not supposed to use the date command to set the system time while the system is running? Me neither -- I do that all the time. Hmm. Anyway, interesting reading, but nothing useful about the system time zone.

It has an extensive SEE ALSO list at the end, so I explored some of those documents. /usr/share/doc/util-linux/README.Debian.hwclock is full of lots of interesting information, well worth reading, but it didn't have the answer. man tzset sounded promising, but there was no such man page (or program) on my system. Just for the heckofit, I tried typing tz[tab] to see if I had any other timezone-related programs installed ... and found tzselect. And there was the answer, added almost as an afterthought at the end of the manual page:

Note that tzselect will not actually change the timezone for you. Use 'dpkg-reconfigure tzdata' to achieve this.
Sure enough, dpkg-reconfigure tzdata let me set the time zone. And it even seems to be remembered through a reboot.

Tags: , , ,
[ 10:04 May 16, 2008    More linux | permalink to this entry ]

Fri, 02 May 2008

Two font mysteries solved

This has been a good week for fonts: two longstanding mysteries solved.

The first concerns the bitstream vera sans mono I've been using as a terminal font in apps like rxvt and xterm. I'd been specifying it in ~/.Xdefaults like this:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso10646-1

The mystery is that I'd noticed that in xterm, the font looked slightly different -- slightly uglier -- than in rxvt (both apps use the same X class name of XTerm). It was hard to put my finger on what was different -- the shape of all the letters looked the same, but it just seemed a little more ragged, and a little less compact, in xterm. I figured it was just a minor difference in their drawing code, or something.

Well, I was fiddling with fonts (trying to get the new-to-me "Inconsolata" font working) and I noticed that iso10646 bit. I didn't know what 10646 was, but shouldn't it be 8859-1 or 8859-15, the codes for the Latin-1 alphabet? After finishing up my Inconsolata experiments, when I set the font back to Vera I changed the line to XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso8859-15 and moved on to other things.

Until the next morning, when I booted up to a surprise: my main terminal window no longer fit on the screen. It seems it had reverted to the other (uglier) version of Vera Sans Mono, which is also very slightly taller, so instead of being a couple of lines shorter than the screen height, it was a couple of lines too tall to fit.

I checked .Xdefaults -- yes, it was still Vera. What was going on? I finally remembered the one thing I had changed: the language setting on the font, from 10646-1 to 8858-15. I changed it back: sure enough, now the font was pretty again and the terminal was short enough to fit.

I fired up xfontsel and did some experimenting. It turned out the difference between the two almost-identical Vera sans mono bold roman fonts is a field xfontsel calls "spc". It can be either 'c' or 'm'. The 'c' version is the pretty, compact font; the 'm' is the uglier, taller one. For some reason, specifying 10646-1 makes "spc" default to 'c', while 8859-15 makes it default to 'm'. But specifying 'c' in the font specifier gets the good version regardless of which language is specified.

So this would work: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-*-*

But then I read up on 10646-1 and it turns out to mean "the whole unicode character set". That sounds like a good idea, so I kept it in my font specifier after all: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-iso10646-1

(For the moment I still didn't know what spc, c or n meant; read on if you're curious.)

The second insight concerned a longstanding mystery of Dave's. He has been complaining for quite a while about the way Ubuntu's modern pango-based apps all refuse to see bitmapped fonts. (It bothered me too, but less so, because the terminal and editor apps I use can see X fonts.)

Dave has an Ubuntu install on one machine that he's been upgrading release after release, which does see his bitmapped fonts. But any fresh Ubuntu installation fails to see the fonts. What was the difference?

We knew about the trick of going into /etc/fonts/conf.d, removing the symbolic link 70-yes-bitmaps.conf and replacing it with a link to /etc/fonts/conf.avail/70-yes-bitmaps.conf ... But doing that doesn't actually change anything, and bitmap fonts still don't show up.

The secret turned out to be that you need to run fc-cache -fv after changing the font/conf.d links. This apparently never happens on its own -- not on a reboot, not on installing or uninstalling font packages. Somehow it had happened once on Dave's good install, and that's why it worked there but nowhere else.

I'm not sure how anyone is supposed to find out about fc-cache -- there's no man fontconfig, and the /etc/fonts/conf.avail/README offers no clue, just misleadingly says "Fontconfig scans this directory". man fc-cache mentions /usr/share/doc/fontconfig/fontconfig-user.html, which doesn't exist; it turns out on Ubuntu it's actually /usr/share/doc/fontconfig-config/fontconfig-user.html. But wait, that's just an html-ized manual page for fonts-conf, so actually you could just run man fonts-conf ... your guess is as good as mine why the fc-cache man page sends you on a hunt for html files instead.

man fonts-conf is good reading -- it even solves the mystery of that spc parameter. It stands for spacing and can be proportional, dual-width, monospace or charcell. Aha! And there's lots more useful-looking information in that manual page as well.

Tags: , ,
[ 14:58 May 02, 2008    More linux | permalink to this entry ]

Tue, 29 Apr 2008

How often does updatedb really need to run?

Since updating to Hardy, I've been getting mail from Anacron:
/etc/cron.weekly/slocate:
slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory

That's the script that updates the database for locate, Linux's fast find system. I figured I must have screwed something up when I moved that slocate cron script from cron.daily to cron.weekly (because I hate having my machine slow to a crawl as soon as I boot it in the morning, and it doesn't bother me if the database doesn't necessarily have files added in the last day or two).

But after talking to some other folks and googling for Ubuntu bugs, I discovered I wasn't the only one getting that mail, and there was already a bug covering it. Comparing my setup with another Hardy user's, I found that the file slocate was failing to find, /etc/updatedb.conf, belongs to a different package, mlocate. If mlocate is installed, then slocate's cron script works; otherwise, it doesn't. Sounds like slocate should have a dependency that pulls in mlocate, no?

But wait, what do these two packages do? Let's try a little aptitude search locate:

p   dlocate                         - fast alternative to dpkg -L and dpkg -S   
p   kio-locate                      - kio-slave for the locate command          
i   locate                          - maintain and query an index of a directory
p   mlocate                         - quickly find files on the filesystem based
i   slocate                         - Secure replacement of findutil's locate   
Okay, forget the first two, but we have locate, mlocate, and slocate. How do they relate?

Worse, if I install mlocate (so slocate will work) and then look in my cron directories, it turns out I now have, count 'em, five different cron scripts that run updatedb. They are:

In cron.daily:

locate: 72 lines! but a lot of that is comments and pruning, and a lot of fiddling to figure out what version of the kernel is running to see whether it can pass any advanced flags when it tries to renice the process. In the end it calls updatedb.findutils (note no full path, though it uses a full path when it checks for it earlier in the script).

slocate: A much simpler but unfortunately buggy 20 lines. It checks for /etc/updatedb.conf, runs it if it exists, fiddles with ionice, checks again for /etc/updatedb.conf, and based on whether it finds it, runs either /usr/bin/slocate -u or /usr/bin/slocate -u -f proc. The latter path is what was failing and sending root mail every time the script was run.

mlocate: an even slimmer 12 line script, which checks for /usr/bin/updatedb.mlocate and, if it exists, fiddles ionice then runs /usr/bin/updatedb.mlocate.

In cron.weekly:

Two virtually identical scripts called find.notslocate and find.notslocate.dpkg-new, which differ only in dpkg-new having more elaborate ionice options. They both run updatedb. And which updatedb would that be? Probably /usr/bin/updatedb, which links to /etc/alternatives/updatedb, which probably links to either updatedb.mlocate or updatedb.slocate, whichever you've installed most recently. But in either case, it's hard to see why you'd need this script running weekly if you're already running both flavors of updatedb from other scripts cron.daily. And having two copies of the script is just plain wrong (and there was already a bug filed on it). (As long as you're poking around in cron.daily and cron.weekly, check and see if you have any more of these extra dpkg-new or dpkg-old scripts -- they might be slowing down your machine for no reason.)

Further research reveals that mlocate is a new(ish) package intended to replace slocate. (There was a long discussion of that on ubuntu-devel, leading to the replacement of slocate with mlocate very late in the Hardy development cycle. There was also lots of discussion of "tracker", apparently a GUI fast find tool that can only search in the user's home directory.)

What is this mlocate? The m stands for "merge": the advantage of mlocate is that it can merge new results into its existing database instead of replacing the whole thing every time. Sounds good, right? However, the down side is that mlocate apparently can't to purge its database of old files that no longer exist, and these files will clutter up your locate results. Running locate -e will keep them from being printed -- but there seems to be no way to set this permanently, via an environment variable or .locaterc file, nor to tell updatedb.mlocate to clean up its database. So you'll need to alias locate to locate -e if you want sensible behavior. Or go back to slocate. Sigh.

Cleaning up

The important thing is to get rid of most of those spurious updatedb cron scripts. You might choose to run updatedb daily, weekly, or only when you choose to run it; but you probably don't want five different scripts running two different versions of updatedb at different times. The packages obviously aren't cleaning up after themselves, so let's do a little manual cleanup.

That find.slocate script looks suspicious. In fact, if you run dpkg -S find.notslocate, you find out that it doesn't belong to any package -- not only should the .dpkg-old version not be there, neither should the other one! So out they go.

As for slocate and mlocate, it's important to know that the two packages can coexist: installing mlocate doesn't remove slocate or vice versa. A clean Hardy install should have only mlocate; upgrades from Gutsy are more likely to have a broken slocate.

Having both packages probably isn't what you want. So pick one, and remove or disable the other. If mlocate is what you want, apt-get purge slocate and just make sure that /etc/cron.*/slocate disappears. If you decide you want slocate, it's a little trickier since the slocate package is broken; but you can fix it by creating an empty /etc/updatedb.conf so updatedb.slocate won't fail.

Tags: , , ,
[ 20:48 Apr 29, 2008    More linux/install | permalink to this entry ]

Tue, 22 Apr 2008

Autologin changes again for Hardy's upstart

Seems like each new Ubuntu release makes a few gratuitous changes to the syntax of system files. Today's change involves autologin, controlled by the "upstart" system (here's what I wrote about the previous syntax for autologin under upstart).

The /usr/bin/loginscript still hasn't changed, and this still works:

#! /bin/sh
/bin/login -f yourusername

But the syntax has changed a little for the getty line in /etc/event.d/tty1: respawn is now on its own line (I don't know if that matters -- I still can't find any documentation on this file's syntax, though I found a new upstart page that links to some blog entries illustrating how upstart can be used to start system daemons like dbus). And the getty now needs an exec before it. Like this:

respawn
exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

Tags: , ,
[ 14:27 Apr 22, 2008    More linux | permalink to this entry ]