00:46 <owrt-images-builds> Build [#5](https://buildbot.openwrt.org/images/#/builders/110/builds/5) of `master_zynq/generic` completed successfully.

00:54 <owrt-images-builds> Build [#5](https://buildbot.openwrt.org/images/#/builders/45/builds/5) of `master_sunxi/cortexa7` failed.

01:03 <Namidairo> the antennas look shared, there's 2.4g and 5g leads coming off them in the cad drawing that was bundled in the fcc filing

08:41 <mrkiko> neggles: thanks a lot for the pointer. So it can be DBDC or not, did I understand right?

08:46 <mrkiko> slh: these are not connected to pci

09:02 <gch981213> mrkiko: mt798x-wmac is a DBDC device. It's one mac which can drive one or two RF chip(s).

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

09:18 <neggles> mrkiko: it should be able to do DBDC, but based on some comments in upstream patch discussions from mediatek staff, it depends on the specific board implementation

09:19 <neggles> it looks like the "non-dbdc" setup is intended for when you're only using one of the two PHY interfaces on the WMAC

09:20 <neggles> or for when it's being used with the cheapo PHYs

09:25 <neggles> ah, sorry, I misread - the pinctrl change for "DBDC mode" vs "2G+5G mode" is just different funcs on the same pins, so yeah, it should just be DBDC capable end of story

09:29 <neggles> but it *is* configurable as to whether it actually runs in DBDC mode or not, so might need a DT tweak or caldata to work?

13:54 <mrkiko> neggles: thanks a lot! Isn't the *dual.bin or *dbdc.bin file usage for eeprom data usage an indication? And, uncorrelated - what are DBDC limitations on modern designs ?

13:56 <slh> on the typical mt7621a+mt7915DBDC, the drawback is obvious, cutting the 4x4 radio into two 2x2 radios - but the gl-mt6000 retains 4x4 for both bands

14:14 <mrkiko> slh: thanks. So the commit message wasn't misleading at all. So then the design becomes as good as fast you are in switching antennas or something like that; I know very little about electronic per se

14:21 <mrkiko> slh: or maybe totally different methodology used for sharing

15:02 <rmilecki> [2023-12-22] [09:43:18 CET] <rmilecki> i can't get much help on this, I think I'll just push:

15:02 <rmilecki> [2023-12-22] [09:43:19 CET] <rmilecki> [PATCH RFC] base-files: execute package's "postinst" after executing uci-defaults

15:02 <rmilecki> [2023-12-22] [09:43:19 CET] <rmilecki> https://patchwork.ozlabs.org/project/openwrt/patch/20231126202428.1158-1-zajec5@gmail.com/

15:02 <rmilecki> ok guys, patch pushed

15:03 <rmilecki> blame me if something fails

15:03 <rmilecki> if it cannot be fixed in a sane way, we can revert abov

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

16:56 <mrkiko> rmilecki: eh, I acknowledge it's really too late, but I would have NACK'ed this patch, for what it counts (and I acknowledge it counts 0 (.

16:56 <rmilecki> mrkiko: i really tried to get some feedback ;)

16:56 <mrkiko> rmilecki: I also didn't follow enough the process behind this patch so ... can't really say much

16:57 <mrkiko> rmilecki: yeah, you're right

16:57 <rmilecki> what's potentially wrong about it?

16:57 <mrkiko> rmilecki: I think that postinst != post-boot, and also am worried that people performs write operations in post-inst because - well, it's postinst. I am not a fan of write operations after every boot and they already happen, so it would be great to not add more

16:58 <mrkiko> rmilecki: I think we are sending the wrong message to packers

17:04 <rmilecki> mrkiko: i'm not sure if I understand

17:04 <rmilecki> mrkiko: postinst doesn't get executed on every boot

17:04 <rmilecki> it wasn't before my change and it isn't now

17:05 <mrkiko> rmilecki: also, mod-ubus installation after installing uhttpd seems more a corner case in itelf rather than people using postinst to modify the filesystem. So much that restarting uhttpd just in mod-ubus package would, in my 2 cents, be acceptable as hacky as it is. Given that it's good to be able to install luci and use it with no reboot

17:05 <mrkiko> ah ok, so I am totally off

17:07 <mrkiko> I misread the commit, lookign at the patch clarifies things little more

17:07 <rmilecki> :)

17:07 <rmilecki> yeah, i'm not a perfect changes description writer

17:08 <rmilecki> (i'm really trying thought!)

17:08 <rmilecki> *though

17:09 <mrkiko> rmilecki: you're great, it's me doing wrong connection; "after executing uci-defaults" did trip me into thinking that after each boot, after executing uci-defaults the system would unconditionally execute packages postinst

17:10 <mrkiko> rmilecki: which may make sense if you write postinst with that in mind

17:10 <rmilecki> ahh

17:10 <rmilecki> i see how it could be misread

17:11 <mrkiko> rmilecki: but if I did look at the patch without bothering you first :) :) ... I would have seen you change the default_postinst function - which BTW I never looked at / never looked where it's called, so ... sorry for the noise

17:13 <rmilecki> np

17:13 <rmilecki> now let's see if that actuallt blows up some packages ;)

17:14 <rmilecki> i already sent a follow-up patch for uhttpd:

17:14 <rmilecki> [PATCH] uhttpd: handle reload after uhttpd-mod-ubus installation using postinst

17:14 <rmilecki> https://patchwork.ozlabs.org/project/openwrt/patch/20231227152045.18336-1-zajec5@gmail.com/

17:14 <rmilecki> which I think is a nice to have cleanup and hopefully I can push it soon

17:51 <mrkiko> :)