**** BEGIN LOGGING AT Thu Dec 13 02:59:58 2012
Dec 13 05:16:08 <builder__> build #90 of ep93xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/90
Dec 13 07:49:18 <builder__> build #84 of mcs814x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/84
Dec 13 09:34:09 <russell--> uh oh, what's this i hear about linux dropping support for 80386?
Dec 13 09:34:41 * russell-- predicts old router hardware will die as a result
Dec 13 09:35:16 <blogic> link ?
Dec 13 09:37:56 <russell--> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=743aa456c1834f76982af44e8b71d1a0b2a82e21
Dec 13 09:40:52 <russell--> post 3.7
Dec 13 09:41:43 <blogic> ok
Dec 13 09:41:46 <blogic> well
Dec 13 09:41:50 <blogic> what router hw will die ?
Dec 13 09:44:48 <russell--> not sure
Dec 13 09:45:49 * russell-- just gets nervious when i see the caboose coming ... i have some soekris net45xx's in service still
Dec 13 09:45:56 <russell--> which are 486, but still
Dec 13 10:08:38 <russell--> AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2, UMC 486SX-S and the NexGen Nx586.
Dec 13 10:17:29 <[florian]> we don't support any i386 hardware
Dec 13 10:17:37 <[florian]> the most ancient we have is i486-based
Dec 13 10:32:21 <builder__> build #120 of brcm47xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/120
Dec 13 10:40:35 <builder__> build #94 of ar71xx is complete: Failure [failed shell_17]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/94
Dec 13 10:47:21 * russell-- breathes sign of relief
Dec 13 10:47:33 <russell--> also a sigh
Dec 13 11:08:04 <builder__> build #95 of au1000 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/95
Dec 13 11:10:34 <builder__> build #112 of pxcab is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/112
Dec 13 11:49:42 <ATS63> #6807 isn't an issue on anything newer than 10.03 right? so does that mean the latest snapshot should work?
Dec 13 11:55:10 <ATS63> or 10.03.1 should work too?
Dec 13 13:07:53 <OpenWrt-Commits> nbd r34656 trunk/package/Makefile
Dec 13 13:07:53 <OpenWrt-Commits> build: only install packages for selected variants, fixes building multiple variant selections in one tree
Dec 13 13:07:58 <OpenWrt-Commits> nbd r34657 trunk/target/linux/ generic/patches-3.7/604-netfilter_cisco_794x_iphone.patch generic/patches-3.6/604-netfilter_cisco_794x_iphone.patch * kernel: fix porting mistakes on the 3.6+ SIP NAT patch causing crashes
Dec 13 13:47:30 <builder__> build #111 of rb532 is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/111
Dec 13 13:50:57 <builder__> build #111 of ppc44x is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/111
Dec 13 14:08:39 <OpenWrt-Commits> jogo r34658 packages/net/ znc/files/znc.conf znc/files/znc.init znc/Makefile * packages: znc: don't start with default config
Dec 13 14:08:42 <OpenWrt-Commits> jogo r34659 packages/net/ (6 files in 3 dirs) * packages: znc: update to 1.0
Dec 13 14:12:33 <OpenWrt-Commits> jogo r34660 branches/packages_12.09/net/ znc/Makefile znc/files/znc.init znc/files/znc.conf * AA: packages: znc: don't start with default config
Dec 13 14:55:48 <OpenWrt-Commits> obsy r34661 packages/net/transmission/Makefile * [packages] transmission: update to 2.74
Dec 13 15:41:12 <OpenWrt-Commits> florian r34662 trunk/target/linux/generic/patches-3.6/084-perf_mkstemp_build_fix.patch * kernel/3.6: backport an upstream build for perf with uClibc
Dec 13 15:41:30 <OpenWrt-Commits> florian r34663 packages/devel/perf/Makefile * perf: fix multiple issues in Makefile
Dec 13 16:15:26 <OpenWrt-Commits> nbd r34664 trunk/package/network/config/netifd/Makefile
Dec 13 16:15:26 <OpenWrt-Commits> netifd: update to latest version, fixes purging old resolv.conf entries after ifdown
Dec 13 16:17:17 <OpenWrt-Commits> nbd r34665 branches/attitude_adjustment/package/netifd/Makefile
Dec 13 16:17:17 <OpenWrt-Commits> netifd: update to latest version, fixes purging old resolv.conf entries after ifdown
Dec 13 16:29:34 <tripolar> hi
Dec 13 16:30:33 <tripolar> ping Hauke
Dec 13 16:30:41 <Hauke> tripolar: pong
Dec 13 16:30:57 <tripolar> Hauke: you switched brcm47xx to 3.6.10 but it seems there is still a problem with it
Dec 13 16:31:02 <tripolar> it get this error for iptables
Dec 13 16:31:04 <tripolar> iptables v1.4.10: unknown option `--log-level'
Dec 13 16:31:08 <Chocks> moo
Dec 13 16:31:31 <tripolar> i think the naming of some modules changed in 3.6
Dec 13 16:33:33 <tripolar> i think the logging option is now called CONFIG_NETFILTER_XT_TARGET_LOG
Dec 13 16:33:40 <tripolar> @Hauke
Dec 13 16:33:59 <tripolar> and this option is not set in the current config
Dec 13 16:34:46 <tripolar> CONFIG_NETFILTER_XT_TARGET_NFLOG is also available
Dec 13 16:34:50 <tripolar> and not set
Dec 13 16:36:23 <Hauke> tripolar: this should be handled, have you run make oldconfig after the kernel version changed?
Dec 13 16:36:45 <tripolar> i think so but i'll try again
Dec 13 16:37:04 <Hauke> instead of CONFIG_IP_NF_TARGET_LOG for kernel version >= 2.4 CONFIG_NETFILTER_XT_TARGET_LOG should be selected
Dec 13 16:37:21 <tripolar> i just saw it in netfilter.mk
Dec 13 16:37:37 <tripolar> but the option is unset here
Dec 13 16:40:29 <tripolar> Hauke: # CONFIG_NETFILTER_XT_TARGET_LOG is not set
Dec 13 16:41:33 <tripolar> i did a make target/linux{clean,compile}
Dec 13 16:45:35 <tripolar> Hauke any idea?
Dec 13 16:48:40 <Hauke> tripolar: yes it is a bug
Dec 13 16:48:52 <tripolar> but whats wrong?
Dec 13 16:50:01 <builder__> build #121 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/121
Dec 13 16:50:32 <Hauke> CompareKernelPatchVer does not work for kconfig options
Dec 13 16:53:39 <tripolar> Hauke ahh now i can remember again - i was talking about this in here some time ago because i wanted to use 3.6 before - i then just set the option manuallly in the generic config for a quick fix
Dec 13 16:54:14 <tripolar> Hauke just set both options? this shouldn't do any harm?
Dec 13 16:54:25 <Hauke> this hack should fix the problem: http://pastebin.com/nNzAKpQd
Dec 13 16:54:32 <Hauke> tripolar:
Dec 13 16:58:21 <tripolar> Hauke i just copied the line from after the if and put it after the else :)
Dec 13 16:58:30 <tripolar> but wiht your patch the $(P_XT)xt_LOG is missing
Dec 13 16:58:35 <tripolar> so it won't copy the module
Dec 13 16:58:51 <tripolar> -from
Dec 13 17:01:20 <Hauke> this part should work, when that is processed the if condition is working
Dec 13 17:02:23 <tripolar> but isn't $(P_XT)xt_LOG) needed instead of $(P_V4)ipt_LOG) for 3.6?
Dec 13 17:08:02 <tripolar> Hauke doesn't work
Dec 13 17:08:20 <Hauke> remove tmp at first
Dec 13 17:08:29 <tripolar> tmp?
Dec 13 17:08:33 <tripolar> the folder?
Dec 13 17:08:36 <Hauke> yes
Dec 13 17:09:49 <tripolar> Hauke: works - but i now use your version - isn't $(P_XT)xt_LOG) needed?
Dec 13 17:11:24 <Hauke> it is used, this code is evaluated more than one time in the build process and only when it is evaluated to get the Kconfig options the if condition does not work, in the later process it works
Dec 13 17:13:01 <tripolar> okay thanks
Dec 13 17:29:55 <tripolar> Hauke thanks for your help - the system works and comes up
Dec 13 17:30:00 <tripolar> have a nice evening
Dec 13 17:35:07 <OpenWrt-Commits> florian r34666 trunk/target/linux/ generic/patches-3.7/084-x86_fix_perf_uclibc_build.patch generic/patches-3.6/084-x86_fix_perf_uclibc_build.patch generic/patches-3.3/084-x86_fix_perf_uclibc_build.patch * kernel: fix perf build with uclibc toolchains on x86
Dec 13 18:40:16 <OpenWrt-Commits> juhosg r34667 trunk/target/linux/ generic/patches-3.7/132-solos-dma.patch generic/patches-3.3/132-solos-dma.patch generic/patches-3.6/132-solos-dma.patch * kernel: fix solos-pci skb double-free in DMA mode
Dec 13 18:47:10 <OpenWrt-Commits> juhosg r34668 branches/attitude_adjustment/target/linux/generic/patches-3.3/132-solos-dma.patch * AA: kernel: fix solos-pci skb double-free in DMA mode
Dec 13 18:51:55 <OpenWrt-Commits> hauke r34669 trunk/target/linux/brcm47xx/patches-3.6/235-bcma-dont-expose-mips-irq.patch * brcm47xx: return the real irq number in bcma_core_irq
Dec 13 18:54:49 <OpenWrt-Commits> hauke r34670 trunk/target/linux/brcm47xx/patches-3.6/241-bcma-broadcom-2011-sdk-updates.patch * brcm47xx: BCMA - Broadcom 2011 SDK Updates
Dec 13 18:56:34 <OpenWrt-Commits> hauke r34671 trunk/package/broadcom-wl/src/glue/wl_glue.c * broadcom-wl: Pass physical address to wl_attach
Dec 13 18:58:23 <OpenWrt-Commits> hauke r34672 trunk/target/linux/ brcm47xx/base-files/etc/init.d/netconfig brcm47xx/image/Makefile * brcm47xx: Additional BCM4716 support
Dec 13 19:56:36 <builder__> build #108 of ar7 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/108
Dec 13 19:58:29 <builder__> build #102 of sibyte is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/102
Dec 14 00:32:37 <builder__> build #118 of ramips is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/118
Dec 14 02:10:51 <builder__> build #105 of avr32 is complete: Failure [failed compile_9]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/105
Dec 14 02:12:52 <builder__> build #124 of s3c24xx is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/124
**** ENDING LOGGING AT Fri Dec 14 02:59:35 2012

**** BEGIN LOGGING AT Fri Dec 14 03:00:19 2012
Dec 14 03:11:01 <builder__> build #85 of mpc52xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/85
Dec 14 04:53:22 <builder__> build #88 of adm5120 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/88
Dec 14 05:29:34 <builder__> build #123 of brcm63xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/123
Dec 14 07:17:36 <OpenWrt-Commits> juhosg r34673 trunk/target/linux/ (6 files in 2 dirs) * ar71xx: merge unifi outdoor patch into the ubnt-xm one
Dec 14 07:17:42 <OpenWrt-Commits> juhosg r34674 trunk/target/linux/ (10 files in 2 dirs) * ar71xx: reorder some patches
Dec 14 08:33:42 <OpenWrt-Commits> juhosg r34675 trunk/target/linux/ generic/patches-3.6/811-pci_disable_usb_common_quirks.patch generic/patches-3.7/811-pci_disable_usb_common_quirks.patch * generic: update pci_disable_usb_common_quirks patch
Dec 14 08:48:24 <OpenWrt-Commits> juhosg r34676 trunk/target/linux/ (6 files in 3 dirs) * generic: refresh patches
Dec 14 11:20:40 <builder__> build #113 of pxcab is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/113
Dec 14 12:09:18 <tripolar> hi
Dec 14 12:10:23 <tripolar> it seems the country for my ath card is ignored
Dec 14 12:10:35 <tripolar> i have option country  AT
Dec 14 12:10:50 <tripolar> and this in dmesg
Dec 14 12:10:50 <tripolar> [   43.652000] cfg80211: Calling CRDA for country: CN
Dec 14 12:11:07 <tripolar> so why is this option ignored? i'm on 3.6.10
Dec 14 12:11:46 <tripolar> it was working in 3.3.8 with the AT
Dec 14 12:12:29 <OpenWrt-Commits> juhosg r34677 trunk/target/linux/ (7 files in 7 dirs) * generic: disintegrate UAPI from include/linux/switch.h
Dec 14 12:12:33 <OpenWrt-Commits> juhosg r34678 trunk/target/linux/ generic/patches-3.3/700-swconfig.patch generic/patches-3.6/700-swconfig.patch * generic: export include/linux/switch.h on 3.3, 3.6
Dec 14 12:12:36 <OpenWrt-Commits> juhosg r34679 trunk/package/network/config/swconfig/Makefile * package/swconfig: don't use kernel headers
Dec 14 12:13:47 <tripolar> when i bring up the wifi device it sets the right country code - but shouldn't this happen in the first place?
Dec 14 12:55:30 <dwmw2_gone> jow_laptop: where is the 'rrasingle' option set for a particular graph, to make it show min/max?
Dec 14 12:55:38 <dwmw2_gone> I don't see any examples
Dec 14 12:56:11 <jow_laptop> its a global option
Dec 14 12:56:23 <jow_laptop> in the collectd uci config
Dec 14 12:56:27 <jow_laptop> its also a nonstandard feature
Dec 14 12:57:17 <dwmw2_gone> hm. Would be nice to show max current draw and min/max voltage for the ups
Dec 14 12:57:25 <jow_laptop> then you have to disable it
Dec 14 12:57:34 <dwmw2_gone> and then it shows on *all* graphs?
Dec 14 12:57:44 <jow_laptop> you also have to re-create all graphs
Dec 14 12:57:46 <jow_laptop> yes
Dec 14 12:58:08 <dwmw2_gone> any objection if I make a per-graph option to enable/disable min/max/avg separately?
Dec 14 12:58:35 <jow_laptop> well the objective of rrasingle was to remove the *.rrd database size by two thirds
Dec 14 12:58:41 <jow_laptop> *reduce
Dec 14 12:59:05 <dwmw2_gone> oh, recreate all *data* not just graphs
Dec 14 12:59:08 <jow_laptop> per-graph is not possible without introducing complex configuration directives for the rrdtool plugin
Dec 14 13:00:54 <dwmw2_gone> I'd settle for "the maximum value that actually got sampled"
Dec 14 13:01:22 <jow_laptop> ?
Dec 14 13:01:24 <dwmw2_gone> hm, I suppose over the longer periods a peak/trough is going to disappear
Dec 14 13:03:06 <dwmw2_gone> yeah, forget it. If people want min/max on the ups data they can disable rrasingle
Dec 14 13:07:51 * dwmw2_gone does so, to test the scaling factor
Dec 14 13:12:56 <dwmw2_gone> jow_laptop: http://david.woodhou.se/0002-luci-statistics-add-scale-factor-to-graphs-use-it-fo.patch
Dec 14 13:13:43 <dwmw2_gone> I made it a general 'adjust' rather than 'scale', because I didn't want to have to express something like 'divide by 60' as "0.01666666666"
Dec 14 13:14:02 <jow_laptop> so it actually takes entire RPNs
Dec 14 13:14:26 <dwmw2_gone> fsvo 'entire' yes.
Dec 14 13:14:39 <jow_laptop> well minus the inital stack argument
Dec 14 13:14:43 <dwmw2_gone> the original value is on the stack. Your provided RPN must leave the adjusted value on the stack
Dec 14 13:15:15 <dwmw2_gone> seemed like the simplest and most versatile way to do it. I don't really expect people to use it for more then '$N,/' and '$N,*' but you never know...
Dec 14 13:15:44 <jow_laptop> I suggest it from transform to rpn or transform_rpn
Dec 14 13:16:09 <jow_laptop> and make it default to 0,+
Dec 14 13:16:24 <dwmw2_gone> and remove the if/else?
Dec 14 13:16:37 <jow_laptop> yes
Dec 14 13:16:45 <dwmw2_gone> ok. Will do that and test...
Dec 14 13:16:47 <jow_laptop> *suggest to rename it
Dec 14 13:17:17 <dwmw2_gone> 					transform_rpn = dopts.transform_rpn or "0,+",
Dec 14 13:17:31 <jow_laptop> yes
Dec 14 13:21:03 <dwmw2_gone> http://david.woodhou.se/0002-luci-statistics-add-scale-factor-to-graphs-use-it-fo.patch again
Dec 14 13:21:22 <dwmw2_gone> along with http://david.woodhou.se/0001-luci-statistics-don-t-plot-data-points-where-there-a.patch
Dec 14 13:23:17 <jow_laptop> shouldn't the _nnl then be derived from ..._raw as well?
Dec 14 13:23:29 <jow_laptop> dunno what RPNs do with NaNs
Dec 14 13:23:40 <dwmw2_gone> no, we scale *everything*
Dec 14 13:23:45 <jow_laptop> ok
Dec 14 13:23:47 <dwmw2_gone> it'll preserve NAN but that's OK
Dec 14 13:23:54 <dwmw2_gone> the ponit in nnl is to remove nan (turn it into zero)
Dec 14 13:24:15 <dwmw2_gone> if the existing datum is nan then the corresponding nnl datum becomes zero
Dec 14 13:24:26 <dwmw2_gone> the _avg *does* contain NaNs
Dec 14 13:24:36 <jow_laptop> ok, can you annotate your both patches with Sob?
Dec 14 13:24:37 <dwmw2_gone> that's why you create _nnl from it for the summation
Dec 14 13:24:55 <dwmw2_gone> didn't think you used sob in luci? My last patch didn't
Dec 14 13:25:06 <dwmw2_gone> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Dec 14 13:25:21 <dwmw2_gone> the magic is still valid as long as you cut and paste instead of typing it yourself :)
Dec 14 13:26:32 <dwmw2_gone> both patches updated at the above urls too
Dec 14 13:28:30 <builder__> build #112 of rb532 is complete: Failure [failed shell shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/112
Dec 14 13:28:48 <jow_laptop> ok committed
Dec 14 13:29:04 <dwmw2_gone> thanks
Dec 14 13:29:33 <dwmw2_gone> I'll go fix collectd to match what octo did upstream (use seconds not minutes) and resend the outstanding patch series
Dec 14 13:29:43 <dwmw2_gone> I was looking for an excuse to repost that series today anyway :)
Dec 14 13:30:58 <builder__> build #112 of ppc44x is complete: Failure [failed shell_11 shell_17]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/112
Dec 14 14:32:01 <dwmw2_gone> posted :)
Dec 14 16:05:39 <dwmw2_gone> jow_laptop: http://david.woodhou.se/0003-luci_statistics-Add-y_min-y_max-units_exponent-optio.patch
Dec 14 16:05:44 <dwmw2_gone> makes some graphs somewhat saner.
Dec 14 16:06:27 <dwmw2_gone> a 'percent' graph with a consistent X axis from 0 to 100% is nice to have
Dec 14 16:06:34 <dwmw2_gone> and system load starting at zero, etc.
Dec 14 18:49:08 <builder__> build #91 of iop32x is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/91
Dec 14 18:51:26 <builder__> build #91 of etrax is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/etrax/builds/91
Dec 14 21:33:33 <builder__> build #88 of gemini is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/88
Dec 14 22:04:12 <dwmw2_gone> cli.c:34:26: fatal error: linux/switch.h: No such file or directory
Dec 14 22:04:32 <dwmw2_gone> do I need to (fix some dependencies to) rebuild/reexport the kernel headers or something?
Dec 14 22:05:23 <dwmw2_gone> jow_laptop: thanks for committing that third patch (and the others, if I didn't already say so)
Dec 14 22:20:27 <_trine> I think you might just need to do make toolchain/clean
Dec 14 22:26:05 <dwmw2_gone> thanks. There isn't a separate target for the exported kernel headers?
Dec 14 22:46:00 <OpenWrt-Commits> hauke r34680 trunk/target/linux/brcm47xx/base-files/lib/preinit/05_init_interfaces_brcm
Dec 14 22:46:00 <OpenWrt-Commits> brcm47xx: improve suppressing printing if a module was found in preinit function.
Dec 14 22:48:33 * dwmw2_gone ponders setting up a cron job to 'git pull --rebase' the openwrt-packages directory, and resend the outstanding patches every day until they're merged :)
Dec 14 22:48:45 * dwmw2_gone wonders how long before he's banned from posting to the list, if he does that :)
Dec 14 23:03:06 <blogic> dwmw2_gone: you start sounding like a user ;)
Dec 14 23:03:39 <blogic> next you wont wonder what to do to get banned but ask if oyu can ask a question
Dec 14 23:04:00 <blogic> stage 3 of transformation involves joining channels and saying ciao a tutti :-D
Dec 14 23:04:44 <blogic> is this the nut package you keep sending ?
Dec 14 23:08:16 <KanjiMonster> blogic: you forgot poking random devs every few minutes to apply your patches ;D
Dec 14 23:09:01 <blogic> :-D
Dec 14 23:10:46 <dwmw2_gone> blogic: nut, and that other small patch that prevents us from turning x86 machines into bricks when flashrom can't find /dev/msr0
Dec 14 23:11:03 <dwmw2_gone> nothing important.
Dec 14 23:13:43 <blogic> bricking FTW !
Dec 14 23:14:22 <blogic> http://patchwork.openwrt.org/patch/3024/
Dec 14 23:14:24 <blogic> that one ?
Dec 14 23:14:26 <dwmw2_gone> thankfully I had taken a copy of the original BIOS before trying to update. So when the last few KiB failed to change, I could put the old contents back
Dec 14 23:14:36 <dwmw2_gone> yes
Dec 14 23:52:02 <dwmw2_gone> hm, both my l2tp and openconnect connections says 'Protocol support is not installed' in the configuration UI, and give me a link to install the relevant package
Dec 14 23:52:09 <dwmw2_gone> which, when followed, tells me that it is already installed
Dec 14 23:55:56 <jow_laptop> I didn't yet commit the luci support for both
Dec 14 23:56:34 <dwmw2_gone> I thought you had the l2tp one?
Dec 14 23:56:42 <dwmw2_gone> it's bitrotted, it seems. I need to fix the is_installed() function on both
Dec 14 23:57:06 <dwmw2_gone> it's no longer using opkg_package() ?
Dec 14 23:57:20 <jow_laptop> it does
Dec 14 23:57:32 <jow_laptop> I didn't change the api in a long time
Dec 14 23:57:50 <jow_laptop> opkg_package is just used as a hint waht to install, its not used to decide whether it is installed
Dec 14 23:58:13 <dwmw2_gone> ah
Dec 14 23:58:42 <jow_laptop> ah right, l2tp was part of ppp
Dec 14 23:59:55 <jow_laptop> is_installed() should return true though
Dec 14 23:59:58 <dwmw2_gone> it should
Dec 15 00:00:03 <dwmw2_gone> although wrongly so
Dec 15 00:00:06 <dwmw2_gone> it doesn't have an l2tp case
Dec 15 00:06:21 <OpenWrt-Commits> jow r34681 trunk/include/netfilter.mk * netfilter.mk: extend nf_add macro to take a version dependency expression
Dec 15 00:17:46 <dwmw2_gone> ok, fixed
Dec 15 00:19:11 <dwmw2_gone> I had a luci/model/network/proto_l2tp.lua file, even in my shiny new AA install. But afaict I must have copied that over with the openconnect one; it's not in the build tree. Removing it seems to fix l2tp.
Dec 15 00:19:18 <dwmw2_gone> well, 'fix' it not to complain about the module being absent
Dec 15 00:19:23 <builder__> build #116 of uml is complete: Exception [exception shell_7 MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/116
Dec 15 00:19:30 <dwmw2_gone> now it doesn't connect, but I'm not sure it did before...
Dec 15 00:23:20 <builder__> build #94 of rdc is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/94
Dec 15 00:24:05 <dwmw2_gone> openconnect works fine. L2TP just silently fails to do *anything* when I try to bring it up. How do I start debugging that?
Dec 15 00:25:00 <jow_laptop> do you have a default route known to netifd?
Dec 15 00:25:11 <dwmw2_gone> er...no.
Dec 15 00:25:28 <dwmw2_gone> the ADSL ports on this box are playing silly buggers so its default route is out the br-lan interface for now
Dec 15 00:25:30 <dwmw2_gone> manually
Dec 15 00:25:43 <jow_laptop> then this is the reason most likely
Dec 15 00:25:56 <jow_laptop> l2tp.sh registers a host dependency on its remote server
Dec 15 00:26:01 <dwmw2_gone> ok, thanks. Should I file a bug for the missing error message?
Dec 15 00:26:11 <jow_laptop> which is only fulfilled once netifd manages a route pointing there
Dec 15 00:26:26 <jow_laptop> not sure if you want an error message there
Dec 15 00:26:49 <dwmw2_gone> *some* indication would be useful. Even if it's just "deferring until I can reach host l2tp.aa.net.uk"
Dec 15 00:26:54 <jow_laptop> once we add one it means it will appear on boot which in turn wil lresult in tickets about "netifd producing errors"
Dec 15 00:27:21 <jow_laptop> you need to discuss this with nbd
Dec 15 00:29:26 <dwmw2_gone> there, l2tp works now. Thanks
Dec 15 00:29:59 <dwmw2_gone> must set up the rest of that, to join the neighbour's wireless as a (fon/wispr) client, then do l2tp over *that*
Dec 15 00:30:41 <jow_laptop> actually if at all the error reporting should be generalize
Dec 15 00:30:54 <jow_laptop> whenever a handler calls notify error, "ifup" should print that out
Dec 15 00:31:39 <jow_laptop> but since it all is asycronously I'm not sure if its easily doable
Dec 15 00:33:01 <dwmw2_gone> jow_laptop: http://david.woodhou.se/0001-fix-is_installed-check-for-l2tp.patch
Dec 15 00:33:22 <jow_laptop> you have no ppp.sh ?
Dec 15 00:33:39 <dwmw2_gone> I have ppp.sh, yes
Dec 15 00:33:44 <dwmw2_gone> it is not sufficient
Dec 15 00:33:54 <jow_laptop> odd
Dec 15 00:34:00 <dwmw2_gone> for l2tp to work I need to install the xl2tpd package. Which provides /lib/netifd/proto/l2tp.sh
Dec 15 00:34:11 <dwmw2_gone> hm, maybe /lib/netifd/proto/l2tp.sh doesn't get *used*?
Dec 15 00:34:21 <dwmw2_gone> perhaps I should check for the existence of /usr/sbin/xl2tpd or something like that?
Dec 15 00:34:29 <dwmw2_gone> but the xl2tpd package definitely is needed
Dec 15 00:34:46 <jow_laptop> I just wonder why it didn't return true anyway, due to the existing ppp.sh
Dec 15 00:34:52 <dwmw2_gone> it did
Dec 15 00:35:17 <dwmw2_gone> I had an older proto_l2tp.lua installed. Once I removed that, proto_ppp.lua did the right thing.
Dec 15 00:35:17 <jow_laptop> l2tp.sh is used afair
Dec 15 00:35:21 <jow_laptop> ah ok
Dec 15 00:35:27 <dwmw2_gone> I *do* have xl2tpd package installed, and it did thw right thing
Dec 15 00:35:38 <dwmw2_gone> but if I *hadn't* had xl2tpd installed, it would have returned true anyway
Dec 15 00:35:42 <dwmw2_gone> hence the patch above
Dec 15 00:36:18 <jow_laptop> yes
Dec 15 02:27:18 <builder__> build #91 of ep93xx is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/91
Dec 15 02:30:30 <builder__> build #84 of octeon is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/84
Dec 15 02:52:51 <builder__> build #95 of ar71xx is complete: Exception [exception MasterShellCommand shell_17]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/95
Dec 15 02:57:34 <builder__> build #125 of s3c24xx is complete: Failure [failed shell_11]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/125
**** ENDING LOGGING AT Sat Dec 15 02:59:58 2012