**** BEGIN LOGGING AT Fri Sep 17 02:59:57 2010 Sep 17 04:20:33 build #75 of x86 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/75 Sep 17 07:53:48 hello Sep 17 09:54:01 build #115 of brcm63xx is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/115 Sep 17 10:12:07 heh, I just wondered why luci said 'kamikaze (unknown)', then I noticed it does that probably because I'm using git Sep 17 12:24:21 xMff: yeah, I agree (block-* stuff) Sep 17 12:38:38 RealOpty: pong Sep 17 12:52:07 cshore: did you look into the overlay-aware preinit yet? Sep 17 12:53:08 xMff: no, I probably will be looking at that next week, or maybe take some time off and try to do some this weekend Sep 17 12:53:24 I will try something today Sep 17 12:55:12 xMff: block-mount and block-hotplug are separte due to mailing list discussion on not bloating Sep 17 12:55:41 xMff: block-extroot is fore more than just USB Sep 17 12:56:00 xMff: it works with IDE and SDHC as well Sep 17 12:56:53 cshore: ah right, well maybe it should be just added to the package profiles Sep 17 12:57:10 but then there will be people complaining that the images are bloated with storage support Sep 17 12:58:03 for block-mount and block-hotplug, the descriptions should be more clear. I didn't understood whether I need block-hotplug to mount usb through fstab Sep 17 12:58:24 block-hotplug is for automounting when a device is plugged in Sep 17 12:58:35 block-mount is for doing the actual mounts Sep 17 12:58:46 regardless of hotplug or not Sep 17 12:59:02 so block-mount can handle usb if it is plugged in during boot? Sep 17 12:59:12 it does not suffer from the usual races? Sep 17 13:00:06 block-mount / block-hotplug were written in part to eliminate the race conditions (for mounting....there are the usual problems with init.d scripts depending on things already being mounted) Sep 17 13:00:57 I see, so for usb mounting through fstab you need hotplug in any case Sep 17 13:01:03 block-mount handles mounting (e.g. if the device is already plugged in), block-hotplug takes cares of the mounts if is hotplugged Sep 17 13:01:30 block-mount alone is still racy Sep 17 13:02:00 without block-hotplug, plugging in a device doesn't mount the device Sep 17 13:02:07 no race Sep 17 13:02:11 it does not mount on boot either Sep 17 13:02:32 because usb settles after init, the problem we basically always had Sep 17 13:02:51 xMff: block-mount is fore modules loaded before init Sep 17 13:03:01 xMff: and is also used by block-hotplug Sep 17 13:03:17 xMff: e.g. for block-extroot you don't need block-hotplug Sep 17 13:03:24 I understood that but usb needs settle time, ensuring a loaded module does not guarantee the usb is ready for mounting Sep 17 13:04:12 xMff: block-extroot: has a settle-time parameter where it waits for specified amount of time for settling Sep 17 13:04:59 xMff: because hotplug is not available in preinit Sep 17 13:05:15 xMff: at least not the way we would need it to e Sep 17 13:05:19 *be Sep 17 13:08:57 it's the best we can do until we have an event/dependency init Sep 17 13:09:02 ok, and whats the default? Sep 17 13:09:08 20s Sep 17 13:09:45 xMff: you can change it in menuconfig Sep 17 13:15:57 xMff: if we modify preinit to that it reads from jffs2 before pivot_root, we can have extroot as a module, not built into the image Sep 17 13:16:07 yes Sep 17 13:16:23 xMff: so the images won't need to be bloated with storage Sep 17 13:17:47 xMff: because I'd modify extroot to load modules from jffs2 instead of the image Sep 17 13:17:56 or either rather Sep 17 13:19:18 yeah Sep 17 13:19:39 I currently try to figure out a non-invasive way to splice new functions into the hook while it runs Sep 17 13:19:58 you mean preinit_main? Sep 17 13:20:04 a new "after overlay" hook is unsuitable Sep 17 13:20:05 yes Sep 17 13:21:05 it's annoying that (b)ash supports variable references only through eval Sep 17 13:21:09 xMff: do you want the new functions to go in arbitrary places in the hook? Sep 17 13:21:41 cshore: yep. I think I'll rework run_hook that it shortens the hook list by one item on each procedure invocation Sep 17 13:22:02 cshore: to splice new stuff in, something would then only need to put new stuff at the beginning of the list Sep 17 13:22:24 through a hypothetcial boot_hook_splice func Sep 17 13:22:30 or unshift Sep 17 13:22:33 dunno Sep 17 13:24:34 this can be done easily by transforming the for loop in boot_run_hook() into a while [ -n "..." ] loop Sep 17 13:24:36 xMff: another thing to consider is that when you source the /lib/preinit it will be appending to the hook Sep 17 13:25:06 I don't want to source that (again) Sep 17 13:25:06 xMff: so when you do the reread you need to throw out the already executed stuff Sep 17 13:25:35 xMff: how will you get the files in /overlay/lib/preinit added then? Sep 17 13:26:27 jffs2_not_mounted || { for $pipart in /tmp/overlay/lib/preinit/*; do . $pipart; done } Sep 17 13:27:02 oh right...I was thinking the overlay would include the stuff of on the squashfs, but of course it won't Sep 17 13:27:45 of course if someone upgrades base-files he'd have duplicates on jffs Sep 17 13:27:51 right Sep 17 13:28:45 maybe keep track of what's been executed duing run_hook so that we can discard duplicates Sep 17 13:30:22 yes Sep 17 13:30:25 I think ordering could be a problem for the overlay added hook stuff Sep 17 13:30:36 not really Sep 17 13:30:50 one must be aware that it will always happen after 40_something Sep 17 13:31:33 maybe we could source only files with a special name Sep 17 13:31:49 like 40_*_* Sep 17 13:32:33 I think that's a good idea...that makes it explicit Sep 17 13:46:17 sorry my computer randomly rebooted...did you say anything Sep 17 13:46:35 nope Sep 17 13:46:51 still figuring out how to do things in shell which are not meant to be done in shell Sep 17 13:46:58 heheh Sep 17 14:07:45 cshore: http://openwrt.pastebin.com/kSB9GFEr Sep 17 14:07:59 cshore: thats what I intend to put into preinit Sep 17 14:11:41 will "v#* " match the empty string, or a string with one space? Sep 17 14:11:51 sorry Sep 17 14:12:08 it will match the portion up to the first space Sep 17 14:12:14 ok Sep 17 14:12:28 what will it do if there is no space? Sep 17 14:12:37 return the original Sep 17 14:14:39 so the hook array is basically treated like a stack Sep 17 14:14:48 right Sep 17 14:15:01 just trying to see if I see anything wrong Sep 17 14:15:58 the splice_hook procedure has the issue that items are added in reverse order Sep 17 14:16:48 but I get solved Sep 17 14:16:52 +that Sep 17 14:17:19 how? Sep 17 14:18:19 for example by remembering the current position Sep 17 14:18:58 or by spolling those splices into an intermediate list which is silently merged on the next shift operation Sep 17 14:20:36 xMff: is it possible to reverse the order of the list of files? that really all that's needed Sep 17 14:20:47 no Sep 17 14:20:50 not easily Sep 17 14:22:19 hmmm...well I don't see anything beyond the reverse order that would be a problem Sep 17 14:23:38 http://openwrt.pastebin.com/Euzn17C0 Sep 17 14:26:23 I notice the TEST_HOOK sometimes has extra spaces Sep 17 14:26:33 that will be no issue Sep 17 14:27:22 ok Sep 17 14:27:28 it look ok to me Sep 17 14:27:45 *looks Sep 17 14:35:52 I noticed a logic issue though Sep 17 14:36:19 ideally you won't force such overlay parts to use another add_hook function Sep 17 14:36:40 s/won't/don't want to/ Sep 17 14:37:27 ? Sep 17 14:37:35 another add_hook? Sep 17 14:38:15 you want preinit parts to function be the same regardless of whether they're sourced from rom or from /tmp/overlay, right? Sep 17 14:38:26 right Sep 17 14:38:37 so they will use boot_hook_add() Sep 17 14:38:43 right Sep 17 14:38:49 which would append parts to the end of the stack Sep 17 14:39:07 while in the particular case of /tmp/overlay we want it to be at the beginning Sep 17 14:39:23 right, I thought about that, then forgot Sep 17 14:40:12 now after implementing boot_hook_add() and boot_hook_splice() I noticed that they're identical except that they use a different var to append to Sep 17 14:40:36 could you add a state variable for book_hook_add; if set do splice, otherwise do add? Sep 17 14:40:46 so I guess I will just introduce a global PI_STACK_SUFFIX or something which is temporarely set when sourcing /tmp/overlay parts Sep 17 14:41:18 right Sep 17 14:41:27 I think that's what we have to do Sep 17 14:41:49 great Sep 17 14:57:02 http://paste.tksite.gotdns.org/d7c609599 Sep 17 14:57:12 untested yet Sep 17 15:00:15 I could enforce a [0-9][0-9]_* format and ignore all files starting with a number < 42 Sep 17 15:00:50 in order to avaoid duplicates in subsequent hooks we need a duplicate detection I suppose Sep 17 15:11:09 you could require format 42_xx_name-of-file Sep 17 15:13:53 That way all overlay hooks appear in /lib/preinit in the same place regardless of whether they're on jffs2 or squashfs Sep 17 15:15:29 moment Sep 17 15:15:41 http://paste.tksite.gotdns.org/d26e35b43 Sep 17 15:15:56 I think 50 is a sane offset Sep 17 15:16:26 I also added a dupe check to boot_hook_add Sep 17 15:17:45 I think using 42_xx_blah makes more sense, because on squashfs 60_xxx will happen after 50, but on overlay it will happen before 50_ files on the squash Sep 17 15:18:23 so the answer is, again, 42 Sep 17 15:19:02 heh, yes Sep 17 15:19:26 okay Sep 17 15:21:38 k, flashing... Sep 17 15:21:40 wich me luck Sep 17 15:22:09 luck Sep 17 15:23:41 are you at home? Do you do openwrt stuff at work too? Or do I just see you doing openwrt stuff because you're home when I'm around? Sep 17 15:24:30 I do it at home Sep 17 15:24:39 at work I'm in the chat but I do no programming there Sep 17 15:26:23 ah, I see Sep 17 16:56:29 yay it appears to work Sep 17 16:56:50 had some stupid syntax error Sep 17 18:15:42 I hate when that happens Sep 17 18:17:07 xMff: easiest way to test that before flashing is to source it in the shell on your desktop....it will catch most problems before flashing (just fire up a subshell with dash or bash and then for file in /lib/preinit/* ; do . $file; done) Sep 17 18:17:37 Just doing that can save some agony Sep 17 18:17:38 it seems to work nicely now Sep 17 18:17:46 good Sep 17 18:17:53 I can create arbritary stuff in /lib/preinit/ and it gets executed Sep 17 18:18:15 made myself a debug shell that gets enabled when "giveshell" is in the kernel args :P Sep 17 18:18:28 cool...that's a good idea Sep 17 18:19:10 so the splicing is basically okay but not 100% perfect Sep 17 18:19:36 it behaviour is basically undefined if parts of preinit are duplicated into the overlay Sep 17 18:20:29 right now I play with the idea to reset all stacks, then re-read all /rom/lib/preinit and /overlay/lib/preinit parts again Sep 17 18:20:41 in the correct order Sep 17 18:20:45 hmmm....would it be possible to have run_hook keep track of executed functions, or and/or to track files that are souced in the for loop? Sep 17 18:21:09 that wouldn't solve the problem Sep 17 18:21:50 well the overlay read would have to not read duplicates Sep 17 18:22:02 but that's ugly and a lot of work Sep 17 18:22:10 right Sep 17 18:24:35 or I could instruct the main preinit to only evaluate files up to 41 Sep 17 18:24:41 and then do the rest Sep 17 18:25:00 but then I'd probably miss functions defined later but executed earlier Sep 17 18:27:37 not sure whether I follow the wrong approach here... Sep 17 18:27:44 yes, that would be a problem. Sep 17 18:27:56 I think re-evaluating the stack would be the best Sep 17 18:28:17 my issue right now is that I find no non-expensive way to interleave the both directories Sep 17 18:28:34 without resorting to sort -u etc. Sep 17 18:28:52 I think track what's been done, re-evaluate the stack, and then throw out the already executed functions on the stack Sep 17 18:29:54 the problem is, when I first source verything from /tmp/overlay and then everything from /rom/overlay I might get wrong order Sep 17 18:29:55 or maybe rethink the whole stack thing Sep 17 18:30:17 because its all just adds and not inserts at a specifc position Sep 17 18:30:22 right Sep 17 18:30:50 hmmmm..... Sep 17 18:31:03 I wish shell had arrays Sep 17 18:31:14 meh, I'll just symlink all /rom parts into /tmp/overlay/lib/preinit (unless they exist already) and then do a glob over that Sep 17 18:31:56 xMff: or rather use a directory under /tmp and symlink both dirs into it Sep 17 18:32:03 yeah, right Sep 17 18:32:12 poking jffs would be no good idea Sep 17 18:33:15 plus the already-done tracking thing Sep 17 18:33:38 right..though that could be expensive Sep 17 18:33:58 I'm trying to think of a better way Sep 17 18:34:04 well I could evalute files > 41 Sep 17 18:34:20 earlier stuff isn't executed anyway Sep 17 18:35:14 if there are functions defined in <41 files in /tmp/overlay, some functions could be missing that way Sep 17 18:35:26 ah, right Sep 17 18:35:48 need to benchmark some approaches to track packages Sep 17 18:35:59 I have two candidates Sep 17 18:36:03 what's needed is a way to associate a function name with a number Sep 17 18:36:24 hmm Sep 17 18:36:43 no this breaks down quickly if overlay inserts stuff early Sep 17 18:37:01 must be a name based lookup Sep 17 18:37:04 but then it won't be executed anyway, right Sep 17 18:38:18 we don't want to execute thing added to the hooks before 41 even if they're added by overlay, because then it would be out of order Sep 17 18:38:44 overlay can't execute functions before the overlay is loaded Sep 17 18:38:46 except if it redefines some helper defined early Sep 17 18:38:54 then it would be correct Sep 17 18:39:05 right Sep 17 18:39:31 I don't think that much about users messing in there but rather simple cases like opkg upgrade Sep 17 18:39:34 actually, maybe just disallow overlay < 41 Sep 17 18:39:36 where various files are changed Sep 17 18:41:04 the main issue is making sure that the functions defined in squash are defined in the right order when the overlay is added, for files >41 Sep 17 18:42:00 actually, yeah, we don't need to resource < 41, you're right Sep 17 18:42:19 because those functions are already defined in environment Sep 17 18:43:03 the preinit_essential_hook doesn't matter because it's already past at that point Sep 17 18:43:23 and we don't care about book_hook_add before 41 Sep 17 18:43:42 so if you reset the stack and source >41 you should be fine Sep 17 18:45:36 if a module needs to execute before the overlay is sourced (file < 41) it's useless on the overlay anyway, so it doesn't matter Sep 17 18:46:57 although documentation that modules need to always be >41 somewhere reasonably likely to be seen by preinit users is probably a good idea Sep 17 18:47:39 btw do you happen to know if anyway has taken advantage of preinit yet? Sep 17 18:47:49 nope Sep 17 18:47:53 don't know Sep 17 18:49:02 did the sdhc stuff for mounting sdhc via extroot ever get posted/added? Sep 17 18:49:38 probably not Sep 17 18:50:13 I know someone was working on it, but I hadn't heard anything Sep 17 18:52:04 if preinit's not widely used, maybe it's not the right approach...I have had great plans for it, but I've been too busy to execute on them, and am wondering if it's more complexity than we really need, upon thinking about it Sep 17 18:52:51 well Sep 17 18:53:12 if you consolidate it a bit its not that much complex anymore Sep 17 18:55:13 how do you mean? Just combine some of the smaller files? Sep 17 18:55:19 yes Sep 17 18:57:17 and less state keeping Sep 17 18:58:01 k, eval based lookup is faster Sep 17 19:06:58 cshore: new approach: http://paste.tksite.gotdns.org/d2e437d07 Sep 17 19:13:03 for hook; boot_run_hook; done will be wrong...it would execute, for instance, failsafe, which is a conditional execution....also initramfs (if defined) Sep 17 19:13:47 then I'll do only preinit_* Sep 17 19:14:34 actually you only need to do preinit_main ... that's the only one that executes unless launched from preinit_main (after overlay....preinit_essentials is already finished by this point) Sep 17 19:14:51 nack, then it wouldn't work for extroot Sep 17 19:15:10 why not? Sep 17 19:15:20 because it hooks into mount_root Sep 17 19:15:38 mount root is called from one of the functions called by preinit_main Sep 17 19:16:11 k, so I'll only mess with main Sep 17 19:16:13 oh, I thought of a problem with only >41 Sep 17 19:16:28 >41 only applies only to preinit_main Sep 17 19:17:15 the other hooks start at lower number for their first function, but they don't necessarily get executed until after preinit_main 41 Sep 17 19:18:03 e.g. mount root Sep 17 19:19:23 k, so far the patch I posted works Sep 17 19:19:41 I can edit, for example, 99_10_init sprinkle some echos there and see them Sep 17 19:20:07 excellent Sep 17 19:20:38 whole new possibilities for users to brick their images :P Sep 17 19:21:19 >41 isn't a problem really....there might be strange ordering if someone has <41 on overlay (because it will have after 41), but that's more of a documentation issue Sep 17 19:21:24 ok ... recap Sep 17 19:21:33 I should only exec preinit_main ? Sep 17 19:21:37 right Sep 17 19:21:52 checking for >41 is actually more expensive than just re-sourcing everything Sep 17 19:22:02 from merge_overlay_hook Sep 17 19:22:03 right Sep 17 19:22:23 I was confused because we had discussed it before Sep 17 19:22:37 yeah, I know I jump from idea to idea Sep 17 19:23:18 basically we just have to tell people "don't name scripts on overlay < 41, especially if they will also be on squashfs because the results will different when in image vs overlay" Sep 17 19:23:43 http://paste.tksite.gotdns.org/d769a5091 Sep 17 19:24:17 as a side effect we have no subshell invocation anymore Sep 17 19:24:24 saves some ram Sep 17 19:25:27 it looks good to me Sep 17 19:26:11 great, trying it on my router now Sep 17 19:26:54 if all goes well, extroot should be opkg-installable Sep 17 19:27:37 well extroot will need to be modified to do insmod from /tmp/overlay/lib/modules instead of /lib/modules Sep 17 19:27:54 otherwise the modules need to be in the image Sep 17 19:28:20 ah right Sep 17 19:28:21 or rather it needs to symlink the modules dirs together, like with the preinit merge Sep 17 19:29:27 but we're making progress to opkg-installable extroot Sep 17 19:29:34 that will make a lot of people happy Sep 17 19:31:30 flashing... Sep 17 19:38:34 well, as soon as my current backup completes (which could be a couple hours yet) I'm going to be shutting down and rearranging my desk so that I can take advantage of my new 27.5" LCD monitor (so I'll have a 27.5" and 24" dual screen). Awesome! Sep 17 19:48:41 hmm something is fish Sep 17 19:48:42 y Sep 17 19:48:50 what's up? Sep 17 19:48:59 as soon as the merge kicks in the box does not boot anymore Sep 17 19:49:02 <_trine> cshore, its great having 2 monitors I couldn't manage on just one now Sep 17 19:49:20 I'm now in failsafe, mount_root hangs at a lock operation Sep 17 19:50:27 maybe some function is supposed to be executed twice instead of only once? Sep 17 19:50:50 or alternatively some function is being executed twice instead of only once Sep 17 19:51:05 that should not happen though Sep 17 19:51:13 ah wait Sep 17 19:51:20 maybe I created a recursion Sep 17 19:51:47 can you post the diff again? Sep 17 19:51:56 functions are marked as executed after they ran Sep 17 19:52:08 I should do that before probably Sep 17 19:52:59 because otherwise the merge function executes again? Sep 17 19:53:25 yes Sep 17 19:53:34 didn't notice this on x86 though Sep 17 19:54:30 crap Sep 17 19:54:32 reflash Sep 17 19:55:44 diff is here http://paste.tksite.gotdns.org/d769a5091 Sep 17 19:55:46 xMff: do you use the serial console on the x86 vm or just the framebuffer? Sep 17 19:55:57 serial Sep 17 19:56:45 unfortuntely no serial on my test device yet Sep 17 19:56:48 <_trine> this is my dockstar http://watchingyou.info Sep 17 19:57:01 I should unpack the 1043nd Sep 17 19:57:49 _trine: heh I took the wndr to the lab yesterday and not even there we had the right screwdriver tips for those torx screws Sep 17 19:58:17 <_trine> you need a torx T9 Sep 17 19:58:42 <_trine> I bought a pack of different sizes Sep 17 19:58:45 yeah, there was anything except this particular size Sep 17 19:58:55 <_trine> they are reasonably cheap Sep 17 19:58:55 xMff: what do you use to attach to the serial on the x86 vm? I assume it's on a pty? (you use VB or Qemu or VMWare?) Sep 17 19:59:15 cshore: socat + screen / virtualbox Sep 17 19:59:31 I bought torx for the Compaq Deskpros I was given Sep 17 19:59:42 I was playing with clustering Sep 17 20:00:00 cshore: http://paste.tksite.gotdns.org/d743d1de1 Sep 17 20:00:33 <_trine> I want to buy a CUDA graphics card to crunch wpa Sep 17 20:04:55 and just screen on the pty? Sep 17 20:05:25 nvm, I see it Sep 17 20:05:51 it also bypasses the gui somewhat Sep 17 20:06:08 those harddisk uuid stupidity of vbox drives me crazy Sep 17 20:06:40 therfore the reattach of the hd Sep 17 20:06:58 yes I see that....I do the same kind of thing with qemu but I haven't automated it because I've been testing on real hardware because I need real networks for my testing Sep 17 20:07:17 with sip phones and wan access Sep 17 20:07:30 software vlans help Sep 17 20:08:56 xMff: the virtual stuff will come in handy later, but for what I'm doing right now it's much easier to use a real device Sep 17 20:43:27 bbl Sep 17 20:58:48 build #87 of rb532 is complete: Failure [failed shell_3] Build details are at http://tksite.gotdns.org:8010/builders/rb532/builds/87 Sep 17 20:58:51 build #101 of mpc52xx is complete: Failure [failed svn compile_12] Build details are at http://tksite.gotdns.org:8010/builders/mpc52xx/builds/101 Sep 17 20:58:54 build #36 of at91 is complete: Failure [failed svn shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/36 Sep 17 20:58:57 build #83 of ramips is complete: Failure [failed svn shell_10 compile_12] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/83 Sep 17 21:07:28 back...ahhh....screen real estate! Sep 17 22:01:32 no updates to svn today :\ Sep 17 22:01:43 xMff, http://wiki.openwrt.org/toh/start?do=revisions Sep 17 22:01:53 I think that needs to be reverted lol. Sep 17 22:04:14 that does indeed make no sense Sep 17 22:14:47 reverted back :) Sep 17 22:38:03 RealOpty: we need some contact page Sep 17 22:38:36 you read my mind, was thinking about that the other day Sep 17 22:38:48 about/contact <-locate it there? Sep 17 22:38:58 yes Sep 17 22:42:05 xMff, http://wiki.openwrt.org/about/contact Sep 17 22:46:55 ty Sep 17 22:50:11 np Sep 17 22:51:22 xMff, should https://dev.openwrt.org/wiki/people be on that page too? Sep 17 22:51:47 RealOpty: yeah, good idea Sep 17 22:55:19 xMff, ive been cleaning out the oldwiki, removing pages like http://wiki.openwrt.org/oldwiki/robdyke Sep 17 22:55:41 xMff, thats ok to remove yeah? Sep 17 22:56:13 sure Sep 17 22:56:41 thought so, theres a lot of those pages lol. Sep 17 23:00:13 xMff, this is useless now yeah? i think the tool can jtag AR7 http://wiki.openwrt.org/oldwiki/zt8qmwz Sep 17 23:00:36 keep it around for now Sep 17 23:00:41 the whole jtag stuff etc. Sep 17 23:00:52 someone with more electronics background needs to review it Sep 17 23:01:29 kk Sep 17 23:03:06 xMff, how about these category pages? http://wiki.openwrt.org/oldwiki/categoryx86device Sep 17 23:03:48 remove Sep 18 00:00:49 build #105 of octeon is complete: Failure [failed compile_7] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/105 Sep 18 00:00:49 RealOpty: http://wiki.openwrt.org/doc/howto/ddns_scripts and http://wiki.openwrt.org/doc/howto/ddns_luci overlap Sep 18 00:02:01 xMff, they should be merged? Sep 18 00:02:07 yes Sep 18 00:02:18 kk np Sep 18 00:02:29 * xMff is facinated how much howto one can write about ddns Sep 18 00:02:49 I clearly have the wrong pov Sep 18 00:03:22 lol Sep 18 00:15:45 xMff, http://wiki.openwrt.org/oldwiki/sambahowto Sep 18 00:15:48 useless? Sep 18 00:17:00 the localhost tip is good Sep 18 00:17:05 the rest is outdated Sep 18 00:20:41 build #81 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/81 Sep 18 00:23:10 xMff, http://wiki.openwrt.org/oldwiki/sqlrecovery ???????? Sep 18 00:23:35 lol Sep 18 00:24:40 spam Sep 18 00:25:01 though nice to have the database recovery procedure on mssql documented :P Sep 18 00:25:30 http://translate.google.de/translate?js=n&prev=_t&hl=de&ie=UTF-8&layout=2&eotf=1&sl=zh-CN&tl=en&u=http%3A%2F%2Fwiki.openwrt.org%2Foldwiki%2Fsqlrecovery Sep 18 00:30:16 xMff, http://wiki.openwrt.org/oldwiki/vncrepeaterhowto looks like a good howto ? Sep 18 00:31:02 yes Sep 18 00:31:45 but someone needs to check whether the old stuff still applies Sep 18 00:32:37 tag it for cleanup / review Sep 18 00:32:55 ^kk Sep 18 00:39:51 xMff, u editing the vnc page? Sep 18 00:39:56 no Sep 18 00:40:31 hm Sep 18 00:40:44 I don't think the xbox thing fits into howtos Sep 18 00:41:51 hmm true. maybe toh? Sep 18 00:42:00 im gonna test it out here soon :) Sep 18 00:42:05 was excited to find that info. Sep 18 00:42:07 yeah, toh Sep 18 00:42:27 xMff, http://wiki.openwrt.org/oldwiki/jonathankollasch/waystobrickyourbox Sep 18 00:42:31 lol!? Sep 18 00:43:04 keep! Sep 18 00:47:14 yeah i was wondering where to put it lol! Sep 18 00:49:15 ok two hours of wiki, i think im done for a bit. Sep 18 00:49:24 at least its cleaner now. :) Sep 18 01:19:10 xMff, cant update that vnc page Sep 18 01:19:10 Your changes were not saved because it contains one or more blocked words. If you tried to spam the Wiki � Bad dog! If you think this is an error, Sep 18 01:19:29 huh Sep 18 01:19:30 ok Sep 18 01:23:38 the badwords list just contains a bunch of http urls Sep 18 01:29:09 RealOpty: ah Sep 18 01:29:16 https?://([^/]*.)?rit.edu is in the spam block list Sep 18 01:29:23 don't ask me why Sep 18 01:29:45 but the "You may want to check if a new version is available" url is the culprit Sep 18 01:30:25 it is 404 anyway so just remove it Sep 18 01:56:59 kk Sep 18 02:27:15 cshore: I got it working **** ENDING LOGGING AT Sat Sep 18 02:59:57 2010