Present Perfect

Lots of stuff has been happening as of late. I stopped working on Dave/Dina for a bit, I wanted to help out on GStreamer.

After agreeing on splitting plugins from the core (finally), we had a last-minute disagreement on how it should be done. Do we use a given directory structure for the plugins, or do we lump them all together ? We're talking about close to 100 plugins by the way.

I had an idea that would make the build maintenance a lot easier, IMO, after having spent quite a few days on fixing build issues and removing cruft everywhere. Some others thought that the advantage here was minimal, and thus it wasn't worth it to use a directory structure.

I'm glad I stood up to it, even though I might have less experience with these issues. IMO, if you have taken the time to get really intimate with autotools and build issues, and got some first-hand experience on how it works and how it's supposed to work, then your voice should count for something.

In the end we decided to vote on it together. It might not be the best solution, but at least it allowed us to move on and get it done. Which we promptly did, after the vote.

GStreamer CVS is in pieces at the moment, but things are starting to work out fine. It builds, it even plays stuff again, and it is easier to maintain at the least !

Now we're working out stuff for the next release which is scheduled in a week.

Using my work's bonus, I bought something totally irrational : a Lego Mindstorms developer set ! It looks cool. I haven't opened it yet though because I know I won't get anything else done anymore as soon as I start ;)

Lots of stuff has been happening as of late. I stopped working on Dave/Dina for a bit, I wanted to help out on GStreamer. After agreeing on splitting plugins from...

The good news is that GStreamer (your future) has a new release out. It took a lot of sweat working on the autotools stuff to get it to build, compile, install and check ok. GStreamer should release more often and hopefully it will.

Whacking the GStreamer ball around all weekend made me realize a few things :

• I don't know enough autotools
• People always blame autotools, when the tools are probably not to blame
• Autotools are hard to debug when you're actually trying to debug them in the project you're trying to get running. Most of the time, you don't want to spend time forcing autotools to do what you want, you want to get them out of the way.

To solve all these problems at once I decided to create a new project : Autostars, the Autostar Sandbox. The idea is delightfully simple, and I suppose I'm not the first one to think it up.

The main problem with debugging autotools stuff is that the fix/run/test cycle takes too long when you do it in a project. While fixing GStreamer builds this weekend, I often tried fixing checks. Running autogen.sh after that again took a few minutes, because GStreamer checks about fourty libraries. So by the time this is finished you have long left your window of concentration and you end up getting frustrated. You're also not learning anything about autotools. You're just throwing cement at little holes all over the place and hope it sticks.

So, the solution is simple : strip down the files involved (configure.ac, Makefile.am, ...) to the bare essentials for that test only, and you'll have a much quicker result of your changes. This is what the Autostar Sandbox is for : simple, atomic tests, showing you how to implement particular tests. Not every autotools problem can be solved this way of course, but most of the basic ones can.

There's not much in there as of yet (five checks at the moment), and it's only in CVS, but I invite you to try it out anyway if you're currently having problems getting something to build. You'll actually fix your build problem quicker if you do it this way (I know, it's paid off for me in the last week as I implemented GStreamer check bits in autostars), you'll end up less frustrated and maybe with a bit more knowledge, and best of all : you get to share that knowledge with other developers ! Enough to make you feel fuzzy and warm all over. My boss would say it's a win-win situation.

The good news is that GStreamer (your future) has a new release out. It took a lot of sweat working on the autotools stuff to get it to build, compile,...

Here's a reminder of what insomnia can do to you. Like I said before, the GStreamer team is getting a new release ready.

One thing that might need to be done after this new release is to split off the plugins from the core to make it more manageable. To this end I had proprosed a division of the plugins among directories. One of the developers (who shall remain nameless to protect the innocent ;) ) spoke out against the idea of directory classification, and argued that we might as well make a flat tree.

Well, yesterday night I couldn't get to sleep and got up again, and on IRC someone commented on the plugins, and he said that "I might as well put all of the .c and .h headers in a separate .tar.gz".

Hah flipping hah. So I thought, sure, why not ?

Ladies and gentlemen, you can download an unofficial pre-release of GStreamer 0.2.99. Grab the tarball (which contains more than 1700 tar.gz's) and the script to unpack them, configure the thing and make it. Send us mail as feedback on whether or not gstreamer compiles for you while you're at it, because all this fun stuff actually serves a purpose. Or drop by in #gstreamer on irc.openprojects.net

Needless to say, I got a good night's rest out of it, though a bit short.

Here's a reminder of what insomnia can do to you. Like I said before, the GStreamer team is getting a new release ready. One thing that might need to be...

Been busy with lots of stuff recently.

This weekend, I'm doing some work on GStreamer. If you don't know it, check it out, for some of you it will be the future. Anyway, it's been quite some time since a last release, so some of us decided to just get ready and do it.

So I've been fixing build issues all over the place, while two of us are trying to make RPM's as well, and we're pretty close to being ready.

As for Dave/Dina, I got this little infra-red receiver add-on for my Asus A7V motherboard. I can't get the thing to work. It's really confusing : what modules should I be using for it anyway ? I hope I can get LIRC to work on it because using a remote will be the best thing.

At work, "marketing" asked me if they could send a html page to a thousand people. *sigh* I told them if they knew how you send a html page with images in the first place, without using Frontpage. One guy's suggestion was to send the page as HTML and make all the IMG tags point to our webserver.

"So what happens when the people reading their mail are not on-line, when they popped their mail ?" Yeah, that sounded like a problem to him.

So I sighed and decided to do it anyway because if I let it lie it's gonna blow up in my face later on. So I spent an hour or two writing a simple perl script that takes a web page with images in a directory and spits out one html page with uuencoded inline images. Then another few hours to set up mailman and off it goes.

The new laptop works fine. I made an rpm for the toshutils package and sent the spec file to the author. That's open source for you.

Been busy with lots of stuff recently. This weekend, I'm doing some work on GStreamer. If you don't know it, check it out, for some of you it will be...

Got a new laptop, a Toshiba Tecra 8200. Nice thingy, but again I need to run the video card in frame buffer mode to get decent X. Oh well, the card seems fast enough for it not to matter, though I won't be playing tuxracer anytime soon.

On another note, I decided it was time to build kernel packages for Dave/Dina the right way. Right now I was custom-building the kernel and moving modules manually into the DD module, and adding these binary modules to CVS. Yeah, I know, don't add object code to CVS.

Anyway, I downloaded a red hat kernel SRPM and checked the spec file. Then I threw that away and started from scratch, and it went suprisingly easy if you forego some of the specialised stuff. Just make a config the standard way, put that config in the DD module, type make rpm, and wait half an hour. I'd have thought I'd run into more issues.

Right now I'm looking for a way for RPM to generate a DD-OS-kernel and DD-OS-modules rpm from the same spec file without trying to make a DD-OS rpm. Oh well, there's always tomorrow.

Got a new laptop, a Toshiba Tecra 8200. Nice thingy, but again I need to run the video card in frame buffer mode to get decent X. Oh well, the...