**** BEGIN LOGGING AT Tue May 25 03:01:36 2021
May 25 07:10:02 <Pepe> slh: You haven't even read the commit message, which is there. It explains that package  brcmfmac-firmware-43455-sdio is provided by cypress-firmware
May 25 07:10:40 <Pepe> And that the files were removed from linux-firmware. Upstream change and it is even referenced there.
May 25 07:25:04 <slh> Pepe: you're right, I didn't expect a conflicts/ provides relation (but yeah, broadcom vs cypress explains a lot), especially as I failed to get that working properly in the past (for iw/ iw-tiny, and ip/ ip-tiny)
May 25 12:29:52 <plntyk> updated the bugticket regarding Fedora "make prereq" fail - changes in which packet triggered it - but dunno how / if / what "shell magic" is the correct way to fix - https://bugs.openwrt.org/index.php?do=details&task_id=3809
May 25 12:33:11 <karlp> it's something to do with the enrivonment that the check runs in, I tried and failed to work around it too.
May 25 12:33:22 <karlp> also note that FORCE=1 won't actually force past this either :|
May 25 12:33:34 <karlp> I just removed the check.
May 25 15:29:53 <rmilecki> nbd: https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=62e3cb52941032e13a8ad421454b9bc93382ef75 ("scripts/netifd-wireless.sh: add support for specifying the operating band")
May 25 15:30:00 <rmilecki> nbd: doesn't it break some existing setups
May 25 15:30:01 <rmilecki> ?
May 25 15:30:15 <rmilecki> it leaves unused "enable_ht" variable
May 25 15:49:32 <nbd> rmilecki: the variable was only used for a legacy hwmode syntax (11na/11ng) which hasn't been used in many years
May 25 15:50:28 <rmilecki> ah, it's about "hwmode_n", i don't recognize that indeed
May 25 15:50:38 <rmilecki> nbd: you may consider dropping that variable + dead code though
May 25 15:50:47 <nbd> right
May 25 15:51:00 <rmilecki> [ "$enable_ht:$wpa_cipher" = "1:TKIP" ] && wpa_cipher="CCMP TKIP"
May 25 15:51:06 <rmilecki> :)
May 25 16:26:21 <rmilecki> we have 13 new commits in netfid since 21.02 branching: https://git.openwrt.org/project/netifd.git/shortlog/c00c8335d618..master
May 25 16:26:22 <rmilecki> nbd: Hauke: do we wany some/all of them for 21.02?
May 25 16:33:15 <Hauke> I do not know I am not an expert in this area
May 25 16:55:31 <plntyk> xdarklight, any idea how to fix USB3 Etron EJ168A on a WLR-8100v1 ? (https://bugs.openwrt.org/index.php?do=details&task_id=3824)
May 25 17:33:35 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.1% packages reproducible in our current test framework.)
May 25 17:44:14 <aparcar[m]> anyone ever used `patch-cmdline`?
May 25 17:44:40 <aparcar[m]> it doesn't appear to be much around in openwrt.git anymore, I'm wondering if I could still use it to mess around with a per device running cmdline
May 25 17:45:11 <aparcar[m]> nbd: I'd like to merge this, https://patchwork.ozlabs.org/project/openwrt/patch/20210413122218.GA5777@darth.lan/ thoughts?
May 25 17:47:00 <nbd> aparcar[m]: ack
May 25 17:47:16 <nbd> rmilecki: i think we want to keep 21.02 netifd in sync with master at this point
May 25 17:48:29 <aparcar[m]> nbd: should I remove the comments or keep them?
May 25 17:49:04 <aparcar[m]> nbd: also since you worked on patch-cmdline aka patch-image, do you know if there is a reason against using it?
May 25 17:50:20 <nbd> i think with boards using device tree, we shouldn't need to patch the cmdline
May 25 17:51:06 <aparcar[m]> nbd: can we sneak in a "openwrt_profile" into the device tree so it end's up somewhere readable on the board?
May 25 17:51:20 <aparcar[m]> *on the running device
May 25 17:52:46 <nbd> interesting idea
May 25 17:57:04 <aparcar[m]> nbd: if we add it next to dts model/compatible, will it be in /proc/?
May 25 17:59:13 <aparcar[m]> what qemu compatible target uses dts?
May 25 18:00:33 <nbd> i think it all ends up in /proc/device-tree
May 25 18:01:22 <aparcar[m]> excellent
May 25 18:01:38 <aparcar[m]> which targets are lacking dts support?
May 25 18:01:41 <aparcar[m]> #x86
May 25 18:42:07 <PaulFertser> aparcar[m]: also, /sys/firmware is the sysfs interface to the whole DT
May 25 18:42:55 <aparcar[m]> sounds good
May 25 18:43:15 <aparcar[m]> can we port x86 to dts?
May 25 18:49:57 <PaulFertser> aparcar[m]: sounds unlikely :) In PC (and ARM servers) world there're certain ACPI tables that tell the kernel about present hardware. That said, probably a dummy DT can be added but that would be an odd hack I guess.
May 25 18:52:25 <rmilecki> nbd: thanks for looking at that (netifd)
May 25 18:53:04 <aparcar[m]> rmilecki: do you plan to backport all the netifd stuff?
May 25 18:53:11 <rmilecki> aparcar[m]: i'll tomorrow
May 25 18:53:24 <aparcar[m]> PaulFertser: are you aware of a slim grub alternative?
May 25 18:54:36 <aparcar[m]> rmilecki: exciting... isn't that a bit of a big backport for a rc?
May 25 18:55:01 <rmilecki> aparcar[m]: it is, that's why I asked nbd for opinion
May 25 18:55:18 <rmilecki> aparcar[m]: he probably the most familiar with netifd
May 25 18:55:25 <nbd> needs to be carefully tested though
May 25 18:56:47 <rmilecki> ok, i'll make sure we ask for testing on rc2 release
May 25 18:56:50 <rmilecki> (notes)
May 25 19:00:35 <aparcar[m]> nbd: any more elegant way to insert openwrt_profiles=<foobar> into all dts builds without modifing all dts files?
May 25 19:00:41 <aparcar[m]> like...a meta dtsi file
May 25 19:01:25 <aparcar[m]> also this current approach wouldn't work for dts files which are already upstream...
May 25 19:04:43 <PaulFertser> aparcar[m]: I'm afraid there's anything with comparable featureset. EFI systems can boot Linux directly as an EFI executable.
May 25 19:07:01 <Pepe> Are there any plans to backport FragAttacks fixes and add ath10k-ct into OpenWrt 19.07?
May 25 20:46:40 <Hauke> Pepe: I am watiting till the FragAttacks patches show up in the 4.19 stable kernel to backport them to 19.07
May 25 20:47:07 <Hauke> Pepe: it should not be so hard to also add them to ath10k-ct then
May 25 20:47:43 <Hauke> currently I am wating for someome testing the FragAttacks patch for ath10k-ct on master and 21.02
May 25 20:50:51 <Hauke> rmilecki: the bcm4908 imagebuilder from 21.02 snapshot fails like this:
May 25 20:51:00 <Hauke> cp: cannot stat '/home/hauke/openwrt/imagebuilder/openwrt-imagebuilder-21.02-SNAPSHOT-bcm4908-generic.Linux-x86_64/build_dir/target-aarch64_cortex-a53_musl/linux-bcm4908_generic/bcm63xx-cfe/asus,gt-ac5300/cferam.000': No such file or directory
May 25 20:51:03 <xdarklight> plntyk: to be honest: I have no idea. on an ath79 SoC it "just" works for me. my suggestion: take it to the upstream linux-usb maintainers and ask for some debugging advice there
May 25 20:51:06 <slh> aparcar[m]: for BIOS booting, syslinux/ extlinux works o.k., for uefi gummiboot (now part of systemd) works rather nicely as well - but grub is the only real solution that works for both (and pretty much the same)
May 25 21:06:21 <aparcar[m]> slh: thank you
May 25 21:10:49 <wvdakker> Hi, I have a problem after upgrading from 19.7 to 21.2. After installing my custom build kernel (same config as in 19.07) I lost my WiFi. The log does not show any errors, but also no 80211 messages. Before I report a bug I want to be sure I am not overlooking something. Here is my log https://pastebin.com/JYu224iU
May 25 21:11:47 <wvdakker> By the way, only a custom kernel will work for the Zyxel 2812 F1. The download on the openwrt site is broken
May 25 21:18:58 <anon^_^> Hauke, nbd
May 25 21:19:00 <anon^_^> http://lists.openwrt.org/pipermail/openwrt-adm/2021-May/001970.html
May 25 21:19:08 <anon^_^> https://www.devever.net/~hl/freenode_abuse
May 25 21:32:53 <rmilecki> Hauke: i don't understand that error :| i see that file locally
May 25 21:33:25 <rmilecki> Hauke: can it be packaging problem? missing PKG_SOURCE_DATE?
May 25 21:34:40 <Hauke> rmilecki: I see a similar problem with the lantiq/xrx200 imagebuilder
May 25 21:34:49 <Hauke> there also a file is missing
May 25 21:35:15 <Hauke> rmilecki: will you merge the netifd update tomorrow?
May 25 21:35:48 <rmilecki> Hauke: i will
May 25 21:36:16 <rmilecki> Hauke: but we still need help from jow on LuCI
May 25 21:36:29 <rmilecki> Hauke: I don't feel experienced with LuCI enough to know what to backport
May 25 21:37:38 <Hauke> rmilecki:  me too
May 25 22:32:15 <philipp64|laptop> jow: what do you think of the email I just sent out with "Subject: 'config route' extension for more compact notation"
May 25 23:57:13 <mirko> nbd: i'm having a question about c46ccb69: commit msg just speaks of uplevelling, however it introduces a complete new realtek PHY driver stack. where is this code coming from? I'm asking in aprticular as it introduces support for rtl8363 and I wonder what's the original source of that (target/linux/mediatek/files-5.10/drivers/net/phy/rtk/rtl8367c/rtk_switch.c)
May 25 23:59:15 <mirko> nbd: nevermind, it was just the move 5.4 -> 5.10 and i got confused
**** ENDING LOGGING AT Wed May 26 03:00:34 2021