Arch Linux User Repository

@tengel Sounds like a plan. Thanks!

@kselstrup in my humble opinion, upload your functional work (rdap-client pkg) add a comment with details why you're orphaning it (link to this bin pkg, "not a rust guy", etc.) and then Orphan. I feel it's important to share the work done (and !lto hurdle overcome!) if you ask me, help the next AUR maintainer out, give the next AUR maintainer a head start with your work. Definitely link to that upstream ring bug report.

@tengel I managed to build the binaries from a PKGBUILD where I had set options=('!lto'). Perhaps I should just upload the PKGBUILD and hope that somebody with Rust skill will adopt it. I know nothing about Rust.

ksestrup: It was only then that I attempted to use a PKGBUILD — and failed. Could it be some compiler flags?

...I think I found the source of the problem - "ring" (as the error is libring) and I found this bug report: https://github.com/briansmith/ring/issues/2378 - "fixed in 0.17.9"

I took a quick look in the .cargo "src/" dir for the offender(s) (wiped the cache first, etc.):

~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f$ find . -name Cargo\.lock | xargs grep -B1 -F 0.17.8
./h2-0.4.6/Cargo.lock-name = "ring"
./h2-0.4.6/Cargo.lock:version = "0.17.8"
--
./rustls-0.21.12/Cargo.lock-name = "ring"
./rustls-0.21.12/Cargo.lock:version = "0.17.8"
--
./reqwest-0.12.9/Cargo.lock-name = "ring"
./reqwest-0.12.9/Cargo.lock:version = "0.17.8"
--
./tokio-rustls-0.26.1/Cargo.lock-name = "ring"
./tokio-rustls-0.26.1/Cargo.lock:version = "0.17.8"
--
./rustls-0.23.19/Cargo.lock-name = "ring"
./rustls-0.23.19/Cargo.lock:version = "0.17.8"

Oy veh, so we have 5 sub-sub-dependencies all specifically asking to use this "broken" version of "ring" $0.02! I'm happy to use this precompiled bin package to be honest, just like I do for pandoc-bin and shellcheck-bin for the same general aversion to carrying 469 compile-time-dep-heavy AUR source builds around.

@tengel Thank you, great mind, for thinking with me! :)

The funny thing is, when I:

» git clone https://github.com/icann/icann-rdap.git
» cd icann-rdap
» cargo build --release

then I end up with lovely binaries. It was only then that I attemted to use a PKGBUILD — and failed. Could it be some compiler flags? I have no idea, so I created this -bin package instead.

It kind of suits me well, because cargo pulls in 469 crates and it takes forever to compile on my old machine. ;)

Thanks for the suggestion for the aarch64 binatries, I'll take a look at it.

Great minds think alike, I was building the same package after reading the Hacker News link to the ICANN article and had the exact same linking problem, something in the rust "sqlx" (sqlx-macros) won't link:

.../icann-rdap-0.0.21/target/release/deps/libring-161d413643b7edf0.rlib(e7a8c4f698753110-chacha-x86_64-elf.o): relocation R_X86_64_PC32 against undefined hidden symbol `ring_core_0_17_8_OPENSSL_ia32cap_P' can not be used when making a shared object

Anyways, my thoughts after looking at the other options and working on my package - de we want to provide the groundwork for other conflicting packages? I'd like to recommend also adding aarch64 since it's on their downloads page:

...
arch=('x86_64' 'aarch64')
conflicts=("icann-rdap" "openrdap-client")
provides=("icann-rdap")
...
source_aarch64=("https://github.com/icann/icann-rdap/releases/download/v${pkgver}/icann-rdap-aarch64-unknown-linux-gnu.tar.gz")
sha256sums_aarch64=('7657a8c799ccccff2077c131ca813b2807599810edb376dbff47778d8a89a706')

If somebody wants to package the icann-rdap, built from source, I have a full PKGBUILD file. Caveat: It doesn't currently link properly, and I do not know how to fix it, which is why I made this package instead.