From nobody Mon May 30 20:02:31 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 128591B5DEE4 for ; Mon, 30 May 2022 20:02:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBmY42LW6z3l2w for ; Mon, 30 May 2022 20:02:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id x11so5331844vkn.11 for ; Mon, 30 May 2022 13:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7XHnH6DOlgp6UEft+Wn6zTJgBeMpVYONiaX5m93dHyk=; b=SDObub1jxkdGkCQsQHxUAEwxbSGhrl0aX29cLr4WGGTMemtLNtdXt+S1Q5UuHTJMKR Kdt7kfJLgmmPWdNnqMdgY+fAqO81ujU07C7ek8NRk6RG4PKTqvRjJovWl7jaRsAhIJDu nU31jwv+V0qYSDvjHJIy3jRDF44XgZJbpN0IKDCE6M4uhUdr5y/aFYLm1WFAQ1VoTuzz n9NVFC/GSL0+fWUt8R8J8utdkpK6emmX2KQGW6kqG8fhQ06oP/W9+ZcbYtON26vPQ85u Un4o9tmECNbcXCqAy9LZSNPMmQvLwyHd6LGVeM3F/IbxvGJSjK7JO8VASvNcGu4ZJ6TM RxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7XHnH6DOlgp6UEft+Wn6zTJgBeMpVYONiaX5m93dHyk=; b=pnAgaxS6O9xMkXcAgT0zUMp4oC5HFVndk5YGRmN5ryll2iAMJZswG81EcvQ3QOA1xR k984E32h0aalwjPq96LYMgMOQEdmPu0z7vqaz2MxkqGDDcFz+Iqv1c4AL46YFdUaQVrB VUtA6HWcLohvu6CBS8st1494AozWTZ7vZg58MXHmYnjbYkv63VrQVLhz1wrhNTsOXdPU VB8dWMTgu1VX9Ix5zc4dNc8+SxSc1LOJzKIKKY3MSp8V1WzpA4YVmxUSzpuxcABZrxNU klElHwWyOziYuvYXBA3Cqe/vtc7ajqzjSI+y1z1IwD7rrhH9h3XPD4YXywgHmiBdREur pYRw== X-Gm-Message-State: AOAM533z1nx04nOqx2pliuXp4nSvundVvAY9MloWRXp/QaOZXHBDDIXu iS2ZqtKjfJAw6ugaEIGqcHXosU0HXsEri8ttCgRXuJLfa2Q= X-Google-Smtp-Source: ABdhPJwHcafRw99v0Tx7vz/2AkLTMNQ75OQC6EFzVf+AkbYaoFfGcks6qvud/Pyv5i1id2tXxmzgWUDhVJ45hdntNp0= X-Received: by 2002:ac5:c34d:0:b0:358:2693:dcae with SMTP id l13-20020ac5c34d000000b003582693dcaemr11586097vkk.16.1653940962486; Mon, 30 May 2022 13:02:42 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> In-Reply-To: From: Warner Losh Date: Mon, 30 May 2022 14:02:31 -0600 Message-ID: Subject: Re: bsdinstall TUI utility To: Devin Teske Cc: "Alfonso S. Siciliano" , "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000008c82a105e040231d" X-Rspamd-Queue-Id: 4LBmY42LW6z3l2w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=SDObub1j; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --0000000000008c82a105e040231d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2022 at 11:40 AM Devin Teske wrote: > > > On May 30, 2022, at 9:18 AM, Warner Losh wrote: > > > > On Mon, May 30, 2022, 9:59 AM Devin Teske wrote: > >> >> >> > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano >> wrote: >> > >> > Obviously, I made some mistake writing in English. >> > >> >> No, your English is fine. Perhaps I did not explain myself well. >> >> >> >> > >> > Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h >> > a BSD licensed alternative . >> > I have almost completed the task >> > . >> >> Well understood. >> >> I have been observing the work. >> >> >> > luckily somebody helped me, I will thank at the end. >> > >> > >> > The topic of the email is not bsdconfig. >> >> Also understood. >> >> >> >> >> > It has already a review, >> >> Link? >> >> >> >> > it preserves the $DIALOG variable to handle a multitude of front-end: >> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. >> >> Good. >> >> >> >> > I would continue the discussion for bsdconfig in phabricator; >> > although I should update it after some recent commit. >> > . >> > >> >> I have commented that I request time to review. >> >> >> >> > >> > The topic of this email is bsdinstall. >> >> Correct. >> >> >> >> > I have to update the last few >> > scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y >> > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e >> > the others used only and called directly `dialog` without any >> > bsdconfig's help. >> > >> >> When you look at the bsdinstall code and you see that it calls dialog >> without bsdconfig=E2=80=99s help, that is because I have not written the= code yet. >> When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig >> api=E2=80=9D) >> >> So removing it will only see it added again later. >> >> >> >> > >> > On 5/29/22 01:02, Devin Teske wrote: >> > > >> > > >> > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano >> wrote: >> > >> >> > >> Hello, >> > >> >> > >> >> > >> So far I replaced and adapted `dialog` with `bsddialog` in >> > >> bsdinstall/scripts. >> > >> >> > >> >> > >> >> > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, >> keymap, >> > >> and wlanconfig. These scripts use also the $DIALOG variable and som= e >> > >> "if" to handle Xdialog(1). >> > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. >> > >> >> > > >> > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean >> bsddialog? >> > > >> > >> > OK. >> > >> > > >> > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. >> > > >> > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG >> > >> > >> > Exactly 1. >> > >> > >> > > >> > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) >> > > >> > > >> > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, probably= , >> > >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). >> > >> >> > > >> > > Correct, bsdconfig does use bsdinstall >> > > >> > >> > >> > Exactly 2. >> > >> > >> > > >> > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to >> > >> provide only the support for bsddialog(1) in bsdinstall(8)? >> > >> >> > > >> > > I object. >> > > >> > > I and another developer are adding support for zenity >> > > >> > > >> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdcon= fig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdcon= fig >> > >> > > >> > > There is also work to resolve the namespace issues in bsdinstall >> > > >> > > >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> > >> > > >> > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where i= t >> exists until those efforts can be completed. >> > > >> > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >> > >> > >> > Exactly 3. >> > >> > >> > Anyway, probably the misunderstanding is at this point. My question is >> > not for bsdconfig but for 4 scripts in bsdinstall. >> >> No, the confusion is that I have my own roadmap that includes fixing >> namespace issues in bsdinstall before then merging bsdinstall with >> bsdconfig so that they use a single API. >> > > Any chance we could unify the efforts? > > As the code I previously linked to in GitHub demonstrates, I was working >> on it in 2020 last, and then the pandemic hit and then I had a child, an= d >> then two root canals, and then some issues due to a data breech, so it= =E2=80=99s >> been a very busy couple of years, pandemic aside =E2=80=94 at work we on= ly just >> returned to the office last week and had been entirely remote for over 2= 4 >> months (and to be honest, it is a little strange to come back into the >> office and find *everything* exactly as it was, even to the point that t= he >> fridge is freshly stocked with the same exact foods that were in the fri= dge >> the day we closed the office; it=E2=80=99s Twilight Zone levels of freak= y). >> >> >> > Let' s say: "should bsdinstall/scripts/auto have the code to handle >> > $DIALOG/LGPL-dialog/Xdialog" >> > ``` >> > if [ "$USE_XDIALOG" ]; then >> > yes=3Dok no=3Dcancel defaultno=3Ddefault-no >> > extra_args=3D"--wrap --left" >> > format=3D"$passed_msg" >> > else >> > yes=3Dyes no=3Dno defaultno=3Ddefaultno >> > extra_args=3D"--cr-wrap" >> > format=3D"$passed_msg" >> > fi >> > >> > ... >> > >> > EXTRA_DISTS=3D$( eval dialog \ >> > --backtitle \"$OSNAME Installer\" \ >> > >> > ``` >> > >> > Please note, I have not a strong opinion, if you confirm your needs fo= r >> > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l >> > I'll add and preserve these features in the 4 scripts. >> > Please let me know, so I can complete the dialog/bsddialog replacement >> > soon. >> > >> >> My answer is YES, the code could continue to handle that for three very >> simple reasons: >> >> 1. The effort of your roadmap is to *introduce* bsdinstall and >> introduction of something new is easier when remnants of the past can be >> referenced as we work toward the goal of: >> >> 1.a. Reaching parity >> >> 1.b. Removing deprecated code >> >> 2. Removing old while adding new means if there is ever a discrepancy: >> >> 2.a. I have to go to git to see how old code worked >> >> 2.b. I have to install old code to run it (opposed to installing old >> dialog and setting some environment variables) >> >> 3. Making fixes to correct an unintended consequence may introduce issue= s: >> >> 3.a. When I cannot run the head (as described in 2 above) code with old >> dialog >> >> 3.b. =E2=80=A6 as I have to run two codeines and merge between the two >> >> 3.c. =E2=80=A6 and there will be a time in the future when this should b= e >> expected to break and that should trigger removal, but not before >> completing the transitional period on a roadmap to reach parity >> >> >> >> > >> > > >> > > >> > >> I would prefer this solution because I can avoid: to handle some >> > >> dialog/Xdialog/bsddialog command line difference and to hook some >> > >> bsdconfig function built on dialog(1) incompatible with bsddialog(1= ) >> > >> (for example autosizing, implemented in bsddialog(3) already). >> > >> >> > > >> > > The differences in command line should be handled through >> conditionals, but can be the default and opt to handle LGPL-dialog throu= gh >> a USE_GNU_DIALOG flag >> > > >> > > bsddialog may support auto-sizing, but so does dialog and Xdialog. >> > > >> > > However, ... >> > > >> > > The sizing code in bsdconfig (used indirectly by bsdinstall) was >> written because the auto-sizing that does exist and is available in both >> dialog and Xdialog (as well as Zenity) does not provide a cohesive >> experience when trying to write a program that is in-reality a series of >> bespoke dialogs. >> > > >> > > The sizing code makes sure that regardless of which utility you are >> using that the experience is uniform in what is presented to the user. >> > > >> > > Attempting to rely solely on the auto-sizing available from these >> separate utilities (including bsddialog) would change the UI/UX. >> > > >> > > The problem was solved by: >> > > >> > > 1. Making the stored text used for dialogs dictate how it will look >> > > 2. Painstakingly determining where each utility failed given the tex= t >> > > 3. Determining how to make the utility display the text properly >> > > >> > > For example, stored text will contain newlines instead of attempting >> to rely on line wrapping on a box of given size. >> > > >> > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to determin= e if it >> is trust-worthy given not only all the stored texts, but all the >> translations as well (as bsdconfig is i18n compatible). It is actually l= ess >> work to just allow bsdconfig to likely treat bsddialog as it is dialog a= nd >> let it perform the size calculations for you. >> > > >> > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than = a little >> surprised that it cannot accept the sizes calculated for dialog being >> passed to it. >> > > >> > > >> > >> >> > >> Please note these considerations are only for bsdinstall, bsdconfig >> is >> > >> unchanged. >> > >> >> > > >> > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-tur= n >> relies on dlg_gauge_reallocate(3) from LGPL-dialog? >> > >> > >> > >> > I seem these considerations are for bsdconfig so the discussion can >> > continue in phabricator. Of course I made some error in English in the >> > first email. >> >> No, your English was fine. I perhaps did not explain the we are at >> perhaps cross efforts with our distinctly separate roadmaps with their o= wn >> goals and timelines. >> >> >> >> > >> > Here the topic is bsdinstall. >> > >> > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, >> > all the components (written in C) were adapted or rewritten to >> > use bsddialog(3). Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7b= df8cec6d32 >> > >> >> I will review and get back with comment. >> >> >> > Most bsdinstall scripts "call" just `dialog` using its autosizing >> > (without any bsdconfig's help). >> > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3b= ffadd17853 >> > The important question was asked above. I would want to understand the >> > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall >> > scripts. >> > >> >> Correct. It is part of my roadmap to remove said auto-sizing in >> bsdinstall. >> >> >> >> > I had some problem using the autosizing functions of bsdconfig for >> > bsddialog, >> >> I do not fully understand this. The API examines the text and determines >> the proper size to pass. Can bsddialog not accept a size? >> >> >> >> >> > probably bacause dialog(3) and bsddialog(3) implement >> > different auto text wrapping algorithms, or the utilities have differe= nt >> > command lines. >> >> Does bsddialog have support for specifying the size of a widget? >> >> >> >> >> > Honestly I am not interested in investigating, >> >> That is an unfortunate statement. I am interested in the work being done= , >> perhaps you could be interested in the work I am doing that I have been >> working on for longer than you have been working on bsddialog. >> >> >> >> > I would >> > like to improve bsddialog instead of wasting time on a LGPL software >> > almost ready to leave the BASE. >> >> Leaving existing code in place does not waste time on LGPL software >> because: >> >> 1. Someone like myself will be installing LGPL dialog from ports and >> relying on the old code to utilize it: >> >> 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using >> environment variables) between LGPL dialog and bsdialog >> >> 1.b. so that I can compare the two against each other and fix any >> regressions >> >> Removing the code to handle LGPL dialog at the same time as removing LGP= L >> dialog from base kind of makes that hard. As previously explained, that >> will force me to perform a series of hacks where I pull down the old tre= e >> with the LGPL handling code and make changes blindly which will only bec= ome >> more and more difficult as the old code without bsddialog support and ne= w >> code (as you propose) without LGPL handling code drift further and furth= er >> apart. >> >> I don=E2=80=99t understand what is so difficult about separating the tas= k of >> =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated featur= es=E2=80=9D to accommodate a >> transitional period is so difficult =E2=80=94 it makes reaching feature = parity >> (which is in bsddialog=E2=80=99s interest) very difficult if you try and= do both of >> those things at the same time. >> >> >> >> > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in >> > bsddialog(3) with colors, a callback and bottom info" depending only o= n >> > BSD licensed code. >> >> Cool! >> >> >> >> > The complete unicode support is a TODO, although bsddialog provides so= me >> > feature already https://bugs.freebsd.org/248968 >> > >> >> Interesting. Will have a look. >> >> >> > This is probably another misunderstanding. My goal, after some email a= nd >> > chat with others, is to provide a BSD licensed alternative to dialog >> > for the "BASE needs"; similar not equal, otherwise the effort would no= t >> > be feasible for a single. >> > Indeed, also the command lines are quite different. Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714= 011c73eb15 >> > >> >> Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for >> transitional period, to come back later and remove old, obsolete/depreca= ted >> code referring to LGPL dialog). >> >> >> >> > So far the replacement process was in phabricator with author(s), >> > maintainer(s) and 2/3 members of the core team. Anyone interested can >> > notify me to be added in future reviews. >> > >> >> I shouldn=E2=80=99t need notification as a principled author/maintainer. >> > > I've found that having a herald rule in phabricator facilitates this. Whi= le > you are listed in the MAINTAINERs file, it's use has been falling out > of fashion in the years since we've adopted phabricator. Also, you've > been kinda AWOL for the last couple of years with activity trailing off > in the 2018 or 2019 time frame, so it's an understandable, though now > corrected, oversight. 3 or 4 years is a long time in 'project time' to be > away > from the caretaking of things. > > > I was not AWOL. I was (and am) working on my roadmaps. > I meant was that there aren't many commits in the last 3-4 years for bsdinstall that were authored by you, but there were a large number authored by others. It was a way of explaining why people might have thought the entry in MAINTAINERS was stale. It was a poor choice of words, and implied much more than I'd intended. It was a sloppy shortcut in expressing this. I'm sorry. Bsdconfig is over 30,000 lines of code. It wasn=E2=80=99t written in a day. > > I have 5 large projects I am working on: > > 1. Bsdinstall namespace > 2. Bsdconfig zenity > 3. libfigput > 4. Sysconf > 5. cmb > > I am working on them in GitHub instead of an f.o branch because I have > never been shown how. > Great! That's the new model. It's easier for the project to setup, but it makes it harder for people to see progress on. there's not been a lot about these things on the mailing lists, but they all sound interesting. Regardless, consider this my notification to be added to add future reviews= . >> > > You'll find you are happier if you add the herald rule yourself. It's a > bit hidden, > but if you go to reviews.freebsd.org and click on the "More Applications" > button > on the left you'll be able to scroll down to find Herald. It makes it so > people > don't have to remember, and you'll see everything relevant to the path of > the > tree that you register. Obviously people should remember, but this will > also > catch new people that are interested in contributing that haven't seen > this thread. > > > Thanks. Didn=E2=80=99t know MAINTAINERS was on the way out. Will look int= o Herald > Sure thing. It's quite helpful. Warner > > > I am available again for review =E2=80=94 though with a child, it may tak= e some >> days before I can respond, since I am new to being a parent. >> > > Good luck with your child. They are a joy, but can also take up a lot of > time. > One of the hardest lessons I learned when I had my child was that sometim= es > you don't have enough time to influence things as much as you'd have done > before the child and that things in the project will continue to happen > nonetheless. > The shared nature of FreeBSD allows for these transitions, and the passin= g > of > code from hand to hand sometimes since there are no 'hard locks' anymore. > > > Thanks. > > I have a non-working spouse, so theoretically only part of what you said > applies. > --0000000000008c82a105e040231d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, May 30, 2022 at 11:40 AM Devi= n Teske <dteske@= freebsd.org> wrote:


