Greg
Greg's diary
April 2006
Translate this page
Select day in April 2006:
Su Mo Tu We Th Fr Sa
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
Select month:
2005 Sep Oct Nov Dec
2006 Jan Feb Mar Apr
2006 May Jun Jul Aug
Today's diary entry
Diary index
About this diary
Previous month
Next month
Greg's home page
Greg's photos
Network link stats
Greg's other links
Copyright information
    
Groogle

Saturday, 1 April 2006 Echunga Images for 1 April 2006
Top of page
next day
last day

David Newall and Hari came along today, David to show me his new Nokia 770 machine. I had invited him a couple of days ago, before I saw Steve's machine yesterday. David has set his up differently; the display (800x480, quite reasonable for such a small machine) requires careful examination. And the soft keyboard is different, but mainly in appearance: still no Ctrl key. David had a Bluetooth laser keyboard, though:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060401/big/david-2.jpeg

Image title: david 2          Dimensions:          2112 x 2816, 680 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Saturday, 1 April 2006, thumbnails          All images taken on Saturday, 1 April 2006, small
Diary entry for Saturday, 1 April 2006 Complete exposure details

 

It's a bit temperamental—I found myself missing keystrokes or getting them double—but at least it has a real Ctrl key, and I was able to confirm that the shell understands Emacs-style editing. Tried to get an xterm on wantadilla, which succeeded for a split second, before the Nokia brought an obscure error message about some process not being active. It was wrong: the process was there. But at least the X implementation is capable of speaking the X protocol, something that neither David nor Steve expected.

Still, the machine looks very much like a prototype, and David and Steve are on the bleeding edge. The concept is excellent, though, and I have no doubt that there will be many more such machines in the near future. I'll wait until others have debugged the real problems.


Sunday, 2 April 2006 Echunga
Top of page
previous day
next day
last day

Woke in the middle of the night with an unpleasant feeling in my knee, which gradually proved to be an additional outbreak of the arthritic condition I've had for some years.

This was gout. For some reason, I was unwilling to mention the fact for some years.

Time to see a doctor, I fear. Hobbled around a bit in the morning and spent some time working on my photo collection, which was in quite a mess, and is still by no means in the state I'd like it to be.

Discussions on Australian lists suggest that I won't find a better alternative to computer video than MythTV or mplayer, so in the afternoon spent more time trying to get things to work. It's still like pulling teeth: spent all afternoon trying to work out how to get my tuner card set up. I've done this before with FreeBSD, but with Linux and even help from people on the list, it still took all afternoon. People on the lists suggested using xawtv to test the tuner; I've already commented on how bad that program's documentation is. It now comes with a new program called scantv. It prompts for standard and country and then does a scan of all channels. The problem is, it looks for a device called /dev/vbi, which doesn't exist. In FreeBSD, I can find out about devices from the man pages: for example, for a /dev/bktr I'll find a man page bktr(4). Linux, at least as I have installed it, has nothing corresponding. Google didn't help much either; the suggestion of creating a device with mknod based on major device numbers of several years ago didn't seem to be the right way to go. Finally found that there's a device called /dev/vbi0, so specified that instead, and it seemed to work. I still have no idea what /dev/vbi0 is. The name shows up in files like drivers/media/video/bttv-driver.c in the kernel, but it has almost no comments, certainly nothing to explain what vbi means.

The output of scantv was not surprising: I had no antenna cable connected, so at least for that reason it didn't find anything. I need to move it to where there's an antenna, but by the time I had got that far, I had no more time. Next week.


Monday, 3 April 2006 Echunga
Top of page
previous day
next day
last day

Mainly administrative stuff today; I still need to write up my streaming backup worklog from Sorrento. That was made more complicated by the fact that I couldn't find my notes; it seems that my synchronization scripts deleted it last Thursday. Thank God for backups! I had backed up the entire laptop after returning from Sorrento, so was able to recover.

Despite all good will, it's not easy to make friends with Linux. I'm sure that when I installed Ubunto on eucla, my laptop, I asked for all development tools. But while installing xtset, I found:

=== grog@eucla (/dev/pts/3) ~ 3 -> make
bash: make: command not found

Sure enough, make wasn't installed. After installation, I tried again:

=== grog@eucla (/dev/pts/3) ~/homekit/src/xtset-1.1/xtset-1.1 12 -> make
cc     xtset.c   -o xtset
make: cc: Command not found
make: *** [xtset] Error 127

After installing gcc, things I still didn't have the rest of the development tools:

=== grog@eucla (/dev/pts/3) ~/homekit/src/xtset-1.1/xtset-1.1 13 -> make
cc     xtset.c   -o xtset
xtset.c:44:20: error: unistd.h: No such file or directory
xtset.c:45:19: error: stdio.h: No such file or directory

A check on ceeveear, the TV machine I was working on yesterday, confirmed that it didn't have any development tools either. Considering that I always do an “everything” installation, that's particularly strange. Discussing it on IRC was helpful, but also revealing:

