**** BEGIN LOGGING AT Sun Oct 17 02:59:58 2010 Oct 17 04:22:57 hmm. there apparently is *one* value in the wgt634u's "normal" nvram block, sdram_ncdl Oct 17 04:26:33 is there an archive somewhere of device stock images? like that could be perused for locations of FLSH and other configuration data? Oct 17 04:27:55 i have a patch that lets broadcom-diag figure out a wgt634u now Oct 17 04:28:05 [florian]: ping Oct 17 04:28:44 if my wgt634u didn't kill itself a while back I'd test out the patch Oct 17 04:29:56 it starts to boot, but crashes w/in a minute or so, quick enough that I can't even tftp upload images to the bootloader Oct 17 04:32:47 Bartman007: it locks up even if you interrupt the boot process? Oct 17 04:33:21 EqUaTe: yeah. after a while it stops responding to serial input Oct 17 04:33:37 yikes.. overheating issue perhaps? Oct 17 04:33:58 there is still an led issue Oct 17 04:34:30 not worth my time to diagnose past what I've already done. the little bugger served me well for a number of years, but I have a number of other functional devices that can take it's place. Oct 17 04:34:40 hehe Oct 17 04:34:50 not overheating though, occurs while cold Oct 17 04:35:26 caps aren't bulging, but still may be going Oct 17 04:35:57 the WAN led stays yellow Oct 17 04:36:51 i have a pile of them with odd quirky behavior like that Oct 17 04:37:10 well, a mixture of problems, but one or two that do a reboot after a few minutes Oct 17 04:37:43 russell_: an LED not changing colour just means something isn't being done at the right stage, but is cosmetic. Oct 17 04:39:21 Bartman007: one thing.. you have tried a different psu, right? :P Oct 17 04:40:49 * russell_ would like to gently suggest that the new-wiki idea was a gigantic disaster. it accomplished approximately nothing and killed participation. whatever the original goals, it would have been smarter to just start fixing pages that you didn't like the organization of. there. i feel better. Oct 17 04:44:29 wtf does sdram_ncdl stand for anyway? Oct 17 04:45:38 no idea, but i disagree about the new wiki being a complete disaster - it was necessary Oct 17 04:45:51 what's killed participation is the fact that it took ~2 years to make the switch Oct 17 04:46:00 with both running side by side Oct 17 04:46:08 no it wasn't. all pages have a fucking edit button on them, go to work! Oct 17 04:46:38 i can tell you i participated a lot before, i haven't made a single edit since the new wiki Oct 17 04:46:46 because it's fucking impossible Oct 17 04:46:48 there was no standardisation, no templating.. Oct 17 04:46:52 how so? Oct 17 04:47:18 so, introduce a template and start editing them into the template with all the information in front of you! Oct 17 04:47:35 there still isn't a wgt634u page on the new wiki, because i can't create one Oct 17 04:47:38 personally i support the switch to the new one. Oct 17 04:47:56 i don't support it taking 2 years where noone knew which to edit Oct 17 04:48:36 where would the wgt634u page be on the new wiki? Oct 17 04:48:40 like, for example, i figured on the jtag on a wgt, but there is no place to record/share that information Oct 17 04:48:55 nfi Oct 17 04:49:12 no, where SHOULD it be? Oct 17 04:49:16 in the ToH Oct 17 04:49:19 what brand is it? Oct 17 04:49:22 netgear Oct 17 04:49:34 does openwrt work on it already, or does it need tweaking? Oct 17 04:49:39 omg Oct 17 04:49:44 it was like one of the first one Oct 17 04:49:45 s Oct 17 04:49:56 i wouldn't know, i'm not an encyclopedia Oct 17 04:50:03 it was supported for like 5 years until it got broken Oct 17 04:50:32 the wiki is supposed to be the encyclopedia Oct 17 04:50:37 are you logged into the wiki? Oct 17 04:50:53 it was easy before, it is difficult now Oct 17 04:51:08 it discourages participation Oct 17 04:51:15 http://wiki.openwrt.org/toh/netgear/wgt634u Oct 17 04:51:20 took me 10 seconds Oct 17 04:51:49 i tried before, it didn't let me Oct 17 04:52:05 define 'didnt let me' Oct 17 04:52:11 did you get an error? Oct 17 04:52:25 i don't remember, it was a year ago Oct 17 04:52:56 it was a year ago, when the 'old' wiki was still in full swing, and you're STILL bitching about it? Oct 17 04:53:02 holy fuck dude, hold a grudge much? Oct 17 04:53:04 no Oct 17 04:53:24 a year ago, the new wiki had fuckall info in it, and the old one was not locked. Oct 17 04:53:31 the old wiki was offline for 6 months before the new wiki made it's first appearance Oct 17 04:53:39 umm.. no. Oct 17 04:53:43 yeah Oct 17 04:53:46 it just moed. Oct 17 04:53:47 moved* Oct 17 04:54:08 it disappeared (or became un-editable) in april or something Oct 17 04:54:18 the wikis were on oldwiki and nuwiki for a couple of years Oct 17 04:54:34 can you edit the old wiki? Oct 17 04:54:35 no Oct 17 04:54:37 by april of this year, the new wiki actually had some information on it, and was moderately useful. Oct 17 04:54:46 you could a year ago Oct 17 04:54:55 anyway Oct 17 04:55:05 you lost at least a year, and my participation, is all i'm saying. for basically nothing. Oct 17 04:55:17 stop being an arse, i've proven to you that creating pages is easy, i even did it for you! Oct 17 04:55:22 just log in, and put your damned info into it. Oct 17 04:55:47 for reference, i'm not a dev, and i have no affiliation with openwrt other than as a user and as someone trying to get it working on a couple more devices. Oct 17 04:56:12 i've had that wiki account for quite a long time, and used it for quite a long time. and i've never had any issues with it. Oct 17 04:59:04 where is the template? Oct 17 04:59:54 http://wiki.openwrt.org/inbox/trialtemplate Oct 17 05:06:27 is it possible to get raw text out of the old wiki? Oct 17 05:06:38 i.e. the old markup? Oct 17 05:12:48 there are no filters that will convert from one format to the other? Oct 17 05:18:10 EqUaTe: yes, multiple PSUs Oct 17 05:18:43 philipp64|laptop: huh? Oct 17 05:18:49 russell_: no idea.. view source? Oct 17 05:18:58 Bartman007: fair enough.. always worth checking :) Oct 17 05:19:01 no button for that on oldwiki Oct 17 05:20:03 EqUaTe: a lot of wikis have import filters to get import from one format to their native one to facilitate migrating wiki content. Oct 17 05:20:22 russell_: are you seriously being that dense? Oct 17 05:20:29 philipp64|laptop: can't comment.. Oct 17 05:20:33 * errr get content from one.... Oct 17 05:20:44 moinmoin has a "Raw text" thingie Oct 17 05:21:06 i want to see the wiki markup, not the html Oct 17 05:23:05 russell_: "Show pagesource" Oct 17 05:23:18 on the oldwiki? Oct 17 05:23:21 give _agb 20 64 Oct 17 05:23:32 oops, minecraft command was in my pastebuffer. Oct 17 05:23:49 http://wiki.openwrt.org/oldwiki/ Oct 17 05:23:57 yes russell_ - on the right hand side. Oct 17 05:24:03 all the actions are on the right of the wiki pages. Oct 17 05:24:25 http://oldwiki.openwrt.org/OpenWrtDocs%282f%29Hardware%282f%29Netgear%282f%29WGT634U.html Oct 17 05:24:41 http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/netgear/wgt634u?do=edit&rev= <-- there. Oct 17 05:24:57 well, here's a request for the Wiki: a meaningful explanation of the message: "WARNING: kmod-hwmon-core is not available in the kernel config" and it's ilk. Oct 17 05:25:13 been staring at that one for hours. Oct 17 05:25:15 philipp64|laptop: it means you fucked up in the kernel config. Oct 17 05:25:28 that much I got. what's the fix? Oct 17 05:25:35 short version: don't play with the kernel configs if you don't know what the different bits do Oct 17 05:25:44 long version: turn i2c back on Oct 17 05:25:54 then turn on the hardware sensors Oct 17 05:26:01 but I'm building it as a module. Oct 17 05:26:18 and perhaps look at the package info to see what it's testing for. Oct 17 05:26:22 yes, on doesn't mean y Oct 17 05:26:24 it can mean m Oct 17 05:26:29 why does it need to be in the kernel .config if I'm kmod'ing it? Oct 17 05:26:48 if it isn't in the kernel .config, how is it going to get built??! Oct 17 05:26:56 it's still _PART_ of the kernel Oct 17 05:26:59 it's not an external module Oct 17 05:27:18 don't KernelPackage's get built "out-of-tree"? Oct 17 05:27:43 go try what i've said and report back. you'll have your answer from that. Oct 17 05:27:57 what's the point of calling them out in KCONFIG:= .... otherwise? Oct 17 05:28:23 russell_: the oldwiki.openwrt.org namespace is deprecated afaik.. everything has been moved to wiki.openwrt.org/oldwiki/ now Oct 17 05:28:33 thanks Oct 17 05:28:48 if you look up, i did paste you the precise page you wanted Oct 17 05:29:02 yeah i saw it, thank you. Oct 17 05:30:17 EqUaTe: so even though the KernelPackage/ sets KCONFIG to include CONFIG_HWMON, I still need to duplicate it in my subtarget's config-defaults? Oct 17 05:30:28 that seems redundant. Oct 17 05:30:31 i don't know. Oct 17 05:30:37 try it and find out. Oct 17 05:31:17 you'd think all it needed to check was that it was neither =y or =m. Oct 17 05:31:36 ok, retrying... again... Oct 17 05:58:05 fail. Oct 17 06:05:28 philipp64|laptop: perhaps use V=99 and pastebin the output Oct 17 06:05:40 and are you doing make, or are you building the package specifically? Oct 17 06:16:01 I'm doing a "make package/kernel/compile V=99" ... http://pastebin.ca/1964643 Oct 17 06:18:09 well, that one tells you what's missing. Oct 17 06:18:27 that bit may even be in the normal openwrt menuconfig Oct 17 06:34:01 not following. I had added CONFIG_I2C_GPIO=m to target/linux/x86/geos/config-defaults and rebuilt. Oct 17 06:41:52 run make package/kernel/clean Oct 17 06:41:58 then do compile again Oct 17 06:46:01 that's what I did. Oct 17 06:54:54 philipp64|laptop: then look MUCH further up for why the module didn't build. Oct 17 07:19:00 * russell_ just sent my wgt634u patch to openwrt-devel ml Oct 17 10:53:58 what is the usb udc? Oct 17 10:56:23 danitool: a cdevice class for usb gadgets Oct 17 10:56:27 *device Oct 17 10:58:29 :| Oct 17 10:58:58 seems to be some foundation class for usb client hardware Oct 17 11:03:48 does it mean, when I have a USB type B plug on the board to use it as a modem ADSL then that is UDC? Oct 17 11:04:27 to plug it through usb to the pc Oct 17 11:04:49 I guess so Oct 17 12:21:01 build #9 of ramips is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/9 Oct 17 12:24:35 mb * r23494 /packages/net/xsupplicant/Makefile: xsupplicant: Internal LEX deps are broken. Disable parallel build. Oct 17 12:40:16 build #8 of s3c24xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/8 Oct 17 12:45:02 florian * r23495 /trunk/target/linux/x86/ (geos/target.mk net5501/target.mk): Oct 17 12:45:03 [x86] Use -pipe for net5501 and geos CFLAGS, same as all of the other platforms Oct 17 12:45:03 Makes the builds run slightly faster on multicores. Oct 17 12:45:03 Signed-off-by: Philip Prindeville Oct 17 12:53:09 mb * r23496 /packages/utils/firmwarehotplug/Makefile: firmwarehotplug: Fix parallel build Oct 17 12:56:57 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/uscan.shtml Oct 17 13:52:10 build #11 of at91 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/11 Oct 17 14:11:30 florian * r23497 /trunk/target/linux/brcm63xx/patches-2.6.35/200-extended-platform-devices.patch: Oct 17 14:11:31 [brcm63xx] register earlier extended platform devices Oct 17 14:11:31 Signed-off-by: Miguel Gaio Oct 17 14:11:35 florian * r23498 /trunk/target/linux/brcm63xx/patches-2.6.35/ (2 files): Oct 17 14:11:35 [kernel] backport SPI master with no RXTX support (from 2.6.36) Oct 17 14:11:35 Signed-off-by: Miguel Gaio Oct 17 14:11:42 florian * r23499 /trunk/target/linux/brcm63xx/patches-2.6.35/ (2 files): Oct 17 14:11:42 [brcm63xx] add 74x164 SPI chip support Oct 17 14:11:42 Signed-off-by: Miguel Gaio Oct 17 14:11:47 florian * r23500 /trunk/target/linux/brcm63xx/patches-2.6.35/200-spi-board-info.patch: Oct 17 14:11:47 [brcm63xx] add spi devices board info int bcm63xx_boards Oct 17 14:11:47 Signed-off-by: Miguel Gaio Oct 17 14:11:51 florian * r23501 /trunk/target/linux/brcm63xx/patches-2.6.35/221-board-NB4.patch: Oct 17 14:11:51 [brcm63xx] refresh nb4 support. Register 74x164 device Oct 17 14:11:51 Signed-off-by: Miguel Gaio Oct 17 14:12:10 florian * r23502 /trunk/target/linux/brcm63xx/patches-2.6.35/ (3 files): Oct 17 14:12:10 [brcm63xx] refresh patches Oct 17 14:12:10 Signed-off-by: Miguel Gaio Oct 17 14:12:20 florian * r23503 /trunk/target/linux/brcm63xx/config-2.6.35: Oct 17 14:12:20 [brcm63xx] restore kernel oldconfig Oct 17 14:12:20 Signed-off-by: Miguel Gaio Oct 17 14:12:27 florian * r23504 /trunk/target/linux/brcm63xx/patches-2.6.35/240-spi.patch: Oct 17 14:12:28 [brcm63xx] fix SPI driver, move register out of driver code Oct 17 14:12:28 Signed-off-by: Tanguy Bouzéloc build #13 of atheros is complete: Failure [failed shell_10] Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/13 Oct 17 16:35:32 florian * r23505 /trunk/target/linux/brcm63xx/ (30 files in 2 dirs): [brcm63xx] remove 2.6.32 support Oct 17 16:39:44 [florian]: damnit, now I have to rebase my local patches ;) Oct 17 16:40:20 <[florian]> KanjiMonster: it's been a while since we switched to 2.6.35, do not lag behind too long ;) Oct 17 16:41:37 [florian]: I thought keeping the LTS kernel was intentional ;) Oct 17 16:41:57 <[florian]> KanjiMonster: I think we will have to switch to another LTS kernel sooner or later anyway Oct 17 16:50:34 mb * r23506 /packages/Xorg/driver/xf86-video-glamo/Makefile: xf86-video-glamo: Fails to compile on some arches. Make it depend on s3c24xx. Oct 17 16:55:51 mb * r23507 /trunk/target/linux/omap24xx/ (config-2.6.35 patches-2.6.35/): omap24xx: Remove 2.6.35 support Oct 17 17:48:45 florian * r23508 /trunk/target/linux/brcm63xx/patches-2.6.35/270-board-96338W2_E7T.patch: [brcm63xx] add bcm96338W2 e7t board (D-Link 2640U/BRU/C, #7558) Oct 17 18:07:52 build #8 of x86 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/8 Oct 17 18:17:43 mb * r23509 /packages/Xorg/xorg/xserver/xorg-kdrive/Makefile: xorg-kdrive: Disable xsdl autoconf check Oct 17 18:18:30 obsy * r23510 /packages/net/transmission/Makefile: [packages] transmission: update to 2.11, remove dependency -daemon from -remote Oct 17 18:18:47 mb * r23511 /packages/Xorg/xorg/xserver/xorg-kdrive/Makefile: xorg-kdrive: Enable parallel build Oct 17 18:23:10 mb * r23512 /packages/Xorg/xorg/xserver/xorg-server/Makefile: xorg-server: Enable parallel build Oct 17 18:49:09 could this error: ../include/click/timestamp.hh:444: error: 'timespec' does not name a type Oct 17 18:49:11 be related with the gcc version? On arm openwrt uses gcc4.3.3cs while on x86 openwrt uses 4.1.3. With the former i get the error while with the latter I do not. Oct 17 19:21:16 nbd: ping? Oct 17 19:28:45 Well, we can always throw: LINUX_VERSION:=2.6.xxx into target/linux/x86/ep*/target.mk, right? Oct 17 19:28:52 oops. Oct 17 20:15:24 philipp64|laptop: 320, 330, 340 Oct 17 20:16:39 they're all very trivial, should be easy to forward port them Oct 17 20:18:38 not sure about the debian patches, they look useful Oct 17 20:18:59 but I'm not that deep into pppd so ymmv Oct 17 20:19:18 the three mentioned above are needed to retain openwrt compatibility Oct 17 20:19:33 the debian patches have a *lot* of whitespace changes, which I'm ideologically opposed to. Oct 17 20:19:42 what about 110? Oct 17 20:20:28 yes that too Oct 17 20:20:42 thats waht I meant with "default route stuff" Oct 17 20:20:52 vanilla pppd does weird things Oct 17 20:21:33 ah.... and 200... some of that is suspect. Why not just pass HAVE_INET6 in via the package Makefile? Oct 17 20:22:29 would be great if upstream could change those assignments to := Oct 17 20:22:53 I work a bit with the ppp folks (I wrote the ppp-2.2.2 port to NextStep 3.2 back in '93)... which of these would you like to submit upstream? Oct 17 20:23:11 320 Oct 17 20:23:34 tracking pppX devices is a pita Oct 17 20:25:12 206 as well Oct 17 20:26:11 340 too, maybe in a configurable manner if there is a specific reasoning to not populate the default gw Oct 17 20:26:29 so far it only caused trouble but maybe I missed something Oct 17 20:26:44 and 330 Oct 17 20:26:58 pppd used to delete default routes not belonging to itself Oct 17 20:30:08 explaination on 330 is here: https://dev.openwrt.org/ticket/7694 Oct 17 20:34:57 how important is 310? Oct 17 20:35:16 checking... Oct 17 20:36:08 hm can't judge that Oct 17 20:37:03 I think its useful to avoid a dep on libpcap? Oct 17 20:37:29 not a clue. Oct 17 20:37:40 me neither :) Oct 17 20:37:56 as far as I know the filter stuff only plays a role with dial on demand mode Oct 17 20:38:11 looking at 320, I'm a little unclear. if you specify "unit 5", that will force the ifname to ppp5, right? Oct 17 20:38:14 which isn working that great on openwrt anyway (due to surrounding script-fu) Oct 17 20:38:25 you don't need 320 to do this. Oct 17 20:38:38 320 allows entirely arbritary ifnames Oct 17 20:38:42 not just pppX Oct 17 20:38:56 and why is that important? Oct 17 20:38:57 right now openwrt uses pppoe-wan, ppp-foo, 3g-bar Oct 17 20:38:59 names like that Oct 17 20:39:20 because it makes it way easier to integrate into the firewall Oct 17 20:39:31 I can see wanting to force determinancy as a way to simply scripting... but I don't see the importance of arbitrary names. Oct 17 20:39:46 well we need it Oct 17 20:39:48 period. Oct 17 20:39:53 :) Oct 17 20:39:55 frankly I'd just do that with "ip link pppX set name ppp-foo" Oct 17 20:40:15 no ip by default Oct 17 20:40:17 and racy Oct 17 20:40:54 iproute2 isn't part of the default build? oh, my. ok, what about ifrename? Oct 17 20:41:01 neither Oct 17 20:41:29 if upstream does not want it, fine. But I'd like to keep it Oct 17 20:42:27 and adding ifrename as a default dependency of ppp? Oct 17 20:42:34 the unit stuff is not sufficient in setups with multiple pppd instances Oct 17 20:42:40 and ifrename is an ugly hack Oct 17 20:46:33 at least it will certainly involve more overhead that having it in pppd Oct 17 20:47:08 plus you need to wait/poll for an pppX to appear and find out the correct pppX etc. Oct 17 20:47:28 it might also confuse hotplug (iface appears, triggers events then gets renamed) Oct 17 20:47:36 well, it might be an ugly hack... but it doesn't involve applying lengthy patches. I like to use code that's as close to what's upstream as possible. Oct 17 20:47:43 but that's just me. Oct 17 20:47:48 I'm lazy. :-) Oct 17 20:48:37 yeah I too, therfore I prefer to make the software work in a reasonable way instead of implementing convoluted rarely working shell scripts with suboptimal success rate Oct 17 20:49:30 however I'm fine with maintaining those patches as I said Oct 17 20:49:35 no need to have them upstream Oct 17 20:49:55 the default route stuff still needs to get fixed Oct 17 20:50:17 unless they made big changes to this in .6 already Oct 17 21:05:33 109 is a big fail. 28 of 28 hunks failed. Oct 17 21:05:41 not sure I see the value in completely redoing the error reporting, either. Oct 17 21:07:29 to have messages on both stderr and in syslog Oct 17 21:07:38 sounds valuable to me Oct 17 21:07:44 esp. if there is no syslog Oct 17 21:09:08 not that I think we need it but it looks reasonable to me for what it does Oct 17 21:12:37 these lengthy, extensive patches are hard to maintain version to version. it would be easier just to write a wrapper and #define syslog() to it. Oct 17 21:13:32 so the pppoe plugin you use is the one in ppp-2.4.4, then, not the rp-pppoe-3.10 standalone? Oct 17 21:13:45 ys Oct 17 21:19:24 how do I know which is the phy_interrupt of the external network phy? Oct 17 21:20:59 you said 310 could go? Oct 17 21:22:07 well Oct 17 21:22:31 only if pppd works without libpcap afterwards Oct 17 21:23:44 I thought you said it was needed for the dial-on-demand stuff which doesn't work anyway? Oct 17 21:25:05 that doesn't change the fact that pppd implements those active filter stuff which needs pcap Oct 17 21:25:21 even if the functionality is not used, pppd needs to link against it Oct 17 21:25:31 *afaik* Oct 17 21:25:37 if not, just ignore it Oct 17 21:50:51 xMff: can you jump on builder a second? Oct 17 21:52:28 hm? Oct 17 21:53:07 there's the patch that's gone upstream for ppp-2.4.6 to make the Makefile's more cross-compile friendly.. Oct 17 21:53:22 but I'm having a problem shimming into it. need your advice. Oct 17 21:54:43 I can look during work tomorrow, was about to hit the bed Oct 17 21:55:45 ok. in short, I need to pass CFLAGS into "make" with additional values when building ppp, but can't figure out how to do that without clobbering the default values. Oct 17 21:56:01 TARGET_CFLAGS += foo ? Oct 17 21:56:06 it's probably something trivial... Oct 17 21:56:17 well, I need to do it just for the one package. Oct 17 21:56:22 ? Oct 17 21:56:37 don't want to affect TARGET_CFLAGS globally. Oct 17 21:56:44 do it in package/ppp/Makefile of course Oct 17 21:57:04 ah, that happens as a subshell. ok. buildroot does a single global make. Oct 17 21:57:29 (except for the private makes for each project's directory, of course) Oct 17 21:59:52 it will work as expected and does not propagate into subsequent packages Oct 17 22:00:06 same for CONFIGURE_ARGS, CONFIGURE_VARS, MAKE_FLAGS etc. Oct 17 22:00:16 just check out some other package makefiles Oct 17 22:08:35 You may also use EXTRA_CFLAGS:=foo Oct 17 22:15:21 is this channel kept archived somewhere? Oct 17 22:17:11 the nslu2-log but makes logs Oct 17 22:17:20 *nslu2-log bot Oct 17 22:21:02 but looks like they're not published Oct 17 22:21:28 actually you may help me anyway Oct 17 22:21:57 a few days ago you suggested some changes to my sshtunnel package Oct 17 22:22:08 I guess including a pastebin example Oct 17 22:22:18 I cant find it Oct 17 22:22:36 do you remember what flavour of pastebin you used so I can search my web history? Oct 17 22:22:51 no but I can grep my irc logs Oct 17 22:24:08 it expired... Oct 17 22:24:20 I remember the idea, don't mind Oct 17 22:24:33 thanks Oct 17 22:24:46 ok, np. take a look at the openvpn init Oct 17 22:24:52 it basically does what I suggested Oct 17 22:25:03 xMff: I think we should split the ToH's "possible, but not being worked on" section in two; one for devices with an already supported SoC, but not the device itself (so probably only minor porting needed), and one for devices which have the requirements (enough ram/flash, linux gpl tarball available) but need serious porting (for those seeking a challenge ;) Oct 17 22:25:30 KanjiMonster: would love to but tbh I'd rather get rid of it completely Oct 17 22:25:54 because I think nobody is going to keep it updated Oct 17 22:27:14 for example the dir-615, wrt160n and wrt610n entries Oct 17 22:29:34 xMff: recruit more gardeners ;) Oct 17 22:30:20 they need to follow development... Oct 17 22:56:51 xMff: if no one is working on them, then it doesn't need updating, does it? Oct 17 22:58:37 <_trine> if you recruited more gardeners you would have to buy more bull shit :) Oct 17 22:59:05 <_trine> sorry couldnt resist Oct 17 22:59:37 no one on irc needs to *buy* bull shit Oct 17 22:59:45 <_trine> :) Oct 17 23:11:27 speaking of ToH, wtf does the VLAN Config heading mean exactly? Shouldn't that be a link to wtf that link intends to mean? Oct 17 23:12:21 e.g. the WGT634U can configure its VLAN config, but is marked No, so ... does that mean something different that one would naively think? Oct 17 23:14:57 * russell-- just changes it to Yes and waits for someone to correct me... which is what wikis are all about! Oct 17 23:23:11 it's the "unplug the unknown device, and the phone will ring" model of identifying interested parties Oct 17 23:55:51 lol. /me just saw the VLAN description in the "Legend" the top. is there an easy way to test that? Oct 18 00:07:40 the tagging capability, that is Oct 18 00:21:51 when linking .o's to make a lib%.so, do you need to specify the list of libraries that the .so links against? I'm guessing you do. Oct 18 00:36:36 any makefile gurus still around? I'm trying to improve ppp's makefiles, but want to use pattern rules. Oct 18 00:55:33 buggery and shit. Oct 18 02:50:56 I'm stumped. **** ENDING LOGGING AT Mon Oct 18 02:59:57 2010