**** BEGIN LOGGING AT Tue Nov 15 02:59:57 2011 Nov 15 03:14:10 nico * r29146 /branches/packages_10.03.1/libs/ldns/ (. Makefile): [backfire] packages: add libldns, merge r27602, r28780 & r28781 (closes: #10308) Nov 15 03:15:39 nico * r29147 /branches/packages_10.03.1/net/unbound/Makefile: [backfire] packages/unbound: use newly added libldns instead of the embedded one (closes: #10308) Nov 15 03:25:24 nico * r29148 /branches/packages_10.03.1/net/nmap/Makefile: [backfire] packages/nmap: add dependencies on libnl (closes: #9868) Nov 15 03:29:56 nico * r29149 /packages/net/nmap/Makefile: packages/nmap: add dependency on libstc++ to nping Nov 15 03:31:45 nico * r29150 /branches/packages_10.03.1/net/nmap/Makefile: [backfire] packages/nmap: merge r29149 Nov 15 03:42:15 nico * r29151 /packages/net/privoxy/ (Makefile files/privoxy.init): Nov 15 03:42:15 packages/privoxy: use new service functions Nov 15 03:42:15 Signed-off-by: Peter Wagner Nov 15 05:04:22 http://luci.subsignal.org/trac/changeset/7773/luci/trunk/modules/admin-full/luasrc/model/cbi/admin_system/system.lua Nov 15 05:05:00 I am wondering where does the deleted lines from 50 to 75 go to. Nov 15 07:07:41 build #112 of brcm63xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/112 Nov 15 09:44:01 build #87 of avr32 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/87 Nov 15 10:19:21 jow * r29152 /trunk/package/uhttpd/Makefile: [package] uhttpd: prevent linking uhttpd binary against crypto libraries Nov 15 10:20:03 jow * r29153 /branches/backfire/package/uhttpd/Makefile: [backfire] uhttpd: merge r29152 Nov 15 10:31:22 build #102 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/102 Nov 15 11:24:44 nico * r29154 /packages/libs/sqlite3/Makefile: packages/sqlite3: enable SQLITE_ENABLE_UNLOCK_NOTIFY (closes: #10211) Nov 15 14:14:34 hi Nov 15 14:14:52 build #89 of ar7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/89 Nov 15 14:15:12 {Nico}: the init script for tor you commited doesnt work - tor will start but stop won't work Nov 15 14:15:20 i sent a patch to fix this to the ml Nov 15 14:32:31 <{Nico}> tripolar: it is working fine here Nov 15 14:32:40 you can start and stop it? Nov 15 14:33:00 for me it writes the wrong pid into the pid file Nov 15 14:33:17 {Nico} Nov 15 14:34:17 starting works for me too with your initscript but stopping it isnt possible as the wrong pid is in the pidfile Nov 15 14:34:31 <{Nico}> http://pastebin.com/9JLf2GTH Nov 15 14:54:44 nbd * r29155 /trunk/package/mac80211/patches/ (7 files): ath9k: reorganize patches, reset hardware after full sleep (fixes #10349) Nov 15 15:47:26 blogic: or anyone else, do youknow what the general state of 802.15.4 support in linux is like? Not zigbee, just raw 802.15.4. Nov 15 15:48:44 I've got some devices that are currently on RF module<->uC<->USB<->desktoppc, and I've got an owrt router that does spi, so it seems like it would be "nicer" to do RF moduel<->openwrt device directly Nov 15 15:49:05 just wondering how much already exists in linux land Nov 15 15:50:26 karlp: hi Nov 15 15:50:48 i have a patch to merge the qi git net802.15.4 into owrt Nov 15 15:51:03 and made a package/kernel/wpan.mk Nov 15 15:51:14 so it builds images witht he latest drivers i could find Nov 15 15:51:19 this is for 3.1 Nov 15 15:51:35 i will be doing some more work on it this or next week Nov 15 15:51:49 did 2 days so far and managed to get it to boot with the stack Nov 15 15:52:08 qi is one of those handheld pcs right? Nov 15 15:52:27 yes Nov 15 15:52:34 what sort of things can the stack do? or is there a page somewhere I can read more abou tit? Nov 15 15:52:43 i am using the atusbben Nov 15 15:52:53 its a atmel based 802.15.4 wit usb Nov 15 15:53:33 http://pastebin.com/ibxXDWqj Nov 15 15:53:39 this is what i will look at next Nov 15 15:55:07 karlp: http://phrozen.org/atusb.patch Nov 15 15:55:13 that is the patch i made so far Nov 15 15:55:22 ok, I had seen the linux-zigbee project, but it seemed to have no updtes for the last couple of years Nov 15 15:55:49 yes Nov 15 15:55:53 well seems activity Nov 15 15:56:06 basically the info is still very spread out with several people working on it Nov 15 15:56:19 i was not able to find a dedicated upstream source Nov 15 15:56:23 there are several it seems Nov 15 15:56:32 anyhow i got 2 dongles and tarted to make them work :) Nov 15 15:56:57 ok. I'm targetting much lower than ssh and tcp :) I currently just have a few devices sending some custom protocol data directly on top of the 802.15.4 headers Nov 15 15:57:15 I'd just like to be able to listen to frames addressed to me, and be able to send frames to designated addresses Nov 15 15:57:34 mb__: ping? Nov 15 15:58:57 what hw do you want to attach to the owrt box ? Nov 15 15:59:05 an mrf24j40 module. Nov 15 15:59:10 slonopotamus: hi Nov 15 15:59:13 probably easiest and cheapest for me right now. Nov 15 15:59:18 https://www.tuxbrain.net/shop/product_info.php?cPath=347&products_id=1965&osCsid=s4fdosusfapj3ue3vm7rf4rd86 Nov 15 15:59:27 i am using that thing Nov 15 15:59:43 meh Nov 15 16:00:11 slonopotamus: what's up? Nov 15 16:00:28 karlp: my intent is to do 2 things Nov 15 16:00:46 1) make it work in owrt in terms of network connectivity Nov 15 16:01:00 2) use it do transport custom stuff to small controller boards Nov 15 16:01:26 yep, I'm interested in 2. Nov 15 16:01:37 I alreadyhave this working with some serially attached micros that run the radio, Nov 15 16:01:45 but long term at least, I'd rather just plug it straight in. Nov 15 16:01:55 was just generally curious how far 802.15.4 was in linux Nov 15 16:01:57 and use wireshark :D Nov 15 16:02:04 looks like it's still, "not real close" Nov 15 16:02:09 well Nov 15 16:02:15 its beyond "what is 802.15.4 Nov 15 16:02:19 ok, let me rephrase Nov 15 16:02:28 it's probably still a bit far out for how much free time I have Nov 15 16:02:32 mb__: wrt n8x0 clock. we can: #1 revert breaking change to rtc that removes custom sysfs and converts it to nonfunctional rtc class. then, we can just run stock maemo retutime from initfs that will handle time for us. #2 we can force set year to 0 and write custom userspace date save/load script that will operate via rtc standard userspace interface. #3 we can try to find where kernel itself can save/load date info and use that place on rtc Nov 15 16:02:36 basic net80215.4 and mac80215.4 ar in the kernel since 3.0 i think Nov 15 16:02:39 init Nov 15 16:02:46 and several people working on stuff Nov 15 16:02:53 its on the verge of being able to do stuff Nov 15 16:02:55 kernel.org shows just fakehard? Nov 15 16:03:07 but yes, production use is a todo Nov 15 16:03:13 mb__: #4 claim n8x0 has no persistent clock and needs ntpdate on boot Nov 15 16:03:22 yes Nov 15 16:03:26 this is good though, it's a lot closer than it was last I looked :) Nov 15 16:03:39 the qi guys have drivers for several dongles Nov 15 16:03:52 and also drivers to simulate a network Nov 15 16:04:07 lots of test infrastructure Nov 15 16:04:16 so you can test / simulate with no real HW available Nov 15 16:04:28 for hardware, I'm normalyl using these: http://eu.mouser.com/ProductDetail/Microchip-Technology/MRF24J40MA-I-RM/?qs=sGAEpiMZZMsnNKdmhDfM1EgN%252btSgBRoY Nov 15 16:04:32 mb__: neither of those makes me happy, but we have to go with hw n8x0 has. Nov 15 16:04:34 because they're uber cheap. Nov 15 16:04:53 slonopotamus: I'm not going to run maemo stuff. Nov 15 16:05:01 the data rate is low enough that bit banged spi should be ok, I'd guess. Nov 15 16:05:06 I'd be fine with a userspace helper script, slonopotamus Nov 15 16:05:18 slonopotamus: That can't really be too complicated, no? Nov 15 16:05:32 probably Nov 15 16:06:01 the unit i have is a arm7 that does usb device2spi and a version of what you have but from atmel Nov 15 16:06:06 some principle Nov 15 16:06:15 * mb__ slaps the guy inventing an RTC without a year counter. Nov 15 16:06:27 aw Nov 15 16:06:29 so mean Nov 15 16:06:53 mb__: okay, we still have several options left :) Nov 15 16:08:04 mb__: what's most weird is that rtc has 32bits total. so it could happily just have single always-incrementing seconds counter and live until 2038 with that Nov 15 16:08:27 blogic: thanks for the info, I'll keep an eye on things a bit more Nov 15 16:08:32 sure Nov 15 16:08:40 my intent is to have it in owrt in 2-3 months Nov 15 16:08:54 i am just getting started Nov 15 16:08:55 mb__: btw, i get errors like https://dev.openwrt.org/ticket/9535 when mounting jffs maemo partitions and directory hierarchy seems messed up on them Nov 15 16:08:56 ;) Nov 15 16:09:02 slonopotamus: We should not become incompatible with maemo for dualboot reasons, IMO Nov 15 16:09:57 mb__: them script needs to save info in the same place maemo does (otherwise, time will be skipped on switches) Nov 15 16:10:12 mb__: do you have working write mode in calvaria? Nov 15 16:10:15 I haven't even wired one up on the spi on my owrt device yet, but in 2-3 months, I may even be at a place where I can try some things out for you :) Nov 15 16:10:32 cool Nov 15 16:10:45 hot Nov 15 16:10:55 slonopotamus: No. But I don't think it's too hard to add Nov 15 16:11:01 up Nov 15 16:11:11 slonopotamus: The format is pretty trivial Nov 15 16:13:23 mb__: i don't have either in https://github.com/slonopotamus/opendsme/blob/master/src/libopencal.c Nov 15 16:15:19 mb__: and don't comment coding style, that was one of my first programs in C after years of Java :P Nov 15 16:18:23 Doesn't look too bad. Nov 15 16:21:03 mb__: write mode isn't finished as you can see on line #532. also, i'm not sure both read and write algorithms are 100% compatible with maemo (i damaged CAL area a bit while writing that and now maemo libcal refuses to find some blocks though my implementation still sees them) Nov 15 16:22:27 mb__: also, maemo does less reads when scans for blocks which means my impl (and yours too, actually) are more brute-force on reading than expected Nov 15 16:23:22 yeah I looked though the maemo asm code once. But I didn't care to improve the implementation Nov 15 16:23:46 The "brute force" approach seems to be good enough Nov 15 16:23:52 * slonopotamus isn't brave enough yet to parse asm Nov 15 16:26:03 mb__: my point is that if write mode we write doesn't respect maemo algorithm, we can end up with maemo impl reading different data because it skips smth Nov 15 16:26:07 *doesn't respect maemo _read_ algorithm Nov 15 16:26:38 ok Nov 15 16:27:39 What if we don't care to write to cal nd store our date elsewhere? We can live with a wrong date in maemo once per year, for now. Nov 15 16:27:46 forever, probably Nov 15 16:28:16 the thing is that after each boot to maemo our date will become wrong too Nov 15 16:28:36 why? Nov 15 16:28:36 because maemo does write to CAL and reset of rtc at least on each boot Nov 15 16:28:50 ah Nov 15 16:28:52 (it also has to do that at least once in 255 days) Nov 15 16:29:23 i haven't checked how often maemo resets rtc while running Nov 15 16:30:56 mb__: so we have either be 100% compatible with maemo wrt time storage (so systems stay in sync) or give up with maemo completely. and if we choose the latter, there's no need to use CAL at all, plain file will be much simpler Nov 15 16:31:34 Ok. Well in that case I'd probably be in favor of dropping maemo compatibility here Nov 15 16:32:11 We should put the effort into battery charging instead. Because that's actually the last thing one would really want to boot maemo for Nov 15 16:32:58 We could probably start with a "safe" implementation that only charges up to 75% or so. That should be possible without interpreting cal data. Nov 15 16:33:30 anyway, I'm off now. Cu later. Nov 15 17:40:19 jow * r29156 /trunk/package/busybox/ (Makefile patches/700-hexdump_segfault_fix.patch): [package] busybox: fix hexdump segmentation fault with an empty leading format unit Nov 15 17:43:14 jow * r29157 /packages/ipv6/wide-dhcpv6/ (Makefile files/dhcp6c.init): [packages] wide-dhcpv6: now that hexdump works again, fix endianess detection (#10396) Nov 15 17:55:26 jow * r29158 /trunk/package/busybox/Makefile: [package] busybox: revert accidentally committed debugging flag Nov 15 17:56:24 jow * r29159 /branches/backfire/package/busybox/ (Makefile patches/700-hexdump_segfault_fix.patch): [backfire] busybox: backport r29156 Nov 15 17:58:48 jow * r29160 /branches/packages_10.03.1/ipv6/wide-dhcpv6/ (Makefile files/dhcp6c.init): [backfire/packages] wide-dhcpv6: backport r29157 Nov 15 18:01:56 nbd: ping Nov 15 18:04:42 thx for r29160 jow Nov 15 18:12:44 dape_on_mw3: was that your ticket? Nov 15 18:12:50 10396 Nov 15 18:22:25 blogic * r29161 /trunk/target/linux/lantiq/ (4 files in 4 dirs): lantiq: add runtime generation of /etc/config/network Nov 15 18:23:42 also r29157 , no jow, but these fix my wl500gpv1 ipv6 custom build Nov 15 18:23:56 you dev guys are amazing Nov 15 18:30:27 ping {Nico} Nov 15 18:30:37 {Nico}: i get this with you tor init script Nov 15 18:30:40 http://nopaste.linux-dev.org/?22278 Nov 15 19:16:53 <{Nico}> tripolar: permissions on /var/run/tor are wrong Nov 15 19:17:07 florian * r29162 /trunk/package/kernel/modules/netdevices.mk: [package] kmod-r6040 depends on kmod-libphy Nov 15 19:19:55 <{Nico}> tripolar: in fact no, anything special in your /et/tor/torrc ? Nov 15 19:23:12 {Nico}: no not really Nov 15 19:35:22 <{Nico}> tripolar: you sure your perms on /tmp & /var/run are ok? Nov 15 19:37:28 <{Nico}> tripolar: do you have PidFile line in your /etc/tor/torrc ? Nov 15 20:11:41 yes i have one Nov 15 20:13:36 build #88 of sibyte is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/88 Nov 15 20:13:49 <{Nico}> tripolar: is it /var/run/tor/tor.pid? Nov 15 20:14:55 yes Nov 15 20:15:40 i restarted the machine and now it works thanks Nov 15 20:19:12 have a nice day Nov 15 20:19:16 bye Nov 15 21:07:19 build #108 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/108 Nov 15 21:22:48 build #106 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/106 Nov 15 22:25:43 florian * r29163 /trunk/package/kernel/modules/netsupport.mk: [package] allow building 8021q and bridge as modules Nov 15 22:25:47 florian * r29164 /trunk/target/linux/rdc/ (Makefile config-2.6.32): [rdc] include bridge and 8021q modules by default Nov 15 22:29:35 ping {Nico} Nov 15 23:00:40 I noticed there was a bunch of updates for the past couple of days. I wonder if the 'feeds/packages/net/bind' package also needs an upgrade. Right now, it breaks during a compilation as shown here (http://pastebin.com/yaf7v7x6). Nov 15 23:24:00 build #80 of iop32x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/80 Nov 15 23:42:04 nico * r29165 /trunk/package/ppp/ (Makefile files/ppp.sh): package/ppp: fix typo in r28868 (closes: #10429) **** ENDING LOGGING AT Wed Nov 16 02:59:57 2011