02:48 <owrt-images-builds> Build [#23](https://buildbot.openwrt.org/images/#/builders/140/builds/23) of `openwrt-22.03_ipq806x/generic` completed successfully.

10:39 <owrt-images-builds> Build [#97](https://buildbot.openwrt.org/images/#/builders/197/builds/97) of `openwrt-23.05_mvebu/cortexa53` failed.

14:13 <schmars[m]> we have pretty bad connectivity to fastly @ frankfurt from berlin, like <= 10 mbps from a berlin datacenter. only got bad in the last couple of weeks. is fastly receptive to peering recommendations? :) cc ynezz

14:54 <dangole> schmars[m]: does that apply to all files on the mirror? and does it also apply when you download the same file again within a short amount of time? I'm asking because I've experienced that bottleneck to be between fastly and the openwrt.org primary site rather than being between fastly and the client.

15:03 <schmars[m]> yeah all files, we're using imagebuilder a lot so we notice stuff like this fast. BUT to be fair we havent isolated this to just fastly yet. e.g. the fedora mirrors are slow too (not a cdn) while google's infra is fast

15:04 <schmars[m]> our peering is usually pretty good thanks to community-ix.net

19:11 <owrt-images-builds> Build [#301](https://buildbot.openwrt.org/images/#/builders/231/builds/301) of `master_mpc85xx/p1010` completed successfully.

19:18 <hauke> Ansuel: Hi, Should I remove the target/linux/bmips/patches-5.15/203-mips-bmips-dma-fix-CBR-address.patch patch in 5.15.162 after your upstream change? https://github.com/openwrt/openwrt/pull/15901#discussion_r1667772246

19:19 <Ansuel> only the first part

19:20 <Ansuel> the second hunk is needed and handled differently upstream

19:20 <Ansuel> ok actually no keep it as is

19:21 <Ansuel> (unless we want to backport the patch but that is way too much work)

19:26 <hauke> Ansuel: ok thanks

22:42 <owrt-images-builds> Build [#301](https://buildbot.openwrt.org/images/#/builders/145/builds/301) of `master_octeon/generic` completed successfully.