Fixing media bugs…

.. sometimes it’s annoying, sometimes it’s funny, sometimes it’s hard, sometimes it’s easy.

Luckily, tonight’s xine fix was an almost trivial one, an amaroK user (bks) reported a problem with current amaroK SVN being unable to detect the audio stream in FLAC files, after a little grepping, I confirmed the bug is in xine, and I fixed it with some vim magic.

On another completely different note, I’ve been pissed off by BZR for the last time. The 0.8 version is slower than ever with pulling, and even after migrating to the new repository format (knit), it’s still slow on pushing via SFTP. Not only, by pushing via SFTP there won’t be the working copy uploaded, so the main reason for which it would have made sense to have BZR (direct plain HTTP access of files), is going byebye. Really, this moves BZR at the bottom of my SCM of choice, even after CVS.

I’ll be migrating my overlay to GIT soon, but as that does not allow (by default) the direct HTTP access I wanted, I set up a gitweb host on my farragut, and with a few rewrite rules I can provide direct URLs to patches on the repositories. Right now there’s only RubyTag++ but later I’ll work with tailor to convert the overlay (or maybe just drop the history and start a new overlay entirely, I don’t think there would be much useful anyway).

Oh I also joined Ruby herd recently to try to give a hand with the basic issues (I don’t know the internal well enough to fix more complex issues but there are thing I can do ;) ); I started by committing the two things I had waiting for them :)

Now, I think I really lost my mind… and my free time.

Update: thanks arachnist, again :) It wasn’t git.farragut but just git :)

I’m no more impressed by Bazaar-NG

So for some months now I’ve been using Bazaar-NG for my overlay on, I also used it for RubyTag++ before finding it too slow and unreliable.

I started using version 0.6, that required complex settings server-side to get rsync pushing working, 0.7 made it simpler although it changed the syntax entirely. Now with 0.8 the syntax has changed again, actually the whole command has changed completely, instead of push, rspush. On a first sight one might consider it good, as you specify that you want rsync, but after some days of use, I find it annoying, I’m used to use “bzr push”, and “git push”, too. Why should I make my finger get used to a new command every time a new release is done?

Not counting that a feature as important as rsync pushing is not available on default installation, bzr just come with ftp and scp pushing, both of which are non-incremental, meaning that they take a damn long time to push the stuff. rsync pushing is present only as an extra package, bzrtools.

Now I can understand it’s a quite a new thing, and I’m not displeased that it’s written in Python, but, you know, in a few months things became even more complex. Really not what I’m expecting.

I think I’ll continue using bzr for a while at least for my overlay, but I’m really no more impressed. GIT seems better for me, really.

Another move to bazaar-ng

Okay, tonight with the help and hints of marienz, I did one more step toward bazaar-ng (bzr). As I found something I don’t really like. If this is true, well, it might be quite a bit of a problem, so I don’t really think of telling people who would help me to join berlios and use SVN at this point. With bzr the problem is way different.

So what’s the deal? I moved unieject on a bzr repository. If somebody wants to help me out with code or with translation, feel free to branch that to me and send me an email with the URL you’re going to use and what you’d like to work on exactly :)

Also, you might want to read how to set up CIA for bzr so that I can read on unieject’s project feed your changes :)

Now I just hope to get someone working on it with me at least for the translations :P