07:05 <dwfreed> Habbie: your package is missing PKG_BUILD_DEPENDS

07:41 <Habbie> dwfreed, oh crap :)

07:41 <dwfreed> that would probably solve your problem :)

07:42 <Habbie> yes, and i don't even want them at runtime

07:42 <Habbie> so they really are in the wrong place now

07:42 <dwfreed> nlohmann's header only, right?

07:43 <Habbie> i think so, but more importantly, my end product is a static binary

07:43 <dwfreed> ah, right

07:45 <Habbie> if this was for upstreaming to openwrt/packages it would be different

07:49 <Mangix> Habbie: yes static dependencies should be BUILD_DEPENDS

07:49 <Habbie> ack

07:50 <Mangix> i would guess a lot of packages would benefit from static linking honestly

07:51 <Habbie> yes

07:51 <Habbie> if you have only one or two, say, openssl consumers, you don't need the whole two .so's

07:51 <Habbie> but shipping half .so's is hard too

08:00 <Habbie> ok, and PKG_BUILD_DEPENDS wants dirnames, and no +

08:08 <Habbie> actually that might be a fun experiment - whatever the linker does to only take part of a .a, apply that logic to an entire image, and strip unused bits out of .so files

09:11 <guidosarducci> nbd: I fixed a mac80211 backports bug while working on malta/6.12. Could you look at https://github.com/nbd168/backports/pull/1 when you get a chance? Thanks, and all the best in the New Year!

10:38 <Habbie> oh right

10:38 <Habbie> | WARNING: Makefile 'package/voorkant/Makefile' has a build dependency on 'curl', which does not exist

10:39 <Habbie> 'this again'

13:36 <notu1> I have a TD-W9980 device, I am trying to change the 8mb flash to 16mb, I am running on this kernel panic https://pastebin.com/NBSECJ7x and this is my diff file https://owo.whats-th.is/8AhWELi.diff , my goal is to boot this and have about 8mb free storage. I am taking notes from this guide https://janfla.slask.pl/2021/01/tp-link-td-w8970v1-16m-mod/ . I have also posted on the forum about this under https://forum.openwrt.org/t/tdw99

13:36 <notu1> 80-16mb-flash/220369.

13:42 <russell--> notu1: you need to partition layout from the original flash

13:49 <russell--> wait, what was the dts file for the unmodified device?

13:52 <notu1> russell--: /target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_tplink_tdw8980.dts with the partition table from vr9_tplink_tdw89x0.dtsi

13:53 <notu1> I have copied over with uboot the boardconfig and it is in the 0xfd0000 region

