Is anyone maintaining libubox?
Philip Prindeville
philipp_subx at redfish-solutions.com
Sun Nov 2 16:46:37 PST 2025
> On Nov 2, 2025, at 6:44 AM, Jonas Lochmann <openwrt at jonaslochmann.de> wrote:
>
> Am Sat, Nov 01, 2025 at 10:49:31AM -0600, schrieb Philip Prindeville via openwrt-devel:
>> There are issues and PR’s that are more than a year old.
>
> I know the problem and very likely there are others that know it too.
> I am already considering forking OpenWrt just because changes are not
> rejected and instead ignored. I know that the time of maintainers is
> limited. Maybe forks could be good for the project long term - as long
> as those are willing to upstream stuff and react to feedback during
> this process.
>
>> I’ve put the same set of PR’s out 3 times and not received so much as a single review comment.
>>
>> Some of the PR’s are pretty trivial and low-risk.
>
> I took a look at your PRs. I am not part of the OpenWrt project and
> thus cannot do anything related to them. They solve something without
> showing that there is actually a problem. It's a bit like the PR
> "ipv6 iol intact certification" at odhcp6c that itself has a good
> motivation (with a solution that I don't like) where the original
> author failed to explain what is solves. I could be rude and say
> it did not solve anything because he did not say what problems
> resulted from the previous state and maybe he did not know himself.
No, I've called this out before. But here it is again since it's been a while. ISC-DHCP (which I own) is EOL, and I've rewritten the backend to take the existing UCI and convert it into JSON for Kea instead (which replaces it). Generating JSON requires two passes over the UCI and random access into the JSON objects, which libubox doesn't handle easily. The current API is meant to generate JSON linearly, not in a tree-like fashion.
The commit:
> From: "Philip Prindeville" <philipp at redfish-solutions.com>
> To: openwrt-devel at lists.openwrt.org
> Cc: Philip Prindeville <philipp at redfish-solutions.com>
> Subject: [PATCH 1/1] jshn.sh: Add getters for the cursor and its parent
>
> When building JSON, the order in which it is synthesized might not
> match the order in which the source information is parsed. In those
> cases, it is useful to be able to save your place in an object or
> an array and come back to it later and fill it out.
>
> Signed-off-by: Philip Prindeville <philipp at redfish-solutions.com>
Handles this specifically.
And is needed to complete this migration. I've had it ready to go for about a year and a half now.
See also:
https://github.com/openwrt/libubox/pull/6#issue-1899109668
Which states:
> You might not always want to populate JSON serially, so a way to save/restore the cursor through a convenience function is handy.
> Also, adding anonymous (unnamed) strings to an array isn't obvious, so added a convenience function for that.
> Lastly, some minor cleanup to show what the parameters are to functions, etc.
Lastly, see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-December/041920.html
Where all of this was introduced and I state:
> The 2nd PR includes improvements to libubox's jshn.sh, in particular the ability to save the "cursor" as one builds multiple empty tables, and then come back to them (by repositioning the cursor) on a subsequent pass to populate them. As you probably guessed, interface tables as created in one pass in the Kea init.d script, and then the host reservations are plugged into them after the reserved address is mapped back to the corresponding subnet/interface pair on the 2nd pass.
>
> This requires "warping" the cursor to the appropriate table, as there is no requirement for ordering of DHCP host reservations vis-a-vis DHCP subnet definitions, etc.
More information about the openwrt-devel
mailing list