Friday 31 August 2007

handy stuff for reformatting text

<eddyp> anyone knows of a quick way to reformat a text to a certain with in vim?
<eddyp> width, even
<liw> !fmt -w 42
<pkern> Something along the lines of gq I think.
<pkern> {Visual}gq says :help gq
<eddyp> liw: ":%!fmt -w 42" should be correct
<eddyp> thanks
* eddyp notes the fmt command for future reference
<liw> fmt is a pretty handy command at times
<ricky> Wow, that is handy.
* seanius is a fan of the J and fmt combo
<pkern> (gq has the advantage that textwidth is obeyed. And fmt could be specified with formatprg.)
<eddyp> pkern: that gq is handy, too
<eddyp> "gggqG" and bam, everything is refromatted
<eddyp> does anyone mind if I post this on my blog?
<eddyp> pkern, liw, seanius, ricky ?
<liw> eddyp, nah
<pkern> eddyp: Please enlighten me why you could possibly need our approval (apart from copying the log verbatim perhaps).
<eddyp> pkern: exactly :-)
<eddyp> verbatim copy; irc is the best source of documentation :-)
<ricky> eddyp: Go ahead :)
<pkern> eddyp: Then please correct the obvious mistake of mine: ":help gq says {Visual}gq", hah. And I disagree on the usefulness of IRC logs as documentation. :-P
<ricky> As a side note, the -u option seems cut words at spaces properly, which I'd been looking for :)
<seanius> eddyp: if you find my armchair opinions valuable for some reason, then by all means :)

Friday 24 August 2007

Dear lazyweb...

Why do I get these errors in a real etch system and I don't in a pbuilder login environment? Missing build-deps?


# Add here commands to compile the package.
/usr/bin/make
make[1]: Entering directory `/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1'
/usr/bin/make -C doc
make[2]: Entering directory `/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc'
docbook2man uclean.sgml
Using catalogs: /etc/sgml/catalog
Using stylesheet: /usr/share/docbook-utils/docbook-utils.dsl#print
Working on: /home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:1:59:W: cannot generate system identifier for public text "-//OASIS//DTD DocBook V4.1//EN"
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:35:0:E: reference to entity "REFENTRY" for which no system identifier could be generated
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:1:0: entity was defined here
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:35:0:E: DTD did not contain element declaration for document type name
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:37:9:E: element "REFENTRY" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:38:15:E: element "REFENTRYINFO" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:39:12:E: element "ADDRESS" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:40:15:E: element "EMAIL" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:42:11:E: element "AUTHOR" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:43:19:E: element "FIRSTNAME" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:44:17:E: element "SURNAME" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:46:14:E: element "COPYRIGHT" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:47:11:E: element "YEAR" undefinednsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:48:13:E: element "HOLDER" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:50:12:E: element "DATE" undefinednsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:52:10:E: element "REFMETA" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:53:17:E: element "REFENTRYTITLE" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:55:15:E: element "MANVOLNUM" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:57:13:E: element "REFNAMEDIV" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:58:12:E: element "REFNAME" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:60:15:E: element "REFPURPOSE" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:62:17:E: element "REFSYNOPSISDIV" undefined
nsgmls:/home/eddy/usr/src/perso/build-area/svn-buildpackage-0.6.22~bpo40+1/doc/uclean.sgml:63:16:E: element "CMDSYNOPSIS" undefined

I am worried about my apartment mate

The last record of her laptop being on is:

syslog.4.gz:Aug 20 01:01:30 ritter dnsmasq[1984]: DHCPACK(eth0) ... endirra

I haven't seen her since, and her phone is off. I tried calling her before, but when it was on, she didn't answer. What is weird is that in the past, she didn't always answer the phone (or better said, seldom did).

Also, when she had a crush on some guy, she left for a whole week without saying anything...

But now I am worried.

Wednesday 22 August 2007

my nslu2 runs an eabi kernel

Thanks to Riku Voipio's advice, my slug now runs an EABI kernel with OABI compat support. As a bonus I have the latest 2.6.18-5 abi kernel :-) .

Things to remember when trying to do the same with your slug:
  • running make menuconfig (somehow) with the debian/arch/arm/config-ixp4xx file as config will, most definitely disable the compilation of the internal driver
  • before flashing a new linux image, check that the drivers for the network interfaces you expect to be up after reboot are present in the deb
  • arm iptables will fail with an eabi kernel, even if it has oabi compat support, you will need to install iptables in the armel chroot; so if you use iptables at all, you need to pass that invocation to the iptables binary from the armel chroot