* groggy boggles.
<groggy> === grog@eucla (/dev/pts/3) ~ 3 -> make
<groggy> bash: make: command not found
<groggy> How can that happen?
* groggy bangs his head against the nearest brick wall.
<groggy> OK, how do I get Ubuntu to install a basic system?
(etc)
<Rasmus> apt-get install libc6-dev
<groggy> Rasmus: Thanks.
* groggy was gradually getting there.
<groggy> Rasmus: What's the difference between libc6 and libc6-dev?
<hughhalf> latter includes the header files IIRC
<Rasmus> one is for dev, the other runtime
<groggy> Rasmus: OK.  Thanks.
<hughhalf> seems to be fairly standard delineation in Debian based systems
<Rasmus> dpkg -L libc6
<groggy> Rasmus: So why doesn't this stuff get installed by default when I ask for developement software?
<Rasmus> It does
<Rasmus> you screwed something up
<groggy> Rasmus: Once, OK.  Twice?
<Rasmus> you are good at screwing up, I guess
<Rasmus> a consistent screw-up
<Rasmus> i think that just installs the build-essential meta-package
<Rasmus> do you have that installed?
<groggy> === root@eucla (/dev/pts/4) ~ 31 -> dpkg -I build-essential
<groggy> dpkg-deb: failed to read archive `build-essential': No such file or directory
<groggy> That means "no"?
<Rasmus> that means no
<groggy> Where do I find this stuff documented?
<Rasmus> the knowledge flows like blood through the veins of the Internet
<groggy> Rasmus: And clots in places...

I particularly like the quote “the knowledge flows like blood through the veins of the Internet”. But that's not really sufficient; why can't I find a book like The Complete FreeBSD that explains these things?


Tuesday, 4 April 2006 Echunga
Top of page
previous day
next day
last day

More work on my API definition today. All seemed so simple in Sorrento, but looking at the details raises many questions, and once again I feel the difficulties of not having somebody in my own time zone to talk about it with.

One useful source of information that I shouldn't discount is this diary; people read it and reply to me. Today on IRC, Olli Lehmann told me about the meaning of /dev/vbi. pointing to an article on zapping VBI. It explained the meaning of the name: “Vertical Blanking Interval”. Makes sense (the vertical blanking interval is often used to carry additional information). But what a way to find out.

My new lagering fridge still has thermostat problems. I had been monitoring the temperature with my fermentation temperature control computer, but the low temperatures caused the sensor connectors to fail. In addition, the thermostat stuck “on”, and by the time I had found the problem, many bottles had frozen, and three had burst. More work to do some time.


Wednesday, 5 April 2006 Echunga
Top of page
previous day
next day
last day

More work on the streaming backup design today. It seems ridiculous that it should take a couple of days to write up what we put together in 90 minutes, but there's a lot to check up on. It seems that the MyISAM debug log is not well known, for example: even people maintaining MyISAM don't know much about it. Anyway, finally got the update put away. How I hate this work log system! There's no editing possible, and for some reason I can't even copy and paste.

Another pointer to documentation in the mail today, this time from Lars Scheuer, pointing to a The Debian System, a book by Martin Krafft. I suppose it was just a coincidence that I had woken up in the night before and spent some time pondering on the fact that the new German spelling (object of much objection) still has the spelling “Kraft” for a word which is pronounced “Krafft”. The book looks like it could be what I need.


Thursday, 6 April 2006 Echunga
Top of page
previous day
next day
last day

As if I don't get enough email spam, I'm also recently getting more fax spam. One of the worst offenders is Dell Computers. Called them up today and was told that the fax number had been “obtained legally”. On further investigation, it's because I'm a customer. Are they trying to drive away their customers? Added the details to my Dell page.

Apart from that, more work on bugs, without making too much tangible progress. Nevertheless I have the feeling that I'm making some progress. Found one bug that wasn't reproducible on FreeBSD or Linux/AMD64, and discovered that I didn't have enough tools installed on my local Linux box (really my CVR) to do the work. Started downloading the latest Ubuntu CD, since I'd had a number of issues with the current version, but didn't get round to installing it.


Friday, 7 April 2006 Echunga Images for 7 April 2006
Top of page
previous day
next day
last day

This morning reconfigured ceeveear: moved the disk to slave position, and added a “new” disk as master, then installed Ubuntu 5.10 on it. Discovered that it was the same version that I had already installed; for some reason, though, on rebooting I got three different installations with the same name (the other two had already been on the disk; I didn't realize that 5.10 and Breezy Badger are the same thing, a good reason to avoid names (another one is that it's not clear whether Breezy Badger or Dapper Duck is the newer of the two). It punished me with a “kernel panic” on boot; possibly it was trying to boot from the slave disk, and the file system names were wrong. Removed the disk and continued with the old version, which was missing some packages.

Finding packages in Ubuntu or Debian is really not as easy as aficionados claim: I just couldn't find aclocal. The only name given looked completely incorrect, and on installation proved to be so:

=== grog@ceeveear (/dev/pts/1) color="red">/src/MySQL/5.0-Bug-17201 color="blue">25 -> apt-cache search aclocal
libguile-dev - Development headers and static library for libguile

Checked on an internal machine, but it wasn't running Debian/Ubuntu. On the advice of Chris Yeoh, found a new program:

=== grog@dl145j (/dev/pts/0) ~ color="blue">5 -> lsb_release -a
LSB Version:    1.3
Distributor ID: FedoraCore
Description:    Fedora Core release 4 (Stentz)
Release:        4
Codename:       Stentz

That's useful to know, but it didn't get me much further, so tried searching on http://packages.debian.org/, which came up with nothing. With help from Jim Winstead, found it after all. When I installed it, though, it came up with error messages. Further investigation revealed that it was very down-rev, even more so than the web page suggested:

=== grog@ceeveear (/dev/pts/1) color="red">/src/MySQL/5.0-Bug-17201 color="blue">24 -> aclocal --version
aclocal (GNU automake) 1.4-p6

By contrast, FreeBSD has:

=== grog@echunga (/dev/ttypc) color="red">/src/MySQL/5.0-Bug-17201 color="blue">4 -> aclocal --version
aclocal (GNU automake) 1.9.6

On IRC discovered that Alan Modra, one of the IBM tools people, has his own problems:

<alanm> groggy: aclocal is indeed part of autoconf, so ought to be in autoconf package..
<groggy> alanm: Found it in automake.
<groggy> alanm: The Debian search page only shows it if I look in oldstable, not if I look at it in stable.
<alanm> groggy: huh.  i was sure it was in autoconf.  had to build myself a new automake and autoconf before i was
+       convinced :)
<groggy> alanm: I have another issue there.  The Debian package says:
<groggy> aclocal (GNU automake) 1.4-p6
<groggy> And it reports errors on build.
<groggy> The FreeBSD version is:
<groggy> aclocal (GNU automake) 1.9.6
<groggy> That's *seriously* down-rev.
<groggy> Did you have any trouble building the latest version?
<alanm> i wonder whether debian has an automake-1.8/9 package.  1.4 is needed for some older source that won't work
+       with newer autoconf/automake
<alanm> and yes, i did hit an error building cvs autoconf..
<groggy> *sigh*

Finally found that there are multiple automake packages:

=== root@ceeveear (/dev/pts/0) /home/grog color="blue">27 -> apt-cache search automake
autoconf - automatic configure script builder
automake1.4 - A tool for generating GNU Standards-compliant Makefiles.
automake1.6 - A tool for generating GNU Standards-compliant Makefiles.
automake1.7 - A tool for generating GNU Standards-compliant Makefiles
automake1.8 - A tool for generating GNU Standards-compliant Makefiles
automake1.9 - A tool for generating GNU Standards-compliant Makefiles
autotools-dev - Update infrastructure for config.{guess,sub} files

Removed automake and, on Jim's recommendation, installed automake-1.8, and not automake-1.9:

<groggy> jimw: Ah, forget it.
<groggy> jimw: I need to install automake-1.9, not automake.
* groggy thought that only FreeBSD was that silly.
<jimw> no, everything is silly with auto* because they aren't always very cross-version compatiable.
<jimw> i have a feeling you may really want automake1.8, since i'm not sure automake1.9 works.  ;)

That didn't help: I still had version 1.4. Despite the removal, the file didn't go away: had to remove it manually. What a way to install software!

While I was doing this, took a look at the sample chapter of The Debian system, conveniently (and presumably not coincidentally) about software installation. It was of no help about how to find packages.

In the afternoon, lots of packages arrived:

Unpacking the multimeter was a surprise: it was powered on. After messing around with it, discovered that it didn't indicate anything. Further examination showed that the probe connected to the circuit board by a fuse and a spring, and the spring had not been soldered on correctly:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060407/big/multimeter-1.jpeg
Image title: multimeter 1          Dimensions:          2816 x 2112, 827 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Friday, 7 April 2006, thumbnails          All images taken on Friday, 7 April 2006, small
Diary entry for Friday, 7 April 2006 Complete exposure details

 

Even after repairing that, it didn't work. It took a long time to realize that the scale indication on the right was a mirror image of the control to which it refers:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060407/big/multimeter-3.jpeg
Image title: multimeter 3          Dimensions:          2816 x 2112, 736 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Friday, 7 April 2006, thumbnails          All images taken on Friday, 7 April 2006, small
Diary entry for Friday, 7 April 2006 Complete exposure details

 

The red switch at bottom left (best seen in the full-size image; click twice) is numbered 4-3-2-1-off. The explanation at top right is numbered 1-2-3-4, so it's easy to get the position the wrong way round. What a stupid thing to do!

Finally got the Apple machine working again, after which I was able to pull down the sources and start a build. It was refreshing to note that aclocal and friends were already present on the machine, saving me further frustration. Not that it worked:

gcc -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local/mysql\"" -DDATADIR="\"/usr/local/mysql/var\"" -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DHAVE_CONFIG_H -I.  -I.  -I..  -I../zlib -I../bdb/build_unix -I../innobase/include -I../ndb/include -I../ndb/include/ndbapi -I../ndb/include/mgmapi -I../include -I../include -I../regex -I.  -I../extra/yassl/include     -g  -DDBUG_ON -DSAFE_MUTEX -Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Woverloaded-virtual -Wsign-promo -Wreorder -Wctor-dtor-privacy -Wnon-virtual-dtor  -felide-constructors -fno-exceptions -fno-rtti -mcpu=powerpc -mtune=powerpc -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG -DFORCE_INIT_OF_VARS -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -DSAFE_MUTEX -O1 -Wuninitialized    -fno-implicit-templates -fno-exceptions -fno-rtti -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT  -c -o gen_lex_hash.o `test -f 'gen_ ex_hash.cc' || echo './'`gen_lex_hash.cc
sql_yacc.yy:3946: type clash (`' `NONE') on default action
sql_yacc.yy:3969: type clash (`' `NONE') on default action
sql_yacc.yy:4297: type clash (`' `NONE') on default action
sql_yacc.yy:4297: type clash (`' `NONE') on default action
sql_yacc.yy:4298: type clash (`' `NONE') on default action
sql_yacc.yy:4298: type clash (`' `NONE') on default action
sql_yacc.yy:4300: type clash (`' `NONE') on default action
sql_yacc.yy:7891: type clash (`' `num') on default action
gmake[2]: *** [sql_yacc.cc] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[1]: *** [all-recursive] Error 1
gmake: *** [all] Error 2

Chris Yeardley arrived in the evening. She took a particular liking to the toy dog that Yana gave Yvonne for Christmas:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060407/big/Chris-and-Lilac-5.jpeg
Image title: Chris and Lilac 5          Dimensions:          2816 x 2112, 1029 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Friday, 7 April 2006, thumbnails          All images taken on Friday, 7 April 2006, small
Diary entry for Friday, 7 April 2006 Complete exposure details

 

Later watched a satire program on TV, “Kylie Kwong”: spice, cleverly disguised as a cooking program. It's very subtle: we first realized what the real intention was when she started talking about cooking a tagine with only east Asian spices. We then managed to second guess that she would add fish sauce to the tagine, which she did. Very clever, but maybe a little too subtle for the average Australian viewer, who might really take it to be a cooking program. To make the point, brought out some Korean fish sauce, which I use to make kimchi; that seriously interested Lilac:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060407/big/Chris-and-Lilac-10.jpeg
Image title: Chris and Lilac 10          Dimensions:          2816 x 2112, 921 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Friday, 7 April 2006, thumbnails          All images taken on Friday, 7 April 2006, small
Diary entry for Friday, 7 April 2006 Complete exposure details

 


Saturday, 8 April 2006 Echunga
Top of page
previous day
next day
last day

More work on trying to get my TV tuners to work on ceeveear, the Ubuntu machine. It's still not easy. One of the strangest things I've seen has been that NFS mounting file systems from FreeBSD to Ubuntu takes 104 seconds per file system. Once mounted, access to the file system works fine. I suspected an incompatibility between the implementations, so spent some time running ethereal to try to work out what was going wrong, but that just showed a normal NFS mount operation followed by 104 seconds of nothing. The local (Ubuntu) /var/log/messages was more informative, but I no longer have the messages (see the end of today's entry); something about “unable to connect to localhost”. I suspect that it's a problem with the initial installation, but it happens on both machines (eucla, the laptop, and ceeveear, the TV machine).

The tuner was easier. I connected it to an antenna and answered the questions, and was gratified by:

=== root@ceeveear (/dev/pts/0) /home/grog color="blue">22 -> scantv -C /dev/vbi0
6    (175.25 MHz): no station
7    (182.25 MHz): ???
[unknown (7)]
channel = 7

8    (189.25 MHz): no station
9    (196.25 MHz): ???
[unknown (9)]
channel = 9

10   (209.25 MHz): ???
[unknown (10)]
channel = 10

11   (216.25 MHz): no station

That all looks correct: we do indeed have channels 7, 9 and 10. But according to the man page,

DESCRIPTION
       scantv  scans  a  v4l  device  for  available  TV stations and writes a
       xawtv/fbtv config file.

So where's xawtv/fbtv? Not in the cwd, nor in the home directory. Since it didn't mention the pathname, decided that it might be somewhere else, and tried running xawtv anyway. Nothing, but the man page said that the configuration file was called .xxawtv, and not xawtv/fbtv. That wasn't there either. Ran scantv again and confirmed that it didn't write any output file. Then I read more of the man page:

       -o outfile
              specify output file.  If none is specified, scantv write to std-
              out.

It turns out that the text in the example above is in fact the configuration information:

[unknown (7)]
channel = 7

Not that you can do anything with it like that; both the defaults and the man page are less than suitable.

Finally created a configuration file, and it selected channel 61 (conveniently, not occupied, so just noise on the screen), and discovered that I could not change channel: neither mouse nor keyboard worked. This seemed to be related to the messages it printed on startup:

This is xawtv-3.94, running on Linux/i686 (2.6.12-8-386)
Warning: translation table syntax error: Unknown keysym name:  XF86AudioRaiseVolume
Warning: ...  found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc)                '
Warning: String to TranslationTable conversion encountered errors
Warning: translation table syntax error: Unknown keysym name:  XF86AudioRaiseVolume
Warning: ...  found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc)                '
Warning: String to TranslationTable conversion encountered errors
Warning: Cannot convert string "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to type FontStruct
Warning: translation table syntax error: Unknown keysym name:  XF86AudioRaiseVolume
Warning: ...  found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc)                '
Warning: String to TranslationTable conversion encountered errors

On another attempt, it found a different channel, one that was in use, and showed that it was, indeed, receiving TV. But it still didn't accept any mouse or keyboard input. So, possibly a forgotten dependency? That seems common in Linux—see the installation of mplayer. Looking for related packages, I found:

=== root@ceeveear (/dev/pts/0) /home/grog 26 -> apt-cache search xawtv
liblircclient0 - LIRC client library
came - Rewrite of the xawtv webcam app using imlib2
libvideo-capture-v4l-perl - Perl interface to the Video4linux framegrabber interface
pia - movie player
scantv - scan TV channels for stations
v4l-conf - tool to configure video4linux drivers
xawtv - X11 TV application
xawtv-plugin-qt - quicktime plugin for xawtv and motv
xawtv-plugins - plugins for xawtv and motv
xawtv-tools - Miscellaneous tools distributed with xawtv
libmjpegtools-dev - MJPEG video capture/editting/playback MPEG encoding
libmjpegtools0 - MJPEG video capture/editting/playback MPEG encoding
mjpegtools - MJPEG video capture/editting/playback MPEG encoding

So, which were installed and which not? What I wanted was the Linux equivalent of FreeBSD's pkg_info. Looking through the documentation for apt-get and apt-cache, that didn't seem right. Neither did the documentation for dpkg. So I went to the Ubuntu support site, which pointed me to a quick tour and a start guide, neither of which I wanted: I wanted a user guide. Looking on Google brought me 102,000 hits for "Ubuntu User Guide". The first one looked good, but despite calling itself an “unofficial user guide” (where's the official one?), it's a forum. Most of the other hits looked less than useful, so I limited my search to PDF documents. One single hit, not from the official Ubuntu site, and only 31 pages long, including table of contents, introductions and disclaimers. It had some stuff on software installation, but still nothing on how to find out which packages were installed.

OK, this system is laid out to work under GNOME, and there's a graphical program called synaptic. That produced its own error messages:

(synaptic:7099): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
(synaptic:7099): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
(synaptic:7099): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed
(synaptic:7099): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed

It also produced a ridiculously badly proportioned display, showing only the first third of the package category names, and that on a full screen 1600x1200 display. Fixed that, selected multimedia and looked for xawtv. Nothing. Also nothing in multimedia-multiverse and multimedia-universe. Only when I did a search for xawtv did I get a display that matched the list from apt-cache above, only alphabetically sorted. It showed that everything I could reasonably expect to install was already installed. So where is the problem? An hour of searching useless and non-existent documentation, and no closer to the solution.

At about this point, and not for the first time, I gave up. I decided that the hardware was working, but the software was not. I've had at least these problems with Ubuntu, and they shouldn't happen in a production release:

Not all of these have to be Ubuntu's fault, of course, and I'm reserving judgement on one other issue, which may be a configuration problem: when I open an X terminal on one of the FreeBSD machines that comprise my office desktop, the shell doesn't handle the Meta- characters correctly. For example, ~-F should move to the end of the following word. It does on FreeBSD, and it also does so on the default Ubuntu display; but with an Ubuntu X-term on one of my FreeBSD X servers, it capitalizes the word. Other keys are even less use. But that may be because of a discrepancy in character sets (UTF-8 on Linux, ISO-8859-1 (8 bit) on FreeBSD).

Anyway, I had just downloaded Fedora Core 5 from the Internode mirror server, so decided to try that on the spare partition (I always put two root partitions of 4 or 5 GB on my machines, and I only put system-related stuff on them, so that I can move from one release to another relatively easily. eucla even has three, two FreeBSD and a Linux, all of which share the same /home file system). Installed Fedora on ceeveear and was gratified by a much cleaner install. No problems with the meta-characters, NFS mounts Just Work, I now have a /dev/vbi, and I even found a MythTV HOWTO that seems to make sense, so followed that. Hopefully I won't run into Yet Another dead end.

Another interesting thing about GNOME is that I was able to get the top menu bar to display on wantadilla, my main machine, which runs fvwm2 as its standard window manager; this could be a good compromise between the GNOME menus and the flexibility of fvwm2. Today, though, it confused things: for some reason, it slowed down the repeat rate of the keyboard, and also disabled kbdcontrol, which should set the repeat rate. It also changed the input line editing on my local (wantadilla) firefox from Emacs-like to something Microsoft-like. But I know about that, and hopefully I'll be able to find a solution that is more convenient than anything I have so far.


Sunday, 9 April 2006 Echunga Images for 9 April 2006
Top of page
previous day
next day
last day

Up early this morning with the intention to finally make progress with the Computer Video Recorder. I did make quite a bit of progress, but mainly towards getting functional Linux installations on ceeveear and eucla:

Following http://wilsonet.com/mythtv/fcmyth.php: For the SiS drivers for ceeveear, execute the following as root:

mkdir -p ~mythtv/sources/sis_drv
cd ~mythtv/sources/sis_drv
wget http://www.winischhofer.net/sis/sis_drv.o_xorg_gcc3_current.tar.gz
tar -xzvf sis_drv.o_xorg_gcc3_current.tar.gz
mv /usr/X11R6/lib/modules/drivers/sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.o.orig
cp sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.o

The directory http://www.winischhofer.net/sis/ contains a very large number of similarly named files, which firefox conveniently truncates. sis_drv.o_xorg_gcc3_current.tar.gz appears to be the latest version (i.e. not a static content).

At this point, things went wrong. /usr/X11R6/ has only one directory in it, bin. Fortunately, Fedora seems to do the right thing by locate (or maybe I was just lucky that it gets done Saturday night; I can't work out the format of the periodic cron scripts). It shows:

=== root@ceeveear (/dev/pts/2) color="red">/home/mythtv/sources/sis_drv color="blue">35 -> locate sis_drv
/ubuntu/usr/X11R6/lib/modules/drivers/sis_drv.o
/usr/lib/xorg/modules/drivers/sis_drv.so

OK, rewrite that script:

mkdir -p ~mythtv/sources/sis_drv
cd ~mythtv/sources/sis_drv
wget http://www.winischhofer.net/sis/sis_drv.o_xorg_gcc3_current.tar.gz
tar -xzvf sis_drv.o_xorg_gcc3_current.tar.gz
mv /usr/lib/xorg/modules/drivers/sis_drv.o /usr/lib/xorg/modules/drivers/sis_drv.o.orig
cp sis_drv.o /usr/lib/xorg/modules/drivers/sis_drv.o

Interestingly, though, that's still not the same name:

=== root@ceeveear (/dev/pts/2) /home/mythtv/sources/sis_drv 41 -> l /usr/lib/xorg/modules/drivers/sis_drv*
-rw-r--r-- 1 root root 597402 Apr  9 12:03 /usr/lib/xorg/modules/drivers/sis_drv.o
-rwxr-xr-x 1 root root 609444 Feb 13 05:53 /usr/lib/xorg/modules/drivers/sis_drv.so
=== root@ceeveear (/dev/pts/2) /home/mythtv/sources/sis_drv 42 -> file /usr/lib/xorg/modules/drivers/sis_drv*
/usr/lib/xorg/modules/drivers/sis_drv.o:  ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
/usr/lib/xorg/modules/drivers/sis_drv.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

So which do we take? Took a look at Thomas Winischhofer's SiS chipset overview, which was instructive. ceeveear has:

02:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 315PRO PCI/AGP VGA Display Adapter (prog-if 00 [VGA]
, "1")
        Subsystem: Silicon Integrated Systems [SiS] 315PRO PCI/AGP VGA Display Adapter
        Flags: bus master, 66MHz, medium devsel, latency 39, IRQ 5
        BIST result: 00
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Memory at e5000000 (32-bit, non-prefetchable) [size=256K]
        I/O ports at c000 [size=128]
        [virtual] Expansion ROM at e4000000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 2
        Capabilities: [50] AGP version 2.0

On further investigation, http://www.winischhofer.net/sis/sis_drv.o_xorg_6.9.0_gcc4_091205-1.tar.gz contains the file /usr/lib/xorg/modules/drivers/sis_drv.so, and it's the correct version of Xorg, so I'll go for that.

While doing that, decided to set up the environment a bit better. One thing I definitely need is a window manager that I'm happy with, and that's pretty much fvwm2. Found the RPM and downloaded it, and was then forcibly reminded of why I didn't like Fedora:

=== root@ceeveear (/dev/pts/2) /home/mythtv/sources 102 -> rpm -i fvwm-2.5.13-1.i386.rpm
error: Failed dependencies:
        libfribidi.so.0 is needed by fvwm-2.5.13-1.i386
        libreadline.so.4 is needed by fvwm-2.5.13-1.i386
        libstroke.so.0 is needed by fvwm-2.5.13-1.i386
        libXft.so.1 is needed by fvwm-2.5.13-1.i386

Spent a bit of time following up these references before it dawned on my that I was being silly. Some of these were missing simply because they were out of date. What I should have been doing was building from source—after all, when it comes to porting, I wrote the book. That worked relatively simply. Getting it to actually work was more complicated; I need to read more about GNOME.

At this point, the instructions became quite complicated, and I first need to read both them and the MythTV documentation to understand what needs to be done. The good news appears to be that there's a generic IR remote control application, which will make things much easier. But that's for another day. Tried installing xawtv, but again ended up with a maze of twisty little unfulfilled dependencies, all different. An attempt to build xawtv from source also failed, since I first needed to install the Xorg sources. Put that in the “too hard” basket.

I now have a blog! I've always been annoyed by people who call this document a blog, so now I have a real one, and people can't reasonably refer to this as a blog any more. It also explains why I hate the “blog” concept.

In the evening, yet another paella:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060409/big/paella-2.jpeg
Image title: paella 2          Dimensions:          2112 x 2816, 1007 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 9 April 2006, thumbnails          All images taken on Sunday, 9 April 2006, small
Diary entry for Sunday, 9 April 2006 Complete exposure details

 

Our messing around the other night was obviously not enough. Discovered we had a number of opened wine bottles, each with a single glass left in it, so emptied them:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060409/big/boozeup-2.jpeg

Image title: boozeup 2          Dimensions:          2816 x 2112, 1083 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 9 April 2006, thumbnails          All images taken on Sunday, 9 April 2006, small
Diary entry for Sunday, 9 April 2006 Complete exposure details

 

Pleasant evening.


Monday, 10 April 2006 Echunga
Top of page
previous day
next day
last day

Input from James Andrewartha on the topic of my Ubuntu woes:

To list the status of packages, you want dpkg -l "*regex*" http://www.us.debian.org/doc/manuals/debian-faq/ch-pkgtools.en.html#s-whatpackages

Debian does have quite a few book-style pieces of documentaiton on its website, although from a quick glance not all of them are fully up-to-date, and they vary in assumed experience significantly. http://www.us.debian.org/doc/

Ubuntu doesn't ship with development tools on the CD or default install, so an 'apt-get install build-essential manpages-dev' is required, along with 'apt-get build-dep packagename' to get the build requirements for a package. http://www.us.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html

Debian keeps old versions of automake around for compatibility reasons, however it probably is a bug that the most recent one isn't installed by default when you just specify automake without a version. Also, this is why your search for aclocal on packages.debian.org didn't find anything - they're all aclocal-1.x so they only match when searching on "files or directories that contain the keyword" http://packages.debian.org/cgi-bin/search_contents.pl?word=aclocal&searchmode=searchword&case=insensitive&version=unstable&arch=i386 Due to the way Linux development works, a lot of device information is only located in Documentation/ in the kernel source. DocBook/videobook.tmpl contains the following:

        <entry>VFL_TYPE_VBI</entry><entry>/dev/vbi{n}</entry><entry>
        The VBI devices capture the hidden lines on a television picture
        that carry further information like closed caption data, teletext
        (primarily in Europe) and now Intercast and the ATVEC internet
        television encodings.</entry>

http://kb.mozillazine.org/Emacs_Keybindings_(Firefox) (should be self-explanatory).

These suggestions are very helpful. It's interesting that the information that he gives, though demonstrably correct, contradicts what many other Debian/Ubuntu people say. The sad thing is that his input shouldn't be necessary. After installing Fedora Core 5, things were much better (though not perfect).

On the work front, still looking at bugs, with mixed results. Got confirmation from Kent Boortz that the automake tools supplied with Mac OS X 10.3.8 are out of date and will not compile MySQL properly. Ran another update of the software and was given lots of new updates, including 47 MB of updates for iPod, which I don't have, but no updates for the development tools. Ended up installing the same versions of the tools that I had for FreeBSD. Another advantage of the Ports Collection is that you automatically get the original source tarball.

Unfortunately, that didn't work either. I got random crashes of aclocal and friends, and also one case of the entire machine locking up, making me wonder whether there's something wrong with the machine. Once I got past that, I couldn't get past the following:

/bin/sh ../libtool --preserve-dup-deps --tag=CC --mode=link gcc  -g  -DDBUG_ON -DSAFE_MUTEX -Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Wunused  -mcpu=powerpc -mtune=powerpc -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG -DFORCE_INIT_OF_VARS -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -DSAFE_MUTEX -O1 -Wuninitialized    -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT   -o libz.la -rpath /usr/local/mysql/lib/mysql -version-info 3:3:2 adler32.lo compress.lo crc32.lo deflate.lo gzio.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo uncompr.lo zutil.lo  -lm
gcc -dynamiclib ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o .libs/libz.1.2.3  .libs/adler32.o .libs/compress.o .libs/crc32.o .libs/deflate.o .libs/gzio.o .libs/infback.o .libs/inffast.o .libs/inflate.o .libs/inftrees.o .libs/trees.o .libs/uncompr.o .libs/zutil.o  -lm  -mcpu=powerpc -mtune=powerpc -install_name  /usr/local/mysql/lib/mysql/libz.1 -compatibility_version 4 -current_version 4.3
(cd .libs && rm -f libz.1 && ln -s libz.1.2.3 libz.1)
(cd .libs && rm -f libz && ln -s libz.1.2.3 libz)
ar cru .libs/libz.a  adler32.o compress.o crc32.o deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o~ranlib .libs/libz.a
ar: zutil.o~ranlib: No such file or directory
gmake[2]: *** [libz.la] Error 1
gmake[1]: *** [all-recursive] Error 1
gmake: *** [all] Error 2
Spent some time trying to work out where that ~ (tilde) comes from, without success.

On the other hand, building on the new eucla (running Fedora Core 5) went without problems, and I was able to run some tests that seem to indicate that BUG#11932 has indeed been fixed by the fix to another bug.

Company-wide teleconference in the evening (7 am in Cupertino, 23:30 here, 24:00 in Brisbane and Melbourne. Managed to stay up and was rewarded by hearing Mårten and Kaj singing “Helan Går” at the end. This is a fun company to work for.


Tuesday, 11 April 2006 Echunga
Top of page
previous day
next day
last day

Up relatively early despite last night's late night, to discover at 9 am on the dot a message telling me that I would get a phone at 9 am. Sure enough, got the call; but that's lucky in itself.

More work on bugs all day long. At the end of the day, I had done everything except look at code; the big part of the learning curve, which is only dawning on me now, is the ability to set up test cases, and that requires understanding of the test suites. I need to step back and look at them.

Despite the work pressure, found enough time to install xchat on the new (Linux) incarnation of eucla. That was interesting in a number of ways:


Wednesday, 12 April 2006 Echunga
Top of page
previous day
next day
last day

More bug work today, and finally got one simple one done without too much effort. Gradually a number of others are progressing as well; hopefully I'll be able to get a number cleaned up in the near future.


Thursday, 13 April 2006 Echunga
Top of page
previous day
next day
last day

Still not done with my code changes; a new pull from the master repo created some conflicts that needed to be resolved. That apparently caused bitkeeper to corrupt something:

RESYNC/sql/SCCS/s.mysqld.cc: unmerged leaf 1.541.1.1
RESYNC/sql/SCCS/s.mysqld.cc: unmerged leaf 1.543
resolve: bad file RESYNC/sql/SCCS/s.mysqld.cc;
Got a recommendation on IRC:
<bloke> bk reportbug
<bloke> or something like that :)
<bloke> then, my recommended way would be:
<bloke> 1.  export changesets
<bloke> 2.  clone a new tree
<bloke> 3.  import changesets into new tree
<bloke> 4.  swear at bk
<bloke> 5.  get beer
<bloke> note that step 5 can be done around any of the other stages.
<bloke> same with step 4

That worked. Running the tests didn't; one of them hung. It turned out that I had run out of space, and that the test hadn't noticed. Removed a dead (source) tree and tried again. This time nothing ran: in retrospect it looks like something was left behind from the previous run, but it was late in the evening, I was supposed to be on holiday, and I couldn't be bothered, so I just rebooted the machine. Then all the tests ran, and I pushed the change. Comments to the change sets: foo1 and foo2. By exporting and importing the change sets, I lost the original comments and ended up with the names of the temporary files. Damn.

Firefox has always given me some strange problems, but today took the cake: once again it stopped accepting input (probably the fault of something else), so I stopped it and tried to restart it (from the window manager). It didn't. Tried again from a shell and saw:

=== grog@wantadilla (/dev/ttyq4) ~ 19 -> firefox
(Gecko:10676): GLib-GObject-WARNING **: cannot register existing type `GConfClient'
(Gecko:10676): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
(Gecko:10676): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
Segmentation fault

What caused that? “I haven't changed anything”. Was unable to find how to restart it, and ended up running it from a different machine.

The battery in Yvonne's mobile phone has died; given that the phone is over 4 years old and is showing some flakiness, it doesn't seem to be worth replacing. I had been thinking of buying a new, featureful phone and giving her my old one, but I wasn't able to find anything that I really wanted. So Yvonne, who only uses a phone for phone calls, went out and found a SAGEM MYC2-3 phone for only $59, including a SIM card with $10 worth of calls. Considering that we were offered a similar SIM card in Germany 18 months ago for € 20 (about $33) without any credits, that doesn't leave much for the cost of the phone. It's not much of a phone, of course, but it's small, which is what interests Yvonne most. Unfortunately, it's full of games and images and things, and even WAP (is that still going?) and GPRS, but it's missing basic things like one-digit access to frequent numbers. The marketeers seem to be missing the point.


Friday, 14 April 2006 Echunga
Top of page
previous day
next day
last day

Off early to Meadows to look at a house that Catherine Smith is thinking of buying. It's quite close to the middle of town, and the price seems reasonable, but the paddocks are full of Salvation Jane, which would require a lot of treatment.

I'm still having problems with my desktop environment:

Finally found out how to enable remote opens of the X server: set

--- /etc/gdm/custom.conf~       2006-03-14 09:45:06.000000000 +1030
+++ /etc/gdm/custom.conf        2006-04-14 14:51:18.000000000 +0930
@@ -38,8 +38,7 @@
 [daemon]

 [security]
+# Allow remote connections
+DisallowTCP=false
-
 [xdmcp]

 [gui]

Only one problem: it didn't work. gdm read the file, but it still started the X with -nolisten-tcp. Not until I rebooted (I'm doing that far too often) did it start X without that option:

usr/bin/Xorg :0 -audit 0 -auth /var/gdm/:0.Xauth vt7

But I still couldn't access the server:

=== grog@wantadilla (/dev/ttyq7) ~ 66 -> xterm -display eucla:0
Xlib: connection to "eucla:0.0" refused by server
Xlib: No protocol specified
xterm Xt error: Can't open display: eucla:0

Spent quite a bit of time looking at the source code of gdm, and noted that there didn't really seem to be a way to disable the -auth options: in the version running on FreeBSD (2.8.0.5), the function gdm_server_resolve_command_line in daemon/server.c has:

    if (disp->authfile != NULL) {
        argv[len++] = g_strdup ("-auth");
        argv[len++] = g_strdup (disp->authfile);
    }

So it's not a command line option after all.

Round about here noted a significant problem with the current state of “Open Source”, as typified by Linux. Yes, the sources for all the software is there—but not here. To build GNOME, I assumed that I would need to have the X sources, so went off looking for them on X.org. To my surprise, the packaging for X11R7 is completely different from the packaging for X11R6. It's much more “modular”, which means that you have to download 575 files from ftp://mirror.isp.net.au/pub/x.org/pub/X11R7.0/src/everything/ to get it all. Fired up an ftp and left it, along with a draft of today's diary entry. It wasn't until much later that I discovered that most archives were in two different formats, and I had downloaded both:

-rw-r--r--  1 grog  lemis    89685 Dec 22 06:19 xmodmap-X11R7.0-1.0.0.tar.bz2
-rw-r--r--  1 grog  lemis   105744 Dec 22 06:19 xmodmap-X11R7.0-1.0.0.tar.gz
-rw-r--r--  1 grog  lemis    92055 Dec 22 06:19 xmore-X11R7.0-1.0.1.tar.bz2
-rw-r--r--  1 grog  lemis   109041 Dec 22 06:19 xmore-X11R7.0-1.0.1.tar.gz

Yana back in the evening for a few days.

Just before going to bed, got a message from James Andrewartha pointing out that I hadn't run xhost to allow access from other hosts. Doh! Of course! I do that automatically in my .xinit files, including the one on eucla, but here they don't get accessed.


Saturday, 15 April 2006 Echunga Images for 15 April 2006
Top of page
previous day
next day
last day

Part of my plans for this week were to tidy up the Mike Smith Memorial Room, which involves at least putting in some shelves to store all the junk I have in the work area:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060415/big/workshop.jpeg

Image title: workshop          Dimensions:          2816 x 2112, 1289 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Saturday, 15 April 2006, thumbnails          All images taken on Saturday, 15 April 2006, small
Diary entry for Saturday, 15 April 2006 Complete exposure details

 

I had thought of getting some shelving and a couple of rails to screw to the wall, but was somewhat shocked to discover that a single 90x30 shelf and a couple of brackets would set me back $30. At that price, I could get a professional to build me some real shelves.

Also had a problem with Yvonne's phone: it's one of these silly phones without an on/off switch, and the instruction manual stated to use the “ON” key instead:

getting-started

That worked, but when we closed the phone, it automatically turned on again. Took it in to the shop and asked “can you show me how to turn off this phone?”. The bloke took it, pressed the “OFF” button, and it went off. Grrr! Another indication of how stupid the idea of symbol keys is. The instructions above are in black and white, while the symbols are green (for “ON”) and red (for “OFF”). Without those colours, it's almost impossible to distinguish them. And in addition, you can turn the phone on and off with the “ON” key. Yet another case of inadequate documentation.

Back home, on with my system configuration. As James Andrewartha had predicted, xhost did the trick, and I was able to include eucla in my desktop display. Decided that that would be an appropriate time to power down flame, my ancient SPARCstation 5, probably for the last time, and replace the monitor with an external monitor for eucla (which is a Dell Inspiron 6000 with a display chip which X.org identifies as:

        Driver      "ati"
        VendorName  "ATI Technologies Inc"
        BoardName   "M22 [Radeon Mobility M300]"

Attempts to get the Fedora/GNOME tools to configure the chip as two displays failed. As I had discovered in January, the server (or is it the driver?) has a habit of ignoring the settings, and I ended up with only a single display with the settings the internal panel, which I could move to the external monitor or back again. Spent some time reading the X.org documentation without getting very far. The only documentation is for the ati driver, which looks as if it should be right, but the documentation that claims that it can't handle Radeon chips, and that it automatically loads the Radeon driver instead. The log file shows that this is correct. Where's the documentation for the Radeon driver? I couldn't find it, no more than I could find any useful references to the parameters. Even Google can't find useful references to things like this:

        #Option     "RageTheatreMicrocPath"     # <str>
        #Option     "RageTheatreMicrocType"     # <str>

Sunday, 16 April 2006 Echunga Images for 16 April 2006
Top of page
previous day
next day
last day
Easter Sunday

Brew day today, which kept me busy for most of the day. It's really time that I throw some money at the problem so that I don't spend as much time on it.

Yvonne back in the afternoon with some brightly coloured mushrooms that she found growing under the pines in Kuitpo Forest:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060416/big/mushrooms.jpeg
Image title: mushrooms          Dimensions:          2816 x 2112, 2576 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 16 April 2006, thumbnails          All images taken on Sunday, 16 April 2006, small
Diary entry for Sunday, 16 April 2006 Complete exposure details

 

I thought that they looked poisonous, but Yvonne recalls something like this from her time in France, something like cèpes, which are apparently called cep in English; I know them by other names, such as Steinpilz (German) or porcino (Italian). In the process discovered that it's the Karl Johanssvamp that I've seen mentioned in my Swedish cookbook.

Clearly these aren't cèpes, though they look pretty similar. But there are many mushrooms of the species boletus, most of them very good. Spent a lot of time looking at my three volumes of mushroom books and many places on the web, not at all helped by the fact that the photos differ wildly—see the Wikipedia articles referenced above to see how different the photos of boletus edulis are—but finally was fairly sure that they must be boletus pinophilus, which is unknown enough in English not to be in Wikipedia yet. It's referred to in French (cèpe des pins), Italian (without a common name) German (Kiefernsteinpilz) and Swedish (Rödbrun stensopp).

But is that what they really are? European descriptions of the mushroom don't describe the bright yellow on the underside, apparently called hymenphore:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060416/big/mushroom-3.jpeg
Image title: mushroom 3          Dimensions:          2816 x 2112, 2368 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 16 April 2006, thumbnails          All images taken on Sunday, 16 April 2006, small
Diary entry for Sunday, 16 April 2006 Complete exposure details

 

Some other links confirmed two things: first, yes, there are mushrooms of this name with the bright yellow hymenphore, and secondly it's very unlikely that we'd find something poisonous that looked like that. It seems that the yellow variety occurs in California, and there's a suggestion that it might really be a separate variety. Still, I'd like to be sure that they're edible.


Monday, 17 April 2006 Echunga Images for 17 April 2006
Top of page
previous day
next day
last day

Spent the morning upgrading my scripts for generating photo web pages; in particular, the rendering had been complicated by the lack of dimensions in the img tags. For comparison, here's something from last week:

    <a id="paella-1" name="paella-1" href="Photos-20060409.html#paella-1"><img
    alt="Click on the picture to see a medium-size version in the index"
    src="Photos/20060409/tiny/paella-1.jpeg" /></a>

and something from today:

    <a id="mushrooms" name="mushrooms" href="Photos-20060417.html#mushrooms"><img
    alt="Click on the picture to see a medium-size version in the index"
    src="Photos/20060417/tiny/mushrooms.jpeg" width="282" height="211" /></a>

Also managed to include the EXIF exposure record information from the original JPEG image, using exif, which also required changing the way I create the original images. I used to use xv, but that doesn't save the EXIF information, so used convert from ImageMagick instead.

Finally I have my RSS feed fixed! Georgios from Greece (who doesn't state his family name) sent me a pattern:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<rss version="2.0">
        <channel>
                <title>Greg's diary--Today and yesterday</title>
                <link>http://www.lemis.com/grog/diary.php</link>
                <description>Greg Lehey's online diary, yesterday and today></description>

                <item>
                        <title>title of 1st item goes here</title>
                        <description>
                                <![CDATA[
                                HTML content of 1st item goes here
                                ]]>
                        </description>
                </item>

                <item>
                        <title>title of 2nd item goes here</title>
                        <description>
                                <![CDATA[
                                HTML content of 2nd item goes here
                                ]]>
                        </description>
                </item>

</channel>
</rss>

That works fine, so now all I need to do is handle the question of relative/absolute URLs: in my main diary, they're relative, but that won't work in an RSS feed.

Back to looking at CVR software. Last Sunday I had got to the stage where I couldn't install xawtv on Fedora Core 5: the binary package had a missing dependency on libXm.so.3, and the source didn't build with some missing header files.

Investigated both. For libXm.so.3, the obvious choice was to find a yum repository with the library. It seems, though, that there are no lists of yum repositories—some of the web pages I found even seemed proud of the fact. Found a watch4tv page, which doesn't say so but appears to be a list of instructions to install a TV application on an operating system that uses yum. That was helpful, but didn't get me past the basic problem:

=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 48 -> rpm --import http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt
=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 49 -> rpm --import http://ftp.osuosl.org/pub/centos/RPM-GPG-KEY-CentOS-4
=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 50 -> yum install xawtv
Loading "installonlyn" plugin
...
--> Running transaction check
--> Processing Dependency: libXm.so.3 for package: xawtv
--> Finished Dependency Resolution
Error: Missing Dependency: libXm.so.3 is needed by package xawtv
=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 51 ->

Confirmed that I had a /usr/lib/libXm.so.4, but symlinking that to /usr/lib/libXm.so.3 didn't get me past the problem. Went back to the issue of building from source; further investigation showed that the missing header file belonged to the X font server, and that xawtv, though it uses autoconf, didn't seem to notice that the X libraries were not installed. Installing that made it build and brought instant gratification:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060417/big/screenshot.jpeg

Image title: screenshot          Dimensions:          1600 x 1200, 1312 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Monday, 17 April 2006, thumbnails          All images taken on Monday, 17 April 2006, small
Diary entry for Monday, 17 April 2006

 

That's the TV image in centre left: it's tiny by itself:

 

https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060417/big/tv.jpeg
Image title: tv
Dimensions: 394 x 314, 110 kB
Dimensions of original: 394 x 314, 110 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Monday, 17 April 2006:
thumbnails    small images    diary entry

It is indeed smaller than it should be, only 394x314. That's something to investigate, but the real issue was to get it to run on ceeveear. That didn't work as well:

=== grog@ceeveear (/dev/pts/11) ~ 3 -> DISPLAY=:0 xawtv
This is xawtv-3.95, running on Linux/i686 (2.6.16-1.2080_FC5)
/dev/video0 [v4l2]: ioctl VIDIOC_G_FBUF: Invalid argument
v4l-conf had some trouble, trying to continue anyway
ioctl: VIDIOC_G_FBUF(capability=0x0 [];flags=0x0 [];base=(nil);fmt.width=0;fmt.height=0;fmt.pixelformat=0x00000000 [....];fmt.field=ANY;fmt.bytesperline=0;fmt.sizeimage=0;fmt.colorspace=unknown;fmt.priv=0): Invalid argument

That looks like a problem with the X configuration; maybe the HOWTOs will help there. Also the program scantv that I used last week under Ubuntu is no longer built by default; the sources are there, but when I try to compile them, I get lots of errors. More stuff to investigate. This whole exercise reminds me of when I was writing Porting UNIX Software well over ten years ago. Why do these problems still exist?

Yvonne back with more mushrooms today, along with the information that she had met some Polish women in the forest who were gathering large quantities. They offered to tell her the name in Polish, but she didn't bother. I sent a message out to an internal MySQL list and got answers from Mårten Mickos and Boel Larsen, who both apparently eat them and tell me, as did Alexander Keremidarski, that they're not boletus pinophilus, but suillus luteus, called smörsopp in Swedish and maslovka in Bulgarian (also Butterpilz in German), all of which mean the same thing (butter mushroom). Certainly the photo looks convincing enough:

https://upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Suilloid2.jpg/120px-Suilloid2.jpg

(September 2016): The original image disappeared, but this seems to be the same image. It no longer seems appropriate, since it claims to be of “Suillus I”, possibly Suillus intermedius, and it doesn't look very similar. It also seems that I'm not the only person who is uncertain: it appears in the list of unidentified Suillus.

They need peeling, apparently, and there are some indications of people who get stomach upsets from them, possibly only if the skin is not removed.


Tuesday, 18 April 2006 Echunga
Top of page
previous day
next day
last day

Today continued my attempts to install MythTV. First continued with xawtv, though, and looked for scantv, which I have used before. It wasn't there. There's no target for scantv in the top-level directory, but there's a file console/scantv.c that won't compile in that directory:

=== root@ceeveear (/dev/pts/1) /usr/src/ports/xawtv-3.95/console 14 -> make scantv
cc     scantv.c   -o scantv
scantv.c:5:20: error: config.h: No such file or directory
scantv.c:19:25: error: frequencies.h: No such file or directory
(etc)

Presumably config.h was in the top-level directory, so tried it there; it got a bit further:

=== root@ceeveear (/dev/pts/1) /usr/src/ports/xawtv-3.95 16 -> make console/scantv
  CC      console/scantv.o
console/scantv.c:47: warning: 'struct vbi_event' declared inside parameter list
console/scantv.c:47: warning: its scope is only this definition or declaration, which is probably not what you want

With a bit of investigation (including far too much guesswork), established that this related to libzvbi, and that the corresponding package was called zvbi. Installed that and zvbi-devel, but scantv still didn't compile. It looked as if the header files weren't being found; but which header files? Spent some time trying to get yum to tell me which files were associated with the packages that were installed (something like FreeBSD's pkg_info -f), but that doesn't seem to exist. It was also strange that scantv.c didn't complain about missing header files. Then it dawned on me: configure was run without the libraries being present, so it decided not to build the programs. Re-ran configure and all got built.

Next was the problem with saving the config file. I had already discovered that scantv writes its output to stdout; but what's the real config file called? xatwv(1) refers to the file several times, but refuses to divulge its name. That's in xawtvrc(1): it's called ~/.xawtv, a funny name considering the name of its man page.

Finally moved on to lirc, the Linux Infrared Remote Control software. That was a new level of incomplete, inaccurate, incorrect and confusing documentation. According to one page, I should try irrecord to find out what the control said. That resulted in:

=== root@ceeveear (/dev/pts/0) ~ 219 -> irrecord foo

irrecord -  application for recording IR-codes for usage with lirc

Copyright (C) 1998,1999 Christoph Bartelmus(lirc@bartelmus.de)

irrecord: could not init hardware (lircd running ? --> close it, check permissions)

Well, lircd wasn't running, so I tried strace:

=== root@ceeveear (/dev/pts/0) ~ 220 -> strace irrecord foo 2>&1 | less
open("/dev/lirc", O_RDWR)               = -1 ENODEV (No such device)

What kind of programming is that? It doesn't even check the return value from open! Of course, I don't have the source, so I can't do the obvious two-line fix, and getting it is liable to cause other problems.

In the middle of this, ran into another problem: the dreaded NFS hangs, this time between ceeveear and wantadilla. I had to reboot ceeveear to get out of it, and then X wouldn't start: the font server kept crashing. strace didn't show anything of interest, so modified the X configuration to load the fonts directly (why are they stored in /usr/share/X11/fonts and not in the usual /usr/X11R6/lib/X11/fonts? Is this a change that came with X11R7?).

After starting X again, discovered that I also no longer had a window manager. That was GNOME anyway, something I don't need, so changed the init level to 3 and started fvwm2 manually, the way I'm used to do it.

Then continued for a while, discovering that my tuner card (MSI “TV@nywhere Master”—where do they get these names from?) probably required a kernel module (I was left to guess which one), and that lircd require a “driver” (again, though there's an entry for my remote control, there's no information about which driver to use). Finally went through with a brute force search and found that a number of them worked, including at least bte and dsp. Of course, they only understood some of the keys; for tomorrow I need to investigate how to decipher the keys.

For the fun of it, tried to run xawtv again. The results were startling: the X server crashed with a SIGSEGV and a backtrace:

Backtrace:
0: X(xf86SigHandler+0x87) [0x80b86c7]
1: [0x675420]
2: [0x5]
3: /usr/X11R6/lib/libXfont.so.1 [0x14e9ed]
4: /usr/X11R6/lib/libXfont.so.1(FontFileListNextFontWithInfo+0x747) [0x121ecb]
5: X(doListFontsWithInfo+0x24c) [0x808b5fc]
6: X(StartListFontsWithInfo+0x145) [0x808bbd5]
7: X(ProcListFontsWithInfo+0x6b) [0x808705b]
8: X(Dispatch+0x19b) [0x80888eb]
9: X(main+0x487) [0x80701d7]
10: /lib/libc.so.6(__libc_start_main+0xdc) [0x6a87e4]
11: X(FontFileCompleteXLFD+0xb1) [0x806f511]

I wonder if the NFS crash somehow ended up corrupting some of the font files. I've never seen that on FreeBSD, but I've heard of it on Linux, and recently I've been experiencing lots of things I have never seen before. The overall fragility of this system is horrifying, a far cry from the claims of absolute stability that the die-hard “Open Source” advocates make.

New credit cards arrived today. ANZ Bank has thought of something special: the cards must first be “activated”. To do that you call a toll-free number and specify:

  1. Your card number.

  2. Your date of birth.

  3. Your credit limit.

The rationale for this choice of information is that it can all be entered via a touch-tone phone. But what nonsense! None of this is particularly confidential information. I also don't know my credit limit. The people who wrote the software didn't cater for that: there was no way to divert to a human. I had to call a different number, where they were able to do it after I specified my password (something that at least isn't known elsewhere). They didn't want to know my credit limit, and I still don't know it.

Software flakiness appears not to come alone. Diane Saunders had seen Yvonne's new phone, and liked it so much that she went out and bought one herself. It's interesting to notice that, though it only has basic functionality, it is selling very well. I wonder how well the marketeers have evaluated the market when they bring out more and more phones with flaky software and unneeded features (do people over the age of 12 really play the games which are on every phone, even these cheap ones?).

Diane had to activate her prepaid SIM card. Calling the number gave her—this horrible, horrible voice menu system which Telstra insists on foisting on its customers, and which never understands anything (“Sorry, did you want to buy a frog?”). Fortunately, there was also a URL for doing the same thing. That was painful enough; yet another badly programmed application that insisted on a post code and then went to check it; it wouldn't volunteer the information. Where we live, we don't have postal delivery, so the concept of a post code is meaningless. But they insisted on one, and it had to be right. They also needed a house number, which neither Diane nor we have. Somebody should ban these programmers to the outback for a month or two so they understand the environment for which they are programming. In the end, Diane changed her town from “Meadows” to “Echunga” (she lives between the two), because we knew the post code for Echunga. The software accepted that.


Wednesday, 19 April 2006 Echunga Images for 19 April 2006
Top of page
previous day
next day
last day

Into the office early this morning with the intention of re-installing X from source. I had already noted that the build process had changed significantly between X11R6.9 and X11R7, so off to the X.org web site to look for the build instructions. That was well structured: “Current Release”—>“Build Directions”. What did I get? “Building the X Window System from the X.Org Monolithic Source Distribution”. At least currently, they have the wrong document on the web site. It's not just the title: the instructions really refer to X11R6.9.

Tried yum instead, but it seems to have decided not to work any more:

Setting up repositories
atrpms                                                               [1/9]
http://dl.atrpms.net/fc5-i386/atrpms/stable/repodata/repomd.xml: [Errno 12] Timeout: <urlopen error timed out>
Trying other mirror.
Cannot open/read repomd.xml file for repository: atrpms
failure: repodata/repomd.xml from atrpms: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from atrpms: [Errno 256] No more mirrors to try.

That really does look like a problem with the repo, though eucla was able to access it; removing it from the list allowed yum to continue (why didn't it anyway? I had 8 other repos to look at). It does this even if I specify the -t option (“be tolerant of errors”).

Tried more stuff with lirc, but it didn't behave as described in the “manual” (not the man pages; that would be too simple. Instead it's on the web). After several readings of this document, I still don't know what to do.

Finally downloaded the source, which also required the kernel sources. ./configure was a surprise: I got a menu asking me which tuner card to compile for (and of course my TV@nywhere wasn't on the list). Somehow it's possible to generate the programs with all “drivers”, but it's not made clear how. It's also full of references to other documentation, which in turn leads on to yet other documents, none of which seem relevant. After following the instructions, I ended up with the Makefile configured only for a serial connection. After a lot of investigation, I found:

  1. The FAQ states:

    1. Which kernel module do I have to load for my hardware?

    The documentation contains a detailed list how to setup the various devices supported by LIRC.

  2. That list does nothing of the sort. Instead, it specifies pretty much the same information that the configure menu does. If your card isn't on the list, it's useless.

  3. Somehow I then found my way to the installation instructions at http://www.lirc.org/html/install.html#compiling, which state:

    See ./configure --help for a detailed description of the possible parameters. You will have to at least choose a driver with the --with-driver=X option.

    That worked: ./configure finished with the message

    All kernel modules will be built.
    Of course, it didn't compile:
    /usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.c:1183: error: unknown field 'owner' specified in initializer
    /usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.c:1183: warning: initialization from incompatible pointer type
    make[5]: *** [/usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.o] Error 1

Round about here something strange occurred to me: the system was responding to the IRC control even when there was no lirc program running! Further investigation showed that there was a kernel module ir_common, and trawling the kernel sources showed that the driver does indeed understand the remote control interface; found some useful information at LinuxTV.org, which enabled me to—finally!— configure the thing.

The next step was easy: install MySQL. Including setting up the MythTV databases, it took about a minute. The next step, mythtvsetup, looked complicated enough that I decided that it would be better to put it off until tomorrow.

Finally ate some of the mushrooms in the evening. Pleasant enough, but nothing spectacularly good. Maybe you have to be a mushroom fanatic.


Thursday, 20 April 2006 Echunga
Top of page
previous day
next day
last day

In to Echunga for a haircut today. What terrible weather we've been having! This time last year it was as dry as a bone, and people were predicting droughts through the winter. That didn't happen, but this year seems to be trying to make up for it. The water tank is already almost full.

On with the pain that is MythTV. Started writing a HOWTO so that I'll find my way better next time. That might be sooner than I expect: I got as far as the step Run mythtvsetup. It's not a very clever program:

Setup finally ground to a halt with the message: Could not open '/dev/viso0' to probe its inputs. Stopped it to run strace, and saw, amongst other irrelevant messages:

=== mythtv@ceeveear (/dev/pts/2) ~ 3 -> mythtvsetup
mythtv: could not open config file /home/mythtv/.mythtv/lircrc
mythtv: No such file or directory
Failed to read lirc config /home/mythtv/.mythtv/lircrc for mythtv
2006-04-20 13:17:48.215 Joystick disabled.
2006-04-20 13:23:51.491 DB Error (simpledbstorage update):
Query was:

No error type from QSqlError?  Strange...
2006-04-20 13:27:35.911 RecordFilePrefix is not set?

I wonder what all that means. It's the first I've seen of a ~/.mythtv/lircrc.

Running strace showed what you might expect:

open("/dev/video0", O_RDWR|O_LARGEFILE) = -1 EACCES (Permission denied)

I feel like screaming! Why can't people report errors any more? But even after I fixed the permissions on all likely devices, mythtvsetup could not access the card. Tried to run xawtv again. It still crashes the local X server, though (modulo network speed) it works fine on wantadilla. Discovered that even on wantadilla, xawtv didn't work for user mythtv; it just displayed noise. Copying ~grog/.xawtv to ~mythtv helped, but only after an explicit channel change. This software is so buggy!

Decided to test my installation instructions and possibly get rid of some crashes by installing Fedora Core 5 again on a new (well, very old, but overwriteable) disk. In the process, various niggles became apparent:

While waiting for that, also downloaded a CD with the of KnoppMyth, which doesn't make it easy. Most of these documents look really confused, and neither the home page nor the FAQ delivered an obvious answer to the obvious question: where can I get it from? The answer is in http://mysettopbox.tv/knoppmyth.html, starting with the line “R5B7 is available from:”; that's the name of the latest version, spelt differently from the previous time it was mentioned.

KnoppMyth states at several occasions on the way that it's experimental beta software; most versions of Knoppix (from which it is derived) do something similar. In each case, they're wrong; Knoppix is surprisingly stable and, bar the horrible eye candy, not at all a bad installation. KnoppMyth is barely alpha quality. The installation scripts forgot the passwords I entered and chopped the first characters off each IP address. They then put me back in the same position I was earlier in the day; the only advantage was that failure came more quickly.

Very frustrated, gave it up for the day. This is not merely a question of compatibility, as some people say; it's a question of really badly written software. Not checking system call return values is a sure course for disaster.


Friday, 21 April 2006 Echunga Images for 21 April 2006
Top of page
previous day
next day
last day

On trying to debug ceeveear today. There's definitely something wrong with the installation for Fedora Core 5: I went to some trouble to specify that the X11 sources should be installed, but they weren't. Emacs was also missing, but it's possible that the packager is a vi bigot and left Emacs out of the default editor installation.

Finally got it installed, along with all the bits and pieces needed to build xawtv. It didn't crash the X server, but it did the same thing as KnoppMyth—blank screen and lots of ioctl error messages:

ioctl: VIDIOC_TRY_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=21;fmt.win.w.top=53;fmt.win.w.widt
h=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.w
in.clipcount=0;fmt.win.bitmap=(nil)): Invalid argument
ioctl: VIDIOC_S_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=21;fmt.win.w.top=53;fmt.win.w.width=
384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.win
.clipcount=0;fmt.win.bitmap=(nil)): Invalid argument
ioctl: VIDIOC_OVERLAY(int=0): Invalid argument

It did this at each attempt to change channel; paradoxically, though there was no image in the main window, it displayed an image in the channel window, suggesting that there's some issue with the phone.

That left the question why the X server crashed before. Installed the new, corrected xorg.conf file and the new driver and—it crashed! So it wasn't something I did with the installation on the “old” version of ceeveear.

In the meantime I had downloaded a CD of FreeBSD 6.1-RC1, so installed that on a spare partition, in the process finding out again how to boot FreeBSD from grub:

title FreeBSD 6.1-RC1
        root (hd0,0,a)
        kernel /boot/loader

The important thing to remember here is that “hd0, 0, a” corresponds to the FreeBSD name ad0s1a; the BIOS partition numbers are off by 1. This isn't what Fedora puts in by default, and it had caused me problems booting eucla, my laptop.

It ran (of course), but didn't detect the tuner, as I expected, so I still need to continue with Linux.

Rebooted the “old” ceeveear and played around with xorg.config. The old one didn't work at all, of course, because it relied on xfs (font server; what a confusing name), which kept crashing. After much trial and error, discovered that the crashes occurred only when Type 1 fonts were used, this entry:

        FontPath   "/usr/share/X11/fonts/Type1/"

Without that, it ran fine and displayed the same ioctl problems as KnoppMyth and the “new” Fedora installation. So it looks like it's a display card problem. Spent some time investigating that, without coming to a conclusion.

Funnily, there seem to be multiple issues with xawtv. It continues to run across the network on echunga and wantadilla, my main machines in the office; but it won't run on teevee, the machine that (currently) drives the projector, also a FreeBSD machine. Another thing that I don't understand.

Into town and bought some metal shelves for the workshop area. They're not as pretty as what I had been looking at, but cost less than a quarter of the price:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060421/big/workshop-2.jpeg

Image title: workshop 2          Dimensions:          2112 x 2816, 793 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Friday, 21 April 2006, thumbnails          All images taken on Friday, 21 April 2006, small
Diary entry for Friday, 21 April 2006 Complete exposure details

 

More shelves to come.


Saturday, 22 April 2006 Echunga
Top of page
previous day
next day
last day

Spent more time searching for the ioctl errors that had been annoying me yesterday, and got quite a few results on Google. Many reported the bug and got no solution. Some reported fixes that were really workarounds (use a different tuner card, for example). Michael Krufky reported that it was a kernel bug in Linux 2.6.15-rc2 and before; unfortunately, I'm still getting it in kernel 2.6.16. Finally, Hermann Pitton came up with a plausible explanation: the driver doesn't support overlay with PCI/PCI transfers to the graphics card. That would explain why it only happened when displaying on the same machine. But why can't there be a better error message?

Hermann recommended to use xawtv grabdisplay and referred to a file called README.cx88 without saying where to find it. It wasn't on ceeveear, and it's not in the xawtv distribution; nor is there more than a passing reference to it in the documentation. More googling suggested that it's in the Linux kernel sources, and indeed I found it there on echunga. But there's no mention of grabdisplay in that file, just the comment “For now only capture, overlay support isn't completed yet.”.

Found a reference to a program called tvtime, and installed that. Oh wonder! It just worked. Well, I had to read through the config file that was supplied, and it got a bit confused about the channel numbers, but it worked, modulo sound, which doesn't seem to be an tvtime problem: it doesn't work at all yet. About the only thing wrong with it is that it only displays TV. If only more software were of this quality.

Spent some time investigating the sound issue. According to man -k, there isn't much choice in mixer software:

=== root@ceeveear (/dev/pts/3) ~ 46 -> man -k mixer
alsamixer            (1)  - soundcard mixer for ALSA soundcard driver, with ncurses interface
alsamixergui        (rpm) - GUI mixer for ALSA sound devices
amixer               (1)  - command-line mixer for ALSA soundcard driver
dump-mixers          (1)  - dump OSS mixer settings to standard output

I suppose there's more, but how do you find it? They could at least have extended man to show what other documentation is available.

Running alsamixer brought a message that I've seen before:

=== grog@ceeveear (/dev/pts/6) ~ 6 -> alsamixer
alsamixer: function snd_ctl_open failed for default: No such device

What device? Are people deliberately trying to make it more difficult? strace revealed:

access("/home/grog/.asoundrc", R_OK)    = -1 ENOENT (No such file or directory)
open("/dev/snd/controlC0", O_RDONLY)    = -1 EACCES (Permission denied)
open("/dev/aloadC0", O_RDONLY)          = -1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f69000
write(2, "alsamixer: function snd_ctl_open"..., 68alsamixer: function snd_ctl_open failed for default: No such device
, "1") = 68

After fixing the permissions, it seemed to work, but it wasn't very easy to understand. Tried the HELP menu, which told me:

Return  return to main screen

That doesn't work, so I of the help menu. tried ESC. That got me out quickly:

=== grog@ceeveear (/dev/pts/5) ~ 2 -> alsamixergui &
[2] 5465
=== grog@ceeveear (/dev/pts/5) ~ 3 ->
Segmentation fault.

I think I'm going to modify that message from bash to

Segmentation fault (too lame to dump core).

By default, a SIGSEGV creates a core image; if it doesn't, it's because the program has explicitly decided not to. Considering that much of this software is of early alpha quality, this just makes it even more difficult to debug. Decided to read the documentation again before doing anything else, and returned to trying mythtvsetup again.

After 5 minutes of swearing at the completely broken interface (right arrow moves left, left arrow moves right, cursor not visible), gave up and looked for a simpler way, like writing a program to do it or encoding it in hex. I didn't find one, so here's a list of things to remember:

Round about this point, my cousin Sandy and her husband Dean showed up. They live just down the road, but we haven't seen them since December 2004. I suppose we should stay in better contact. At least it gave me a chance to get away from this multimedia frustration.

In parallel with the other work, started downloading the latest (DVD) version of Knoppix from the Internode mirror server; contrary to my normal use of command lines, I this time allowed firefox to do it. That always annoys me, because firefox is just completely stupid about path names; it started downloading to Desktop, which on this machine proved to equate to /var/tmp. There was enough space there, so I let it go. Some hours later I found it had stopped:

=== grog@echunga (/dev/ttypl) /var/tmp 57 -> l KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso
-rw-r--r--  1 grog  wheel  2147483647 Apr 22 15:07 KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso

That wasn't the real size, of course; the download had stopped at the 2 GB limit. Grr. And because I was loading from a web server, I couldn't use REGET. Looked around on the web and found alternatives, and started that transfer, somewhat slower (50 kB/s instead of 150 kB/s).

Read in this week's “Mount Barker Courier”: “Under the legislation, anyone wishing to remove or lop a tree of more than 2 metres in circumference (any species except weeds) must apply for council approval”.


Sunday, 23 April 2006 Echunga Images for 23 April 2006
Top of page
previous day
next day
last day

Came into the office to discover that my Knoppix download was still going:

ftp> reget KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso
local: KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso remote: KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso
229 Entering Extended Passive Mode (|||61749|)
350 Restart position accepted (2147483647).
150 Opening BINARY mode data connection for KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso (3344640000 bytes).
 91% |**********************************************************************       |  2918 MB   13.16 KB/s  5:51:43 ETA

That's nearly 24 hours. Network transfer speeds may have increased, but so have download volumes. Did some investigation and discovered that the Internode mirror server also has an ftp interface, so finished off the transfer from there.

Today was the last day of a ten day period during which I had intended to do a number of things; just about all of it was spent fighting Linux multimedia, and I'm still far from finished. The current biggest problems are:

In any case, I didn't have any time to do any more on the subject. Spent most of the day tidying up my office, which at least showed some progress. I had intended to go riding, but for once Yvonne didn't feel like it. In the late afternoon to Kuitpo forest to look for more mushrooms, and found a number of other kinds:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/yvonne-muscaria-2.jpeg
Image title: yvonne muscaria 2          Dimensions:          2112 x 2816, 672 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-5.jpeg
Image title: mushroom 5          Dimensions:          2816 x 2112, 576 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-6.jpeg
Image title: mushroom 6          Dimensions:          2816 x 2112, 560 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-11.jpeg
Image title: mushroom 11          Dimensions:          2816 x 2112, 480 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-12.jpeg
Image title: mushroom 12          Dimensions:          2816 x 2112, 1296 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-14.jpeg
Image title: mushroom 14          Dimensions:          2816 x 2112, 688 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-15.jpeg
Image title: mushroom 15          Dimensions:          2816 x 2112, 544 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060423/big/mushroom-16.jpeg
Image title: mushroom 16          Dimensions:          2816 x 2112, 448 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 23 April 2006, thumbnails          All images taken on Sunday, 23 April 2006, small
Diary entry for Sunday, 23 April 2006 Complete exposure details

 

Brought them back home and tried to identify them, with little success.


Monday, 24 April 2006 Echunga
Top of page
previous day
next day
last day

Back to work today, starting with 3200 mail messages to handle. Fortunately, I had done the important ones during my holiday, and managed to get them down to quite reasonably proportions relatively quickly.

Apart from that, spent the day looking at bugs. I really need to learn more about the test suite.

One of the things that I didn't manage to get done during my holiday was to attach eucla, my Dell Inspiron 6000 machine, to a monitor to replace flame. That looks like it will still be a lot of work, so brought back sydney (a now very flaky Inspiron 7500) out of retirement. It still runs, but it's not a good example of Dell reliability. It's not quite 6 years old, and it has been through two sets of batteries, a power supply and a combined floppy CD-ROM drive, and now has a flaky keyboard (CAPS LOCK sticks). On powering it up, discovered that the disk is also dying. This compares to mojave, a Latitude CP+ that is now 8 years old and has none of these problems.

Getting sydney to run was not completely straightforward; it proved impossible to complete fsck on the /home partition, so mounted it read-only. That went fine until I had to reboot it, after which one of the keys on the keyboard stuck, and I couldn't start X (“please release Ctrl-L”). And I couldn't change the keyboard mapping because the file system was read-only. What a pain.


Tuesday, 25 April 2006 Echunga Images for 25 April 2006
Top of page
previous day
next day
last day
ANZAC day

Another holiday today, so spent more time torturing myself with multimedia setup. A package that I haven't tried so far is VLC, so set to trying that out. Found a detailed (and somewhat opinionated) description by Brent Norris, which required a complete kernel upgrade. That didn't go well. Once again dl.atrpms.net was not accessible. It's a real pain that you can't tell yum to ignore it; it causes the entire update to fail, even if you tell it to tolerate errors. I had to move the file away (yes, I know you can also disable it, but it's easier and less error prone to move it). Even then, I got messages like this:

--> Running transaction check
--> Processing Dependency: libgif.so.4 for package: libgdiplus
--> Processing Dependency: libgif.so.4 for package: emacs
--> Processing Dependency: libgif.so.4 for package: gfontview
--> Finished Dependency Resolution
Error: Missing Dependency: libgif.so.4 is needed by package libgdiplus
Error: Missing Dependency: libgif.so.4 is needed by package emacs
Error: Missing Dependency: libgif.so.4 is needed by package gfontview

But Emacs was installed, for example, and so was libgif.so.4. While experimenting, removed Emacs:

=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 64 -> yum remove emacs
...
  Removing  : emacs                        ######################### [1/1]
Removed: emacs.i386 0:21.4-14
Complete!
=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 65 -> yum install emacs
...
Installing:
 emacs                   i386       21.4-14          core              1.6 M
...
Installed: emacs.i386 0:21.4-14
Complete!

Then, later, it happens again:

...
--> Finished Dependency Resolution
Error: Missing Dependency: libgif.so.4 is needed by package libgdiplus
Error: Missing Dependency: libgif.so.4 is needed by package emacs
Error: Missing Dependency: libgif.so.4 is needed by package gfontview

There's obviously something very wrong here, but it's not clear what I can do about it. Later I got, after downloading 230 MB of packages:

(162/165): firefox-1.5.0.  100% |=========================|  17 MB    02:42
(163/165): mythvideo-0.19 100% |=========================| 470 kB    00:04
(164/165): libksba-0.9.13 100% |=========================| 2.2 kB    00:00
(165/165): mythweb-0.19-7 100% |=========================| 602 kB    00:05
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
[('installing package firefox-1.5.0.2-1.2.fc5 needs 17MB on the / filesystem', (9, '/', 17469440L)),
('installing package mythweb-0.19-74.at needs 17MB on the / filesystem', (9, '/', 17485824L))]

No idea what that is. Checked things, but it wasn't obvious:

=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 71 -> echo $?
1
=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 73 -> df
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/hda2                 5540      4865       389  93% /
tmpfs                      506         0       506   0% /dev/shm
/dev/hda1                 5629      2487      2856  47% /ubuntu
/dev/hda4               175495      9212    157369   6% /spool

So it wasn't a lack of space. The annoying thing is that yum appears to insist on downloading every package every time; presumably they're already on the system. With 230 MB at a time, it takes a while, and it could become expensive. Ended up installing some of the larger packages individually; I think in future I'll always do it that way.

That still didn't help too much, of course, since dl.atrpms.net was still not accessible. Tried some other things and with a lot of effort more or less got mplayer to display on the screen, something that tvtime had done out of the box.

=== grog@ceeveear (/dev/pts/1) ~ 3 -> mplayer -tv driver=v4l2:normid=2:width=960:height=720:chanlist=australia:\
channels=2-ABC,7-Seven,9-Nine,10-Ten,28-SBS:outfmt=yuy2:brightness=70:saturation=90:hue=50  -vo x11 tv://5

Unfortunately, getting the companion mencoder to make MPEG files out of that didn't work: mplayer claimed that the result was not a valid MPEG stream. What a crock!

One thing that all programs agreed on was that there was no audio. I wasn't sure that there wasn't something wrong with the motherboard, so tried setting up audio under FreeBSD on wantadilla, which has the same kind of motherboard. That worked fine. Tried booting ceeveear with the FreeBSD image I installed a couple of days ago, which required rewriting the /etc/fstab file, since it was now on disk /dev/ad1 instead of /dev/ad0. That failed: the loader prompt for the new root file system wouldn't accept keyboard input. Couldn't find my FreeSBIE CD-ROM, so decided to burn a new one. That failed on eucla, apparently because I had been playing an audio CD on it earlier. For some reason, teevee refuses to burn CDs at the moment, so put it on a DVD+RW. After that, got ceeveear up running FreeBSD, installed mpg123 and confirmed that the sound was really dead. Damn. Do I buy a new motherboard (considering that this one may be flaky anyway) or do I buy a sound card? And if I buy a new motherboard, should it be i386 or amd64? More decisions to make.

Those weren't the only frustrations of the day. Opened up the beer fridge and found tell-tale brown liquid in the bottom: somehow the thermostat had jammed again. Damn. Time to rewrite my temperature control software to handle multiple contexts.

While tidying up, found a letter about the AVIS fiasco: the bank had got some feedback (I still have none): allegedly the windscreen was broken. Nobody wants to do a further refund; looks like I'll have to take legal action.

Cooked on the barbecue in the evening. I suppose it was a fitting end to a frustrating day that the gas cylinder ran out.


Wednesday, 26 April 2006 Echunga
Top of page
previous day
next day
last day

The painters finally arrived to do the screen on the lounge room wall today, nearly 9 months after I started. Things are gradually looking a little tidier.

Back to bug resolution, and made some progress. With BUG#17248 I had managed to excise too much, so spent a bit of time trying to work out how to avoid that kind of error. One approach would be to check the output of the SHOW VARIABLES command, but that included too much environment-dependent stuff. Put it into the “too hard” basket.

Apart from that, spent some time looking at BUG#17201, in the process discovering that mysqldump is a pretty straightforward program. Testing it isn't so straightforward: under some circumstances that I haven't quite understood, the file client/mysqldump is not an executable, but a shell script, so I couldn't run gdb against it. Instead modified it to explicitly start gdb against the real program, client/.libs/mysqldump. That didn't last long, of course: on the next build, it was replaced. So called it client/mysqldump.sh instead. The important change is:

--- mysqldump   2006-04-26 17:22:01.000000000 +0930
+++ mysqldump.sh        2006-04-26 17:06:40.000000000 +0930
@@ -102,7 +102,7 @@
     if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
       # Run the actual program with our arguments.

-      exec "$progdir/$program" ${1+"$@"}
+      exec gdb "$progdir/$program" ${1+"$@"}

       $echo "$0: cannot exec $program ${1+"$@"}"
       exit 1

Then created a local mysql-test/.gdbinit, which enabled me to test with relative ease. The real question on this bug is what the correct output is; it seems that there's a lot wrong, and I need to talk to somebody with more experience in using mysqldump.


Thursday, 27 April 2006 Echunga
Top of page
previous day
next day
last day

Up early for a scheduled phone call, which didn't eventuate. I'm not at my best early in the morning anyway, but the fact that there's no clean way to cancel a call that early makes it even more of a problem. Technology is powerless against two insoluble problems: time zones and the speed of light. Access to the MySQL cluster in Uppsala takes me about 370 ms; the actual round-trip distance (via the USA) is about 60,000 km, which at the speed of light would take 200 ms, so there's not much room for improvement:

=== grog@echunga (/dev/ttypb) ~ 3 -> traceroute -q 1 www.mysql.com
traceroute to www.mysql.com (213.115.162.29), 64 hops max, 40 byte packets
 1  lemis-gw.sa.adsl.internode.on.net (150.101.14.9)  16.702 ms
 2  172.31.172.38 (172.31.172.38)  15.791 ms
 3  atm2-0-53.lns2.adl2.internode.on.net (150.101.225.138)  54.849 ms
 4  gi0-2-8.cor1.adl2.internode.on.net (203.16.212.161)  17.323 ms
 5  gi0-2.bdr2.adl2.internode.on.net (203.16.215.35)  15.653 ms
 6  pos2-0.bdr1.syd7.agile.on.net (203.16.212.33)  205.912 ms
 7  pos2-0.bdr1.sjc2.agile.on.net (203.16.213.41)  204.222 ms
 8  490.ge-6-0-0.mpr1.sjc7.us.above.net (64.124.57.154)  204.561 ms
 9  so-5-0-0.mpr4.sjc2.us.above.net (64.125.30.178)  204.730 ms
10  so-4-3-0.mpr1.lax9.us.above.net (64.125.27.6)  216.306 ms
11  so-3-0-0.mpr2.lax9.us.above.net (64.125.31.102)  220.914 ms
12  so-3-0-0.mpr1.iah1.us.above.net (64.125.29.102)  244.125 ms
13  so-0-0-0.mpr2.iah1.us.above.net (64.125.31.62)  244.492 ms
14  so-5-1-0.mpr1.atl6.us.above.net (64.125.29.61)  262.321 ms
15  so-0-0-0.mpr2.atl6.us.above.net (64.125.27.50)  271.189 ms
16  so-6-1-0.cr1.dca2.us.above.net (64.125.28.229)  270.468 ms
17  so-2-0-0.cr1.lhr3.uk.above.net (64.125.27.58)  357.561 ms
18  64.125.27.221.available.above.net (64.125.27.221)  352.435 ms
19  PNI.Bredband.ams1.nl.above.net (82.98.247.6)  379.944 ms
20  pos11-0.cr2.sto2.se.bredband.com (195.54.123.149)  376.890 ms
21  ge6-0-0.cr1.sto1.se.bredband.com (195.54.123.162)  378.661 ms
22  tenge9-1.cr2.sto3.se.bredband.com (195.54.114.246)  378.344 ms
23  ge6-8.dr2.upp1.se.bredband.com (195.54.115.150)  378.201 ms
24  static-213-115-248-140.sme.bredbandsbolaget.se (213.115.248.140)  378.584 ms
25  wwwb1.mysql.com (213.115.162.29)  378.126 ms

Spent all day working on bugs, and have now broken the back of a number of them:

Tomorrow our quarterly tax returns are due. For years I've been keeping my tax records in straight text files and processing them with awk; today I finally took the plunge and started to change them to a MySQL database. It's about time I used the software I work on. The change went relatively well from a technical standpoint, though I still need to decide on the table formats.


Friday, 28 April 2006 Echunga
Top of page
previous day
next day
last day

Came into the laundry this morning and noticed a smell of beer. The thermostat on my new fridge had jammed again and caused several bottles to freeze. Grrr. It's time to replace the whole damned thing with a computer-controlled system.

As planned, took a break from bug fixes—a number are waiting for review anyway—and spent today working on online backup. Somehow the documentation is really painful.

I've been using ircII for a long time mainly because of the command line editing. Recently I started using xchat instead, but I've had Emacs bindings wired into my fingers for over 25 years, and getting used to something other than c-f to move the cursor to the right takes a lot of doing (expecially since I'm still using bash and Emacs, and even the mysql client uses readline and thus presents the same bindings). On IRC, Jim Winstead came up with the obvious solution: an Emacs IRC client:

*   groggy curses xchat.
<groggy> Is there any way to get xchat to understand the same control characters as, say, bash?
<groggy> i.e.  Emacs bindings without trying to be clever?
<chad|away>  groggy, Not likely.  If it used readline, then probably, but mine (at
         least) isn't linked with readline.
<groggy> chad|away: I'd look at that the other way round.  If it were linked with readline,
         I wouldn't have that problem.
<groggy> chad|away: But you can still have Emacs bindings without readline.
*   jimw is surprised there isn't an irc client for emacs.
<jimw>   http://www.zenirc.org/
<jimw>   http://delysid.org/emacs/erc.html
<groggy> jimw: Thanks.
<groggy> jimw: I knew about zenirc; I used it many years ago.  It's strange.
<groggy> jimw: I'll try erc.

In fact, saying that http://www.zenirc.org/ is strange is probably a slight understatement. Downloaded the tarball and discovered it hadn't changed since 1998, so gave up and downloaded http://delysid.org/emacs/erc.html instead. That looks like it might have potential; I haven't had time to read the documentation, and currently it's not configured the way I like. In particular, it takes input from the channel buffer by default; I'd much rather see it come from the minibuffer.


Saturday, 29 April 2006 Echunga
Top of page
previous day
next day
last day

Quiet day. Bottled some beer, did some work around the household, and that was about all. Yana arrived in the afternoon, but we didn't do much.


Sunday, 30 April 2006 Echunga Images for 30 April 2006
Top of page
previous day
next day
last day

Another day with little to show for it. Brewed some beer and spoke at length with Yana, who is currently both studying at the University of Adelaide and doing a course in commercial photography. Looks like she has some work ahead of her.

Still more mushrooms in the garden:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060430/big/mushroom-1.jpeg

Image title: mushroom 1          Dimensions:          2816 x 2112, 608 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Sunday, 30 April 2006, thumbnails          All images taken on Sunday, 30 April 2006, small
Diary entry for Sunday, 30 April 2006 Complete exposure details

 

I'm not at all sure that these ones are safe to eat; much more research required.


Do you have a comment about something I have written? This is a diary, not a “blog”, and there is deliberately no provision for directly adding comments. It's also not a vehicle for third-party content. But I welcome feedback and try to reply to all messages I receive. See the diary overview for more details. If you do send me a message relating to something I have written, please indicate whether you'd prefer me not to mention your name. Otherwise I'll assume that it's OK to do so.


Top of page Previous month Greg's home page Today's diary entry Next month Greg's photos Copyright information

Valid XHTML 1.0!

$Id: diary-apr2006.php,v 1.65 2021/04/19 02:39:47 grog Exp grog $