**** BEGIN LOGGING AT Thu Mar 03 02:59:58 2016 Mar 03 04:58:33 plz bump debootstrap to 1.0.79 Mar 03 04:58:39 1.0.78 went missing from the directory specified **** BEGIN LOGGING AT Thu Mar 03 05:29:14 2016 Mar 03 05:32:40 * DonkeyHotei thinks a system where debootstrap is needed probably shouldn't be running owrt Mar 03 07:01:07 has anyone seen one of these new-fcc-rule affected routers with the locked firmware, up close? Mar 03 07:01:43 nyt there is already a ticket open https://github.com/openwrt/packages/issues/2443 - feel free to send a pull request and CC the maintainer of that package Mar 03 07:09:49 russell--: not yet it seems - http://wirelesspt.net/wiki/Firmware_lockdown Mar 03 07:10:10 that link is from the battlemesh mailing list where the initial post + discussion started Mar 03 07:10:29 mailing list archive at: http://ml.ninux.org/pipermail/battlemesh/2016-February Mar 03 07:11:23 there probably will be some workshops, discussions etc. at Battlemesh (http://battlemesh.org/) Mar 03 07:12:34 russell--: looks like the guys at dd-wrt managed to inject the US firmware header onto their build Mar 03 07:13:17 " Mar 03 07:13:17 The TP-Link router upgrade runs some check against the header (not a Mar 03 07:13:17 cryptographic signature)." Mar 03 07:14:32 there is also WCW in Berlin (May) where some discussion might happen - see https://wiki.freifunk.net/Wireless_Community_Weekend_2016 - you can organize a workshop/talk there yourself Mar 03 07:51:44 oh that reminds me, I'm interested in understanding if anyone has done work in making OpenWrt support and building signed code, as in modules, libraries and other executables. I understand that because typical devices OpenWrt runs on don't support secure boot, loading the kernel is most likely unsecure, but I would like to require all executable code after that to be signed. From what I have been able to find, there is still not support in ... Mar 03 07:51:51 ... Linux for shared libraries: http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries/ Mar 03 07:55:09 * russell-- would guess it's built into the bootloader, so maybe just matter of replacing the bootloader. Mar 03 07:56:02 SwedeMike: afaik its WIP at uboot currently "secure_boot: enable chain of trust for PowerPC platform" (commit in january 2016) Mar 03 10:57:11 build #216 of imx6 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/216 Mar 03 10:57:12 build #224 of ramips is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/224 Mar 03 10:57:17 build #219 of oxnas is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/219 Mar 03 10:57:18 build #211 of malta is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/211 Mar 03 10:57:19 build #225 of brcm47xx.legacy is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/225 Mar 03 10:57:24 build #221 of ramips.mt7628 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/221 Mar 03 10:57:25 build #222 of brcm47xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/222 Mar 03 10:57:27 build #223 of bcm53xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/223 Mar 03 10:57:33 build #223 of ipq806x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ipq806x/builds/223 Mar 03 10:57:35 build #222 of ramips.rt3883 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/222 Mar 03 10:57:35 build #178 of kirkwood is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/178 Mar 03 10:57:38 build #170 of brcm47xx.mips74k is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/170 Mar 03 10:57:43 build #174 of lantiq.xrx200 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/174 Mar 03 10:57:45 build #168 of au1000 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/168 Mar 03 10:57:46 build #173 of ramips.mt7620 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/173 Mar 03 10:57:53 build #168 of ramips.rt305x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/168 Mar 03 10:57:53 build #165 of at91 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/165 Mar 03 10:57:55 build #163 of mpc83xx is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/163 Mar 03 10:57:56 build #154 of octeon is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/154 Mar 03 10:58:00 build #168 of cns3xxx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/168 Mar 03 10:58:01 build #162 of ep93xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/162 Mar 03 10:58:01 build #164 of uml is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/164 Mar 03 10:58:02 build #162 of ar71xx.mikrotik is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/162 Mar 03 10:58:03 build #164 of ath25 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/164 Mar 03 10:58:03 build #219 of cobalt is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/219 Mar 03 10:58:04 build #222 of brcm63xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/222 Mar 03 10:58:05 build #219 of cns21xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/219 Mar 03 10:58:06 build #215 of x86.64 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/x86.64/builds/215 Mar 03 10:58:07 build #204 of rb532 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/204 Mar 03 10:58:08 build #198 of brcm2708 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/198 Mar 03 10:58:09 build #185 of arm64 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/185 Mar 03 10:58:10 build #219 of orion is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/219 Mar 03 10:58:11 build #216 of pxa is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/216 Mar 03 10:58:12 build #217 of realview is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/217 Mar 03 10:58:13 build #181 of brcm63xx.smp is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/181 Mar 03 10:58:14 build #208 of ppc40x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/208 Mar 03 10:58:15 build #200 of x86.xen_domu is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/x86.xen_domu/builds/200 Mar 03 10:58:16 build #184 of x86.kvm_guest is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/184 Mar 03 10:58:17 build #174 of ixp4xx is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/174 Mar 03 10:58:18 build #185 of x86 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/185 Mar 03 10:58:19 build #181 of ar7 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/181 Mar 03 10:58:20 build #178 of avr32 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/178 Mar 03 10:58:21 build #182 of xburst is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/182 Mar 03 10:58:22 build #155 of adm5120 is complete: Failure [failed shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/155 Mar 03 10:58:23 build #161 of mvebu is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/161 Mar 03 10:58:24 build #174 of ar71xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/174 Mar 03 10:58:25 build #161 of adm8668 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/161 Mar 03 10:58:26 build #160 of mpc85xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/160 Mar 03 10:58:27 build #157 of mcs814x is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/157 Mar 03 10:58:28 build #155 of mpc52xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/155 Mar 03 10:58:29 build #154 of gemini is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/154 Mar 03 10:58:30 build #157 of sunxi is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/157 Mar 03 10:58:31 build #197 of netlogic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/197 Mar 03 10:58:32 build #224 of ramips.mt7621 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/224 Mar 03 10:58:33 build #178 of mxs is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/178 Mar 03 10:58:34 build #156 of omap is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/156 Mar 03 10:58:35 build #224 of lantiq is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/224 Mar 03 10:59:55 ugh Mar 03 11:00:35 :D Mar 03 11:01:30 migration pains Mar 03 11:02:03 =) Mar 03 11:02:50 build #194 of ar71xx.nand is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/194 Mar 03 11:13:51 build #175 of ar71xx is complete: Failure [failed] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/175 Mar 03 11:18:05 * nitroshift hands Kaloz screwdriver and hides Mar 03 11:18:15 * nitroshift hands Kaloz a screwdriver and hides Mar 03 11:27:23 jow_laptop: I was looking further at the procd_set_param file not reloading thing I was asking about last week. Mar 03 11:27:37 So, /etc/init.d/xxx reload works well, checks the file param nicely. Mar 03 11:27:46 but "reload_config" doesn't. Mar 03 11:27:53 is that how it's _meant_ to work? Mar 03 11:28:43 could reload_config just called "reload" on all the init.d scripts and let procd handle whether to restart or not? Mar 03 11:28:52 karlp_: yes. reload_config is a convenience wrapper to reload all services Mar 03 11:29:03 but only if /etc/config/foo files changed Mar 03 11:30:03 what's the downside to having it just call reload on them all and letting procd sort out whether "changes" have occured, rather than limiting it to just the /etc/config/foo files? Mar 03 11:31:29 the fact that not all services are gracefully handlign relaods yet Mar 03 11:31:48 there's a number of services having reload implemented as uncondtional start/stop iirc Mar 03 11:32:35 won't that always be the case? isnt that because they _want_ to do that? Mar 03 11:33:05 is it really easonable to stop everyone else from having the richness of procd support just because some people are hardrestarting services? Mar 03 11:34:24 calling init scripts takes time as well Mar 03 11:34:29 i think having the triggers is a better solution Mar 03 11:37:26 whcih trigger? Mar 03 11:37:56 https://wiki.openwrt.org/inbox/procd-init-scripts#procd_triggers_on_config_filenetwork_interface_changes seems to imply that that does the reload if the /etc/config/(foo changes, Mar 03 11:38:05 but it seems that "reload_config" already does that for you, Mar 03 11:38:17 here's how it works: Mar 03 11:38:43 reload_config checks the hash for each config file, and if it changed, it generates config file change triggers Mar 03 11:38:50 which procd uses to determine which init scripts need to be called again Mar 03 11:39:05 based on what trigger information the init script provided on first run Mar 03 11:39:44 ok, so only a procd init script that has a "service_triggers" function, with a procd_add_reload_trigger call, will actually get reloaded when "reload_config" is called. Mar 03 11:39:55 yes Mar 03 11:40:51 can you have triggers on files not in /etc/config? Mar 03 11:41:42 there's also "procd_add_config_trigger" ? Mar 03 11:41:47 right now we don't have any triggers for that Mar 03 11:42:06 where would you need it? Mar 03 11:42:56 for something like procd_set_param file /etc/some-non-uci-config stuff. Mar 03 11:43:14 i have an idea on how to solve this Mar 03 11:43:31 /etc/init.d/blah reload works very well with that file param, it's nice. Mar 03 11:43:41 reload_config could emit a config.change trigger for '*' after it has emitted a trigger for all the files that changed Mar 03 11:43:59 so you could define a trigger that would lead to an init script reload call for every reload_config call Mar 03 11:44:19 so apps with "good" wellbehved procd init scripts could register their support, Mar 03 11:44:32 yes, that sounds like it would work out. Mar 03 11:45:17 just so I can update the wiki a bit then, what's the difference between procd_add_reload_trigger and procd_add_config_trigger now then? Mar 03 11:45:53 procd_add_reload_trigger is a wrapper for the other one Mar 03 11:46:28 either way, if we add support for a '*' trigger, it should be used by as few init scripts as possible Mar 03 11:47:13 why not just any script that already has a add_reload_trigger line as well? Mar 03 11:50:11 plntyk: interesting, do you know about the rest of the current support. I mean, booting the kernel is one thing, in order to get the rest then modules, libs and executables need to be signed, is this being worked into the build system? Mar 03 11:50:47 one thing that would be "nice(tm)" would be to be able to send signals in the reload handler, instead of stop/start. Quite a few daemons can reload their config files on some signal. Mar 03 11:51:37 not sure whether that woulbe a new cmd_handler in procd/triggers or just different scripts to run... Mar 03 12:02:24 SwedeMike: no i dont know of any project or of anyone working on OpenWrt with that ("secure boot" in uboot seems to be PPC/ARM - for the imx target it seems to be possible because of open specs/docs) - so you need right hw for that - i just stumbled across those things when looking at posts on january uboot list (http://lists.denx.de/pipermail/u-boot/2016-January/) Mar 03 12:02:52 plntyk: the part I'm looking for is what happens after the kernel has been booted, not so much booting the kernel securely Mar 03 12:03:02 plntyk: but ok, thanks for the info Mar 03 12:05:22 shouldnt this be documented either in Kernel Tree (in Documentation subdir) or maybe by some "larger" projects on some Linux Conference - from free-electrons or some other embedded company Mar 03 12:08:39 embedded world had a conference track for "Securing IOT" - dont know how good these tracks were since they seem to be closed and only for extra $$$ Mar 03 12:09:02 how ironic Mar 03 12:09:22 "In zwölf Fachvorträgen beleuchten hier Fachleute aus Forschung und Industrie unterschiedliche Aspekte der Sicherheit von Embedded Systemen. " Mar 03 12:09:37 from a german news site ^^ Mar 03 12:09:50 hopefully not the same fachleute running the bsi Mar 03 12:10:25 yeah lol - that Cyber-Clown Mar 03 12:13:30 its funny that these conferences demand such amounts of money, having big "sponsors" according to their web pages and the CCC manages to have a bigger congress Mar 03 12:16:02 embedded world conference track had "only" 1600 visitors thats way less than congress Mar 03 12:16:40 90% of show visitors are "management" Mar 03 12:17:21 those ppl responsible for not implementing GPL conformity Mar 03 12:19:12 karlp: we don't want every init script to be called on every reload_config call Mar 03 12:19:20 that's just a waste of cpu time Mar 03 12:19:37 karlp: and most init scripts simply don't need it Mar 03 12:20:30 nbd: but I guess we can make ubus call service list expose the current file watches, then make reload_config aware of that Mar 03 12:20:54 nbd: I'd also like to expose the netdev watches in the ubus state, then we can also add hotplug functionality Mar 03 12:21:53 i don't think we should trigger netdev watch based on netdev hotplug events Mar 03 12:22:42 not by default but I want the ability Mar 03 12:22:56 ok Mar 03 12:23:12 but back to the files Mar 03 12:23:35 I'd like /sbin/reload_config to fetch a list of current active file watches via ubus call service list Mar 03 12:23:43 then make it hash those toop Mar 03 12:23:45 *too Mar 03 12:23:54 wouldn't it make more sense to have procd do that internally Mar 03 12:24:18 do what internally? Mar 03 12:24:28 check the file hashes Mar 03 12:24:31 against the ones it recorded already Mar 03 12:25:06 it does, I meant the fingerpritning performed by reload_config to decide whether to do something or not Mar 03 12:28:16 hm, but thinking further about it Mar 03 12:28:26 i think current file entries are not suitable for that Mar 03 12:28:30 that entire reload_config thing should become an ubus service.* call Mar 03 12:28:34 we'd be mashing together values with different meanings Mar 03 12:28:42 i agree Mar 03 12:28:53 ubus call service reload_whatever_needs_reloading Mar 03 12:28:56 here's the thing, we need to differentiate between two different kinds of config files Mar 03 12:29:03 the kind that needs an instance restart Mar 03 12:29:04 basically a global state recalculation Mar 03 12:29:07 and the kind that needs an init script restart Mar 03 12:29:29 so far we've only covered the one that needs an instance restart Mar 03 12:29:37 and we should not use it as a trigger for init scripts at all Mar 03 12:29:59 because the kind of files we reference are often generated by the init script Mar 03 13:16:29 "ubus listen" doesn't show the ubus call service events? is neither does "ubus listen service" ? aren't you meant to see the events here? Mar 03 13:16:59 also, procd's doing somehting odd with symlink targets: https://paste.fedoraproject.org/332905/45701101/ Mar 03 14:06:20 oh, so ubus listen only listens to things that were "send"ed, ubus call doesn't. Mar 03 14:06:59 so, why is the reload_config "calling" the "service" blob with an event, instead of just publishing an event for anyone to consume that wants to listen? Mar 03 14:09:14 karlp: there likely is no particular reason Mar 03 14:09:34 I suppose while implementing it that event where considered to be an internal communication detail Mar 03 14:10:22 this is what happens when you end up with both rpc and pub/sub options available to people :) Mar 03 15:13:54 I just discovered python doesn't have proper event loop http clients... this is outrageous Mar 03 15:45:49 build #224 of bcm53xx is complete: Failure [failed shell_16 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/224 Mar 03 15:45:49 build #183 of ar7 is complete: Failure [failed shell_16 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/183 Mar 03 15:45:49 build #170 of au1000 is complete: Failure [failed shell_16 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/170 Mar 03 15:49:05 build #220 of orion is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/220 Mar 03 15:49:59 build #217 of pxa is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/217 Mar 03 15:50:03 build #220 of cobalt is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/220 Mar 03 15:50:07 build #209 of ppc40x is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/209 Mar 03 15:50:27 build #164 of mpc83xx is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/164 Mar 03 15:50:31 build #179 of avr32 is complete: Failure [failed shell_11] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/179 Mar 03 16:27:14 build #157 of omap is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/157 Mar 03 18:19:38 build #161 of mpc85xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/161 Mar 03 18:35:29 nbd: ^ Package kmod-usb2-fsl is missing dependencies for the following libraries: ehci-hcd.ko Mar 03 18:35:40 I suppose due to the 4.4 bump Mar 03 18:44:53 on what platform? Mar 03 19:08:53 fsl=freescale so probably arm Mar 03 19:09:30 ah no TARGET_mpc85xx:kmod-usb2-fsl Mar 03 19:09:31 actually it was mpc85xx Mar 03 19:09:35 :) Mar 03 19:09:50 selling IP to ppc Mar 03 19:09:51 the link the last buildbot msg Mar 03 19:11:01 are the buildbots supposed to work correctly ? "Could not generate file hash" seems like a strange error Mar 03 19:11:21 (found in http://buildbot.openwrt.org:8010/builders/omap/builds/157/steps/compile_3/logs/stdio ) Mar 03 19:13:47 hm.... http://buildbot.openwrt.org:8010/buildslaves/wyrding - is that page supposed to have clickable "stop build" buttons - dunno if they work - I won't klick on them Mar 03 19:14:38 build #217 of x86.64 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.64/builds/217 Mar 03 19:17:09 and the bot with " No space left on device" is still working Mar 03 21:33:07 build #195 of ar71xx.nand is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/195 Mar 04 00:16:29 build #222 of ramips.mt7628 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/222 Mar 04 01:05:49 build #218 of realview is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/218 Mar 04 01:50:28 build #205 of rb532 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/205 Mar 04 01:53:15 build #158 of sunxi is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/158 Mar 04 02:43:42 build #155 of octeon is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/155 **** ENDING LOGGING AT Fri Mar 04 02:59:58 2016