Random tidbits Bdale thinks are worth documenting.

Bdale Garbee
bdale@gag.com

Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

sdcc and git
I've been using git for a while, like it a lot, and finally decided it's time to move all my Debian packaging work over from CVS. After a frustrating few hours trying, I gave up on trying to use git-cvsimport. It generates mangled repositories even for simple packages like sudo. The git-import-dsc tool in the git-buildpackage package works fine as far it goes, but I'd really like to preserve my history. So, after some consultation on IRC, I took a look at parsecvs. It didn't quite work out of the box, either, but looks promising, and the author showed an immediate interest in the problems I'm having and offered to help. So, perhaps I'll be able to use it before long...

In the meantime, a while back I offered to help Gudjon I. Gudjonsson restructure the sdcc packages so that a DFSG compliant version can return to main with a full version under a different package name going in non-free. This is all necessary because some of the assemblers provided in the package have a non-commercial use clause in the license, and there are also license issues with the HTML documentation. I care about this because sdcc is a build dependency for gnuradio, which I maintain for Debian (it uses the 8051 toolchain to build downloadable code for the USRP, etc). While waiting for parsecvs to get some love and attention, I sat down this evening to restructure sdcc and move it to git.

I'm pretty happy with my progress so far, though there's a bit left to do before uploads happen. Gudjon and I decided to use the collab-maint facilities on alioth.debian.org for collaboration, which took me a little head-scratching to figure out, but looks like a perfect fit for our needs. I updated the wiki page about Git on Alioth with a few of my learnings as I went through the process.

Using git branching to handle non-DFSG-compliant upstream sources is pretty obvious, the notes in the git-buildpackage documentation helped. Using pristine-tar to capture the deltas required to regenerate orig.tar.gz files from the git repo is amazingly cool. It's hard to believe how much friendlier the world seems when you don't have to drag a bunch of tarballs around with you to do useful work! And git-buildpackage has suitable options to make using it pretty automatic. Great stuff!

It's likely to be a few days before I can get back to this, finish up, and upload the results of this restructuring work. In the meantime, I'm writing this entry largely to offer my compliments to everyone involved in making git-buildpackage, alioth, and collab-maint work so well. Special thanks to Joey Hess, whose pristine-tar package is another in a long line of absolutely brilliant tools that contribute to making my life easier! I'm going to end up using it a lot.

[/bdale/debian] permanent link

Debian Developer LWN Subscriptions
I just made time to catch up on processing requests for access to LWN.net under the Debian group subscription sponsored by HP.

If you think you were waiting for me, and didn't get some sort of email reply articulating what was wrong or saying you were added, please re-send your request.

If you're a DD and don't know what this is about, you can find details about LWN and how to get added to the Debian group subscription in this message in the Debian mailing list archives.

For what it's worth, there are now 494 DD's subscribed to LWN as part of this group subscription.

[/bdale/debian] permanent link

Technical Committee Update
The Debian Technical Committee has recently decided three outstanding issues, and at least one question still before the committee is moot now that etch is released. So, I spent a little time this evening updating the committee's web page , and closing the bugs related to the issues decided so that we can better focus on the remaining open issues .

[/bdale/debian] permanent link

Debian on HP ProLiant
Back in August, I noted here that HP announced support for Debian on ProLiant servers.

Recently, the first set of concrete deliverables resulting from that decision became available, in the form of freely downloadable hpasm and hprsm packages in Debian format. I've just learned that customers can now purchase support Care Packs for Debian 3.1 (Sarge) running on enabled ProLiant servers! This offering includes 9x5 and 24x7 Care Pack service for Debian available in 1 year and 3 year contract options. These service products are now available, as of December 1, 2006, on the HP Corporate Price List. Speak to your local HP sales rep for details.

The list of currently enabled server models, the downloads, and related documentation are available online at http://www.hp.com/go/debian.

[/bdale/debian] permanent link

It Moved!
There's a particular analogy I've used from time to time to explain what it feels like to be someone like me, working in a very large corporation. I tell people that it's as if I'm standing next to a large rock with an eye dropper, carefully placing individual drops of water in hopes of eventually seeing the rock move.

