[00:39] <blux> what the hack is so magig an address 0x1c001000: ???? erverytime debrik fails at this address
[04:49] <Bartman007> looks like the new version of madwifi isn't working on xscale... http://www.padded-cell.net/openwrt/errors/armeb_madwifi
[04:58] <CIA-17> nbd * r4703 /branches/buildroot-ng/openwrt/package/madwifi/patches/100-kernel_cflags.patch: remove -mapcs-32 from madwifi xscale build
[04:58] <nbd> Bartman007: :)
[04:59] Action: Bartman007 svn updates
[05:02] <Bartman007> damn I wish I could get a 15k rpm hd for this laptop, svn updates so slowly.
[05:02] <Bartman007> though on the otherhand, I wouldn't want my laptop to melt.
[05:03] <Exiles> I'm wanting to get a nice 10k rpm drive sata
[05:03] <Exiles> I wish 15k drives came in sata
[05:15] <Bartman007> nbd: a make package/madwifi-clean should be sufficient, shouldn't it?
[05:16] <nbd> yeah
[05:16] <Bartman007> if so, similar error, here's a diff
[05:16] <Bartman007> 8d7
[05:16] <Bartman007> < cc1: error: invalid option 'apcs-32'
[05:17] <Bartman007> full updated error is at the same location
[05:21] <CIA-17> nbd * r4704 /branches/buildroot-ng/openwrt/package/madwifi/patches/ (100-kernel_cflags.patch 101-no_werror.patch): add no_werror patch again, fix xscale cflags
[05:21] <nbd> there you go
[05:25] <Bartman007> works now
[05:26] <Bartman007> florian: the md5 sum of the updated aircrack-ng source is wrong
[05:33] <Bartman007> valid md5sum should be 8a72ad4746752dac9127edb3b41f6274
[05:38] <Bartman007> next issue: mt-daapd is another package with the No rule to make target `all' issue
[06:02] <CIA-17> nbd * r4705 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: enable math emulation
[06:08] <CIA-17> nbd * r4706 /branches/buildroot-ng/openwrt/package/base-files/default/etc/config/ (. network): add default /etc/config/network
[06:09] <CIA-17> nbd * r4707 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/patches/ (001-magicbox_support.patch 002-flash_map.patch): split magicbox patch
[06:26] <CIA-17> nbd * r4708 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: remove useless junk
[06:26] <groz> sheesh nbd, after all those commits putting it in, now you are calling the mb 'useless junk' :)
[06:27] <nbd> ?
[06:27] <groz> the last config 'remove useless junk'
[06:27] <nbd> well, i removed useless junk from the config :)
[06:27] <groz> err.. commit
[06:46] <CIA-17> nbd * r4709 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: remove even more stuff
[07:12] <Bartman007> nbd * r4710 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/config: remove the kitchen sink
[07:12] <CIA-17> nbd * r4710 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/patches/002-flash_map.patch: update flash map driver for jffs2, squashfs will follow later
[07:14] Action: nbd goes to sleep
[07:14] <nbd> good night, everybody
[07:14] <Bartman007> night
[07:14] <groz> cya
[07:14] <groz> but, put the sink back before you get up to shave in the morning
[07:14] <nbd> hehe
[07:15] <Bartman007> on a side note, are the No rule to make target `all' problems easily fixable?
[07:16] <Bartman007> if there is some easy fix in virtually all cases I'd be happy to start submitting patches when I run into them.
[07:16] <groz> usually just add an alias to the makefile
[07:16] <groz> will do it
[08:30] <[mbm]> Bartman007: usually that's an indication that the configure script has failed and there isn't a valid makefile
[08:32] <Bartman007> ok. I haven't ever had to actually deal with make and haven't had the time to actually look at the Makefiles other than quick glances.
[08:37] <Bartman007> maybe one of these days I'll be able to sit down and figure it out.
[08:38] <[mbm]> basic makefile is easy
[08:38] <[mbm]> foo:
[08:38] <[mbm]> command to amke foo
[08:38] <[mbm]> ..
[08:39] <[mbm]> what openwrt does with some of it's makefiles is well, nasty
[08:40] <Bartman007> yeah, that's what has thrown me off. I've been able to follow the basic structure of some of them, but quite a few that I've glanced through just make me stop and say "wtf???"
[08:40] <[mbm]> make really isn't designed to do the things we're trying to do
[08:41] <[mbm]> weve written it so most of the ugly details are hidden in makefiles few people will ever have to deal with
[08:49] <CIA-17> florian * r4711 /packages/net/aircrack-ng/Makefile: Update md5sum
[08:52] <Bartman007> hey
[08:55] <florian> thanks Bartman007 for the md5sum thouhg it was updated
[08:56] <florian> mt-daapd compiles fine for me (fc4)
[08:56] <florian> not yet tried on my gentoo x86
[08:58] <Bartman007> well, if it helps, http://www.padded-cell.net/openwrt/errors/armeb_mt-daapd
[08:59] <[mbm]> useless log .. try "make package/mt-daapd-{clean,install} V=99"
[09:02] <Bartman007> complete output appended to that file
[09:02] <florian> Kaloz: what about installing our own pastebin ?
[09:03] <[mbm]> Bartman007: umm doesn't look like the package is selected in the configs for that second part
[09:03] <Bartman007> florian: is there an advantage to using that vs any of the others?
[09:03] <Bartman007> [mbm]: yeah, oops, forgot I deselected it....
[09:03] <florian> Bartman007: this is because I don't know if there advantages using ours that I ask
[09:03] <Bartman007> no, it's reselected.
[09:04] <florian> I guess it could ease ticket reporting in some ways
[09:04] <Bartman007> could have a bot in the channel like CIA or wrt announcing pastes
[09:04] <Bartman007> and potentially you could add some syntax coloring....
[09:06] <Bartman007> [mbm]: hold on a sec...
[09:07] <Bartman007> it blew the mt-daapd, that's why it looked weird
[09:07] <Bartman007> mt-daapd dir.
[09:13] <Bartman007> here, we go, more info, http://www.padded-cell.net/openwrt/errors/armeb_mt-daapd
[09:13] <[mbm]> told you; configure failed.
[09:14] <florian> Bartman007: have you also symlinked gdbm,libid3tag and howl ?
[09:15] <Bartman007> florian: libgdbm, libid3tag and howl, yes.
[09:16] <Bartman007> [mbm]: yeah you were right (though I don't recall saying otherwise)
[09:17] <florian> Bartman007: that's weird they should get installed before mt-daapd compiles
[09:18] <Bartman007> if you want I can do another make dist-clean to confirm, but I did one last night to track down another issue.
[09:19] <Bartman007> I have all package dirs from openwrt/packages/ symlinked and have it set to build all packages (minus the java related stuff)
[09:22] <Bartman007> I'm confused as to why `make package/mt-daapd-{clean,install} V=99` didn't work correctly, whereas `make package/mt-daapd-clean; make V=99` did.
[09:22] <[mbm]> order
[09:39] <Kaloz> florian: that's a bit further in our world domination plans, isn't it?
[09:40] <florian> Kaloz: yes the brain :)
[10:02] <[mbm]> the sablevm-classpath package makefile is wrong
[10:05] <groz> no
[10:06] <groz> your menuconfig is wrong, it includes sabler
[10:06] <groz> sable
[10:06] <[mbm]> the prereqs check on sablevm-classpath is wrong
[10:07] <[mbm]> RequireCommand can't actually handle multiple commands being specified like that
[10:18] <murb> has anyone looked at usb connected vga adaptors?
[10:22] <groz> never even heard of such a thing, do they exist ?
[10:22] <Bartman007> yes they do exist
[10:22] <groz> i've heard of various display devices, but find it hard to believe they attempt vga compatible
[10:22] <Bartman007> usb 2.0 SVGA adapters are not uncommon.
[10:23] <groz> but vga is a register specification
[10:31] <jr--> i have usb vga adaptor. there's even linux drivers for it.
[10:32] <groz> is it truely a vga, or is it just a display with 'vga resolution' ?
[10:33] <murb> probably the latter.
[10:33] <groz> either way, i'm intrigued by the prospect
[10:34] <groz> but, the bandwidth over usb, even usb2, dont think it'll come close to whats needed for any kind of animated display
[10:37] <[mbm]> depends on the resolution, depth and refresh rate
[10:38] <[mbm]> the dongle will just be a framebuffer, constantly displaying the contents of it's memory
[10:39] <jr--> groz. http://www.winischhofer.at/linuxsisusbvga.shtml
[10:41] <murb> well we need something for the new gui/X.org openwrt front end, and we only have 7 months.
[10:43] <groz> ??
[10:43] <groz> why do we need a gui, and where does the 7 month timeframe come from ?
[10:43] <murb> groz: 4/1 or 1/4
[10:44] <groz> ahh
[10:44] <groz> ok
[10:44] <groz> but, that's for the kool-aid branch
[10:44] <groz> so, functionality after install ins't a high priority requirement :)
[10:53] <groz> interesting device, just reading up on it
[10:53] <groz> seems to be an sis 315 with 1 meg of ram
[10:53] <groz> just sitting there operating as a dumb frame buffer
[11:23] <[mbm]> hmm .. why do we have a "sound" category and a "multimedia" category?
[11:23] <[mbm]> isn't sound multimedia?
[11:24] <Kaloz> sound itself is singlemedia
[11:24] Action: Kaloz hides
[11:24] <Kaloz> ;)
[11:25] <[mbm]> Kaloz: what about stereo sound?
[11:25] <Kaloz> well, multimedia means sounds and video in the same time :) but whatever, i was just kidding
[11:26] <[mbm]> I know ;)
[11:26] <[mbm]> mono is single, stereo is double, surround is multi ;)
[11:27] <groz> all forms of sound, one media
[11:27] <groz> all forms of video, another media
[11:27] <groz> multimedia implies more than one media
[11:27] <groz> and it's one of the most over abused buzzwords ever created
[11:27] <[mbm]> heh
[11:31] <[mbm]> hmm I think I just found a major hole in our dependancy system
[11:31] <groz> oh, where is that ?
[11:32] <[mbm]> let's say I start with a default config file
[11:32] <[mbm]> and I then select mt-daapd
[11:32] <[mbm]> that depends on libgdbm libhowl libid3tag
[11:33] <[mbm]> but those aren't selected in config
[11:33] <groz> you wouldn't have this problem if you weren't trying to turn a router into a sterio
[11:33] <groz> :)
[11:33] <[mbm]> well, I'm giving this as an example
[11:33] <groz> hehe, and i'm being cynical
[11:34] <[mbm]> mt-daapd-compile: libgdbm-compile howl-compile libid3tag-compile
[11:34] <[mbm]> that's .pkgdep
[11:34] <[mbm]> but, the important thing is that since those packages aren't actually selected in the config
[11:34] <[mbm]> the -compile commands are no-op
[11:34] <groz> ok, now, shouldn' tthey actually end up selected automagically
[11:35] <groz> if they are dependants ?
[11:35] <groz> is this a dependancy problem, or, a config problem ?
[11:35] <[mbm]> hmm ..
[11:35] <[mbm]> something odd is going on here
[11:35] <groz> there's plenty of examples like that in the kernel itself
[11:36] <groz> where you select item x, and it causes y and z to be selected
[11:36] <[mbm]> right, I know that
[11:36] <[mbm]> thing is I added a new rule to package.mk to warn me when a package isn't selected in the config
[11:36] <[mbm]> and I'm hitting it on all the deps
[11:37] <groz> but, the way it's all glued together here, system may be missing or skipping that bit
[11:38] <[mbm]> oh .. wait a sec
[11:38] <[mbm]> packages/libs/howl compile
[11:38] <[mbm]> ERROR: howl-utils must be selected in the config before it can be compiled
[11:38] <[mbm]> ERROR: autoipd must be selected in the config before it can be compiled
[11:38] <[mbm]> ..
[11:38] <[mbm]> it's not complaining about having to compile libhowl
[11:38] <[mbm]> it's complaining about the other packages which are part of the same makefile
[11:39] <[mbm]> hrm ..
[11:43] <groz> is there an easy way to check a file to see if it's been sparsely allocated ?
[11:45] Action: [mbm] changes it from an error to a warning
[11:45] <[mbm]> now it looks like
[11:45] <[mbm]> WARNING: skipping sablevm-classpath-full -- package not selected
[11:45] <[mbm]> which is better
[11:46] <[mbm]> the intent is that if I did "make package/foo-compile" it would tell me that it didn't do anything
[11:46] <[mbm]> instead of just being silent
[11:46] <groz> you know what that'll do
[11:46] <groz> it'll make all those failed compiles way to easy to track down why they failed
[11:47] <[mbm]> exactly :P
[11:48] <groz> another one i've been wondering about, something like a 'tools dependancy'
[11:48] <groz> so, to compile package x you need tool y installed on the host
[11:48] <groz> but that gets a lot messier
[11:48] <[mbm]> that's the RequireCommand macro
[11:49] <groz> ok, so then it's there, just not implemented in all of th epackage defs
[11:49] <groz> i forget which it was, think it was part of the sable stuff
[11:49] <groz> complained here about cant run javac
[11:49] <groz> which wasn't on my machine
[11:49] <groz> but that was a while back, and i've never looked at it again
[11:49] <CIA-17> mbm * r4712 /packages/lang/sablevm-classpath/Makefile: Fix the RequireCommand macro
[11:50] <[mbm]> heh, that?
[11:50] <groz> heh
[11:57] <groz> i've been working here on building up a few test cases
[11:57] <groz> one of them is to run pptp thru it's paces, as well as testing the conntracks for it etc
[11:57] <groz> basically works like this so far
[11:57] <groz> first we bring up one uml, with 2 'eth' connections via a pair of umlswitches
[11:58] <CIA-17> mbm * r4713 /branches/buildroot-ng/openwrt/include/package.mk: Add new warning to help track down pesky compile issues
[11:58] <groz> then it brings up another uml, that becomes a 'client' behind the first one
[11:58] <groz> first step, run a bunch of pptp connects with various forms of mppe from the 'front' router of the pair
[11:58] <groz> then when that's all done
[11:58] <groz> repeat the tests but have the pptp client coming from the one 'behind' the front router
[11:59] <groz> then, the beind one changes it's mac address to pretend to become a different client
[11:59] <groz> and repeats the tests again
[11:59] <groz> that exercises the pptp system, and all the contracks associated with it
[11:59] <groz> does that sound like the right kind of stuff we should build for automated testing ?
[12:00] <[mbm]> sounds like a good test
[12:00] <groz> i'm looking at how to generalize this methodology
[12:00] <groz> right now, it's hard wired scripts
[12:00] <groz> but i'm contemplating ways of generalizing it a bit
[12:01] <groz> so the framework of bringing up a cascade of umls is re-useable for various other tests
[12:01] <groz> thinking of what other kinds of tests to do like this
[12:01] <groz> another i have working reasonably well is the full exercise of the dhcp server
[12:02] <groz> bascially the client keeps changing mac address till the server runs out of leases
[12:02] <groz> then it waits till the least time is up
[12:02] <groz> and confirms that the server will indeed recycle them onto 'yet more' new clients
[12:02] <groz> by just constantly changing the mac address of the client, then run udhcpc
[12:02] <groz> and test to see that it indeed got a lease
[12:03] <groz> wondering if a wish list of tests is probably a thing to start a fresh wiki page on
[12:04] <groz> then see if we cant migrate to a methodology of create bug reports with a test script, then commit the test that creates the problem, along with it's solution, so that test becomes part of the 'normal tests' later down the road
[12:06] <florian> re
[12:08] <groz> the way i've started fleshing it out, when i build my initial root file systems, i'm injecting one init.d script in there, that parses something out of the env, then ipk-installs that
[12:08] <groz> so when i bring up the two umls for this test, they each ipkg install a separate test package, which then proceeds to run the tests
[12:09] <groz> the env var goes in as a command line option to the startup of the uml kernel
[12:10] <groz> the concept is, always start each one with a fresh build, and then the tests themselves are isolated into an ipkg that carries all the dependancies needed to bring in all the components needed for the test
[12:10] <florian> do you guys if it is possible to share the auto-learned stuff from spamassassin with other spamassassins ?
[12:11] <florian> I mean differently than sharing via nfs
[12:11] <nbd> just copying it over? should work.
[12:11] <florian> humm, what about making all my mx contribute to the same auto-lear file ?
[12:12] <florian> I am not sure spamassassin handles well concurrent accesses
[12:12] <nbd> it needs working locking
[12:13] <florian> yes
[12:13] <nbd> because it rewrites most parts when new training data comes in
[12:13] <groz> florian, use a .forward to send it all to one place
[12:13] <groz> let one machine do all the 'learning'
[12:13] <groz> then rsync the results out
[12:13] <groz> to all of them
[12:14] <florian> hu sounds complicated though simple in principle
[12:14] <florian> complicated to deploy
[12:14] <groz> how are you gathering up the 'learning' data ?
[12:15] <florian> by amavais
[12:15] <florian> amavis damn I type like a french cow
[12:15] <nbd> btw. you can use a central spamassassin server
[12:15] <groz> lol, i have a slightly cruder method, but, sure works well
[12:15] <nbd> and use spamc to check
[12:15] <groz> i have a couple of common usernames set up
[12:15] <florian> nbd: this sounds better to me actually
[12:16] <groz> that are not actually real accounts, bill, john, kathy
[12:16] <florian> this is what I will probably do
[12:16] <groz> and all mail that comes to them
[12:16] <groz> goes directly into the 'spam to be learned' pipe
[12:16] <florian> groz: I use postgrey with rbl and it does a great job forward the smtp server
[12:18] <CIA-17> mbm * r4714 /packages/net/squid/Makefile: remove incorrect host dependancy
[12:19] <[mbm]> any reason why the package.mk ignores a configure failure?
[12:19] <nbd> let me check..
[12:19] Action: [mbm] wants to get rid of the true command in Configure/default
[12:19] <groz> probly cuz some things will always fail, they dont have configure scripts
[12:20] <[mbm]> no, there's a check for that
[12:20] <nbd> pretty obvious. it's running true after configure
[12:20] <nbd> i'll fix it
[12:21] <[mbm]> nbd: yeah I know that it's running true, I was asking why
[12:21] <nbd> because of the [ -x configure ]
[12:21] <nbd> to trap the error if that one returns false
[12:23] <[mbm]> it's in the wrong place
[12:23] <[mbm]> it's causing it to ignore all errors running configure
[12:24] <CIA-17> nbd * r4715 /branches/buildroot-ng/openwrt/include/package.mk: only run trap error code in the configure template, if the configure script was not found
[12:24] <nbd> that should fix it
[12:24] <[mbm]> actually that's not right either
[12:24] <nbd> oh, wait
[12:24] <nbd> yeah, i noticed
[12:25] <[mbm]> let me
[12:25] <nbd> i'll put an if in there
[12:25] Action: [mbm] has the patch already written and was just about ready to commit
[12:26] <nbd> http://pastebin.ca/154420
[12:26] <CIA-17> mbm * r4716 /branches/buildroot-ng/openwrt/include/package.mk: fix previous commit
[12:26] <[mbm]> how's that?
[12:27] <nbd> i think it's better to enclose the script in a { } block
[12:27] <nbd> because some makefiles apparently add commands separated by ;
[12:28] <nbd> i'll change it, ok?
[12:28] <[mbm]> heh sure
[12:28] <[mbm]> this is going to be a mess in the logs
[12:28] <nbd> you know what... i'll just use if [ -x ./configure ]
[12:29] <[mbm]> haha
[12:29] Action: groz gets ready to grab a fresh copy and count how many packages got broke
[12:29] <[mbm]> there's nothign wrong with the shorthand I used
[12:30] <CIA-17> nbd * r4717 /branches/buildroot-ng/openwrt/include/package.mk: use an if block on the whole configure command
[12:33] <florian> it does not seem to break package
[12:48] <[mbm]> bind fails
[12:48] <[mbm]> checking for /dev/random... configure: error: cannot check for file existence when cross compiling
[12:49] <[mbm]> configure: error: /bin/sh './configure' failed for lib/bind
[12:49] <CIA-17> nbd * r4718 /branches/buildroot-ng/openwrt/toolchain/Config.in: set -mcpu=405 in the default cflags for magicbox
[13:16] <CIA-17> florian * r4719 /branches/buildroot-ng/openwrt/target/linux/brcm63xx-2.6/patches/040-bcm963xx_flashmap.patch: Add early support for CFE mapping
[16:06] <CIA-17> nbd * r4720 /branches/buildroot-ng/openwrt/target/linux/magicbox-2.6/patches/002-flash_map.patch: magicbox: add 0x40 to the kernel image size (uImage header)
[00:00] --- Thu Aug 31 2006