gregoa's blog

first I was wondering why viewing photos with qiv takes so long. then I was wondering about the high incoming network traffic; netstat showed that it was coming from my laptop to my desktop machine.

then I realized that I had started qiv in the xterm that contained the ssh connection to the screen session on my laptop.

on 2007-04-03 I applied to become a Debian Developer; that means that today's my first anniversary of being in the New Maintainer process.

(details on the past & future steps & stages of my NM process can be found on my NM page).

update: DAM have reviewed my application on 2008-04-07, so "only" the actual account creation is missing.

after my laptop I tried to get 2.6.24 running on my desktop machine; several attempts (Debian kernels, self-compiled ones with different options) all led to the same results: a machine that feels rather unresponsive & where music has sporadic dropouts.

some searching on the intarweb showed that the new CFS scheduler (cf. Documentation/sched-design-CFS.txt) (at least the enabled-by-default CONFIG_FAIR_USER_SCHED flavour) might have latency problems, in itself or in combination with the ondemand CPU frequency scaling governor or with nice'd processes; after turning off all CONFIG_FAIR_* options in .config, recompiling & rebooting the machine seems to behave normally.

maybe I'm missing some great new features but actually I prefer a working desktop computer :)

update 1: approximately half an hour after the original blog entry I had my first "ion sorbet", i.e. a half-frozen ion3 (the applications are still running, I can switch to a tty but I cannot change/close/whatever ion3's frames). at the moment I have no idea what's going (wr)on(g) here ...

update 2: two more "ion sorbets" today yet; let's see if a new kernel (CONFIG_FAIR_USER_SCHED seems to be fixed in 2.6.24.1) & a new ion3 version help.

update 3: still the same problems (& inbetween some glitches with switching from X to a tty and back; I hope I solved them with some kernel config options); ATM I suspect ion3 to be the culprit; when it hangs it eats almost all the CPU, & strace'ing the pid gives only SIGALRM messages.

update 4: maybe I fixed the problem; by changing from ion3's deprecated statusbar_external.lua to the newer statusd_exec.lua (I just wanted to get rid of the error when starting ion3 ...).

update 5: & after compiling a kernel without PREEMPT ion3-statusd doesn't get stuck at using all my cpu every once in a while. or after removing some duplicated statusd_*.lua scripts. who knows.

update 6: nope, ion3-statusd is still hogging the cpu. argl.

update 7: I guess it's statusbar_external.lua's fault, as it happens on my other machine too.

no big step for humankind but I'm quite happy that linux 2.6.24 is finally running on my laptop (thinkpad R60e). the culprit that caused the freezes during earlier attempts was cpudyn; after deactivating it I had no more problems so far.

what's not working is ath5k which seems to dislike my wifi card; but the recent madwifi packages do what they are supposed to do.

JFTR:

• I grabbed the latest kernel snapshot from the Debian kernel team's repo.
• after reading #463353 I downloaded kel's source packages for madwifi-*, built them, installed them, & built the modules as usual with m-a.

now let's have a look at 2.6.24 on my desktop machine :)

finally I found the time to write down the configuration we use on our server to blacklist hosts that try to send emails to pre-defined nonexistent mail addresses. it uses only exim & postgresql & is (except for adding the "triggering" recipient email address patterns to the respective table) rather self-contained.

the documentation can be found in the article dynamic blacklisting with exim & postgresql. feel free to use/improve/comment/... the ideas!

an hour ago I received an email from my AM who considers my packages to be in good shape; that means that the "Tasks and Skills Check" part of my NM process is finished. & wouter has also already sent the NM report mail including his recommendation to accept me as a DD to debian-newmaint! so only FD review, DAM review, & account creation are lying ahead of me.

I'm indeed quite happy tonight :)

due to the latest changes in apt (which installs packages marked as Recommends: by default since 0.7.7) aptitude — even if "Install recommended packages automatically" is not checked in aptitude's options dialog — pulls in recommended packages just like apt-get, whether called from the command line or interactively; cf. also #448561.

the fix to keep both apt-get & aptitude from installing recommended packages is something like:

$ cat /etc/apt/apt.conf.d/15recommends
APT {
        Install-Recommends "false";
};

(also very useful for (p|cow)builder where installing recommended packages in the chroot is just wrong & takes a long time; cf. also #448562.)

after a little communication problem between my Application Manager & me I got an email today stating that T&S 2 (the second set of questions in the "tasks&skills" part for my New Maintainer process) is finished, too.
the next part will now be a check of my packages which will be interesting, too.

gudrun lent me her old TFT (thanks!); it's small (15") but works much better than the crappy old CRT I've been using for the last two days. at least I won't turn blind until the samsung 226bw I've ordered today will arrive.

& philipp hast lent us an old machine called "phercab" (thanks!) which has become guinan's fourth host body; i.e. I put the two disks (& the NIC) into the machine, & after a little fsck'ing guinan is up & running again.

coming home after a long work day I detected a strange smell in my room; after some investigation it turned out that guinan's motherboard has melted down; i.e. her third host body is dead for sure (offers for a replacement welcome). well, no flat server at the moment.

more unpleasant is that it seems to have killed (via the kvm switch) my TFT; need to check again, call the insurance company, probably buy a new screen. — currently I'm typing in front of an old & not very healthy 15" CRT; I hope the problem is fixed before I turn blind.

(oh, BTW, the kvm switch might be dead, too, at least keyboard & mouse have stopped working several times.)

good news: my hero&hausmasta chrisu has soldered a — whatever, the part to be able to connect to the serial port in my bricked fonera, & after changing the RX/TX cables it really works with the serial extension cable I have (& cutecom as a terminal app).

some times later it works ("works" as in: I successfully re-flashed & therewith de-bricked kes). the key was not to transfer the needed files via cutecom and the xmodem protocol but via tftp.

helfpul links:

• Fonera - Debricking and more
• Reflashing LaFonera original firmware