This work also supports the incoming bsdpv(3) library and bsdpv(1) utility -- which is dpv(3)/dpv(1) rebuilt to use bsddialog(1) instead of cdialog(1) that was removed from base

I don't see any of this upstream at https://gitlab.com/alfix/bsddialog, nor even as a merge request there?

Hi, I’m on vacation right now. I’ll have a look next week since reading on my phone is a bit uncomfortable.

In D58118#1333583, @jrtc27 wrote:

I don't see any of this upstream at https://gitlab.com/alfix/bsddialog, nor even as a merge request there?

Hi Jessica, to clarify: this review is intentionally a DNM (Do Not Merge) patch for local staging and refinement.

Because bsddialog is critical to base system tools like dpv/bsdpv, bsdinstall, bsdconfig, sade, etc, the goal here is to use our native infrastructure to vet the API fixes with Alfonso first. Once the technical implementation is finalized here, the clean patch will be exported and submitted to the upstream GitLab repository.

When Alfonso imports the vendor update back into FreeBSD, the final commit will cross-reference this Phabricator review. This hybrid approach allows us to:

1. Refine base-system impacts using our standard project tools without forcing committers into external 'dual-citizenship' workflows.
2. Establish a permanent, two-way historical provenance in our own tree that remains intact even if external git hosting platforms change or go down.

I am leaving this open for discussion here until Alfonso gets back from vacation next week to review the logic.

Ok, so long as everyone's in agreement that this ultimately needs to land in FreeBSD as a vendor import of a new upstream release, I'm happy

Does this diff target src/contrib/ or the upstream GitLab project repository?

Here is the current roadmap for bsddialog: https://lists.freebsd.org/archives/dev-commits-src-main/2025-October/036498.html. Things are running a bit behind schedule, and item #2 is currently in progress.

Which specific function or feature does dpv need? I can try to squeeze it in between items #2 and #3.

After that, as mentioned in item #3, bsddialog will be rewritten, I gave a quick heads-up about this in the previous review (https://reviews.freebsd.org/D55424#1328149). The goal is to make bsddialog easier to maintain and simpler for adding new features. Among other things, this includes:

• Implementing the items in "TODO and Ideas" (https://gitlab.com/alfix/bsddialog/#todo-and-ideas)
• Eliminating unnecessary screen refreshes (it's not just the calendar dialog, similar dialogs suffer from this too; we noticed it during the last Google Summer of Code while improving the partitioner, and Adrian Chadd reported similar issues during a serial console installation, which are already fixed)
• ...and plenty more!

@dteske I suggest you submit your changes as Gitlab PRs (preferably piecemeal) and work with @asiciliano to get them integrated upstream.

@asiciliano I sympathize with the urge to rewrite but trust me, it is never a good idea. You always underestimate the amount of arcane knowledge and experience embedded in working code, and the amount of work (which you already put into the original!) required to get all the kinks ironed out of a rewrite. Gradual refactoring supported by automated tests is a better path forward.

In D58118#1338921, @des wrote:

@dteske I suggest you submit your changes as Gitlab PRs (preferably piecemeal) and work with @asiciliano to get them integrated upstream.

I'll make the effort to sign-up for GitLab today and get to know its workflow. I was a little intimidated in having to learn a new workflow with new terminology that I had never heard before (e.g., "forge"). I do know GitHub but it uses Pull Requests, and I admit that GitLab (which I had never heard of before) is a completely unknown surface for me. I didn't even know that bsddialog was considered 3rd party, and thought we could (as was explained above) have Alfonso handle the slurping-in of changes and reference the review here. After since learning that there are outstanding changes upstream that would complicate that process, I fully and readily admit that it would be easier (and faster) to address the changes upstream; and in a piece-meal manner (everyone loves a minimal diff, after all, myself included).

I originally used Gitorious. When I created my Gitorious account, GitHub didn't exist yet, or at least I wasn't aware of it. Both companies were founded in 2008. In 2015, GitLab acquired Gitorious, and since then most of my open source projects have been hosted under the same GitLab account, except for my blog.

Until now, I had never heard the term "forge" either. GitHub's "Pull Request" is GitLab's "Merge Request", so I think the rest of the workflow should be pretty much the same.

There are outstanding changes upstream that would complicate that process.

More than the differences between the upstream GitLab version and contrib/, what concerns me are the changes that will happen upstream in the future. I need to rewrite or heavily refactor bsddialog to add mouse support, rewrite the gauge, and implement some of the other features already described in the TODO and ideas.

What does dpv actually need? bsddialog_gauge_open(), bsddialog_gauge_update(), bsddialog_gauge_close(), bsddialog_gauge_flush(), and anything else?

Since this API is quite different from the other dialogs, we could isolate it in dedicated files in the library, such as lib/bsddialog_dpv.h and lib/bsddialog_dpv.c, somewhat similar to how progressview() is currently implemented, since it is completely different from the other dialogs.

I can add all the other features to the TODO list for the refactoring I'll do in a few months. For example, "buttons backward": the TODO already mentions that button handling should be managed globally. Adding macros and functions now would make the future refactoring more complicated, especially since I'm still not sure whether I want to keep everything in C or rewrite it in an object-oriented way in Lua.