05:36 <owrt-images-builds> Build [#128](https://buildbot.openwrt.org/images/#/builders/70/builds/128) of `openwrt-24.10_mvebu/cortexa53` failed: failed Packages built (failure)

05:40 <russell--> Moe1978: define "quite motivated"

05:46 <russell--> do you have links to the threads, my searching on your model number has not turned up such threads for me

06:38 <Moe1978> quite motivated = prior professional embedded experience (albeit none with openwrt), and commercially backed

06:39 <Moe1978> it is a supply chain and regulation matter: I can get a bunch of those devices cheaply in a country where some of the more modern counterparts are specifically precluded to operate.

06:46 <Moe1978> these are the threads: 1) https://forum.openwrt.org/t/help-adding-support-for-sxt-g-2hnd/1441/5 and 2) https://forum.openwrt.org/t/mikrotik-sxt-5hpnd-help/187728

06:50 <Moe1978> I'm trying to find the thread where someone did a solder job on the serial pins. it was the exact same solder job I did only to discover in the thread that the pins were electrically disconnected from serial (possibly by software config) at boot.

06:53 <Moe1978> I've found that generally the model numbers are red herrings, so to speak. The real important information is that this device is the 128MB version with a mipsbe arch.

06:55 <Moe1978> The current state I'm in is that I know I can do the try-ethernet- option and get it to bootp fetch an image. After that, I am in what appears to be a blind stretch where I don't have access to any form of IO (specifically UART) until boot is complete. Clearly, the thing hangs on boot, however it's not totally clear to me whether it fails at the boot loader, or just brings up a bricked linux OS.

06:55 <Moe1978> from my understanding, the RX/TX lines are either disconnected at a hardware level, or are disabled by the bootloader firmware.

06:56 <Moe1978> Also, the firmware is an issue: moving forward, the issue of the routeros 7+ firmware will need to be resolved anyways, so this is yet another bite to chew off, I guess - as in, we can't just hope for the best that all devices moving forward will have a factory firmware <7.

06:59 <Moe1978> my strategy was to try and get a minimal openwrt build that would send out a sign through any means (e.g. LED blink) to indicate that it is indeed booting.

07:00 <Moe1978> I guess one of the issues I haven't fully digested is why the 7+ bootloader is a no go.

07:01 <Moe1978> (btw, there are some other threads out there. I have found around half a dozen through various searches, but all are of abandonned efforts at various stages)

13:28 <neocturne> nbd: are there any news on the wphy renaming issue we talked about a while ago? Anything I can help with if you didn't get around to it?

14:36 <f00b4r0> do we have a platform/channel for publishing development bounties?

18:33 <hurricos> robimarko: are you willing to merge https://github.com/openwrt/packages/pull/25551 (the realtek-poe change which builds config from board.json)?

18:34 <hurricos> The last gotcha was this thread - https://github.com/openwrt/packages/pull/25551#discussion_r1885007674 - RE: the Makefile. It works under apk and per @howels testin on opkg -- I see no concerns TBH and it ties the bow on the default-config being correct.

19:31 <f00b4r0> I need a build system guru to tell me why I'm doing something stupid

19:31 <f00b4r0> this change: https://github.com/f00b4r0/uspot/commit/1fb546fbb10f90e8442a7f60ae8e508fb72a34e9 results in ninja complaining that:

19:31 <f00b4r0> ninja: error: unknown target 'uspot'

19:32 <f00b4r0> can't figure that one out

19:32 <f00b4r0> all the binaries are successfully built, it seems it's some packaging step that's failing

19:36 <robimarko> hurricos: done

19:51 <f00b4r0> if I remove the define Build/Compile section it works again (although the bpf module isn't built obviously). I lifted that from qosify build recipe though

20:01 <f00b4r0> ha. s+$(Build/Compile/Default)+$(call Build/Compile/Default,)+ apparently makes it work again. The former is used in qosify and bridger, latter comes from unetd Makefile. WTH shrug

20:30 <hurricos> robimarko: Thank you :^)

20:30 <hurricos> nwm

21:12 <dwfreed> f00b4r0: because the cmake Build/Compile/Default passes $(1) to ninja as a target; qosify and bridger have targets named after themselves, uspot does not

21:13 <dwfreed> f00b4r0: $(Build/Compile/Default) treats Build/Compile/Default as a macro, and substitutes its contents into the current location; $(call Build/Compile/Default,) treats it as a function, and gives it no parameters

21:13 <dwfreed> or an empty first parameter, which gets removed by the shell during the actual ninja execution