03:17 <mangix> cool, util-linux update works

06:12 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

09:28 <aparcar[m]> jow: can you give me your thoughts on the AUTORELEASE feature? Do you think it's entirely broken?

09:28 <aparcar[m]> I'm thinking of changing the logic to use PKG_VERSION changes instead of looking for commit subjects containing "bump to / update to"

09:29 <aparcar[m]> but it all takes CPU time to juggle around Git, maybe the entire approach is just broken? Instead the CI could just warn users to fix their PKG_RELEASE

09:29 <aparcar[m]> then all logic would be in the CI and AUTORELEASE would be obsolete again

09:37 <aparcar[m]> Mangix: ping

10:59 <jow> aparcar[m]: I'd strongly favor a CI-driven solution that warns maintainers

10:59 <jow> aparcar[m]: inherent problem with AUTORELEASE is the fact that it needs an accompanying Git history

11:00 <jow> build such an (unmodified) Makefile against another tree or non-Git source tree and you get completely different results

11:01 <jow> also non-Makefile changes to packages cannot be judged by visiting (contents or modification times of) Makefiles alone

11:01 <jow> which also requires downstream tooling to have a complete Git history available

11:01 <aparcar[m]> so CI shouldn't fail in case PKG_RELEASE isn't changed but a warning should happen?

11:02 <jow> and finally the reliance on properly formatted Git commit subjects

11:02 <jow> yeah, a strong warning

11:03 <jow> a rough past definition was that PKG_RELEASE should only be bumped on functional changes

11:03 <jow> fixing whitespace or a typo in a Makefile wouldn't qualify for a bump

11:03 <aparcar[m]> I came up with a solution that doesn't rely on commit subjects here https://github.com/openwrt/packages/issues/14537#issuecomment-1127526012

11:03 <jow> fixes to init scripts, modified compile flags etc. would

11:03 <aparcar[m]> but the point still exists that Git is required.

11:04 <aparcar[m]> if the typo results in a different binary (e.g. the description changed) it should change the release since both package artifacts are different, even if it's just the accompanying metadata

11:05 <jow> fair enough

12:24 <aparcar[m]> jow: please comment on https://github.com/openwrt/openwrt/pull/9893

12:41 <jow> aparcar[m]: git log --format=%h -1 -G '^(PKG_RELEASE|PKG_VERSION|PKG_SOURCE_DATE)' -- Makefile

13:07 <stintel> blocktrron: did you see my pm ?

13:18 <blocktrron> stintel: i guess no?

13:18 <blocktrron> Ah wow

13:18 <blocktrron> yes, it is there but i got no notification

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

15:24 <stintel> hmmm so on the EAP615 the wifi radio is DBDC, and there is only a single MAC address in the device flash. I couldn't use offset in the DTS because that would cause conflicts between my 2 APs, but now I have 2.4 and 5 GHz networks on the same AP with the same BSSID, so 802.11v transition request doesn't work properly. do we have some mechanism already to avoid duplicate BSSID like this?

15:48 <stintel> guess I'll have to use macaddr_add in target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac

15:49 <stintel> anyone with an EAP615 running stock to confirm that's how it works?

15:49 <stintel> would be nice though if this could be handled in the driver, albeit with a flag in the dts

16:53 <stintel> I guess the problem is that using nvmem-cells on mt76 dbdc radio bypasses the logic to not have overlapping MAC adresses :/

16:53 <stintel> nbd: any thoughts?

17:17 <Slimey> it's that most wonderful time of year when all the students are gone :D

18:16 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 95.7% packages reproducible in our current test framework.)

19:57 <owrt-snap-builds> Build [#642](https://buildbot.openwrt.org/master/images/#builders/2/builds/642) of `layerscape/armv7` failed.

20:07 <owrt-snap-builds> Build [#551](https://buildbot.openwrt.org/master/images/#builders/10/builds/551) of `bcm63xx/smp` failed.

20:47 <owrt-snap-builds> Build [#556](https://buildbot.openwrt.org/master/images/#builders/15/builds/556) of `armvirt/64` failed.

23:34 <owrt-snap-builds> Build [#543](https://buildbot.openwrt.org/master/images/#builders/31/builds/543) of `layerscape/armv8_64b` failed.