**** BEGIN LOGGING AT Mon Apr 01 02:59:57 2013
Apr 01 07:12:52 <builder_> build #162 of octeon is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/162
Apr 01 07:50:20 <dape8708> uhm, anyone tested 6relayd with a /56 provider allocated prefix?
Apr 01 07:57:37 <dape8708> i wonder if i set ip6assign 56 then 6relayd will offer /63 pds to clients that want to use two /64 for their links..
Apr 01 08:06:22 <dape8708> or should i use ip6prefix so lan routers can get /63s ..
Apr 01 09:32:09 <builder_> build #175 of gemini is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/175
Apr 01 09:54:10 <OpenWrt-Commits> nbd r36142 trunk/target/linux/mpc85xx/Makefile * mpc85xx: enable ath9k and wpad-mini by default
Apr 01 09:54:14 <OpenWrt-Commits> nbd r36143 trunk/package/devel/valgrind/Makefile * valgrind: update to v3.8.1
Apr 01 10:03:23 <OpenWrt-Commits> nbd r36144 trunk/package/network/services/openvpn/Makefile * openvpn: enable password save support (#13245)
Apr 01 10:10:21 <cyrusff> dape8708: we don't have any pd-server support as of now
Apr 01 10:10:52 <cyrusff> you can set ip6assign to something <64 but the RA-server will nevertheless announce a /64
Apr 01 10:12:10 <dape8708> cyrusff, thanks for responding, i am thinking how i can manage a /56 from the provider for second level routers under the main cpe
Apr 01 10:13:50 <dape8708> like if i can give /63s on br-lan for routers that will split that into two /64
Apr 01 10:14:00 <cyrusff> yeah i know what you mean
Apr 01 10:14:21 <cyrusff> the small servers we have (6relayd, dnsmasq) both don't support acting as a PD-server as of now. you'd have to go with wide-dhcpv6-server or so, but the automatic configuration is a bit painful as the server doesn't pickup the prefix automatically
Apr 01 10:14:41 <dape8708> ah, that i am worried about
Apr 01 10:15:02 <cyrusff> its on the todo at some point but there are many many things on the ipv6 todo-list
Apr 01 10:15:26 <dape8708> of course, i imagine that, thanks for the awesome work so far
Apr 01 10:15:35 <cyrusff> sure, np
Apr 01 10:15:45 <cyrusff> youre welcome
Apr 01 10:16:04 <dape8708> so wide-dhcp6 server tweaking maybe.. have to test it, its kindof.. aged.. ȘD
Apr 01 10:16:15 <cyrusff> hehe
Apr 01 10:18:25 <cyrusff> maybe isc-server would work as well
Apr 01 10:18:37 <cyrusff> but its probably equally or mor epainful to adapt
Apr 01 10:21:48 <dape8708> will look into them, thanks for the insights!
Apr 01 15:09:21 <OpenWrt-Commits> kaloz r36145 trunk/toolchain/gcc/ Config.in patches/llvm common.mk Config.version * [toolchain/gcc]: llvm is marked broken for two and a half year now, nuke it
Apr 01 15:14:26 <OpenWrt-Commits> kaloz r36146 trunk/toolchain/gcc/common.mk * [toolchain/gcc]: fixup 4.7 configure options
Apr 01 15:23:47 <OpenWrt-Commits> kaloz r36147 trunk/toolchain/gcc/patches/4.6.2 * [toolchain/gcc]: remove empty 4.6.2 patches directory
Apr 01 15:44:04 <OpenWrt-Commits> kaloz r36148 trunk/toolchain/gcc/ initial/Makefile common.mk * [toolchain/gcc]: cleanup
Apr 01 15:47:21 <OpenWrt-Commits> kaloz r36149 trunk/toolchain/gcc/ patches/4.5-linaro Config.in common.mk Config.version * [toolchain/gcc]: drop 4.5 support
Apr 01 18:13:15 <russell--> nbd, my libpcap patch builds here (for brcm47xx relative to r36132) ... appears (from quick look) the libusb-1.0 dependency comes from canusb, i take it you'd rather that be disabled?
Apr 01 18:24:35 <nbd> russell--: there's a config option for usb support. if that's disabled, it must not use anything that depends on usb
Apr 01 18:25:22 <nbd> if canusb is a new feature, it probably makes sense to disable it unconditionally until somebody needs it
Apr 01 18:32:42 <russell--> ah, *lightbulb*
Apr 01 18:36:23 <Weedy_lappy> http://www.debian.org/
Apr 01 18:36:27 <Weedy_lappy> loling
Apr 01 18:37:40 <russell--> nbd: interestingly, configure seems to ignore --disable-canusb, so /me is just whacking out the relevant part of the configure script
Apr 01 18:38:02 <nbd> it probably checks if libusb is available
Apr 01 18:38:09 <nbd> maybe you can use an env var to force that test to disabled
Apr 01 18:38:23 <nbd> (it's always good to avoid patching if possible)
Apr 01 18:38:55 * russell-- tries harder
Apr 01 18:56:35 <russell--> grr.  configure seems to be ignoring --disable-canusb or even --enable-canbus=no ... looks like the upstream configure is just broken???
Apr 01 18:57:04 <russell--> unconditionally sets enable_canusb to yes
Apr 01 18:57:19 <russell--> (not canbus, canusb)
Apr 01 19:08:56 <russell--> ah, yes, forcing the ac_cv_header_libusb_1_0_libusb_h to no works
Apr 01 19:18:02 * russell-- mails v2
Apr 01 19:20:31 <russell--> but failed to cc nbd this time
Apr 01 19:42:25 <builder_> build #210 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/210
Apr 01 19:47:06 <builder_> build #210 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/210
Apr 01 20:33:10 <nbd> russell--: no problem
Apr 01 20:33:15 <nbd> i'll pick it up from the list
Apr 01 20:44:39 <tripolar> hi
Apr 01 20:45:14 <tripolar> i'd like to update to linux 3.8.5 but i get this error when compiling kernel/signal.c: In function 'flush_signal_handlers':
Apr 01 20:45:17 <tripolar> kernel/signal.c:489:9: error: 'struct sigaction' has no member named 'sa_restorer'
Apr 01 20:45:46 <tripolar> a new ifdef was introduced into signal.c
Apr 01 20:45:46 <tripolar> #ifdef SA_RESTORER
Apr 01 20:45:52 <tripolar>                 ka->sa.sa_restorer = NULL;
Apr 01 20:46:18 <tripolar> this creates the error - how can i fix this in a good way? just removing the lines seems to be somehow dirty
Apr 01 20:56:16 <larsc> Isn't there a fix for this in upstream?
Apr 01 21:03:02 <nbd> russell--: builds now, but it has picked up some bloat since the last version
Apr 01 21:03:10 <nbd> i'll check if there are some easy ways to mitigate it
Apr 01 21:05:36 <russell--> tripolar: yes, there was a patch pasted in here a few days ago
Apr 01 21:07:43 <russell--> http://stewie.be.tintel.eu/001-fix-sa_restorer.patch
Apr 01 21:08:16 <OpenWrt-Commits> nbd r36150 trunk/package/libs/libpcap/ patches/102-makefile_disable_manpages.patch patches/100-debian_shared_lib.patch patches/202-protocol_api.patch Makefile * libpcap: update to 1.3.0
Apr 01 21:08:19 <OpenWrt-Commits> nbd r36151 trunk/package/libs/libpcap/Makefile * libpcap: get rid of some bloat introduced by the update
Apr 01 21:08:31 <nbd> russell--: still a bit bigger than the old version, but acceptable
Apr 01 21:09:38 <russell--> cool
Apr 01 21:09:39 <Hauke> russell--: you need sone more patch adding the define __ARCH_HAS_SA_RESTORER for some archs (not mips) ;-)
Apr 01 21:11:09 <russell--> not my patch! ;-)
Apr 01 21:12:40 <Hauke> I hope this will get into 3.8.6
Apr 01 22:08:54 <tripolar> russell-- thanks
Apr 01 22:10:45 <tripolar> nbd: it seems your git repo of openwrt doesnt update anymore
Apr 01 22:11:14 <tripolar> or is this known
Apr 01 22:13:26 <nbd> fixed now
Apr 01 22:13:32 <tripolar> thanks
Apr 01 22:25:27 <stintel> that patch http://stewie.be.tintel.eu/001-fix-sa_restorer.patch is what is in Linus' git tree
Apr 01 22:25:44 <stintel> I didn't search for the entire commit though
Apr 02 02:57:17 <builder_> build #200 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/200
**** ENDING LOGGING AT Tue Apr 02 02:59:58 2013