Older blog entries for bcollins (starting at number 2)

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!