**** BEGIN LOGGING AT Wed May 16 03:00:01 2012 May 16 07:51:24 build #16 of x86 is complete: Failure [failed compile_1] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/16 May 16 08:45:27 nbd * r31747 /trunk/package/libubox/Makefile: libubox: update to latest version, fixes handling of numbers in jshn variables May 16 09:43:25 nbd? May 16 09:48:20 dwmw2_gone: ported openconnect, had to patch it to not take the password from stdin, but read if from a file instead May 16 09:48:31 yeah, that's what I wanted to hassle you about May 16 09:48:37 why can't you pass it to stdin? May 16 09:49:04 in fact, this is probably a good time to ask the other questions I had about the auth setup. May 16 09:49:09 so... May 16 09:49:23 openconnect authenticates through web forms. It's not just username/password although that's quite common. May 16 09:49:30 the openconnect script does not call openconnect directly May 16 09:49:35 it tells netifd to run it May 16 09:49:37 and keep track of it May 16 09:49:48 you present a certificate, or not, and the server gives you an arbitrary set of web forms to fill in. May 16 09:50:03 when you're done, it rewards you with an HTTP cookie which is what openconnect *actually* needs to connect. May 16 09:50:37 so why not give netifd the cookie and let netifd pass it to openconnect on stdin? May 16 09:52:05 i didn't want to add the extra complexity for something that's easier to handle in a different way May 16 09:53:14 is it really more complex? Once you realise that it's just the cookie, every time, and not an *optional* password and other args etc.? May 16 09:53:24 I would have thought it was *simpler* May 16 09:53:37 how do you know which file to use? And whether to pass a cookie or a passwd? May 16 09:53:42 i didn't want to add non-blocking buffered feeding of data to stdin for the proto-shell task May 16 09:53:46 That's complexity that you can *lose* May 16 09:54:01 in the netifd core May 16 09:54:03 we do actually allow the cookie on the command line with the -C option. May 16 09:54:10 but then it's visible in the process list May 16 09:54:19 $DEITY knows why I did that, but on openwrt it doesn't matter so much. May 16 09:54:32 I can make openconnect hide it. And probably should. May 16 09:55:34 of course, you don't have to have netifd handle feeding of data. Just open the file and use dup2() to make it openconnect's stdin :) May 16 09:56:09 what's the advantage of doing it this way? May 16 09:56:19 not to mention the fact that pipe(foo); write(foo[1], cookie, strlen(cookie)); would be fine. May 16 09:56:35 you don't have to persuade upstream to take a patch that upstream hates :) May 16 09:57:36 dammit, why does NetworkManager keep reconnecting to my wireless? May 16 09:57:40 or i can just keep this simple patch May 16 09:58:13 why patch it when you can just open the file and invoke openconnect with that as stdin? May 16 10:00:52 hm, must take baby to GymBabes. back later! May 16 10:01:09 anyway, that aside the thing I wanted to look at was how we authenticate in the general case, if it isn't as simple as username/password May 16 10:01:17 or if it requires one-time tokens or something. May 16 10:01:18 i don't like adding such special cases to netifd May 16 10:01:48 I was thinking about a page in luci where it handles the authentication for you, showing you the forms it gets from the server (and remembering your answers where it can) May 16 10:02:02 and then when that works, it sticks the cookie into the runtime config for the interface. May 16 10:02:04 hm May 16 10:02:43 invoking openconnect is *already* a special case. You already deal with these files and put the right arguments on the command line, surely? May 16 10:03:14 you ought to be able to make it *simpler*, but just passing the cookie (and server and server's certificate fingerprint). May 16 10:03:21 it's not a special case because it's used by pretty much any shell proto handler already May 16 10:03:24 pppd, udhcpc, etc. May 16 10:03:27 that's all that you need to give to openconnect to actually make the connection. HAving done the auth in advance. May 16 10:03:41 hm, I'll have to take a look at the code May 16 10:03:45 really must run now. May 16 10:04:05 the shell script tells netifd to start a process and provides the full command line and environment May 16 10:04:24 ah, ok. May 16 10:04:33 and when that process dies, netifd calls the teardown function of the script May 16 10:06:11 i'll think about the pipe stuff May 16 10:06:41 or put it on the command line, and I'll fix openconnect to obscure it. It'll only be visible for a moment May 16 10:06:48 which you really don't mind on openwrt, surely? May 16 10:07:02 * dwmw2_gone goes. NOW. Really this time! May 16 10:44:48 juhosg * r31748 /trunk/target/linux/generic/config-3.3: linux/3.3: add missing symbol May 16 10:44:51 juhosg * r31749 /trunk/target/linux/x86/ (6 files in 6 dirs): x86: sync 2.6.39 configs May 16 10:44:53 juhosg * r31750 /trunk/target/linux/x86/ (alix2/config-default config-3.2 net5501/config-default): x86: sync 3.2 configs May 16 10:44:56 juhosg * r31751 /trunk/target/linux/x86/ (config-3.3 geos/config-default): x86: sync 3.3 configs May 16 10:45:00 juhosg * r31752 /trunk/target/linux/x86/net5501/ (config-3.3 target.mk): May 16 10:45:01 x86/net5501: switch to 3.3 May 16 10:45:01 Compile tested only. May 16 10:45:06 juhosg * r31753 /trunk/target/linux/x86/alix2/ (config-3.3 target.mk): May 16 10:45:06 x86/alix2: switch to 3.3 May 16 10:45:06 Compile tested only. May 16 12:53:30 jow_laptop: is it possible to put functions into view .htm files? http://pastebin.com/NHRi1UBn May 16 12:53:50 looking at view/admin_status/index.htm, there's a big chunk of lua for handling the callback, May 16 12:54:13 or do all functions have to go in external, separate lua files (or as functions in the controller file?) May 16 12:56:15 I get "attempt to call global 'include' (a nil value)" May 16 12:58:00 if I take out the module(karl.test) and make the row generator just use "make_data" the page comes up, but has no data May 16 12:58:30 I was copying that table row generator from view/admin_status/route.htm May 16 13:03:56 jow * r31754 /trunk/package/firewall/ (Makefile files/reflection.hotplug): [package] firewall: fix nat reflection after netifd switch (#11460) May 16 13:04:33 karlp: yes, you can put any kind of lua code into views, including functions May 16 13:07:25 karlp: you shouldn't put a module() line in a view, that changes the current scope and will mess up stuff May 16 13:08:25 yeah, Itook that out, and used the raw name in the <% make_data(function(e) %> line May 16 13:08:50 but how does the magic to make those "per row of data returned" 's get created? May 16 13:09:15 make_data(function(e) ... end) May 16 13:09:28 means you pass an anonymous function (a closure) as argument to make_data() May 16 13:10:01 make_data() has to call this closure in the for loop May 16 13:10:27 ah, ok, I was just looking at the routes.htm cdoe, which has: "<% luci.sys.net.arptable(function(e) %>" May 16 13:10:38 yes May 16 13:10:49 and luci.sys.arptable is also implemented in such a way May 16 13:10:57 and then luci.sys.net.arptable in the API ref just says it "Returns the current arp-table entries as two-dimensional table." May 16 13:11:13 yeah its not fully updated :) May 16 13:11:19 ok, :) May 16 13:11:27 http://pastebin.com/i5U1kwyD May 16 13:11:49 right, funky. May 16 13:11:57 I'll play some more. May 16 13:12:17 starting to try things a little bit more complicated than just cbi models .) May 16 13:12:35 you don't need to use the closure/callback pattern May 16 13:12:51 in the case of arp tables I used it to avoid aggregatign a huge temporary table internally May 16 13:13:13 instead each row can be pushed out immediately without the need to store it somewhere May 16 13:13:17 the alternative is doing the for loop down in the html table itself? May 16 13:13:21 yes May 16 13:13:52 http://luci.subsignal.org/trac/changeset/5054/luci/trunk/libs/sys/luasrc/sys.lua May 16 13:15:22 clever May 16 13:37:50 jow * r31755 /trunk/package/firewall/files/reflection.hotplug: [package] firewall: rework interface address determination to skip ipv6 addresses May 16 13:56:06 jow_laptop: is nixio a superset of lua-socket? or a different api altogether? May 16 13:57:01 its a completely different library and api as luasocket was severely limited a few years ago May 16 13:57:47 just looking at packaging something that uses lua socket, ua socket been improved since then I take it? May 16 13:59:42 not sure May 16 13:59:56 guess I'll find out :) May 16 14:00:01 it seemed to be without a maintainer for quite a while May 16 14:00:18 if we run out of flash space, we can look at porting this to nixio if need be May 16 15:23:07 nbd * r31756 /trunk/target/linux/generic/ (8 files in 2 dirs): (log message trimmed) May 16 15:23:07 kernel: add codel and fq_codel to generic 3.3 patch set (based on patch by Dave Täht) May 16 15:23:07 Codel is a new AQM algorithm and RED replacement designed by May 16 15:23:07 Kathie Nichols and Van Jacobson, and published in ACM queue: May 16 15:23:07 http://queue.acm.org/detail.cfm?id=2209336 May 16 15:23:07 Codel stands for "Controlled Delay", and needs no knobs in the May 16 15:23:08 general case, twiddled, for optimum results. It aims for 5ms of May 16 15:23:10 nbd * r31757 /trunk/package/kernel/modules/netsupport.mk: kernel: add codel and fq_codel support to kmod-sched (patch by Dave Täht) May 16 15:23:14 nbd * r31758 /trunk/package/iproute2/ (12 files in 2 dirs): iproute2: update to 3.3.0, drop a few useless old patches, add codel support May 16 15:23:18 nbd * r31759 /trunk/package/qos-scripts/files/usr/lib/qos/ (generate.sh tcrules.awk): qos-scripts: replace sfq/red with fq_codel - massively improves latency under load May 16 15:23:22 nbd * r31760 /trunk/package/kernel/modules/netsupport.mk: kernel: split kmod-sched into kmod-sched-core and kmod-sched May 16 15:23:26 nbd * r31761 /trunk/package/qos-scripts/Makefile: qos-scripts: use kmod-sched-core instead of kmod-sched May 16 16:21:20 can I use overlayfs to lay my own luci module's controller,model,view directories on top of the existing ones in /usr/lib/lua/luci ? May 16 16:21:28 (in conjunction with sshfs?) May 16 16:21:45 or should I just poke more to get this to work on my local machine instead. May 16 16:21:50 probably a better idea May 16 16:22:56 I don't know, never attempted something like that May 16 16:25:08 I just always forget the fiddly bits to get the luci packages to run locally, I've got some notes from you from last time, so I should be able to get it up again. May 16 16:26:14 I almost always work remotely with sshfs May 16 16:26:48 so that the owrt filesystem appears locally? May 16 16:27:10 I'm hoping to get it so that edits work immediately on the owrt device, but _also_ turn up as changes in my local git checkout May 16 16:28:27 currently I have sshfs giving me /usr/lib/lua/luci from the owrt box on my local system, but edits there aren't versioned anywhere. May 16 16:28:32 oh well, just a thought :) May 16 16:29:04 you could run luci off from a git checkout on your target system May 16 16:29:19 if you're worried about space then do it within an x86 vm May 16 16:30:12 hmm, if I get "make run" work from the luci checkout directly, then I just have to worry about the diffs between lua on myhost and the target, (like ints) May 16 17:38:10 there's no limit on how many controllers can be in an application module for luci right? as long as they're named properly (filename and module) and all have an index() function? May 16 17:39:17 I keep getting "no page registered at blah/url/entry" if it belongs to an extension, make sure it's installed.. May 16 17:41:09 bleh, works on the target, not via make runhttpd May 16 18:21:10 maybe an old cache May 16 18:53:51 where would that cache be? I've looked in /tmp and in /host/tmp and done make clean; make runhttpd, but it wasn't fixing it May 17 01:44:08 build #20 of s3c24xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/20 **** ENDING LOGGING AT Thu May 17 02:59:59 2012