darkness

I’m working on backing up a client’s mail server to CD-RW, and later to DVD-RAM. I found Mondo Rescue which looks pretty cool. I haven’t tried playing with it yet, though, because I’ve been busy gathering its dependencies. The only things missing from Red Hat 8.0 were afio, buffer, and lzop; bzip2, cdrecord, lzo, mkisofs, newt, slang, and syslinux are all included. So I packaged the things needed to run Monddo Rescue on RH 8.0. Of course, I later noticed that Brian Baggett has Mondo Rescue dependency packages. I’ll probably use mine just because I already spent time on them, and mine are slightly newer versions than what he’s got posted there, FWIW.

On a side note, a decent replacement for LaunchEmHack on my new Palm Tungsten C is McPhling. It allows me to pop up a list of most recently used programs, and lets me flip back and forth between my last application. Pretty configurable, and the new version has the support to only activate when you hold a button. This is a good thing because the Tungsten C has a shortage of buttons it recognizes, and I’ve now got Graffiti turned off in favor of the keyboard. No silk screen area either. Anyway, recommended.

Today I was fighting with YDL 3.0 keys in X Windows. I’ve previous fought with keys in X on my Powerbook. Option "CustomKeycodes" and the other modifications described in that entry weren’t sufficient for only one reason: somehow, right arrow starts sending the keycode for home. I can’t seem to find a way to change this without going to the source to at least add some logging statements, since I don’t entirely grasp how all of Xkb works. (OK, that’s a lie: I basically understand none of it.)

The default key setup in X this time is almost passable, though, as opposed to YDL 2.3. I still have this problem of a lack of insert and delete keys, though. Now I’ve got the enter key next to the space bar, which is keypad enter, mapped to insert; and Fn + right Alt, which is usually… Alt_R (right Alt; if you don’t press Fn, it’s still left Alt, Alt_L), mapped to delete since I use it far less frequently. This worked out well enough.

That was too easy, though, so I had to find something else wrong. Namely, Alt was being treated as Alt, and the Apple key was being treated as Meta. Fuckers! I couldn’t get this fixed up in ~/.Xmodmap either, no matter how hard I tried. The problem with this was that I couldn’t do Apple key + backspace in a terminal window, which is like Emacs’ backward-kill-word. This just wouldn’t do. Of course, after dicking with xmodmap forever, I decided to search on something like “emacs alt meta.” This revealed the existence of the altwin option. I gather this option is most used for working with the two Windows keys on a PC-104 keyboard, to set the Windows key to Meta or Alt or other combinations like that. You can check out /usr/X11R6/lib/X11/xkb/rules/xfree86.lst for a list of different options it seems. I tried Option "XkbOptions" "altwin:meta_alt" and it worked: now my Apple key works as Meta, but I can backward-kill-word in gnome-terminal/bash. Happy days.

As a bonus, here’s my new ~/.Xmodmap:

keycode 108 = Insert
keycode 113 = Delete
remove Mod1 = Alt_R

Also, I had to use the Gnome menu editing fix mentioned in my previous entry. Worked like a charm. gtkpbbuttons keeps dying and I can’t seem to get it to restart. Don’t forget you can set trackball options in /etc/sysconfig/trackpad, though I kind of suspect that the trackpad service isn’t starting properly, or its settings are later being overridden, so I have to service restart trackpad when I first log in to X. YDL 3.0’s /etc/sysconfig/i18n doesn’t have UTF-8 in it — hallelujah. fnset still isn’t included, but you can fondle the kbdmode setting in /etc/pbbuttonsd.conf. I left mouse button emulation on and set it to use F11 and F12 for middle and right mouse buttons, respectively. I turned this off before, but now I’m thinking it’s a good thing. (Note: must stop watching Martha Stewart media with darkho.)

So I’m putting YDL 3.0 on my Powerbook Pismo. My recipe for Sawfish beating Metacity to a pulp didn’t quite work. I ended up having to do something like (gnome-session-properties &); sleep 2; gnome-session-save since, after I exited gnome-session-properties, I could never get keyboard focus back to a gnome-terminal. Then on login Gnome’s loading screen froze on Sawfish. I started killing things, like Xclients and Sawfish, until it loaded with no window manager. Luckily it gave me a terminal. So I started sawfish, ran gnome-session-properties again, removed the startup Sawfish, changed the priority for Sawfish to 20, set it to restart, and saved my session.

Here’s another tip for you: YDL 3.0’s /etc/apt/sources.list is broken by default! The first repository listed points to “base” where it needs to point to “main”. (Look at the end of two lines for “base” and change it to “main”. Should be the first two uncommented.) I ran yum update but it was downloading all sorts of things forever before I stopped it. apt-get update was so much faster.