On May 30, 2022= , at 9:18 AM, Warner Losh <imp@bsdimp.com> wrote:



On Mon, May 30, 2022, 9:59 AM Devin Teske <dteske@freebsd.org> wrote= :


> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com= > wrote:
>
> Obviously, I made some mistake writing in English.
>

No, your English is fine. Perhaps I did not explain myself well.



>
> Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h
> a BSD licensed alternative <https://wiki.freebs= d.org/GPLinBase>.
> I have almost completed the task
> <https://wiki.freebsd.org/Ro= admapFromDialogToBSDDialog>.

Well understood.

I have been observing the work.


> luckily somebody helped me, I will thank at the end.
>
>
> The topic of the email is not bsdconfig.

Also understood.




> It has already a review,

Link?



> it preserves the $DIALOG variable to handle a multitude of front-end:<= br> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on.
Good.



> I would continue the discussion for bsdconfig in phabricator;
> although I should update it after some recent commit.
> <https://reviews.freebsd.org/D34755>. >

I have commented that I request time to review.



>
> The topic of this email is bsdinstall.

Correct.



> I have to update the last few
> scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y
> to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e
> the others used only and called directly `dialog` without any
> bsdconfig's help.
>

When you look at the bsdinstall code and you see that it calls dialog witho= ut bsdconfig=E2=80=99s help, that is because I have not written the code ye= t. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig api=E2=80=9D)

