Today I have compiled 2.6.24-rc1 (from wireless-2.6 git) for testing the ath5k driver. Well, ath5k does not work as expected, but that’s not the topic of this post.
After Thomas ‘tglx’ Gleixner has said me, the his hrt patches are no longer needed with 2.6.24-rc1, I wanted to check that with powertop.
During the check, powertop complained about CONFIG_ACPI_BATTERY not being set, and I was like "WTF o_O", because I used the .config of my 2.6.23 and just added the ath5k stuff to it.
The option really wasn’t set, and I also could not find the switch in menuconfig, where it always has been.
After a small search and the help of ong from #powertop, I found the solution.
CONFIG_ACPI_BATTERY now depends on POWER_SUPPLY (it’s Device Drivers -> Power supply class support), which was not enabled by default, and also was not enabled as a dependency of an enabled option…
Well, after enabling POWER_SUPPLY, ACPI_BATTERY was back again.

Some time ago I started using Git. First for fetching the latest versions of drivers (radeon and radeonhd) and now also for storing my own stuff in it. I won’t tell you, why git is so good and so sexy, and why all the other systems suck (well, some really do, some not), but just how to setup a repository and publish it to everyone.

Imagine you have two computers, one called client, and one called server. On the client you will create a repository, push it to the server and from there anyone will be able to fetch it via git or http (or view it via gitweb).
For easier reading, I will mark shell-commands on the server with a s, and on the client with a c. Additionally I will add an $ for user-run commands, and # for root-run. So a command run as root on the server would look like:
s# command

The first step is (as usual) installing some packages. On the client-side git-core should be enough, but don’t miss the completion of zsh – you’ll love it. On the server-side you need git-core, git-daemon-run and gitweb, you also need an cgi-enabled webserver (I use Apache here, but won’t talk about it largely).

Now we can create a repository on the client:
c$ mkdir ~/gittest
c$ cd ~/gittest
c$ git-init-db (or git-init when you use something never than Etch)
put some files into ~/gittest and read the nice git cheat sheet
c$ git-add .
c$ git-commit

You now have a git-repository on your computer. This repository can be pushed to the server.

On the server we need a directory where the stuff will go, e.g. ~/gittest/.
s$ mkdir ~/gittest
s$ cd ~/gittest
s$ git-init-db (or git-init when you use something never than Etch)

The server-side is ready for receiving the data, so on the client we do:
c$ git-push ssh://server/~/gittest master
<type in your ssh password>
The repo should be synced now and ready for going public.

For gitweb, just login as root on your server and do the following:
s# cd /var/cache/git
s# ln -s ~user/gittest/.git/ gittest (note the .git folder!)

http://server/cgi-bin/gitweb.cgi/ should now list the gittest repository and you are done.

So gitweb is done, git:// and http:// fetching to go.

Let’s start with git:// one, this is done by git-daemon. It is already running, as you have installed git-daemon-run.
But the repository is not exported by default, you need to do a
s$ touch ~/gittest/.git/git-daemon-export-ok[/b]
And ready, git-daemon exports the repository to git://server/git/gittest/

What comes after git://? Right, http://!
This looks easy, but has a nice possibility to fail, so read on.
The webserver should be configured to follow symlinks, then (on the server):
s# mkdir /var/www/git
s# cd /var/www/git
s# ln -s ~user/gittest/.git/ gittest (note the .git folder!)
From now, you can access the gittest folder by http://server/git/gittest, but git cannot. git clone fails with something like:

Initialized empty Git repository in /home/zhenech/gittest/.git/
cat: /home/zhenech/gittest/.git/refs/remotes/origin/master: Datei oder Verzeichnis nicht gefunden
cd: 464: can’t cd to /home/zhenech/gittest/.git/refs/remotes/origin
fatal: : not a valid SHA1
fatal: Not a valid object name HEAD

The solution is easy, but I needed about an hour to find it. Just run the following command on the server:
s$ git-update-server-info

As you will need to run it, after each git push, just enable the post-update hook of the repository, by doing:
s$ chmod +x ~gittest/.git/hooks/post-update

Now you’re done, and your repository is available via gitweb, git:// and http://
But you probably want to have a look at .git/description and .git/cloneurl. The first one contains the description (really!) of the repository, this will be shown by gitweb, and the second contains urls, one per line, those will also be shown by gitweb, so your users will know where actually to fetch the stuff.

