Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Wed, 16 Jul 2008
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: X11, screenshots
[
20:01 Jul 16, 2008
More linux |
permalink to this entry
]
Sun, 22 Jun 2008
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: cellphone, usb, linux
[
19:27 Jun 22, 2008
More linux |
permalink to this entry
]
Sat, 31 May 2008
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: ubuntu, usb
[
20:45 May 31, 2008
More linux |
permalink to this entry
]
Thu, 22 May 2008
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: linux, ubuntu, scanner, udev, hal
[
15:56 May 22, 2008
More linux |
permalink to this entry
]
Fri, 16 May 2008
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: linux, debian, ubuntu, vaio
[
10:04 May 16, 2008
More linux |
permalink to this entry
]
Fri, 02 May 2008
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: linux, fonts, i18n
[
14:58 May 02, 2008
More linux |
permalink to this entry
]
Tue, 29 Apr 2008
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: linux, boot, ubuntu, install
[
20:48 Apr 29, 2008
More linux/install |
permalink to this entry
]
Tue, 22 Apr 2008
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: linux, ubuntu, boot
[
14:27 Apr 22, 2008
More linux |
permalink to this entry
]