So removing it will only see it added again later.



>
> On 5/29/22 01:02, Devin Teske wrote:
> >
> >
> >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@= gmail.com> wrote:
> >>
> >> Hello,
> >>
> >>
> >> So far I replaced and adapted `dialog` with `bsddialog` in > >> bsdinstall/scripts.
> >> <https://wiki.freeb= sd.org/RoadmapFromDialogToBSDDialog>
> >>
> >>
> >> Currently, I am addressing the last 4 scripts: auto, bootconf= ig, keymap,
> >> and wlanconfig. These scripts use also the $DIALOG variable a= nd some
> >> "if" to handle Xdialog(1).
> >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `d= ialog`.
> >>
> >
> > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bs= ddialog?
> >
>
> OK.
>
> >
> >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI ut= ility.
> >
> > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
>
>
> Exactly 1.
>
>
> >
> > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)
> >
> >
> >> * I seem bsdconfig(8) does not "call" these 4 scrip= ts, so, probably,
> >>=C2=A0 =C2=A0Xdialog(1) is not used in this context (that is `= bsdconfig -X`).
> >>
> >
> > Correct, bsdconfig does use bsdinstall
> >
>
>
> Exactly 2.
>
>
> >
> >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog = to
> >> provide only the support for bsddialog(1) in bsdinstall(8)? > >>
> >
> > I object.
> >
> > I and another developer are adding support for zenity
> >
> > http= s://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig= <https://g= ithub.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig><= br> > >
> > There is also work to resolve the namespace issues in bsdinstall<= br> > >
> > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdco= nfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig>
> >
> > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support wher= e it exists until those efforts can be completed.
> >
> > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog
>
>
> Exactly 3.
>
>
> Anyway, probably the misunderstanding is at this point. My question is=
> not for bsdconfig but for 4 scripts in bsdinstall.

