**** BEGIN LOGGING AT Mon Nov 02 02:59:59 2015
Nov 02 03:16:55 <builder> build #136 of ramips is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/136
Nov 02 04:12:38 <builder> build #110 of mvebu is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/110
Nov 02 04:15:48 <builder> build #106 of mpc52xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/106
Nov 02 04:20:52 <builder> build #132 of brcm47xx.legacy is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/132
Nov 02 05:29:12 <russell--> hmm. timezone weirdness. recent build using PST8PDT still showing daylight time today (should have transitioned this morning)
Nov 02 05:31:01 <DonkeyHotei> 	option timezone 'PST8PDT,M3.2.0,M11.1.0'
Nov 02 05:31:14 <DonkeyHotei> that's what i have
Nov 02 05:31:33 <DonkeyHotei> root@OpenWrt:~# date
Nov 02 05:31:33 <DonkeyHotei> Sun Nov  1 21:31:22 PST 2015
Nov 02 05:32:56 <russell--> option timezone 'PST8PDT'
Nov 02 05:32:59 <DonkeyHotei>  DESIGNATED DRIVER (Bleeding Edge, r47278)
Nov 02 05:34:12 <russell--> r47306
Nov 02 05:35:49 <builder> build #131 of ramips.mt7628 is complete: Failure [failed shell_4]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/131
Nov 02 05:37:23 <DonkeyHotei> 'PST8PDT' by itself doesn't say much
Nov 02 05:37:45 <russell--> it's always said enough before
Nov 02 05:38:14 <russell--> the previous build from 2014 had done the transition correctly
Nov 02 05:38:27 <DonkeyHotei> i had to use the above to get it to work ages ago and kept it
Nov 02 05:38:28 <russell--> maybe a uClibc vs musl difference
Nov 02 05:48:51 <russell--> weird, there are no zoneinfo files in the running image afaict
Nov 02 05:49:12 <russell--> so how does it even know what PST8PDT means?
Nov 02 05:49:32 <DonkeyHotei> as i said
Nov 02 05:49:56 <DonkeyHotei> after all, zoneinfo was never there by default
Nov 02 05:52:05 <jow_laptop> russell--: glibc does not transition either with your zonespec
Nov 02 05:52:17 <jow_laptop> russell--: its knows what it means due to the rules (PST8PDT,M3.2.0,M11.1.0)
Nov 02 05:53:06 <russell--> CHAOS CALMER (Bleeding Edge, r45513) works
Nov 02 05:53:10 <jow_laptop> means transition to PDT on sunday of 2nd week in march and transition to PST on sunday of 1st week of november
Nov 02 05:53:48 <DonkeyHotei> he's in my timezone so i responded
Nov 02 05:53:59 <russell--> # date
Nov 02 05:54:00 <russell--> Sun Nov  1 21:53:46 PST 2015
Nov 02 05:54:07 <jow_laptop> if the alternative tz does not specifiy an offset its assumed to be one hour ahead in stadnard time
Nov 02 05:54:37 <russell--> # uname -a
Nov 02 05:54:38 <russell--> Linux zane 3.18.11 #2 Mon Apr 20 22:07:40 PDT 2015 mips GNU/Linux
Nov 02 05:55:03 <russell--> that's on uclibc
Nov 02 05:55:34 <russell--> and that's made the transition correctly
Nov 02 05:56:24 <russell--> also just has option timezone 'PST8PDT'
Nov 02 05:56:40 <jow_laptop> that will not work without installed zoneinfo
Nov 02 05:56:58 <russell--> and yet, it does work in the april image
Nov 02 05:57:59 <russell--> no /etc/zoneinfo or /usr/share/zoneinfo
Nov 02 05:58:33 <russell--> so, i'm curious where/how it resolves it correctly
Nov 02 06:00:12 <jow_laptop> glibc appears to get it wrong as well
Nov 02 06:02:51 <jow_laptop> russell--: so PST should be effective now?
Nov 02 06:02:58 <russell--> CHAOS CALMER (Bleeding Edge, r45513) gets it right with plain PST8PDT
Nov 02 06:03:07 <russell--> yes
Nov 02 06:03:58 <jow_laptop> I do believe you that it gets it right but I do not see how
Nov 02 06:04:45 <jow_laptop> uclibc is not able to understand zoneinfo (so even if installed it would have no effect) but it also has no builtin ruleset for timezones, afaik it solely relies on the tz spec
Nov 02 06:05:18 <russell--> i can say that i've been using PST8PDT for years, successfully
Nov 02 06:05:49 <russell--> hence my surprise
Nov 02 06:06:00 <DonkeyHotei> i tried it years ago and it did not work
Nov 02 06:09:17 <jow_laptop> russell--: apparently uclibc has code for zoneinfo and /etc/localtime
Nov 02 06:09:28 <jow_laptop> russell--: not sure if it is enabled by default though
Nov 02 06:10:15 <jow_laptop> russell--: is there an /etc/TZ on your system?
Nov 02 06:12:23 <russell--> jow_laptop: on the working one:
Nov 02 06:12:25 <russell--> root@zane:/# cat /etc/TZ
Nov 02 06:12:27 <russell--> PST8PDT
Nov 02 06:13:00 <russell--> on the non-working one, same thing
Nov 02 06:13:17 <jow_laptop> PST is the standard time and PDT the daylight savings one?
Nov 02 06:13:34 <russell--> yes
Nov 02 06:16:54 <DonkeyHotei> S for standard, D for daylight
Nov 02 06:17:20 <jow_laptop> yeah, was just wondering because in europe the S stands for "Summer time"
Nov 02 06:17:24 <jow_laptop> CEST vs. CET
Nov 02 06:17:27 <russell--> right
Nov 02 06:17:37 <russell--> that had me confused once-upon-a-time
Nov 02 06:18:26 <Fishman> which would make more sense, since the US is in standard time only about 1/3 of the year.
Nov 02 06:18:46 <russell--> lol
Nov 02 06:19:22 <Fishman> well, it's true.  and silly.  -.-
Nov 02 06:19:44 <jow_laptop> russell--: following observation on musl:
Nov 02 06:20:14 <DonkeyHotei> it would be nice if at least one presidential candidate in the debates wanted to abolish daylight time, but nooooo
Nov 02 06:20:42 <jow_laptop> russell--: a short zonespec (TZ=PST8PDT) will cause it to be stuck in alternative time forever, it also does not attempt to lookup /usr/share/zoneinfo/PST8PDT is present
Nov 02 06:21:09 <russell--> ah, nice!
Nov 02 06:21:14 <russell--> so, mystery solved
Nov 02 06:21:25 <jow_laptop> russell--: the fully qualified zone (TZ=PST8PDT,M3.2.0,M11.1.0) will cause it switch correctly
Nov 02 06:21:58 <jow_laptop> russell--: as does specifying TZ=/usr/share/zoneinfo/PST8PDT)
Nov 02 06:22:32 <jow_laptop> russell--: I guess that  rm /etc/TZ & ln -s /usr/share/zoneinfo/PST8PDT /etc/localtime  would work correctly as well
Nov 02 06:23:11 <jow_laptop> russell--: openwrt is still stuck in the tz semantics due to backwards compat with uclibc, we specifically patched musl to read its tz spec from /etc/TZ and I guess it simply takes precedence over any zoneinfo rules
Nov 02 06:24:49 <russell--> jow_laptop: thanks for investigating!
Nov 02 06:27:03 <jow_laptop> too bad that the zoneinfo stuff is so huge
Nov 02 06:27:12 <jow_laptop> ~250K for zoneinfo-core
Nov 02 06:27:35 <jow_laptop> not sure if historic data is already stripped
Nov 02 06:27:48 <DonkeyHotei> luci just does it for you
Nov 02 06:28:01 <builder> build #130 of ramips.rt3883 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/130
Nov 02 08:57:00 <phaidros> Kaloz: ping
Nov 02 10:18:18 <OpenWrt-Commits> blogic r47338 trunk/ package/devel/perf/Makefile target/linux/generic/patches-4.1/222-perf-build-Do-not-fail-on-missing-Build-file.patch * package/devel/perf: fix build for kernel 4.1
Nov 02 10:18:28 <OpenWrt-Commits> blogic r47339 trunk/toolchain/musl/patches/020-upstream_open_memstream.patch * musl: add upstream patch for open_[w]memstream
Nov 02 10:18:37 <OpenWrt-Commits> blogic r47340 trunk/target/linux/ramips/rt305x/config-3.18 * ramips: rt305x: update kernel config symbols
Nov 02 10:18:45 <OpenWrt-Commits> blogic r47341 trunk/target/linux/ramips/rt305x/config-3.18 * ramips: rt305x: enable seama mtdsplit parser
Nov 02 10:18:52 <OpenWrt-Commits> blogic r47342 trunk/scripts/checkpatch.pl * scripts/checkpatch.pl: Fix deprecation warnings
Nov 02 10:18:58 <OpenWrt-Commits> blogic r47343 trunk/target/linux/omap/profiles/beagleboard.mk * omap/Beagleboard: remove FEATURES override
Nov 02 10:19:05 <OpenWrt-Commits> blogic r47344 trunk/target/linux/ar71xx/image/Makefile * ar71xx: Add support for wdr7500v3
Nov 02 10:19:14 <OpenWrt-Commits> blogic r47345 trunk/target/linux/ramips/base-files/etc/board.d/02_network * ramips: add support for the Asus RP-N53 in the "02_network" boot script
Nov 02 10:19:23 <OpenWrt-Commits> blogic r47346 trunk/target/linux/ramips/mt7620/config-3.18 * ramips: mt7620 add icplus phy driver kernel config symbol
Nov 02 10:19:29 <OpenWrt-Commits> blogic r47347 trunk/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom * ramips: add function to change rt2x00 wifi eeprom mac
Nov 02 10:19:39 <OpenWrt-Commits> blogic r47348 trunk/target/linux/ (8 files in 7 dirs) * ramips: add support for Dovado tiny AC
Nov 02 10:19:51 <OpenWrt-Commits> blogic r47349 trunk/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips * ramips: preinit: use iproute2 instead of vconfig
Nov 02 10:19:57 <OpenWrt-Commits> blogic r47350 trunk/target/linux/ramips/dts/RP-N53.dts * ramips: add eeprom mtd partition to the Asus RP-N53 dts
Nov 02 10:20:07 <OpenWrt-Commits> blogic r47351 trunk/target/linux/ (7 files in 7 dirs) * ramips: add support for ZBT WG2626
Nov 02 10:20:12 <OpenWrt-Commits> blogic r47352 trunk/package/boot/uboot-lantiq/patches/0043-MIPS-add-board-support-for-Arcadyan-VGV7510KW22.patch * uboot-lantiq: Add SoC version 1.2 support for Arcadyan VGV7510KW22
Nov 02 10:20:17 <OpenWrt-Commits> blogic r47353 trunk/package/system/fstools/Makefile * fstools: update to latest git HEAD
Nov 02 10:20:38 <OpenWrt-Commits> blogic r47354 trunk/target/linux/ (92 files in 9 dirs) * mediatek: add support for the new MT7623 Arm SoC
Nov 02 10:29:28 <karlp> is there a nice built in way of getting verbose output from cmake package builds?  make package/blah/{clean,compile} V=s doesn't turn on VERBOSE to the cmaek build by default?
Nov 02 10:34:37 <karlp> ah, make ... V=sc
Nov 02 10:34:39 <karlp> very magical
Nov 02 10:35:09 <karlp> is there any particular reason to use yet another letter that must be _with_ s to get that?
Nov 02 10:50:52 <plntyk> karlp: afaik this is documented in the change set where its introduced
Nov 02 10:52:40 <karlp> yeah, I found it in the wiki
Nov 02 10:52:54 <karlp> but c actually always needs to be with s,
Nov 02 10:53:01 <karlp> make V=c doesn't work.
Nov 02 10:55:35 <plntyk> hm... so either my doc/changeset description is buggy or it was changed again later
Nov 02 11:01:12 <karlp> nvm, it's a minor edge.  just one of those things.
Nov 02 11:01:50 <karlp> sometimes you just want the "all" flag, instead of having to go and find what letters you need to add to get more
Nov 02 11:34:33 <jow_laptop> karlp: I always memorize it as (s)tatus and (c)ommands
Nov 02 11:35:06 <KanjiMonster> karlp: I guess you need to enable (s)tdout to see the (c)ommands - IIRC the c was originally to switch between linux' default compile output of "CC foo.o" and the actual gcc invocations (-> V=1 linux build or so)
Nov 02 12:11:22 <builder> build #118 of mxs is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/118
Nov 02 12:22:22 <builder> build #123 of ar71xx.nand is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/123
Nov 02 12:25:38 <builder> build #131 of cobalt is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/131
Nov 02 12:27:01 <karlp> never had a cmake project in the past, just sort of felt that V=0/1/99 was somewhat more obvious than V=swc, even if the latter is more "flexible" if more classes get added.
Nov 02 12:27:06 <karlp> very minor issue though :)
Nov 02 12:29:04 <builder> build #131 of cns21xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/131
Nov 02 12:32:36 <builder> build #131 of orion is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/131
Nov 02 12:49:39 <builder> build #115 of ixp4xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/115
Nov 02 13:48:04 <builder> build #121 of brcm63xx.smp is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/121
Nov 02 14:09:35 <KanjiMonster> karlp: you can still use V=1/99 (in fact I still do most of the time ;)
Nov 02 14:51:25 <builder> build #113 of au1000 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/113
Nov 02 14:54:11 <builder> build #129 of pxa is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/129
Nov 02 15:37:00 <karlp> but V=99 doesn't do the same as V=sc ;)
Nov 02 15:37:22 <karlp> all of this really just to work out how to make cmake 2.8 do things that cmake 3.1 do differently ;)
Nov 02 16:30:46 <builder> build #114 of ramips.rt305x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt305x/builds/114
Nov 02 16:36:53 <plntyk> karlp: well the document states that V=s does the same like V=99 ^^
Nov 02 16:39:49 <karlp> well, it doesn't in CC, but is that a bug in the converson of V=99 to the "modern" style or is that a bug in the documentation?
Nov 02 17:18:51 <builder> build #114 of ramips.mt7620 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/114
Nov 02 18:13:52 <OpenWrt-Commits> nbd r47355 trunk/toolchain/Config.in
Nov 02 18:13:52 <OpenWrt-Commits> toolchain: use glibc instead of uclibc for mips64 by default - uclibc is still buggy there in a few places
Nov 02 18:13:58 <OpenWrt-Commits> nbd r47356 trunk/toolchain/ (26 files in 2 dirs) * uclibc-ng: bump version from 1.0.6 to 1.0.8
Nov 02 18:14:06 <OpenWrt-Commits> nbd r47357 trunk/toolchain/ (30 files in 2 dirs) * uclibc: remove version 0.9.33
Nov 02 18:14:11 <OpenWrt-Commits> nbd r47358 trunk/package/network/utils/iproute2/Makefile * iproute2: always use -DHAVE_SETNS, since the old uclibc is gone now
Nov 02 18:14:28 <OpenWrt-Commits> nbd r47359 trunk/include/kernel.mk * include/kernel.mk - better search for ARCH
Nov 02 18:14:35 <OpenWrt-Commits> nbd r47360 trunk/ scripts/config.guess scripts/config.sub * update config.guess & config.sub
Nov 02 18:14:42 <OpenWrt-Commits> nbd r47361 trunk/package/network/services/hostapd/files/netifd.sh * hostapd: add default value to eapol_version (#20641)
Nov 02 18:14:47 <OpenWrt-Commits> nbd r47362 trunk/package/utils/busybox/Config-defaults.in * busybox: enable find mtime support by default
Nov 02 18:17:42 <txomon> nbd: is there ar6004 support anywhere?
Nov 02 18:18:34 <nbd> you mean for using it as a wifi device?
Nov 02 18:18:43 <nbd> or for running code on its cpu?
Nov 02 18:18:47 <txomon> nbd: to have openwrt on it
Nov 02 18:18:54 <nbd> nope
Nov 02 18:19:10 <txomon> looking at http://www.4gltemall.com/alcatel-one-touch-y850.html
Nov 02 18:19:26 <txomon> I found that EE one, osprey 2 mini is based on the one linked, and it's quite chip
Nov 02 18:19:31 <txomon> cheap*
Nov 02 18:19:47 <plntyk> https://wikidevi.com/wiki/Atheros that chip series does has not many hw listed
Nov 02 18:20:40 <txomon> yeah... I don't know where they got that information from
Nov 02 18:20:53 <txomon> on that link
Nov 02 18:21:24 <txomon> I will be able to disassemble this one in one week
Nov 02 18:21:42 <txomon> and is really small
Nov 02 18:22:40 <OpenWrt-Commits> nbd r47363 trunk/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch * ar71xx: use correct PLL configuration register bitmask for QCA956x SoC.
Nov 02 18:23:32 <plntyk> at least there is some "leaked"(?) vendor code/sdk for some variant it seems
Nov 02 18:24:03 <txomon> I can't believe they aren't running *any* open source
Nov 02 18:28:03 <OpenWrt-Commits> nbd r47364 trunk/package/kernel/mac80211/patches/313-mac80211-fix-crash-on-mesh-local-link-ID-generation-.patch * mac80211: fix crash when using mesh (11s) VIF together with another VIF
Nov 02 19:28:22 <builder> build #129 of ppc40x is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/129
Nov 02 21:26:07 <builder> build #133 of brcm47xx.legacy is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/133
Nov 02 22:35:41 <builder> build #114 of brcm47xx.mips74k is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/114
Nov 03 00:00:31 <builder> build #121 of x86 is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/121
Nov 03 00:03:52 <builder> build #116 of ar71xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/116
Nov 03 00:32:15 <builder> build #117 of lantiq.xrx200 is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/117
Nov 03 00:35:55 <builder> build #121 of xburst is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/121
Nov 03 00:43:43 <txomon> So I think I found something strange in ubus, but I am not too sure. For some reason, declaring within a policy BLOBMSG_TYPE_INT16, won't be accepted, and blobmsg_get_u16 will return null
Nov 03 00:44:04 <txomon> I mean, it is accepted but it will refuse to work
Nov 03 00:44:17 <txomon> and in ubus -v list will appear as nil
Nov 03 00:45:00 <txomon> it will appear as "(unknown)"
Nov 03 00:47:17 <txomon> looking at the cli code, I understand why it appears as unknown, because int16 is not in there, but anyway, why doesn't it work for my client?
Nov 03 00:48:17 <txomon> It might be because ubus cli is not prepared to send uint16?
Nov 03 00:48:39 <txomon> (I always refer to BLOBMSG_TYPE_INT16)
Nov 03 00:51:44 <txomon> well, I understand it isn't because json doesn't have such thing as int16... and indeed libubox/blobmsg_json.c L72 is just prepared for u32, but anyway, that means you can't use any datatype that doesn't match those ones!
Nov 03 00:52:03 <txomon> shouldn't ubus cli inspect the interface and then send the correct datatype through ubus?
Nov 03 00:55:27 <txomon> I suppose it's the same for uhttpd-mod-ubus
Nov 03 01:01:23 <txomon> I have checked and yeah... so I will just use BLOBMSG_TYPE_INT32.... why does ubus even support that then? :(
Nov 03 01:02:19 <builder> build #132 of ramips.mt7621 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/132
Nov 03 01:09:15 <builder> build #132 of brcm63xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/132
Nov 03 01:12:48 <builder> build #110 of mpc83xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/110
Nov 03 01:47:35 <builder> build #110 of ep93xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/110
Nov 03 02:18:03 <builder> build #131 of ramips.rt3883 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/131
**** ENDING LOGGING AT Tue Nov 03 02:59:58 2015