**** BEGIN LOGGING AT Fri Nov 12 02:59:57 2010
Nov 12 05:14:32 <builder> build #28 of brcm47xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/28
Nov 12 07:18:29 <acoul> hello
Nov 12 08:19:30 <builder> build #29 of brcm63xx is complete: Failure [failed compile_10]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/29
Nov 12 08:58:31 <[florian]> sn9: negative target reset?
Nov 12 08:58:44 <sn9> tap reset
Nov 12 08:58:50 <sn9> nominally
Nov 12 08:59:02 <[florian]> ah no idea
Nov 12 08:59:52 <sn9> i tried jtag on a different device and found that the nTRST pin has to be wired to Vcc for jtag to be enabled
Nov 12 09:00:15 <sn9> and the actual nTRST is on DINT
Nov 12 09:00:57 <sn9> so i need someone with access to an ar7 datasheet that identifies the actual bga pins
Nov 12 09:01:52 <sn9> iirc, AndyI identified the known pins with a scope or something
Nov 12 09:34:06 <CIA-76> acoul * r23970 /trunk/target/linux/generic/ (3 files in 3 dirs): linux/generic: add imq patches for linux kernels 2.6.35,36,37. (closes #8211)
Nov 12 09:43:37 <Acinonyx> gmorning
Nov 12 11:45:47 <builder> build #27 of cobalt is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/27
Nov 12 13:08:52 <KanjiMonster> [florian]: ping
Nov 12 13:16:11 <[florian]> KanjiMonster: pong
Nov 12 13:31:02 <KanjiMonster> [florian]: I can't get openwrt to compile with a git kernel (it actually fails already when building uclibc; complaining about redefinitions), so I'll develop my patches against 2.6.35, but can only make sure they apply against current git head, not compile or run test them
Nov 12 13:33:22 <[florian]> KanjiMonster: that's surprising, but maybe it's due to us switching to uclibc 0.9.31
Nov 12 13:33:46 <KanjiMonster> [florian]: I tried both .30.1 and .31
Nov 12 13:36:07 <[florian]> ok, I never had problems with that
Nov 12 15:20:47 <CIA-76> acoul * r23971 /trunk/package/madwifi/patches/ (63 files): package/madwifi: refresh madwifi patches
Nov 12 16:20:56 <builder> build #24 of ps3 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/24
Nov 12 16:48:54 <builder> build #26 of pxcab is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/26
Nov 12 17:02:58 <CIA-76> nbd * r23972 /trunk/package/mac80211/patches/040-fix_pm_qos_compat.patch: mac80211: fix compile on linux 2.6.35
Nov 12 17:12:56 <CIA-76> acoul * r23973 /trunk/target/linux/adm5120/ (10 files in 3 dirs): linux/adm5120: add preliminary 2.6.37 kernel support
Nov 12 17:34:42 <_trine> can someone tell me who looks after asterisk
Nov 12 17:35:01 <_trine> because at the moment its segfaulting
Nov 12 18:14:05 <_trine> is there some incompatibility between newer openwrt and asterisk 14?
Nov 12 19:52:45 <trine> http://dpaste.com/274542/
Nov 12 19:53:05 <_trine> anyone know why asterisk seg faults like this
Nov 12 19:53:55 <trine> http://dpaste.com/274542/
Nov 12 19:54:27 <trine> KAMIKAZE (bleeding edge, r23970)
Nov 12 20:19:28 <philipp64|laptop> _trine: why is it still shipping with 1.4???
Nov 12 20:20:11 <_trine> philipp64|laptop, I compiled it into trunk
Nov 12 20:20:30 <_trine> its smaller than the others and it works for what I want it for
Nov 12 20:20:54 <_trine> and its what I normally use on my other bits of kit
Nov 12 20:21:08 <_trine> so I can just copy the other confs over
Nov 12 20:21:22 <philipp64|laptop> I'd rather be using 1.8.
Nov 12 20:21:39 <_trine> is 1.8 working and available
Nov 12 20:21:51 <_trine> on openwrt
Nov 12 20:22:20 <_trine> maybe I should try to do a makefile for 1.8
Nov 12 20:23:02 <_trine> but I would guess it wont be as simple as that
Nov 12 20:23:30 <KanjiMonster> there's already a a ticket with a patch for 1.8
Nov 12 20:24:49 <philipp64|laptop> some of the cross-compilation got cleaned up thanks to Tilghman (after a fair amount of pestering).
Nov 12 20:25:22 <philipp64|laptop> libtool continues to be broken, though. it wants to --relink even if you're using a cross-compiler. sigh.
Nov 12 20:28:01 <philipp64|laptop> I'm thinking that 1.8 might actually be easier to build than 1.4. and the sounds cache feature makes repetitive builds a lot faster.
Nov 12 20:29:01 <_trine> well at the moment 1.4 does not work
Nov 12 20:29:41 <_trine> and thats probably to do with something other than asterisk itself
Nov 12 20:30:10 <_trine> maybe something else that should be included isnt being
Nov 12 20:30:13 <philipp64|laptop> do you have a stack trace?
Nov 12 20:30:27 <_trine> I have strace
Nov 12 20:30:46 <_trine> http://dpaste.com/274542/
Nov 12 20:31:36 <_trine> killed instantly
Nov 12 20:31:42 <_trine> more or less
Nov 12 20:32:41 <philipp64|laptop> ldd /usr/sbin/asterisk?
Nov 12 20:33:05 <philipp64|laptop> file /usr/sbin/asterisk
Nov 12 20:33:35 <trine> root@OpenWrt:~# ldd /usr/sbin/asterisk
Nov 12 20:33:35 <trine> Segmentation fault
Nov 12 20:33:36 <trine> root@OpenWrt:~#
Nov 12 20:34:23 <trine> root@OpenWrt:~# file /usr/sbin/asterisk
Nov 12 20:34:23 <trine> -ash: file: not found
Nov 12 20:35:26 <philipp64|laptop> ok, that's a really bad sign.
Nov 12 20:35:45 <_trine> pretty much an under statement :)
Nov 12 20:35:53 <philipp64|laptop> what happens if you do ldd on your build host?
Nov 12 20:36:06 <_trine> dunno
Nov 12 20:36:33 <_trine> I'm compiling at the moment
Nov 12 20:36:58 <philipp64|laptop> paste me the trace from the terminal link.
Nov 12 20:37:20 <_trine> philipp64|laptop, I'm not sure what you mean
Nov 12 20:38:29 <_trine> oh yes hang on
Nov 12 20:38:37 <_trine> just twigged
Nov 12 20:39:45 <_trine> it just seg faults
Nov 12 21:01:15 <_trine> asterisk 1.6 runs ok
Nov 12 21:01:26 <_trine> I just compiled it into my image
Nov 12 21:01:37 <_trine> and flashed the wrt160nl with it
Nov 12 22:52:11 <CIA-81> juhosg * r23985 /branches/backfire/target/linux/generic-2.6/files/drivers/input/misc/gpio_buttons.c: backfire: generic: update gpio_buttons driver (backport of r23984)
Nov 13 00:22:58 <philipp64|laptop> _trine: if it's failing on startup it's either a bad link, or a link to a bad library (or library path).  if it were the wrong executable type (x86_64, for instance) you'd get "not found" from execp
**** ENDING LOGGING AT Sat Nov 13 02:59:57 2010