![[lang]](/images/eye.png)
|
|
2003-12-31
|
Dave/Dina
Massive three day hacking spree on Dave/Dina. It was still running on Red Hat 7.3. I took the platform to RH9, rebuilding almost all of the packages, throwing some out, tweaking things all over, and so on.
It is amazing to actually use all of the side projects you were involved with and start using them for what you intended them to. Building all these packages was made a hell of a lot easier using mach. That was a great experience.
I also learnt some more about the delicacies of controlled kernel building. In my older packages for the D/D kernel, I started from the patched RH kernel sources, and didn't have to do make mrproper. When I synced with the RH9 kernel sources, the build failed mysteriously halfway through, and commenting out modules one by one that failed (megaraid, dac, ...) didn't really tell me what was going on.
Someone suggested running make mrproper, which worked. So I suppose the kernel-source rpm isn't really a pristine kernel source tree with RH patches, but in some way preconfigured or whatever.
This just shows me I have yet a lot to learn about the kernel compilation process.
On the plus side, after a day of fiddling, I had a completely decent kernel package, buildable as non-root (mach forces me to deal with these issues, which is good for my package-fu), which installed and worked just fine. It even has the custom boot logo for Dave/Dina, sweet.
Checked the Sourceforge statistics page for D/D by accident - it seems that this weekend the project was two years old. Crikey.
That made me all tear-eyed. It is amazing both how far it has gotten and how usable it is in day-to-day life, but also makes me wonder about all of the other things we could have been doing with it today.
In any case, the four of us that are now living together are going to part ways soon, and two of the three others have already decided to buy a machine and install Dave/Dina. A sure sign we're doing something right.
DAD
Worked with Kristof on the new DAD version. We put in lots of nice tweaks and options to get playlists based on the ratings you've given to songs.
One of the things that bugs me to no end in other PHP-based projects (well, apart from the obvious/usual bad coding style/stupid variable names/hackish install ways) is that they are so damn hard to upgrade properly; especially when the database backend tables change.
So I discussed with him some way of setting up an upgrade path that would be pretty much transparent. We experimented a bit and came up with a dead easy solution:
- Create a table with the "database" version to keep track of what version of the source the current database corresponds to
- in the header.inc file, check this version against the source version
- run through all of the upgrade_to_(version) functions one by one
- each of these functions tests the database version against it's own version, and makes mysql adjustments as needed
This might sound a bit complicated, but in the end works very well. A new RPM version of dad gets installed. A user browses to the interface. The interface checks the database version and notices there's a mismatch between db and src version. It takes a backup dump (also very handy for our night rest), and starts going through the upgrade functions.
The net result is that, when we just keep adding upgrade functions whenever necessary, each version is upgradeable to each following version without problems.
Sometimes the fun is in the small details like these. (Just like, how adding flush (); at the end of the header.inc file gives us a nice always-there header when browsing through the interface).
Kernel hacking
Today I presented myself with a hard problem to solve. The basics are simple.
- a Creative Live Audigy card (unsupported by the kernel emu10k1 driver)
- emu10k1.sf.net (a module to replace emu10k1 and ac97_codec)
- the desire to make a Fedora package for this kernel module so that the people who will have to look after the machine with the Audigy will have some hope of being able to update the OS/kernel/...
- the problem that you can't cleanly override already installed kernel modules
- the desire to make modules.conf autoprobe the "new" module, and not the original one
At first I wanted to find some way of installing them in a different subtree, and then figuring out how to make depmod and friends ignore the "old" module.
I couldn't really find anything to help me in that direction, so in the end I decided to do it by mangling the name of the new kernel modules. I prefixed both with ext-, and changed the Makefiles, and that worked. I tried the modules, modprobed ext-emu10k1, but sadly it loaded ac97_codec (the old driver).
Trying to back-guess how depmod and friends worked, I figured that emu10k1 must be trying to call symbols from ac97_codec, and I dug around and found some define-like thingy that exports symbols. So I prefixed all of these with ext_, rebuilt the RPMS, and retried, and this time it correctly loaded the two modules. Success ! A new set of lessons well learnt, one of which is to not be afraid of the kernel. Well, of modules, anyways.
Anyways, if you have an Audigy and are running RH9 then please go to this Fedora bugzilla entry, get the packages, test them and report your progress in that bug number.
Music
Was eagerly awaiting the new Elbow record, "Cast of Thousands". It's one of those bands I didn't get into when they got their album out, or which I had written off as just another hype. But after picking up their first one on the cheap, I fell in love with the graceful beauty of songs like Newborn or Scattered black and whites. It's always hard to comment on songs when they haven't had a chance to grow, but there are some very nice touches on the record.
Lyrically, it's top notch. Poetic in a good way. Just when you think every way to tell someone you love them has been said, someone invents some new way of saying it.
this world has ever made