02:06 <grid> hey, i'm trying to bring up a compex 802.11be ath12k card (QCN6224 - which isn't supported at all, i know - but there is a pending PR to enable ath12k) on tip of master. i tried firmware from https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware.git and get a mismatch in board-2.bin: https://paste.ee/p/bdXKg#j7XqaBGuKV_QfuEhb4qlyvPNSg9RBNxJ

02:07 <grid> is this something compex would need to provide? or qualcomm? the available public board.bin has board id 1, it appears the compex card is looking for 4634

06:57 <jow> Mangix: I might have a wndr4700 lying around

06:57 <jow> Mangix: what's needed? a boot test + iperf session?

08:45 <Mangix> jow: DSA conversion

08:45 <Mangix> https://github.com/openwrt/openwrt/pull/14037

09:35 <owrt-images-builds> Build [#331](https://buildbot.openwrt.org/images/#/builders/78/builds/331) of `master_ramips/rt305x` failed.

09:35 <owrt-images-builds> Build [#323](https://buildbot.openwrt.org/images/#/builders/205/builds/323) of `master_mpc85xx/p1020` completed successfully.

09:47 <opty> hello, why auc offers '23.05-SNAPSHOT r24021-6edde2b502' but web 'SNAPSHOT (r27052-4e6212e62f)'? o_O

09:48 <opty> also, how can i easily check which one contains https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=901adc3f2f651bd852de6ad4790e01ea9829eb75 ?

09:49 <opty> e.g. https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=6edde2b502 returns 'No match.' :/

10:22 <mrkiko> rmilecki: hi!!

10:36 <mrkiko> Did my last env layouf fix patch reach theML or did I do something wrong?

10:37 <robimarko> Yeah, its there

10:39 <mrkiko> thanks...

11:08 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

13:45 <kabel> robimarko: do you know if there is a maintainer for the mvebu platform? I'd like to get the Turris Omnia PR (13799) moving

13:57 <robimarko> kabel: there are no dedicated maintainers

13:58 <robimarko> I will take a look

14:07 <kabel> robimarko: thanks! the last CI failed because for some reason one test got cancelled. I don't know why. Previously some tests failed so I had to refresh kernel patches on various platforms. Now it all passed but for one test, which did not fail but got cancelled instead...

14:10 <stintel> russell--: we never managed to get network up and running on the M200

14:10 <stintel> but iirc the M300 mobo is also marked MB-M200

14:11 <stintel> I can't check, the M300's are still in my apartment but I've been living in my house for the past 3 months

14:14 <rmilecki> would that make sense to modify "opkg" to return error code for missing package?

14:15 <rmilecki> # opkg info whoami; echo $?

14:15 <rmilecki> 0

14:16 <rmilecki> (i expected error code and not 0)

14:23 <schmars[m]> aren't we about to switch to APK soon anyway?

14:45 <rmilecki> maybe, I guess

14:45 <rmilecki> still I'm working on the latest stable branch and found it a problem

14:46 <schmars[m]> yeah exit != 0 definitely seems sensible

14:57 <robimarko> kabel: No worries about CI.

14:57 <robimarko> BTW, any reason not to backport those patches only to mvebu target?

14:57 <robimarko> I dont really see a reason for them to go into generic

15:10 <kabel> I thought that upstreamed patches should go to generic

15:11 <kabel> I can move them to mvebu, though, if it will make things easier...

15:13 <robimarko> Please do as they affect only mvebu

15:14 <kabel> ok

15:27 <kabel> I pushed it, but am also rebuilding, just to be sure

15:27 <kabel> in the meantime, what do you think about PR 15990 ?

15:28 <robimarko> The BTRFS one?

15:33 <kabel> yes

15:36 <robimarko> I need to look into it, I dont have anything specialy against

15:36 <robimarko> But, I dont understand why should we make BTRFS special

15:41 <kabel> I could add more of them, for exampel all that have the config option KERNEL_fsname_FS_SECURITY

15:42 <kabel> but I don't know if some target config files do not overwrite those

15:42 <kabel> when adding btrfs, I had to update layerscape config files and .mk files to add dependency

15:44 <kabel> so I think the other ones should be done separately (at least multiple commit messages)

15:44 <kabel> (*commits)

15:46 <kabel> or we could do this for ext4, f2fs, ubifs, jffs2 and squashfs ? all these could potentially be root filesystem

15:50 <robimarko> If we are going to have this, then it would be great for the common FS-es

15:50 <robimarko> Do we need JFFS2 anymore?

15:56 <kabel> I don't know, probably not

15:57 <kabel> ok, I will look into adding more of them: ext4, btrfs, f2fs and ubifs

16:01 <hurricos> mrnuke: pong, returned. I might have missed some stuff.

16:01 <hurricos> mrnuke: I just doubt it a little bit, protection on STM32 ICs is kind of overkill considering the entire point of the platform is a simple open cheap common core with decent peripherals

16:01 <hurricos> given that it's just acting as a proxy ....

16:02 <mrnuke> hurricos: https://github.com/Hurricos/realtek-poe/pull/36 ?

16:03 <mrnuke> Silicon is free. die area is expensive. If you have the die area on STM32, why not use it?

16:03 <hurricos> mrnuke: Have you tested on your own hw?

16:03 <mrnuke> Yes

16:03 <hurricos> I mean, it'

16:03 <hurricos> you're

16:03 <hurricos> if I had to hire someone to develop me some C I'd ring you up, let's just say that

16:03 <hurricos> I trust you know what you're doing

16:03 <hurricos> I can zip back and tell the package maintainers wait wait

16:03 <hurricos> take this higher bump instead ;^)

16:03 <hurricos> but

16:03 <hurricos> RE: https://github.com/openwrt/packages/pull/24626

16:04 <hurricos> I agree, best to get it out the door.

16:04 <hurricos> On the other hand? It seems moot considering I think realtek is going to be dropped from snapshot

16:04 <hurricos> I have to go pick up sandwiches so I'll be back

16:04 <mrnuke> Not necessarily. It gets stuck at 23.05. Those devices don't magically stop working

16:05 <hurricos> packages doesn't get rebuilt for 23 unless I make a new PR to backport to the 23 branch

16:05 <hurricos> just thinking about rushing to bump that one PR

16:06 <mrnuke> I wouldn't worry about putting the refactorings in openwrt feeds. There's no functional change

16:09 <mrnuke> hurricos: don't forget to tag ea32075 in git if we will be using the "v1.1" name for it

16:16 <hurricos> fair

16:16 <hurricos> ea32075?

16:17 <hurricos> mrnuke: does this suffice? https://github.com/openwrt/packages/pull/24626/commits/cc2218e553d148eb8ae85419634e5dcd9a60a5db#diff-2da3364b09596d79342d3e27609ad8c1dc231fcdca90b9fd268666c740e85853R12

16:19 <mrnuke> hurricos: nope. You need to do it in realtek-poe: `git tag v1.1 ea32075 ` and `git push --tags`

16:40 <kabel> robimarko: the Omnia PR is ready with those patches moved to mvebu

18:03 <owrt-images-builds> Build [#321](https://buildbot.openwrt.org/images/#/builders/96/builds/321) of `master_qualcommax/ipq807x` failed.

19:17 <PixelHir> hey, dropping in for a quickversion, im trying to build latest tailscale package and while it builds fine for older versions, newest one (1.70.0) requires golang ver 1.22 (buildroot has 1.21). Could anyone help me out and tell me if it's possible to upgrade buildroot's golang and if yes - how would I do that? Thank you.

19:17 <PixelHir> dropping in for a quick question* (i type without thinking)

22:18 <hurricos> mrnuke: done

22:55 <mrnuke> hurricos: Excellent! https://github.com/Hurricos/realtek-poe/releases/tag/v1.1