hzjnet

> 还是build variant: regular错误，估计是没人修了，我前面提过,但是大佬直接被关issue 最后还是参考其它issue用openwrt官方22.03或者master版本的mac80211直接替换就正常了，仅仅测试了ipq401x和ipq806x, 修改前mesh完全不能用，修改后mesh正常，仅发现mesh子网dns不正常外nss没测试其它都正常！ 今早恢复出厂模式后重新设置mesh就一切正常了

> 最后还是参考其它issue用openwrt官方22.03或者master版本的mac80211直接替换就正常了，仅仅测试了ipq401x和ipq806x, 修改前mesh完全不能用，修改后mesh正常，仅发现mesh子网dns不正常外nss没测试其它都正常！ > > 今早恢复出厂模式后重新设置mesh就一切正常了 最后测试还是用openwrt官方22.03的5.15.81版本mac80211稳定可用

> 这不是刚升级了么，你在编译试试呢 这问题存在几个月了，翻翻关闭的多个ath10k-ct错误issus就知道了；当然也能解决，但是麻烦；同时集成nss加速后影响mesh正常应用

> > > > > > > > > 今天又试了几次，只要加easymesh插件必出错。 > > 与我的测试结果相同，很可能是easymesh导致的。对了，从今天开始，源码同时导致无线无法正常驱动。 应该不是 我编译的无线正常

> Applying ./patches/988-ath10k-always-use-mac80211-loss-detection.patch using plaintext: patching file ath10k-5.15/mac.c touch /home/test/lede/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/ath10k-ct-regular/ath10k-ct-2022-05-13-f808496f/.prepared_a5b8a1f5c6fc141bd7bb7a275a6eade9_6664517399ebbbc92a37c5bb081b5c53 make[3]: *** No rule to make target '/home/test/lede/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/include/mac80211-backport/backport/autoconf.h', needed by '/home/test/lede/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/ath10k-ct-regular/ath10k-ct-2022-05-13-f808496f/.configured_68b329da9893e34099c7d8ad5cb9c940'. Stop. make[3]: Leaving directory '/home/test/lede/package/kernel/ath10k-ct' time: package/kernel/ath10k-ct/regular/compile#0.30#0.31#0.53 ERROR: package/kernel/ath10k-ct...

go版本升级后对应应用软件源码是不是应该由源码开发者自动升级更新啊？ 编译人员根本搞不懂喔

> ### 详细叙述 > 切换旧分支，以 20230609 为例 ./scripts/feeds update -a 后提示以下错误 > >  > > ### 重复 issue > * [x] 没有类似的 issue > > ### 具体型号 > N5105...

配置文件里面启用2行： CONFIG_VERSION_DIST="LEDExxxx" CONFIG_VERSION_NUMBER="cools-M-d20231218"

> 垃圾玩意 没事天天再升 这个xray 不知道一天哪来那么多更新 没事就更新go go一个编程语言非要没事去搞那个玩意，看下xray打个补丁给他降回去 看下可行不 内核版本不也是一样吗？ 修安全问题就行了，没事儿动不动该内核是不是也是吃饱撑了？（~~）

确实是automake版本问题，升级后好几个应用编译都有问题，回到1.15.1版本就正常了