Older blog entries for bcollins (starting at number 3)

Blah, one of the Kachina's UltraSPARC's is barfing out CPU errors. Come to find out, it is possibly a bad memory module :(

Data merging is coming along slowly. There is so much divergence and special casing, I'm not sure how valid the end result will be. I think in the end we will have to choose a primary source to pull from and use the second and third db's for "additional" info, and then start updating the primary db (most likely the PeopleSoft db).

My server is back up, which means the SPARC build daemon will be operating again. I loathe the day I have to start working on woody. All of the new packages promise to be a nightmare for the autobuilders I'm sure.

Been corresponding with Billy at LinuxISO about supplying him with regular updates for potato (Debian 2.2) ISO's. He's very interested so expect some Real Soon Now for all 6 of Debian's supported architectures (for potato that means Intel, Alpha, Motorola 68k, SPARC/UltraSPARC, PowerPC and Arm).

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.

Bummer, some major /tmp races found in OpenLDAP by RHAT, and narry a single post on the OpenLDAP lists about it. This is the second time I've seen Christian Gafton find a serious security hole in a program, and post the vulnerability, but not give feedback to the upstream.

The last time was in Linux-PAM. The sad part with that was that the section of code where the problem was, came FROM Gafton himself! Andrew Morgan (the Linux-PAM author) was quite surprised to find out about a RHAT vulnerability announcement from a Debian developer :/

Such is life, not everyone is as great as yourself :)

Spent some time with my 3 year old and wife (who is expecting in Aug :) today. Getting ready for Easter and all....and now it's time for bed.

Well, after finishing some work for my job, I settled into to some more mailing list coding for lists.debian.org. Now that it is all VERPified, I decided it would be a good idea to take some simple anti-spam measures. I'm tossing around the idea of disallowing submissions to the list unless a @.*debian.org address is one of the recipients. Looks like it will have some good results.

I'll be working on my own packages tonight (openldap, shadow, and PAM) to squash the remaining bugs before release. I've been putting it off until close to release to make sure everything has settled in properly.

(can't wait till my homebrew DSL gets running, 28.8k sucks)

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!