No, the confusion is that I have my own roadmap that includes fixing namesp= ace issues in bsdinstall before then merging bsdinstall with bsdconfig so t= hat they use a single API.
Any chance we could unify the efforts?

As the code I previously linked to in GitHub demonstrates, I was working on= it in 2020 last, and then the pandemic hit and then I had a child, and the= n two root canals, and then some issues due to a data breech, so it=E2=80= =99s been a very busy couple of years, pandemic aside =E2=80=94 at work we = only just returned to the office last week and had been entirely remote for= over 24 months (and to be honest, it is a little strange to come back into= the office and find *everything* exactly as it was, even to the point that= the fridge is freshly stocked with the same exact foods that were in the f= ridge the day we closed the office; it=E2=80=99s Twilight Zone levels of fr= eaky).


> Let' s say: "should bsdinstall/scripts/auto have the code to = handle
> $DIALOG/LGPL-dialog/Xdialog"
> ```
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "$USE_XDIALOG" ]; then
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dok no=3Dca= ncel defaultno=3Ddefault-no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--wrap --left"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0else
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dyes no=3Dn= o defaultno=3Ddefaultno
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--cr-wrap"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0EXTRA_DISTS=3D$( eval dialog \
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= backtitle \"$OSNAME Installer\" \
>
> ```
>
> Please note, I have not a strong opinion, if you confirm your needs fo= r
> $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l
> I'll add and preserve these features in the 4 scripts.
> Please let me know, so I can complete the dialog/bsddialog replacement=
> soon.
>

