**** BEGIN LOGGING AT Thu Nov 18 02:59:58 2010
Nov 18 03:43:45 <sn9> http://www.gimpelevich.san-francisco.ca.us/danielg4/r24027.patch
Nov 18 03:43:56 <sn9> get it while it's hot
Nov 18 04:14:46 <builder> build #33 of ppc40x is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ppc40x/builds/33
Nov 18 05:05:29 <builder> build #30 of s3c24xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/30
Nov 18 07:50:37 <builder> build #34 of atheros is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/34
Nov 18 07:53:01 <builder> build #32 of brcm47xx is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/32
Nov 18 08:12:37 <iSteve> dottedmag: Committed the three patches.
Nov 18 08:14:03 <cshore> pig xMff
Nov 18 08:14:07 <cshore> ping xMff
Nov 18 08:14:13 <cshore> *sorry
Nov 18 08:14:35 <xMff> pong
Nov 18 08:15:02 <cshore> have you have a chance to look at the reload...if not if you could point me in the right direction, I can do that now
Nov 18 08:15:12 <cshore> ?
Nov 18 08:15:34 <cshore> *had
Nov 18 08:15:58 <xMff> I have committed a bunch of fixes during the night
Nov 18 08:16:09 <xMff> even tamed IE7
Nov 18 08:16:23 <cshore> ok, I'll try the new stuff then. Excellent :)
Nov 18 08:16:52 <xMff> I now tested with opera, chrome, firefox, ie7 and all work okay
Nov 18 08:17:20 <xMff> but that must not mean anything, I test on a wndr3700 here, it is quite fast so I suspect I will not notice some timing realted stuff
Nov 18 08:18:00 <xMff> however, just tell me how it goes
Nov 18 08:18:05 <cshore> hmmm...yeah the disadvantage of testing on modern hardware when there are primitive users :)
Nov 18 08:18:11 <cshore> sure, will do
Nov 18 08:18:32 <cshore> like my router ;-)
Nov 18 08:18:42 <xMff> what hw is it?
Nov 18 08:19:03 <cshore> brcm63xx 96348GW 200 MHz
Nov 18 08:19:18 <xMff> ah
Nov 18 08:19:20 <xMff> with b43?
Nov 18 08:19:28 <cshore> have been, yes
Nov 18 08:19:35 <cshore> want to try the proprietary
Nov 18 08:19:55 <cshore> just havent't had a chance
Nov 18 08:20:15 <xMff> ah, can you test iwinfo with that some time? I wonder whether the stuff still works correctly
Nov 18 08:20:56 <cshore> is that a package, or part of the default?
Nov 18 08:21:13 <xMff> its a library used by luci but it has a command line util called "iwinfo"
Nov 18 08:21:19 <cshore> ok
Nov 18 08:21:41 <cshore> I probably do that today or tomorrow
Nov 18 08:21:48 <xMff> sure, no hurry
Nov 18 08:22:16 <cshore> well, i'm doing final wrap-up on v1.0 of the PBX based on OpenWRT and FreeSWITCH
Nov 18 08:22:27 <cshore> or rather v0.1
Nov 18 08:22:45 <cshore> first experimental release
Nov 18 08:24:06 <cshore> so I'm doing things like figuring out what packages to include on the image and such like (once I finish with testing the reload)
Nov 18 08:25:15 <xMff> great
Nov 18 08:26:17 <cshore> it's taken a lot of work, and there's a lot more to do yet, but I feel like I'm getting somewhere with it now
Nov 18 08:29:05 <xMff> oh btw, did you figure out howto reorder sections?
Nov 18 08:29:17 <cshore> you mean for the linked list?
Nov 18 08:29:23 <xMff> uci in general
Nov 18 08:29:32 <cshore> What I did was use rename
Nov 18 08:29:52 <xMff> so you sort them by name?
Nov 18 08:30:21 <cshore> Each section has a name (e.g. bleg_route_1, bleg_route_2) etc
Nov 18 08:30:30 <xMff> ok
Nov 18 08:31:37 <cshore> and I use next_target in each section except the last
Nov 18 08:33:45 <cshore> so on cbi parse, I do some work to determine if I need to change this section and rename it.  next_target also sometimes needs to be changed.
Nov 18 08:34:10 <cshore> it results in a 2-4s delay on the page, but it works
Nov 18 08:35:06 <cshore> (slow browser slows things down more than the luci stuff on my router)
Nov 18 08:35:48 <cshore> not that the browsers have been an issue lately, but for a whle firefox was slow
Nov 18 08:36:13 <cshore> now I'm usually using Chromium
Nov 18 09:06:00 <acoul> hello
Nov 18 09:38:05 <jow_laptop> cshore: hm true
Nov 18 10:12:59 <CIA-48> nbd * r24028 /trunk/package/mac80211/patches/310-pending_work.patch: mac80211: merge pending cfg80211 patches to fix a race condition with setting the regdomain for multiple cards
Nov 18 10:53:53 <cshore> jow_latop: it works
Nov 18 10:54:17 <cshore> jow_laptop: the reload that is
Nov 18 10:59:57 <builder> build #31 of orion is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/orion/builds/31
Nov 18 11:51:58 <sn9> Wipster: http://www.gimpelevich.san-francisco.ca.us/danielg4/r24027.patch
Nov 18 11:55:56 <Wipster> sn9, thanks
Nov 18 11:56:30 <sn9> the ethernet stuff is as good as it's going to get without switching to the dsa driver
Nov 18 11:56:49 <sn9> but wifi no worky
Nov 18 11:57:21 <Wipster> damn
Nov 18 11:57:26 <sn9> vlynq just can't establish a link to the wifi controller no matter what i do
Nov 18 12:04:52 <builder> build #28 of ramips is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/28
Nov 18 12:05:26 <jow_laptop> cshore: great
Nov 18 12:05:36 <sn9> Wipster: ideas?
Nov 18 12:06:19 <Wipster> I'm afraid not sorry, not looked at vlynq at all
Nov 18 12:10:28 <cshore> jow_laptop: for libuci-lua, how do you set the config dir (i.e. to something other than /etc/config?)
Nov 18 13:03:58 <builder> build #30 of gemini is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/30
Nov 18 13:08:25 <jow_laptop> cshore: either as argument to cursor() or afterwards via set_*dir()
Nov 18 13:09:21 <cshore> jow_laptop...which arg is it?  1 is savedir, 2 is statedir, so 3 is configdir?
Nov 18 13:10:46 <jow_laptop> http://dev.luci.freifunk-halle.net/luci-doc/modules/luci.model.uci.html
Nov 18 13:12:26 <cshore> set_confdir for the set* method, but which arg for cursor()?  Or does it matter?
Nov 18 13:12:26 <jow_laptop> the configdir is the first arg to cursor()
Nov 18 13:13:00 <cshore> oh, then what's the savedir?  I though it was first cursor(savedir, statedir)
Nov 18 13:14:19 <jow_laptop> now you confused me ;)
Nov 18 13:15:47 <cshore> heh
Nov 18 13:16:44 <jow_laptop> arg 1 is confdir
Nov 18 13:16:45 <jow_laptop> arg 2 is sa
Nov 18 13:16:45 <jow_laptop> vedir
Nov 18 13:16:56 <cshore> and statedir is 3rd if present?
Nov 18 13:17:08 <jow_laptop> uncommitted changes and state vars share the same delta format
Nov 18 13:17:16 <jow_laptop> therfore you can interchange the savedir with a statedir and vice versa
Nov 18 13:17:23 <cshore> ah, ok, so really they're the same thing
Nov 18 13:17:25 <jow_laptop> there is no 3rd parameter
Nov 18 13:18:08 <cshore> statedir is just what /var/state is called, but really it's a savedir like a temp savedir
Nov 18 13:18:09 <jow_laptop> well technically state vars behave exactly like uncommitted changes
Nov 18 13:19:03 <cshore> so you can't mix a savedir with the /var/state?
Nov 18 13:19:18 <jow_laptop> no
Nov 18 13:19:55 <jow_laptop> and I wouldn't recommend doing that
Nov 18 13:20:38 <jow_laptop> there is an instance method "substate()"
Nov 18 13:20:57 <jow_laptop> it gives you another uci cursor initialized with the statedir and bound to another cursor
Nov 18 13:21:08 <jow_laptop> its kept in sync
Nov 18 13:21:12 <cshore> cursor_state() you mean?
Nov 18 13:21:27 <jow_laptop> no. var x = ...cursor()
Nov 18 13:21:34 <jow_laptop> var y = x:substate()
Nov 18 13:21:46 <jow_laptop> x is /etc/config + /tmp/.uci
Nov 18 13:21:50 <cshore> oh ok
Nov 18 13:21:52 <jow_laptop> y is /etc/config + /var/state
Nov 18 13:22:18 <cshore> got it
Nov 18 13:24:32 <jow_laptop> if you do commit or save on x (which alters the anonymous section hashes), y automatically reloads its config
Nov 18 13:24:43 <jow_laptop> so its guaranteed that they are in sync
Nov 18 13:25:47 <cshore> ok, so substate (rather than  config_state) stays in sync with the just-committed changes when you commit a cursor
Nov 18 13:26:16 <cshore> Cursor.cursor_state() I mean
Nov 18 13:26:35 <cshore> no that wrong. cursor_state .
Nov 18 13:27:27 <cshore> but anyway, I see what you mean.
Nov 18 13:28:39 <jow_laptop> I used this technique in luci.model.network as I sometimes need access to the real vars, sometimes to the overlayed ones (.ifname vs. device, ...)
Nov 18 13:39:59 <Wipster> [florian], ping
Nov 18 13:40:35 <cshore> I have to browse the luci source to see how to create a drop down list of IP's based on the interface sections
Nov 18 13:40:46 <cshore> I know I've seen you've done it for other things
Nov 18 13:41:13 <[florian]> Wipster: pong
Nov 18 13:41:59 <Wipster> [florian], just grabbed latest trunk and put the .36 patches on and I am getting http://pastebin.com/c1Nt4hiq
Nov 18 13:42:36 <[florian]> Wipster: can you enable kallsyms?
Nov 18 13:43:58 <Wipster> [florian], certainly how do I do that?
Nov 18 13:44:55 <[florian]> Wipster: make menuconfig -> Global build settings -> Compile the kernel with symbol table information
Nov 18 13:45:32 <Wipster> [florian], yeh thats set
Nov 18 13:48:35 <Wipster> [florian], is it not showing what you need?
Nov 18 13:50:07 <[florian]> Wipster: I would like function names instead of addresses
Nov 18 13:52:30 <Wipster> oh thought that was the call trace bit, it was compiled with the symbol table info hmmm
Nov 18 14:04:00 <builder> build #28 of rb532 is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/28
Nov 18 14:24:54 <sn9> Wipster, [florian]: i have an idea how to fix vlynq. building now to test
Nov 18 14:26:12 <[florian]> sn9: fixing it for what reasons? what's broken with it?
Nov 18 14:26:23 <sn9> it won't link :(
Nov 18 14:26:56 <[florian]> link in the sense it does not link with the remove vlynq device?
Nov 18 14:27:05 <sn9> correct
Nov 18 14:27:22 <[florian]> that part of the driver looks suspicious to me anyway
Nov 18 14:27:25 <sn9> i am about to test an idea to fix that
Nov 18 14:27:33 <[florian]> sn9: I have seen your patch and it looks like an improvement in any case
Nov 18 14:28:48 <sn9> well, the vlynq part of that patch was spaghetti at the wall. if this works, i'll have a much better one. in the meantime, you think the rest of the patch is commit-worthy?
Nov 18 14:45:08 <sn9> [florian]: ?
Nov 18 14:45:36 <[florian]> sn9: yes
Nov 18 14:45:46 <[florian]> sn9: yes for I am here
Nov 18 14:45:53 <[florian]> sn9: I need to have a look at a file patched
Nov 18 14:46:03 <sn9> go ahead
Nov 18 15:04:40 <builder> build #25 of uml is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/25
Nov 18 15:05:30 <CIA-48> acoul * r24029 /trunk/toolchain/uClibc/patches-0.9.31/ (7 files): toolchain/uClibc: push some upstream patches for uClibc-0.9.31. should resolve isses of #8269
Nov 18 15:08:22 <CIA-48> acoul * r24030 /trunk/toolchain/uClibc/patches-0.9.31/ (2 files): toolchain/uClibc: fix upstream patch name on r24029
Nov 18 16:18:02 <builder> build #31 of cobalt is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/31
Nov 18 16:19:41 <builder> build #29 of ppc44x is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ppc44x/builds/29
Nov 18 16:27:31 <sn9> [florian]: at some point, the vlynq protocol specs were revised, and vlynq.c handled the old, but not the new
Nov 18 16:29:02 <[florian]> sn9: that's very likely yes
Nov 18 16:29:45 <sn9> i just now fixed that in theory, still no joy
Nov 18 16:58:11 <sn9> [florian]: are you still reviewing the rest of the patch?
Nov 18 16:58:51 <[florian]> sn9: I have not reviewed it, I am at work
Nov 18 16:58:58 <sn9> oh ok
Nov 18 17:57:54 <tripolar> hi
Nov 18 17:58:07 <tripolar> is someone of the devs here with write access to openssl?
Nov 18 18:00:28 <tripolar> i send a patch to the mailinglist please apply it - it updates openssl to 0.9.8p - this fixes a critical bug
Nov 18 18:01:16 <tripolar> thepeople: ping
Nov 18 18:19:43 <builder> build #26 of x86 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/26
Nov 18 18:34:10 <builder> build #26 of etrax is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/26
Nov 18 19:08:38 <netprince_> interesting b43 on whr-g54s seems to trigger button events at random intervals
Nov 18 19:09:32 <netprince_> wl on whr-g54s seems to work normally
Nov 18 19:11:25 <netprince_> nice to have options, but I was rooting for b43
Nov 18 19:47:14 <EqUaTe> netprince_: why? (re rooting for b43)
Nov 18 19:47:48 <netprince_> dont care for the binary blob
Nov 18 19:48:30 <EqUaTe> there is that, but with it being between not having that and stable wifi, i'll go for the stable wifi..
Nov 18 19:50:26 <netprince_> I dont buy broadcom based devices anymore, ath9k is sooo much better
Nov 18 19:50:55 <EqUaTe> in general, yeah
Nov 18 19:53:02 <netprince_> testing a wrt160nl now, it seems I need to mv /etc/modules.d/20-rfkill /etc/modules.d/19-rfkill for wifi to be happy
Nov 18 20:09:36 <epointsystem> Hello, have there been any substantial changes recently in the wifi driver for the ar71xx architecture?
Nov 18 20:16:32 <roh> uh. nice rtl datasheet collection: http://realtek.info/pdf/
Nov 18 21:23:04 <stintel> epointsystem: depends which wifi driver you are talking about
Nov 18 21:23:40 <stintel> epointsystem: there are ar71xx boards that have miniPCI slots, so you can put in about any wifi card ..
Nov 18 21:23:44 <epointsystem> ath9k
Nov 18 21:24:14 <stintel> there have been lost of changes recently
Nov 18 21:24:20 <stintel> both in trunk and in the backfire branch
Nov 18 21:25:11 <stintel> see commit logs @ https://dev.openwrt.org/log/trunk/package/mac80211 and/or https://dev.openwrt.org/log/branches/backfire/package/mac80211
Nov 18 21:25:18 <epointsystem> Thanks.
Nov 18 21:27:10 <epointsystem> That probably explains why some backfire branch builds worked reliably, while others didn't. What is the current status, BTW?
Nov 18 21:29:36 <stintel> at work I'm using an rspro with mikrotik r52n (ath9k), and backfire r24027, very stable
Nov 18 21:30:05 <stintel> tested it today with 2 VAP's or what's it called, was very stable as well
Nov 18 21:30:55 <stintel> if you use ath9k, I can recommend using the backfire branch, or if you dont want to build your own image, wait for the 10.03.1-rc4 to come out
Nov 18 21:31:50 <epointsystem> I'm rolling the current revision of backfire branch, then.
Nov 18 21:31:58 <stintel> (rc3 doesn't have those recent changes yet)
Nov 18 21:32:24 <stintel> epointsystem: ok. I should say that I only tested it in AP mode, but I guess that's what most people will be using anyway
Nov 18 21:32:55 <epointsystem> Actually, I am having problems with WDS client mode with an older revision.
Nov 18 21:33:57 <stintel> ah ic, not sure how that works, but you should probably try most recent backfire anyway ;-)
Nov 18 21:34:49 <epointsystem> Well, if you can wait for a full build, I'll tell you how it worked out.
Nov 18 21:36:02 <stintel> sure, I'm always online - might read it with some delay though
Nov 18 21:36:20 <stintel> and others might be interested as well
Nov 18 22:42:42 <Weedy> stintel: do VAPs support one AP and one STA?
Nov 18 23:47:43 <epointsystem> Looks good. The current version of the ar9k wifi driver seems to work fine with simultaneously being a WDS client and AP.
Nov 18 23:48:44 <epointsystem> The one in backfire branch, I mean.
Nov 19 01:04:31 <CIA-48> nbd * r24031 /trunk/package/mac80211/patches/ (2 files): ath9k: rework the mac address override patch to not break ath9k_htc
Nov 19 01:04:37 <CIA-48> nbd * r24032 /trunk/package/hostapd/patches/340-madwifi_key_fixes.patch: hostapd: back out a problematic madwifi change that worked around some issues with wep in madwifi (which may no longer be necessary), but broke dynamic WEP in AP mode (fixes #8267)
Nov 19 01:09:29 <CIA-48> nbd * r24033 /trunk/package/mac80211/patches/310-pending_work.patch: mac80211: merge the upstream ht40 fix
Nov 19 02:29:42 <builder> build #27 of ar7 is complete: Failure [failed shell_13]  Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/27
Nov 19 02:55:37 <builder> build #27 of kirkwood is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/27
**** ENDING LOGGING AT Fri Nov 19 02:59:58 2010