**** BEGIN LOGGING AT Tue Oct 23 02:59:57 2007
Oct 23 06:23:15 <CIA-23> nbd * r9405 /trunk/ (3 files in 3 dirs): (log message trimmed)
Oct 23 06:23:15 <CIA-23> don't replace powerpc arch with ppc
Oct 23 06:23:15 <CIA-23> 'powerpc' is a valid arch for the LINUX_KARCH variable, but the build
Oct 23 06:23:15 <CIA-23> system unconditionally replaces LIUNUX_KARCH=powerpc with
Oct 23 06:23:15 <CIA-23> LINUX_KARCH=ppc.
Oct 23 06:23:16 <CIA-23> This change only does the replacement if LINUX_KARCH isn't set. This
Oct 23 06:23:18 <CIA-23> allows us to use the powerpc architecture.
Oct 23 06:23:21 <CIA-23> nbd * r9406 /trunk/toolchain/gcc/Makefile:
Oct 23 06:23:24 <CIA-23> openwrt: honour gcc extra configuration flags
Oct 23 06:23:25 <CIA-23> Although the CONFIG_EXTRA_GCC_OPTIONS flag is available, it isn't used
Oct 23 06:23:27 <CIA-23> anywhere.
Oct 23 06:23:30 <CIA-23> This change adds the extra flag to both gcc configure stages.
Oct 23 06:23:32 <CIA-23> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Oct 23 06:23:33 <CIA-23> nbd * r9407 /trunk/toolchain/binutils/ (Config.in Makefile):
Oct 23 06:23:35 <CIA-23> Add binutils extra configure options
Oct 23 06:23:38 <CIA-23> Currently, we can specify extra configure options for gcc, but not
Oct 23 06:23:39 <CIA-23> binutils.
Oct 23 06:23:42 <CIA-23> This change adds an EXTRA_BINUTILS_CONFIG_OPTIONS config variable,
Oct 23 06:23:44 <CIA-23> so we can add configure options for binutils.
Oct 23 06:23:45 <CIA-23> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Oct 23 06:23:49 <CIA-23> nbd * r9408 /trunk/include/ (kernel-defaults.mk kernel.mk): (log message trimmed)
Oct 23 06:23:59 <CIA-23> don't specify "CC=<nothing>" on kernel build command line
Oct 23 06:24:01 <CIA-23> If KERNEL_CC isn't set, we end up with a "CC=" on the kernel build
Oct 23 06:24:03 <CIA-23> command-line. We don't always need CC, as the CROSS_COMPILE flag does
Oct 23 06:24:06 <CIA-23> the job instead. In fact, specifying CC messes up the build when we're
Oct 23 06:24:07 <CIA-23> using a biarch compiler.
Oct 23 06:24:10 <CIA-23> This change doesn't specify CC= if the KERNEL_CC variable is empty.
Oct 23 06:24:11 <CIA-23> nbd * r9409 /trunk/include/kernel-defaults.mk:
Oct 23 06:24:14 <CIA-23> Use current UID for initramfs root user:group
Oct 23 06:24:16 <CIA-23> Set the CONFIG_INITRAMFS_ROOT_{U,G}ID kernel variables to the current
Oct 23 06:24:20 <CIA-23> user, so that all files end up being owned by root in the final
Oct 23 06:24:21 <CIA-23> initramfs image.
Oct 23 06:24:23 <CIA-23> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Oct 23 06:24:27 <CIA-23> nbd * r9410 /trunk/ (2 files in 2 dirs): (log message trimmed)
Oct 23 06:24:30 <CIA-23> Allow targets to specify extra initramfs source files
Oct 23 06:24:32 <CIA-23> The CONFIG_INITRAMFS_SOURCE Kconfig variable can be a space-separated
Oct 23 06:24:36 <CIA-23> list of source files (or directories). This allows a platform to
Oct 23 06:24:38 <CIA-23> add extra components to the initramfs image, by defining the
Oct 23 06:24:40 <CIA-23> INITRAMFS_EXTRA_FILES make var.
Oct 23 06:24:41 <CIA-23> By default, we add a simple initramfs extra file for the generic-2.6
Oct 23 06:24:44 <CIA-23> nbd * r9411 /trunk/target/linux/generic-2.6/base-files/init: (log message trimmed)
Oct 23 06:24:45 <CIA-23> only do hotplug2 init if hotplug2 is present
Oct 23 06:24:49 <CIA-23> (15 lines omitted)
Oct 23 06:25:21 <nbd> whee
Oct 23 07:22:51 <jk-> woot
Oct 23 07:30:17 <CIA-23> florian * r9414 /trunk/package/p54/ (13 files in 2 dirs): Add the prism54-mac80211 version from #2560
Oct 23 08:12:13 <blogic> jk-: did you submit those patches ?
Oct 23 08:12:19 <blogic> morning all btw
Oct 23 08:12:39 <juhosg> morning blogic
Oct 23 08:13:13 <CIA-23> florian * r9415 /trunk/ (9 files in 9 dirs): We are now at .23.1
Oct 23 08:13:49 <jk-> blogic: to openwrt-devel, yeah.
Oct 23 08:16:10 <blogic> jk-: cool
Oct 23 08:16:35 <blogic> i just added Xorg, but it is dependend on x86
Oct 23 08:16:43 <blogic> i guess i could extend that :P
Oct 23 08:16:45 <nbd> jk-: are you subscribed? i accidentally hit 'reply' instead of 'reply to all' when replying
Oct 23 08:17:04 <jk-> nbd: yep, just replied
Oct 23 08:17:24 <jk-> blogic: I don't think xorg would fit in our flash area :/
Oct 23 08:17:55 <blogic> how much flash is there ?
Oct 23 08:18:11 <blogic> and there must be usb ?
Oct 23 08:18:41 <nbd> jk-: before i can really address the problem, i will probably have to modify menuconfig
Oct 23 08:18:42 <jk-> i think we have 4MB, but I've had something dodgy happening when the image gets close to that; I don't know what the exact limit is.
Oct 23 08:18:59 <nbd> jk-: i need a way to preload config options with values from different config options
Oct 23 08:19:00 <jk-> yeah, there's USB. or access to the PS3 disk :)
Oct 23 08:19:21 <nbd> jk-: (the issues with cflags, compiler build options)
Oct 23 08:19:51 <ejka> or move them into target/
Oct 23 08:20:13 <nbd> ejka: ?
Oct 23 08:20:34 <ejka> cflags, compiler options etc
Oct 23 08:20:39 <nbd> that's what i'm talking about
Oct 23 08:21:28 <nbd> but simply moving the config options to the generated target menuconfig code messes up the menuconfig structure
Oct 23 08:21:39 <nbd> i want to keep the config options in the current menu
Oct 23 08:21:45 <nbd> but fill them with values from target/
Oct 23 08:23:17 <jk-> gotta run - thanks guys! :)
Oct 23 08:23:32 <ejka> the simplest way is to have things in Makefiles, overridable through menuconfig
Oct 23 08:24:09 <nbd> but when you're overriding through menuconfig, you typically want to see the default
Oct 23 10:46:24 <CIA-23> florian * r9416 /trunk/ (7 files in 7 dirs):
Oct 23 10:46:24 <CIA-23> The RB513 CF driver is now a module, enable it by default for the RB1xx profile.
Oct 23 10:46:24 <CIA-23> Fix the membase of the CF driver.
Oct 23 12:02:51 <CIA-23> ejka * r9417 /trunk/target/linux/ar7/image/Makefile: ar7: fix eva image generation
Oct 23 12:04:43 <nabcore> ejka; is https://dev.openwrt.org/ticket/2569 a bug or do I need to change my rx ring size?
Oct 23 12:05:47 <ejka> yes, it is a bug
Oct 23 12:05:48 <ejka> but I haven't been able to track it down yet
Oct 23 12:06:23 <nabcore> ah ok thanks... I just was not sure if I was doing something wrong
Oct 23 12:09:43 <nabcore> interesting AR7 coverage at the moment: http://www.theregister.co.uk/2007/10/22/zen_ar7_infineon_bt_fault/ and http://www.thinkbroadband.com/news/3257-dsl-modem-chipset-issue-comes-to-the-fore.html
Oct 23 12:16:24 <farnz> nabcore: My gut feeling (note ancedote, not data) is that the earlier DSP firmwares were going all-out for speed, and they're slowly stabilising as time goes on (7.02.01.00 is very stable here).
Oct 23 12:17:24 <nabcore> interesting
Oct 23 12:18:29 <nabcore> I must agree 7.02.01.00 has been very stable for me; but I've never had any issues with my line.
Oct 23 12:20:09 <farnz> My D-Link came with 4.something, and was unstable on a very good line.
Oct 23 12:20:25 <nabcore> Although, with recent openwrt builds, avsar_modem_stats seems to report nothing for SNRs: http://pastebin.ca/746672
Oct 23 12:20:26 <farnz> I'm now on a dodgy line, and 7.02.01.00 is stable.
Oct 23 12:20:52 <nabcore> look at {US,DS} Margin:
Oct 23 12:21:27 <farnz> nabcore: I've opened ticket #2532
Oct 23 12:21:43 <farnz> nabcore: You're using DSP 7.01.01.00 with drive 7.02.01.00
Oct 23 12:22:30 <farnz> And the comment from cfarinis@gmail.com suggests that I've not found the latest Annex B DSP.
Oct 23 12:23:28 <nabcore> root@Bunny:/proc/avalanche# dmesg  | grep ATM
Oct 23 12:23:28 <nabcore> [42949388.410000] Texas Instruments ATM driver: version:[7.02.01.00]
Oct 23 12:24:05 <farnz> That's the ATM driver, not the DSP firmware image.
Oct 23 12:24:24 <nabcore> ah ok
Oct 23 12:24:37 <farnz> In fact, I seem to have found DSP DSP Datapump version: [7.02.03.00] Annex A
Oct 23 12:25:12 <nabcore> farnz; I might just try your https://dev.openwrt.org/attachment/ticket/2532/ar0700xx.bin now and see what happens
Oct 23 12:25:19 <farnz> It's the avsar_ver file to look at.
Oct 23 12:25:59 <farnz> nabcore: /wii nabco	
Oct 23 12:26:14 <nabcore> farnz; you're right: http://pastebin.ca/746679
Oct 23 12:28:20 <nabcore> ok; brb
Oct 23 12:31:15 <CIA-23> juhosg * r9418 /trunk/target/linux/adm5120/files/ (3 files in 3 dirs): [adm5120] fix flash driver, it should work on RB150 as well
Oct 23 12:39:11 <nabcore> farnz; nice... it seems to have fixed it
Oct 23 12:40:47 <farnz> Would be nice to find the Annex B image, so that someone can close ticket 2532 by putting in the right DSP images.
Oct 23 12:42:17 <farnz> I've put what hints I can in the ticket, in case someone's on AR7 and has Annex B connectivity.
Oct 23 12:42:59 <nabcore> ok
Oct 23 12:43:09 <nabcore> I've updated the tickets with my findings as well
Oct 23 12:43:32 <nabcore> thanks for the pointers there farnz... this issue has been annoying me for a while
Oct 23 12:44:22 <farnz> No problem.
Oct 23 12:49:53 <nabcore> farnz; do you also see this: https://dev.openwrt.org/ticket/2377
Oct 23 12:51:26 <farnz> nabcore: I do, but abusing the IP175A switch is my next issue.
Oct 23 12:51:35 <nabcore> :)
Oct 23 12:52:24 <farnz> ejka gave me the pointers I need to make it work.
Oct 23 12:59:35 <nabcore> farnz; it must have taken a while to work out that it was the firmware causing the issues with the avsar_modem_stats
Oct 23 13:00:02 <nabcore> I initially thought it was connected to the increase in kernel version
Oct 23 13:00:52 <farnz> nabcore: It took very little time to work it out :)
Oct 23 13:01:40 <farnz> I noticed that the stats were wrong, looked and found the ATM driver change, so compared what OpenWRT had with the source Matteo got it from.
Oct 23 13:01:51 <nabcore> This took me *ages* https://dev.openwrt.org/ticket/2400
Oct 23 13:02:08 <matteo> farnz: so? you fixed it?
Oct 23 13:02:22 <matteo> well, i never looked at stats
Oct 23 13:02:57 <farnz> matteo: It's really simple; you picked up the new ATM driver, but missed the changed DSP.
Oct 23 13:03:31 <farnz> matteo: Ticket #2532.
Oct 23 13:04:12 <nabcore> matteo; it's looking good, just tested it.
Oct 23 13:04:31 <matteo> ah, the binary firmware?
Oct 23 13:04:35 <farnz> Yep.
Oct 23 13:04:47 <matteo> mm, don't have the old to compare
Oct 23 13:04:59 <matteo> are you usre that the last one is yours?
Oct 23 13:05:24 <matteo> any difference in connection?
Oct 23 13:05:29 <matteo> stabler, faster etc.
Oct 23 13:05:42 <farnz> Holds the link better when I run out of SNR margin.
Oct 23 13:05:46 <nabcore> well; it gives the correct stats and I'm connecting now
Oct 23 13:06:28 <farnz> I've got plain ADSL, not ADSL2+ though.
Oct 23 13:06:34 <nabcore> me too
Oct 23 13:07:12 <farnz> nabcore: Not according to your ticket; you're apparently using 2+, but with a fixed speed equivalent to BT's IPStream 2000 service.
Oct 23 13:07:20 <nabcore> really?
Oct 23 13:08:29 <farnz> nabcore: Compare the value in avsar_modem_stats for Trained Mode with the values in avsar_dsl_modulation_schemes
Oct 23 13:08:57 <farnz> At a guess, you're on Pipex in an LLU'd area.
Oct 23 13:09:06 <nabcore> yup
Oct 23 13:09:40 <farnz> They've moved you to LLU on their kit, but kept your service unchanged.
Oct 23 13:10:23 <nabcore> ah yes; ADSL_2plus                      0x10  == Trained Mode:           16
Oct 23 13:10:25 <slapin_birthday> ejka, hi
Oct 23 13:11:01 <slapin_birthday> ejka, git://ossfans.org/git/di524up.git
Oct 23 13:11:49 <nabcore> farnz; you're a wealth of information
Oct 23 13:11:56 <farnz> matteo: If you could push the binary firmware change through, it'd be appreciated.
Oct 23 13:12:48 <farnz> matteo: Finding the Annex B firmware could be an issue though, if I've not picked it up.
Oct 23 13:13:28 <nabcore> farnz; I think you're right https://dev.openwrt.org/ticket/2532#comment:1 did not test the annex B firmware properly
Oct 23 13:14:42 <farnz> nabcore: The symptom is there, but I could be in error, given that I just pulled apart the same package Matteo did, and looked for things he'd not noticed.
Oct 23 13:16:45 <nabcore> farnz... hmmm I'm noticing a problem: http://pastebin.ca/746733
Oct 23 13:17:16 <nabcore> the nonsense values are back
Oct 23 13:17:53 <nabcore> maybe it's a function of uptime?
Oct 23 13:18:10 <farnz> nabcore: That US margin looks like it's trying for -3 but printing as unsigned.
Oct 23 13:18:10 <nabcore> let me reboot
Oct 23 13:19:20 <loswillios> I have annex B
Oct 23 13:19:31 <loswillios> But unfortunately I can't test it until next month
Oct 23 13:19:58 <loswillios> because I only have ssh access over the internet
Oct 23 13:20:51 <nab-core> http://pastebin.ca/746737
Oct 23 13:21:20 <nab-core> weird
Oct 23 13:22:51 <nab-core> http://pastebin.ca/746740
Oct 23 13:23:25 <farnz> Possibly not a full fix, then.
Oct 23 13:23:29 <slapin_birthday> [florian], git://ossfans.org/git/di524up.gi
Oct 23 13:23:29 <nab-core> :(
Oct 23 13:29:32 <[florian]> slapin_birthday: thanks
Oct 23 13:31:41 <nab-core> farnz; can it physcially take on a value on -3?
Oct 23 13:32:41 <farnz> nab-core: Only for brief periods. -3 means that there's sufficient noise to overcome the signal completely.
Oct 23 13:33:02 <nab-core> ok
Oct 23 13:34:15 <nab-core> surely then, it should return to a positive value?
Oct 23 13:34:41 <nab-core> I'm seeing it "stuck" at 4294967273 now
Oct 23 13:37:00 <nab-core> in tn7dsl.c : http://pastebin.ca/746753
Oct 23 13:38:23 <farnz> nab-core: Might be worth seeing what happens if you enable the high precision mode in ADAM2.
Oct 23 13:40:14 <nab-core> Do you know offhand how to do that?
Oct 23 13:40:38 <farnz> It's a setenv of some form.
Oct 23 13:40:54 <nab-core> ok
Oct 23 13:43:23 <farnz> Unfortunately, I've just hit the tx dma ring bug that ejka's planning to look into :(
Oct 23 13:44:34 <nab-core> :)
Oct 23 13:44:52 <nab-core> brb
Oct 23 13:47:39 <nabcore> farnz; DGB34 > setenv high_precision 1 seemed to work
Oct 23 13:47:52 <nabcore> [42949388.040000] tn7dsl_init : env var high_precision is set.
Oct 23 13:48:08 <farnz> Does it solve the problem? If so, comment on the ticket.
Oct 23 13:48:15 <nabcore> testing now
Oct 23 13:48:44 <farnz> I can easily supply a patch for OpenWRT to force high precision despite the env var, if it makes things healthier.
Oct 23 13:50:12 <nabcore> farnz; I'm not sure if that has worked. http://pastebin.ca/746770
Oct 23 13:51:08 <farnz> Drat. Time to go hunting for new TI sources. Or rewrite the DSL stuff ;)
Oct 23 13:52:04 <nabcore> hehe
Oct 23 13:52:26 <nabcore> I don't recall this happening when openwrt was on a 2.6.19 kernel
Oct 23 13:52:55 <nabcore> circa r7000 ish
Oct 23 13:54:24 <farnz> It's not the kernel. It's the ATM driver and DSP firmware.
Oct 23 14:01:45 <nabcore>  diff sangam_atm-07.02.01.00  sangam_atm-07.01.00.10  : http://pastebin.ca/746777
Oct 23 14:04:02 <nabcore> hmmm really should have done that the other way around
Oct 23 14:05:23 <nabcore> ok; better: http://pastebin.ca/746785
Oct 23 14:05:59 <nbd> please use diff -u
Oct 23 14:06:48 <farnz> nabcore: diff -urNp sangam_atm-07.01.00.10 sangam_atm-07.02.01.00 please.
Oct 23 14:07:53 <nabcore> ok
Oct 23 14:08:04 <farnz> Gets a much more readable diff.
Oct 23 14:09:15 <nabcore> ok; sorry for that.
Oct 23 14:09:16 <nabcore> http://pastebin.ca/746792
Oct 23 14:10:20 <nabcore> around line 507 on that last link
Oct 23 14:11:19 <farnz> OK. First thing that's clear is that the only reason to not use high-precision is for userspace that parses /proc/avalanche/avsar_modem_stats
Oct 23 14:12:20 <farnz> Oh, and they've rearranged attenuation, margin and annex selected registers, to add an overhead register
Oct 23 14:13:17 <slapin_birthday> [florian], git://ossfans.org/git/di524up.git
Oct 23 14:13:36 <slapin_birthday> [florian], there's my full build system for firmware.
Oct 23 14:13:55 <slapin_birthday> [florian], so it is easy to reproduce toolchain bug.
Oct 23 14:14:09 <[florian]> slapin_birthday: ok
Oct 23 14:14:43 <slapin_birthday> [florian], are you going to look into this?
Oct 23 14:14:56 <[florian]> slapin_birthday: not now
Oct 23 14:16:01 <slapin_birthday> [florian], I meant if at all
Oct 23 14:16:36 <[florian]> slapin_birthday: not now means later, so yes
Oct 23 14:16:55 <slapin_birthday> [florian], thatks!
Oct 23 14:17:36 <nabcore> farnz; going between those sangham versions, dsMargin is now signed int, but in line 13 at http://pastebin.ca/746753 it is being printf(ed) as unsigned
Oct 23 14:17:39 <Weedy> "An ADSL modem disconnecting once or twice a day is probably acceptable to 99% of ADSL users" ahahahaha fuck no
Oct 23 14:18:29 <farnz> nabcore: Only if you're not in high precision mode. Still doesn't explain *why* it goes so negative.
Oct 23 14:18:33 <nabcore> sorry I mean usMargin
Oct 23 14:18:44 <nabcore> (but the same applies to dsMargin)
Oct 23 14:22:22 <nabcore> actually... I've lost myself a bit.
Oct 23 14:26:17 <Weedy> lol
Oct 23 14:28:31 <farnz> Weedy: For 99% of users, twice daily disconnections is a non-issue. You and I are in the 1%.
Oct 23 14:28:55 <Weedy> point
Oct 23 14:32:13 <farnz> My parents wouldn't notice a router that was offline from 9am to 5pm Mon-Fri, for example. Or one that was offline midnight to 6am.
Oct 23 14:46:59 <blogic> http://www.golem.de/0710/55577.html
Oct 23 14:49:49 <loswillios> nice
Oct 23 14:59:39 <slapin_birthday> do anybody aware of gcc backend docs for gccs around 3.3.3?
Oct 23 15:01:41 <slapin_birthday> I still try to find why my toolchain still emits lwl/lwr instructions
Oct 23 15:03:44 <slapin_birthday> [florian],
Oct 23 15:04:28 <[florian]> slapin_birthday: I have no docs about that
Oct 23 15:45:56 <CIA-23> matteo * r9419 /trunk/target/linux/ar7/files/include/asm-mips/ar7/gpio.h: ar7_gpio: remove unneeded checks and volatile
Oct 23 15:46:20 <shadsec>  Anyone knows how to disable soft reset on gpio 6 of fon2200 without patching the kernel?
Oct 23 17:03:15 <slapin_birthday> [florian], what do you think, is 7zip which realtek use = p7zip in debian?
Oct 23 17:06:12 <slapin_birthday> ejka, ping
Oct 23 17:07:23 <slapin_birthday> ejka, about this 7zip binary in firmware sources - is there any source for it? I just want to understand -k option
Oct 23 17:59:41 <slapin_birthday> do anybody knows where to get older source for 7zip to match realtek kernel?
Oct 23 18:01:27 <slapin_birthday> [florian], ejka: how big is 2.6 kernel on flash without lzma? is there lzma image support for 2.6 kernel? it seems realtek guys forgot to releaset source for 7zip
Oct 23 18:02:48 <slapin_birthday> [florian], ejka: is it possible to blindly replace old p7zip decompressor with new one?
Oct 23 18:13:24 <[florian]> slapin_birthday: I am not sure it is possible, some vendors do like to replace standard compressors with their ownn
Oct 23 18:15:02 <slapin_birthday> [florian], decompressor seems to be standard, but very old. and all signatures are ok.
Oct 23 18:15:54 <slapin_birthday> [florian], from source it seems they use 7zip-0.1 source, which I can't find anywhere.
Oct 23 18:15:55 <[florian]> slapin_birthday: then yes, go ahead replace it with your own
Oct 23 18:16:08 <slapin_birthday> current 7zip seems to be 0.2
Oct 23 18:18:14 <slapin_birthday> [florian], file zimage.7z
Oct 23 18:18:14 <slapin_birthday> zimage.7z: 7-zip archive data, version 48.107
Oct 23 18:19:50 <slapin_birthday> [florian], so format is changed. 7z at start is present though.
Oct 23 18:21:56 <slapin_birthday> [florian], is there any lzma-image patches for 2.4 kernel?
Oct 23 18:21:59 <[florian]> slapin_birthday: there might be some options to use 7zip with
Oct 23 18:22:05 <[florian]> slapin_birthday: look at brcm-2.4
Oct 23 18:22:13 <[florian]> slapin_birthday: the lzma-loader is kernel version independet
Oct 23 18:22:42 <slapin_birthday> [florian], in openwrt subversion?
Oct 23 18:22:55 <[florian]> slapin_birthday: absolutely
Oct 23 18:23:14 <slapin_birthday> [florian], thanks!
Oct 23 18:42:30 <slapin_birthday> [florian], they seems to use version field for their own flags, as I see...
Oct 23 18:46:22 <slapin_birthday> [florian], header looks the same, but algorithm used seems to be different :(
Oct 23 18:47:01 <[florian]> slapin_birthday: if it works, I guess the bootloader will accept it
Oct 23 18:48:04 <slapin_birthday> [florian], it seems that bootloader doesn't care, it will run decoder.
Oct 23 18:48:27 <slapin_birthday> [florian], so even zImage should work, but it will be bigger :(
Oct 23 18:51:09 <[florian]> slapin_birthday: ah the zImage is bigger with the newer tool ?
Oct 23 18:51:13 <[florian]> slapin_birthday: if so, this sucks
Oct 23 18:54:20 <slapin_birthday> [florian], I think I'll test that tomorrow anyway, thanks a lot for hints.
Oct 23 19:06:21 <CIA-23> pavlov * r9420 /packages/utils/rrdtool/Makefile: add librrd_th installation, needed for ntop
**** ENDING LOGGING AT Wed Oct 24 02:59:57 2007