My answer is YES, the code could continue to handle that for three very sim= ple reasons:

1. The effort of your roadmap is to *introduce* bsdinstall and introduction= of something new is easier when remnants of the past can be referenced as = we work toward the goal of:

1.a. Reaching parity

1.b. Removing deprecated code

2. Removing old while adding new means if there is ever a discrepancy:

2.a. I have to go to git to see how old code worked

2.b. I have to install old code to run it (opposed to installing old dialog= and=C2=A0 setting some environment variables)

3. Making fixes to correct an unintended consequence may introduce issues:<= br>
3.a. When I cannot run the head (as described in 2 above) code with old dia= log

3.b. =E2=80=A6 as I have to run two codeines and merge between the two

3.c. =E2=80=A6 and there will be a time in the future when this should be e= xpected to break and that should trigger removal, but not before completing= the transitional period on a roadmap to reach parity



>
> >
> >
> >> I would prefer this solution because I can avoid: to handle s= ome
> >> dialog/Xdialog/bsddialog command line difference and to hook = some
> >> bsdconfig function built on dialog(1) incompatible with bsddi= alog(1)
> >> (for example autosizing, implemented in bsddialog(3) already)= .
> >>
> >
> > The differences in command line should be handled through conditi= onals, but can be the default and opt to handle LGPL-dialog through a USE_G= NU_DIALOG flag
> >
> > bsddialog may support auto-sizing, but so does dialog and Xdialog= .
> >
> > However, ...
> >
> > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both di= alog and Xdialog (as well as Zenity) does not provide a cohesive experience= when trying to write a program that is in-reality a series of bespoke dial= ogs.
> >
> > The sizing code makes sure that regardless of which utility you a= re using that the experience is uniform in what is presented to the user. > >
> > Attempting to rely solely on the auto-sizing available from these= separate utilities (including bsddialog) would change the UI/UX.
> >
> > The problem was solved by:
> >
> > 1. Making the stored text used for dialogs dictate how it will lo= ok
> > 2. Painstakingly determining where each utility failed given the = text
> > 3. Determining how to make the utility display the text properly<= br> > >
> > For example, stored text will contain newlines instead of attempt= ing to rely on line wrapping on a box of given size.
> >
> > I would have to evaluate bsddialog=E2=80=99s auto-sizing to deter= mine if it is trust-worthy given not only all the stored texts, but all the= translations as well (as bsdconfig is i18n compatible). It is actually les= s work to just allow bsdconfig to likely treat bsddialog as it is dialog an= d let it perform the size calculations for you.
> >
> > If bsddialog is top be a drop-in replacement, I=E2=80=99m more th= an a little surprised that it cannot accept the sizes calculated for dialog= being passed to it.
> >
> >
> >>
> >> Please note these considerations are only for bsdinstall, bsd= config is
> >> unchanged.
> >>
> >
> > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-= turn relies on dlg_gauge_reallocate(3) from LGPL-dialog?
>
>
>
> I seem these considerations are for bsdconfig so the discussion can > continue in phabricator. Of course I made some error in English in the=
> first email.

