Don't update openssl or anything depending on it (eg. coreutils, curl, sudo, libarchive and more)
until obaruns pacman is updated, otherwise pacman will be broken, and believe me, that's pain to deal with :p
If you install the new openssl-1.1 package at the same time as updating openssl, you'll be ok until obarun pacman - and any other arch packages that will utlimately need a rebuild - are updated. As a failsafe (or an alternative), make a copy of libcrypto.so.1.1 and libssl.so.1.1 from /usr/lib and move them back after the openssl update.

I was fortunate to have a recent snapshot to rollback so that I didn't have too much pain to deal with while figuring out a workaround.
thanks, that's better advice . i saw that openssl-1.1 package but it didn't occur to me to use it :p ( i just extracted the old libs out of the old package in cache)
pacman is now in obarun repo and is all good again (thanks eric)
i notice though there seems to be a curious thing with sudo, currently requiring both openssl-1.1 and openssl-3.0 (though not declared)
 ldd /usr/lib/sudo/sudoers.so | grep libssl 
	libssl.so.3 => /usr/lib/libssl.so.3 (0x00007f4047a21000)
	libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007f4047905000)
to be clear, this is an arch anomaly, and easily dealt with via the openssl-1.1 package, just not automatically so.
i tried to rebuild it with openssl3 but with no luck, sudo insist to use libssl.so.1 for some plugins. If someone found the solution. This cause me a lot of trouble to be able to build the docker image used to build the package.
8 days later
The problem is with libldap, it needs to be recompiled. Ldd shows not only what a file directly links to, but also what libraries it links to, links to. Scanelf (from pax-utils) shows only what the file directly links to.
Lennie wroteThe problem is with libldap, it needs to be recompiled. Ldd shows not only what a file directly links to, but also what libraries it links to, links to. Scanelf (from pax-utils) shows only what the file directly links to.
nice one :) ... makes sense now.. (not an arch anomaly after all :p )
that's `ldd -v <file>` , for future reference..
The rebuild of openldap failed last week. I tried to rebuild it locally and I get the same error at the same point in the testing process:
>>>>> 00:16:43 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011... /tmp/makepkg/openldap/src/openldap-2.6.3/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...

Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
./scripts/test076-authid-rewrite: line 177: 30051 Segmentation fault      $LDAPSASLWHOAMI -H $URI1 -Y $MECH -U $ID -w $PASSWD
ldapwhoami failed (139)!
>>>>> 00:16:44 Failed   test076-authid-rewrite for mdb after 1 seconds
I tried to build it on VM with fresh pure archlinux system installation. Exact same result! Another magical package at Arch linux repo. Maybe one day we will have sufficient packager to build Obarun packages by our own way.
Apparently, Alpine can build it successfully.
So, i continue to search. All idea is welcomed to fix this issue.

Powered by Obarun