05:02 <owrt-images-builds> Build [#39](https://buildbot.openwrt.org/images/#/builders/148/builds/39) of `openwrt-23.05_mvebu/cortexa53` completed successfully.

05:25 <Edu4rdSHL> I have a setup where I build custom images for different devices. I want to use ccache, so my question is: is this sufficient to enable ccache on the build options (CONFIG_CCACHE=y) for each image, or do I need something else? Does ccache will use the same .ccache directory for all the builds (there are several subtargets that share packages, for example)?

05:26 <Edu4rdSHL> Thanks in advance. Also, any other recommendation for the setup is welcome. I was thinking about CCACHE_DIR=, for example

11:12 <hitech95> is there any procedure to ask for a python3- package to be made?

12:22 <schmars[m]> efahl: happy the luci thing is fixed :) - but so sad that the AI attacks are draining so much energy that it's hard to recognize the real bugs in all the noise. fuck AI

13:18 <efahl> scharms[m]: yeah, it's a never ending battle, I'm hoping the humans win it in the end 😁

13:20 <Rondom> hauke: I am running the image now on mt7621 and I am working from home using the wifi and wifi performance is as good as on master. One thing I noticed is that my Samsung mobile and FireTV show RX as "6.0 Mbit/s, 20 MHz" in LuCI, but as soon as I do some traffic from those devices it will move to 40 or 80Mhz and faster modulations. So, I guess this is fine and some powersaving thing. It is just that I have never seen it on 24.10 or master,

13:20 <Rondom> or it could be a regression on master/24.10. Not too familiar with WiFi details. Given that speed is fine, I think we can ignore it for 23.05 at least

13:55 <Rondom> hauke: Regarding MRs, I would really like https://github.com/openwrt/packages/pull/26842 to make it for 23.05 so that sdwalker's analysis gives a more realistic view of the security of 23.05 and . I care a bit about https://github.com/openwrt/openwrt/pull/19485 as well. I do not care at all about https://github.com/openwrt/openwrt/pull/19525, it was just something that I stumbled over.

15:37 <castiel652> djfe: ping

15:54 <djfe> yeah?

15:55 <djfe> :)

16:10 <castiel652> How many clients do you have on the ath10k AP? I am trying to reproduce the flush error.

18:29 <fidodido> Hi All. Why the mt7620n.dtsi use compatible = "ralink,rt2880-pinmux"; istead of compatible = "ralink,mt7620-pinctrl"; ?

18:57 <Edu4rdSHL> I wonder how safe is it to use ccache for openwrt builds

18:58 <Edu4rdSHL> for production builds* ups

19:03 <owrt-images-builds> Build [#264](https://buildbot.openwrt.org/images/#/builders/24/builds/264) of `main_mvebu/cortexa53` completed successfully.

20:50 <djfe> castiel652 hopefully you see this in the history

20:50 <djfe> https://map.aachen.freifunk.net/#!/de/map/d88466be4b40

20:51 <djfe> number of clients doesn't matter

20:51 <djfe> frequency of clients leaving the access point matters

20:51 <djfe> for the ath10k flush transmit queue error

20:52 <djfe> public wifi with known ssids are prone to be triggered more often because of people passing the crowded street in a city

20:54 <djfe> https://grafana.ffac.rocks/d/000000002/node?refresh=1m&orgId=1&var-node=d88466be4b40&var-saveinterval=1m&from=now-7d&to=now&timezone=browser&var-select_hostname=Beginenstrasse-15-EG&var-hostname=ffac-seilpforte-L4L-3825i-01&var-nodetolink=0c0e76cf3adc

20:54 <djfe> this one is running with the fix from upstream nkw

20:54 <djfe> *now

20:56 <djfe> each client leaving wifi ath10k triggers a 5 second timeout and drops the traffic that was about to be send

20:58 <djfe> https://patchwork.kernel.org/project/linux-wireless/patch/17d26d6a3e80ff03939ee7935fdc07f979b61a4f.1732293922.git.repk@triplefau.lt/

23:01 <swalker> wasn't there a time when "data" file updates were discouraged in packages? constant v2ray-geodata bumps