No, your English was fine. I perhaps did not explain the we are at perhaps = cross efforts with our distinctly separate roadmaps with their own goals an= d timelines.



>
> Here the topic is bsdinstall.
>
> bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months,
> all the components (written in C) were adapted or rewritten to
> use bsddialog(3). Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf8ce= c6d32
>

I will review and get back with comment.


> Most bsdinstall scripts "call" just `dialog` using its autos= izing
> (without any bsdconfig's=C2=A0 help).
> So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bffadd= 17853
> The important question was asked above. I would want to understand the=
> right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall<= br> > scripts.
>

Correct. It is part of my roadmap to remove said auto-sizing in bsdinstall.=



> I had some problem using the autosizing functions of bsdconfig for
> bsddialog,

I do not fully understand this. The API examines the text and determines th= e proper size to pass. Can bsddialog not accept a size?




> probably bacause dialog(3) and bsddialog(3) implement
> different auto text wrapping algorithms, or the utilities have differe= nt
> command lines.

Does bsddialog have support for specifying the size of a widget?




> Honestly I am not interested in investigating,

That is an unfortunate statement. I am interested in the work being done, p= erhaps you could be interested in the work I am doing that I have been work= ing on for longer than you have been working on bsddialog.



> I would
> like to improve bsddialog instead of wasting time on a LGPL software > almost ready to leave the BASE.

Leaving existing code in place does not waste time on LGPL software because= :

1. Someone like myself will be installing LGPL dialog from ports and relyin= g on the old code to utilize it:

1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using env= ironment variables) between LGPL dialog and bsdialog

