failed to load source for dependency boring

[bratkartoffel]

Hi,

the build for the client-java lib currently fails as it cannot fetch the boring git repository:

> Task :client:compileJava UP-TO-DATE
> Task :downloadNonLinuxLibraries SKIPPED

> Task :makeJniLibrariesDesktop
cargo build -p libsignal-jni --release
    Updating git repository `https://github.com/signalapp/boring`
error: failed to load source for dependency `boring`

Caused by:
  Unable to update https://github.com/signalapp/boring?branch=libsignal#b95cb545

Caused by:
  object not found - no match for id (b95cb545b97395cdf5da36814f7dfb6e3856a99c); class=Odb (9); code=NotFound (-3)

> Task :makeJniLibrariesDesktop FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':makeJniLibrariesDesktop'.
> Process 'command './build_jni.sh'' finished with non-zero exit value 101

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 15s
2 actionable tasks: 1 executed, 1 up-to-date

[jrose-signal]

Oops, I guess that's the problem with rebasing our branch on upstream. I'll tag releases to bring those commits back, thank you for bringing it to our attention!

[jrose-signal]

Pushed tags to the signalapp/boring repo, please try again.

[KoljaHartmann]

I have the same issue right now, so unfortunately the issue does not seem to be fixed

Updating git repository https://github.com/signalapp/boring
error: failed to load source for dependency boring

Caused by:
Unable to update https://github.com/signalapp/boring?branch=libsignal#b95cb545

Caused by:
object not found - no match for id (b95cb545b97395cdf5da36814f7dfb6e3856a99c); class=Odb (9); code=NotFound (-3)

[jrose-signal]

Hmm, I didn't expect Cargo to require that the locked commit was actually on the branch. Thanks for verifying, I'll investigate further (and I'm able to reproduce locally, my bad for not testing that cleanly before).

[marsavar]

Same here - compiling libsignal from source generates the same error mentioned in this thread.

The hash b95cb545b97395cdf5da36814f7dfb6e3856a99c appears in Cargo.lock here: https://github.com/signalapp/libsignal/blob/main/Cargo.lock#L268-L287

👉 Fix (to make the build succeed locally)

Deleting Cargo.lock and rebuilding the project regenerates the lock file with the correct hash, and the project builds just fine.

[jrose-signal]

We do want the lockfile, though; otherwise you're not building from the same sources that we at Signal did when we incorporated libsignal into a particular client app. But that's a reasonable workaround.

If I can't figure out how to convince Cargo that this is acceptable, I'll put the old boring branch back in place, so as not to disturb existing releases (not just the current release, but every tag since v0.19.0).

[jrose-signal]

Now done: the old boring branch is back in place, with a merge commit from upstream rather than rebasing, and my local testing seems to be working again. Sorry for the trouble, everyone!

[marsavar]

Working for me - thank you for addressing this so quickly!