Some brief tasks that people might be interested in taking on. These are fairly quick things, that require only a little investigation. All of these are from an internal hurd problems list, and some of them are sufficiently old that the bugs might have been fixed but the problems entries not deleted.
It's useful if you just say "I checked and the bug is still there" even if you aren't interested in or able to fix it. Anyone who has done the relevant investigation can send mail to me detailing the results. * Fix emacs/src/unexelf.c to deal with occasional lack of mmap When this problem was noted, emacs's unexelf.c assumed that mmap either always exists or never exists. If the autoconf test for mmap succeeded, then unexec would assume that mmap would work in unexelf.c, and fail if it didn't. We noticed this problem in building emacs on an NFS-mounted partition (because NFS doesn't support mmap right now). The fix would consist of having unexelf.c tolerate an error from its mmap call, and in that case fall back to the non-mmap code. * It would be nice if someone could check profiling on the current libc. Last time I checked, the call counts worked, but the CPU usage profiling did not. * the reboot() call needs to be declared in some header file, and at some point it was not. * I have a note about "extra commas in enums in socket.h and errnos.h" (in libc). * We have a note that emacs, on standalone system, with no nsswitch.conf, crashes. "Standalone" here means, I think, that there is no translator at all on /servers/socket/2. It should be tested both with no translator on /servers/socket/2, and with a loopback-only translator there. * It would be nice if someone could test out fifos (named pipes) to verify that they work right. * There is an nfsd in the Hurd right now; it would be nice to see someone begin using it and report bugs back. It is surely quite buggy. * The talk/talkd programs once were reported not to work; it would be nice to find out if that's still true. * We have a report that telnetd doesn't fill in the utmp host field correctly (what you see with the `who' and `w' commands). Is that still true?
