app in flatpak about biglybt

[ghazyami]

I started working on packaging BiglyBT as a flatpak, I got it to work, needs more fine-tuning and dialling down of permissions to better adhere to Flathub's requirements.
If anyone is interested in testing, please reach out.
If BiglyBT maintainers are interested in being part of the application submission into Flathub once it's in a good shape (write permission on the repo that will be created containing the manifests), please also reach out.

Thanks!

[ghazyami]

BiglyBT is now published at Flathub https://flathub.org/apps/details/com.biglybt.BiglyBT 🎊

[parg]

There's config settings under Options->Interface->Start

e.g. Check for latest version when BiglyBT starts

[legacychimera247]

thanks for your answer...i'm not a developer, just a normal user but i'm becaming more and more fan of flatpaks because of it's advantages. For runtime is intended a set of libraries shared across all the flatpak apps, for example gnome apps in the gnome repos relies on the gnome x.xx runtime, kde apps relies on the kde runtime and flathub apps relies on freedesktop and/or gnome x.xx runtime.

the first advantage in that is that you could just download 1 runtime for all the apps that use it, and if you want to remove the app you can do it without leaving garbage on the pc cause all the libraries and dependencies are inside the runtime (whichever is) that can easily removed if not needed anymore, without leaving clutter at all. in case those runtimes does not provide the dependencies you need, you can include them inside your flatpak (maybe just bundle the one you need and just link the others to the runtime), so again in case of unistallation there is no clutter left behind, and that to me is great.

As for the installation, flatpak can be installed through terminal with a simple command, through a flatpak file, by simply downloading a flatpak file and then doing 2 click on it to install it like every normal .rpm and .deb (at least in gnome and kde distros, and anyway all the distro that, have gnome software and flatpak support installed), and by the store like every other app.

if you want to distribute your app in software stores there is now a repo called flathub which is the official repo for all the flatpak app, so simply insert that in terminal and gnome software and kde discover are ready to install flatpaks.

Don't know if it's doable but at least to me seems the way to go, and considering this is an universal format you have one single flatpak for every distro, and every desktop so you will have less hassle...

[parg]

If someone does it then it will be done, until then it won't be done.

[ferdnyc]

@ghazyami Those defaults are set in core.config.impl.ConfigurationDefaults.java; this patch applied to the source before building would default them off in the Flatpak build.

From 077c717ed6dac69a5df71a4553491be3ef37d195 Mon Sep 17 00:00:00 2001
From: "FeRD (Frank Dana)" <[email protected]>
Date: Tue, 3 May 2022 21:35:25 -0400
Subject: [PATCH] Disable update checks by default

---
 .../com/biglybt/core/config/impl/ConfigurationDefaults.java   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/core/src/com/biglybt/core/config/impl/ConfigurationDefaults.java b/core/src/com/biglybt/core/config/impl/ConfigurationDefaults.java
index 50f4ed59f..5586c922a 100644
--- a/core/src/com/biglybt/core/config/impl/ConfigurationDefaults.java
+++ b/core/src/com/biglybt/core/config/impl/ConfigurationDefaults.java
@@ -322,8 +322,8 @@ public class ConfigurationDefaults {
 	def.put("Default save path", f.getAbsolutePath());
 	def.put("saveTo_list.max_entries", new Long(15));
 
-    def.put("update.start",TRUE);
-    def.put("update.periodic",TRUE);
+    def.put("update.start",FALSE);
+    def.put("update.periodic",FALSE);
     def.put("update.opendialog",TRUE);
     def.put("update.autodownload", FALSE);
     def.put("update.anonymous", FALSE);
-- 
2.35.1

(Also attached:)
0001-Disable-update-checks-by-default.patch.txt

[parg]

BiglyBT supports configuration presets in the same way as its predecessor

https://wiki.vuze.com/w/Configuration_directory

The "custom" directory can be wither in the installation folder or per-user configuration folder

[TuxPaper]

First time I've looked at flatpak, but it initially looks promising. I especially like the idea of being able to bundle our own libraries, since our SWT library is always near-bleeding edge, and most distros have a SWT version from 5 years ago.

I'm not quite sure yet if flatpak has all the tools to handle our app, I'd have to dig in some more. The first worrying thing is they seem to link an app to a "runtime" (gnome, in all their examples). If by "runtime" they mean desktop environment, we try to keep pretty "runtime" independent. We can run on gnome just as well as KDE and probably XFCE, providing there's a GTK library.

Also, I'm not sure if their suggesting we have the whole .java source code in the bundle and have every user compile it. That seems insane to me, not only in the sheer waste of time since the jars are cpu/os independent, but also in requiring the user to have a full JDK instead of just a nice headless-jre. But again, I haven't read all the docs, I could be missing a section.

I'll leave this issue open as an enhancement. If anyone wants to try to make a flatpak before we get around to it, they are very very much welcome!

On a side note, I spent some time before the release to make the code a bit more distro friendly (and made a proper .desktop file, etc). We don't have the time (or knowledge) to become maintainers of a distro package, and having someone else build and maintain them will be one of our requests in our github "Contributers" file once we write it.

[legacychimera247]

considering now java has been released for flatpak, maybe is now time to take a look at this? :)