PCMCIA was broken again. PCMCIA=no was still in /etc/sysconfig/pcmcia. Changed it to yes. No dice. Set PCIC=yenta_socket. No dice. Weird messages about needing pcmcia_core.o. I tried modprobe pcmcia_core.o and it fails. Why not just modprobe pcmcia_core, which works? I have no idea! I edited /etc/init.d/pcmcia, found the part where it says if -d $PC ; then and changed it to if -d x$PC ; then. Result is that the conditional always fails (I hope, uh, this is not the best fix really) so it never attempts to probe the stupid module name. The elif section following this newly-broken conditional loads the correct modules.

Been a while.

I got a new Palm Tungsten C when I broke the screen on my venerable Palm Vx. It was out of warranty, and was going to be $100 to fix it. My company was kind enough to pick up the bill for a new PDA. Summary of the Tungsten C: keyboard, no graffiti area, Palm OS 5.2.1 (I think), Graffiti 2 (different from original graffiti — and I’m not sure experienced Graffiti users will like it), built-in 802.11b, 320×320 “trans-reflective TFT” color screen, 400MHz XScale (model 255 I think? Not 250 which is supposedly very buggy), built-in SD slot, no CF2 unfortunately. Overall I’m quite pleased. HotSyncing via wireless is nice when you want to install a bunch of software. I was unhappy that it didn’t have a CF2 slot, but felt somewhat better when I learned of SDIO, which allows using SD slots for more than just storage.

(I’m about to talk about Palm development. WARNING: I learned most of this piecemeal from other stuff posted around the Internet. I’ve so far compiled only a hello world program. I’m far from an expert. All of this is liable to be wrong. I have yet to actually fuck up my system. Don’t do much or any of what’s below as root would be my recommendation. I installed everything to a directory under my home directory, as a normal user.)

I decided that I might want to play with some Palm development. For example, it would be nice if TGSSH would allow me to move the cursor around in the input area with the four-way control on the Tungsten C. The vast majority of Palm development looks like it’s done in C or C++. I’m not a big C++ fan, though maybe I should brush up on it if only for the added marketability it would lend me. Anyway, I started with prc-tools. I wanted to develop ARM applications, and found they had ARM tools available for download. Alas, it looked like they were GCC 2.95 based and not the bleeding edge! So I decided to build prc-tools. (I actually started with an ARM-ELF-GCC HOWTO, but later learned that I’d need prc-tools for build-prc anyway.)

I downloaded the 2.2 sources from their SF project, but found no GCC 3.x patch, and found the other patches to be out of date as well. I then checked out the latest from CVS and found the patches for GCC 3.2.2, GDB 5.3, etc. I couldn’t get the damn thing to build on RH8, though. I suspect it might have been a matter of needing to re-run autoconf somewhere, probably in prc-tools, and making sure to run autoconf 2.13 and not 2.53. When you run autoconf in RH8 (and probably newer releases as well) you get autoconf 2.53. I tried this order of things, in general:

1. Download and unpack GCC 3.2.2, GCC 2.95.x (needed for m68k), binutils latest, GDB 5.3 (I think; latest release), and prc-tools from CVS.

2. Apply all four of the patches from prc-tools: one for each version of GCC, one for GDB, and one for binutils. The GCC 3.2.2 one applied to GCC 3.2.3 except for problems modifying gcc/version.c (IIRC). Ignore it or edit by hand (see the .rej file) if you really care.

3. Apparently it is recommended that tools like GCC, GDB, and binutils be built in a directory separate from their source. Whatever kids. You need to build and install, in order: binutils, GCC 3.2.3, GCC 2.95.x., and GDB. (Honestly, GDB is kind of optional in all this.) This “building in a directory separate from their source” is accomplished (using binutils for example) like mkdir binutils-obj; cd binutils-obj; /path/to/binutils/source/configure --target m68k-palmos; make all; make install. Note the --target that tells it you’ll be building tools to run on your current platform, but to work with binaries and such from another platform, m68k-palmos in the example. You need to repeat this process for each package with both m68k-palmos and arm-palmos, except for GDB which apparently supports only m68k-palmos. I did an rm -rf in my build directory after I did make install. Also note that both GCC configure scripts will require an --enable-languages=c,c++ kind of parameter. I used only c for mine. You’ll end up with nice stuff like m68k-palmos-gcc and arm-palmos-gcc.

4. In the prc-tools source directory, make a symbolic link named binutils pointing to your binutils source directory.

5. prc-tools, like the other packages we’ve built, supposedly likes to be built in a directory separate from its source. So along the same lines as above: mkdir prc-tools-obj; cd prc-tools-obj; /path/to/prc-tools/source/configure --target m68k-palmos; make all; make install. I suspect prc-tools will rebuild binutils, but it seems to be very unhappy if it is not allowed to do so.

6. Go grab a Palm OS SDK. The link given is probably for an OS 5 SDK only.

7. Run palmdev-prep. The prc-tools documentation might be of use here.

Based on a hello world for Palm OS out on the Interwebernet, I came up with:

