SOLVED Re: any way to "redo" a botched upgrade?
Thank you to all who responded in this thread and by private email -- your replies were very helpful! Following Stuart Henderson's suggestion, I found that I did indeed have a /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/Term/ReadLine/Gnu containing (among other things) an out-of-date file Gnu.so. I have now "solved" the problem by replacing the entire /usr/local/libdata/perl5/ tree with a copy of that from a twin machine (also amd64/7.3, just upgraded from 7.2) which doesn't seem to have this problem. After that the immediate problem (fatal error on /use Term::ReadPassword;/) is gone. I did another full 'pkg_add -uvv' to be on the safe side, which found a few 'file already exists', but after overwriting those everything seems to be working now. Thanks again to everyone who helped! ciao, -- -- "Jonathan Thornburg [remove -color to reply]" on the west coast of Canada "Now back when I worked in banking, if someone went to Barclays, pretended to be me, borrowed UKP10,000 and legged it, that was `impersonation', and it was the bank's money that had been stolen, not my identity. How did things change?" -- Ross Anderson
curl-8.0.1 exists in two non-comparable versions (Someone forgot to bump a REVISION)
This happened when I ran 'pkg_add -u' after upgrading an i386 system from 7.2 to 7.3: andrew@bilbo:~$ doas pkg_add -u quirks-6.121 signed on 2023-04-22T01:10:43Z quirks-6.42->6.121: ok bash-5.2.15:libiconv-1.17->1.17: ok bash-5.2.15:gettext-runtime-0.21p1->0.21.1: ok bash-5.1.16->5.2.15: ok Couldn't find ngtcp2 in first signature Couldn't find nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Couldn't find www/nghttp3 in first signature Couldn't find net/ngtcp2 in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1:ngtcp2-0.13.1: ok curl-8.0.1:nghttp3-0.9.0: ok curl-8.0.1:nghttp2-1.49.0->1.52.0: ok Couldn't find nghttp3 in first signature Couldn't find ngtcp2 in first signature Couldn't find net/ngtcp2 in first signature Couldn't find www/nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1->8.0.1: ok iperf3-3.10.1->3.12: ok libsodium-1.0.18p1->1.0.18p1: ok par2cmdline-0.7.4p0->0.7.4p0: ok smartmontools-7.3->7.3p0: ok vim-9.0.0192-no_x11->9.0.1388-no_x11: ok xz-5.2.5p2->5.4.1: ok Read shared items: ok andrew@bilbo:~$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD It seems that it succeeded in the end, but what happened? Is there a 7.3-stable curl pkg with new dependencies but the same revision as 7.3? (Or maybe a 7.2-stable pkg, since I was apparently at 8.0.1 already?) Thanks, Andrew
Re: hw RNG on APUs
Christian Weisgerber wrote: > Christian Weisgerber: > > > I built a kernel with an instrumented driver. Unfortunately, no > > entropy is provided: > > FWIW, it appears to work on the SoftIron OverDrive 1000: > > ccp: rng 058f9dad > ccp: rng f0a495ba > ccp: rng a757bdf7 > ccp: rng 31b21d19 > ccp: rng d1ce1c78 > ccp: rng 863c9199 The driver does no initialization. Maybe there is a register that needs to be initialized, and some firmwares initialize it, but others don't.
Re: hw RNG on APUs
Christian Weisgerber: > I built a kernel with an instrumented driver. Unfortunately, no > entropy is provided: FWIW, it appears to work on the SoftIron OverDrive 1000: ccp: rng 058f9dad ccp: rng f0a495ba ccp: rng a757bdf7 ccp: rng 31b21d19 ccp: rng d1ce1c78 ccp: rng 863c9199 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: passing environment variables to daemons in rc.d scripts
Hello!
jor...@geoghegan.ca (Jordan Geoghegan), 2023.04.20 (Thu) 23:08 (CEST):
> Hello,
>
> tl;dr: Is there any way to pass an environment variable to a daemon started
> with rc.d?
There's a way via login.conf(.d), here's an example I use:
sogod:\
:openfiles-cur=1024:\
:openfiles-max=2048:\
:setenv=GNUSTEP_STRING_ENCODING=NSUTF8StringEncoding:\
:tc=daemon:
Marcus
> A bit of context for those interested:
>
> I'm trying to run Apache Airflow from an rc.d script so I can make use of
> rcctl and other niceties. My rc.d script is included below.
>
> The problem I'm facing is that it seems that Airflow looks for various
> environment variables such as $HOME, $AIRFLOW_HOME, $AIRFLOW_CONFIG etc and
> I'm seeing no obvious way to pass those requisite environment variables to
> Airflow from my rc.d script. Without these variables set, Airflow annoyingly
> just looks in /dev/null for everything and fails to function.
>
> I'm probably missing something obvious, but hoping the fine folks here can
> point me in the right direction.
>
> Regards,
>
> Jordan
>
>
> # Airflow scheduler rc.d script:
>
> #!/bin/ksh
> #
>
> daemon="/usr/local/bin/airflow scheduler -D"
> daemon_flags="-l - --stderr - --stdout -"
> daemon_user="_airflowd"
> daemon_logger="daemon.info"
> daemon_timeout="60"
>
> . /etc/rc.d/rc.subr
>
> pexp=".*python.* ${daemon} ${daemon_flags}"
> rc_reload=NO
>
> rc_pre() {
> rm -f /var/airflow/airflow/airflow-scheduler.pid
> }
>
> rc_cmd $1
>
>
> # Airflow webserver r rc.d script:
>
> #!/bin/ksh
> #
>
> daemon="/usr/local/bin/airflow webserver -D -E -"
> daemon_flags="-p 8080 -l - --stderr - --stdout -"
> daemon_user="_airflowd"
> daemon_logger="daemon.info"
>
> . /etc/rc.d/rc.subr
>
> pexp=".*python.* ${daemon} ${daemon_flags}"
> rc_reload=NO
>
> rc_pre() {
> rm -f /var/airflow/airflow/airflow-webserver.pid \
> /var/airflow/airflow/airflow-webserver-monitor.pid
> }
>
> rc_cmd $1
>
Re: Will tags length influence the performance in PF?
Many thanks for the clarification. On Fri, Apr 21, 2023 at 10:19 AM David Gwynne wrote: > > inside the kernel tags are given numeric identifiers, and these numbers are > used everywhere. the length of the tag name doesnt affect performance. > > > On 21 Apr 2023, at 04:10, Cristian Danila wrote: > > > > Hello Misc, > > > > I have a technical question in regards to PF tags. > > I was always wondering if the length of tags matters > > or not in terms of performance. > > For example will PF use the same effort to match a tag > > TEST_TEST_TEST_TEST_TEST as it would do for a tag A? > > I am wondering if PF internally would just translate initially all > > tags in a set of optimized id's and later will use only those id's > > when tag filtering is used. > > > > I appreciate your answer. > > With respect, > > Claudiu > > >
Re: Will tags length influence the performance in PF?
inside the kernel tags are given numeric identifiers, and these numbers are used everywhere. the length of the tag name doesnt affect performance. > On 21 Apr 2023, at 04:10, Cristian Danila wrote: > > Hello Misc, > > I have a technical question in regards to PF tags. > I was always wondering if the length of tags matters > or not in terms of performance. > For example will PF use the same effort to match a tag > TEST_TEST_TEST_TEST_TEST as it would do for a tag A? > I am wondering if PF internally would just translate initially all > tags in a set of optimized id's and later will use only those id's > when tag filtering is used. > > I appreciate your answer. > With respect, > Claudiu >
