Package Details: biglybt

Git Clone URL: (read-only, click to copy)
Package Base: biglybt
Description: Feature-filled Bittorrent client based on the Azureus project
Upstream URL:
Licenses: GPL3
Submitter: Det
Maintainer: mrxx
Last Packager: mrxx
Votes: 9
Popularity: 0.25
First Submitted: 2017-12-26 15:31
Last Updated: 2020-05-21 20:19

Latest Comments

1 2 3 4 Next › Last »

centqwerG7890FCT commented on 2020-05-26 03:00

Wow. I thought that maybe this could be improved so I deleted the link to and then restarted BiglyBT. BiglyBT remade the instant I opened it. The file is different than the that was already on it, ie. different sum. It appears that was corrupt. If anyone else has the problem then rename that file so BiglyBT can remake the file.

centqwerG7890FCT commented on 2020-05-26 02:52

Thanks mrxx. Got it working. When I saw your post the first thing I thought of is that Manjaro didn't offer openjdk 14. I had 13 as the default because that was the highest version I had. I installed jdk 14 from the AUR and set it as default but I get the exact same error. Maybe its an Arch vs. Manjaro thing going on here. So I then uninstalled jdk 14 since that wasn't it. Then I noticed that is actually on my computer and biglybt is loading it. I left out a part of the error message because I had to type it in. Something about a PowerPC library was not compatible with an AMD platform. So I renamed the file to and made a link from to This last part fixed it. Your post helped immensely. Thanks again.

mrxx commented on 2020-05-25 21:40

centqwerG7890FCT, on my machines it starts like this:

Starting BiglyBT...

Suitable java version found [java = openjdk 14.0.1 2020-04-14]

Using swt/swt-x86_64.jar v4.924

Maybe you're using an incompatible java package.

Use "archlinux-java" to fix your java environment or select a different one (I've installed jre-openjdk).

centqwerG7890FCT commented on 2020-05-23 20:58

Can't launch. I get the following errors: GUI could not be loaded. java.lang.UnsatisfiedLinkError: Could not find SWT library. Reasons: no swt-gtk-4934r5 in java.library.path [/opt/biglybt] no swt-gtk in java.library.path [/opt/biglybt] ~/.swtlib/linux/x86_64/ Can't load library: ...

mrxx commented on 2020-03-18 22:39

Thanks, eschwartz and SolarAquarion.

A fake homedir is created below $srcdir now and the installer writes everything into it.

eschwartz commented on 2020-03-18 21:53

Can't you trick the installer into writing those files into the $srcdir by faking the $HOME?

mrxx commented on 2020-03-13 15:40

SolarAquarion, I've changed this back to the situation as it was when I adopted the package (where neither the app launcher link nor the link on the Desktop worked on the build machine because the .desktop files created by the program installer had a wrong execution path).

Now, on the build machine, the program installer again creates a link on the user's Desktop, and even worse, still with wrong Exec= content.

As proposed by you this link is no longer removed immediately, but a message in post-install directs the users to remove it on their own (and, just in case it reappears one day, also the link in .local/share/applications).

SolarAquarion commented on 2020-03-11 16:47

trick the installer into "HOME=$srcdir" or something like it

SolarAquarion commented on 2020-03-11 16:06

you should probably do an if for the " ~/.local/share/applications", because what if you build it in a chroot?

You should probably do a post_upgrade and post_install message instead of deleting stuff in the PKGBUILD or something that isn't in the build chroot

mrxx commented on 2020-02-10 20:31

Added armv7h to archs.