**** BEGIN LOGGING AT Fri Nov 09 02:59:58 2018
Nov 09 03:20:36 <ds_shadof> latest trunk and earlier . mt7621 Thu Nov  8 13:51:42 2018 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Nov 09 03:21:29 <ds_shadof> what a disaster device.
Nov 09 03:21:46 <ds_shadof> ethernet switch broken https://bugs.openwrt.org/index.php?do=details&task_id=1618
Nov 09 03:23:27 <ds_shadof> usb broken https://bugs.openwrt.org/index.php?do=details&task_id=1637
Nov 09 03:26:57 <ds_shadof> only wifi seems to go further day by day
Nov 09 03:59:10 <mangix> ds_shadof: try reverting https://github.com/openwrt/openwrt/commit/8110bf18f4c1d04e8dfe94438caeadf78ceac892#diff-0168328969ebaa99b4c3061dad140191
Nov 09 03:59:35 <mangix> hmmm actually nvm
Nov 09 03:59:45 <mangix> seems to affect multiple devices
Nov 09 04:01:17 <mangix> ds_shadof: ethernet problem will be fixed with kernel 4.19. weep for now.
Nov 09 04:07:31 <ds_shadof> sounds like 100 light years
Nov 09 04:10:33 <mangix> yep
Nov 09 04:11:16 <mangix> driver cleanups were submitted but rejected
Nov 09 04:11:33 <mangix> on the grounds that they will come with 4.19
Nov 09 09:07:19 <xback> jow: thanks!
Nov 09 10:20:38 <ldir> xback: ping
Nov 09 10:30:31 <xback> ldir: pong
Nov 09 10:30:42 <xback> ldir: I noticed your patch yesterday evening
Nov 09 10:31:18 <xback> ldir: but I don't have Darwin anywhere :)
Nov 09 10:35:08 <ldir> Lol I understand the problem. My patch feels ugly  maybe nbd has a prettier solution:-)
Nov 09 10:35:51 <xback> I can test it if you like :)
Nov 09 10:36:20 <xback> but I can not actually compile-test it under Darwin OS
Nov 09 10:36:51 <xback> ldir: the patch itself looks more than fine
Nov 09 10:37:17 <ldir> Ahh well it compiles under Darwin ok as my build would fail without.
Nov 09 10:37:30 <xback> The original author also used bswap32,  but without checking endiannes of the host system upfront ..
Nov 09 10:37:46 <xback> no worries,  ill test the patch in the debugger here
Nov 09 10:38:01 <xback> if that is working,  and you confirm that Darwin compilation is fine.  than it's OK
Nov 09 10:38:16 <ldir> Whether the utility still produces a valid image at all is another question:-)
Nov 09 10:38:46 <xback> well .. I compared binaries with the original and this new version
Nov 09 10:39:14 <xback> but it's nearly impossible to verify correct function by looking at the code alone
Nov 09 10:39:41 <xback> I really wonder if it actually worked once ..
Nov 09 10:41:28 <xback> i'll ping you after debugging it
Nov 09 10:41:34 <karlp> I'm trying to update https://openwrt.org/docs/guide-user/base-system/hotplug_lede a bit, was trying to fill in ntp, but just reviewing it, there's not hotplug.d/button, that's all under /etc/rc.button?
Nov 09 10:41:59 <karlp> it says "not created by default" but how does /etc/rc.button and the hotplug relate?
Nov 09 10:42:05 <ldir> xback: gotta go anyway - catch you later
Nov 09 10:43:47 <jow> karlp: /etc/hotplug.json maps SUBSYSTEM = button events to [ "button", "/etc/rc.button/%BUTTON%" ]
Nov 09 10:44:27 <jow> "button" is a special flavor of "exec"
Nov 09 10:45:12 <jow> it shares the semantics with exec but does additional housekeeping to provide duration information
Nov 09 10:58:56 <rmilecki> blogic: i'm planning to add some description to the target/linux/ramips/patches-4.14/0040-nand-hack.patch
Nov 09 10:59:09 <rmilecki> blogic: i meant to just push my patch
Nov 09 10:59:14 <rmilecki> blogic: let me know if that's a problem
Nov 09 11:07:10 <karlp> jow: thanks, trying to work out what to do with this old page too: https://openwrt.org/docs/techref/hotplug
Nov 09 11:07:17 <karlp> but it's a bit of a big ball of mud :)
Nov 09 11:09:35 <karlp> do things in hotplug.json get matched first, and then if and only if they're not in hotplug.json, does it do the exec hotplugcall SUBSYSTEM?
Nov 09 11:10:06 <karlp> it looks like usb-serial does a special call, and then _also_ calls hotplug-call?
Nov 09 11:10:28 <karlp> why wouldn't that just be a script shipped in the  hotplug.d directories?
Nov 09 11:13:25 <jow> ok, so basically there is only one central udev event delegator which is procd's hotplug deamon
Nov 09 11:13:54 <jow> this daemon uses /etc/hotplug.json as configuration to figure out what to do with incoming uevents
Nov 09 11:14:48 <jow> for many event classes, hotplug.json simply instructs to execute /sbin/hotplug-call $subsystem with the env vars populated from the uevent attributes
Nov 09 11:17:10 <jow> some scripts (proto event handlers, init scripts, dhcp lease scripts, ntp statum callback scripts) invoke /sbin/hotplug-call directly
Nov 09 11:19:01 <jow> not sure what you mean with usb-serial
Nov 09 11:19:07 <jow> the logic in my config is:
Nov 09 11:19:37 <jow> if subsystem is usb-serial and the device name starts with ttyUSB or ttyUSB, then exec /sbin/hotplug-call tty
Nov 09 11:20:05 <jow> else exec /sbin/hotplug-call $subsystem if /etc/hotplug.d/$subsystem/ exists
Nov 09 11:21:14 <jow> the intention here is to delegate usb tty* device events to /etc/hotplug.d/tty/ and not /etc/hotplug.d/usb-serial/
Nov 09 11:21:29 <jow> probably to remain compatible with builtin rs232 ports and the like
Nov 09 11:38:06 <karlp> I'm not sure I see how in the default hotplug.json it calls the hotplug.d/subsystem for things like ntp? btu maybe I just cant' read the if/and way of the json file? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/system/procd/files/hotplug.json;hb=HEAD
Nov 09 11:38:20 <blogic> rmilecki: go for it
Nov 09 11:39:03 <karlp> I see button, usb-serial, and add/remove devs being handled, is it fallthrough to thoe hotplug-call if it's _not_ matched in the hotplug.json?
Nov 09 13:10:12 <ldir> karlp: ping
Nov 09 13:15:08 <xback> ldir: ping
Nov 09 13:15:17 <ldir> xback: pong
Nov 09 13:15:28 <xback> ldir: I tested you patch in the debugger.  Builds and runs fine
Nov 09 13:15:37 <xback> host system was ubuntu 18.04
Nov 09 13:16:59 <ldir> the code was stolen/copied/acquired from oseama.c anyway :-)
Nov 09 13:17:49 <xback> borrowed/confiscated/...
Nov 09 13:18:48 <ldir> lol - I have never claimed to be any more than a copy&paste coder :-)  Will document the commit and push
Nov 09 13:19:16 <xback> ok. thanks for the fix!
Nov 09 13:24:21 <ldir> at some point though we're going to hit a decision on whether we support building on anything !linux
Nov 09 13:24:51 <xback> tried building on DOS 6.22 yesterday but it failed at line 1 .. :(
Nov 09 13:26:36 <ldir> yeah my 386sx-16 is really struggling these days - might have to upgrade to a 486sx-20 - who needs a co-pro
Nov 09 13:27:00 <xback> seriously:  it's a good question
Nov 09 13:36:26 <xback> ldir:  lol @ commit msg :)
Nov 09 13:45:29 <ldir> jow: ping - I've 2 questions for you - hopefully you're running a 2 for 1 promotion discount at the moment ;-)
Nov 09 13:57:00 <karlp> ldir: yar?
Nov 09 13:57:17 <ldir> karlp: pm
Nov 09 13:57:57 * karlp looks for a window and soesn't find any :) sure, go ahead :)
Nov 09 14:20:07 <stintel> Hauke: you were looking into brcm2708 and 4.14 at some point .. what do you think about adding support for 4.14 without any backports as a start? so just a config-4.14, and some changes to target/linux/brcm2708/modules.mk ?
Nov 09 14:22:57 <stintel> maybe should check with Noltari but he seems MIA for a long time
Nov 09 14:25:39 <stintel> and it would be nice if we can include dtc and provide a way to generate a DT overlay based on some uci settings
Nov 09 14:27:10 <stintel> right now I'm having target/linux/brcm2708/patches-4.9/960-bmp280-dtbo.patch and target/linux/brcm2708/files/arch/arm/boot/dts/overlays/bme280_{i2c,spi}-sensor-overlay.dts so that I can use my BME280 sensor with iio-utils
Nov 09 14:43:15 <stintel> right, that wouldn't even work. upstream an rpi kernel use different dtb files, bcm27{0{8,9},10} vs bcm278{5,6,7}
Nov 09 14:43:57 <karlp> dt overlays soudns like a nightmare.
Nov 09 14:44:03 <stintel> maybe we should introduce a new bcm278x target and phase out brcm2708
Nov 09 14:44:08 <karlp> no wonder people just hack around stuff in userspace.
Nov 09 14:45:12 <owrt-snap-builds> build #1084 of ipq806x/generic is complete: Failure [failed targetupload]  Build details are at http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/1084  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 15:10:20 <luaraneda> stintel: are you talking about dt-overlay from userspace (configfs)? That's would require a patch, which is present in the current brcm2708 target but not in mainline
Nov 09 15:15:11 <stintel> luaraneda: something like that. right now I need to add a custom dts file and patch that in the openwrt source if I want to use my bme280 on my rpio
Nov 09 15:15:30 <stintel> and if I want to add more/other sensors I would have to build a new image
Nov 09 15:16:00 <stintel> that's not very user-friendly is it :)
Nov 09 15:20:37 <luaraneda> But the brcm2807 target (k4.9) supports dt-overlay using configfs
Nov 09 15:20:43 <luaraneda> 950-0090-OF-DT-Overlay-configfs-interface.patch
Nov 09 15:21:42 <luaraneda> I've tested the k4.14 version of that patch on the zynq target and it works
Nov 09 15:21:59 <stintel> interesting. how does that work ?
Nov 09 15:32:01 <luaraneda> https://lore.kernel.org/patchwork/patch/511853/
Nov 09 15:32:09 <luaraneda> Read the description for steps
Nov 09 15:34:44 <stintel> luaraneda: thanks!
Nov 09 16:14:04 <jow> ldir: pong
Nov 09 16:26:09 <jow> xback: I don't have root access on all builders so I cannot simply install zip
Nov 09 16:26:15 <jow> xback: is this a new prereq?
Nov 09 16:26:19 <xback> jow: no
Nov 09 16:26:29 <xback> it was present in the initial version
Nov 09 16:27:19 <jow> wonder why the prereq-build phase didn't bail out then
Nov 09 16:27:50 <xback> because it's invoked using a system() call
Nov 09 16:27:56 <xback> and the return value was ignored
Nov 09 16:28:33 <jow> I mean, whenever we require a new hostutil which we do not ship/build ourselves, we should amend include/prereq-build.mk
Nov 09 16:28:51 <jow> this should cause make to fail early
Nov 09 16:29:03 <xback> i see ..
Nov 09 16:29:29 <jow> will take care of the zip package
Nov 09 16:35:05 <jow> mailed the admin of tictex-02, will install zip on the other two boxes
Nov 09 16:35:29 <xback> jow: thank you!
Nov 09 16:35:38 <xback> srry for all the noise at your address ..
Nov 09 16:36:10 <xback> I really want all targets to build properly
Nov 09 16:36:22 <xback> next week i'll take a look at the remaining gemini builds
Nov 09 16:36:36 <jow> all fine
Nov 09 16:37:01 <jow> really need to onboard this new machine, I think I'll do that right now
Nov 09 16:47:02 <ldir> Hi jow - updated https://openwrt.org/downloads to point at openwrt.org but people are finding and using https://openwrt.org/playground/downloads and don't understand why they both exist?
Nov 09 16:48:42 <ldir> jow: and the bonus question relates to nlbwmon - have experienced issue on first boot/upgrade that nlbwmon doesn't track ipv6 traffic - it looks like it starts before the dhcpv6-pd has occurred so I copied this from dnsmasq https://github.com/ldir-EDB0/packages/commit/209ad34279222a25b8cf22e16fec6fdd6d310f6e
Nov 09 16:55:13 <jow> ldir: oh yeah, trigger would be great
Nov 09 16:55:30 <jow> ldir: as for the downloads thing. what about removing the playground page and putting a redirect?
Nov 09 16:57:02 <jow> ldir: I deleted the playground page and added a redirect
Nov 09 16:57:21 <jow> if there was anything of interest on the old page we can get it from the history
Nov 09 17:03:33 <ldir> jow: great - thank you!
Nov 09 19:09:02 <Hauke> stintel: I do not care if we use a more or less vanilla kernel or a patched one for bcm270x
Nov 09 19:09:19 <Hauke> the official kernel on version 4.19 has only very few patches
Nov 09 19:15:10 <stintel> yeah, we should probably wait until 4.19 is in or after 19.01 and then add bcm283x and phase out brcm2708 so that it's aligned with upstream
Nov 09 19:15:20 <stintel> I'm actually trying that right now
Nov 09 19:19:50 <stintel> but even if we go that road we kinda need to bump brcm2708 to 4.14
Nov 09 19:19:58 <stintel> how far did you get with that?
Nov 09 19:24:56 <greearb_> I'm compiling with V=s, but kernel modules are still using V='', how to make kernel modules show all args?
Nov 09 19:29:59 <greearb_> aah, V=c it seems
Nov 09 19:30:13 <Slimey> or V=sc
Nov 09 19:31:21 <greearb_> yeah, I guess so, first thing didn't do the trick
Nov 09 19:38:00 <greearb_> so I'm trying to compile the out-of-tree rtl8812au driver, and it compiles, but it appears it #includes the wrong cfg80211.h file (I guest the 4.14 instead of the backports version)???  So it won't load properly
Nov 09 20:17:33 <Hauke> stintel: not that far, I only rebased the patches on top of a current 4.14 kernel
Nov 09 20:18:44 <Hauke> greearb_: have a look at other packages like this one how mac80211 is integrated: package/kernel/mwlwifi/Makefile
Nov 09 20:22:40 <greearb_> ahh, I see
Nov 09 20:23:10 <greearb_> I had deleted that earlier trying to debug some other things
Nov 09 20:23:37 <greearb_> the NOSTDINC_FLAGS stuff that is
Nov 09 20:28:58 <Hauke> greearb_: yes
Nov 09 20:55:19 <rmilecki> stintel: Hauke: i voted long time for running upstream Linux for raspberry
Nov 09 20:55:30 <rmilecki> stintel: you got all my support running as much mainlinea s possible
Nov 09 20:57:03 <jow> isn't the problem that mainline requires 4.19+ ?
Nov 09 20:57:10 <jow> whel we target 4.14 for release
Nov 09 20:57:13 <jow> *while
Nov 09 20:58:29 <rmilecki> jow: I don't think there's a single kernel verison that magically supports raspberry
Nov 09 20:58:41 <rmilecki> support was being added over years piece by piece
Nov 09 20:58:44 <rmilecki> depends on what you need
Nov 09 20:59:44 <stintel> well hence my suggestion to wait for 4.19 / after 19.01
Nov 09 21:00:12 <stintel> I'm trying to get vanilla 4.14 to boot on my rpi0w
Nov 09 21:00:22 <stintel> but I guess it won't be for today
Nov 09 21:08:06 <greearb_> is there a sane way to enable CONFIG_WIRELESS_EXT?
Nov 09 21:09:50 <stintel> greearb_: I would argue the only sane way is "don't do it" :)
Nov 09 22:20:07 <greearb_> I'm having a heck of a time with BIT being double-defined somewhere ever since I started using backports includes...anyone know where the problem might be?
Nov 09 22:26:23 <karlp> ~missing includes?
Nov 09 22:26:38 <karlp> sprinkling more #ifndefs?
Nov 09 22:26:45 <greearb_> In file included from /home/greearb/git/openwrt-neo2-dev/staging_dir/target-aarch64_cortex-a53_musl/usr/include/mac80211-backport/linux/bitops.h:3:0,
Nov 09 22:26:45 <greearb_>                  from /home/greearb/git/openwrt-neo2-dev/build_dir/target-aarch64_cortex-a53_musl/linux-sunxi_cortexa53/rtl8812au-ct-2018-11-09c-acc060df/include/osdep_service_linux.h:23,
Nov 09 22:26:45 <greearb_>                  from /home/greearb/git/openwrt-neo2-dev/build_dir/target-aarch64_cortex-a53_musl/linux-sunxi_cortexa53/rtl8812au-ct-2018-11-09c-acc060df/include/osdep_service.h:41,
Nov 09 22:26:45 <greearb_>                  from /home/greearb/git/openwrt-neo2-dev/build_dir/target-aarch64_cortex-a53_musl/linux-sunxi_cortexa53/rtl8812au-ct-2018-11-09c-acc060df/include/drv_types.h:32,
Nov 09 22:26:48 <greearb_>                  from /home/greearb/git/openwrt-neo2-dev/build_dir/target-aarch64_cortex-a53_musl/linux-sunxi_cortexa53/rtl8812au-ct-2018-11-09c-acc060df/core/rtw_cmd.c:22:
Nov 09 22:26:51 <greearb_> ./include/linux/bitops.h:7:19: error: expected identifier before '(' token
Nov 09 22:26:53 <greearb_>  #define BIT(nr)   (1UL << (nr))
Nov 09 22:26:55 <greearb_> something is defining it twice I guess?
Nov 09 22:27:42 <Monkeh> greearb_: You're missing a bracket
Nov 09 22:27:54 <Monkeh> I think
Nov 09 22:28:01 <Monkeh> Or not, perhaps I need new glasses
Nov 09 22:28:23 <karlp> that's a bug somewhere else...
Nov 09 22:28:23 <greearb_> that error is coming from deep in linux bitops.h, I think something #defines BIT elsewhere, just can't find it
Nov 09 22:28:37 <karlp> my bet is a bug in an inline function in aheader file?
Nov 09 22:29:08 <greearb_> seems like I hit this before, but I can't recall where
Nov 09 22:48:36 <greearb_> looks like problem is that rtl driver includes a huge amount of duplicated stuff, and the include logic that allowed it to pull in backports include files is conflicting
Nov 09 22:49:11 <jwh> I love gcc errors, so clear :D
Nov 09 22:55:13 <karlp> you love people who abuse teh preprocessor...
Nov 09 22:55:42 <jwh> heh
Nov 09 23:04:37 <owrt-snap-builds> build #196 of at91/sama5d2 is complete: Success [build successful]  Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/196
Nov 09 23:35:44 <owrt-snap-builds> build #987 of imx6/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/imx6%2Fgeneric/builds/987  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:35:48 <owrt-snap-builds> build #1039 of ixp4xx/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ixp4xx%2Fgeneric/builds/1039  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:35:55 <owrt-snap-builds> build #1064 of ar7/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fgeneric/builds/1064  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:35:59 <owrt-snap-builds> build #1070 of apm821xx/nand is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/apm821xx%2Fnand/builds/1070  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:03 <owrt-snap-builds> build #1065 of ramips/rt3883 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Frt3883/builds/1065  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:07 <owrt-snap-builds> build #1079 of ar71xx/mikrotik is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fmikrotik/builds/1079  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Daniel Engberg <daniel.engberg.lists@pyret.net>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:10 <owrt-snap-builds> build #73 of samsung/s5pv210 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/samsung%2Fs5pv210/builds/73  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:14 <owrt-snap-builds> build #72 of layerscape/armv7 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv7/builds/72  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:18 <owrt-snap-builds> build #1123 of brcm47xx/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/brcm47xx%2Fgeneric/builds/1123  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:21 <owrt-snap-builds> build #470 of octeontx/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/470  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:25 <owrt-snap-builds> build #1132 of brcm63xx/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fgeneric/builds/1132  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:29 <owrt-snap-builds> build #767 of sunxi/cortexa53 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/sunxi%2Fcortexa53/builds/767  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:33 <owrt-snap-builds> build #250 of oxnas/ox820 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/oxnas%2Fox820/builds/250  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:36 <owrt-snap-builds> build #738 of lantiq/ase is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Fase/builds/738  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:40 <owrt-snap-builds> build #1190 of x86/64 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/x86%2F64/builds/1190  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:44 <owrt-snap-builds> build #1135 of ar7/ac49x is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fac49x/builds/1135  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:47 <owrt-snap-builds> build #1096 of brcm47xx/mips74k is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/brcm47xx%2Fmips74k/builds/1096  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:51 <owrt-snap-builds> build #667 of arc770/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/arc770%2Fgeneric/builds/667  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:55 <owrt-snap-builds> build #1115 of ath25/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ath25%2Fgeneric/builds/1115  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:36:58 <owrt-snap-builds> build #983 of pistachio/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/pistachio%2Fgeneric/builds/983  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:37:02 <owrt-snap-builds> build #249 of mediatek/mt7623 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7623/builds/249  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:37:06 <owrt-snap-builds> build #276 of mvebu/cortexa72 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/mvebu%2Fcortexa72/builds/276  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:37:10 <owrt-snap-builds> build #890 of armvirt/32 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/armvirt%2F32/builds/890  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:37:13 <owrt-snap-builds> build #219 of mediatek/mt7622 is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7622/builds/219  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:37:18 <owrt-snap-builds> build #1015 of ar71xx/generic is complete: Failure [failed gcc]  Build details are at http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/1015  blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Nov 09 23:53:50 <russell--> oops ;-)
Nov 09 23:54:10 <jow> yeah, accidentally mounted the tmpfs overlay with noexec
Nov 09 23:56:01 <jwh> lol
Nov 10 00:33:11 <greearb_> ok, rtl8812au driver at least builds....plz see the email I sent to openwrt-devel if you'd like to try it out
Nov 10 01:11:21 <russell--> greearb_: i think i have one of those
Nov 10 02:06:56 <luaraneda> greearb_: I think the #echo "rtl8812au-ct:  Nothing to configure." could be avoided (from Build/Configure)
Nov 10 02:10:02 <luaraneda> At least for normal packages you can use Build/Configure/Default, but I'm not sure it applies to all kind of packages
**** ENDING LOGGING AT Sat Nov 10 02:59:59 2018