Mon Aug 14 14:38:10 EST 2000 1015-1315, 1415-1800, 2300-0430:

• Drew up purchase order for Craig.
• Rang Optus to order the cable modem. The installers will be here in one week - Monday between noon and 5pm.
• Rang a local computer hardware retailer, got him to order a Netgear RT311 home router from his distributor. We will use this as our firewall. Should be picking this up tomorrow afternoon.
• Rearranged our office, with the addition of Greg's table. Rerouted and tidied up all the cables and the junk that's been accumulating. Now it looks like an office!
• Went to lunch at 1315, back at 1415. Picked up credit card.
• cvs uped our checkouts. This PSTN modem is killing us - 15 minutes per checkout per update.
• Cleaned up and deleted a few old checkouts we had.
• Drew up list of equipment we need.
• mjd worked on the NFS timeout problem. Turns out that to effectively debug the kernel after it's started we will need a separate command channel from the serial port, either another serial port or telnet over the Ethernet port.
• gnb worked on building a telnetd for the SuperH. After spending a lot of time on it, in.telnet was found in /usr/libexec/. What's it doing there?
• inetd is not working. netstat shows no waiting connections, even though inetd is running. After much head- scratching, we found that the "syslog" logging mechanism wasn't working. /dev/log could not be created by syslogd. We traced this down to having left "Unix-domain sockets" out of the kernel configuration.
• After this, inetd was running, but not binding any ports. After much head-scratching we found that the inetd program doesn't have a problem, but the chiyonofuji distribution has misconfigured it by putting the config file somewhere else. After creating the necessary configuration files, inetd seems to work now. In particular, Greg symlinked /usr/etc/ to /etc/. Did inetd ever work?
• Grr, this inetd has a bug: It adds extra, random and irrelevant options to the program it's spawning. As an example, in.ftpd complains about being given "-L" - where does that come from? This is possibly because TCP wrappers aren't being used on this machine, but we'd need to dig around more to find out.
• We tried to run the in.ftpd daemon manually, but it doesn't like the -p flag that is supposed to tell it to open its own connection, rather than being handed the connection on stdin/stdout like when it's started by inetd.
• We're now starting in.telnetd manually, but the client-side telnet says "All network ports in use". We think this is because there are no pseudo-ttys. Time to get them working.
• Created /dev/ttys[0-7] and /dev/ptys[0-7] and tried again. No luck. Maybe it uses Unix98 ptys.
• Recompiled the kernel with Unix98 ptys. Still doesn't work.
• Worked out how to mount the devpts filesystem necessary for Unix98.
• Grr, still the same problem. Greg is looking at the glibc sources to see how it accesses ptys. It seems to try and use the Unix98 method (if the kernel headers glibc is built against supports Unix98 ptys). If they're not available, it falls back to the BSD pty method.
• Oops, those BSD pty/tty pairs should have been [pt]typ instead. Once we fixed that, we now get a login prompt. But after the username, things die. It turns out that in.telnetd is looking for /usr/bin/login which doesn't exist in chiyonofuji. This incarnation of in.telnetd could never have worked! We worked around this by symlinking /usr/bin/login to /bin/login, which does exist.
• Well, a telnet login works!! Hi-5's all round!! inetd is still broken though - without it, in.telnetd will have to be manually started via the serial port whenever we want to log in. But at least we can log in two people at the same time, and we can use the serial line as the debugger channel for kernel debugging while using the network for interaction.
• Sent off mails to people.
• Arrgh! The cache patches that Niibe-san checked in earlier today seem to have fixed our NFS problems. More testing tomorrow.

One conclusion we have reached: Although Chiyonofuji shows signs of not having been extensively exercised, the selection of packages and its basic philosophy will make a worthwhile basis for the work we're planning in the future. I think coupling this with Stuart's ideas of having source RPMs for the packages in the distribution and we have a winner. I cannot wait to start working on it.