**** BEGIN LOGGING AT Tue Nov 03 02:59:58 2015 Nov 03 03:59:09 build #133 of bcm53xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/133 Nov 03 04:16:39 build #133 of brcm47xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/133 Nov 03 04:57:36 build #132 of ramips.mt7628 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/132 Nov 03 06:55:04 build #130 of imx6 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/130 Nov 03 07:30:12 build #133 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/133 Nov 03 08:17:19 build #137 of ramips is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/137 Nov 03 10:11:05 build #132 of malta is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/132 Nov 03 10:29:54 build #134 of brcm47xx is complete: Failure [failed compile_2] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/134 Nov 03 11:09:21 kaloz r47365 trunk/package/boot/uboot-envtools/files/mvebu * uboot: create the uboot config file for the shelby as well Nov 03 11:10:42 kaloz r47366 branches/chaos_calmer/package/boot/uboot-envtools/files/mvebu * uboot: create the uboot config file for the shelby as well Nov 03 11:28:42 build #132 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/132 Nov 03 11:32:10 build #132 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/132 Nov 03 11:36:09 build #132 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/132 Nov 03 12:00:58 nbd r47367 trunk/package/network/services/lldpd/files/lldpd.init * lldpd: implement a reload hook Nov 03 12:01:24 nbd r47368 trunk/tools/mpc/Makefile * tools/mpc: update to 1.0.3 Nov 03 12:01:38 nbd r47369 trunk/tools/ mpfr/patches/001-only_src.patch mpfr/Makefile * tools/mpfr: update to 3.1.3 Nov 03 12:01:52 nbd r47370 trunk/tools/ bison/patches/100-fix-gets-removal.patch bison/Makefile * tools/bison: update to 3.0.4 Nov 03 12:02:25 nbd r47371 trunk/package/kernel/mac80211/patches/002-change_allconfig.patch Nov 03 12:02:25 mac80211: fix kconf handling of allnoconfig, fixes spurious brcmfmac related build errors Nov 03 12:02:43 nbd r47372 trunk/scripts/config/confdata.c * scripts/config: fix handling of CONFDEFAULT on oldconfig Nov 03 13:33:51 blogic r47373 trunk/target/linux/ ramips/base-files/lib/upgrade/platform.sh ramips/base-files/etc/diag.sh * ramips: add feature to blink led on sysupgrade Nov 03 13:34:44 blogic r47374 branches/chaos_calmer/ target/linux/ramips/base-files/etc/diag.sh target/linux/ramips/base-files/lib/upgrade/platform.sh * ramips: add feature to blink led on sysupgrade Nov 03 14:12:19 build #130 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/130 Nov 03 14:15:23 we can haz valid ssl on the wiki Nov 03 14:15:24 \o/ Nov 03 14:16:35 and there was much rejoicing... Nov 03 14:19:11 great stuff Nov 03 14:22:37 .. finally ;) Nov 03 14:23:34 the issuer... startcom... do they provide free certs or did you handle it in the end? Nov 03 14:23:42 *or how Nov 03 14:33:53 jow_laptop: free certs, tho time limited for a year (used to be 3 months ..), hence all cool so far Nov 03 14:34:04 and hopefully letsencrypt is there sooner! Nov 03 14:39:43 the duke nukem of ssl Nov 03 14:39:48 :) **** BEGIN LOGGING AT Tue Nov 03 14:50:40 2015 Nov 03 14:55:13 I know a few people who are in the letsencrypt beta, and it definitely is actually a thing. Nov 03 14:55:13 apparently letsencrypt wants to go live on Nov 16 Nov 03 14:55:13 or some time around that day Nov 03 14:55:14 okay, cool Nov 03 14:55:14 was just tongue in cheek :) whenever I heard about it it was about it not ready yet Nov 03 14:58:31 git sign off is just a line at the end of the commit, yes? https://github.com/saik0/luci/commit/5541065793913f8bf201123440e4a827ec779ebd Nov 03 15:00:05 saik0: yes. You can autogenerate it by passing the "-s" (or long "--signoff") flag to "git commit" Nov 03 15:00:18 saik0: or retroactively by using "git commit --amend -s" Nov 03 15:05:32 build #111 of ar71xx.mikrotik is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/111 Nov 03 15:06:30 saik0: and another tip, you can amend your commit and use git push --force to the branch you used for the already open pr - this will update the pr accordingly Nov 03 15:06:54 saik0: however it iwll not automatically change the description text of the pr (which is initially copied from the first commit message) Nov 03 15:07:14 jow_laptop: I try to avoid rewriting history Nov 03 15:07:40 Even though nobody was downstream of this branch Nov 03 15:07:44 well as long as stuff is not merged and the branch solely contains feature cmmits then it is acceptable - imho Nov 03 15:08:24 anyhow, closing and reopening wors too, as long as it doesn't take like 30 attempts :) Nov 03 15:09:11 I'll keep it in mind for future contribs :) Nov 03 15:37:07 can anyone confirm the BLOBMSG_TYPE_INT16/32 thing? I am going to document that part now Nov 03 15:45:42 txomon: the ubus cli does not query the interface Nov 03 15:45:51 you should avoid int16 if you want cli/json compatibility Nov 03 15:46:00 nbd: ok, perfect! Nov 03 15:46:13 I am starting with blob.h Nov 03 15:46:19 will move to blobmsg later Nov 03 15:48:16 nbd: but if I call with ubus cli, the handler could virtually parse a 16 or a 32, no? or does the policy not pass invalid datatypes_ Nov 03 15:48:18 ? Nov 03 15:48:43 build #112 of ath25 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ath25/builds/112 Nov 03 15:48:57 meaning if policy defines 16, and it receives 32, would I be able to read those 16? Nov 03 15:49:03 why do you want to use 16 bit data types? Nov 03 15:49:13 and why do you want to use blob only to move to blobmsg later? Nov 03 15:49:59 nbd: no no, I meant that I am documenting blob.h now, and will move to blobmsg later. on my program I'm using ubus, so blobmsg directly Nov 03 15:50:43 16bit datatypes because the interface doesn't allow more. I am controlling stuff using 16bit binary datatypes, so 32 one would be trimmed anyway Nov 03 15:51:10 I thought ubus would complain about receiving a huge number on a int16, etc. Nov 03 15:51:58 that way I could rely on ubus doing for me the data dimension checks Nov 03 16:18:42 build #110 of mpc85xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/110 Nov 03 16:51:57 build #124 of netlogic is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/124 Nov 03 16:59:48 build #130 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/130 **** BEGIN LOGGING AT Tue Nov 03 17:27:42 2015 Nov 03 17:29:57 nbd: would it be interesting to have such checks from ubus cli/jsonmsg/uhttpd-mod-ubus? Checks/datatype compliance Nov 03 17:32:18 so far the idea is that ubus handlers check their input and return invalid argument when it does not fit Nov 03 17:33:15 most handlers utilize *_parse() with a policy, then check if the resultting attr array contains all wanted fields (which it will not if a passed field does not satisfy the datatype specified in the policy) Nov 03 17:33:24 jow_laptop: but what are policies for? Nov 03 17:33:32 I mean, you have to register them Nov 03 17:34:06 I guess to provide a certain amount of reflection capabilities to the api, so that a client can infer types from the method signature Nov 03 17:34:08 if doesn't make sense to register a policy in ubus if the cb will have to do it on it's onwn Nov 03 17:34:37 well you still have to check semantic validity, e.g. if field foo is given then also bar and baz must be provided, else not Nov 03 17:35:10 jow_laptop: so, currently providing any out of string, int8, int32 breaks that reflection capability... Nov 03 17:35:28 so far the the policy was most useful to me to infer required attributes for procedures without reading the C code Nov 03 17:35:31 I was just asking to know how much does it worth to work on that part Nov 03 17:35:45 so more a user hint thing Nov 03 17:36:05 jow_laptop: but int16, int64, and others are set to be 'unspecified' Nov 03 17:36:16 in the policy? Nov 03 17:36:34 if you have a policy with int16, it will appear as unspecified Nov 03 17:36:46 I see. I guess because there's no appropriate mapping to JSON Nov 03 17:37:28 in another system I used integer literals to denote the field type, e.g. 8 = int8, 16 = int16, 32 = int32, 64 = int64 Nov 03 17:37:52 jow_laptop: indeed, if we wanted to create proper support, we should be doing reflection on the datatypes provided, and give an error if provided value doesn't fit etc. Nov 03 17:38:24 and the boolean "true" literal to denote a bool, idea was that a consumer can call typeof() on the thing and get a somewhat meaningful type Nov 03 17:38:25 meaning, when a call is issued to X, we check that provided data fits into the interface Nov 03 17:39:08 jow_laptop: boolean is tricky thing because any int8 will be treated as boolean Nov 03 17:39:27 so in the json literal you could describe a signature like: { "bool": true, "int8": 8, "int16": 16, ..., "string": "", "array": [], "object": {} } Nov 03 17:39:35 IIRC (was reading code really late yesterday) Nov 03 17:39:52 yeah right, int8 should be considered equivalent to bool Nov 03 17:40:04 jow_laptop: I don't think it should... Nov 03 17:40:13 I mean, even if we store it like that, user should never know Nov 03 17:40:42 I am mostly doing all my work to be ubus compliant so that I can ship programs that I know will have a json rpc interface automatically Nov 03 17:41:03 maybe I'm biased. I mostly consume ubus from JS and that limits me to signed int32 more or less Nov 03 17:41:34 I don't mind raising errors on overflows, but looking at the precision and quality of the code, I found strange that there weren't checks... Nov 03 17:42:16 I mean, if you provide a string instead of a number, it will complain, but providing a number bigger than the interface won't Nov 03 17:42:26 maybe nbd can shed some light on the actul purpose of method policies Nov 03 17:43:26 if you go down that route you need to differentiate between unsigned and signed as well Nov 03 17:49:13 build #124 of ar71xx.nand is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/124 Nov 03 17:50:36 txomon: in principle I agree that method signatures could be leveraged to let the ubus framework preprocess the data, maybe even pass an already parsed attr array to the method handler, would reduce quite some boiler plate code Nov 03 17:51:17 but it should still be possible for handlers to receive and handle free-formed data, but I guess this is easily achieved by passing them the original messgae payload as wel Nov 03 17:56:08 build #118 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/118 Nov 03 17:58:08 build #119 of ar7 is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/119 Nov 03 19:19:49 jow_laptop: Are luci modules responsible for building the controller entires for apps? Nov 03 19:20:55 oh i see, the apps are married to the modules. Nevemrind. Nov 03 20:54:10 Hi, does anyone know why NDP is not skipped by the IP stack for EUI-64 addresses (since the mac is included in the address) Nov 03 21:02:17 because NDP is useful :) Nov 03 21:02:26 and that would be a severe layering violation Nov 03 21:03:06 hehe Nov 03 21:44:18 build #134 of brcm47xx.legacy is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/134 Nov 03 22:10:25 build #111 of mvebu is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/111 Nov 03 22:39:56 build #111 of adm8668 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/111 Nov 03 23:17:44 jow_laptop: IMO we should need to know how people is using it, to see how they are doing... Nov 03 23:19:43 or at least study the use cases within trunk Nov 03 23:20:12 I mean, what is the point of having different datatypes if you are finally not able to expose them? Nov 03 23:20:35 (expose them through all the interfaces? Nov 03 23:20:49 s,?,), Nov 03 23:26:36 jow_laptop: about the parsed attr I don't agree because the current design lets you have the same handler for different calls, so you should be able to receive different policies Nov 03 23:27:26 but a policy is a policy, else, it would just be something cumbersome that generates noise or that just generates docs on how to use the interface (in theory, because you can really receive X and read Y) Nov 03 23:31:33 also, another thing that came to my mind was to increase the power of a policy by being able to mark stuff as required/optional Nov 03 23:32:25 Every change I have thought around this has good things and drawbacks, and don't really know which is the opinion of the ones that develop with ubu Nov 03 23:32:30 ubus* Nov 04 00:11:45 build #109 of mcs814x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/109 Nov 04 01:02:09 build #134 of bcm53xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/134 Nov 04 01:49:40 build #133 of brcm63xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/133 Nov 04 01:56:45 build #133 of ramips.mt7621 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/133 Nov 04 02:00:00 build #107 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/107 Nov 04 02:22:04 build #134 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/134 **** ENDING LOGGING AT Wed Nov 04 02:59:58 2015