**** BEGIN LOGGING AT Wed Feb 03 02:59:58 2016 Feb 03 03:01:20 build #171 of brcm63xx.smp is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/171 Feb 03 03:01:23 build #168 of kirkwood is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/168 Feb 03 03:02:30 build #164 of ixp4xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/164 Feb 03 03:06:27 build #164 of ar71xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/164 Feb 03 03:07:25 build #167 of mxs is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/167 Feb 03 03:07:57 build #164 of lantiq.xrx200 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/164 Feb 03 03:11:34 build #160 of brcm47xx.mips74k is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/160 Feb 03 03:12:48 build #158 of au1000 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/158 Feb 03 03:13:13 build #163 of ramips.mt7620 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/163 Feb 03 03:17:29 build #159 of ramips.rt305x is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/159 Feb 03 03:17:37 build #157 of at91 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/157 Feb 03 03:18:02 build #155 of mpc83xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/155 Feb 03 03:21:25 build #163 of ixp4xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/163 Feb 03 03:22:29 build #160 of cns3xxx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/160 Feb 03 03:22:50 build #154 of ep93xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/154 Feb 03 03:22:52 build #155 of ath25 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/155 Feb 03 03:25:54 build #155 of uml is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/155 Feb 03 03:27:27 build #153 of mvebu is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/153 Feb 03 03:28:01 build #152 of mpc85xx is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/152 Feb 03 03:28:09 build #153 of adm8668 is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/153 Feb 03 04:53:22 build #154 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/154 Feb 03 06:01:45 build #154 of ar71xx.mikrotik is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/154 Feb 03 06:49:00 nbd, ping Feb 03 09:28:47 nitroshift: pong Feb 03 09:30:19 servers are back Feb 03 09:33:02 nbd, re: witi Feb 03 09:33:22 the new edition will be manufactured after the chinese new year Feb 03 09:33:42 rmilecki r48621 trunk/target/linux/generic/ files/drivers/net/phy/swconfig.c files/include/linux/switch.h * swconfig: add (PHY) generic helper setting port link Feb 03 09:33:51 rmilecki r48622 trunk/target/linux/generic/files/drivers/net/ phy/b53/b53_priv.h phy/b53/b53_mdio.c phy/b53/b53_common.c * b53: provide PHY access to swconfig Feb 03 09:33:57 rmilecki r48623 trunk/target/linux/generic/files/drivers/net/phy/b53/b53_common.c * b53: support setting port link Feb 03 09:38:43 rmilecki r48624 trunk/package/network/config/swconfig/src/swlib.c * swconfig: support setting SWITCH_TYPE_LINK attributes Feb 03 09:54:37 nitroshift: nice Feb 03 09:58:00 changes or just a new manufacturing run? Feb 03 10:00:12 new manufacturing run Feb 03 10:03:26 nbd, karlp actually a few changes too Feb 03 10:03:57 512MB RAM default, 32MB SPI NoR and cooling for the chips Feb 03 11:32:31 jow_laptop: why do struct ubus_object_type and ubus_object exist? Don't they have duplicate data? I was looking at possible uses, such as reusing, but I really cannot figure out why both exist, and ubus_object contains the _type Feb 03 12:42:51 txomon: hm? they're entirely different structures Feb 03 12:43:33 jow_laptop: but ubus_object holds a copy of the methods too Feb 03 12:43:48 and the id and the name too Feb 03 12:43:57 I don't see where Feb 03 12:44:19 the only duplicate field I see is the id Feb 03 12:44:29 https://github.com/txomon/ubus/blob/master/libubus.h#L91-L113 Feb 03 12:46:07 struct ubus_object_type *type is referenced from struct ubus_object, and at the same time, struct ubus_object has name, id, methods and n_methods fields Feb 03 12:46:41 maybe I am missing something? Feb 03 12:48:08 struct ubus_object_type is a template struct for user facing apis Feb 03 12:48:34 they can describe their object in it iirc while the struct ubus_object is an internal object instance Feb 03 12:49:38 struct ubus_object_type is usually statically declared in source code and then handed over to ubus for registration, see e.g. http://lxr.mein.io/source/luci2-ui/luci2/src/rpcd/luci2.c#L2791 Feb 03 12:50:10 jow_laptop: yeah, in my case it will be dynamic :/ all of it Feb 03 12:50:27 using the larger struct ubus_object would waste a lot of stack space for internal members which are not to be used by calling code anyway Feb 03 12:51:01 and the consumer would need to memset everything private to sanitize it (avl nodes or list heads with junk data cause segfaults) Feb 03 12:52:21 or maybe I'm wrong Feb 03 12:52:32 so, do the members of struct ubus_object and the members from struct ubus_object_type need to be the *same*? Feb 03 12:52:35 you could try asking nbd if he can shed light on it Feb 03 12:52:38 ok Feb 03 12:52:53 I suppose the idea is that you can have multiple ubus_object instances sharing the same interface Feb 03 12:53:06 like for example the network.interface.* namespaces Feb 03 12:53:10 oh, like in the network part Feb 03 12:53:23 yeah, all clear now then Feb 03 12:53:48 because I've just seen that ubus_object needs to be constructed by calling code as well Feb 03 12:53:53 so its not something internal Feb 03 12:54:22 yeah, was just about to ask that, as line 2794 in rcpd? Feb 03 12:55:46 so, you could register luci-rpc-luci2-system (the type) at other places tahn just "luci2.system" just by declaring an other ubus_object? Feb 03 12:56:21 yes Feb 03 12:56:37 iirc its done by netifd Feb 03 12:56:57 network.interface, network.interface.lan, network.interface.wan, ... all share the same type Feb 03 12:58:05 but that doesn't explain why they have references to the functions... I mean, an interface just needs to be a struct blobmsg_policy Feb 03 12:58:26 maybe because that way you could reuse in case you wanted? Feb 03 12:58:43 yes Feb 03 12:58:56 like the type doesn't take into account the pointer to function, and it could be null, but the object does Feb 03 12:59:09 ok Feb 03 13:02:17 when I finally understand all this I will document it Feb 03 13:02:30 but I really want to be sure it's all like that Feb 03 13:03:05 I suppose you can also publish an updated ubus object type and still have ubus objects alive providing the older interface Feb 03 13:03:16 therfore it probably makes sense to have a copy of the method table Feb 03 13:03:33 that soundsd like a usecase fraught with peril. Feb 03 13:07:44 it sounds like blackmagic to me hahaha but ok, for now I will concentrate on generating all the structures and probably read the code for that _type one and see how it's used... Feb 03 13:09:16 doh, no wonder I coudln't find it. jsonpath is renamed to jsonfilter in the package install.. Feb 03 13:20:58 I've got json doc like: https://pastee.org/vebxt and jsonfilter can get me the senml.e elements with -e '@.senml.e[0]' but is there a way to say, "get me the element where the .n field == xxx" ? Feb 03 13:23:18 ok -e '@.senml.e[@.n="karl"]' works, I just had the wrong quoting earlier. Feb 03 14:40:49 build #198 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/198 Feb 03 14:41:20 build #209 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/209 Feb 03 14:41:36 build #209 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/209 Feb 03 14:41:54 build #206 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/206 Feb 03 14:42:21 build #209 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/209 Feb 03 15:48:44 jow_laptop: does jsonpath/jsonfilter build for you? https://paste.fedoraproject.org/318021/51451814/ Feb 03 15:52:20 karlp: yes Feb 03 15:54:04 karlp: you want to build it for your host? Feb 03 15:54:27 yeah, I've got ubox already, Feb 03 15:55:07 have already tried fiddlign with the cmake to make it build in a build dir ok, that lemon parser thing is unfriendly to cmake's worldview, but can't figure out how to turn down warnings for a single file easilyt. Feb 03 15:56:06 http://paste.fedoraproject.org/318026/14545149/ fixes that actually. Feb 03 15:58:15 I got into a mess trying to make "lemon" a target with it's own deps and outputs because it keeps making the parser.c in the same directory as it finds the .y file :) Feb 03 15:58:40 it is supposed to do that Feb 03 15:59:11 yes, now try "mkdir build && cd build && cmake .. && make" Feb 03 16:07:43 fix pushed Feb 03 16:08:02 build #188 of brcm2708 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/188 Feb 03 16:44:05 thanks, awesome. Feb 03 16:44:20 what do you feel about me maybe pulling out a library for jsonpath to be used in other apps? Feb 03 16:44:47 your jsonpath was the first one I found in C :) Feb 03 16:51:12 build #176 of arm64 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/176 Feb 03 16:54:30 I could add a static library Feb 03 16:59:12 do you happen to know how "standard" that syntax is? Feb 03 17:05:12 its the simple subset of jsonpath with a few custom additions Feb 03 17:05:30 the more complex jsonpath standard elements require a javascript engine Feb 03 17:05:31 yeah, the -e xxx=stuff to make that "export xxx=..." Feb 03 17:06:36 http://goessner.net/articles/JsonPath/ Feb 03 17:06:43 scroll to that xpath vs. jsonpath table Feb 03 17:07:01 my tools upports $, @, [], * and the union operator Feb 03 17:07:28 plus the usual expression stuff (>, <, >=, <=, !=, =, &&, ||) Feb 03 17:08:11 string literals (also unicode \ufedc), number literals and the boolean true and false literals Feb 03 17:08:39 it does not support the recursive child search operator .. Feb 03 17:10:20 or the ?() and () epxressions [those would require a js engine] Feb 03 17:11:36 oh and I do not simulate properties like @.length in array context... could do that though Feb 03 17:11:51 but I do support [-1] iirc so its not really needed Feb 03 17:13:59 what do you think about http://paste.fedoraproject.org/318066/51958214/ or does it add too much size to the binary? Feb 03 17:14:41 I could alternatively maybe just print a "full help in https://wiki.openwrt.org/doc/techref/jsonfilter" ? Feb 03 17:15:07 a usage tesxt is fine Feb 03 17:15:34 instead of refering to a 3rd party blog I'd rather jsut give one or two medium complex examples plus a link to the wiki page Feb 03 17:16:17 yeah, I had some examples, but without including some json text it seemed hard to describe, or rather large after including sample json. Feb 03 17:17:27 something like # ifstatus lan | jsonfilter -e '@["ipv4-address"][0].address' Feb 03 17:18:19 and the other one: # ubus call system board | jsonfilter -e '@.release.description' Feb 03 17:18:21 ah, of course, there's internal json sources :) Feb 03 17:18:26 I'm using this on my own data :) Feb 03 17:21:31 build #175 of x86.kvm_guest is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/175 Feb 03 17:21:41 so -e '@.metric' works as is, is the ["ipv4-address"] just special quoting to get around the '-' character? Feb 03 17:22:01 yeah, ok, works the same for metric there too. Feb 03 17:22:02 yes Feb 03 17:24:48 build #169 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/169 Feb 03 17:27:10 better? http://paste.fedoraproject.org/318074/20408145/ Feb 03 17:30:59 karlp: yes Feb 03 17:36:05 build #190 of x86.xen_domu is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.xen_domu/builds/190 Feb 03 17:43:15 phew, just had a look at the "jq" project. it's a 1meg binary :) Feb 03 17:48:31 I hope you don't mind if I rewrite the usage a bit Feb 03 17:53:09 no problem Feb 03 17:53:16 just be nice to have some :) Feb 03 18:10:19 f Feb 03 18:15:00 karlp: pushed it Feb 03 18:19:51 build #205 of x86.64 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86.64/builds/205 Feb 03 19:14:15 build #173 of xburst is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/173 Feb 03 19:20:36 build #176 of x86 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/176 Feb 03 19:20:40 build #169 of kirkwood is complete: Failure [failed svn shell_15 compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/169 Feb 03 20:38:37 nbd: yay, my TD-8870 arrived and is indeed v1 Feb 03 20:38:51 We still need to open it up and attach a serial console, right? It does have the new firmware Feb 03 22:28:55 all, I'm trying to modify view/admin_status/index.htm and I've followed the developer guide to disable caching, so now I don't see any /tmp/luci* files. however, for some reason, I'm not seeing my changes take. do you have to restart uhttpd as well between changes? Feb 03 22:32:10 rmilecki r48625 trunk/target/linux/ (5 files in 3 dirs) * bcm53xx: start working on Netgear R8500 Feb 03 23:57:36 wigyori r48626 trunk/target/linux/sunxi/profiles/orangepi_plus.mk * sunxi: update orangepi-plus profile to reflect the real uboot package Feb 04 01:57:28 dwmw2_gone: yes, serial access is needed Feb 04 01:57:41 I just flashed one Feb 04 02:01:21 an 8970 anyway, damn numbers Feb 04 02:52:26 build #208 of oxnas is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/208 Feb 04 02:58:12 build #186 of netlogic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/186 **** ENDING LOGGING AT Thu Feb 04 02:59:59 2016