13:58 <russell--> for simplicity (and because i don't quite understand how device tree overriding works) i'd copy both those into -16m versions and adjust the flash partitioning in the new dtsi, and obviously change the include in the new dts file to point at at the new dtsi file and whatever else seems obvious.

13:58 <russell--> i did something similar with the wdr3600

14:04 <russell--> notu1: this was my change from original to modded dts: https://pastebin.com/9LwJA6za

14:04 <russell--> so, i guess i do know how overriding works or something

14:08 <russell--> notu1: this was my whole commit to add support for my mod'd version: https://pastebin.com/QkAm07jA

14:20 <russell--> so, mostly i think you need to redeclare thing parts that change, and tweak the reg = < > parts. firmware will get a modified size and the config and boardconfig will get new starting addresses.

14:39 <notu1> okay I tried your method and ended up with this diff https://pastebin.com/9R9ZyJcv , I feel like nvmem is the issue and I dont know why this does not work at all

14:39 <notu1> same kernel panic

14:49 <russell--> notu1: this is my guess at a patch: https://pastebin.com/5ZP17sts

14:50 <russell--> nvmem ought to be relative to the partition, and that shouldn't change from just moving partitions around, obviously you have to copy the bits from the original to the right part of the new flash image

14:50 <robimarko> svanheule: I guess this branch was accidental?

14:50 <robimarko> https://github.com/openwrt/openwrt/tree/realtek-fix_mac_address_for_hpe1920-24g-180w-jmspswny

14:57 <russell--> notu1: i don't understand the purpose of the firmware-utils in your patch or the hotplug change, tdw8980 wasn't in there before, why add it now if you are just changing the flash part?

15:04 <Habbie> dwfreed, i have learned that doing src-link (like PowerDNS/openwrt-feeds) makes build dep works

15:04 <Habbie> dwfreed, the way openwrt-vlmcsd sets up the package makes them fail

15:04 <Habbie> likely a bug somewhere in scripts/

15:18 <notu1> russell--: Changes to the firmware-utils are basically 3 lines, to add the correct flash layout from the janfla patches since we define a new flash layout 16Mltq-8Mflsh . As for the hotplug tdw8980 it was in there before but got moved to xrx200_legacy since it failed to build due to images failing to build for release 24, so it is adapted from there.

15:21 <notu1> You instead of moving it back to the xrx200 you did it in the xrx200_legacy which I avoided to be closer to the guide, Ill try and see what your attempt gives us

15:29 <notu1> And you used the 16Mltq flash layout which apparently has different kernel offsets, might be an issue for uboot since I think uboot needs to be adapted for that, see how the patch was at https://github.com/Notupus/firmware-utils/blob/5835a3f7abe55fe0fedf37f030a973eb4a186fd2/src/mktplinkfw2.c#L121

15:30 <russell--> notu1: if the only thing you are changing is the flash, then everything else is the same, i'd be inclined to validate that part before layering on other chaos

15:31 <russell--> anyway, that counts as my guess. i can't help beyond that

15:35 <notu1> Thanks a lot no matter what, I'll keep looking into it

17:29 <schmars[m]> hauke: interested in picking cudy ap3000 v1 support to 24.10? i have two devices that i can test it with - https://github.com/openwrt/openwrt/commit/6992d6e51af34603de099d7bbe9d7e848f109e22

18:20 <totkeks> robimarko, I saw your comment about the issue bot being a bit stupid. How could that be fixed? Its a workflow in github, right?

18:21 <robimarko> I dont think its fixable

18:21 <robimarko> For the version at least

18:22 <totkeks> how so?

18:23 <robimarko> I mean, if you are interested, look at https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/issue-labeller.yml#L57

18:24 <robimarko> As well as version validation

18:26 <robimarko> It should work as long as you input snapshot and then full version

18:28 <totkeks> ah yes, version and release. confused me as well the first time I created an issue because I, as probably many other, ignored the useful hint below the field

18:29 <robimarko> Yes, that is why most non release versions are tagged as invalid

18:29 <robimarko> As if you dont post what the hint says it will fail checks

18:29 <robimarko> Device names as well are bit of an issue

18:30 <totkeks> but only if people don't use the proper command, right?

18:30 <robimarko> Yes

18:30 <robimarko> And most people dont

18:30 <totkeks> people are lazy. that is to be expected unfortunately

18:30 <robimarko> So we have a lot of issues with device, target or versions marked as invalid

18:31 <robimarko> Effectively making everybody just ignore the bot comments

18:31 <totkeks> that sounds like a waste of them then on both sides.

18:32 <totkeks> what was/is the original intent behind that labelling?

18:33 <robimarko> Basically, to make it clear what is the version that has the bug, device, target and diffconfig

18:33 <robimarko> As otherwise you gotta ask for all of that manually

18:33 <robimarko> Basically, if the validation was run before issue could be created then it would help

18:34 <robimarko> Now it just annoys people

18:41 <robimarko> It really helps when people fill out all of the fields though, so its not bots fault really

18:43 <totkeks> then one option could be to me more drastic and just close/delete the issue, if it is faulty.

18:43 <totkeks> another option could be to rerun the validation when the user edits the issue after the bot tells him he made some mistakes

18:44 <robimarko> I am not sure if GH supports that, but that would be really good

18:44 <robimarko> As currently, you gotta remove the comments manually

18:45 <totkeks> I just conversed with copilot and it said there is a "edited" trigger for workflows.

18:50 <totkeks> https://github.com/orgs/community/discussions/10227 there is also this, but that seems unanswered for 2 years :D

19:14 <totkeks> looking at the issue labeller workflow I have mainly no idea what it does. :D but at least github has copilot integrated to ask for a summary.

19:14 <totkeks> its a pity github actions don't have the same features as azure devops ones. e.g. importing steps

19:33 <totkeks> one Ai was wrong. the other knew it better. it is actually supported. which is good, because it could make that job easier to read and reuse parts.

19:38 <totkeks> is there a description of the process somewhere? new bug report (has labels to-triage, bug and bug-report) comes in. workflow runs and checks if label "bug-report" is present. then parses issue and validates version (revision actually, seems confusing to use two different words), release, target and device and adds the appropriate labels or comments if it fails. And then removes the two labels. While instead it should

19:38 <totkeks> bugger the OP to fix the issue until it is fine, right?

20:19 <notu1> russell--: it booted.. and works, i dont know why luci doesnt but uci works just fine

23:45 <ov2k> I noticed a security concern with ddns-scripts. Who should I talk to about this?