This will be fixed by the next release, which should be this weekend.

Which month? :) (it still fails, but building from git works)

bump

Don't mean to beat a dead horse, but this (maybe obviously) also prevents using age as a library.

I get exactly the same error for target x86_64-unknown-openbsd running OpenBSD-stable 6.8 amd64

Interestingly I can cargo build --release the latest commit (v0.5.0-105-ge4bbc00) after cloning the repo. Also the v0.5.0 tagged commit builds without issues. I don't know what cargo install rage is trying to do differently.

I think the difference is that cargo install doesn't respect Cargo.lock. When I check out v0.5.0 and delete Cargo.lock, then cargo build repros the failure.

Just messing around, it seems like a quick patch like this might be enough to make v0.5.0 build again. Maybe something like this could be released as a bugfix branch, if the rest of main isn't ready? (I don't actually understand the dependency issue that's breaking the build, just that this version bump seems to have fixed it.)

diff --git a/age/Cargo.toml b/age/Cargo.toml
index b6d0add..4b81fb7 100644
--- a/age/Cargo.toml
+++ b/age/Cargo.toml
@@ -71,7 +71,7 @@ pin-project = "1"
 
 # Localization
 i18n-embed = { version = "0.9", features = ["fluent-system"] }
-i18n-embed-fl = "0.2"
+i18n-embed-fl = "0.3"
 lazy_static = "1"
 rust-embed = "5"
 
diff --git a/rage/Cargo.toml b/rage/Cargo.toml
index ca79a2e..b63dc7e 100644
--- a/rage/Cargo.toml
+++ b/rage/Cargo.toml
@@ -49,7 +49,7 @@ console = "0.13"
 env_logger = "0.8"
 gumdrop = "0.8"
 i18n-embed = { version = "0.9", features = ["desktop-requester", "fluent-system"] }
-i18n-embed-fl = "0.2"
+i18n-embed-fl = "0.3"
 lazy_static = "1"
 log = "0.4"
 minreq = { version = "2", features = ["https"] }

Yeah, that's close to the necessary change. The PR that fixed this is #187, which I made from and merged into master before learning that this affected cargo install rage. Had this issue been opened before that PR, I'd have directly fixed it as a 0.5.1 point release. However, it was already fixed in master, and I thought I'd be making a release that weekend. That turned out to not be the case (as we decided to make a change to the plugin protocol that I'd just stabilised, so I couldn't cut a release from master).

I've back-ported the fix onto 0.5.0 and published 0.5.1. Sorry for the delay!

Also, I should have noted earlier that you could avoid this issue by using cargo install --locked rage, to force cargo to use the provided Cargo.lock as-published (which contained a resolved dependency tree that did not have this issue).

$ cargo install rage
<...>
   Installed package `rage v0.6.0` (executables `rage`, `rage-keygen`)

Perfect! Thank you!