ASP Concert

So … I’m back from the ASP concert. And it’s been completely aweseome :). The people in the audience are way more active than the ones in Stuttgart — which is a very pleasant experience :D.

Anyways … I’m hoarse, I’m deaf, every fiber of my body hurts: Ergo mission accomplished :P

Oh. And I noticed, that French guys are not this amused when using this nice quote (it’s German). His buddys were, though.

Portato moving to Git – Part II

I now found some time to finalize the move from bzr to git. Hence now it can be considered official and the old bazaar branches are deprecated.

You can find the portato code and the overlay at github:

• http://github.com/Necoro/portato
• http://github.com/Necoro/portato-overlay

As Launchpad offers a git-import service (which is quite nice), the master branch is mirrored there and can still be accessed via lp:portato using bzr.

I announced in the following places … hopefully I haven’t forgotten an important one:

• Both threads in the Gentoo forums.
• Launchpad page.
• Origo Development Page.

Managing your configuration files with Git. Revisited.

I showed a way of managing the configuration files with git and StGit in the post two days ago. But this has two disadvantages:

1. StGit is not installed on all systems. And though it is only some Python-Code which is not hard to install in your home directory, it is something I’d like to avoid.
2. Using two commands (config and cstg) is not the best thing. Having only one command would be better…

So I tried the more natural way (often I tend to think way too complex) of using git branches. I created a “local” branch, which is used for the local changes (hah – you could not guess it :P). And then I only use rebasing to pull global changes.

Compared to the older method, the approach is now:

1. Same as the old one.
2. Create local branch and use it:

   config checkout -b local
   # hack hack hack
   config commit -a
   # ...
   

3. Change to master and work there

   config checkout master
   # make changes
   config commit -a
   config push
   config checkout local
   config rebase master
   

4. Same (except step 7 of course).

Lesson learned: Simpler is sometimes better ;).

Managing your configuration files with Git and StGit

This is propably a wide known problem: You want your personal config files (for ViM, Emacs, $SHELL, …) on all the boxes you have to deal with. The solution here is often: Use some distributed VCS/SCM like git, bzr, hg, whatever and be happy. But it might happen (and it will surely happen quite often), that the boxes have different versions installed for some packages. Or there are other differences (for example: I have to use other font sizes on my laptop than on my PC). This not a problem, if the config files you are using allow importing other ones — you have your global options and override them with some local additions. Well, unfortunately, this is not always supported (e.g. I do not know of a way to import something into .gitconfig). So we have to find a solution…

And I guess, I found one: Use Git to manage the global stuff — and use StGit to manage a stack of patches for the local boxes :)

(UPDATE: As written in my later post, using StGit is not the ideal solution and using normal branching seems to be better. But read on to get the basic setup and just replace the stgit stuff with branching (as explained in the linked post).)

Portato moving to git — Part I

So — as announced in my previous post, I started moving to git. You can find the current git repository at Github: http://github.com/Necoro/portato

Note: This move is not yet “official”. I have to test first, if I get completely used with git. And then I have to find a hosting platform (github was chosen, because I have an account there already) :). Or perhaps, I am going to host it myself … dunno.

Bzr vs Git

I had to deal with git yesterday, as I worked on ktsuss. And as always: I couldn’t make it to do what I wanted it to do ;). Thus I head to read the docs … and believe it or not: I’ve been always a contra-Git-guy, but when you get rid of the “it must be similar to all the other SCMs”-thought, git’s concepts begin to make sense. So I spent even more time with reading docs and playing around. And currently it seems, like I am going to replace bzr by git sometime in the future.

Reasons:

• way faster
• branches inside the one repository file — no more ‘gnah — the branch is still on my laptop’
• allows to finally get the currently split svn history back in (though using ugly hacks … but hey — git is all about ugliness :P)
• git is better supported by most tools — bzr plays only a small role (unfortunately)

I just need to find another bugtracker then, as I planned to use the launchpad one, which does not make sense anymore.

A last remark: I still think, that bzr is a GREAT scm :).

Probably move back to sf.net

Quite some time ago, I moved the main Portato hosting from Sourceforge to Origo. The reason was mainly, that I wanted some nice wiki-stuff w/o having to deal myself with hosting and configuring it. Also SF.net is … well … not really fast :).

But Origo has many other disadvantages, which I ignored so far:

• Does not support bzr — and does not allow to make the “Development” link point to somewhere useful.
• Uploading system sucks hard. Adds a random integer to each download URL, which makes it necessary to change the ebuild for each release.
• Flat namespace for attachments… Yes! … No comment -.-
• Bug tracker is ok for — but has real issues with attachments -.- … And it being built as somehow part of the wiki is not a good idea either.
• No possibility to put extra files somewhere (docs, …).

Additionally I noted, that sf.net now has some real nice features with its “Hosted Apps” — so it is possible for example to add a trac-instance — just with one click :D. So I’m now considering to move back to sf.net. I just do not know yet, whether I try to use trac and it’s bug tracker — or if I’m going to use the one in Launchpad. And where to host the bzr-branches? Also on sf.net — or leaving them on LP?

Comments are welcome :)

Portato 0.13 released

So — there it is: the new Portato release :)

Changelog is here.

Feel free to use it — it still waits for inclusion in the portage tree, but this will happen in the next future, I’m sure.

Portato’s new C-Modules

As I’ve written yesterday I created an eix cache parser. But … it was overengineered: It took like ages and was way slower than the normal portage way:


$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 3.18 sec per loop
$ python -m timeit "import test; test.portage()"
10 loops, best of 3: 280 msec per loop


Thus I had to improve it: The first thing was to re-implement it using Cython. And step after step I ripped out features (in the original approach, the parser was lazy, i.e. only reading data if he needed to do so) and trimmed it down to what I really needed (opposed to being complete). Oh – and some C-level improvements :) (like using | instead of +).

Well: This is where I ended:

$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 56 msec per loop


Now it is usable :)

Well — and while testing the new eix parser, I noticed, that Portato segfaults sometimes during shutdown. I thought the shm module the culprit and thus replaced the external dependency by a self-written module (again in Cython). And this also now uses message queues instead of shared memory — which is more intuitive and easier (no stupid locks and stuff). Seems to work up to now :)

Result: In the future, portato ships with C-Modules :) (hence the title

EixReader for Portato

Yay :) … I’ve finished the EixReader for Portato. It is now able to parse eix-files.

Now I only need to write a DB-Backend that makes use of it. And then some operations will be much faster — especially during startup, where the internal database is filled.

(Perhaps I am going to write a complete eix-Backend … thus not using portage for most operations… We’ll see)

Branch is here.