phayz just pushed out a special Frugalware logo for Xmas, I like it. :)

BTW it's interesting, my sister got an English bible and it claims that "to make it easier to read it more fluently and accurately, it's 'anglicised'." Not sure if that's really true, especially that young people like me typically learn a lot of words and expressions from movies and series...

"big-zoo" is a collection of darcs repos, the darcs developers do benchmarks using this collection from release to release.

Recently our old Frugalware repo has been added, which is good, for multiple reasons.

First, now I can say that the reference for a good darcs exporter is the big-zoo, our old repo contains weird patches which were not yet part of "big-zoo" so far. Not that I'm evil, but I want to show that currently darcs-fast-export is the only exporter that can correctly convert all the repos in "big-zoo".

Second, it is a huge repo, so developers can how see the corner cases where darcs is really slow for a huge repo - though the GHC one was already included which is almost as big as our one and the most annoying cases are already optimized recently. (No, of course I can't compare it to git, I compare it to darcs-1.x.)

I've just added a new comment to the previously mentioned ticked. In short, it seems that darcs what -s --xml is horribly broken, and tailor heavily relies on this, so darcs-fast-export did.

I just removed this for now - maybe later I'll write my own patch parser, but that does not have a high priority in my TODO.

I want to cut a release in case all the test conversions in the "darcs-benchmark" repo passes fine, but that will take 2-3 days, I guess.

See this ticket. The idea is not to use "chat_randomnumber" as channel name, so that irssi can remember the layout.

We'll see how wilmer will welcome the idea. ;-)

OTOH, I still hate bzr:

$ bzr pull
Using saved location: http://code.bitlbee.org/bitlbee/
Format <RepositoryFormatKnit1> for http://code.bitlbee.org/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
No revisions to pull.
$ bzr upgrade
bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.

I guess it refers to the server repo, but PLEASE, why should I care about it? It's not my repo!

And again something else. I just started using tuxguitar. I like it, but having sound in it was not trivial. It turns out that the working setup is to run

timidity -iA -Os

and then disable the oss output plugin, enable alsa, and choose the timidity midi output in the sounds settings in tuxguitar.

Yesterday macmaN on #bitlbee poked me about how would it be possible to rejoin existing groupchats after connect automatically. It turned out that Skype has support for Jabber-like bookmarks, and it wasn't too hard at all to implement it.

I want this to settle down then I'll be ready to release 0.7 next year, I hope.

OK, this is probably not that interesting, but who knows... I just put out some code I did during this semester for this OpenGL course. It's available here.

So this came up on IRC: ancient tag objects in git have no "tagger" line, and thus converting such a repo with git fast-export is not possible. And the usual way - I just reported it on the mailing list and Dscho quickly provided the necessary patch.

I hope the ubuntu guy (who is in CC) will at least give Dscho a "thanks", but who knows if it'll ever happen..

One item in Python's magic word is that you don't have to really care about memory management. I already know if i want to "strdup" a list, then i need foo[:], but I did not notice that in case I iterate over a list _and_ modify it, then I need such a trick as well.

Example

l = ['a', 'b']
for i in l:
        l.remove(i)
print l

So we remove each item from the list (an expensive version of "l = []").

However, the result will be "['b']". Now if you use "for i in l[:]:", everything will be fine, because you can iterate over the original list.

It's a shame that I do python for more than 2 years, and I did not know such a basic stuff. :(

(original post)

I spent some time today to prepare some rpm packages for an RHEL4 box, it was an interesting experience. To preface to this story is that first I had to do the followings on Frugalware:

• Patch mysql 5.0.37 to add support for the sphinx search engine
• Make sure about sphinx itself works fine with this (though sadly I haven't had time yet to package sphinx as well).

We have a newer (but compatible, since we still ship 5.0.x) mysql, but a simple git checkout gave me the old buildscript and then the patch applied perfectly.

Then the plan changed, I needed to do this on an RHEL4 box as well.

Steps:

• Fix broken up2date config, it seems nobody installed any security update on the box for a long time.
• Notice that RHEL4 has mysql 4.x, so I had to upgrade it to 5.0.x which was not trivial.
• After adding the patch to the spec file, I saw that there are a bunch of manual autoconf/automake/autoheader/autowhatever calls, so I did not add a call to mysql's own autogen script. It turned out later that this was a fault, the default autofoo calls did not regenerate all the necessary files, basically they just took a lot of time, but did not really do anything useful. Sigh.
• Once build was done, I had to rebuild perl's mysql driver and the whole php package because of the major mysql upgrade. Did I say I hate to touch php?
• And finally the worst was to package sphinx. I used some opensuse spec file, but it turned out to be badly broken on RHEL4. Fixing it was not so problematic, but took a lot of time, because debugging a specfile under RH is a PITA.
• Let me show a few examples. The equivalent of Fdestdir (the directory which will be tared up after the build is done) is not rm -rf'd before the build starts. So if you have some crap there, your final package will have it.
• OTOH, Fsrcdir (the directory where the build takes place) is deleted, which means you can't do an incremental build.
• If you break your pre-uninstall script, you can't easily uninstall a package, even with rpm -e --force --nodeps (you need some magic --no-preun switch, which is not implied by --force).
• If you say rpm -Uvh foo-2.0.rpm, then sometimes it bails out with an error about it has a file conflict because /bar/baz.so is provided by foo-1.0. What? Doesn't -U stand for upgrade?

Okay, this was enough. I finally finished the task, but I again just can make a "this is so much more efficient with Frugalware" note. ;-)

And no, I don't like to write about why foo sucks, but both this packaging system (or at least the default settings) a docbook sometimes really sucks.