Today, the rock moved!

Of course, it helps a lot that a growing number of HP customers have been pushing on this particular rock, including a few burly types who've really put their shoulders into the effort... ;-) But I guess I'd like to think all those little drops over several years helped soften the soil up a bit, making the rock a little easier to move today.

[/bdale/debian] permanent link

Thanks for the Thanks
I don't know quite what's going on this week, but I like it.

I receive a fair number of emails every week asking me to do little things related to Debian. For some reason, over the last few days, the percentage of people who are taking the time to send a quick email saying "thank you" for whatever I've done in response to their reqeust has gone way up.

Thank you.

[/bdale/debian] permanent link

SPI Board Election
All contributing members of SPI should make time to go vote in the SPI Board Election currently underway. We have 5 candidates for 3 open seats this year, and there has been some spirited discussion among candidates and others about the purpose and direction of the organization. The election closes on the 29th, so do it today!

[/bdale/debian] permanent link

Debian LWN Subscriptions
I just discovered that at least some of the requests for access to LWN.net under the group subscription Debian paid for by HP have ended up in the wrong mailbox for a few weeks. Sorry about that, it's entirely my fault. I believe I've now caught up and given everyone access who asked for it and meets the requirements. If I missed any, please re-send the request.

If you're a DD and don't know what I'm talking about, you can find details about LWN and how to get added to the Debian group subscription in this message in the Debian mailing list archives.

For what it's worth, there are now 427 DD's subscribed to LWN as part of this group subscription.

[/bdale/debian] permanent link

Gender Research
Back in mid-February, I was invited to participate in a review of EU government policy support research on gender issues in Free Software communities at the University of Cambridge. The meeting was fascinating to me not only because of my level of interest in the content, but also because the reviewers were a wonderfully diverse group of genuinely interesting people. I also must admit that being a guest of Kings College for two nights was quite an experience in and of itself...

As someone who has been a strong proponent of the idea that approaches and technologies adopted by Free Software developers are something other communities might want to borrow from or emulate, I found the results of this research both disturbing and enlightening. The disturbance centers around just how strongly male-biased our current behaviors seem to be in practice, particularly in the Debian project. My moment of enlightenment was the realization that many of the ideas we discussed about how to encourage and enable more female participation in our communities could simultaneously make our projects more appealing and rewarding to all of our contributors!

I've talked to various people about this research in my travels since the meeting in February, and many have followed up asking for pointers to the findings. I was pleased to learn this morning that the integrated report of findings and recommendations from this work are finally available online.

I hope at least some of you will read this report, and will then be as interested as I am in looking for ways to change the status quo. Perhaps a BOF at the upcoming Debian developer's conference to discuss these results and brainstorm specific actions we can take in the Debian project would be a good place to start? I expect to arrive late on the 15th, and must depart early on the morning of the 21st...

[/bdale/debian] permanent link

First Annual Bangalore Debian Developer Conference
I just received word that there will be a Debian developer gathering in Bangalore, India, on the afternoon of Saturday, August 20th, at the International Institute of Information Technology. The target audience is current or aspiring Debian developers, and interested and sophisticated users of Debian in Bangalore. A registration page is available, and apparently there's an event mailing list.

While I won't be able to attend, I think this sort of low-key, techie-focused, regional Debian gathering is a great idea... and it would be wonderful to have more Debian developers in India!

[/bdale/debian] permanent link

hppa d-i
After a burst of learning, hacking, and iteration, I have debian-installer working again on hppa... and it now uses 2.6.8 kernels by default.

[/bdale/debian] permanent link

Another Autobuilder in My Basement
Andreas Barth approached me about providing resources to support his effort to build packages for experimental and debian-volatile. Seemed worthwhile, so I poked around and found enough working pieces to put an ia64 system online last night for him to use.

[/bdale/debian] permanent link

elilo in Debian