[akurtakov]

We are experimenting with releasing Eclipse as flatpak and so far it looks quite promissing. See http://eclipse.matbooth.co.uk/flatpak/index.html .
There is even maven plugin for creating flatpaks http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/maven-plugins/eclipse-flatpak-packager (snapshot repo at https://repo.eclipse.org/content/repositories/cbi-snapshots/) .
Hope that helps.
If you decide to try this maven plugin and have issues please report them at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CBI

[ferdnyc]

Flatpak does indeed build on top of "runtimes", it's basically a way of still taking advantage of shared libraries within the Flatpak environment. You can have the same runtime installed at multiple different versions, and apps built on top of any particular version will use the appropriate one. For instance, flathub currently has runtimes for three GNOME releases, and the gnome-nightly repo offers a fourth bleeding-edge runtime. (Interestingly, even though GNOME 3.30 released September 5 it still hasn't hit flathub yet, unless my metadata is just lagging for some reason. That's... not exactly confidence-inspiring regarding the whole flatpak "thing"):

$ flatpak search org.gnome.Platform
Application ID     Version Branch Remotes       Description                                
org.gnome.Platform         master gnome-nightly Shared libraries used by GNOME applications
org.gnome.Platform         3.28   flathub       Shared libraries used by GNOME applications
org.gnome.Platform         3.26   flathub       Shared libraries used by GNOME applications
org.gnome.Platform         3.24   flathub       Shared libraries used by GNOME applications

AppImage bundles

If you wanted to release completely self-contained bundles for BiglyBT, without having to worry about runtimes, one solution to that might be an AppImage. AppImages are self-mounting filesystem images in an executable package. When run they mount to a directory such as /tmp/.mount_zrAnDOm (using FUSE) and launch the app from there. Any bundled shared libs will be used, any that aren't bundled will fall back to the system shared library path. It's how OpenShot Video Editor has been distributing Linux builds for some time, and it's mostly worked well.

$ ./OpenShot-v2.4.3-release-candidate-1537332770-x86_64.AppImage &
$ mount |grep OpenShot
/var/tmp/OpenShot-v2.4.3-release-candidate-1537332770-x86_64.AppImage on
 /tmp/.mount_znKPaI type fuse.OpenShot-v2.4.3-release-candidate-1537332770-x86_64.AppImage
 (ro,nosuid,nodev,relatime,user_id=1000,group_id=1000)

(See partial contents listing at the end of this comment.)

In the case of BiglyBT and Java, a BiglyBT.AppImage could either bundle usr/bin/java and the full standard OpenJDK JRE distribution inside the AppImage (making it completely self-contained), or it could use the system java executable (requiring that java be installed locally), and set the classpath to prioritize whatever bundled .jar files are part of the AppImage.

Problems/Lessons

Shared library forwards-incompatibility

The only major issue so far has been OpenShot/openshot-qt#1757, a library-versioning problem where a bundled shared library (libdrm) was older than a system shared library that had the same SONAME, and wasn't fully forwards-compatible. Because OpenShot was bundling a build of libdrm.so.2, that was the version being loaded. But the system libGL.so.1 in use was linked to the system libdrm.so.2 which contained a symbol drmGetDevices2 that wasn't present in the bundled libdrm.so.2, causing OpenShot to crash on launch with an undefined symbol error.

That kind of sucked, and it was a lesson in what can go wrong when libraries ignore forward compatibility in their SONAME versioning. If libdrm had gotten a SONAME bump to libdrm.so.3 when drmGetDevices2 was added, there wouldn't have been any problem. The system libGL.so.1 would've been linked with, and loaded, a system libdrm.so.3. Our bundled libs that were linked against the bundled libdrm.so.2 would've loaded that. But because shared libraries typically don't get an SONAME bump when they add symbols (since it doesn't break backwards compatibility), it can cause an issue in AppImage-type situations. The solution for OpenShot was to just remove libdrm.so.2 from the AppImage, so the system version is used in all instances.

But if the AppImage's bundled resources are going to be newer than the system versions, then there shouldn't be any such problems. (Of course .jar files aren't versioned or loaded the same way ELF shared dynamic libraries are, so it's not an issue anyway.) An AppImage would be a pretty ideal packaging model in that case. OpenShot tends to be built with very out-of-date dependencies, which is the core of the problem. (The bundled Qt in the AppImage is still Qt 5.2.1, which was released in February 2014 — the current release is Qt 5.11.2! I've griped about this at great length to the lead developers, but so far ineffectually.)

Native platform dialogs in Qt

The only other issue with the AppImage bundles, so far, has been access to native dialogs. OpenShot is written in Qt (actually PyQt5), and a properly-configured Qt installation uses native desktop versions of things like the file chooser and font picker, which on my system running Gnome Shell means the Gnome dialogs. (The "properly-configured" part can be tricky — native dialogs are used out of the box on Fedora, but Ubuntu users have had trouble getting their Qt to support them. It's all about how the Qt theme's platform component plugins are set up.)

However, when running from the AppImage, the native dialogs aren't available (even on Fedora), so OpenShot falls back to the built-in Qt file chooser. It's not ideal, since Qt's file chooser is kind of poor, but it's not a showstopper. If there's a solution to this problem, we haven't found it yet. (Not that we've tried hard enough, IMHO. Updating the bundled Qt to something more recent might solve it, if the developer would just do it. Qt made major improvements to native-dialogs support in Qt 5.7.)

I'm honestly not sure what would happen with Java/SWT, in this regard. I notice that BiglyBT also uses native Gnome dialogs for things like the file chooser and color picker, when I have it installed locally.

Partial contents of the OpenShot AppImage

(Ignore that all the shared libs are in usr/bin/. The OpenShot developer is packaging it that way, and it works even though it looks stupid. I've given up trying to talk sense into him. But it would work the same if they were in usr/lib/.)

$ find /tmp/.mount_znKPaI -maxdepth 3
/tmp/.mount_znKPaI
/tmp/.mount_znKPaI/.DirIcon
/tmp/.mount_znKPaI/AppRun
/tmp/.mount_znKPaI/openshot-qt.desktop
/tmp/.mount_znKPaI/openshot-qt.svg
/tmp/.mount_znKPaI/usr
/tmp/.mount_znKPaI/usr/bin
/tmp/.mount_znKPaI/usr/bin/blender
/tmp/.mount_znKPaI/usr/bin/classes
/tmp/.mount_znKPaI/usr/bin/effects
/tmp/.mount_znKPaI/usr/bin/gevent.ares.so
/tmp/.mount_znKPaI/usr/bin/gevent.corecext.so
/tmp/.mount_znKPaI/usr/bin/gevent._semaphore.so
/tmp/.mount_znKPaI/usr/bin/gevent._util_py2.py
/tmp/.mount_znKPaI/usr/bin/greenlet.cpython-34m.so
/tmp/.mount_znKPaI/usr/bin/imageformats
/tmp/.mount_znKPaI/usr/bin/images
/tmp/.mount_znKPaI/usr/bin/language
/tmp/.mount_znKPaI/usr/bin/launch
/tmp/.mount_znKPaI/usr/bin/launch.py
/tmp/.mount_znKPaI/usr/bin/launch-openshot
/tmp/.mount_znKPaI/usr/bin/libavcodec.so.54
/tmp/.mount_znKPaI/usr/bin/libavcodec.so.57
/tmp/.mount_znKPaI/usr/bin/libavformat.so.57
/tmp/.mount_znKPaI/usr/bin/libavutil.so.52
/tmp/.mount_znKPaI/usr/bin/libavutil.so.55
/tmp/.mount_znKPaI/usr/bin/libbluray.so.1
/tmp/.mount_znKPaI/usr/bin/libbz2.so.1.0
/tmp/.mount_znKPaI/usr/bin/libcairo.so.2
/tmp/.mount_znKPaI/usr/bin/libchromaprint.so.0
/tmp/.mount_znKPaI/usr/bin/libcroco-0.6.so.3
/tmp/.mount_znKPaI/usr/bin/libcrypto.so.1.0.0
/tmp/.mount_znKPaI/usr/bin/libcrystalhd.so.3
/tmp/.mount_znKPaI/usr/bin/libdatrie.so.1
/tmp/.mount_znKPaI/usr/bin/libfdk-aac.so.1
/tmp/.mount_znKPaI/usr/bin/libffi.so.6
/tmp/.mount_znKPaI/usr/bin/libfftw3.so.3
/tmp/.mount_znKPaI/usr/bin/libfontconfig.so.1
/tmp/.mount_znKPaI/usr/bin/libfreetype.so.6
/tmp/.mount_znKPaI/usr/bin/libgcrypt.so.11
/tmp/.mount_znKPaI/usr/bin/libgdk_pixbuf-2.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgio-2.0.so
/tmp/.mount_znKPaI/usr/bin/libgio-2.0.so.0
/tmp/.mount_znKPaI/usr/bin/libglapi.so.0
/tmp/.mount_znKPaI/usr/bin/libglib-2.0.so
/tmp/.mount_znKPaI/usr/bin/libgme.so.0
/tmp/.mount_znKPaI/usr/bin/libgmodule-2.0.so
/tmp/.mount_znKPaI/usr/bin/libgmodule-2.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgmp.so.10
/tmp/.mount_znKPaI/usr/bin/libgnutls.so.28
/tmp/.mount_znKPaI/usr/bin/libgomp.so.1
/tmp/.mount_znKPaI/usr/bin/libgraphite2.so.3
/tmp/.mount_znKPaI/usr/bin/libgsm.so.1
/tmp/.mount_znKPaI/usr/bin/libgssapi_krb5.so.2
/tmp/.mount_znKPaI/usr/bin/libgstapp-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgstaudio-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgstbase-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgstpbutils-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgstreamer-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgsttag-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgstvideo-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libgthread-2.0.so
/tmp/.mount_znKPaI/usr/bin/libharfbuzz.so.0
/tmp/.mount_znKPaI/usr/bin/libhogweed.so.2
/tmp/.mount_znKPaI/usr/bin/libicudata.so.52
/tmp/.mount_znKPaI/usr/bin/libicui18n.so.52
/tmp/.mount_znKPaI/usr/bin/libicuuc.so.52
/tmp/.mount_znKPaI/usr/bin/libjpeg.so.8
/tmp/.mount_znKPaI/usr/bin/libk5crypto.so.3
/tmp/.mount_znKPaI/usr/bin/libkrb5support.so.0
/tmp/.mount_znKPaI/usr/bin/libkrb5.so.3
/tmp/.mount_znKPaI/usr/bin/liblcms2.so.2
/tmp/.mount_znKPaI/usr/bin/liblqr-1.so.0
/tmp/.mount_znKPaI/usr/bin/libltdl.so.7
/tmp/.mount_znKPaI/usr/bin/libMagickCore.so.5
/tmp/.mount_znKPaI/usr/bin/libMagickWand.so.5
/tmp/.mount_znKPaI/usr/bin/libMagick++.so.5
/tmp/.mount_znKPaI/usr/bin/libmodplug.so.1
/tmp/.mount_znKPaI/usr/bin/libmp3lame.so.0
/tmp/.mount_znKPaI/usr/bin/libnettle.so.4
/tmp/.mount_znKPaI/usr/bin/libnuma.so.1
/tmp/.mount_znKPaI/usr/bin/libogg.so.0
/tmp/.mount_znKPaI/usr/bin/libopencore-amrnb.so.0
/tmp/.mount_znKPaI/usr/bin/libopencore-amrwb.so.0
/tmp/.mount_znKPaI/usr/bin/libopenjp2.so.7
/tmp/.mount_znKPaI/usr/bin/libopenjpeg.so.2
/tmp/.mount_znKPaI/usr/bin/libopenshot-audio.so.6
/tmp/.mount_znKPaI/usr/bin/libopenshot.so.16
/tmp/.mount_znKPaI/usr/bin/libopus.so.0
/tmp/.mount_znKPaI/usr/bin/liborc-0.4.so.0
/tmp/.mount_znKPaI/usr/bin/libpangocairo-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libpangoft2-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libpango-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libpgm-5.1.so.0
/tmp/.mount_znKPaI/usr/bin/libpixman-1.so.0
/tmp/.mount_znKPaI/usr/bin/libpng12.so.0
/tmp/.mount_znKPaI/usr/bin/libpython3.4m.so.1.0
/tmp/.mount_znKPaI/usr/bin/libQt5Core.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5DBus.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Gui.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Network.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5OpenGL.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Positioning.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5PrintSupport.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Qml.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Quick.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Sensors.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Sql.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Svg.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5WebKitWidgets.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5WebKit.so.5
/tmp/.mount_znKPaI/usr/bin/libQt5Widgets.so.5
/tmp/.mount_znKPaI/usr/bin/library.zip
/tmp/.mount_znKPaI/usr/bin/librsvg-2.so.2
/tmp/.mount_znKPaI/usr/bin/libschroedinger-1.0.so.0
/tmp/.mount_znKPaI/usr/bin/libshine.so.3
/tmp/.mount_znKPaI/usr/bin/libsnappy.so.1
/tmp/.mount_znKPaI/usr/bin/libsoxr.so.0
/tmp/.mount_znKPaI/usr/bin/libspeex.so.1
/tmp/.mount_znKPaI/usr/bin/libsqlite3.so.0
/tmp/.mount_znKPaI/usr/bin/libssh-gcrypt.so.4
/tmp/.mount_znKPaI/usr/bin/libssl.so.1.0.0
/tmp/.mount_znKPaI/usr/bin/libswresample.so.2
/tmp/.mount_znKPaI/usr/bin/libswscale.so.4
/tmp/.mount_znKPaI/usr/bin/libtasn1.so.6
/tmp/.mount_znKPaI/usr/bin/libthai.so.0
/tmp/.mount_znKPaI/usr/bin/libtheoradec.so.1
/tmp/.mount_znKPaI/usr/bin/libtheoraenc.so.1
/tmp/.mount_znKPaI/usr/bin/libtwolame.so.0
/tmp/.mount_znKPaI/usr/bin/libva-drm.so.1
/tmp/.mount_znKPaI/usr/bin/libva.so.1
/tmp/.mount_znKPaI/usr/bin/libva-x11.so.1
/tmp/.mount_znKPaI/usr/bin/libvdpau.so.1
/tmp/.mount_znKPaI/usr/bin/libvorbisenc.so.2
/tmp/.mount_znKPaI/usr/bin/libvorbis.so.0
/tmp/.mount_znKPaI/usr/bin/libvo-amrwbenc.so.0
/tmp/.mount_znKPaI/usr/bin/libvpx.so.1
/tmp/.mount_znKPaI/usr/bin/libwavpack.so.1
/tmp/.mount_znKPaI/usr/bin/libwebp.so.5
/tmp/.mount_znKPaI/usr/bin/libX11-xcb.so.1
/tmp/.mount_znKPaI/usr/bin/libx264.so.148
/tmp/.mount_znKPaI/usr/bin/libx264.so.152
/tmp/.mount_znKPaI/usr/bin/libx265.so.151
/tmp/.mount_znKPaI/usr/bin/libXau.so.6
/tmp/.mount_znKPaI/usr/bin/libxcb-dri2.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-dri3.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-glx.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-icccm.so.4
/tmp/.mount_znKPaI/usr/bin/libxcb-image.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-keysyms.so.1
/tmp/.mount_znKPaI/usr/bin/libxcb-present.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-randr.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-render.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-render-util.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-shape.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-shm.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-sync.so.1
/tmp/.mount_znKPaI/usr/bin/libxcb-util.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-xfixes.so.0
/tmp/.mount_znKPaI/usr/bin/libxcb-xkb.so.1
/tmp/.mount_znKPaI/usr/bin/libXcomposite.so.1
/tmp/.mount_znKPaI/usr/bin/libXdamage.so.1
/tmp/.mount_znKPaI/usr/bin/libXdmcp.so.6
/tmp/.mount_znKPaI/usr/bin/libXext.so.6
/tmp/.mount_znKPaI/usr/bin/libXfixes.so.3
/tmp/.mount_znKPaI/usr/bin/libXi.so.6
/tmp/.mount_znKPaI/usr/bin/libxkbcommon.so.0
/tmp/.mount_znKPaI/usr/bin/libxkbcommon-x11.so.0
/tmp/.mount_znKPaI/usr/bin/libxml2.so.2
/tmp/.mount_znKPaI/usr/bin/libXrender.so.1
/tmp/.mount_znKPaI/usr/bin/libxshmfence.so.1
/tmp/.mount_znKPaI/usr/bin/libxslt.so.1
/tmp/.mount_znKPaI/usr/bin/libxvidcore.so.4
/tmp/.mount_znKPaI/usr/bin/libXxf86vm.so.1
/tmp/.mount_znKPaI/usr/bin/libzmq.so.3
/tmp/.mount_znKPaI/usr/bin/libzvbi.so.0
/tmp/.mount_znKPaI/usr/bin/mmap.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/openshot-qt
/tmp/.mount_znKPaI/usr/bin/openshot-qt.svg
/tmp/.mount_znKPaI/usr/bin/openshot-qt.wrapper
/tmp/.mount_znKPaI/usr/bin/platforms
/tmp/.mount_znKPaI/usr/bin/presets
/tmp/.mount_znKPaI/usr/bin/profiles
/tmp/.mount_znKPaI/usr/bin/PyQt5.Qsci.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.Qt.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtCore.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtDBus.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtDesigner.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtGui.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtHelp.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtMultimedia.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtMultimediaWidgets.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtNetwork.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtOpenGL.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtPositioning.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtPrintSupport.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtQml.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtQuick.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtSensors.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtSerialPort.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtSql.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtSvg.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtTest.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtWebKit.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtWebKitWidgets.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtWidgets.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtX11Extras.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.QtXmlPatterns.so
/tmp/.mount_znKPaI/usr/bin/PyQt5.uic.widget-plugins
/tmp/.mount_znKPaI/usr/bin/PyQt5._QOpenGLFunctions_2_0.so
/tmp/.mount_znKPaI/usr/bin/qt.conf
/tmp/.mount_znKPaI/usr/bin/readline.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/settings
/tmp/.mount_znKPaI/usr/bin/sip.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/termios.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/tests
/tmp/.mount_znKPaI/usr/bin/timeline
/tmp/.mount_znKPaI/usr/bin/titles
/tmp/.mount_znKPaI/usr/bin/transitions
/tmp/.mount_znKPaI/usr/bin/windows
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.constants.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.context.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.error.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.message.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.socket.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython.utils.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython._device.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython._poll.so
/tmp/.mount_znKPaI/usr/bin/zmq.backend.cython._version.so
/tmp/.mount_znKPaI/usr/bin/zmq.devices.monitoredqueue.so
/tmp/.mount_znKPaI/usr/bin/zmq.utils.initthreads.so
/tmp/.mount_znKPaI/usr/bin/zmq.utils.rebuffer.so
/tmp/.mount_znKPaI/usr/bin/_bz2.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_cn.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_hk.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_iso2022.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_jp.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_kr.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_codecs_tw.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_ctypes.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_hashlib.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_json.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_lzma.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_multibytecodec.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_multiprocessing.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_opcode.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/bin/_openshot.so
/tmp/.mount_znKPaI/usr/bin/_ssl.cpython-34m-x86_64-linux-gnu.so
/tmp/.mount_znKPaI/usr/lib
/tmp/.mount_znKPaI/usr/lib/mime
/tmp/.mount_znKPaI/usr/share
/tmp/.mount_znKPaI/usr/share/mime
/tmp/.mount_znKPaI/usr/share/pixmaps

[Dyras]

3 years later. Is this happening? I really wish to see BiglyBT as a Flatpak.

[parg]

Hi ghazyami,

Thanks for working on it! I personally don't have the bandwidth to get involved with the build side of things so please go ahead and submit to Flathub when ready.

Kind regards,
Parg

[ghazyami]

Download badges are available here https://flathub.org/badges

sample

<a href='https://flathub.org/apps/details/com.biglybt.BiglyBT'><img width='240' alt='Download on Flathub' src='https://flathub.org/assets/badges/flathub-badge-en.png'/></a>

[ghazyami]

Hi, so far, overall it has been working fine with me.
One small issue now is plugin auto update, since flatpak package ships the application main directory in read-only BiglyBT will fail to apply downloaded plugin installation (e.g. move / modify biglybt/plugins),

Is there a flag that can be passed to disable plugin auto update, or maybe use another directory that is writable like ~/.biglybt/plugins that is currently used for user specific plugins for updates?

[ghazyami]

Thanks for your feedback, currently I am using the binary directly and not building from source, is there a way to pass these flags at runtime? Something like -Dupdate.start=FALSE

[ghazyami]

Thank you very much, an update using custom presets directory is now published on Flathub

[ghazyami]

Just a quick update, since BiglyBT was published on Flathub almost 5 months ago (2022-04-11):

• It has been downloaded 2,000+ times (unique installs according to Flathub statistics).
• It has been updated to the latest version released on July

No unexpected behaviour caused by the packaging so far (that I am aware of).

[parg]

Most excellent!

[S7venLights]

Very happy to have Bigly on Flathub!

Two questions/issues with the flatpak (also posted here flathub/com.biglybt.BiglyBT#7)

1. How do I allow it to download in different locations without giving the flatpak full access to the home directory using Flatseal.
2. How do I get the 'Play Now' streaming to work? Gives an Error (VLC does not appear to be installed correctly) I tried to install VLC as a flatpak and as a package in a Fedora Silverblue Toolbox.

I'm On Fedora Silverblue

[S7venLights]

Very happy to have Bigly on Flathub!

Two questions/issues with the flatpak (also posted here flathub/com.biglybt.BiglyBT#7)

1. How do I allow it to download in different locations without giving the flatpak full access to the home directory using Flatseal.

2. How do I get the 'Play Now' streaming to work? Gives an Error (VLC does not appear to be installed correctly) I tried to install VLC as a flatpak and as a package in a Fedora Silverblue Toolbox.

I'm On Fedora Silverblue

Figured out 1:
With the app Flatseal I added these filesystem access paths to Flatseal:
~/.biglybt
and
~/InputYourPath/Movies

where ~/ means home directory

2. Play Now Feature
   This may require input from Bigly Maintainers, see this comment.

[ghazyami]

@S7venLights ~/.biglybt is already granted by default. It's already part of the flatpak manifest.

[S7venLights]

Oh, I see it under the persistent section of Flatseal. But after setting a custom path for downloads my bigly wouldn't work until I allowed ~/.biglybt too. But I now removed that permission and it still works.
I guess it could have been something else I did or a flatseal bug.

[parg]

If anyone is around can they please take a look at

https://www.reddit.com/r/BiglyBT/comments/10ak05k/error_data_missing_runflatpakdoc/

thanks!

[S7venLights]

Can anyone help with the Play Now Feature
This may require input from Bigly Maintainers, see this comment: flathub/com.biglybt.BiglyBT#7

[parg]

Play Now requires the "Embedded Media Player" plugin to be installed and, ideally, configured to use VLC.

You don't need to explicitly enable sequential download or anything else, that is done automatically on playback.

Alternatively use the "copy stream URI to clipboard" menu option and then paste this explicitly into a player that supports network streams.

[S7venLights]

@parg Hi thanks for your answer, Play now does not work in the linux Flatpak package of Bigly BT as troubleshot in that link I shared above.
I couldn't get any URI to work with VLC flatpak with all the standard permissions granted.

[parg]

Right-click on a download or a file in the Files View and select the Content menu tab. Then go to Media Server->Copy Stream URI to clipboard (or one of the others). Open VLC and go to the Media menu and select "open stream" and paste it in

[S7venLights]

Yes, I did do that, with all the various URI links, VLC doesn't do anything but show a black screen with the logo, no error dialogue.
Tested with completed downloads and current.

Are you testing with the flatpak version of BiglyBT and VLC?

I'm in a Wayland login if that has any impact on the situation

I also tried adding a "Talks" to, permission to each app from Flatseal in the Sytem Bus section Let VLC talk to BiglyBT

[ferdnyc]

@parg @S7venLights @ghazyami

So, I took a look at this just now.

Initial install

Installing the flatpak version of com.biglybt.BiglyBT into my user space from flathub went without a hitch, and I whipped through a quick config of what I needed to set.

I had no trouble installing RSSFeed Scanner from Chrome, as a test of the browser scheme handling.

Embedded browser is a browsn't

First issue, probably unrelated but I can't say for sure it doesn't potentially impact the media functionality so I'll mention it: The packaged swt-x86_64.jar doesn't include the org/eclipse/swt/internal/mozilla/nsIWebBrowserChrome.class found in the BiglyBT-distributed copies, so the embedded browser functionality is disabled in the Flatpak build. (Immediately noticeable in the non-functional Dashboard view.)

Anyway, ignoring the browser issue for now, I went and grabbed an unstarted torrent from my main install, to download with this instance instead. I imported it in the Stopped state and set about attempting to Play Locally.

Video, video, who's got the video?

First issue: The torrent I picked happened to include some subtitle files along with the video, and all media-player functionality on the torrent seemed resolutely determined to serve the first .srt file instead of the video content. Clicking the "Play Locally" button in the table got me this output on the console:

play: <40-character hash>-0.srt

...and no other output. At one point, after right-clicking and choosing Media Server > Copy Local Stream URI to Clipboard, then pasting the URL into Chrome, I was actually looking at the contents of the .srt file. Which was actually helpful, because it told me two things:

1. The built-in webserver on port 5xxxx was accessible and serving content
2. It was serving the wrong content

Forcing the issue

So I went back to BiglyBT, expanded the torrent contents, and clicked Play Now on the video file itself.

Wherefore art thou, VLC?

That netted me, first, an error about VLC being missing. (Unsurprising, since it's not bundled with the app and I don't have Flatpak VLC installed. Flatpak's whole deal is that it makes it unreasonably difficult for installed apps to interoperate, so it certainly wasn't going to run the copy in /usr/bin/vlc.)

Going it alone

Once I'd been suitably chastized about not making VLC available to it, it did manage to launch the embedded media player in a new window. Once the torrent had grabbed enough pieces of the video file,it even resized to the video's frame dimensions and displayed the runtime on its controls overlay. All seemed well, and the countdown to stream initiation dutifully counted. (Mostly down, though it did jump up from 8 seconds to 3 minutes, briefly, before going back to 5 seconds.)

Crash & burn

Once the countdown expired and the stream attempted to start, instead of a playing video I was treated to a console NPE error message, a locked-up player window that wouldn't close or resize, and an eventual "Not Responding" popup that force-closed the player window and took all the rest of BiglyBT down with it.

Exceptionally null

So... not stellar. Here's the NPE that was logged:

java.lang.NullPointerException
	at com.vuze.mediaplayer.mplayer.MPlayerInstance.doOpen(MPlayerInstance.java:152)
	at com.vuze.mediaplayer.mplayer.MPlayer.doOpen(MPlayer.java:558)
	at com.vuze.mediaplayer.BaseMediaPlayer.open(BaseMediaPlayer.java:141)
	at com.vuze.mediaplayer.swt.Player.open(Player.java:496)
	at com.azureus.plugins.azemp.ui.swt.emp.EmbeddedPlayerWindowSWT$7.runSupport(EmbeddedPlayerWindowSWT.java:500)
	at com.biglybt.core.util.AERunnable.run(AERunnable.java:36)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:5067)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4573)
	at com.biglybt.ui.swt.mainwindow.SWTThread.<init>(SWTThread.java:526)
	at com.biglybt.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:58)
	at com.biglybt.ui.swt.Initializer.<init>(Initializer.java:183)
	at com.biglybt.ui.swt.UI.takeMainThread(UI.java:162)
	at com.biglybt.ui.Main.main(Main.java:247)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.biglybt.launcher.Launcher$1.run(Launcher.java:48)
	at java.base/java.lang.Thread.run(Thread.java:829)

That'd correspond to line 152 in the BiglySoftware/BiglyBT-plugin-azemp file Player/src/com/vuze/mediaplayer/mplayer/MPlayerInstance.java:

		try{
			
			fileOpened = fileOrUrl;
			
			List<String> cmdList = new ArrayList<String>();
			
/* Line 152 → */	cmdList.add( BINARY_PATH.getAbsolutePath());
			
			cmdList.add("-slave");
			
			//cmdList.add("-quiet");
			
			cmdList.add("-identify");
			
			cmdList.add("-prefer-ipv4");
			
			cmdList.add("-osdlevel");
			cmdList.add("0");

I don't know what BINARY_PATH is supposed to be initialized to, but if it's trying to find a media player binary (mplayer?), from inside a flatpak it's for sure not gonna have any luck. (Clearly, since BINARY_PATH was apparently initialized to Null.)

...Whether this might've worked in the browser instead, if I'd tried to use the local sharing URL in Chrome rather than running the embedded media player, I have so far not tested.

[ferdnyc]

...Whether this might've worked in the browser instead, if I'd tried to use the local sharing URL in Chrome rather than running the embedded media player

(Or, for that matter, if I'd run /usr/bin/vlc and explicitly told it to open the local sharing URL provided by BiglyBT.)

[o0nd7ots]

Should this thread be open? @TuxPaper

[o0nd7ots]

@parg can we close this thread?

[parg]

Closing as nothing's going to happen here, re-open if so desired.