**** BEGIN LOGGING AT Tue Jan 12 02:59:59 2016 Jan 12 07:52:31 jow r48208 trunk/package/libs/ gettext-full/patches/000-relocatable.patch gettext-full/Makefile * gettext-full: make autopoint and gettextize reloctable Jan 12 07:54:54 jow r48209 branches/chaos_calmer/ (7 files in 2 dirs) * CC: gettext-full: update to version 0.19.6 Jan 12 07:54:57 jow r48210 branches/chaos_calmer/ package/libs/gettext-full/patches/130-format-secuirty.patch package/libs/gettext-full/Makefile * CC: gettext-full: activate format-security checks Jan 12 07:55:00 jow r48211 branches/chaos_calmer/ package/libs/gettext-full/patches/000-relocatable.patch package/libs/gettext-full/Makefile * CC: gettext-full: make autopoint and gettextize reloctable Jan 12 09:26:22 jow r48212 trunk/target/sdk/Makefile * sdk: add base repository fallback Jan 12 09:28:06 jow r48213 branches/chaos_calmer/target/sdk/Makefile * CC: sdk: add base repository fallback Jan 12 10:04:26 jow r48214 trunk/package/ network/services/dnsmasq/files/dnsmasq.init network/services/dnsmasq/Makefile * dnsmasq: add local hostname record for own lan ula address as well Jan 12 10:05:22 nbd r48215 trunk/target/linux/generic/config-4.4 * kernel: add missing symbols for linux 4.4 Jan 12 10:05:31 nbd r48216 trunk/target/linux/ (12 files in 7 dirs) * x86: update to linux 4.4 Jan 12 10:08:54 nbd r48217 trunk/target/linux/pxa * pxa: moved to targets feed Jan 12 10:19:36 ah nice, x86 -> 4.4, I had just built and x86 image with 4.4 :) Jan 12 10:19:42 but perf seems totally broken Jan 12 10:19:59 (it didn't compile for x86/64 with 3.18 either) Jan 12 10:20:21 hm, didn't try perf with it yet Jan 12 10:20:44 will try building that now Jan 12 10:22:55 I have disabled it for now. want to get my apu2b4 board up and running to do some tests :) Jan 12 11:16:10 nbd r48218 trunk/package/devel/perf/musl-compat.h * perf: fix build errors on x86 and other platforms Jan 12 11:16:29 stintel: ^^ Jan 12 11:34:18 nbd: cheers Jan 12 13:19:59 i sent a v2 of the big config-4.4 cleanup - boot tested on x86_64 VM and no issues there Jan 12 14:28:48 kaloz r48219 trunk/package/kernel/mac80211/files/regdb.txt * mac80211: resync regulatory db with master-2015-12-14 Jan 12 14:29:54 kaloz r48220 branches/chaos_calmer/package/kernel/mac80211/files/regdb.txt * mac80211: resync regulatory db with master-2015-12-14 Jan 12 15:45:18 hi openwrt-dev! my question this time is about binary data in blobmsg ... Jan 12 15:45:19 can Jan 12 15:45:25 't seem to find an example ... Jan 12 15:46:11 I want to pass a few KB over ubus, it seems blobmsg_add_field() can do that, but how do I get the data back? Jan 12 15:46:27 or maybe just pass base64-encoded data as string? Jan 12 15:55:15 okay, base64 string it is then ... Jan 12 15:55:22 xxcn: you fetch the blob_attr and extract the data within it using blobmsg_data() Jan 12 15:55:42 there are various ways to get to the blob_attr pointers Jan 12 15:56:22 one is blobmsg_for_each_attr(struct blob_attr *cur, struct blob_attr *buf, int rem) Jan 12 15:56:34 to simply iterate all members of a blobmsg Jan 12 15:57:20 okay, thanks! being new to all those APIs I just looked at the server/client ubus example and followed the approach there Jan 12 15:57:21 another way is using blobmsg_parse() to fill an array of struct blob_attr pointers using a policy Jan 12 15:57:32 so I do a blobmsg_parse() to populate a table of pointers Jan 12 15:58:06 right, then just do char * binary_data = blobmsg_data(table_of_pointers[MY_FIELD]); Jan 12 15:58:18 so blobmsg_data(tb[MYCALL_BINDATA]) Jan 12 15:58:23 you type faster :) Jan 12 15:58:28 what about the length? Jan 12 15:58:40 and int len = blobmsg_data_len(tb[MYCALL_BINDATA]); Jan 12 15:58:49 thank you, jow_laptop! Jan 12 16:00:15 and ... there won't be a way to call this method using the command line tool then? Jan 12 16:00:27 no way to encode raw binary data in json I think ... Jan 12 16:00:38 you can try Jan 12 16:01:08 ubus call myobj myfunc '{ "field": "\u0000\u0003\u0020..." }' Jan 12 16:14:04 xxcn: last byte needs to be a null-byte though Jan 12 16:14:19 (to make it pass the string validation rules) Jan 12 16:14:19 yeah, the first null byte will terminate the string Jan 12 16:14:34 you can add data that includes a null-byte Jan 12 16:14:36 since the length is stored Jan 12 16:14:53 as long as you use blobmsg_data_len to identify the length Jan 12 16:15:08 however, you still need to add that one extra null-byte at the end Jan 12 16:15:19 understood Jan 12 16:15:53 but I'm starting to think a base64 encoded string is a cleaner approach Jan 12 16:16:11 I'll do some more experiments and fiddle with this Jan 12 16:16:20 nbd: fyi, now running into a different problem with perf: http://pastebin.com/fFkshRwX Jan 12 16:17:54 DD is slated to release with a 4.4 kernel right? Jan 12 16:19:40 afaik yes Jan 12 16:19:45 yes Jan 12 16:19:50 stintel: will look into it Jan 12 16:20:10 xxcn: yeah, as long as it's not performance critical, the base64 approach makes sense Jan 12 16:42:48 nbd r48221 trunk/package/devel/perf/ musl-include Makefile musl-compat.h musl-include/string.h Jan 12 16:42:48 perf: fix strerror_r override detection, apparently part of tools/ relies on non-GNU behavior Jan 12 16:42:51 stintel: ^^ Jan 12 16:43:05 the use of strerror_r is really stupid and inconsistent Jan 12 16:43:23 part of the code wants the hackish GNU version, part of the code wants the standard version Jan 12 16:51:40 nbd, a null byte on the command line terminates the string data, the receiver gets it truncated Jan 12 16:52:28 not only you need an extra null at the end, you cannot pass null bytes in the data with the ubus cli Jan 12 16:52:38 I think ... Jan 12 17:04:30 xxcn: yes, you can't pass it via the cli, but you can pass it via a c client Jan 12 19:30:16 Hmm, looks like sch_hfsc.c is buggered on 4.4 for x86_64. If QoS is enabled and I try to upload anything, the kernel starts repeatedly WARN_ON()ing from sch_hfsc.c:1429. Jan 12 19:30:32 This consumes the entire CPU and effectively halts the router. Jan 12 20:51:18 hauke r48222 trunk/target/linux/ (44 files in 7 dirs) * kernel: refresh patches for kernel 4.4 Jan 12 20:52:10 hauke r48223 trunk/ (19 files in 9 dirs) * kernel/4.1: update to version 4.1.15 Jan 12 20:52:55 hauke r48224 trunk/ (39 files in 7 dirs) * kernel/4.3: update to version 4.3.3 Jan 12 20:53:40 hauke r48225 trunk/ (18 files in 3 dirs) * kernel/3.18: update to version 3.18.25 Jan 12 21:11:34 mamarley: please show me /etc/config/qos and the output of qos-stat Jan 12 21:12:36 nbd: One sec... Jan 12 21:16:42 actually, never mind Jan 12 21:16:51 it seems to be a relatively old bug Jan 12 21:16:59 that was introduced after 3.18, but long before 4.4 Jan 12 21:17:04 i might have an idea on how to fix it Jan 12 21:17:11 can you test a kernel patch for me? Jan 12 21:17:31 Sorry, I was trying to figure out how to dump the qos-stat output from this VM. Sure! I am building myself anyway, so testing a kernel patch is easy. Jan 12 21:20:39 mamarley: http://nbd.name/hfsc-test.patch Jan 12 21:20:45 you can just apply it directly to the kernel tree in build_dir Jan 12 21:20:49 then you don't have to run target/linux/clean Jan 12 21:28:03 actually, i probably misunderstood the issue Jan 12 21:28:12 you can revert that patch, the problem is probably in fq_codel, not hfsc Jan 12 21:28:26 will make a new one Jan 12 21:43:36 what have I nto "cleaned" appropriately for "dd: failed to open '/home/karlp/src/openwrt-trunk/build_dir/target-mipsel_24kec+dsp_musl-1.1.11/linux-ramips_mt7620/root.ubifs': No such file or directory" Jan 12 21:43:44 do I need a whole "make dirclean" now? Jan 12 21:46:48 nbd: OK, thanks! Jan 12 21:51:28 mamarley: hm, i can't seem to figure this one out at the moment. i think you should report it to the linux netdev list Jan 12 22:20:03 ok, just had to run make clean a few more times, must hav ebeen a -j thing :) **** ENDING LOGGING AT Wed Jan 13 02:59:59 2016