At the moment, I’m doing much stuff in LaTeX for my study. And Kile seems to be the editor of choice here.
But there is one bad thing with Kile, it’s a KDE-app, which behaves – well – KDEish :(

Today I wanted to enable spell checking in Kile, which should support aspell and ispell. As aspell was already installed on my system, I assumed, it would "just work". But clicking Tools > Spelling just gave me
"The spelling program could not be started. Please make sure you have set the correct spelling program and that it is properly configured and in your PATH."
Aspell is in my PATH and works perfectly for all the other apps (Gajim, Sylpheed, XChat).

So I started googling for a solution. It looked like Kile was defaulting to ispell, and you could set it to aspell in kcontrol.
My system runs Xfce, so no kcontrol for me (I could install it, but who wants this KDE-stuff?).
So there seem to be two solutions for me:
1. Install ispell (what I don’t want, why having multiple spell-checkers installed?)
2. ln -s /usr/bin/aspell /usr/local/bin/ispell (yeah, that works, as aspell is a drop-in replacement for ispell)

But wait, where is the how not to make a website part? Here it is:
On my journey, I found this blog-post: http://andrewjpage.com/index.php?/archives/93-IASpell-could-not-be-started-in-Kile.html (yes, not linked). Running Iceweasel with AdBlock, the page looked like:

Wtf?! I’m not allowed to see the content, just because I block stupid ads?

Wollte grade hier evince-gtk aus experimental installieren, und stolperte über:
Get:6 http://ftp.de.debian.org experimental/main evince-gtk 2.20.0-1 [1337kB]

Scheiße ist das leet!
Und ja ich weiß, der Post hat in etwa 0 Sinn :)

Ich nutze Linux, ich mag keinen Jobs und werde mir sicherlich nie DRM verseuchte Musik kaufen^Wmieten.
Aber es geht ja eigentlich auch anders. Sogar kostenlos – bei Jamendo nämlich, da kann man einfach so legal Musik saugen.

Denkste…

Vor einiger Zeit habe ich die Band pornophonique kennen gelernt, und fand die Musik einfach nur geil: Gitarre, Gameboy und C64…
Und genau diese Band hat vor kurzem ein Album herausgebracht: 8-bit lagerfeuer. Und das komplett kostenlos (wenn man MP3 mag, CDs gibt’s aber auch zu kaufen).
Leider ist die Version auf der Homepage der Band nur 128kbit/s, aber dort ist auch das vorhin erwähnte Jamendo verlinkt, wo man 192kbit/s MP3 oder 300kbit/s OGG kriegen kann.

Ich korrigiere, kriegen sollte. Da so ein Musik-Anbieter einiges an Traffic verbrutzelt, wird dieser auf P2P abgeschoben, nämlich eMule und BitTorrent – würd ich für die Musik zahlen würd mir das stinken, bei einem kostenlosen Angebot finde ich’s aber nicht so schlimm.
Schlimmer ist aber, dass man die Daten dann doch nicht kriegt.
Am 2ten Oktober, gegen 21Uhr hab ich mein BitTornado angeworfen, und ihn sowohl mit der MP3 als auch der OGG Version gefüttert, mal sehen was schneller fertig ist. Einen eMule Client habe ich hier nicht, und will auch keinen haben.
Bis heute ist kein einziger Byte Daten hier angekommen, und der Tornado meldet mittlerweile
Problem connecting to tracker – [Errno http error] 503: ‘Service Unavailable’

Gut, also doch nur 128kbit/s MPblöd… Schade eigentlich, denn die Mukke ist recht nais, und ich glaube ich werde mal das Album kaufen. Nicht unbedingt weil ich es so absolsut geil finde (es ist dennoch ziemlich gut), sondern weil ich die Band supporten möchte, damit die sich Traffic leisten können, und das nächste mal das Album als FLAC online stellen ;)

Und was lernt man daraus? Will man gute MP3/OGG haben, muss man CDs kaufen und selber rippen (natürlich nur die ohne Kopierschutz, denn wir wollen ja keine Straftat begehen und die UnCD-Industrie fördern… Ich glaub da fehlt ein Komma).
Auf jeden Fall ist Jamendo wohl interessant, aber etwas kaputt :(