In a recent work-related conversation, Matthew Wilcox pointed out that EFI partitions are mountable on Linux and many distributions keep ia64 system partitions mounted at /boot/efi by default, but Debian does not. Since that behavior is mostly my fault, I recounted the history by way of explaining why it worked that way... and on suggestion from Martin Pool am repeating it here to document all this for posterity.

When we were making ia64 bootstrap decisions, the default bootloader on i386 was lilo, and the closest example to what we needed for ia64 in Debian was powerpc. This is because systems using EFI only understand FAT partitions by default, and thus need a FAT partition somewhere that the firmware can read from... often the first partition on the first disk. The Debian model for handling such things at the time seemed to be to craft a command to hook from kernel package postinst scripts that did the heavy lifting in association with a config file. What went on behind the curtain wasn't something to bother the user with on an average day if you could avoid it cleanly.

Some bootloaders know how to read a config file from /boot directly, and we started out thinking we'd use elilo that way, but it was hard to match up paths/naming in EFI to what they would look like under Linux. It was also clear to me that most ia64 systems were going to have large system partitions so there'd be plenty of space. So we punted and copy the elilo executable, config file, and any kernels or initrd files referenced in the config to the system partition.

I also thought the default location other distributions had chosen for mounting the EFI partition once the kernel was up, /boot/efi, was pretty ugly, but I couldn't think of anything better. The problem is that the standard says you need an \efi\"whatever" directory as the root of your content in the system partition, so mounting the partition at /boot/efi yields paths like /boot/efi/efi/debian. Some distributions didn't adhere to the standard at first, and so didn't see the ugliness until they started to comply... but I was on a team at HP making disk partitioning and content decisions that caused me to be very aware of these details.

Putting that all together, I decided there wasn't any point in having the EFI partition mounted by default... anyone who cared and wanted it mounted could just add a line to /etc/fstab to put it wherever they wanted. If I were doing it again today, I'd have an entry in /fstab marked noauto delivered during system installation. I haven't cared enough to tackle that change, though.

Sadly, there's one detail of the current implementation that can get in the way of complete happiness. The Debian-specific 'elilo' script that runs in user space to manage the EFI boot partition contents based on the content of /etc/elilo.conf expects to have to mount the EFI partition, and exits with a complaint if the partition is already mounted. For typical users, this script only gets called during installation and from kernel package postinsts, and the actual elilo bootloader remains oblivious to all this. If other distros have picked up the Debian script, I'm not aware of it. So, you're no worse off mounting the EFI partition in Debian than with some other distro, you just get treated poorly if you try to use our elilo script while the partition is mounted.

Clearly, we could handle this better. If someone wants to offer up a patch to the elilo script that asks the user if it's OK to scribble in the already-mounted partition instead of doing a mount / scribble / unmount cycle in the presence of an existing mount, I'll be happy to include it in the Debian elilo package.

Meanwhile, a lot of us have switched from lilo to grub on our i386 systems, and I'd love for my ia64 systems to work more like my grub-equipped systems. But making a substantive change like teaching elilo to know where /boot is so that it can read a config file from there and do things more like grub, without symlinks, etc, has several issues. We'd need to get the right set of file systems supported from EFI/elilo, we'd need to address the naming issues, and we would require either user intervention on upgrade, or some clever automatic parsing and rewriting of the relevant config files.

I can think of other things that would be more rewarding to work on, so don't anyone hold their breath...

[/bdale/debian] permanent link

makedev updated
Couldn't sleep tonight (sinus congestion), so decided to close a few makedev bugs. Well, I'm not sure 18 still counts as "a few", but...

This is more hacking on the current nasty codebase. I'd really like to cut over to the new table-driven version in experimental before sarge releases, but getting the tables right to match our current version still hasn't floated to the top of my "things I want to work on today" list. Sigh.

[/bdale/debian] permanent link

cpmtools updated
As much time as I spend harping on portability, it's kind of embarrasing when one of my own packages fails to build from source on one or more architectures. Simple thinko in my use of autotools-dev, hopefully this makes the mips* crowd happy again.

[/bdale/debian] permanent link