I just chroot-ed into an armel chroot and rrdtool made some nice and meaningful graphs.

Instead of:


I got:



Some complaints:
  • migrating to armel will probably be a pain, if care is not taken to migrate settings, scripts and everything in /etc
  • the load spikes up just to make these graphs :-(

Saturday 18 August 2007

how did the Debian Games Team got rid of spam

How to get rid of most spam on Alioth mailing lists.

Until some Debian developer implements this idea in the BTS, the mailing list and in PTS, the quantities of spam that people get on the mail addresses they expose in the Debian world, the spam will keep on coming in huge quantities. I don't care that there will always be spam, I care that the amount of spam would be lower or probably nonexistent for one time sending (I sent just one mail to the BTS from two different mail addresses and it was enough to get huge amounts of spam on them).


The Debian Games Team's ML has suffered for a while, back in 2006, from spam bombing.
We thought that the easiest method to get rid of spam is to requires registration in order to be able to send mails to the list.

That was a big mistake because, as some people suspect, mails from the BTS needed to be allowed in and the reporters got an automated reply saying that the mail is waiting for approval, etc, etc - plain rude, people send you bug reports and you say "You are not listed, bla, bla bla". We changed the setting not to send any automatic reply and people were more content.

But still, we had to hand approve or white list valid mails/addresses. That worked for a while, but once the mail ended up on spammer lists, the thing blew out of proportions. We were desperate. We tweaked the settings of the lists in different ways, but in the end we ended up in having such a broken setup that we had to approve white listed addresses.

That did for me. I had to do something. So I started working on the ML setup and basically I did the following things to get rid of spam:
  • anything coming from white listed mail addresses was approved
  • black listed mails (bellsouth is one of those) is rejected (or should be)
  • anything that came from the BTS (there are some nice headers that the BTS puts) and was evaluated as ham with a score of 0 (there is a field for that, too - some field has Spam=No, Score=...) was allowed
  • anything that came from the BTS that was Spam=No with a score above 0 was held for moderation
  • anything else is held for moderation

This solution allowed us to lighten the burden of manually white listing every email address that ever sent valid mails to the BTS and to focus only on real spam.

Try it your self on your lists, you'll be pleasantly surprised.

Friday 17 August 2007

2 of the cross compiling issues...

... I found when trying to cross compile rrdtool already have a fix.
  • freetype's bug was fixed by somebody in gentoo and they sent the patch upstream; I tested the patch and it works
  • for the libart_lgpl bug I made a couple of (really non-instrusive) patches (one for the bootstrapped version and one for upstream source) and I sent them to both gnome and gentoo; as a bonus, libart_lgpl's art_config.h is now defined based on stdint. The definitions for ART_SIZEOF_* were removed since a grep on the source revealed that they are not used (confirmed by the fact that the source compiled).
I have these patches myself and they work. There shouldn't be any reason for the native build to fail.

The rrdtool issues [1] were not reported since:
  1. I am not sure if is really a bug (IEEE math test bug) and
  2. I don't have a clean fix (link-with-build's-library issue).



[1] look for 'xmerging rrdtool, the bugs don't stop'

Thursday 16 August 2007

too much to do, too little time