1.b. so that I can compare the two against each other and fix any regressio= ns

Removing the code to handle LGPL dialog at the same time as removing LGPL d= ialog from base kind of makes that hard. As previously explained, that will= force me to perform a series of hacks where I pull down the old tree with = the LGPL handling code and make changes blindly which will only become more= and more difficult as the old code without bsddialog support and new code = (as you propose) without LGPL handling code drift further and further apart= .

I don=E2=80=99t understand what is so difficult about separating the task o= f =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated feature= s=E2=80=9D to accommodate a transitional period is so difficult =E2=80=94 i= t makes reaching feature parity (which is in bsddialog=E2=80=99s interest) = very difficult if you try and do both of those things at the same time.



> For dpv(3) in distfetch.c, I implemented an "improved mixedgauge&= quot; in
> bsddialog(3) with colors, a callback and bottom info" depending o= nly on
> BSD licensed code.

Cool!



> The complete unicode support is a TODO, although bsddialog provides so= me
> feature already https://bugs.freebsd.org/248968 >

Interesting. Will have a look.


> This is probably another misunderstanding. My goal, after some email a= nd
> chat with others, is to provide a BSD licensed alternative to dialog > for the "BASE needs"; similar not equal, otherwise the effor= t would not
> be feasible for a single.
> Indeed, also the command lines are quite different. Example
> ht= tps://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714011c7= 3eb15
>

Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for tr= ansitional period, to come back later and remove old, obsolete/deprecated c= ode referring to LGPL dialog).



