Older blog entries for bcollins (starting at number 8)

Been a LONG time since my last entry. Seems I take on more and more things that I really have no time for.

My wife and I are looking at a new vehicle. For the entire 5 years we have been married we have suffered with a 87 Pontiac and an 86 Cadillac Eldorado. Now that we have some extra cash we are looking at a Dodge Durango to fit out family needs (one kid, and one on the way).

Work is coming along great. The LDAP server is up and running with relevant data seeded. I've also been given the task of testing ieee1394 on Linux. This meant a lot of porting since my main system is actually an UltraSPARC. Also get to test a CardBus card. Both seem to be working ok now. I just need actual devices to attach to the chains in order to test the data transfers. I'm looking forward to ether1394 testing.

The Debian UltraSPARC/SPARC port is nearing completion for potato. Only thing left to do is burn CD's and complete our current test cycle. After that I can finally go full swing with the binary-sparc64 port.

Well, that's all for this month :)

Whew, lot's has happened. To start off with, our new server, Auric has been having issues which seem to have magically disappeared now that I am finally trying to pin it down.

Almost finished working on some new speedups for the lists.debian.org VERP handler. Seems all the bounce cache files I was grep'ing turned out to be a real slow down :)

Work is moving along on binary-sparc64. I've almost bootstrapped all of base. I wish these patches from Jakub would make it into the mainline CVS for gcc3. I really need to start on doing a full test of gcc3 for sparc-linux for the verification.

Job is going well. I finally have a decent dataset to put in the new LDAP directory for the enterprise wide (read 5000+ employees) directory. Interesting work.

What a weekend. Spent a lot of time outside (even though it was cold and raining most of the time) with my son, wife and her little brother. Got some yard work done too.

The UltraSPARC from Donovan Systems came in this weekend (Sat. delivery, yeah FedEx!). Problem is, it's only one of the two I was supposed to get, and there appears to be no monitor :/ Oh well, it's a nice system, and it'll leave my UltraSPARC 5 open for much testing (can we say bootstrapping binary-sparc64? :)

Lots to do before work in Monday. I dread the traffic around D.C., but I love the scenery on the way. Hate leaving my wife and kid, even for 2 days though :(

TGIFF (Thank God It's Fucking Friday). Starting to make plans for a big cookout in a few weeks to kick off the end of the cold season. It's been unusually cold here for April, where we usually see 70F, and it's been hovering around 55F for the past few weeks.

Starting off the day with a diary entry is weird, I'm used to writing about what I have done, and I'm hoping that by writing this now, I'll force myself to meet the goals I lay down for the day :)

Going to start off by getting everything I need done for work on Monday. The job I have is pretty sweet. I work from home, and go into the office for 2 or 3 days every other week. So, yeah, I get to roll out of bed and work in my boxers :P

Doh, in the middle of writing this I found out that sparc modutils in potato/woody is broken (missing some bins) so I had to make an emergency upload.

Back to the diary...I think I'll also get around to uploading my packages today, to fix all the bugs that are still left before release. May 2 is going to be the start of the test cycle for potato, so we'll see how things work out.

Installed 2.2.15pre19to20+vger on the Ultra5 and X stopped working. With lots of help from Dave I finally got it working again.

Also tried 2.3.99-pre6, and that seemed to lock up somehow overnight. Running it now to see if I can watch it die.

Been a slow day, trying to get VPN working over dialup from my Linux-PC to an Altiga gateway VPN concentrator. The connection auths, but I get no network traffic over the VPN interface. Hopefully I'll get it setup soon since I can't really do any real work until it is done :/

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!