**** BEGIN LOGGING AT Thu Feb 02 02:59:58 2012 Feb 02 06:02:56 build #122 of pxcab is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/122 Feb 02 08:23:46 jogo * r29985 /trunk/ (5 files in 2 dirs): kernel: update module names and add new config symbols for linux 3.3 Feb 02 08:23:58 jogo * r29986 /trunk/target/linux/generic/ (123 files in 2 dirs): Feb 02 08:23:58 kernel: add preliminary support for linux 3.3 Feb 02 08:23:58 Based on 3.3-rc2 Feb 02 10:01:53 jow * r29987 /packages/ipv6/ndppd/ (. Makefile files/ files/ndppd.init): (log message trimmed) Feb 02 10:01:53 ndppd: initial import (release 0.2.1) Feb 02 10:01:53 Hi, Feb 02 10:01:53 here is a patch to add a package for ndppd: Feb 02 10:01:53 ndppd, or NDP Proxy Daemon, is a daemon that proxies NDP (Neighbor Discovery Feb 02 10:01:53 Protocol) messages between interfaces. ndppd currently only supports Feb 02 10:01:54 Neighbor Solicitation Messages and Neighbor Advertisement Messages. Feb 02 10:02:01 jow * r29988 /packages/net/xtables-addons/ (4 files in 2 dirs): [packages] xtables-addons: update to v1.41 Feb 02 10:02:03 jow * r29989 /packages/utils/collectd/patches/004-version-gen-shell.sh: [packages] collectd: fix build on machines using zsh for /bin/sh Feb 02 10:05:07 jow_laptop: thanks Feb 02 10:10:12 np Feb 02 10:12:35 do I officially maintain it? (ie. have svn commit rights on the ndppd/ subdir) Feb 02 10:13:02 there shouldn't be many updates anyway Feb 02 10:25:05 kerneis: not yet, I'll send a mail to Kaloz Feb 02 10:27:59 done, now lets wait Feb 02 10:34:46 ok, no hurry anyway, just wondered for future updates Feb 02 11:18:28 jow_laptop: maybe enable CONFIG_BUSYBOX_CONFIG_GROUPS in busybox by default.. i know winscp complains each time i connect to scp something from windows to the router Feb 02 11:19:16 that has no useful functionality Feb 02 11:20:36 or disable BUSYBOX_CONFIG_FEATURE_WGET_STATUSBAR Feb 02 11:21:18 also BUSYBOX_CONFIG_TRACEROUTE6 could be very useful, i see ping6 is already enabled Feb 02 11:22:57 build #119 of rb532 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/119 Feb 02 12:12:05 tripolar * r29990 /packages/net/ntpd/Makefile: [packages]: update ntpd to 4.2.6p5 Feb 02 12:46:57 jow_laptop: the next release of ndppd uses -std=c++0x but it doesn't compile with openwrt Feb 02 12:47:27 the flag is accepted, but the new constructs are not parsed Feb 02 12:48:01 anybody tried to compile c++0x code for openwrt? Feb 02 13:16:58 jow * r29991 /packages/utils/mc/Makefile: [packages] mc: use autoreconf fixup, remove custom Build/Prepare override, install Syntax directory, fix iconv depends (#10889) Feb 02 13:18:02 kerneis: what is needed to support c++0x? A new gcc? Feb 02 13:21:27 seems that gcc >= 4.3 should work Feb 02 13:22:30 hmm Feb 02 13:22:44 looks like g++ is not the culprit Feb 02 13:22:53 its probably uclibc++ Feb 02 13:22:53 rather uClibc++ Feb 02 13:23:01 its headers are ancient Feb 02 13:26:05 I've seen mentions of the libstdc++ package, while googling Feb 02 13:26:12 could it help? Feb 02 13:26:40 yeah but it would be big :( Feb 02 13:26:45 ok Feb 02 13:26:54 +150KB just for some C++ sugar Feb 02 13:27:01 indeed Feb 02 13:37:31 on the up side it seems upstream got rid of confuse Feb 02 13:38:42 if it must use unavailable libc++ features to do so, i'd rather call it a downside Feb 02 13:38:57 is confuse really that broken? Feb 02 13:40:39 I think thproblem is that he uses std::shared_ptr and std::weak_ptr Feb 02 13:40:46 both are C++0x features Feb 02 13:41:01 and he did that in the complete codebase, not only the config handling Feb 02 13:42:27 « I'll switch back to the old implementation of smart pointers Feb 02 13:42:30 for now, and get rid of the std::shared_ptr dependency. Feb 02 13:42:33 Also, as of 0.2.2, ndppd will no longer depend on libconfuse Feb 02 13:42:36 » Feb 02 13:42:48 as an alternative he could use boost Feb 02 13:43:10 its only headers with inline funcito Feb 02 13:43:17 *functions, no actual libraries Feb 02 13:43:20 yes Feb 02 13:46:27 anyway, Daniel is fine with the idea of rolling back to C++ < 11 Feb 02 13:46:36 great Feb 02 13:46:49 that's why he asked me to check the openwrt port Feb 02 14:06:18 jow * r29992 /trunk/package/iwinfo/ (Makefile src/iwinfo_nl80211.c): Feb 02 14:06:18 [package] iwinfo: fix segmentation fault when doing two consecutive scans through wpa_supplicant Feb 02 14:06:18 Based on patch by Christian Kapeller with one minor whitespace change Feb 02 14:06:18 and updated package version. Feb 02 14:07:01 jow * r29993 /branches/backfire/package/iwinfo/ (Makefile src/iwinfo_nl80211.c): [backfire] iwinfo: backport r29992 Feb 02 14:47:45 hello Feb 02 14:48:19 nobody for my static linking problem of yesterday? Feb 02 14:48:36 Naha: I guess you can consider it unsupported Feb 02 14:48:58 it appears that static pthreadlinking does not even work in all cases on "normal" systems Feb 02 14:49:24 what is a normal system? Feb 02 14:49:26 in any case you're probably better of with contacting upstream (uclibc.org) Feb 02 14:49:43 i think at least parts of this have been reported and maybe even fixed upstream already Feb 02 14:49:59 i do remember seeing something on the uclibc list related to sigaction and static linking Feb 02 14:50:58 is it pointless to open a ticket on the OpenWrt bugtracker? Feb 02 14:51:38 I don't think anybody is going to look into it Feb 02 14:51:40 make a simple test case, then open a ticket Feb 02 14:51:50 maybe i'll look into it when i find the time Feb 02 14:51:55 its a corner case and it might be best adressed upstream Feb 02 14:52:02 ok thanks Feb 02 14:52:02 we don't statically link pthread anywhere Feb 02 14:52:22 and at least the ticket will document the fact that it doesn't work Feb 02 14:54:26 but wouldn't such a ticket be better placed at uclibc.org ? Feb 02 14:55:06 it makes no sense to file a ticket against 10.x as we're not going to change the libc impl there Feb 02 14:55:11 and in trunk it might be already fixed Feb 02 14:55:29 if its not then that means that the latest uclibc release is still broken, in this case it makes sense to notify them Feb 02 14:55:36 as they're prearing a release Feb 02 14:55:51 no relevant party will notice it in the openwrt tracker Feb 02 14:56:18 the point of a ticket in openwrt would only be to merge an upstream fix once it exists Feb 02 14:56:29 and yes, the ticket needs to be against trunk, not 10.1 Feb 02 14:56:32 10.03 Feb 02 14:56:39 backport won't happen Feb 02 14:57:10 jow_laptop: it's still broken, I tested with trunk yesterday Feb 02 14:57:50 and I don't really care about a backport, by the way Feb 02 14:58:30 so to summarize, feel free to file a ticket but don't exepct anyone to actually look into it Feb 02 14:58:45 oh, did you see that uClibc 0.9.33 was released yesterday? Feb 02 14:58:55 yes Feb 02 14:58:57 jow_laptop: er, noted Feb 02 14:59:48 is there a chance it is fixed in 0.9.33? Feb 02 15:00:04 maybe, someone has to try it Feb 02 15:00:34 will try as soon as it is in trunk Feb 02 15:18:58 any idea when uclibc 0.9.33 will be in trunk, btw? Feb 02 15:35:27 I suppose I could give it a try this evening Feb 02 15:36:11 wow fast :-) Feb 02 15:37:05 that does not mean that it'll work :) Feb 02 15:37:18 er, sure :-) Feb 02 16:01:47 moo Feb 02 16:02:34 *PAW* Feb 02 16:03:02 if you have room on your system, try eglibc Feb 02 16:03:37 how much room is needed? Feb 02 16:03:53 I work with 4MB flash routers Feb 02 16:04:07 I suspect it isn't enough… Feb 02 16:04:12 you won't have much room for anything else Feb 02 16:04:27 or anything Feb 02 16:04:43 with the default image I have 700kB left, that's reaaaaally short Feb 02 16:04:55 I might be prepared to try uclibc again, but the testing for me is quite involved Feb 02 16:06:37 what do you mean? Feb 02 16:06:52 I mean that it's substantially slower for my PHP testing Feb 02 16:07:24 uclibc is slower than eglibc? Feb 02 16:07:40 in certain limited contexts that I know about Feb 02 16:08:46 ok Feb 02 17:20:13 anyone notice that linux-ocf has released a 3.2 compatible patch set? Feb 02 17:31:58 not yet Feb 02 17:32:08 so you think we should update ocf? Feb 02 17:33:42 dumb question, but is it possible to convert LE MIPS binaries to BE? Feb 02 17:34:13 assuming they don't have any #ifdef endian stuff Feb 02 17:34:23 probably a big mess Feb 02 17:35:51 build #92 of mpc52xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/92 Feb 02 17:38:02 Chocks: it might be theoretically possible Feb 02 17:38:12 Chocks: but it's probably practially impossible Feb 02 17:38:23 I'm not sure it's worthwhile. Feb 02 17:38:34 ok, so who decides the endian of a given MIPS processor? Feb 02 17:38:48 some cpus have strapping options Feb 02 17:38:56 maybe even most of them Feb 02 17:39:05 and endian aside, is it likely, given the same toolchain, that my ramips and ar71xx binaries are identical? Feb 02 17:39:17 what do you mean by 'identical'? Feb 02 17:39:45 there's not just the endian type of instructions Feb 02 17:39:51 but also of data, and interpretation of external data Feb 02 17:39:54 I mean, that there are no toolchain options that would cause a binary built for one to not work on the other Feb 02 17:40:10 yes, I know. let's assume they are the same endian Feb 02 17:40:34 aside from endian, ramips and ar71xx can probably take the same binaries in user space Feb 02 17:40:48 why do you ask? Feb 02 17:40:57 thought so. "file" tells me they have the same ELF format, although I know that's not the complete story Feb 02 17:41:10 I'm just wondering for future refernce Feb 02 17:41:12 +e Feb 02 17:43:38 Chocks: what you also have to look out for is the mips32 revison; (older) bcm47xx and bcm63xx are mip32r1, but ramips and ar71xx are mips32r2 (which is backward compatible to mips32r1). So you could in theory use the bcm47xx binaries on ramips (or the bcm63xx ones on ar71xx), but not the other way round. Feb 02 17:43:48 aye Feb 02 17:46:00 newer bcm47xx, newer ar71xx (ar93xx/ar94xx) and newer ramips (rt3662/rt3883) even support DSP instructions which would make binaries not work on older mips32r2 chips, but I don't think we have that enabled (because of the breakage, and for most apps there is no gain in it) Feb 02 17:48:07 jow_laptop: I was saying yesterday that luci wasn't running for me locally, with make runhttpd, "Unable to read UCI data:" .. self.config is indeed the line it fails on, Feb 02 17:48:18 it works for one of my cbi modles, but not the other, Feb 02 17:48:28 both of them work on the owrt router, Feb 02 17:48:46 and on my linux dev machine, uci show blah_name works for both of them too. Feb 02 17:50:00 karlp: maybe it does not exist in host/etc/config/ in the sdk environment? Feb 02 17:50:11 rember that it uses a prefix Feb 02 17:50:19 *remember Feb 02 17:50:24 yep, true. Feb 02 17:50:35 ok, how did one of my config files get there, but not the other one? Feb 02 17:51:13 the development guide says not to edit anything in the host directory, as they will be lost when you rerun make? Feb 02 17:51:18 not sure Feb 02 17:51:26 luci ships a number of configs Feb 02 17:51:31 with the sdk Feb 02 17:52:08 if you have a fully operational uci on your host system you can as well edit build/setup.lua and comment out the overriding of the uci contructors Feb 02 17:52:47 the not edit warning refers more to source files which are overwritten on the next run Feb 02 17:53:08 if you put additional files they're not deleted until you run an explicit host-clean Feb 02 17:53:31 ok,no rule to make host-clean ? Feb 02 17:53:49 jow_laptop: did 29988 introduce a missing symbol? CONFIG_NETFILTER_XT_MATCH_ECN? Feb 02 17:53:53 can I stop it from asking me for some sort of password all the time too? Feb 02 17:54:04 karlp: you can also further decrease the number of built/copied stuff by running make runuhttpd MODULES="applications/myapp" Feb 02 17:54:07 password?! Feb 02 17:54:17 it tells me that no password is set on this router. Feb 02 17:54:27 ah Feb 02 17:54:33 and I can just put in anything and lets me in, but keeps showing a "no password is set" warning window on top Feb 02 17:54:40 and what's jogo's IRC handle? Feb 02 17:54:47 philipp64|laptop: KanjiMonster Feb 02 17:54:47 jogo = KanjiMonster Feb 02 17:54:52 ;) Feb 02 17:54:56 ah, that's you. Feb 02 17:55:09 thanks for putting in 3.3. Feb 02 17:55:22 yw Feb 02 17:55:24 I added the missing symbols for x86. Feb 02 17:55:47 what would normally place a file in the host/etc/config directory? Feb 02 17:55:48 I only tested bcm63xx (which still has some issues, hence not committed yet) Feb 02 17:57:04 it's patch #1813. Feb 02 17:57:37 karlp: try this: http://pastebin.com/wmtRhHcE Feb 02 17:59:24 and comment out the SYSROOT .. parts in cursor_state and .cursor() to use the real system uci? Feb 02 18:00:24 karlp: yes Feb 02 18:00:40 or comment out the whole function redeclaration Feb 02 18:01:18 hmm, of course, then I need to make sure that no other applications are loaded :) Feb 02 18:01:21 * karlp reloads again. Feb 02 18:01:31 moo Feb 02 18:02:19 karlp: you can prevent it from rebuilding anything with make runuhttpd MODULES="" Feb 02 18:02:37 karlp: or only let it rebuild your own app with make runuhttpd MODULES="applications/foo" Feb 02 18:03:05 my real system /etc/config has working uci config files for the two apps referred to by applications/luci-remake, Feb 02 18:04:09 but with the SYSROOT append commented out, and make clean, then make MODULES="applications/luci-remake" it still gets stuck on "getifaddrs" Feb 02 18:04:13 and doesn't finish starting. Feb 02 18:04:19 ? Feb 02 18:04:55 "still" ? I was not even ware that it does not finish starting Feb 02 18:05:07 I had the impression your issue was with missing config files? Feb 02 18:05:19 that was before I commented out the sysroot appending Feb 02 18:05:33 with SYSROOT appending in place, it just doesn't find my files, (because they're not in host/etc/config) Feb 02 18:06:49 I have no idea what your current problem is, please paste a log or something Feb 02 18:08:08 if I just symlink my config files from the real /etc/config/ into host/etc/config it all works pretty well enough. Feb 02 18:08:30 can't luci make the config file from the CBI if it doesn't exist already? Feb 02 18:09:10 no Feb 02 18:10:16 so I've just been lucky that my package installer writes in a default file itself then :) Feb 02 18:10:30 philipp64|laptop: you lied! ;p -> "Bump to 3.2.2" (...) "+LINUX_VERSION:=3.2.1" Feb 02 18:10:32 ok, and in this development luci, nothing installed those files, so that's workable. Feb 02 18:11:01 umm... for which? Feb 02 18:11:18 KanjiMonster, philipp64|laptop: apart from that please keep stuff separated Feb 02 18:11:19 unless you want to go digging on the taking out SYSROOT and using the system uci, I think I'll just use the symlinkd config files into host/e/c, and keep working on the luci bits itself. Feb 02 18:11:33 bumping 3.2.x is not related to updating geos Feb 02 18:11:46 that should happen centrally Feb 02 18:12:05 jow_laptop: the bump is for the geos subtarget only Feb 02 18:12:51 KanjiMonster: except that x86 seems to be permanently stuck in 2.6.39.4 limbo. I tried to ask Imre why that was, but I didn't really get an answer. Feb 02 18:12:55 if I run: "make runhttpd MODULES="applications/luci-remake"" though, I still have asterisk and voice and freifunk tabs and NIU and Essentials and Freifunk in the top right, I thought it was only going to run my module? Feb 02 18:13:23 karlp: well it does not delete previous stuff from host/, only copies over new stuff Feb 02 18:13:40 philipp64|laptop: but aside from that, you should split the gpio-kmod naming cleanup and the version bump into its own patches; the patch looks like several things stuffed together Feb 02 18:14:01 KanjiMonster: we should not bump single subtargets either Feb 02 18:14:03 ah, you missed that conversation.... Feb 02 18:14:25 we already have ten different minor kernel versions, no need to split them at the micro level too now Feb 02 18:14:34 and make clean doesn't clean the host then I take it? Feb 02 18:14:49 karlp: make hostclean Feb 02 18:15:06 ahh ok, host-clean was earlier, which didn't exist :) Feb 02 18:15:07 KanjiMonster: it's hard to get even a single x86 ugly-stepchild patch committed... it's harder still to get a series of 5 done in a timely, sequenced fashion that doesn't leave the target in an intermediately broken state. Feb 02 18:15:38 I'd be happy to break the patches up if I were committing them myself and had control over their going in in a timely fashion, but that's not the case. Feb 02 18:16:02 well I'd be happy to commit the if they where broken up Feb 02 18:16:07 but thats not the case Feb 02 18:16:26 if I start applying x86 patches from a series I do all Feb 02 18:16:41 assuming that we only do one and leave the rest lingering for extended perios of time is wrong Feb 02 18:16:50 as for version numbering... 3.2.1 recently got replaced in include/kernel-version.mk.... Feb 02 18:17:10 so at the time I submitted my patch, 3.2.1 was the most recent version in that file... Feb 02 18:17:12 * Chocks gives philipp a red-headed wig Feb 02 18:17:32 philipp64|laptop: also if your split up patches leave the tree in a broken state in between then you are doing something wrong; they should never create a breakage that gets fixed by a later patch; this makes bisecting a real PITA Feb 02 18:17:55 jow_laptop: http://www.pastebay.org/306744 Feb 02 18:18:23 philipp64|laptop: ok then it a matter of wording. "Bump to 3.2.2" implies that you somehow update the version somewhere (which I don't see anywhere) so you probably meant you synced the config Feb 02 18:18:26 KanjiMonster: target names have changed in 3.1. especially the gpio-cs5535 driver. Feb 02 18:18:45 so the version number bump and the gpio driver cleanup are intimately related. Feb 02 18:20:15 karlp: sigh, well you obviously have to add essential modules too for the initial run, like make runuhttpd MODULES="libs/* themes/* modules/admin-core modules/admin-full applications/yourapp" Feb 02 18:20:56 karlp: after you got a complete environment this way you can do subsequent runs with only make runuhttpd MODULES="applications/yourapp" to only "rebuild" your part of the system Feb 02 18:21:02 jow_laptop: well, the alix patch went in and the net5501 driver didn't. ditto for the geos one. Feb 02 18:21:29 how do you want the geos commit broken up? Feb 02 18:22:35 jow_laptop: I'm trying, I really am, but this is not exactly documented, or obvious. at least not to me. it's certainly not described here: http://luci.subsignal.org/trac/wiki/Documentation/DevelopmentEnvironmentHowTo Feb 02 18:22:59 karlp: no worries, just too much stuff at once here Feb 02 18:23:13 yeah, sorry about that :) Feb 02 18:23:23 actually I try to do actual stuff for days but don't get to it Feb 02 18:23:47 me too, I'm only back to working on this for the first time since I was asking you about it yeterday, all day was helping other people. Feb 02 18:24:06 anyway, I've got all your notes from yesterday on templtes, so I'm going to play with that now that it's running locally :) Feb 02 18:24:09 thanks again. Feb 02 18:24:18 philipp64|laptop: is it intentional that net5501 uses kmod-wdt-geode ? Feb 02 18:24:26 ok... trying to get a concrete answer here.... given that (a) the default version for x86 is 2.6.39.4 and (b) the driver names for the CS5535 GPIO driver changed in 3.1... how do I separate the GPIO cleanup from the version bump and *not* break things? Feb 02 18:24:43 jow_laptop: yes, why? Feb 02 18:25:24 because the naming is confusing (no, thats not your fault, not thats not a critique, no I do not want to imply that you should clean it up) Feb 02 18:25:54 just wondered to see something geos in net5501 Feb 02 18:25:58 (yes about using kmod-wdt-geod I mean...) Feb 02 18:26:05 also why so much more packages? Feb 02 18:26:10 thats another hold up for me Feb 02 18:26:26 do net5501 units have dsl? Feb 02 18:27:08 all those drivers were previously built in statically.... the changes to target.mk reflects making them modular. Feb 02 18:27:34 the net5501's don't have onboard DSL, no... but they frequently use the solos PCI cards. Feb 02 18:27:36 seems like not, I'll add that net5501 patch but I'll throw out the dsl specific packages Feb 02 18:28:08 at alater stage we could define DSL profiles which select the appropriate additional packages Feb 02 18:28:47 so about the Geos target... and the GPIO cleanup.... Feb 02 18:29:09 moment, let me bring the rest in sync first Feb 02 18:30:19 in this patch the config-defualt got updated. which kernel does it target? http://patchwork.openwrt.org/patch/1814/ Feb 02 18:31:28 you said 3.2.2 but default is at 2.6.39.x (no discussion here now) but did set LINUX_VERSION in target.mk to 3.2.2 Feb 02 18:31:34 erm to 3.2.1 Feb 02 18:31:46 is this a typo in the description? Feb 02 18:32:16 no, that was me being an idiot with git stash pop Feb 02 18:32:52 the linux version should be 3.2.2 ... when I submitted the patch, as I said, include/kernel-version.mk said 3.2.1 Feb 02 18:33:08 then it got updated while the patch was sitting in the queue. Feb 02 18:33:31 I didn't notice until after I had created the patch but hadn't yet sent the email. Feb 02 18:33:34 I'll update. Feb 02 18:33:41 ok, I�ll defer that one then Feb 02 18:33:51 on to net5501 Feb 02 18:34:39 who wants to update my 2.6.27 ramips patches to 2.6.39, ktb. Feb 02 18:34:47 er. 2.6.37 Feb 02 18:41:14 jow * r29994 /trunk/target/linux/x86/net5501/ (10 files in 6 dirs): (log message trimmed) Feb 02 18:41:14 [PATCH] net5501: correct net5501 h/w configuration Feb 02 18:41:14 Bump to version 3.2. Feb 02 18:41:14 Simplify and correct kernel config (based on x86/config-3.2). Feb 02 18:41:14 Designate eth0 as wan interface, and bridge eth1/eth2/eth3. Feb 02 18:41:14 Add heartbeat LED trigger. Feb 02 18:41:14 Use correct CS5535 GPIO driver. Feb 02 18:44:39 jow * r29995 /trunk/target/linux/x86/geos/target.mk: Feb 02 18:44:40 [PATCH 1/2] geos: cleanup GPIO driver name Feb 02 18:44:40 In 3.1, the old drivers/char/ entry for the CS5535 GPIO driver went obsolete. Feb 02 18:44:40 Make Geos use a recent kernel and remove this ambiguity. Feb 02 18:44:40 [Patch from Philipp Prindeville, via http://patchwork.openwrt.org/patch/1815/] Feb 02 18:45:50 philipp64|laptop: now, can I update alix2 and net5501 to 3.2.2 ? Feb 02 18:48:39 philipp64|laptop: and where is patch 2/2 ? Feb 02 18:49:44 just sent it out. Feb 02 18:51:07 uhm that target.mk change is already applied Feb 02 18:51:49 partially that is Feb 02 18:52:01 ok, let me sync up. Feb 02 18:52:13 I'll merge it by hand now to not confuse it even further Feb 02 18:53:19 fwiw, make runhttpd keeps printing out "sh: brctl: not found", even reloading my own page, which shouldn't be doign anything with interfaces or anything. Feb 02 18:53:55 philipp64|laptop: but stupid question, where exactly is that backport? Does it mean you jsut enabled a kernel capability or did you forget to add a patch to this patch? Feb 02 18:54:29 karlp: yeah thats network model executing brctl show to find bridges, I know it shouldn't do that but adding a special case for the sdk was not worth it Feb 02 18:55:34 yeah, no sweat. Feb 02 18:55:50 should it be doing it when I press on my own tab again though? Feb 02 18:55:58 it seems to try it everytime I hit my tab. Feb 02 18:56:19 well if something in the stack instantiates luci.model.network then yes Feb 02 18:57:10 philipp64|laptop: is CONFIG_GEOS=y enabling the platform driver? Feb 02 18:57:23 oh yeah, luci rebuilds that menu of tabs every time Feb 02 18:57:45 philipp64|laptop: yeah it is, found it Feb 02 18:58:23 jow * r29996 /trunk/target/linux/x86/geos/target.mk: (log message trimmed) Feb 02 18:58:23 [PATCH 2/2] geos: backport Geos driver from linux-next Feb 02 18:58:23 Backport of linux-next driver. Feb 02 18:58:23 Driver adds support for LEDS and S/W button. Feb 02 18:58:23 Add hotplug script for button actions. Feb 02 18:58:23 Add Openwrt system config for LEDS triggers. Feb 02 18:58:23 Add updated kernel .config for 3.2 symbols. Feb 02 18:59:53 jow * r29997 /trunk/target/linux/x86/geos/ (5 files in 4 dirs): [x86] geos: add missing files from previous commit Feb 02 19:00:42 jow * r29998 /trunk/target/linux/x86/ (alix2/target.mk net5501/target.mk): [x86] alix2, net5501: bump both subtargets to Linux 3.2.2 to align with the rest Feb 02 19:06:24 jow * r29999 /trunk/target/linux/x86/ (alix2/target.mk geos/target.mk net5501/target.mk): Feb 02 19:06:24 [x86] alix2, goes, net5501: clean up default packages Feb 02 19:06:24 Remove packages which are dependencies of other packages Feb 02 19:06:24 Remove packages which are part of the default package list Feb 02 19:06:24 Remove DSL specific packages from net5501 Feb 02 19:06:24 Remove bridge package, we use the busybox applet Feb 02 19:06:25 Replace hostapd with wpad Feb 02 19:11:15 jow_laptop: if I set a template on a option(DummyValue), how can I pass the map of values to it? Feb 02 19:11:42 and is there a magic lua way of getting the correct link path to reach a page lik, "entry({'admin', 'RME', 'diags'}," Feb 02 19:11:54 jow * r30000 /trunk/target/linux/x86/ (alix2/target.mk geos/target.mk net5501/target.mk): [x86] alix2, geos, net5501: remove kmod-ledtrig-netfilter, its not used by any standard system facility Feb 02 19:12:01 hardcoding ../diags or something doesn't feel real reliable. Feb 02 19:12:33 karlp: luci.dispatcher.build_url("admin/RME/diags") Feb 02 19:13:02 karlp: or luci.dispatcher.build_url("admin", "RME", "diags") if you prefer that Feb 02 19:13:39 congrats jow Feb 02 19:13:43 :P Feb 02 19:13:59 and to pass things into the template? Feb 02 19:14:04 oh yeah, r30k :) Feb 02 19:14:14 party like it's the year 30,000! Feb 02 19:14:18 im gonna open some redbulls thinking of you owrt guys Feb 02 19:14:45 karlp: x = s:option(...); x.foo = 123; x.template = "whatever" Feb 02 19:15:09 and then the template should be able to do <%=foo%> right? Feb 02 19:15:23 karlp: within the template, just reference self.foo Feb 02 19:15:35 ahh, I was missing the self earlier. Feb 02 19:17:16 lovvvvely Feb 02 19:19:00 jow_laptop: glad to see the broken dependencies with kmod-crypto-ocf on crypto-headers and openssl have been fixed. Feb 02 19:19:15 I previously had to name them explicitly. Feb 02 19:20:17 how does ppp get included? is that a base dependency in Openwrt now? Feb 02 19:20:32 it always has been Feb 02 19:20:50 include/target.mk DEFAULT_PACKAGES Feb 02 19:21:01 apart from that ppp-mod-pppoa will pull it in as well Feb 02 19:21:13 ok, good. Feb 02 19:21:35 sent one more patch out... Feb 02 19:22:21 now... to figure out why the LED stuff in ath5k is unstable... Feb 02 19:23:01 errr... comment should say "and x86/patches-3.3 ..." sigh... not getting enough sleep. Feb 02 19:26:35 jow * r30001 /trunk/target/linux/x86/ (4 files in 2 dirs): Feb 02 19:26:35 [PATCH 1/1] alix2: backport platform driver updates from linux-next Feb 02 19:26:35 Add patches to x86/patches-3.2 and x86/patches-3.3 (update will appear in 3.4). Feb 02 19:26:35 [Patch from Philipp Prindeville, via http://patchwork.openwrt.org/patch/1817/] Feb 02 19:26:46 build #132 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/132 Feb 02 19:27:33 jow_laptop: thanks! Feb 02 19:31:34 build #130 of ubicom32 is complete: Failure [failed compile_1] Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/130 Feb 02 20:10:19 anyone else using linuxigd? Feb 02 20:35:05 you, yourself and your alter-ego Feb 02 20:42:38 ok guys, im going to build a r30k image, so 2.6.39.4 is still default for ar71xx ? 3.2 and 3.3. were tested ok? Feb 02 20:43:04 2.6.39.4 is still default Feb 02 20:43:10 jow_laptop: execute permission got dropped from target/linux/x86/geos/base-files/etc/hotplug.d/button/50-reboot Feb 02 20:43:32 philipp64|laptop: hotplug handler need no execute permission Feb 02 20:43:37 aight, thanks, i'll go with 2.6 Feb 02 20:43:45 ok, good to know. Feb 02 20:43:56 philipp64|laptop: they're sourced Feb 02 20:44:31 see package/base-files/files/sbin/hotplug-call Feb 02 20:44:38 I believe you. Feb 02 20:44:44 KanjiMonster: 1813? Feb 02 20:47:37 delboy_: what wifi do you have? Feb 02 20:47:42 philipp64|laptop: gimme a few minutes, I'm currently preparing an upstream patch Feb 02 20:50:52 btsimonh: b/g ath5k Feb 02 20:53:11 did it give you many problems getting it going? Feb 02 20:54:50 yes, had problems with that eeprom stuff Feb 02 20:55:36 but it didn't had any problems like you have with eeprom Feb 02 20:56:18 but even when i got the eerpom hacked in, it still did not transmit :( - did oyurs fire up once you had the eeprom in place? Feb 02 20:56:31 yes Feb 02 20:56:55 and did you have to read stuff from eeprom and set into pci regs? Feb 02 20:58:39 nope, I just added eeprom into that mach.h because sx763 has the same eeprom on all boards and I got it working Feb 02 20:59:15 i still use 168c:ff96 or something for pci id Feb 02 21:00:24 maybe your orig fw does something to eeprom before wlan driver init, like on arcadyan boards Feb 02 21:00:47 I think they have some regdomain issues Feb 02 21:01:23 i'll take a look at your eeprom - it's still in my mach header :) Feb 02 21:01:32 it seems to be a good joke among OEMs to set the flash eeprom to nonesense and then fixing it up in software Feb 02 21:01:46 (w.r.t. regdomains) Feb 02 21:02:02 jogo * r30002 /trunk/target/linux/ (generic/config-3.3 x86/config-3.3): Feb 02 21:02:02 x86: add 3.3 generic symbols Feb 02 21:02:02 Copy x86/config-3.2 to x86/config-3.3 and add additional symbols (for 3.3-rc2). Feb 02 21:02:02 Signed-off-by: Philip Prindeville Feb 02 21:03:06 was at 'talktalk' yesterday through work. didn't want to let on i was hacking bt hubs :) they might have seen me as a threat... Feb 02 21:04:25 tsk Feb 02 21:07:13 nbd: ping pls, i would like to test netifd with a wr740n, pppoe setup with ipv6 and all. unfortunately i still dont have a serial adapter at hand yet so i would like to ask if it is safe to try it like this :P Feb 02 21:10:12 Delboy_: did you work out why you have a second 5aa5? Feb 02 21:11:46 00:0e.1 Serial controller [0700]: Atheros Communications Inc. Device [168c:ff96] (rev 01) Feb 02 21:12:21 I haven't read your question that good :) Feb 02 21:12:43 where in the beginning? Feb 02 21:13:44 6th line of the data in the h (for 763, at least). Feb 02 21:13:59 the 5aa5 is the 'magic'. Feb 02 21:14:15 yes, but moo Feb 02 21:15:25 that is the original 5aa5 magic, I added other one to the beginning because otherwise ath5k says some error about eeprom size Feb 02 21:16:15 :). so original looked for calibration data in a different place to the ath5k code... Feb 02 21:17:36 something like that, try doing the same thing maybe it will work for you Feb 02 21:19:26