2024Q1 portbuild trouble

PMc

PMc

When building a port, a text dialog interface is invoked to configure the option. This is how it looked in 2023Q4 (and was perfectly usable):
port.old.png


This is how it looks now - and I have no idea in which line I am in (if at all):
port.new.png


It apparently does not know what to scroll.
 
The port option dialog is changed recently (I don't remember when this happened, one day I see the message 'F1' for Ports Collection help I never seen before). The old version (dialog4ports) was replaced by ports-mgmt/portconfig.

To use dialog4ports I guess the two environment variables can be changed in /etc/make.conf:

Code: 
DIALOG4PORTS = ports-mgmt/dialog4ports
DIALOGNAME = dialog4ports

I'm not sure if what I wrote is true, wait for the answer from a more experienced user. I'm trying to make a TUI port browse/maintainer program and looked at files /usr/ports/Mk/bsd.port.mk and /usr/ports/Mk/Scripts/dialog4ports.sh.
 
  • Thanks
Reactions: PMc
You're fully right. I've seen the message that dialog4ports is deprecated, and installed the "drop-in replacement" portconfig and bsddialog.

It is not only that the screen gets garbled. That is a problem somewhere with curses. and that can happen. In such case you press Ctrl-L and it should redraw the screen. But Ctrl-L does not work in this place.
Also, I seem to remember that dialog4ports would work with mouse - at least my fingers seem to remember that. But not any more.

What I'm now wondering is the rationale in this change and the quality of the work. What is going on? This is unsatisfying. Even if this is consindered as a learning experience for somebody, then someone should supervise it.
 
Thank you all for the reports and comments.


Some clarification is necessary before proceeding with the investigation and the effort to improve portconfig.

Please next time open a new issue to gitlab.com/alfix/portconfig to report a problem about portconfig. As it is a personal project hosted in a personal repository, please avoid to send messages to unrelated mailing list and PR. As is easy sharing screenshot on this forum we can continue the investigation and discussion here.

ports-mgmt/dialog4ports can be used ("restored") in several ways, an example is
# pkg install dialog4ports
after installation adding to /etc/make.conf
DIALOG4PORTS=${LOCALBASE}/bin/dialog4ports

Another option is to use ports-mgmt/portoptscli, a CLI utility instead of a TUI. PortOptsCLI is designed for blind users, however anyone who wants to use a CLI can use it.
# pkg install portoptscli
After installation adding to /etc/make.conf
DIALOG4PORTS=${LOCALBASE}/bin/portoptscli

I've seen the message that dialog4ports is deprecated, and installed the "drop-in replacement" portconfig and bsddialog.
Click to expand...
bsddialog is a "drop-in replacement" for dialog in BASE, rationale GPLinBase. However portconfig is just an installable port (ports-mgmt/portconfig). Moreover it does not use private libbsddialog in BASE, it installs the devel/bsddialog port like a dependency.
To note dialog4ports, portconfig and portoptscli are external projects. Theirs purpouse is helping users to set up ports options interactively (other ways exist, to know more ports(7)()). The PORTS framework installs portconfig by default. An user can delete it ( pkg delete portconfig) and can install another utility (if another utility meets his needs); some example above.

It is not only that the screen gets garbled. That is a problem somewhere with curses. and that can happen.
Click to expand...
It is right: "That is a problem somewhere with curses". I need to know how to reproduce the problem to investigate/fix/improve. To describe your environment is a good starting point.

In such case you press Ctrl-L and it should redraw the screen. But Ctrl-L does not work in this place.
Also, I seem to remember that dialog4ports would work with mouse - at least my fingers seem to remember that. But not any more.
Click to expand...
libbsddialog does not handle Ctrl-L and mouse so portconfig cannot provide these features. I added them to the TODO list some day ago (commit), they will be available in the next versions.
Anyway, 1) ncurses is a "render" library, 2) it does not provide widget (buttons, checklist, ...), 3) curs_mouse(3X)() functions give only the screen-position of the click. Then it's quite tedious to implement mouse support (to understand which element was clicked). Fortunately libbsddialog is open source, feel free to implement the mouse support and to open a merge request to improve the library if you need it in short/mid term.

What I'm now wondering is the rationale in this change and the quality of the work. What is going on? This is unsatisfying.
Click to expand...
The rationale is available in commit messages and ports@ mailing list.
I use portconfig since 2 years without problems on my main laptop with FreeBSD CURRENT via vt(4()) and XFCE terminal.
So far the reported problems were about old ncurses version (link), putty on Windows (link), MacOS terminals. Usually I fixed them after some message with screenshots/feedback/testing. So far the cause "is a problem somewhere with curses. and that can happen", that is an unexpected and strange ncurses rendering on some terminal/environment unrelated to the logic of portconfig. So I fixed this problem using tricks for ncurses in libbsddialog without changing the logic of portconfig or bsddialog (example).

Even if this is consindered as a learning experience for somebody, then someone should supervise it.
Click to expand...
This software is a personal project, designed and implemented during my spare time.
It is not a project developed during a paid day job with a manager and a employee in a company. It is not developed during a sponsored learning experience with an instructor and a trainee.
As portconfig is released for free (like free beer) under a permissive open source license, others helped me with tips, feedback and testing for free during their spare time.