Short update:
  • I had no time to do hacking lately
  • there are too many mails on -boot; I wish they changed their minds and made a -boot-dev list, the BTS mails are incredibly annoying (yes, I made a filter, but is not that efficient); I am thinking seriousely about unsubscribing from that list
  • I would like to retreat from supporting the ppp-udeb package of ppp since I have no more interest in it; I already unsubcribed from part of the mails related to it
  • I have a new HDD from my router and is really silent :-) (some good news, at last)
  • glest-data contains some unclearly licensed stuff; imagine how nice is that when upstream is unresponsive (although not dead - adds new messages on the upstream forum, but never answers other's posts)
  • sorry for not having time to work on svn-buildpackage, glest, naughtysvn, wormux and oolite; I would really like NMU work on the debian packages (but I don't know what to say about svn-buildpackage since Eduard Bloch is the lead developer)
  • real life is taking is share back
  • I am thinking of upgrading to lenny in an attempt to motivate myself back into coding
  • aspell-ro with support for the correct diacritics should be uploaded soon in sid; cedilla support is dropped; minor obstructions in the way of the uplaod
  • LVM rules
  • RPM still sucks big time not because of itself, but because of the pure lack of tools for it
  • scons can't cross build
  • the freetype cross building bug (reported and found in gentoo) has a working patch; they claim they sent the patch
  • I got 2 cool presents for my birthday (27 now): an ASUS wl-500g Premium wireless router and a Fujitsu USB HDD
  • chroot-ing in armel from arm isn't possible (for me?):
ritter:/home/eddy# chroot /data/chroots/armel-root-fs/
Illegal instruction
ritter:/home/eddy# uname -a
Linux ritter 2.6.18-4-ixp4xx #1 Sun Aug 5 19:53:40 EEST 2007 armv5tel GNU/Linux
  • I no longer have this on my belly (it washed away):

  • the vacation was really great
  • I have too many interests in and outside of Debian, I'll have to cut back on some of them
  • Ross Burton rules because he wrote tasks and he maintains it properly

Wednesday 8 August 2007

small commits

Update: I have been informed that git and mercurial have support for the hunk commit feature, excellent! See the comments section if you want to know the details. IIRC, The last time someone talked about this feature was when John Gorzen analyzed his options for another VCS (still now I can't find any reference to this issue).


Lars, darcs allows this and, as a supplement that is missing from any other VCS I know, is the ability to select individually changes in a file. That means you can commit only some of the changes affecting a file and leave others for later commits.

So for this diff:

$ darcs diff -u
diff -rN -u old-asd/asdnbfnd new-asd/asdnbfnd
--- old-asd/asdnbfnd 2007-08-08 18:12:17.000000000 +0300
+++ new-asd/asdnbfnd 2007-08-08 18:12:17.000000000 +0300
@@ -1,3 +1,3 @@
-#!/bin/ash
+#!/bin/sh

-echo "intentionaol spelling error"
+echo "intentional spelling error"

you can do this:

$ darcs rec -m "spelling correction"
hunk ./asdnbfnd 1
-#!/bin/ash
+#!/bin/sh
Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help: n
hunk ./asdnbfnd 3
-echo "intentionaol spelling error"
+echo "intentional spelling error"
Shall I record this change? (2/?) [ynWsfqadjkc], or ? for help: y
Finished recording patch 'spelling correction'

$ darcs rec -m "make the script run on posix shell"
hunk ./asdnbfnd 1
-#!/bin/ash
+#!/bin/sh
Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help: y
Finished recording patch 'make the script run on posix shell'

Of course, being able to unrecord/uncommit or to rollback is a nice thing to have.

Bash says: I am different from myself!

Dear lazyweb, is this a bug? Should I fill this?

$ sh -x rpm/build_latest_srpm foo 2>&1 | grep -E '\'
+ alias 'rpmbuilder=rpmbuild --define "_topdir /tmp/rpmbuildarea/foo/redhat"'
+ rpmbuild --define '_topdir /tmp/rpmbuildarea/foo/redhat' -bs foo.spec
$ sh rpm/build_latest_srpm foo 2>&1 | grep -E '\'

$ bash -x rpm/build_latest_srpm foo 2>&1 | grep -E '\'
+ alias 'rpmbuilder=rpmbuild --define "_topdir /tmp/rpmbuildarea/foo/redhat"'
+ rpmbuilder -bs foo.spec
rpm/build_latest_srpm: line 46: rpmbuilder: command not found
$ bash rpm/build_latest_srpm foo 2>&1 | grep -E '\'
rpm/build_latest_srpm: line 46: rpmbuilder: command not found

$ rpm/build_latest_srpm foo 2>&1 | grep -E '\'
rpm/build_latest_srpm: line 46: rpmbuilder: command not found

$ type sh
sh is hashed (/bin/sh)
$ type bash
bash is hashed (/bin/bash)
$ ll /bin/*sh
-rwxr-xr-x 1 root root 677184 2006-12-11 23:20 /bin/bash
lrwxrwxrwx 1 root root 21 2006-08-17 21:05 /bin/csh -> /etc/alternatives/csh
-rwxr-xr-x 1 root root 80200 2007-02-02 09:34 /bin/dash
lrwxrwxrwx 1 root root 4 2006-12-19 15:02 /bin/rbash -> bash
lrwxrwxrwx 1 root root 4 2006-12-19 15:02 /bin/sh -> bash
lrwxrwxrwx 1 root root 13 2006-08-17 20:58 /bin/tcsh -> /usr/bin/tcsh


The script has /bin/bash in the shabang.

I tried to reproduce with another simpler script, and I observed that the issue happens when the script is processed by bash. With a /bin/sh shabang, it didn't since the command processing the script was sh, also all sh commands were ok.

I also suspect that it has to do with this paragraph from the bash manual:


Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using
shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).


... but different and (I would say) worse behaviour than the sh invocation should not happen.

The test script follows:

#!/bin/bash

alias rpm-build="echo \"I:\""
alias dpkg-select="dpkg --get-selections \"ls\*\""

echo "alias1:" && rpm-build test
echo "alias2:" && dpkg-select

Test and enjoy. Before you ask, yes, I use bash functionality.

Update: Also using set -i just before the alias definition and keeping it during the expansion does not help.

this is the way forward

leveraging existing technologies and obtaining cool things

Tuesday 7 August 2007

tilting at windmills - the NSLU2 issues

It turns out I was playing Don Quijote when I was trying to fix the reset issues I had with my slug.

Of course, I was suspecting the USB rack for the issues, but the issues never showed up on the laptop... until now.

I decied to temporary use a USB stick for the FS and started copying files over to the stick. During the copying the rack disconnected and everything became more clear. I was tilting at the windmills all the time.

BTW, be smarter than myself and just change the UUID to mach the old one instead of regenerating the initrd and reflashing it:

tune2fs -U the_uuid_of_the_previous_root_partition /dev/sda1


Oh, next on the agenda will be to use my ipod mini as a hdd for the slug in order to prevent ruining the stick... And another thing, total silence is really nice, even if the rack was not that noisy.

Monday 6 August 2007

nslu2, the kernel...

Update: it didn't work .... :((

eddy@ritter ~ $ grep '##### kern' -A 2000 /var/log/syslog | grep -E '(reset|####)'
Aug 6 11:19:00 ritter manual message: ##### kernel was changed to linux-image-2.6.18-4-ixp4xx_2.6.18.dfsg.1-12etch2.1_arm.deb #####
Aug 6 11:23:08 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:35:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:52:41 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:54:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2



I cross built this:

Changes:
linux-2.6 (2.6.18.dfsg.1-12etch2.1) stable; urgency=low
.
* Non-maintainer upload.
* ixp4xx kernel:
Disabled options:
- USB_EHCI_SPLIT_ISO
- USB_EHCI_ROOT_HUB_IT
Enabled options:
- USB_BANDWITH

And it took me on my amd64:

real 105m0.331s
user 79m43.423s
sys 12m46.324s

Is not an upload, is just my try to fix this issue. Let's see if it works.

Oh, thanks to Riku for pointing out that cross building the kernel is trivial.

Friday 3 August 2007

dear anonymous reader...

I have answered to your request about the config files for bluetooth.

Have fun!

more news from the nslu2 front

The main reason for the lack of activity during this week was that I had some problems with my router, a NSLU2 running the debian arm port. This was the machine I wanted the softfloat rrdtool I was talking about in these 2 posts.

It turns out that for some weird reason the USB controller of the slug resets when there is too much traffic going on. I got lots and lots of messages like:


$ grep reset -A 1 /var/log/syslog | grep -E '(reset|repeated)'
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
...
Aug 3 11:50:29 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:51:03 ritter last message repeated 4 times
Aug 3 11:53:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:53:46 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:55:48 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:07 ritter last message repeated 2 times
Aug 3 11:56:52 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:57 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2



That wouldn't have been a problem as long as the damn thing worked, but in some cases after the reset the root filesystem was lost and all the services running on the machine died (except the networking itself since all of that is part of the kernel and is loaded in memory).

It took me about three evenings to get to this conclusion (imagine being locked out of a machine which advertised running ssh, http, and dns services, being able to telnet and getting a respons, but the full protocol failed).

It all became more clear when, while being connected via ssh I got his result:

eddy@ritter ~ $ ls
-bash: ls: command not found

"WHAT?" was the first reaction, then I figured that life without ls is unbearable and came up with this bit:

alias ls='for I in * ; do echo $I ; done'

Quite cool to understand a little bit about the system. Still, cat was unavailable so having /proc and /sys available did not help that much. At some point I was thinking about a busybox shell, tried that, it didn't work since it wanted to remove some important bits like the initramfs tools.


I googled again and found a good starting point for a discussion of the same problem someone else was having. I ended up trying all the proposed solutions: rmmod-ing ehci-hcd, blacklisting the module, regenerating a initrd image with the blacklisted module... None of these worked (individually) and I ended up having an even more unstable system when ehci was not present (I was loosing the root FS after aprox. 1 min after logging in remotely immediately after start). Restoring the image with ehci was a pain (not to mention the time spent trying to figure a way to revert the change safely, since bricking the machine was not out of the question - imagine loosing the FS while flashing the ram drive image).

I finally managed to revert the ehci enabled image and tried the workaround proposed in this gentoo BR. I tried 128 and now I am at 64 and I am still getting those resets; Still something good came out of this, I followed Michael Prokop's Use root=UUID on NSLU2 article and I think I have now a stable root file system just thanks to him.

Now I am stuck:


grep -E '(max_sect|reset)' /var/log/syslog
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:27:38 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:38:43 ritter manual message: max_sectors was set to 128
Aug 3 08:55:25 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:31:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:54:11 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:09:32 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:15:27 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:24:24 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:38:12 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:47:04 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 10:48:27 ritter set_max_sectors: sda's max_sectors was set to 64
Aug 3 11:04:36 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:06:16 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
....
Aug 3 15:05:58 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2

Should I try setting to 32?

In case you're wondering, I am doing the setting with this script:

#!/bin/sh

MAX_SECTORS=64
DISK=$(ls -l `grep 'uuid.* / ' /etc/fstab | awk '{print $1;}'` | sed 's#.*/\(.*\)$#\1#' | tr -d '[0-9]')

[ -z "$DISK" ] && logger -t 'set_max_sectors' "error: could not detect root disk" && exit

echo "$MAX_SECTORS" > /sys/block/$DISK/device/max_sectors
logger -t 'set_max_sectors' "${DISK}'s max_sectors was set to ${MAX_SECTORS}"

exit 0


Dear (not at all) lazy web, what can I do to fix/workaround this issue? Any help would be gratly appreciated (personal mail or comments).

Note: I am reluctant to try the fix proposed in the last comment that claims to fix the issue since compiling an arm kernel natively is a pain and I would like to have an official kernel from Debian Etch, as I do now.

Thursday 2 August 2007

softfloat rrdtool sequel

Hey, I am back from vacation. I was back on Saturday but I didn't had the time to blog or do Debian work, so hello :-D.

After coming back from my vacation I went back to the softfloat rrdtool thingie I was working on before and I finaly managed to compile a statically linked softfloat uclibc rrdtool. Needless to say that I found that a pain and I ended up:
  • avoiding the Makefile and made the linking manually because:
    • for some unknown reason, the -static option didn't ended up in the final link call
    • libfreetype and libart_lgpl always were added as .so files... - libtool is probably the usual susupect, but I suspect the upstream libraries themselves
  • avoided (completely) using xmerge and used directly the source since:
    • CFLAGS="-Wl,-static" did not do the right thing (it didn't do in raw source, either)
    • I was about to make a static rrdtool, so I didn't needed gentoo's ebuilds at that point

If you are curious about the hideous details, just add a comment or email me and I'll send them or publish them.

So, in the end, I managed to produce a staticlly linked arm-softfloat-uclibc rrdtool which:
  • did not work directly on the .rrd files generated by the debian packaged collectd since they were "generated on another achitecture"; well with debian's rrdtool, 'rrdtool dump' was not that slow, so it was acceptable to dump with debian's rrdtool and restore with the statically linked one
  • generated graphs in about 1 minute (way slower than my amd64 machine, which does in 3s, but at least 100+ times faster than debian's arm rrdtool - remember, I tested the generation and it didn't finish the first graph not even after 50 minutes)
So that was fun. The total round trip for a round of graph generation was about 15 min which was more than cool and fast compared to the slow native variant, whohoo!

Now the downside, I am not through with it. If you look at the picture you'll notice that there is a "small-ish" problem: there are no scales, legends and no letters/glyphs of any kind, so the graphs are still quite useless, but better than nothing:


They should look something like this:




Notice any difference? :-/

Of course, I won't stop here!

I suspect the problems come from the cross compiled libfreetype and libart_lgpl, and I'll probably end up doing some native compiling after all, sigh!