**** BEGIN LOGGING AT Fri Jun 13 02:59:59 2014
Jun 13 03:19:59 <plntyk> russell: what do you mean by "new-wiki carnage" ?
Jun 13 03:56:23 <russell--> plntyk: back in 2009 the old wiki was just turned off for 4+ months
Jun 13 03:56:33 <russell--> that is, no edits
Jun 13 03:57:27 <russell--> and then, it was kind of abandoned in place, similar to old-packages with a new mostly empty wiki taking its place
Jun 13 03:58:21 * russell-- made an observation at the time that a better solution might have been to just fix the pages that were seen to be inadequate, instead of killing input for half a year
Jun 13 04:19:38 <plntyk> ah yes that seems bad ....  I think there should be some "invisibility flag" like @BROKEN for dead/obsolete upstream and/or using unmaintained upstream (current upstream too large for OpenWrt : example rrdtool)
Jun 13 04:56:52 <5EXAA8SU8> build #90 of bcm53xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/90
Jun 13 05:14:49 <5EXAA8SU8> build #87 of omap is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/87
Jun 13 05:34:16 <5EXAA8SU8> build #88 of adm8668 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/88
Jun 13 05:37:27 <russell--> zip build is broken in the new packages archive, complaining about a missing dependency on libbz2
Jun 13 05:59:24 <5EXAA8SU8> build #193 of mxs is complete: Failure [failed shell]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/193
Jun 13 06:12:54 <5EXAA8SU8> build #88 of brcm2708 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/88
Jun 13 06:27:01 <5EXAA8SU8> build #499 of ep93xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/499
Jun 13 07:14:05 <cyrusff> Btw. Guys we have added a 3 weeks grace period where we still build oldpackages.
Jun 13 07:14:40 <cyrusff> https://forum.openwrt.org/viewtopic.php?id=51078
Jun 13 07:18:35 <5EXAA8SU8> build #551 of ixp4xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/551
Jun 13 07:18:39 <5EXAA8SU8> build #661 of at91 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/661
Jun 13 07:28:13 <5EXAA8SU8> build #492 of adm5120 is complete: Failure [failed shell]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/492
Jun 13 07:28:52 <russell--> cyrusff: i'm still a little unclear on the motivation for the packages change, is it just to try to shed them so they aren't 'core' openwrt's responsibility any more? or something else?
Jun 13 07:54:12 <megal0maniac> russell--: I'd guess it's just easier to start with a clean slate and put everything back one by one than to try and weed out unmaintained and obsolete packages
Jun 13 07:55:33 <megal0maniac> You're right about the "package carnage" breaking things (even Luci won't work for me at the moment) but I suppose this is also one of the goals - to "untangle" stuff with strange dependencies and workarounds
Jun 13 07:57:18 <dottedmag> russell--: I have done a major cleanup of wiki of one of Linux distributions (relatively-obscure one).
Jun 13 07:57:32 <dottedmag> There was maybe 1:20 compression rate after getting rid of old, irrelevant and duplicate stuff.
Jun 13 07:57:57 <dottedmag> Granted, packages are not documentation, but still.
Jun 13 08:01:49 <megal0maniac> dottedmag: Well yeah, there's a correlation. It's "spring cleaning" in a sense. Devs and contributors come and go, and it can get messy quite quickly. I just wish it wasn't so destructive
Jun 13 08:03:48 <dottedmag> Was there packages repository on github before, by the way?
Jun 13 08:03:53 * dottedmag was little bit disconnected
Jun 13 08:08:04 <cyrusff> dottedmag: there were git mirrors of the old packages svn, and there are some feeds on github already (e.g. routing feed)
Jun 13 08:10:40 <russell--> there were only a dozen or so packages that didn't build for me, out of a crapton
Jun 13 08:11:50 <cyrusff> thats not really the point
Jun 13 08:12:06 <cyrusff> there were / are at least a dozen with critical vulnerabilities
Jun 13 08:12:34 <cyrusff> + we couldn't really keep up with patches that got send
Jun 13 08:13:27 <dottedmag> I suppose https://dev.openwrt.org/wiki/SubmittingPatches should be updated to not to suggest to submit [packages] e-mails.
Jun 13 08:14:25 <russell--> cyrusff: so what's likely to happen now?
Jun 13 08:14:51 <cyrusff> we have readded "oldpackages" as enabled by default now
Jun 13 08:14:53 <cyrusff> at least for june
Jun 13 08:15:03 <russell--> right, but after that
Jun 13 08:15:05 <cyrusff> then we will disable it again
Jun 13 08:15:15 <cyrusff> haven't really made a finally decision
Jun 13 08:15:29 * russell-- is hoping that the repo's hang around, just the link in feeds.conf goes away?
Jun 13 08:15:44 <cyrusff> yeah that i guess will happen anyway
Jun 13 08:15:58 <cyrusff> either it will be removed from feeds.conf.default or commented out again
Jun 13 08:16:08 <dottedmag> cyrusff: Maybe try "3% of packages get shot from oldpackages every day"? :)
Jun 13 08:16:15 <russell--> what i meant was, what is likely to happen with new-packages over time?  the same thing is likely to happen.
Jun 13 08:16:36 <russell--> people will tag themselves as maintainers and then wander away
Jun 13 08:16:44 <cyrusff> maybe
Jun 13 08:17:04 <cyrusff> but github is a more accessbile platform than svn
Jun 13 08:17:08 <dottedmag> Unless the bottleneck was in patch merging.
Jun 13 08:17:18 <cyrusff> right and thats what we believe
Jun 13 08:17:51 <cyrusff> and somehow giving people access to svn got stuck for sometimes months
Jun 13 08:17:57 <dottedmag> At least github solves the problem "where the heck do I host my copy?"
Jun 13 08:18:02 <cyrusff> because of admin-foo or bureaurcarcy whatever
Jun 13 08:19:22 <russell--> i can see this having a help-recruiting effect
Jun 13 08:20:30 <cyrusff> + at least github makes merging pull requests 10x easier then fethcing patches
Jun 13 08:20:42 <cyrusff> from a mailing ist
Jun 13 08:21:06 <dottedmag> I wonder whether TravisCI can be configured to build pull requests (in some default configuration of OpenWRT).
Jun 13 08:22:25 <russell--> what's the canonical way to rebase github forks? /me hasn't spent much time doing that
Jun 13 08:23:34 <russell--> e.g. i forked openwrt/packages.git, i create my own branches for patches, how do i keep my fork up-to-date with openwrt's
Jun 13 08:23:48 <cyrusff> git pull --rebase
Jun 13 08:24:09 <cyrusff> or without --rebase if you want merge commits
Jun 13 08:24:24 <cyrusff> with git you can add multiple remote-repositories per local-repository
Jun 13 08:24:44 <russell--> right, maybe that workflow should be documented?
Jun 13 08:25:18 <russell--> because unless you have write access you are going to be pushing to your own fork/branch and making a pull request, right?
Jun 13 08:25:28 <cyrusff> right
Jun 13 08:25:38 <cyrusff> but i wouldn't mind giving you write access :P
Jun 13 08:25:59 <russell--> so, the precise mechanics of that, in the general case, might be useful for the general audience
Jun 13 08:26:51 <russell--> sometimes i have dumb ideas for fixes (though they usually work for me), so i don't mind someone else looking at them first
Jun 13 08:27:03 <cyrusff> ok
Jun 13 08:34:33 <russell--> like that one, for example ;-)
Jun 13 08:34:46 <cyrusff> he
Jun 13 08:35:14 <cyrusff> it's not stupid though just maybe not preferable ;)
Jun 13 08:35:55 <russell--> right
Jun 13 08:36:25 <russell--> i appreciate the feedback, hopefully that leads to better patches over time
Jun 13 08:51:11 <OpenWrt-Commits> cyrus r41175 packages/libs/nacl * nacl: moved to github
Jun 13 08:51:12 <OpenWrt-Commits> cyrus r41176 packages/net/ethtool * ethtool: moved to github
Jun 13 08:57:06 <russell--> flashrom has a build problem on mips, to do with cb_vendor and cb_model not being defined
Jun 13 09:17:58 <OpenWrt-Commits> blogic r41177 trunk/target/linux/ (9 files in 8 dirs) * ramips: add asiarf awapn2403 support
Jun 13 09:23:53 <russell--> oh, that reminds me, the switch configuration for the asiarf awm003 (and maybe the 002) is wrong
Jun 13 09:35:46 <OpenWrt-Commits> nbd r41178 trunk/ (9 files in 9 dirs) * kernel: fix pkt_type filter mask for packet sockets
Jun 13 09:41:57 <OpenWrt-Commits> nbd r41179 trunk/package/kernel/mac80211/Makefile * revert an accidentally committed patch chunk
Jun 13 10:06:23 <5EXAA8SU8> build #89 of mpc83xx is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/89
Jun 13 10:11:49 <OpenWrt-Commits> nbd r41180 trunk/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh * mac80211: fix disabling of 802.11n features
Jun 13 10:18:08 <plntyk> is luci2 bugged atm ? i only get Loading data after entering login+password
Jun 13 10:22:34 <jow_laptop> plntyk: check the console with firebug
Jun 13 10:26:21 <5EXAA8SU8> build #88 of cns3xxx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/88
Jun 13 10:34:13 <plntyk> k its open - in Netzwerk/xhr  :4x 404: base.en-us.json , base.en.json , ppp.js , pppoe.js not found - is some of that the cause ?
Jun 13 10:38:10 <jow_laptop> hm not sure... can you make a screenshot?
Jun 13 10:45:16 <plntyk> screenshot: http://imgur.com/N2QhUQR
Jun 13 10:45:50 <jow_laptop> the last one is an error
Jun 13 10:46:07 <jow_laptop> you might need to activate the script tab
Jun 13 10:46:13 <jow_laptop> then you can pinpoint the exact error
Jun 13 10:46:24 <jow_laptop> or location rather
Jun 13 10:50:51 <plntyk> luci2.js line 1743  : var alias = (ifname.charAt(0) == '@');
Jun 13 10:52:05 <jow_laptop> can you pastebin your network config?
Jun 13 10:52:31 <jow_laptop> and is there a stack trace?
Jun 13 10:54:11 <jow_laptop> I think there's some cornercase in your network or wifi config
Jun 13 10:54:28 <jow_laptop> with the stack trace I could determine where exactly
Jun 13 10:54:45 <plntyk> network config: http://paste.debian.net/104775/
Jun 13 10:55:36 <plntyk> wireless: http://paste.debian.net/104776/
Jun 13 10:56:30 <plntyk> how to create a stacktrace - firebug ? or with commandline in openwrt ?
Jun 13 10:57:32 <jow_laptop> firebug... once the script tab is activated you should be able to click on the "TypeError" line and it should jump to the script table with a "Stack" tab on the right pane
Jun 13 10:58:15 <jow_laptop> if that does not work you can set a breakpoint in the error console next to the typeerror (the pale red circle)
Jun 13 10:58:25 <jow_laptop> then reload the page
Jun 13 11:08:53 <plntyk> stack trace all expanded with breakpoint set on type error line: http://paste.debian.net/104779/
Jun 13 11:10:51 <OutBackDingo> jow_laptop: whos handling ssh keys for commits now
Jun 13 11:11:15 <OutBackDingo> time for me to get back to work on wrt things
Jun 13 11:45:20 <jow_laptop> plntyk: can you provide me with the output of "ubus call luci2.network device_list" ?
Jun 13 11:45:22 <nighty^> nbd,  clk_disable issue isn't in the x86 image , the soekris boots fine so so far I see it only in ar71xx
Jun 13 11:47:40 <plntyk> jow_laptop:  http://paste.debian.net/104783/
Jun 13 11:52:08 <jow_laptop> plntyk: and  ubus call network.wireless status  ?
Jun 13 11:52:50 <plntyk> jow_laptop: http://paste.debian.net/104784/
Jun 13 11:53:03 <jow_laptop> ah, there we go
Jun 13 11:55:39 <jow_laptop> http://git.openwrt.org/?p=project/luci2/ui.git;a=commitdiff;h=b7bde2e0ae9f21a3726fd6567e2b5eacbb8dbb92
Jun 13 12:09:42 <KanjiMonster> nighty^: I guess this is a AA issue?
Jun 13 12:10:02 <nighty^> KanjiMonster, it is an AA issue since the last batch of patches
Jun 13 12:10:21 <nighty^> KanjiMonster, it worked fine before that
Jun 13 12:10:52 <KanjiMonster> nighty^: looks like the issue is that compat-3.6/clk.h check for COMMON_CLK, but the symbol was only introduced in 3.4 (also nbd, Hauke_away)
Jun 13 12:12:30 <nighty^> KanjiMonster, I see but it works in AA on net6501 at same revision r41156
Jun 13 12:13:41 <KanjiMonster> net6501 is which target?
Jun 13 12:13:45 <nighty^> x86
Jun 13 12:16:12 <KanjiMonster> x86 does not implement clk(enable,disable), so it works there. but ar71xx does implement it, therefore the conflict. I would assume most targets have the problem
Jun 13 12:19:13 <KanjiMonster> I guess HAVE_CLK would be more correct to check
Jun 13 12:19:36 <nighty^> I see
Jun 13 12:20:55 <nighty^> KanjiMonster, however it fails in ar71xx and I do not know the cause
Jun 13 12:21:31 <nighty^> so I am not sure I follow your logic
Jun 13 12:22:17 <KanjiMonster> nighty^: the cause is it checks the wrong config symbol for presence of clk_disable - it checks COMMON_CLK, sees it isn't defined, and exports it own clk_disable. While ar71xx has HAVE_CLK selected, and also exports clk_disable.
Jun 13 12:22:56 <KanjiMonster> x86 has neither, and also does not export any clk_disable. therefore it works, even when checking the wrong config symbol.
Jun 13 12:23:07 <nighty^> Ok I understand
Jun 13 12:24:05 <nighty^> But I wonder why that was touched
Jun 13 12:24:10 <nighty^> since it worked before
Jun 13 12:24:33 <nighty^> was it lost in some attempt to fusion together that support for multiple platform ?
Jun 13 12:25:37 <KanjiMonster> probably because kernel-backports now includes drivers that rely on clk_enable/disable, and they are now always present on modern kernels (even if only as stubs)
Jun 13 12:25:56 <nighty^> Ah that would explain it yes.
Jun 13 12:26:10 <KanjiMonster> grep "CONFIG_HAVE_CLK=y" target/linux/*/config-* will give you all broken targets ;)
Jun 13 12:26:23 <nighty^> :(
Jun 13 12:27:08 <KanjiMonster> actually, likely not even all
Jun 13 12:27:26 <KanjiMonster> I know of at least one target that doesn't define HAVE_CLK, but implements clk_enable
Jun 13 12:28:20 <nighty^> how about atheros target ?
Jun 13 12:29:19 <nighty^> Looks like a major breakage though
Jun 13 12:29:24 <nighty^> (major for users)
Jun 13 12:29:26 <KanjiMonster> doesn't implement clk_enable, so should work there
Jun 13 12:32:30 <KanjiMonster> it will likely be a mess to sort out and require a few kernel packports
Jun 13 12:33:55 <KanjiMonster> (like those commits selecting HAVE_CLK for those targets that implement clk_enable/disable, but are missing the select)
Jun 13 12:34:16 <nighty^> Yes it looks like the problem is a little more complicated and impacting
Jun 13 12:34:22 <nighty^> that what I initially thought
Jun 13 12:34:35 <nighty^> I mean to do it right
Jun 13 12:34:44 <nighty^> right now I just disabled that and it works
Jun 13 12:34:51 <nighty^> but that is not the way to rightly fix it
Jun 13 12:36:19 <nighty^> CONFIG_HAVE_CLK is the same as CONFIG_COMMON_CLK ?  if so then modifying the #ifndef in compat/compat-3.6.c would be reasonable no ?
Jun 13 12:36:34 <nighty^> I think not
Jun 13 12:36:55 <nighty^> nbd, ?
Jun 13 12:38:07 <KanjiMonster> no, they are not the same
Jun 13 12:39:30 <KanjiMonster> HAVE_CLK means the presence of clk_*, while COMMON_CLK is a generic implementation for most clk operations (and selects HAVE_CLK)
Jun 13 12:41:49 <KanjiMonster> HAVE_CLK implies clk_get/clk_put/clk_enable/disable; COMMON_CLK is a framework for those so arch code does not have to implement these by itself, but only the actual register modification part (but no refcounting etc)
Jun 13 12:41:56 <KanjiMonster> oh, oops
Jun 13 12:42:18 <KanjiMonster> some how missed I pressed enter ;)
Jun 13 12:42:36 <5EXAA8SU8> build #90 of realview is complete: Failure [failed shell]  Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/90
Jun 13 12:59:23 <nighty^> :)
Jun 13 13:11:47 <nighty^> KanjiMonster, so basically how do we fix this ?
Jun 13 13:12:16 <Noltari> russel-- which target did you use to build flashrom? https://github.com/openwrt/packages/issues/18
Jun 13 13:13:13 <KanjiMonster> nighty^: change the check in compat-3.6.c/clk.h to HAVE_CLK instead of COMMON_CLK, add a "select HAVE_CLK" for those targets that do implement clk_enable/disable without selecting it
Jun 13 13:13:31 <KanjiMonster> no idea if this is the right thing for 3.4/3.5
Jun 13 13:14:44 <nighty^> uhmmm
Jun 13 13:15:34 <nbd> for openwrt i will do something else
Jun 13 13:15:41 <nbd> rip out the clk_* backport ;)
Jun 13 13:15:49 <nighty^> oh
Jun 13 13:15:54 <nighty^> I could have done that :)
Jun 13 13:16:52 <nighty^> nbd, you are serious ?
Jun 13 13:17:09 <nighty^> the problem with the funky tcpdump was that the AA tcpdump is too old
Jun 13 13:17:12 <nighty^> btw
Jun 13 13:17:32 <nbd> interesting
Jun 13 13:17:41 <nbd> yes, i'm serious about the clk_* stuff
Jun 13 13:17:46 <nbd> because no wireless driver uses it
Jun 13 13:17:50 <nighty^> I fixed this for myself by using the one from trunk
Jun 13 13:17:55 <KanjiMonster> nbd: that works, too, since afaict none of the clk_* users are wireless drivers
Jun 13 13:18:13 <nighty^> USB port ?
Jun 13 13:19:23 <nighty^> but I guess really the package should be upgraded in AA
Jun 13 13:19:29 <nighty^> for tcpdump
Jun 13 13:20:36 <nighty^> nbd, no influence on USB driver ?
Jun 13 13:21:09 <nighty^> nbd, for clk*
Jun 13 13:21:14 <nighty^> I guess I could check
Jun 13 13:21:48 <nbd> no influence there
Jun 13 13:28:17 <KanjiMonster> zajec_: ping
Jun 13 13:31:02 <OpenWrt-Commits> nbd r41181 trunk/package/kernel/mac80211/patches/080-disable_clk_backport.patch
Jun 13 13:31:02 <OpenWrt-Commits> mac80211: disable the clk_* backport, it is unused by drivers and has the wrong ifdef
Jun 13 13:31:54 <nighty^> nbd, thanks
Jun 13 13:32:51 <nbd> backport will be committed soon
Jun 13 13:32:56 <nighty^> yup :)
Jun 13 13:35:22 <OpenWrt-Commits> nbd r41182 branches/attitude_adjustment/package/ (6 files) * AA: mac80211: sync with trunk r41181
Jun 13 13:36:43 <zajec_> KanjiMonster: pong (but a bit lacking of time)
Jun 13 13:38:07 <KanjiMonster> zajec_: I just noticed, won't making ssb a module disable the fallback_sprom support for it, thus causing issues for wrt610nv2/e3000v1's pcie wifi? or do they come with a working sprom?
Jun 13 13:38:14 <KanjiMonster> for the 74k target
Jun 13 13:38:53 <zajec_> hm, don't know
Jun 13 13:38:59 <zajec_> i never played with fallback_sprom
Jun 13 13:40:18 <KanjiMonster> most if not all embedded wifis need it, because the pcie cards have no (valid) sprom, and take theirs from nvram values
Jun 13 13:40:31 <zajec_> Hauke_away: i think u have WRT610N v1
Jun 13 13:40:37 <zajec_> Hauke_away: did you test mips74k on it?
Jun 13 13:40:46 <zajec_> KanjiMonster: i know..
Jun 13 13:40:49 <zajec_> you may be right
Jun 13 13:42:15 <KanjiMonster> AFAIK v2, not v1. v1 is bcm4785 + bcm4321 I think.
Jun 13 13:45:44 <zajec_> ah, right, it mush be V2
Jun 13 13:45:48 <zajec_> so we don't even haev a tester
Jun 13 13:46:05 <zajec_> i hate there are bcma SoCs with ssb PCIe attached :/
Jun 13 13:46:18 <zajec_> i'll look at this over weekend
Jun 13 13:46:55 <KanjiMonster> jow_laptop: is the e3000 you received a v1?
Jun 13 14:13:06 <5EXAA8SU8> build #89 of x86_64 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/x86_64/builds/89
Jun 13 15:31:25 <russell--> Noltari: it was ar71xx
Jun 13 15:31:41 <russell--> oh, no, strike that, it was ramips
Jun 13 15:40:42 <Noltari> russell-- mmm isn't ramips big endian?
Jun 13 15:41:17 <Noltari> that bug only happened on mips little endian (I had tested it on brcm63xx with no issues)
Jun 13 15:44:25 <russell--> this one is mipsel, afaict
Jun 13 15:45:13 <russell--> it was for the asiarf awm002-evb
Jun 13 16:28:27 <OpenWrt-Commits> cyrus r41183 packages/libs/libowfat * libowfat: moved to github
Jun 13 16:28:28 <OpenWrt-Commits> cyrus r41184 packages/net/xl2tpd * xl2tpd: moved to github
Jun 13 16:28:29 <OpenWrt-Commits> cyrus r41185 packages/admin/debootstrap * debootstrap: moved to github
Jun 13 16:28:30 <OpenWrt-Commits> cyrus r41186 packages/net/freeradius2 * freeradius: moved to github
Jun 13 17:02:39 <karlp> on a somewhat recent BB (a week maybe?) should link down/linkup trigger dhcp client to run again?
Jun 13 17:03:32 <karlp> or is force_link interfering with that?
Jun 13 17:03:39 <karlp> I see the link down, link up in logread
Jun 13 17:41:51 <5EXAA8SU8> build #594 of rb532 is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/594
Jun 13 17:42:12 <5EXAA8SU8> build #594 of ppc44x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/594
Jun 13 17:44:04 <5EXAA8SU8> build #563 of sibyte is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/563
Jun 13 17:50:06 <5EXAA8SU8> build #501 of iop32x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/501
Jun 13 18:42:38 <nighty^> nbd, thanks for the backports :)
Jun 13 18:44:44 <5EXAA8SU8> build #640 of orion is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/640
Jun 13 18:50:21 <5EXAA8SU8> build #605 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/605
Jun 13 19:02:49 <5EXAA8SU8> build #565 of xburst is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/565
Jun 13 19:02:56 <5EXAA8SU8> build #634 of cobalt is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/634
Jun 13 19:06:12 <5EXAA8SU8> build #629 of lantiq is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/629
Jun 13 19:06:49 <5EXAA8SU8> build #529 of au1000 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/529
Jun 13 19:12:26 <5EXAA8SU8> build #546 of kirkwood is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/546
Jun 13 19:12:45 <5EXAA8SU8> build #200 of imx6 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/200
Jun 13 20:26:01 <5EXAA8SU8> build #489 of mcs814x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/489
Jun 13 20:38:04 <5EXAA8SU8> build #574 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/574
Jun 13 21:46:12 <5EXAA8SU8> build #89 of pxa is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/89
Jun 13 22:52:27 <5EXAA8SU8> build #593 of ar7 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/593
Jun 14 00:59:14 <ausjke> is it feasible to add a uhttpd mod to handle soap(xml/http)?
Jun 14 00:59:23 <ausjke> or I have to hack uhttpd directly
Jun 14 02:10:18 <5EXAA8SU8> build #92 of cns21xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/92
**** ENDING LOGGING AT Sat Jun 14 02:59:58 2014