"quality of the work", "This is unsatisfying." "you press Ctrl-L and it should redraw the screen". "someone should supervise it".
Click to expand...
Please read the LICENSE of portconfig, to note:

... THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. ...

please do not use portconfig if: you disagree with its LICENSE and/or it does not meet your needs.
 
What are the exact steps to reproduce the problem?
Can you post the output of:
% portconfig -v
% uname -a
% echo $TERM
% /usr/local/bon/bsddialog --print-version
% /usr/local/bin/bsddialog --print-maxsize
% tput lines
% tput columns
% locale
% % uname -a ; cd /usr/include/ ; rgrep -n NCURSES_VERSION_PATCH
 
Ups, sorrysorrysorry, that one got buried on my stack.

Explanation: I looked into the matter more closely, and figured that I might replace the entire dialog program with the true command, then grab the resulting options-file and stuff it into a database, then manage the options from there - and that way possibly achieve the desires that I really have (e.g. comparison with default settings, or bringing multiple ports onto a single page where one can comprehend the set of changes more easily).
That is obviousely not done in one day (if manageable at all), so it went on my project stack - and so the issue got buried for the time being. Sorrysorry.

(My actual mistake was that I started the quarterly upgrade in order to evade a more imminent -unrelated- task that I really should try to solve, and expected a smooth operation at least with that - which it wasn't, in many a regard).

alfonsosiciliano said:
It is right: "That is a problem somewhere with curses". I need to know how to reproduce the problem to investigate/fix/improve. To describe your environment is a good starting point.
Click to expand...
Okay, investigating now. Usecase:
  1. in an xterm a remote host is connected and there tmux is started - this steals the bottom line and changes stty from 80x24 to 80x23.
  2. Then, inside tmux, cu is used to connect a guest bhyve.
  3. The connection goes to COM2, there is no login happening.
  4. make config is run in the guest (automated, per script) with STDIO redirected to that COM2.
Let's see:
Code: 
# echo $TERM
xterm-256color
# stty -a
speed 38400 baud; 24 rows; 80 columns;
...
# tmux
# echo $TERM
tmux-256color
# stty -a
speed 9600 baud; 23 rows; 80 columns;
...
# cu -l /dev/nmdm4B
[login happening on cuau0]
# echo $TERM
xterm-mono
# stty -a
speed 115200 baud; 23 rows; 80 columns;  [but this happens only the first time!]
...
# stty -a < /dev/cuau1
speed 9600 baud; 0 rows; 0 columns;
...

tmux changes the terminal size and configures it accordingly.
Then cu does indeed get that terminal size over to the guest console (I have no idea how, apparently during the login - but this works only for the first login after the bhyve is started!).
No size gets configured on the COM2. There is no getty on COM2, no login happening, no program running; it is only used for data exchange.

Tests:
  • I login to the guest via cu (stty is 24 rows; 80 columns) and run make config: screen is fine.
  • I restart the bhyve. I start tmux, then login to the guest via cu (23 rows; 80 columns) : screen is fine.
  • I logout from the guest, stop cu, stop tmux, start cu and login to the guest again (still 23 rows; 80 columns - which is now wrong): screen uses only 23 lines, but works.
  • I restart the bhyve, start cu and login to the guest, without tmux (24 rows; 80 columns) - screen is obviousely fine.
  • I logout, stop cu, start tmux, start cu and login again (still 24 rows; 80 columns) - screen is garbled.
  • I correct the stty to the proper 23 rows, 80 columns: screen is fine.
  • I run make config with STDIO redirected to cuau1, where a cu is attached (stty 0 rows; 0 columns): screen is garbled except when the usable screen size is 80x24.
  • I stty set the screen size of cuau1 to the correct useable screen size, then run make config output to there: screen is fine.
Conclusion 1: cu can correctly transfer the terminal screen size to a bhyve guest console. But this works only once during the lifetime of the bhyve, it does not get updated later.

Conclusion 2: portconfig seems to depend on the stty screen information, and may produce garble when that is incorrect (except when it is unset and the screen is 80x24),
  • I run make config on the host itself, in the xterm (no cu involved), with stty rows configuration changed to a wrong value: screen does also get garbled.
and finally:
  • comparing with dialog4ports, this does also create garble when the rows information is seriously wrong. But, apparently due to a different design of the scrolling area, this is visibly disturbing only when the misconfiguration is at least 3 lines off.

Conclusion: the problem was there all the time, it was just not perceivable in the given usecase. Design error on my side.
(Next time I wonder why something works without reason, I should look closer.)

alfonsosiciliano said:
libbsddialog does not handle Ctrl-L and mouse so portconfig cannot provide these features. I added them to the TODO list some day ago (commit), they will be available in the next versions.
Click to expand...
Great!

alfonsosiciliano said:
Anyway, 1) ncurses is a "render" library, 2) it does not provide widget (buttons, checklist, ...), 3) curs_mouse(3X)() functions give only the screen-position of the click. Then it's quite tedious to implement mouse support (to understand which element was clicked). Fortunately libbsddialog is open source, feel free to implement the mouse support and to open a merge request to improve the library if you need it in short/mid term.
Click to expand...
Mouse support is not so imminent an issue. Ctrl-L is a traditional life-saver when you're on a remote machine and things go wrong and you can't afford to make a mistake.
 
You must log in or register to reply here.
Back
Top