// Include Palm prototypes, variables etc.
#include <PalmOS.h>

// Entry point for palm applications
UInt32 PilotMain (UInt16 cmd, void *cmdPBP, UInt16 launchFlags) {
  // Variable declarations
  EventType event;

  // Check the launch code
  if (cmd == sysAppLaunchCmdNormalLaunch) {

    // Write hello world to the screen
    WinDrawChars("Hello world!", 12, 20, 50);

    do {
      // Wait until something happens
      EvtGetEvent(&event, evtWaitForever);

      // Let the system handle the event
      SysHandleEvent(&event);

    // Quit if we have received an appStopEvent
    } while (event.eType != appStopEvent);
  } // cmd == sysAppLaunchCmdNormalLaunch
  return;
} // PilotMain

It works. I’m impressed.

One more little point of interest. OS 5 devices are all ARM AFAIK. They have this m68k emulation layer apparently, so they can take advantage of the plethora of pre-ARM applications available for Palm OS. That’s all well and good, but since I figured I was developing just for myself for now I might as well make ARM programs instead. Apparently this is not really supported. I have no crt0.o for arm-palmos. Apparently you normally just put in “ARMlets” for the performance-critical portions of an application. You do this, apparently, by compiling the ARM code separately, then including the resulting binary as a “code resource” in a Palm OS application. I suspect you could make what is basically an entirely ARM application by making a tiny m68k bootstrap that basically calls into the ARM code first thing. I’m no expert, though.

On other notes, since I’m keeping my personal configuration files in CVS these days, I also hacked up a shell script to install them. (Thanks again, Andy, for the help.) Then I put my .emacs into CVS. Now I’m running Emacs on my new RH9 box. I don’t think the machine is as fast as my Powerbook, but entirely usable. It’s not bad to have a full keyboard sometimes too. So I’m writing this entry from my RH9 box as well.

Only problem I encountered during the whole ordeal was adding a fucking item to my main menu (the thing that looks suspiciously like a start menu in Gnome — but isn’t, really!) to run emacs -f server-start --iconic. Turns out you have to follow some instructions for allowing users to add menu items in RH9. Silliness! killall gnome-panel rather than logging out and back in worked quite nicely.

Silliness!

We had a power outage this afternoon. Result was everything rebooting. I feel so bad for my machines when they flicker. Like a million hard drives crying out in pain…

Anyway, when I came back up, first think I did was try and log in on my new RH9 box. No go. I figured something on verin (the PDC/KDC/LDAP box) didn’t come back up, but it looked OK. Then I found some message about “too much clock skew” in verin’s logs. Nice of that message to appear in morgase’s (the machine I was trying to log in on) logs. That’s because when morgase booted, verin’s ntpd hadn’t gotten a good “fix” on the time (I think that’s what’s happening?) and so wouldn’t allow morgase to sync off of it. service ntp restart, try and log in again.

This time I get, “your password has expired.” Neat! It’s telling me this in GDM and letting me change it. I give my old password. I give my new password. I retype my new password. There is a pause. “Authentication failed.” WTF? Check some logs, find the password was changed, but apparently GDM gives back authentication failed and makes you log in again. OK, I try it with my new password, and it works. Happy days.

Then I go try and log in on my W2K box. No go. Try my old password, and it goes in. Fuckers! As it turns out, when requesting the password change from morgase, I have to have pam_smbpass in use on morgase as well, set up in /etc/pam.d/system-auth. BTW, though RH9 does ship with pam_smbpass, authconfig doesn’t appear to have any ability to use it. So I’ve changed /etc/pam.d/system-auth outside of authconfig, and if I ever run authconfig again I’m going to be in extreme pain.

When I decided that morgase needed to use pam_smbpass, I also decided that morgase needed to join the domain. I don’t know why, really. More of a hunch. So I went about that pain again. I tried some instructions I found in Samba docs, but that required me to log in as administrator. I seem to recall this not working so well. I finally figure out to smbpasswd -a -m morgase\$ on verin, then try to join from morgase; failure. After a long time, I remember that the LDAP administrator account is one of the few that needs an LDAP password set on it, for Samba to bind to LDAP. Fuck with ldappasswd (don’t forget -x, -D, and -W, and maybe -h) and finally get that set. Then use smbpasswd to set administrator’s SMB password. Then do smbpasswd -j PAD and… it works. I don’t even think I ended up using administrator’s sodding password. Fuckers.

Now I can’t run passwd on morgase, though. Checking why…

Oh argh. pam_smbpass appears to only operate locally. As does pam_smb_passwd. Not confirmed, of course, but from reading a bit of docs and a bit of source, this is how it looks. Additionally, I can’t get smbpasswd -r verin to work for the life of me, and nothing helpful in samba logs without upping my debug level.

Going to see X-Men 2 now, though. Have to check it out later tonight. ARGH. Single sign on is in a disgusting state.