Necoro's Blog

moztmp update

Necoro — Mon, 14 Mar 2011 20:01:53 +0000

Someone has obviously discovered my old post about moving the .mozilla directory of firefox into RAM. Unfortunately it did not work anymore and I also stopped using it (one reason: well – it did not work, second reason: my computer was quite unstable for some time and thus I lost quite often my FF-data).

But now I took the time to look into it and fix it. I also moved it from bzr to git: It can now be found at github.

Feel free to play around with it. And if you want to add nice features: do so. Remember that it is quite easy to fork and push-back repositories with git and github :)

Portato 0.14.1 released

Necoro — Wed, 08 Sep 2010 21:37:02 +0000

Well … it probably won’t hurt to announce it here too:

Because of some API-changes in portage, I had to release a bugfix release for portato. And well … it is called 0.14.1 as you might have guessed :P

At the moment I am not developing portato actively. This is partly due to lack of time and partly due to lack of interest. The latter one is especially created by the fast-changing portage (which is in itself a nice thing), where I can’t keep step with w/o needing to spend tons of time in it.

Portato 0.14 released

Necoro — Tue, 11 May 2010 23:41:27 +0000

“Was lange währt, wird gut” is the German saying (the dictionary tells me “Good things come to those who wait.” is the English translation) — hopefully this applies for this version of Portato too.

The changes:

NEW: allow eix as backend DB
NEW: show the list of world packages
NEW: allow to search descriptions
NEW: add an icon to signal the ‘best’ version for a package
CHANGE: use an internal messagequeue module instead of external shm
FIX: bugmail sending
I18N: Italian translation – thanks to Ponsi
I18N: French translation – thanks to Clément ‘moonpyk’ Bourgeois

Personally, I find the addition of the eix-backend the most important improvement. This now allows fast startup and fast searching. Additionally the long awaitened feature of searching descriptions is only possible here (implementing it with other backends would make the startup sloooooooow).

So – let’s hope that the bugs are on vacation. :) — And a big thanks to idl0r for adding it to the portage tree in no time.

Subscribing to Google Group without needing a Google account

Necoro — Wed, 21 Apr 2010 20:11:12 +0000

More and more projects host their mailinglists on google groups. This is nothing bad per se. But it is not quite easy to find out how one can subscribe there w/o needing a google account. But it is easy: If the mailinglist you want to subscribe to is named foo-bar@googlegroups.com, you just have to send a normal subscription message (i.e. an empty one) to foo-bar+subscribe@googlegroups.com.

This is also documented on Google, but somewhat hidden.

Hopefully someone finds this useful :)

Portato’s homepage moved to own server

Necoro — Thu, 08 Apr 2010 23:50:25 +0000

Up until now, the web home for Portato was at http://portato.origo.ethz.ch — but although the Origo-platform was promising during the start (and has been a nice alternative to Sourceforge), several problems appeared (I won’t repeat them here, as I already wrote about them in this post).

I started to look for a new home, but could not find a pre-hosted solution. Thus (and as I happened to have rented a virtual server) I decided to host it on my own. So I was able to use the software I liked etc. Well … finding the ‘right’ software was not as easy as I thought ^^… I am now settled with running web.py as the web framework and Mako. But, as I’m only serving more or less static sites, getting rid of web.py and using some tool to generate static pages from the mako templates is also a nice idea… Perhaps I’ll do something in this direction later (if I find a nice tool doing all the work :P).

Oh – btw: The new home for portato is: http://necoro.eu/portato – bugs are going to be hosted on launchpad (this is no final decision either) … and I decided, that there is no need for a wiki.

Managing your configuration files with Git and StGit. Revisited #2

Necoro — Sat, 27 Mar 2010 14:28:21 +0000

Ok … I wrote about using Git and StGit and about how I ditched StGit and used plain Git. So – just a short update: I reverted back to using StGit :D. I updated the two mentioned posts.

Oh – and for my convenience, I wrote a “small” function in zsh which does the “pop, commit, push, push” cycle needed if you want to have a patch applied directly in Git and not in StGit. You can find it here (function “cci”) … or below.

