**** BEGIN LOGGING AT Wed Jan 08 02:59:58 2020
Jan 08 03:03:03 <owrt-1907-builds> build #75 of brcm2708/bcm2709 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/75
Jan 08 05:26:14 <owrt-snap-builds> build #195 of sunxi/cortexa7 is complete: Failure [failed pkgbuild]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa7/builds/195  blamelist: Matthias Schiffer <mschiffer@universe-factory.net>, Daniel Golle <daniel@makrotopia.org>
Jan 08 06:09:08 <mangix> jow: what is i386_legacy used on?
Jan 08 07:30:28 <pkgadd> mangix: the target mentions Soekris, from which I assume devices in the same league as soekris net4521 (with AMD Elan SC520/ 486 class), but I'm just guessing. from the stats it might still be barely functional
Jan 08 07:32:58 <pkgadd> I quite certainly wouldn't want to run such a system since at least 2015 though
Jan 08 08:45:21 <mangix> pkgadd: no way. CONFIG_AGP_INTEL=y is specified for legacy
Jan 08 08:45:43 <mangix> yeah even i915 driver
Jan 08 08:46:11 <mangix> and so is CONFIG_PATA_AMD=y. hmmmmm.....
Jan 08 08:47:55 <mangix> I ask since the default CPU type of pentium causes NASM to create broken compiled asm. I have a commit that changes the CPU type to pentium2, which is from 1997
Jan 08 08:48:04 <mangix> fixes NASM
Jan 08 09:04:03 <dangole> mangix: x86/legacy should also cover aged embedded x86 chips like VIA EPIA, AMD Geode, ...
Jan 08 09:08:13 <mangix> amd geode has its own target
Jan 08 09:09:38 <mangix> via epia looks newer than pentium2
Jan 08 09:13:52 <dangole> mangix: afaik some C3, VIA and Cyrix cores marketed post-pentium2 still didn't come with complete pentium2 compatible instruction set. they are considered somewhere in-between i586 and i686...
Jan 08 09:15:11 <dangole> mangix: if the problem is just nasm, i think we should just override the cpu-type for nasm to be pentium2 while keeping it pentium for x86/legacy in general
Jan 08 09:19:44 <mangix> dangole: hmm? got a patch?
Jan 08 09:20:07 <mangix> the problem is with legacy and geode
Jan 08 09:20:22 <mangix> pentium4 target works fine
Jan 08 09:20:55 <mangix> https://downloads.openwrt.org/snapshots/faillogs/i386_pentium/packages/ffmpeg/full/compile.txt
Jan 08 09:25:08 <dangole> mangix: looks like the object created by nasm doesn't match up with gcc's expectations... maybe just --disable-x86asm for those old CPU_TYPES for now
Jan 08 09:30:57 <mangix> funny enough, objdump doesn't know what these files are
Jan 08 09:31:51 <mangix> but yes, disabling asm works. but so does changing the CPU_TYPE to pentium2
Jan 08 10:16:38 <Tapper> We don't need to run on such old CPUS as a pentium2.
Jan 08 12:30:56 <olmari> I'm broad general one of the cool tings with openwr is that it has been possible to put it to "any old device" so to speak... In that way x86 legacy is nice to have feature to as low as we can get it into.. But at the same time I do realise keeping something against anything else really caring is at the least worksome if not hard... And is there really the need either
Jan 08 12:33:36 <olmari> For really legacy stuff one ought to use appropiate era softwares too, goes to anything.. So in this sense mine 2 cents is that keep cpu/platform in legacy as low as easily possible, otherwise just the minimum for legacy
Jan 08 12:35:17 <olmari> ..Because I I do think givin many thoughts to x86-legacy isn't bringing that much users(?)
Jan 08 12:41:20 <dangole> olmari: i know a couple of pretty legacy PBX systems out there running Asterisk on OpenWrt. and it's not so easy to replace that hardware for the existing legacy PCI BRI interfaces...
Jan 08 12:42:23 <olmari> dangole: does they also absolutely require latest openwrt to operate? :)
Jan 08 12:42:42 <ynezz> who don't want to run latest and safest?
Jan 08 12:43:30 <dangole> olmari: more or less latest asterisk is needed and a reasonable maintained OS with recent dropbear etc.
Jan 08 12:44:23 <olmari> ynezz: most sane peoples, but it still doesn't change my point really :)
Jan 08 12:45:05 <olmari> Ofcourse skilled dev can do also as much work as possible if wanted to, I'm not saying that :P
Jan 08 12:46:04 <dangole> olmari: i just see more gain in supporting otherwise unsupportable hardware with quite little effort even if that comes with the drawback that not-so-terribly-outdated systems may lack some ASM-optimized functions in ffmpeg
Jan 08 12:47:06 <olmari> I also did not say devs, or generally people, should just stop and drop everything all of the sudden :P
Jan 08 12:48:00 <owrt-1907-builds> build #85 of sunxi/cortexa7 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/85  blamelist: Matthias Schiffer <mschiffer@universe-factory.net>
Jan 08 12:49:02 <olmari> it was ans still is general statement, where amount of work needed vs. gains and usebase is to consider... while this also does not say that someone couldn't do it just because, that is als allowed =)
Jan 08 12:52:51 <dangole> olmari: true :)
Jan 08 12:55:10 <olmari> For this specific issue I'd say just drop the ASM-optimisation and keep on supporting old things
Jan 08 12:55:50 <olmari> one issue in "x86" is that it caters stuff from basically ~1980 to this day and keeps on going
Jan 08 12:57:01 <olmari> while often it does not be too exact what any new x86 cpu comes, as a category on openwrt it is kinda diffirent from all the other devices =)
Jan 08 12:58:48 <olmari> every piece of device variants get own file and setup process, while x86 is just some basically random set of things especially drivers/hardware wise and generally user needs to know somewhat much more when deploying it, be it from image directly or building it
Jan 08 12:59:41 <olmari> And also this notion is indiffirent to is it better or worse... I know I like mine x86-64 but I generally compile my own openwrt anyways for any device =)
Jan 08 13:02:08 <olmari> and occasionally have some weird-ass PEBKAC like above at night xD
Jan 08 16:04:28 <FinboySlick> My question is probably better asked here so here goes:
Jan 08 16:04:37 <FinboySlick> From what I could find so far, the 'proper' way to support usb3 on Octeon 7130 is to use CONFIG_DWC3_OF_SIMPLE, but that relies on CONFIG_COMMON_CLK which is not enabled for octeon targets.  Anyone knows if that's an omission or just not supported (it seems enabled with a bunch of mips targets).
Jan 08 17:52:36 <owrt-1907-builds> build #104 of malta/be is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/malta%2Fbe/builds/104
Jan 08 17:56:22 <greearb_> anyone have opinions on whether I should compile out congestion control in the ath10k-ct wave-2 firmware?  If I do, then it will be up to the upper stacks to provide better service to certain QoS.  Not sure how well that is implemented?
Jan 08 17:56:51 <greearb_> getting rid of it will fix some tx packet loss that is at least bothersome for my use cases...
Jan 08 18:38:32 <russell--> FinboySlick: git log -S CONFIG_COMMON_CLK might be helpful
Jan 08 18:43:09 <FinboySlick> russell--: Thanks.  I really need to start learning git properly if I'm going to contribute to this project :P  Though this seems to output every instances of the kernel config changing :P
Jan 08 18:44:37 <russell--> any diffs that include that search term, i think
Jan 08 18:45:21 <russell--> you can narrow the search to a particular subtree as well
Jan 08 18:45:29 <russell--> or an individual file
Jan 08 18:46:27 <FinboySlick> Yeah.  That said, it's not a configurable option, it's one of those selected-by things that seems to depend on the choice of architecture.  I find it a bit odd that a driver that supports Octeon would require it, but then that building a kernel for octeon wouldn't select it.
Jan 08 18:46:39 <russell--> if there is a discussion "oh we unset this for reason X" that might be informative
Jan 08 18:47:43 <russell--> i neglect to say that I personally have no idea, but if i wanted to know, that might be where i'd start
Jan 08 18:48:57 <FinboySlick> russell--: Still appreciated :)
Jan 08 18:49:39 <russell--> if i failed to find a reason for it being unset, i think i'd try setting it and see if everything still worked
Jan 08 19:36:59 <KanjiMonster> FinboySlick: the config symbol says "this arch doesn't use its own homegrown clk implementation, but the generic, (common) clk framework"
Jan 08 19:38:15 <FinboySlick> KanjiMonster: Yeah.  I forced it on for fun and it built but the driver couldn't find clk so I guess that doesn't help.
Jan 08 19:39:58 <Hauke> jow: could you please retrigger the 19.07 build for bcm2709
Jan 08 19:40:04 <Hauke> this is the only one which failed
Jan 08 19:40:32 <FinboySlick> Still a bit odd that the driver specifically supports octeon 7130 usb, yet relies on COMMON_CLK which doesn't seem to exist on those.
Jan 08 19:43:54 <Hauke> ok it is triggered here: http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709
Jan 08 19:55:14 <ynezz> Hauke: and sunxi?
Jan 08 19:57:50 <ynezz> nm, it's different build
Jan 08 20:08:42 <jow> yes
Jan 08 20:08:51 <jow> sorry, Hauke: yes
Jan 08 20:09:06 <jow> ah you figured it out already
Jan 08 21:48:39 <FinboySlick> Not having enough documentation on devices is so frustrating :P
Jan 08 21:51:32 <ynezz> for those who don't follow forum/mailing lists regularly https://forum.openwrt.org/t/refresh-project-identity-new-openwrt-project-logo
Jan 08 22:13:57 <pkgadd> some pretty nice logos among them
Jan 08 22:15:00 <Hauke> as the bcm2709 build didn't finish yet and the 18.06 build is also ongoing I will try to find some time tomorrow to send the release anncounment
Jan 08 22:16:01 <Hauke> zorun: hostapd-wolfssl didn't work for me with WPA3, only the openssl versions worked I think we should only mention openssl for now
Jan 08 22:20:48 <malwar3hun73r_> i'm seeing some strange issues where openwrt is spewing 1000s (100,000s) reverse lookups for IPs on my lan
Jan 08 22:20:51 <malwar3hun73r_> any ideas?
Jan 08 22:28:48 <barhom> Can someone make sense of what is going on here so I can bug a proper bugreport? https://pastebin.com/eQFW4Knq
Jan 08 22:29:23 <barhom> Basically my wife's Galaxy S10 enters this unrecoverable state in the wifi where it keeps trying to reconnect without succeeding until I turn off wifi and turn it back on. ATH10k based 5g.
Jan 08 22:31:05 <owrt-snap-builds> build #231 of ixp4xx/harddisk is complete: Failure [failed checkarch]  Build details are at http://buildbot.openwrt.org/master/images/builders/ixp4xx%2Fharddisk/builds/231  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Ansuel Smith <ansuelsmth@gmail.com>
Jan 08 23:04:12 <malwar3hun73r_> if i restart dnsmasq, the reverse lookups stop for a day or two, then they return... 100,000s per day
Jan 08 23:12:45 <greearb_> barhom, you using ath10k-ct?  What chipset?
Jan 08 23:14:16 <owrt-snap-builds> build #230 of mediatek/mt7622 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/230
Jan 08 23:22:52 <barhom> greearb_: I am using ath10k-ct on ipq4019
Jan 08 23:23:52 <greearb_> if you use stock ath10k firmware, does the problem go away?
Jan 08 23:24:39 <barhom> greearb_: I would need to try, I'll post an issue on your github afterwards
Jan 08 23:25:30 <barhom> Also, I have no idea if this is related in anyway, but for some reason this same phone will NOT connect to a whatsapp voice/video call when connected to wifi. Works fine on other routers. Ill see if it works with stock ath10k as well
Jan 08 23:25:56 <barhom> I am on a commit from Dec 14, so not latest master
Jan 08 23:29:30 <barhom> What is the correct syntax to add a new 'NAMED' section? I am trying to do 'uci add wireless wifi-iface NAMED' which fails.
Jan 08 23:29:57 <barhom> I'd like to populate the conig with "config wifi-iface 'NAMED'"
Jan 08 23:35:18 <owrt-snap-builds> build #231 of cns3xxx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/231
Jan 09 00:46:06 <jow> barhom: uci set wireless.NAMED=wifi-iface
Jan 09 00:55:12 <owrt-snap-builds> build #230 of x86/geode is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeode/builds/230
Jan 09 02:27:36 <owrt-1907-builds> build #86 of sunxi/cortexa7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/86
Jan 09 02:34:34 <owrt-snap-builds> build #197 of octeon/generic is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/197  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Hauke Mehrtens <hauke@hauke-m.de>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Ansuel Smith
Jan 09 02:34:34 <owrt-snap-builds> <ansuelsmth@gmail.com>
Jan 09 02:35:32 <owrt-snap-builds> build #194 of ar7/ac49x is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/ar7%2Fac49x/builds/194  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Hauke Mehrtens <hauke@hauke-m.de>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Ansuel Smith
Jan 09 02:35:32 <owrt-snap-builds> <ansuelsmth@gmail.com>
**** ENDING LOGGING AT Thu Jan 09 02:59:58 2020