> So far the replacement process was in phabricator with author(s),
> maintainer(s) and 2/3 members of the core team. Anyone interested can<= br> > notify me to be added in future reviews.
>

I shouldn=E2=80=99t need notification as a principled author/maintainer.

I've found t= hat having a herald rule in phabricator facilitates this. While
y= ou are listed in the MAINTAINERs file, it's use has been falling out
of fashion in the years since we've adopted phabricator. Also, = you've
been kinda AWOL for the last couple of years with acti= vity trailing off
in the 2018 or 2019 time frame, so it's an = understandable, though now
corrected, oversight. 3 or 4 years is = a long time in 'project time' to be away
from the caretak= ing of things.

I wa= s not AWOL. I was (and am) working on my roadmaps.

I meant was that there aren't many commits in= the last 3-4 years for bsdinstall
that were authored by you,= =C2=A0but there were a large number authored by others. It
was a = way of explaining why people might have thought the entry in MAINTAINERS
was stale. It was a poor choice of words, and implied much more tha= n I'd intended.
It was=C2=A0a sloppy=C2=A0shortcut in express= ing this. I'm sorry.

Bsdconfig is over 30,000 lines of code. = It wasn=E2=80=99t written in a day.

I have 5 large= projects I am working on:

1. Bsdinstall namespace=
2. Bsdconfig zenity
3. libfigput
4. Sysconf<= /div>
5. cmb

I am working on them in GitHub in= stead of an f.o branch because I have never been shown how.

Great! That's the new model. It'= s easier for the project to setup, but it makes
it harder for peo= ple to see progress on. there's not been a lot about these things
=
on the mailing lists, but they all sound interesting.

Regar= dless, consider this my notification to be added to add future reviews.
=

You'll find you are happier if you add= the herald rule yourself. It's a bit hidden,
but if you go t= o reviews.freebsd= .org and click on the "More Applications" button
on= the left you'll be able to scroll down to find Herald. It makes it so = people
don't have to remember, and you'll see everything = relevant to the path of the
tree that you register. Obviously peo= ple should remember, but this will also
catch new people that are= interested in contributing that haven't seen this thread.
<= /div>

Thanks. Didn=E2=80= =99t know MAINTAINERS was on the way out. Will look into Herald
=

Sure thing. It's quite helpful.
<= div>
Warner
=C2=A0
=C2=A0
I am available again for review =E2=80=94 though with a child, it may take = some days before I can respond, since I am new to being a parent.

Good luck with your child. They are a joy, but c= an also take up a lot of time.
One of the hardest lessons=C2=A0I = learned when I had my child was that sometimes
you don't have= enough time to influence things as much as you'd have done
b= efore the child and that things in the project will continue to happen none= theless.
The shared nature of FreeBSD allows for these transition= s, and the passing of
code from hand to hand sometimes since ther= e are no 'hard locks' anymore.


Thanks.

I= have a non-working spouse, so theoretically only part of what you said app= lies.
--0000000000008c82a105e040231d--