Helping with Debian Installer
In between keeping things going at work and hanging out more than usual with my kids (who are off from school on spring break this week), I've been trying to help out around the edges with Debian Installer this week. Probably the most significant thing I've done is to provide access to one of my hppa systems so that nightly builds of d-i for hppa can happen. However, trying to help out has finally gotten me to organize "my other rack" in a way that testing stuff like this will be easier in the future.

What I've done is to set up a modest test server with a private subnet behind it. The private subnet now has an APC Masterswitch remotely-controllable power switch, a Cyclades 16-port serial server, and a growing set of target systems representing different Debian architectures. The server provides DHCP and TFTP support for network booting the various target systems, my evolving conserver configuration makes it possible to access serial consoles on each target system, and the Masterswitch makes it possible to power cycle the target systems remotely. There's a bit of security work yet to do before I allow anyone else to play, but my intent is to allow other folks working on debian-installer to also have access to this lashup for remote testing of some of the less-readily-available system architectures...

My only gripe is that conserver is in non-free. I'm not entirely sure why, though, since the licensing appears at first glance to be a mixture of BSD-like with and without advertising clauses. Time to email the maintainer and ask...

[/bdale/debian] permanent link

amanda, tar updated
Uploaded tar 1.13.93-3 on Friday. Quick fix from upstream for the problem with lone zero blocks. May or may not be enough to make everyone happy with tar for sarge... we'll see.

Uploaded amanda 1:2.4.4p2-2 tonight, mostly to fix the postinst so that it doesn't assume /var/backups is still owned by user backup. Fixed a few typos and rolled in the Japanese debconf translation as long as I was uploading.

[/bdale/debian] permanent link

tar updated
Just packaged and uploaded a new upstream version of tar, 1.13.92.

I suspect some of the open tar bugs may be resolved by this upload, but I haven't worked through the list yet, and am not sure when I will get to it.

[/bdale/debian] permanent link

makedev updated
Fixed a few more bugs in the existing makedev package today, and uploaded 2.3.1-65.

I'd really rather not touch this version again, but I guess I'll keep applying patches offered for important-seeming issues, until I can find time to finish working up a reasonable set of tables for the new table-driven version that I uploaded to experimental a while back...

[/bdale/debian] permanent link

ia32-libs updated
I finally got around to updating the ia32-libs package. It's a bunch larger now... and all libraries were updated to current sarge i386 package versions.

[/bdale/debian] permanent link

Experimental Makedev Package
With some nudging from aj, I uploaded an experimental package of makedev to Debian's experimental tree. This is my first cut at moving to the table-driven version written in C from RH. Needs more work on the table definitions before it can move into unstable, hopefully I'll get that done very soon.

[/bdale/debian] permanent link

Making it Go Away...
After digging around in their policy docs, I believe my empty 'makedev' project qualifies for complete removal from SourceForge, and so I submitted a support request asking them to do it.

[/bdale/debian/makedev] permanent link

MAKEDEV
Well, it's finally time. Serious hacking on makedev today. Moving Debian to the written-in-C version from Red Hat, which is table-driven. The packaging part is easy, getting the tables right is hard... Uploaded a "final" version of 2.3.1 just to make sure nothing in my CVS gets lost unnecessarily.

I should probably tell SourceForge to throw out the makedev project I opened there long ago, since I don't expect I'll ever use it.

[/bdale/debian/makedev] permanent link

em18.2 uploaded
Finally uploaded my 2.4.20 em18.2 kernels. Installed on caballero.

[/bdale/debian] permanent link

em18.2 kernels
Latest kernel builds for ia64 seem ok. Biggest change in .2 is turning on the qlogic fibre channel driver. Forgot to turn ACPI serial port discovery on in .1, fixed now. Had to disable the BT878 video input driver since it won't build for some reason. Don't really care since that card won't physically work in a zx2000 and I've replaced it and the video card with a cheap ATI Radeon 7500 All-In-Wonder I picked up at CompUSA. Haven't tried using the tuner on it yet, but have high hopes of making it work.

[/bdale/debian] permanent link