So when I first sent a kernel patch to the x86 subtree, I had to wait a lot. The patch (commit 273c112 in linux-2.6.git) was created in May and the first release (v2.6.27) was out in October. Then I discovered that critical bugfixes and security fixes are a different matter, getting such a patch in a release takes 1-2 weeks, depending on the priority of the patch.

Today I noticed that the newest git release (v1.6.0.5) comes with my patch which I just created 1.5 days ago. Yes. that's how does goes if people know you. :) OK, this is not a rule, a release may take more time, but it is really committed in ~2 days in most cases - if the patch itself is correct and you earned some credit already from the maintainer.

I like this feature. It's pretty useful now when I have a homework at the uni where the whole solution should be a single C file. So I just do a texture in Gimp, export it to C, copy&paste it to "the" file, and stop wasting my time trying to create some texture by hand. Yay! :)

So we decided to upgrade from 1.35.0 to 1.37.0 in Frugalware-current. As usual, there is a WIP repo since this won't be finished in one day. Most of the trivial rebuilds are done, but still need to fix up miro, pdfedit and bmpx. Ah and I needed to upgrade libtorrent as well which resulted some problem in btg and qtorrent, though both have some support for the new 0.14.x libtorrent in SVN so most of the work was just to backport those patches.

A user on #frugalware asks when will we have python-2.6. Not before boost-1.37, I'm sure.

Side note: It seems I managed not to waste the whole day just because I met and old friend (and drinking beer). It turns out that if I drink 2 beers and sleep 2 hours then I can code without the usual "go to bed early, sleep a lot, then you can work" procedure.

It has not been updated for a long time, but today a fix appeared. It seem to be kernel.org-specific though, so don't worry.

Today evening gitte collected a summary of his tailor problems, which I would call a nice collection.

He says:

01:31 < gitte> vmiklos: tailor was limited in many ways.
01:31 < gitte> vmiklos: one, basically branch per branch.
01:32 < gitte> vmiklos: two, it was written in Python
01:33 < gitte> vmiklos: three, it did not define a language, but a
                     class interface
01:33 < gitte> vmiklos: four, it made assumptions about the internal
                     organization of SCMs
01:33 < gitte> vmiklos: five, it is maintained in a darcs repository,
                     which tailor cannot even convert to Git.
01:35 < gitte> vmiklos: oh, and it did not help that the configuration
                     is awkward and badly documented, not to mention
                     inconsistent with regard to the types of input/output
                     repositories.

OK, given that I want to build the Git User Manual 1.6.1-rc1 with Asciidoc 8.3.0, I continue the story started yesterday. The new bug seem to have something with attribute handling, whitespaces in references and quotes, pick your favorite one.

So today I had a test at the uni with a lot of formula and given that it was boring to learn, I created a cheat sheet using asciidoc. The fun part is that the just released asciidoc 8.3 not only supports inline tex expressions but (using -a latexmath) supports rendering most of them to html as well.

I bookmarked a few related useful howtos on delicios, and my 14-page-length doc is available here (source, pdf, html).

I also like the new table format. The only buggy thing seems that I always have to scale images down, 100% results in a size about 200% somehow. Ah and the url escaping stuff I just reported, but that's not a problem here.

I hit it while building Git v1.6.1-rc1, released today. The toplist of that is interesting:

$ git shortlog -s -n v1.6.0..v1.6.1-rc1|head
   351  Junio C Hamano
    61  Alexander Gavrilov
    54  Shawn O. Pearce
    48  Miklos Vajna
    43  Jeff King
    38  Brandon Casey
    29  Nanako Shiraishi
    28  Nicolas Pitre
    25  Alex Riesen
    24  Petr Baudis

Heh, heh.

OK, I gave up converting darcs' darcs with tailor, opened a ticket for it. Once that is resolve, I hope I can do a comparision.

Snip. I like the new asciidoc-8.3.0, now math expressions can be defined using the latexmath :: [] macro inline. ;-)

Snip. I like how people can say the usual "if you need it, send a patch" sentence. Today's version:

"It's not very high on my list of priorities, but I assume fixing the problem is probably not hard if you decide to get your editor dirty." :-)

(full message)

I just sent this patch, because I hated I had to look up the source about what -b does.

BTW, I did the d-f-e benchmark for the ghc repo as well, the results are here. I hope I can get tailor to somehow convert the darcs and ghc darcs repo as well, then I can draw some nice chart about how fast d-f-e is. ;-)

Currently it can't convert darcs.darcs because I specified latin2 as input/output charset and it considered that as invalid. Given that d-f-e detected ISO-8859-2, I wonder WTF is this, I unspecified the output charset and changed latin2 to ISO-8859-2 on the input side, we'll see if that helps or not.

I got to implement the direct patch technique for darcs2 repos in darcs-fast-export, and it seems to be a dramatic speedup.

The benchmark was done using darcs' darcs.

Before:

real    786m16.035s

After:

real       29m39.458s

I plan to do a similar benchmark with ghc's darcs repo as well (it contains about 19k patches).