**** BEGIN LOGGING AT Sat Feb 08 02:59:58 2020
Feb 08 06:21:11 * shalzz sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/UBWCZmGREVXpoFPnIxbpgxFv >
Feb 08 08:04:09 <Pepe> russell--: Does that help you? If yes, can you please respond to that pull request? Tested / acked by would be OK.
Feb 08 08:29:37 * shalzz sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/BJEmqBpPOnkhPsJhbeEtlEKX >
Feb 08 08:29:58 <shalzz> my config: https://paste.rs/hxd
Feb 08 08:35:29 <Borromini> shalzz: master or 19.07?
Feb 08 08:35:56 <shalzz> master
Feb 08 08:37:22 <Borromini> try adding +libnl-tiny to the WPAD package depends in package/network/services/hostapd/Makefile
Feb 08 08:44:11 <shalzz> Borromini: Doesn't work. Now I get this: https://paste.rs/i1v
Feb 08 08:44:52 <shalzz> I'm still getting this error even after removing the +libnl-tiny
Feb 08 08:46:29 <Borromini> i'll prep you a patch, sounds like that didn't go too well...
Feb 08 08:47:39 <shalzz> My git staging is clean
Feb 08 08:49:02 <shalzz> Do I need to make clean? It'll take hours tho then
Feb 08 08:49:57 <Borromini> sec
Feb 08 08:50:07 <Borromini> there's already DRV_DEPENDS:=+PACKAGE_kmod-cfg80211:libnl-tiny by default on line 130 of the Makefile
Feb 08 08:51:08 <Borromini> what you might want to do is do a make package/hostapd/{clean,compile}
Feb 08 08:51:26 <Borromini> this is what i whipped up https://paste.debian.net/1129744/
Feb 08 08:51:42 <Borromini> but since line 130 is already pointing to libnl-tiny it seems, there is probably something else going wrong
Feb 08 08:52:05 <shalzz> > this is what i whipped up https://paste.debian.net/1129744/
Feb 08 08:52:05 <shalzz> Yeah this is what I did
Feb 08 08:52:16 <Borromini> ok then try the clean/compile routine
Feb 08 08:52:26 <shalzz> and removed
Feb 08 08:55:53 <shalzz> > ok then try the clean/compile routine
Feb 08 08:55:53 <shalzz> no doesn't work. Still the huge dependency errors with hostapd
Feb 08 08:56:10 <shalzz> Lemme try doing a make clean then
Feb 08 08:56:38 <shalzz> Nope
Feb 08 08:57:22 <Borromini> no idea then sorry. i've gone through the git log of the past few days and libnl-tiny isn't exactly a new dependency or anything.
Feb 08 08:57:31 <shalzz> Tried updating my feeds as well still  https://paste.rs/i1v
Feb 08 08:58:33 <Borromini> remove ./tmp/ as well
Feb 08 08:58:36 <Borromini> (not /tmp)
Feb 08 09:00:38 <shalzz> same
Feb 08 09:01:11 <shalzz> It rebuilds the package list and arrives at the same conclusion
Feb 08 09:01:39 <Borromini> a config error again?
Feb 08 09:02:03 <shalzz> yes same error  https://paste.rs/i1v
Feb 08 09:05:38 <shalzz> wow somethings really off. Even after make distclean I get the same error.
Feb 08 09:05:51 <shalzz> my ccache :(
Feb 08 09:07:16 <Borromini> well the last error showing is a config error, not sure if ccache has anything to do with that
Feb 08 09:08:44 <shalzz> Yeah but I did `make distclean` which removes the local ccache folder inside openwrt If i'm not wrong
Feb 08 09:11:02 <Borromini> that should wipe pretty much everything, yes
Feb 08 09:23:16 <shalzz> I think there's a bash or make version issue. Its generating a config with `||` at the end for eg :`PACKAGE_PACKAGE_wpad-wolfssl||` in tmp/.config-package.in
Feb 08 09:24:42 <shalzz> manually removing that fixed it to atleast get me to the ncurses interface
Feb 08 09:39:27 <shalzz> How is packageauxvars?
Feb 08 09:39:39 <shalzz> How is packageauxvars generated?
Feb 08 09:41:57 <KanjiMonster> shalzz: .config-package.in is generated by https://github.com/openwrt/openwrt/blob/master/scripts/package-metadata.pl
Feb 08 09:43:08 <jow> shalzz: your make is too new
Feb 08 09:45:09 <shalzz> Yeah I'm on arch linux and they updated make to version 4.3.1 on 6th feb :/
Feb 08 09:46:05 <jow> you can try this: https://github.com/openwrt/openwrt/pull/2713
Feb 08 09:48:42 <Borromini> such is the price of bleeding edge
Feb 08 09:50:13 <shalzz> Yeah that did it thanks!
Feb 08 09:59:28 <KanjiMonster> shalzz: can you test if removing the space difinition from hostapd's Makefile also works? $(TOPDIR)/rules.mk already provides one
Feb 08 10:01:27 <shalzz> Ok, yes removing space definitions from hostapd works as well
Feb 08 10:04:40 <Tapper> jow could you take a peek at this pleas. https://github.com/openwrt/openwrt/pull/2756
Feb 08 10:06:16 <Tapper> The mwlwifi is such a cluster fuck!
Feb 08 10:06:57 <Borromini> orly :D
Feb 08 10:07:14 <Tapper> Borromini Hi
Feb 08 10:07:40 <Tapper> Going to grab coffee brb
Feb 08 10:08:09 <Borromini> hey man
Feb 08 10:36:29 <jow> KanjiMonster: http://sprunge.us/yTAMr8 ?
Feb 08 10:38:56 <ldir> ha! does it not even use space then? :-)
Feb 08 10:40:00 <KanjiMonster> ldir: it does, but by removing the defininition from package/.../hostapd/Makefile it just uses the one from $(TOPDIR)/rules.mk, which it already includes (and seems to be make 4.3 compatible)
Feb 08 10:40:39 <ldir> great, problem solved with less code - yay
Feb 08 10:41:13 <KanjiMonster> jow: yes. Don't have a make 4.3 to test though, but shalzz did test it (looks like manjaro still has 4.21)
Feb 08 10:42:11 <jow> updated commit with more context: http://sprunge.us/0xiPIF
Feb 08 10:43:27 <KanjiMonster> maybe shalzz also wants to provide a "Tested-by:" line? then we have almost everything ;)
Feb 08 10:44:29 <Borromini> the perfect commit :^)
Feb 08 10:45:19 <shalzz> Yes sure, Tested-by: Shaleen Jain <shaleen@jain.sh>
Feb 08 10:45:28 <KanjiMonster> yay
Feb 08 10:46:41 <jow> thanks. pushed & cherry-picked
Feb 08 10:52:00 <KanjiMonster> jow: 18.06 also needs it
Feb 08 10:52:41 <KanjiMonster> 17.01 doesn't, as it was introduced in a refactoring commit that isn't in 17.01
Feb 08 10:55:48 <jow> done
Feb 08 10:56:02 <KanjiMonster> ty
Feb 08 14:32:32 <shalzz> Is DFS scan a known issue with the mt7612en for the 5Ghz radio?
Feb 08 14:33:06 <shalzz> My 5Ghz doesn't come up no matter if I set channel selection to auto or any other
Feb 08 14:33:18 <shalzz> logs: https://paste.rs/SZ7
Feb 08 14:33:30 <shalzz> Here wlan0 is my 5ghz radio
Feb 08 14:35:14 <shalzz> I can see some mediatek guys contributing to mt76. Hopefully they can come around to fixing this issue as well :D
Feb 08 17:52:33 <RobertP> is there anyone online who is experienced with bcm53xx and bcm4366 - need some high level advice please :)
Feb 08 20:13:08 <karlp> RobertP: always best to just ask the question.
Feb 08 20:28:20 <RobertP> thanks karlp :)
Feb 08 20:31:17 <RobertP> I'm looking for a advice if adding support for Asus RT-AC5300 is feasible (with the new driver bcmfmac and new firmware 4366c) ?
Feb 08 20:34:10 <olmari> On similar note, is there currently "best openwrt supported" wifi chipset or family?
Feb 08 20:35:20 <olmari> I try not to ask the dreaded "what device I need?" But rather specifically what would be todays owrt friendly wifi :)
Feb 08 20:36:54 <RobertP> @olmari currently supported devices? or in near future?
Feb 08 20:40:07 <RobertP> I'm newbie here - but I found this: https://bluegadgettooth.com/best-openwrt-router/ ... however situation might change when work on AX routers will be finished
Feb 08 20:47:55 <olmari> On my radar kinda both.. for separate reasons :) generally current situation where openwrt devs thinks a wifi mfg/model/chip is cobsidered best.. or least fucjed up as it often times is these days
Feb 08 20:48:14 <olmari> ...and then future prospects ofcourse :)
Feb 08 21:03:11 <Borromini> RobertP: nobody will recommend you broadcom here, except maybe the single device that does work (and is the odd one out)
Feb 08 21:08:55 <RobertP> @Borromini - I know nobody would recommend BCM here ... but I already have that router :)  And situation probably has improved recently - at least a bit as people are adding support for similar devices (e.g. Phicomm K3)
Feb 08 21:16:01 <Borromini> yeah, but adding device support doesn't imply adding support for its radios. especially for broadcom
Feb 08 21:16:16 <Borromini> haven't you asked before?
Feb 08 21:18:27 <Borromini> i have no idea how well supported BCM4366 wireless is on linux/openwrt.
Feb 08 21:20:16 <RobertP> I know it's not easy :)  that is why I'm asking what more experienced devs thinks
Feb 08 21:22:42 <Borromini> sorry, it seems i only read your question half. i'll shut up.
Feb 08 21:25:23 <olmari> Should I figure best chip, then I'll try to dig device for a task with said chip... or ofcourse if something like in the link is "only one" then that
Feb 08 21:27:29 <RobertP> @Borromini - absolutely no problem :)
Feb 08 23:31:21 <karlp> olmari: mt76 stuff is "good" for future stuff, if you ask nbd/blogic.
Feb 08 23:32:10 <olmari> Hehe
Feb 08 23:32:57 <olmari> Ofcourse there are preferences.. I "just" need to update mine current knowledge and possible future techs
Feb 08 23:36:26 <karlp> ath10k has some support from candelatech, but *shrugs*, brcmfmac mostly _works_ but you only get what they give, realtek is as random as always,  what's left? cypress may or may make broadcom great again?
Feb 08 23:38:36 <olmari> Mine most current knowledge is ath10k and indeed ct, say tplink archer c7v2
Feb 08 23:38:53 <pkgadd> is there any chipset from realtek that would really be up to AP uses? with a mainline nl80211 driver and unpatched/ current hostapd. I don't really know of any
Feb 09 00:47:17 <aparcar[m]> mwarning: ping
**** ENDING LOGGING AT Sun Feb 09 02:59:57 2020