Arch Linux User Repository

Oh, absolutely! I didn't even think about that. Will get to it :)

Is it possible to include a .desktop file? (I created a little template here).

Currently, the easiest way to launch Briar Desktop is to run briar-desktop in a terminal. However, most users expect to find a launcher in their application menu.

Thanks again for the comments (and the testing)!

I've now limited the jdk to <18 because, well, I think it won't hurt :)

briar-headless as a dependency is now also removed.

I've added the same changes to briar-desktop-git and I've also just added a simple briar-headless-bin package as well, for good measure! :)

Ouch, my previous comment was messy. Typing in this little box huh..

Tried now. I could both build and run this, and run the jar downloaded from the website, without any briar-headless installed

OK, a "-bin" pkg it is then for the website jar.

=> runtimes: thanks. yes. the only issue is that once jre-openjdk is for example java 18, then there are two (repo) javas that briar can run wit. User might have installed the jre17-openjdk (assuming it exists), or they might install jre-openjdk (18). Briar should still run, but in this case, could not be locked to /usr/lib/jvm/java-17-openjdk/bin/java, but should somehow find 17 or 18 :) anyway, later prob... And maybe there are tools for solving this, or other pkgs have done something clever. I guess a program that requires java >= 11 is in this situation now. 11 or 17 might be installed, but 8 might be the default.

Ooooh, thanks for this (sorry for always forgetting to check issues in the pinebookpro-things-repo)

=> briar-headless: have you tried running (and building – maybe it's a makedep?) it without it? (it's entirely possible that it's just pulled in indirectly via the submodule or something like that; didn't test that for lack of time) I'm asking because at least a while ago it seemed to have been part of / a requirement for this package as well; see https://code.briarproject.org/briar/briar-desktop/-/merge_requests/5#note_53432 for example

I'd be happy to drop it as a dep, don't get me wrong – just want to make sure!

=> runtimes: That's quite a reasonable point that I hadn't considered. Locking the dependency down to >=17 <17 doesn't make sense as long as 18 isn't out, but running it explicitly /usr/lib/jvm/java-17-openjdk/bin/java sounds like a great idea – I'll get to that!

As for directly using the .jar from upstream: I'm in no way against it, but that should be a separate package for users to have a choice between building from source or using something prebuilt. Or more specifically: that should go in a briar-desktop-bin package :) (Also discussed a bit here: https://code.briarproject.org/briar/briar-desktop/-/issues/56#note_61417)

/edit

scratch the briar-headless-question of mine – if it can run with a single upstream- .jar, then it probably doesn't need a separate briar-headless :D

Hi! Moving over here (from https://gitlab.com/ohfp/pinebookpro-things/-/issues/4)

1. briar-headless is not a dependency, it's part of the old desktop client right.

2. On my system, the default runtime is jaSo, the script starting briar shouldva-8: /usr/lib/jvm/default-runtime -> java-8-openjdk

But, I also have jre-openjdk installed of course (that's java 17).

So, I think that the script starting briar-desktop should run /usr/lib/jvm/java-17-openjdk/bin/java -jar /usr/share/java/briar-desktop.jar. Not relying on what the default java is set to.

I guess it ideally should pick java 18 instead if that exists (and 17 doesn't), since it depends on >= 17. But I don't know if there is some clever way of doing that (instead of letting the script brute force it).

1. I'm thinking that this pkg could be build by just downloading the plain jar from https://briarproject.org/download-briar-desktop/ and running it with /usr/lib/jvm/java-17-openjdk/bin/java -jar ./briar-desktop.jar. Right? But remember that the downloaded source name must be unique, see the :: syntax: https://wiki.archlinux.org/title/PKGBUILD#Sources but your probably knew that :)

At least 1. and 2. above are valid for the git pkg as well.