**** BEGIN LOGGING AT Tue Dec 01 03:00:02 2020
Dec 01 03:24:33 <stintel> ByteEnable: you shouldn't modify the tarbal, learn how to use patches: https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem
Dec 01 03:25:42 <ByteEnable> Will browse.  Thanks.
Dec 01 03:27:42 <ByteEnable> The issue in in kexec-tools someone define my_debug twice.  Once in the .h and then again as a global in main().
Dec 01 03:28:53 <ByteEnable> kexec/fs2dt.c and the .h.
Dec 01 04:00:24 <mangix> ByteEnable: are you building with GCC10?
Dec 01 04:20:08 <mangix> ByteEnable: please test https://patchwork.ozlabs.org/project/openwrt/patch/20200901215008.90451-1-rosenp@gmail.com/
Dec 01 05:46:04 <ByteEnable> Yeah.  Using GCC10.  Its a linker error with kexec-tools.  A debug variable named 'my_debug'.  I just wrote a patch for it.  The my_debug is for PPC64 only.
Dec 01 05:47:55 <ByteEnable> My build is still running.  FIrst builder.  At first I was cursing the build system.  It's actually state of the art in most respects.
Dec 01 05:48:55 <ByteEnable> *First time builder.
Dec 01 09:24:02 <Pepe> Guys, I can not do git clone as fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': Failed to connect to git.openwrt.org port 443: Connection timed out failed.
Dec 01 09:24:04 <Pepe> It fails because of: This server could not prove that it is git-01.infra.openwrt.org; its security certificate is from git.openwrt.org
Dec 01 09:35:04 <karlp> https ensuring a reliable web experience again :)
Dec 01 09:43:51 <ynezz> Pepe: works for me, just tried `git clone https://git.openwrt.org/feed/packages.git`
Dec 01 09:44:06 <mangix> Pepe: replace feeds/packages origin to the github one
Dec 01 09:44:27 <mangix> the github the original and hence gets updates faster
Dec 01 09:44:34 <mangix> *is the
Dec 01 09:50:00 <Pepe> mangix: Thanks! But it is different fron what it is in https://github.com/openwrt/openwrt/blob/master/feeds.conf.default
Dec 01 09:52:48 <karlp> hehe
Dec 01 09:53:03 <karlp> using the non-canon source to point out that the canon source is using a non-canon source :)
Dec 01 09:53:36 <karlp> but yes, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=feeds.conf.default;h=03bfacb620fd9f9bd489b1d5009d09c3f75fb462;hb=HEAD is IMO, wrong, as github is canonical for the packages,
Dec 01 09:53:44 <karlp> but I know people like to use their own infra....
Dec 01 09:55:15 <Pepe> ynezz: The issue relays here: https://git-01.infra.openwrt.org/ just open it with your browser. That's the simplest what you can do.
Dec 01 09:55:47 <ynezz> Pepe: why are you using that URL?
Dec 01 09:56:12 <ynezz> I've never used it directly
Dec 01 10:00:58 <Pepe> ynezz: I am not using it directly, but using git.openwrt.org, which CNAME points to A and AAAA records of git-01.infra.openwrt.org and it has no valid SSL certificate. Downloads does not work.
Dec 01 10:01:20 <ynezz> eh?
Dec 01 10:02:32 <Pepe> https://dnsviz.net/d/git.openwrt.org/dnssec/
Dec 01 10:04:38 <ynezz> pastebin output of `git clone https://git.openwrt.org/feed/packages.git` and `curl -v https://git.openwrt.org` commands
Dec 01 10:49:44 <grift> the issue in that event is the third party
Dec 01 10:49:59 <grift> wrong chan ignore
Dec 01 11:24:17 <adrianschmutzler> is there a remaining blocker for 19.07.5 now that the ipq40xx double-tagging has been addressed?
Dec 01 11:30:26 <jow> adrianschmutzler: there's a pending firewall3 patch I want to merge
Dec 01 11:31:29 <jow> the decision to proxy github urls through git.openwrt.org was a deliberate one back in the day
Dec 01 11:33:17 <adrianschmutzler> ah, okay
Dec 01 11:34:29 <adrianschmutzler> btw are there any plans yet what happens to feeds when we move main repo to gitlab? probably they will prefer staying at github and keeping the infrastructure they have built?
Dec 01 11:34:44 <jow> github folks can remain there
Dec 01 11:35:05 <jow> but we'll likely continue to proxy external feeds through whatever hosting we use for the core
Dec 01 11:36:08 <jow> the reasoning behind that is that we reserve the ability to hold back or sanitize external feed updates in case it is ever needed
Dec 01 11:36:26 <jow> after all we're essentially running untrusted code on our build infrastructure
Dec 01 11:36:32 <jow> and uploading it to the repos
Dec 01 11:37:35 <jow> right now we simply mirror the github repo every minute but that could be theoretically changed to a more elaborate scheme if the need arises
Dec 01 11:39:58 <jow> Pepe: as far as I am aware we're not doing DNSSEC for *.openwrt.org
Dec 01 15:40:25 <Piraty> if i issue: `opkg install ./local_file.ipk` , can i make opkg resolve deps from a specified dir where many packages reside (possibly not installed yet) so it takes them into account for dep resolving?
Dec 01 16:11:06 <karlp> Piraty: not entirely the answer, but I found just "python -m SimpleHTTPServer" and editing the sources list is enough to work around it.  I haven't really tried actually looking further.
Dec 01 20:24:01 <aparcar[m]> mangix: ping
Dec 01 20:24:13 <aparcar[m]> mangix: mind creating a PR to remove openvpn and put nbd in cc?
Dec 01 20:30:33 <mangix> you want openvpn out as well?
Dec 01 20:31:00 <mangix> I guess it makes sense given that wireguard is a thing
Dec 01 20:31:16 <aparcar[m]> mangix: I wouldn't mind I and think nobody else neither
Dec 01 20:32:12 <ynezz> +1
Dec 01 20:34:18 <mangix> there are two packages looks like
Dec 01 20:38:53 <mangix> sent. forgot to put nbd in CC
Dec 01 20:39:01 <mangix> https://github.com/openwrt/packages/pull/14097
Dec 01 20:41:33 <rsalvaterra> mangix: WireGuard is *the* thing. :D
Dec 01 20:42:00 <mangix> right. but the longest time OpenVPN had the top spot AFAIK
Dec 01 20:42:05 <mangix> *for the
Dec 01 20:42:23 <rsalvaterra> Yeah, before WireGuard, to me, OpenVPN was the thing, for sure.
Dec 01 20:43:51 <mangix> in other news, /me hates windows update with a passion
Dec 01 20:44:03 <aparcar[m]> mangix: thanks for the quick rtt
Dec 01 20:45:30 <aparcar[m]> maybe I was wrong and nbd isn't even the maintainer.
Dec 01 20:45:43 <aparcar[m]> -PKG_MAINTAINER:=Felix Fietkau <nbd@nbd.name>
Dec 01 20:45:45 <rsalvaterra> mangix: I don't think I even know how to use Windows anymore… The last Windows I used daily was XP.
Dec 01 20:45:46 <aparcar[m]> oh he his
Dec 01 20:46:26 <aparcar[m]> mangix: do you feel like becoming the maintainer of openvpn in packages.git?
Dec 01 20:51:38 <mangix> aparcar[m]: not my laptop. and no. I don't use OpenVPN.
Dec 01 20:51:55 <mangix> Magnus might
Dec 01 20:51:59 <aparcar[m]> neoraider: ping
Dec 01 20:52:39 <mangix> speaking of Magnus, I should probably apply his patch.
Dec 01 21:00:20 <aparcar[m]> mangix: may put him in cc too
Dec 01 21:01:39 <mangix> hmm is he on GitHub?
Dec 01 21:02:45 <aparcar[m]> ¯\_(ツ)_/¯
Dec 01 21:05:05 <mangix> found him
Dec 01 21:07:04 <Hauke> adrianschmutzler: I just comitted an update of the kernel and support for an addition flash chip to 19.07, I have nothing else on my list
Dec 01 21:08:54 <stintel> so I'm giving wireguard another try, again not very successful. on one side it appears to work fine, on the other site I'm getting NO_DEVICE in ifstatus wg_vr0
Dec 01 21:09:18 <stintel> and no matter how many ifdown wg_vr0 ; ifup wg_vr0 I try, *nothing* changes, as if it completely ignores it
Dec 01 21:09:59 <stintel> https://bpa.st/4K4A
Dec 01 21:11:07 <aparcar[m]> s/#openwrt-devel/#openwrt/
Dec 01 21:11:10 <aparcar[m]> duck
Dec 01 21:11:25 <stintel> nah
Dec 01 21:19:12 <ldir-> quack
Dec 01 21:19:45 <stintel> reboot fixed it, so some stuck state in netifd or something I guess
Dec 01 21:19:45 <stintel> meh
Dec 01 21:22:45 <stintel> grmbl, after making changes and ifup, same problem
Dec 01 21:25:19 <aparcar[m]> ldir-: huh?
Dec 01 21:25:33 <ldir-> duck
Dec 01 21:25:49 <aparcar[m]> stintel: do both ends use the correct time?
Dec 01 21:28:27 <ldir-> it's not an 'ifconfig' funny is it?  does 'ip foo' work?
Dec 01 21:29:56 <stintel> aparcar[m]: the tunnel comes up after reboot, it's a local problem, ifdown wg_vr0 or ifup wg_vr0 are completely ignored
Dec 01 21:30:49 <ldir-> ignore me - ifup/down not ifconfig doh!
Dec 01 21:31:38 <stintel> running "wg" also displays nothing
Dec 01 21:32:06 <stintel> looks like I'm sticking with IPsec IKEv2 for a few more years until this thing becomes usable
Dec 01 21:36:52 <aparcar[m]> stintel: I guess you're missing some package or something, I've been using it for some time and it's great :)
Dec 01 21:38:09 <stintel> aparcar[m]: nothing is missing, the tunnel was up earlier
Dec 01 21:38:56 <stintel> it's just not normal that ifdown wg_vr0  or ifup wg_vr0 does absolutely nothing (nothing shows up in logread)
Dec 01 21:39:22 <stintel> pretty sure netifd is doing something funky, but that's such an undocumented black box that is impossible to debug
Dec 01 21:56:55 <mangix> jow: do the buildbots use debian stretch or buster?
Dec 01 22:09:14 <aparcar[m]> I think the old thing
Dec 01 22:18:17 <stintel>  /65
Dec 01 22:55:14 <mangix> aparcar[m]: https://github.com/openwrt/packages/pull/13800#issuecomment-736835903
Dec 01 22:55:27 <mangix> stretch uses python 3.5, buster uses 3.7
Dec 01 22:55:49 <mangix> I want to say that warning appears even with newer than 3.5 installs
Dec 01 23:20:47 <figgyc> bit of a weird one: is there a way to configure kmod-ledtrig-gpio in the dts? I'm porting to a device where one of the LEDs is designated for SD card presence, I know the GPIO which goes low when the SD card is detected so I'm wondering how I should implement that LED. Saw that kmod but I don't think it's actually being used anywhere, there isn't a ledtrig module specific to sdmmc
Dec 01 23:20:47 <figgyc> either. Is that even what it's designed for? thanks
Dec 02 00:30:27 <mangix> what the... https://www.crowdsupply.com/traverse-technologies/ten64
Dec 02 00:30:49 <russell--> yeah
Dec 02 00:31:10 * russell-- lives a mile from crowdsupply hq
Dec 02 00:31:19 <russell--> 2km
Dec 02 00:31:43 <mangix> DPAA2. I'm guessing this is powerpc
Dec 02 00:31:55 <russell--> arm, afaik
Dec 02 00:32:26 <mangix> oh wait isn't NPX the company that bought marvell?
Dec 02 00:32:33 <mangix> or was that broadcom
Dec 02 00:32:34 <russell--> NXP
Dec 02 00:32:37 <dorf> it is, mangix
Dec 02 00:32:50 <rsalvaterra> mangix: I… what…? Where the hell did that one come from? Looks really nice!
Dec 02 00:32:56 <dorf> *NXP
Dec 02 00:34:15 <russell--> kind of spendy, i'd be interested in a more trimmed down version, allegedly it'll be open-hardware, iirc
Dec 02 00:34:33 <dorf> lol @ spendy
Dec 02 00:34:41 <dorf> it makes the Turris Omnia look cheap
Dec 02 00:34:46 <rsalvaterra> RP-SMA connectors galore…! But… $650. :(
Dec 02 00:34:54 <mangix> I learned my lesson with the Turris Omnia
Dec 02 00:35:06 <mangix> no spending on expensive hardware
Dec 02 00:35:51 <rsalvaterra> mangix: I got myself two Omnias at the time. Absolutely no regrets (sold one in the mean time, though).
Dec 02 00:36:03 <russell--> fwiw, i asked for an evaluation model in their pre-launch period
Dec 02 00:36:57 <mangix> problem with mine is that I broke off one LED. I also fitted it with mikrotik minipcie cards. pretty disappointing.
Dec 02 00:37:06 * russell-- is interested in using something like it as an open-source fiber CPE
Dec 02 00:38:19 <mangix> having said that, mvebu is a pretty solid platform
Dec 02 00:38:26 <dorf> the only "issue" with that box is the binary blob for the ethernet. that's a shame.
Dec 02 00:38:32 <rsalvaterra> mangix: The broken LED isn't exactly a problem with the Omnia itself… :P
Dec 02 00:39:06 <mangix> right but the wifi is the biggest issue
Dec 02 00:39:14 <mangix> that's what I get for messing with it :)
Dec 02 00:39:20 <rsalvaterra> What MicroTik cards are you using?
Dec 02 00:39:36 <dorf> what's the issue with wifi on the omnia, mangix?
Dec 02 00:39:46 <rsalvaterra> mangix: I probably messed with mine more than you… :P
Dec 02 00:39:56 <mangix> https://git.openwrt.org/?p=project/iwinfo.git;a=commit;h=77a9e98009d43200ab7140acf1fdfd7d3b055c51
Dec 02 00:40:17 <mangix> and yes, the generic listing bothered me enough
Dec 02 00:41:26 <rsalvaterra> Wait, you replaced a QCA9880 card with another QCA9880 card…? Why?
Dec 02 00:41:39 <mangix> Because this one has a heatsink
Dec 02 00:42:25 <rsalvaterra> Hmm… heating problems? I don't remember ever having any issues with heat.
Dec 02 00:42:25 <mangix> I just noticed this crowdsupply thing has Turris Omnia in the comparison, LOL
Dec 02 00:43:06 <mangix> That no on XDP is very misleading
Dec 02 00:44:41 <rsalvaterra> It's not misleading, it's factually wrong, mvneta has XDP support.
Dec 02 00:44:55 <mangix> it's not that
Dec 02 00:44:59 <rsalvaterra> (Not on OpenWrt, though.)
Dec 02 00:45:11 <mangix> XDP can only be used with software buffer management
Dec 02 00:45:27 <mangix> mvneta in OpenWrt uses hardware buffer management
Dec 02 00:45:40 <rsalvaterra> Yes, but it can be disabled.
Dec 02 00:46:03 <mangix> sure. do note that XDP support is relatively new :P
Dec 02 00:46:18 <rsalvaterra> I don't know if the XDP benefits would outweigh the performance impact of software buffer management, though.
Dec 02 00:46:40 <mangix> my understanding is the new espressobin stuff uses software buffers
Dec 02 00:47:00 <mangix> at least that's what i got from lorenzo's description
Dec 02 00:48:02 <aparcar[m]> mangix: what's up?
Dec 02 00:48:20 <mangix> ?
Dec 02 00:53:02 <mangix> wtf. HWBM is only used by mvneta but is found under include/net
Dec 02 00:55:27 <mangix> OK. so hardware buffers are only supported on 38x/XP. And nowhere else.
Dec 02 00:55:44 <rsalvaterra> LOL?!
Dec 02 00:56:49 <rsalvaterra> Why not drivers/net/ethernet/marvell?
Dec 02 00:57:28 <mangix> I guess upstream expects more drivers to use hardware buffer management. But so far it's only marvell
Dec 02 00:58:35 <mangix> yeah, .compatible = "marvell,armada-380-neta-bm"
Dec 02 00:59:07 <mangix> git grep shows only 38x/xp dtsi file
Dec 02 00:59:09 <mangix> s
Dec 02 00:59:31 <mangix> so no 370 or arm64 stuff
Dec 02 01:00:25 <rsalvaterra> But I'd expect buffer management to be something very tightly tied to the specific hardware, not exactly generic.
Dec 02 01:00:39 <mangix> I wonder if the actual hardware doesn't support it or nobody has written a driver for it. Probably the former
Dec 02 01:01:12 <rsalvaterra> And there's also net/core/hwbm.c…
Dec 02 01:01:34 <mangix> looks like only three functions
Dec 02 01:02:43 <mangix> guess that's the non hardware specific stuff
Dec 02 01:02:47 <rsalvaterra> Yeah, the ones declared on the include/net/hwbm.h header.
Dec 02 01:02:53 <mangix> still weird
Dec 02 01:03:01 <mangix> since there's only one user
Dec 02 01:04:57 <rsalvaterra> Oh, well… enough weirdness for one day. Bed time. :P
Dec 02 01:53:38 <ynezz> stintel: running netifd in debug mode aka `netifd -d255 -l255` does wonders, feel free to document it https://openwrt.org/docs/techref/netifd
Dec 02 01:58:11 <ynezz> stintel: that -d is debug mask, bit 0 enables system messages, bit 1 enables device messages, bit 2 enables interface messages, bit 3 enables wireless messages
Dec 02 02:19:02 <aparcar[m]> mangix you pinged me with some comment of lighthttpd?
Dec 02 02:49:47 <mangix> did i?
Dec 02 02:54:46 <dorf> simple patch for lighttpd, for whoever's maintaining it: in lighttpd.conf -> server.tag = "<hostname"
**** ENDING LOGGING AT Wed Dec 02 02:59:57 2020