Re: bc and dc -e/-f and Copyright
On Thu, Jul 30, 2020 at 4:25 PM Jessica Clarke wrote:
>
> On 30 Jul 2020, at 23:21, Jessica Clarke wrote:
> > On 30 Jul 2020, at 20:35, Gavin Howard wrote:
> >>
> >> Hello,
> >>
> >> My name is Gavin Howard, and I am the developer and maintainer of the
> >> new bc and dc implementation in -CURRENT. Stefan Eßer brought a
> >> discussion about my bc to my attention, and I would like to solve the
> >> problems.
> >>
> >> First, I will add some way to remove the printing of the copyright
> >> header at compile time, and FreeBSD should be able to take advantage
> >> of it as soon as I put out a new release, which should be within days
> >> after this discussion is settled.
> >>
> >> Second, there seems to be those who are unhappy with my decision to
> >> make bc and dc not exit when using the -e and -f options. While the
> >> behavior of my bc is what I personally need, I have a few options to
> >> change it back to what is expected:
> >>
> >> 1. I could make it a compile-time selection. I don't like this option,
> >> to be honest.
> >>
> >> 2. I could restore the expected behavior of -e and -f and change the
> >> environment variable to BC_EXPR_NO_EXIT (DC_EXPR_NO_EXIT) and reverse
> >> the logic. I could do this one, but Stefan mentioned to me that he
> >> would prefer less environment variables be used. I agree.
> >>
> >> 3. I could restore the expected behavior of -e and -f and add -E and
> >> -F options that do the same thing but do not exit. I think I like this
> >> option the best. I am willing to change -E and -F to something else if
> >> that would be better.
> >
> > Rather than introducing new options like any of these you could instead:
> >
> > 4. Make sure -f - reads from stdin. Then just append -f - to your uses.
> >
> > 5. Overload -i when used with -e/-f to also make it not exit.
> >
> > I personally prefer 4 as it doesn't require any confusing overloading
> > (-f - should read from stdin as a well-behaved Unix tool regardless in
> > my opinion), but does come with the downside that you can't just:
> >
> >alias bc='bc -f -'
> >
> > for your case, you'd have to instead:
> >
> >bc() { command bc "$@" -f - }
> >
> > or equivalent in your shell of choice.
>
> NB: 4 already works with GNU dc. FreeBSD's old dc requires you to do -f
> /dev/stdin instead as it doesn't treat - as special but otherwise also
> works. I haven't looked to see whether your dc regards - as stdin or
> not, but -f /dev/stdin surely already works. So 4 seems the most
> consistent and/or compatible option when considering other
> implementations.
>
> Jess
All,
I have made the following changes:
bc does not print a copyright header unless the version options (-v,
-V, and --version) are given. The -q and --quiet options are no-ops,
but are kept for compatibility with GNU bc.
I have ensured that -f - works; it basically disables exiting after
processing all expressions and files given with -e and -f. I have
found a way to make this work for me personally.
If there are no objections within 24 hours or so, I will release the
changes as 3.1.4.
Gavin Howard
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, Jul 30, 2020 at 07:14:26PM -0500, Kyle Evans wrote:
> ...
> > I finally just re-retried the "make installworld," and it succeeded.
> >
>
> To be clear, this was just a second installworld without rebuilding,
> correct?
Yes. The most recent typescript from the build process on that machine
resides at
http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_build_typescript.txt.
> If so, I'm going to amend the UPDATING to add:
>
> installworld may encounter the following error: Undefined symbol
> "regcomp@FBSD_1.6"
>
> It is imperative that you do not interrupt the installworld, but
> instead let it proceed to
> completion, whether it succeeds or not, and run installworld again.
>
OK.
I note that I did not change any configuration (e.g.,
/etc/{src{,-env},make}.conf) or anything else -- merely invoke a csh
alias that did:
setenv TMPDIR /tmp && \
id && \
mount && \
cd /usr/src && \
uname -aUK && \
date && \
mergemaster -U -u 0022 -p && \
date && \
rm -fr /usr/include.old && \
date && \
mv /usr/include{,.old} && \
date && \
rm -fr /usr/share/man && \
date && \
make installworld && \
date && \
mergemaster -F -U -u 0022 -i && \
date && \
make delete-old && \
date && \
df -k && \
gpart bootcode -b /boot/boot ada0s4
I rebooted the machine verbosely (which worked), then ran a csh
alias that did:
setenv TMPDIR /tmp && \
id && \
mount && \
cd /usr/src && \
uname -aUK && \
date && \
make delete-old-libs && \
cp /var/run/dmesg.boot /var/tmp/dmesg.boot.13.0-CURRENT && \
log_uname && \
date
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"White fear has become the unalloyed rallying cry of Trump's bid for a
second term." -- John Harwood, paraphrasing GOP strategist Stuart Stevens
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, Jul 30, 2020 at 2:48 PM David Wolfskill wrote: > > On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote: > > On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill > > wrote: > > ... > > > ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make: > > > Undefined symbol "regcomp@FBSD_1.6" > > > > > > I would appreciate a suggestion. > > > > > > > Hi, > > > > Can you describe the environment in which you're running installworld, > > please? i.e. is it just a raw installworld directly in your shell, or > > something more complicated? > > > > I observed this in testing an exceptional scenario; running > > installworld in a buildenv. installworld injects .WAIT between lib and > > libexec + other subdirs, which is supposed to prevent stuff like this > > (new binary got installed linked against new libc before new libc). > > Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving > > me with an annoyance where I had to installworld twice. > > > > Thanks, > > > > I finally just re-retried the "make installworld," and it succeeded. > To be clear, this was just a second installworld without rebuilding, correct? If so, I'm going to amend the UPDATING to add: installworld may encounter the following error: Undefined symbol "regcomp@FBSD_1.6" It is imperative that you do not interrupt the installworld, but instead let it proceed to completion, whether it succeeds or not, and run installworld again. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bc and dc -e/-f and Copyright
Hi Gavin, Thanks for reaching out! My primary concern is that `dc -e' returns to its previous auto-exit behavior. Any of the options you described would achieve that, and would be fine with me. Thanks again, Ravi (rpokala@) -Original Message- From: Gavin Howard Date: 2020-07-30, Thursday at 12:35 To: , , , , , Stefan Esser Subject: bc and dc -e/-f and Copyright Hello, My name is Gavin Howard, and I am the developer and maintainer of the new bc and dc implementation in -CURRENT. Stefan Eßer brought a discussion about my bc to my attention, and I would like to solve the problems. First, I will add some way to remove the printing of the copyright header at compile time, and FreeBSD should be able to take advantage of it as soon as I put out a new release, which should be within days after this discussion is settled. Second, there seems to be those who are unhappy with my decision to make bc and dc not exit when using the -e and -f options. While the behavior of my bc is what I personally need, I have a few options to change it back to what is expected: 1. I could make it a compile-time selection. I don't like this option, to be honest. 2. I could restore the expected behavior of -e and -f and change the environment variable to BC_EXPR_NO_EXIT (DC_EXPR_NO_EXIT) and reverse the logic. I could do this one, but Stefan mentioned to me that he would prefer less environment variables be used. I agree. 3. I could restore the expected behavior of -e and -f and add -E and -F options that do the same thing but do not exit. I think I like this option the best. I am willing to change -E and -F to something else if that would be better. When I presented these options to Stefan, he suggested that I ask you all for your opinions. I am also willing to consider other options that you might think of. Thank you for your time. Gavin Howard ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote: > On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill wrote: > ... > > ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make: > > Undefined symbol "regcomp@FBSD_1.6" > > > > I would appreciate a suggestion. > > > > Hi, > > Can you describe the environment in which you're running installworld, > please? i.e. is it just a raw installworld directly in your shell, or > something more complicated? > > I observed this in testing an exceptional scenario; running > installworld in a buildenv. installworld injects .WAIT between lib and > libexec + other subdirs, which is supposed to prevent stuff like this > (new binary got installed linked against new libc before new libc). > Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving > me with an annoyance where I had to installworld twice. > > Thanks, > I finally just re-retried the "make installworld," and it succeeded. Peace, david -- David H. Wolfskill da...@catwhisker.org "White fear has become the unalloyed rallying cry of Trump's bid for a second term." -- John Harwood, paraphrasing GOP strategist Stuart Stevens See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: CFT for vendor openzfs - week 4 reminder + memdisk images
On Wed, Jul 29, 2020 at 20:16 Chris wrote: > On Tue, 28 Jul 2020 21:16:28 -0700 Matthew Macy mm...@freebsd.org said > > > On Tue, Jul 28, 2020 at 21:06 Chris wrote: > > > > > On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said > > > > > > > On Tue, Jul 28, 2020 at 20:43 Chris wrote: > > > > > > > > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org > said > > > > > > > > > > > On Tue, Jul 28, 2020 at 8:03 PM Chris > > > wrote: > > > > > > > > > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy > mm...@freebsd.org > > > said > > > > > > > > > > > > > > > On Wednesday, July 8th I issued the initial call for testing > for > > > the > > > > > > > > update to HEAD to vendored openzfs. We'd like to give users > > > roughly a > > > > > > > > month to test before merging. The tentative merge date is > August > > > > > > > > 17th. > > > > > > > > > > > > > > > > Again, I hope it's not terribly controversial to point out > that > > > > > > > > it really rests with users of non amd64 platforms to test to > > > avoid > > > > > any > > > > > > > > unpleasant surprises the next time they update their trees > > > following > > > > > > > > the merge. > > > > > > > > > > > > > > > > amd64, i386, and aarch64 memdisk images can be found at: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/ > > > > > > > > > > > > > > Is this in an attempt to replace the opensolaris version used > now? > > > > > > > > > > > > The word "attempt" is a misnomer. If you search the mail archives > > > this > > > > > > has been the PoR for some time. > > > > > Sure. OK. I caught this thread. But must have missed the > announcement > > > > > of the intent to replace the opensolaris version with openzfs. > > > > > Do you recall which mailing list that was made to? > > > > > > > > > > Thank you for your quick reply, Matthew. > > > > > > > > > > > > > Apart from the 3 previous CFT mails, the initial intent was > discussed in > > > > December 2018. Getting FreeBSD support integrated in to openzfs took > a > > > lot > > > > more incremental PRs than I anticipated. > > > > > > > > > > > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html > > > > > > Thank you very much, Mathew. Sorry for any bother. > > > > > > > > > No bother or not much at least. It’s just been a long haul and I’d like > > to > > wrap this up. > No doubt. > FTR I'm not looking to impede you. :-) > My only concern would be that I'd need to remaster the art of ZFS. I've > got 1500 installs to maintain, and any changes tend to alarm me. :-) > I see we're a bit behind the others, if this status report is current: > > https://docs.google.com/spreadsheets/d/1CFapSYxA5QRFYy5k6ge3FutU7zbAWbaeGN2nKVXgxCI/edit#gid=0 > Will your impending commit move us closer? Is there anything others > like myself can do to help? Close to 90% of the sources files in openzfs are shared between Linux and FreeBSD. So the features will, give or take a line item, be the same. For non developers the main thing they can do to help out is to run it in their own environments to identify any changes in behavior or regressions. If you’re doing 1500 installs it’s in your best interest to make this as smooth a transition as possible. However, it’s not something you’re going to face until you move to 13. The openzfs port is available to those who want to run it on 12. -M > > > Thanks again, Matthew. > > --Chris > > > > -M > > > > > > > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, 30 Jul 2020 04:24:23 -0700, David Wolfskill
wrote:
> build{worl,kernel} and installkernel were uneventful, but:
>
> ...
> install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/Mail
> install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/mailx
> ===> usr.bin/msgs (install)
> install -s -o root -g wheel -m 555 msgs /usr/bin/msgs
> install -o root -g wheel -m 444 msgs.1.gz /usr/share/man/man1/
> ===> usr.bin/bmake (install)
> install -s -o root -g wheel -m 555 make /usr/bin/make
> install -o root -g wheel -m 444 make.1.gz /usr/share/man/man1/
> ===> usr.bin/bmake/tests (install)
> ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make:
> Undefined symbol "regcomp@FBSD_1.6"
> *** Error code 1
> *** Error code 1
> *** Error code 1
> *** Error code 1
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Running:
> FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #986
> r363660M/363660: Wed Jul 29 03:52:03 PDT 2020
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 1300102 1300102
>
> src/UPDATING has a recent entry:
> 20200729:
> r363679 has redefined some undefined behavior in regcomp(3); notably,
> extraneous escapes of most ordinary characters will no longer be
> accepted. An exp-run has identified all of the problems with this in
> ports, but other non-ports software may need extra escapes removed to
> continue to function.
>
> but while there does seem to be some relevance, I'm not seeing what
> sort of evasive maneuvers I need to make.
>
> I would appreciate a suggestion.
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskillda...@catwhisker.org
> "White fear has become the unalloyed rallying cry of Trump's bid for a
> second term." -- John Harwood, paraphrasing GOP strategist Stuart Stevens
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
It would be nice to have some way before the installkernel, I think, to make
sure
the installworld will succeed before installing kernel or world. Failure of the
latter to
install has often caused nearly-unfixable problems here. [ luckily, 'nearly.' ]
... Perhaps
using some no-fail mountpoint or jail or chroot destination?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote: > ... > Hi, > > Can you describe the environment in which you're running installworld, > please? i.e. is it just a raw installworld directly in your shell, or > something more complicated? "make installworld" is being invoked via [t]csh alias from a csh prompt, which is running within script(1), within tmux(1). I use: WITH_META_MODE=yes in /etc/src-env.conf (and have done for a few years, now). More detail is available at http://www.catwhisker.org/~david/FreeBSD/upgrade.html > I observed this in testing an exceptional scenario; running > installworld in a buildenv. installworld injects .WAIT between lib and > libexec + other subdirs, which is supposed to prevent stuff like this > (new binary got installed linked against new libc before new libc). > Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving > me with an annoyance where I had to installworld twice. FWIW, I reproduced the condition on my laptop. (That will probably require more extensive evasive maneuvers on my part, as I need to use the laptop, so I have already rebooted it to stable/12 (my normal running environment). > Thanks, > > Kyle Evans > Thank you for the prompt response! Peace, david -- David H. Wolfskill da...@catwhisker.org "White fear has become the unalloyed rallying cry of Trump's bid for a second term." -- John Harwood, paraphrasing GOP strategist Stuart Stevens See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: "make installworld" fail r363660 -> r363689 (amd64)
On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill wrote:
>
> build{worl,kernel} and installkernel were uneventful, but:
>
> ...
> install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/Mail
> install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/mailx
> ===> usr.bin/msgs (install)
> install -s -o root -g wheel -m 555 msgs /usr/bin/msgs
> install -o root -g wheel -m 444 msgs.1.gz /usr/share/man/man1/
> ===> usr.bin/bmake (install)
> install -s -o root -g wheel -m 555 make /usr/bin/make
> install -o root -g wheel -m 444 make.1.gz /usr/share/man/man1/
> ===> usr.bin/bmake/tests (install)
> ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make:
> Undefined symbol "regcomp@FBSD_1.6"
> *** Error code 1
> *** Error code 1
> *** Error code 1
> *** Error code 1
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Running:
> FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #986
> r363660M/363660: Wed Jul 29 03:52:03 PDT 2020
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 1300102 1300102
>
> src/UPDATING has a recent entry:
> 20200729:
> r363679 has redefined some undefined behavior in regcomp(3); notably,
> extraneous escapes of most ordinary characters will no longer be
> accepted. An exp-run has identified all of the problems with this in
> ports, but other non-ports software may need extra escapes removed to
> continue to function.
>
> but while there does seem to be some relevance, I'm not seeing what
> sort of evasive maneuvers I need to make.
>
> I would appreciate a suggestion.
>
Hi,
Can you describe the environment in which you're running installworld,
please? i.e. is it just a raw installworld directly in your shell, or
something more complicated?
I observed this in testing an exceptional scenario; running
installworld in a buildenv. installworld injects .WAIT between lib and
libexec + other subdirs, which is supposed to prevent stuff like this
(new binary got installed linked against new libc before new libc).
Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving
me with an annoyance where I had to installworld twice.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
"make installworld" fail r363660 -> r363689 (amd64)
build{worl,kernel} and installkernel were uneventful, but:
...
install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/Mail
install -l h -o root -g wheel -m 555 /usr/bin/mail /usr/bin/mailx
===> usr.bin/msgs (install)
install -s -o root -g wheel -m 555 msgs /usr/bin/msgs
install -o root -g wheel -m 444 msgs.1.gz /usr/share/man/man1/
===> usr.bin/bmake (install)
install -s -o root -g wheel -m 555 make /usr/bin/make
install -o root -g wheel -m 444 make.1.gz /usr/share/man/man1/
===> usr.bin/bmake/tests (install)
ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make:
Undefined symbol "regcomp@FBSD_1.6"
*** Error code 1
*** Error code 1
*** Error code 1
*** Error code 1
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Running:
FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #986
r363660M/363660: Wed Jul 29 03:52:03 PDT 2020
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
amd64 1300102 1300102
src/UPDATING has a recent entry:
20200729:
r363679 has redefined some undefined behavior in regcomp(3); notably,
extraneous escapes of most ordinary characters will no longer be
accepted. An exp-run has identified all of the problems with this in
ports, but other non-ports software may need extra escapes removed to
continue to function.
but while there does seem to be some relevance, I'm not seeing what
sort of evasive maneuvers I need to make.
I would appreciate a suggestion.
Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"White fear has become the unalloyed rallying cry of Trump's bid for a
second term." -- John Harwood, paraphrasing GOP strategist Stuart Stevens
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
