In August Productions

gwibber, which is what Ubuntu tries to launch when I click "broadcast" in the little drop down menu (Ubuntu's current word meaning micro-blogging application) has been broken for me for weeks. It used to just not do anything... but since I upgraded to Maverick this week, I thought I'd check to see if it had started working again.

Nope.

But now at least I get a Bug Buddy crash window up - so at least I _know_ it didn't do anything.

Here's the next problem:

That's sort of FAIL. Twitter is sort of a popular thing, and gwibber seems to be the chosen app in Ubuntu for this task. How Bug Buddy could not know about gwibber is beyond me. BUT - there's light at the end of the tunnel.

Some angry googling brought up exactly what I've been looking for my entire life:

pidgin-microblog

As usual, pidgin continues to be one of the best open source apps out there, in that it not only gets stuff done, but it gives me more features than my closed-source friends have in their lives. Additionally, it means I might actually be able to start participating sensibly in twitter world, since I've always been turned off by the fact that it's essentially just web-based async IRC except not as good. But now I can make it look like what it is in a user interface that works. YAY!

Yet one more reason for me to continue using Pidgin over Empathy (OTR being the first reason, in case you weren't following along at home)

So short story- bugs in gwibber == FAIL, but Open Source once again saves the day by having, oh, I don't know - CHOICE!

I just made a patch to the OpenStack tarmac instance which was merged back into upstream trunk. There is now an option (which we are using) which removes the requirement for a separate commit message to be present on the merge proposal before an approved proposal can be merged. It will still use an explicit commit message if it's there, but if it's not, it will happily use your merge proposal description as a commit message.

I do implore you though - if you're the type of person who likes to write 10 page merge proposal descriptions, please also add a short commit message.

Thanks to Jobin's work with mingw and getting libdrizzle to compile on Windows at all, I have been able to get it working in Visual Studio natively. The code is in trunk now.

The approach I took, which is how I'm going to approach Windows and Visual Studio for all of our stuff, is to not worry with analogues to things like configure on Windows. Windows is a very different platform from Linux, and there is no need to attempt to duplicate Linux process there. To that end, the goal at least for now will be static VS Solution files and a set of instructions of how to get depends installed so that the Solution can find them. 

I'm excited to start poking at Garrett Serack's CoApp Project, which has some tools do do tracing of things like make to help with the initial project creation... and I fully expect to take advantage of his work in terms of creating installable packages.

Jobin has started working on Drizzle itself and has the drizzle client working so far.

Recently, Jobin took up the mantle of starting to poke at Windows support for Drizzle. We decided that step 1 is getting libdrizzle building on Windows - not to mention we could solve a few systemic "how to go about it" problems on a much simpler codebase.

We decided to go the mingw route - for two reasons.

1. on windows we wouldn't have to solve the build problem yet
2. on linux we can cross-compile, and then I can spend less time connecting to a windows machine 

I'm happy to say that the branch implementing support for building under mingw has been merged in to trunk - so please go hammer at it and tell me that I'm an idiot.

If you're on linux and want to play, you'll need mingw32 and mingw32-pthread. You may notice that mingw-pthread isn't in the Ubuntu archive... that's ok - I added a package for it in the drizzle-developers ppa (add-apt-repository ppa:drizzle-developers/ppa) Once you're set with that, it's as simple as:

 bzr branch lp:libdrizzle

 cd libdrizzle 

 ./config/autorun.sh

 ./configure --build=x86_64-unknown-linux-gnu --host=i586-mingw32msvc

 make

And you're off to the races. Now, as for actually doing anything with it, well, I'm expecting some windows person to fill in details on that.

Next up - building under Visual Studio. (oh, and getting Drizzle itself working)

Almost no one will ever notice anything about this, but I'm excited, so I thought I'd share.

Instead of using the build infrastructure installed by gettextize to handle message translations, we're now using the more modern replacement, intltool.

Unless you're actually hacking on build, this will mean nothing - translations are still done via launchpad - Drizzle still uses gettext() to translate strings. It's purely a tooling change which means the build is less brittle and I'm slightly less ornery. Oh, and we have many less random generated files committed to bzr. I like deleting files.