Ahh, GTE is so reliable. I wish they would get in gear and install this dry pair for my DSL.

I've gotten 2.2.12 boot-floppies ready for Debian SPARC potato, should prove to be very reliable. I'm looking forward to this SPARC release, it is a huge improvement over the slink release.

On the job front, I'm merging some data sets for our internal directory server. 4300+ user entries with names, addresses, phone numbers, and email. All three data sets need to be compared and merged and checked for discrepancies, what fun :)

On the lighter side of the Debian front, I've volunteered to represent Debian/SPARC for testing gcc3 (am I an idiot? :). 64bit support will be very exciting, Dave and Jakub have done an excellent job with SPARC build tools. I'm still contemplating whether Debian will have a native sparc64 port, or will I simply overlay 64bit userspace on the sparc32 port. I may end up doing both. I don't know of any OS for UltraSPARC that is native 64bit from kernel to userspace (even Solaris 7 is 64bit overlay, not sure about Solaris 8), so having it will be a big plus :)

I still need to talk to Jakub about the 64bit library layout. /lib64:/usr/lib64 seems simply wrong, IMHO. Solaris does it with /lib/sparcv9. I'm just wondering if /lib/64 would fit better into the FHS, especially since i386 does things like /lib/686. Also, it would be nice if SPARC's ld.so could pull optimized libraires like /lib/{v7,v8,v8plus} based on the current running system. Only problem with that is uname() only returns "sparc" instead of "sparcv7", "sparcv8", "sparcv8plus", etc.. I should probably code up a patch for that, shouldn't be too hard.

I think I finally have the Debian lists.debian.org mailing lists under control. VERP is a wonderful thing, and it has reduced my maintainence effort considerably. Now all I do is sit and watch the bounce logs while the automated system slices and dices those evil errors.