BiglyBT
BiglyBT copied to clipboard
BiglySoftware
app in flatpak
what about having a flatpak option in linux instead of a script installer?so we can use biglybt without messing up with dependencies?considering every distro is adopting flatpak and it will probably be the future of linux it would be a great addiction
by the way, it's good to see you back...used vuze for more than 10 years and left last year because didn't like the direction it was taking, so it's good to see you back with this fork...
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.
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...
considering now java has been released for flatpak, maybe is now time to take a look at this? :)
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
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
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!
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
BiglyBT is now published at Flathub https://flathub.org/apps/details/com.biglybt.BiglyBT 🎊
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>
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?
There's config settings under Options->Interface->Start
e.g. Check for latest version when BiglyBT starts
@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
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
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
Thank you very much, an update using custom presets directory is now published on Flathub
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).
Very happy to have Bigly on Flathub!
Two questions/issues with the flatpak (also posted here https://github.com/flathub/com.biglybt.BiglyBT/issues/7)
- How do I allow it to download in different locations without giving the flatpak full access to the home directory using Flatseal.
- 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
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
- Play Now Feature This may require input from Bigly Maintainers, see this comment.
@S7venLights ~/.biglybt is already granted by default. It's already part of the flatpak manifest.
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.
If anyone is around can they please take a look at
https://www.reddit.com/r/BiglyBT/comments/10ak05k/error_data_missing_runflatpakdoc/
thanks!
Can anyone help with the Play Now Feature This may require input from Bigly Maintainers, see this comment: https://github.com/flathub/com.biglybt.BiglyBT/issues/7
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.
@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.
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
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
@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:
- The built-in webserver on port
5xxxxwas accessible and serving content - 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.