**** BEGIN LOGGING AT Mon Jul 06 02:59:59 2015 Jul 06 06:40:17 build #51 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/51 Jul 06 06:47:14 build #51 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/51 Jul 06 07:50:51 build #51 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/51 Jul 06 08:55:46 cyrus r46192 trunk/package/libs/uclibc++/Makefile * uclibc++: link libssp_nonshared only for musl Jul 06 09:42:12 build #51 of sunxi is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/51 Jul 06 10:15:33 _trine: should be now fixed Jul 06 10:19:09 nbd r46193 trunk/target/linux/ar71xx/image/Makefile * ar71xx: fix UAP-PRO images Jul 06 10:19:20 nbd r46194 trunk/package/kernel/mac80211/ patches/931-ath10k_add_ath10k_fw_ie_htt_op_version.patch patches/932-ath10k_bump_up_fw_api_to_5.patch patches/933-ath10k_fix_htt_op_backwards_compatibility_for_qca6174.patch * mac80211: Backport ath10k firmware API v5 support Jul 06 10:19:31 nbd r46195 trunk/package/kernel/mac80211/Makefile * mac80211: Update QCA9880 firmware to 10.2.4.70-2 Jul 06 10:19:40 nbd r46196 trunk/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k * ar71xx: update preinit script for new ath10k firmware Jul 06 10:21:43 nbd r46197 trunk/package/kernel/mac80211/Makefile * ath10k: remove support for the obsolete STA firmware Jul 06 10:30:10 hi guys! Jul 06 10:30:38 someone able to patch this ? https://dev.openwrt.org/ticket/18197#comment:4 Jul 06 13:53:33 build #53 of lantiq.xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/53 Jul 06 16:26:52 nbd r46198 trunk/package/kernel/ (180 files in 3 dirs) * mac80211: update to version 2015-06-22 Jul 06 16:30:02 nbd: will u care to push https://patchwork.ozlabs.org/patch/487028/ Jul 06 16:30:56 this looks awkward Jul 06 16:33:40 I think he tried 2 approaches and this was an approach suggested by jow_laptop Jul 06 16:35:12 cyrusff: would be nice to have you follow discussion or suggest better solution Jul 06 16:36:21 yeah seems i'm not very helpful ;) Jul 06 16:38:05 i'm annoyed by not having any reply/reaction & having John saying he'll push it soon (few times) Jul 06 16:38:17 well, just by being ignored Jul 06 16:39:36 I think John is with a lot of work and under pressure, but I agree he is a bit angry sometimes hehe Jul 06 16:43:09 who does the original setting? is that libc? Jul 06 16:45:03 nbd r46199 trunk/package/system/ubus/Makefile * ubus: update to the latest version, fixes a segfault on message retry Jul 06 17:09:55 cyrusff: sorry ,I don't understand the question Jul 06 17:10:16 do you mean the initial buffer setup? Jul 06 17:10:32 the decision line buf vs. size buf? Jul 06 17:10:34 i guess it's libc Jul 06 17:13:44 yeah, found it meanwhile Jul 06 17:27:46 nbd r46200 trunk/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch * ar71xx: fix kernel Oops in at803x_link_change_notify Jul 06 17:32:39 build #51 of octeon is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/51 Jul 06 17:40:18 rmilecki: i acknowledge there seems to be no better way really Jul 06 17:42:14 cyrusff: thanks for checking that for me (us) Jul 06 17:42:33 so let's make the patch itself a little less awkward Jul 06 17:42:54 sure, just tell me where it's awkard :) Jul 06 17:43:11 the whole strcat / strncat is unnecessarily verbose Jul 06 17:43:34 there's like 15 lines for what could be done in 3 or so Jul 06 17:44:27 ?? Jul 06 17:44:29 or well 5 or so Jul 06 17:44:33 how? Jul 06 17:47:49 if ((preload_seccomp || preload_setlbf) && asprintf(&ld_preload, "LD_PRELOAD=%s%s%s", ) > 0) putenv(ld_preload); Jul 06 17:47:51 or so Jul 06 17:48:01 fill in %s appropriately ;) Jul 06 17:50:26 hm, handling separators : will require checking the same thing twice Jul 06 17:50:30 but it still should be easier Jul 06 17:50:35 OK, I'll try that Jul 06 17:51:01 compiler will optimize that out anyway Jul 06 17:54:17 setenv("foo", "bar", 1) internally does malloc() copy "foo=bar" into buffer and then does putenv Jul 06 17:55:28 oh, i didn't know that Jul 06 17:55:30 thx Jul 06 17:58:29 i'm still having problems with the kvm_guest target Jul 06 18:01:16 rmilecki: another little question. shouldn't it apply to stderr (as well)? Jul 06 18:02:44 also we should look at if we want to conditionally enable it Jul 06 18:03:04 instead of applying it to all processes? Jul 06 18:03:53 cyrusff: several places in the internet claim that stderr is always line buffered or unbuffered by default; only stdin and out can be blockbuffered Jul 06 18:04:56 cyrusff: stderr is unbuffered by default Jul 06 18:04:59 doesn't my patch say that? Jul 06 18:05:38 it doesn't Jul 06 18:05:42 I can update commit message as well Jul 06 18:06:02 cyrusff: it's already conditional Jul 06 18:06:14 cyrusff: it's enabled by asking procd to do the logging Jul 06 18:06:16 build #51 of adm5120 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/51 Jul 06 18:06:18 logging stdout especially Jul 06 18:07:19 build #51 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/51 Jul 06 18:09:19 KanjiMonster: right seems to be unbuffered Jul 06 18:09:23 on musl Jul 06 18:09:51 cyrusff: same in uclibc Jul 06 18:09:53 i verified that Jul 06 18:09:56 that said rmilecki why are you logging on stdio and not stderr? Jul 06 18:10:11 stderr seems to be more natural choice Jul 06 18:10:37 cyrusff: for debugging purposes Jul 06 18:10:38 sometimes you just want to catch stdout stuff as well Jul 06 18:10:41 also some apps may print to stdout Jul 06 18:10:43 somethinguseful Jul 06 18:10:50 the needs depen on user / app Jul 06 18:12:18 hmm Jul 06 18:12:26 what do i need to set to enable procd logging? Jul 06 18:12:43 grep procd * -R | grep log Jul 06 18:12:50 doesn't really result in anything useful Jul 06 18:12:56 in the packages folder Jul 06 18:13:04 stdout Jul 06 18:13:49 procd_set_param stdout 1 Jul 06 18:13:52 ah Jul 06 18:14:10 as an option also procd_set_param stderr 1 Jul 06 18:14:28 wondering if nobuf would be better Jul 06 18:14:35 or not Jul 06 18:16:03 i don't think it makes sense to add another option disabling buffering Jul 06 18:16:06 ah well procd reads line based Jul 06 18:16:11 okay then Jul 06 18:16:14 i guess everyone expect logs to appear immediately Jul 06 18:16:53 yeah i'm just wondering because to me stdout is not the logical channel for either logging or (necessarily) line-buffered output Jul 06 18:17:06 but i guess this procd feature is specially designed to do that Jul 06 18:17:23 just wondering since stderr will be unbuf and stdout will be linebuffed then Jul 06 18:17:38 as for procd_set_param stderr vs stdio Jul 06 18:17:42 i tried unbuf, but smoeone suggested line buffering Jul 06 18:17:43 omg Jul 06 18:17:56 okay Jul 06 18:18:10 cyrusff: see https://patchwork.ozlabs.org/patch/486925/ Jul 06 18:18:13 its V1 Jul 06 18:18:44 yep Jul 06 18:19:34 old patch looked (bit) better to me to be honest :P Jul 06 18:20:17 anyway send me V3 and i will see that it can be applied Jul 06 18:20:19 well, i was OK with it too Jul 06 18:20:25 but this one guy objected Jul 06 18:20:33 and i didn't get any other comments about that of ocurse Jul 06 18:37:48 nbd: the new mac80211 package doesn't build for me: http://pastebin.com/JepEVucE Jul 06 18:38:14 hrm, might be missing a chunk Jul 06 18:38:18 sorry about that Jul 06 18:39:25 no problem, I only wanted to check if it builds now for 4.1, and this doesn't seem to be 4.1's fault ;) Jul 06 18:41:35 nbd r46201 trunk/package/kernel/mac80211/patches/600-0001-rt2x00-rt2800lib-move-rt2800_drv_data-declaration-in.patch * mac80211: add missing patch chunk Jul 06 18:41:40 KanjiMonster: fixed Jul 06 18:41:52 thanks Jul 06 18:55:17 nbd: you were one of 4 people or so committing to the kvm_guest target Jul 06 18:55:34 why is it -march 486? Jul 06 18:56:56 i never used it Jul 06 18:58:51 nbd: 486 just can't be correct for kvm and may be causing a problem Jul 06 18:59:50 the other committers were jow_laptop, juhosg, and blogic Jul 06 19:02:16 o/ Jul 06 19:02:16 the wireless regulatory db seems to be out of date, should I submit a patch updating it to the latest master-2015-06-05 version? Jul 06 19:05:41 nbd: is x86.kvm_guest assigned to someone? Jul 06 19:06:14 i don't think so Jul 06 19:07:46 nbd: were there even any kvm-capable processors that were 32-bit only? Jul 06 19:11:49 DonkeyHotei: i don't know much about kvm, so i'm really the wrong person to ask about it Jul 06 19:12:34 nbd: who should i talk to about fixing the target? Jul 06 19:12:40 no idea Jul 06 19:13:36 nbd, you seem to be listed as the maintainer of the mac80211 package, so my question above should probably have been directed to you Jul 06 19:13:47 iirc, there is a maintainers file in target dir Jul 06 19:17:30 ignisf: yes, feel free to submit a patch Jul 06 19:18:37 ignisf: please make sure you include the tweak that removes NO-IR from channel 36-48 in the world regd Jul 06 19:18:49 (r42882) Jul 06 19:19:21 thanks, will do Jul 06 19:36:31 nbd, why is this tweak needed and should it be submitted upstream? As far as I could find out, upstream has stated that passive scanning should be used with the world regd for any channel above 11 (see https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=3a01e34 ) Jul 06 19:37:11 has always stated* Jul 06 19:51:57 build #53 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/53 Jul 06 19:52:12 build #53 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/53 Jul 06 19:53:31 build #53 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/53 Jul 06 19:55:44 cyrusff: i'll have a patch to review in a moment if you are still around Jul 06 19:55:52 cyrusff: unfortunetely this asprintf isn't too clean neither Jul 06 19:57:23 ignisf: because since taiwan disallows using channels 36-48, there is no single 5 GHz channel in the world reg domain that allows AP mode, and many embedded devices are hardcoded to world Jul 06 19:58:25 ah, I see Jul 06 20:00:19 cyrusff: http://pastebin.com/k4fanzkH Jul 06 20:00:25 build #53 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/53 Jul 06 20:00:40 nbd: you're listed as maintainer of x86 Jul 06 20:00:50 yes Jul 06 20:01:42 i'm not seeing where that target specifies toolchain options such as -march Jul 06 20:10:48 build #53 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/53 Jul 06 20:12:27 nbd: is x86_64 also compiled with -march=i486? Jul 06 20:26:44 build #52 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/52 Jul 06 20:30:37 DonkeyHotei: it specifies a CPU_TYPE, and then the flags will set according to that in include/target.mk Jul 06 20:31:45 i will try a different CPU_TYPE for kvm Jul 06 20:32:50 the i386 target only knows the i486 and genode cpu types Jul 06 20:33:03 s/target/arch Jul 06 21:22:47 so, the sysfs GPIO devices belong to root:root. is there any problem with changing group ownership (in the kernel module code) to some group that I can add a service user to? Jul 06 21:23:23 for example, on a raspberry pi, the sysfs devices belong to the `gpio` group instead of `root` Jul 06 21:31:31 hauke r46202 trunk/package/kernel/mac80211/patches/004-backports_debugfs_fix.patch * mac80211: remove useless patch Jul 06 21:31:58 hauke r46203 trunk/package/kernel/mac80211/patches/008-fix_netdev_unregister.patch * mac80211: remove useless patch Jul 06 21:32:34 hauke r46204 trunk/package/kernel/mac80211/Makefile * mac80211: add kernel 4.1 support again Jul 06 21:44:05 hauke r46205 trunk/package/kernel/mac80211/patches/910-01-add-support-for-mt7620.patch * mac80211: fix compile warning in rt2800lib.c Jul 06 22:07:53 yeah people are alive here! **** ENDING LOGGING AT Tue Jul 07 02:59:58 2015