cci ()
{
    if [[ $# == 0 ]]; then
        echo "No message given. Aborting."
        return 1
    fi

    local message=$1
    local tok=__cci__

    pushd -q ~

    cstg diff
    echo -n "Is this ok? [y/n] "
    
    if ! read -q; then
        echo
        echo "I would have done the wrong thing ... aborting!"
        return 2
    fi

    echo ">> Creating new patch"
    cstg new $tok -m "$message"
    
    echo ">> Refreshing"
    cstg refresh

    if [[ -z $(cstg files) ]]; then
        echo
        echo "Ehm - this patch is empty. Narf. Aborting!"
        echo "Deleting useless patch"
        cstg del $tok
        return 3
    fi

    echo ">> Committing"
    cstg commit $tok
    
    if [[ -n $(cstg series --applied) ]]; then
        echo
        echo "Urgs! Something went wrong. There are still patches applied."
        echo "Clean up for yourself. Aborting here!"
        return 4
    fi
    
    echo ">> Pushing to remote"
    config push

    echo ">> Re-apply patches"
    cstg push -a

    echo ">> Done"

    popd -q
}

ASP Concert

Necoro — Sat, 31 Oct 2009 00:11:03 +0000

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

Necoro — Fri, 23 Oct 2009 23:19:44 +0000

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:

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.

Necoro — Sat, 10 Oct 2009 01:26:14 +0000

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

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.
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.

Update: In the meantime I switched back to using stgit … it just worked somewhat better. But the approach mentioned here still works pretty good :)

Compared to the older method, the approach is now:

Same as the old one.

Create local branch and use it:

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

Change to master and work there

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

Same (except step 7 of course).

Managing your configuration files with Git and StGit

Necoro — Thu, 08 Oct 2009 00:52:40 +0000

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 :)

Note: As I am personally using the zsh, I will talk of the .zshrc. Adopt it to fit your personal shell. Additionally, I’ll assume, that you know how to use git.

1. Creating the global configuration repository

First remark: This idea is to 99% based on this post I found. I’ll repeat it here nevertheless.

Create an initial directory to store the git data:
```
mkdir ~/.config.git
```

Create an alias for managing this special git repository:

alias config='git --git-dir=$HOME/.config.git/ --work-tree=$HOME'

Initialize the git repo:
```
config init
```
(Optional) To have your config status calls and similar not being cluttered with everything in your home directory, make git ignore everything :)
```
echo "*" >> .gitignore
```
Note that you now have to use config add -f to add files, because the “add” command will not add ignored files by default.
Add all the files you want to have managed to the reposority using config add -f. Do not forget the .gitignore, if you’ve done the step above.
Finally: Commit
```
config commit
```
(Optional, but suggested) Push your reposority to somewhere, where you access it from all the boxes needed. If you push to a public host: Take care, that there is no sensible information contained in your configs, like passwords or similar.
Example:
```
config remote add origin git@github.com:Necoro/dotfiles.git
config push origin
```

2. Initializing StGit

Note: A general StGit tutorial can be found here: http://www.procode.org/stgit/doc/tutorial.html
Note #2: All the following commands should be done in your home directory, because the/my current StGit version (0.14.3) seems not to handle such a strange setup :).

Yet another alias:
```
cstg='GIT_DIR=$HOME/.config.git stg'
```
Initialize your repo for cstg:
```
cstg init
```

Add your local settings as StGit patches:

cstg new some-cool-new-change
# ... hack ...
cstg refresh
cstg new yet-another-change
# ... hack....
cstg refresh
# ...

3. Modify your global settings

As StGit manages your patches as git commits, you cannot simply use git/config to modify the global settings. This would take your already applied patches and safe them in the history. Thus I will show, how to deal with it. As the example task: Add the two aliases we defined to .zshrc.

New method (needs stgit-0.15)

Create a new patch:
```
cstg new "temp-patch"
```

Do your change:

for i in cstg config; echo $(alias $i) >> ~/.zshrc

Refresh:
```
csgt refresh
```
Commit to git:
```
cstg commit "temp-patch"
```
Optional:Push to remote.
```
config push
cstg push -a
```
Note If you do not want to push to the remote, you still need to do
```
cstg push -a
```

I created a zsh-function for the complete procedure. You can find it here (the function “cci”).

Old method (prior to stgit-0.15)

Get rid of the current local patches:
```
cstg pop -a
```
Note: Use cstg pop -ak if you already made your changes

Do your change:

for i in cstg config; echo $(alias $i) >> ~/.zshrc

Commit:
```
config commit -a .zshrc
```
Push:
```
config push
```

Reapply patches:

cstg repair
# I haven't yet found out if this repair command 
# is really necessary always... 
# it seems to work without, so far
cstg push -a

4. Cloning on other hosts

Clone the repository. Example:

git clone git@github.com:Necoro/dotfiles.git

Move the .git directory to its final destination.
```
mv dotfiles/.git ~/.config.git
```
Get your old configs out of the way and make sure, that you have a backup of your local settings.
Copy your settings into the wild :). (Note that I use copy instead of move, as I have sometimes only parts of directories managed.)
```
cp -r dotfiles/.* ~
# also copy dotfiles/* if you have non-dotted stuff
```
Remove the dotfiles directory
Open another shell or re-login, so your new settings (especially the aliases) are loaded.
```
cstg init
```
Create your local patches

5. Conclusion

I have just “developped” this approach today (I think, there were already other guys having this idea :) – but I could not find something using a quick google search). So it really needs some testing to see if everything works out as expected. And a nice wrapper script should also be written to ease the work. Ideally you would only need config and not two different commands.

So — I’m going to test this on a couple of boxes and we’ll see where this ends :D.

Update I am currently thinking, whether a setup using only branches and using rebasing could achieve the same but being easier to manage. I have to test it :)