Frostwire doesn't run under Fedora Workstation and/or Silverblue 35 (or newer)

[EuriNaiz]

Recently I've opened an issue to build an universal Flatpak version, and I tried to build a wrapper like JDownloader does (with the tarball) and I have noticed that Frostwire doesn't even run under Fedora, sincerely idk why is this happening but it seems to be a dependency (library) missed, but I'm not sure...

Mainly I tried to run in my host (Fedora Workstation 35 x86_64) and I didn't be able to run it, next I tried into a Fedora Silverblue 36 x86_64 virtual machine and, again, it doesn't run, and to finish, I created a new and clean Fedora Workstation 35 x86_64 virtual machine and I've got the same error...

Before it was running fine under Debian 10 x86_64, Debian 11 x86_64 and Ubuntu 20.04 Focal Fossa, so I decided to create a new Ubuntu container with Distrobox using my Fedora Workstation 35 host (image pulled from Docker.io), and... It runs fine...
I know that running under a Ubuntu container can be an option for me, but, being realistic, it isn't for all.

Here you can see the errors trying to run on a Fedora Clean Install:

And here you can see FrostWire running in a Ubuntu container inside Fedora 35:

I don't want to be heavy but, this problems can be avoided with a flatpak package, because all apps have their own runtime that is something like a microdistro where your app runs inside and it includes all dependencies in it... I hope you can fix this problem with the RPM package, or ideally and better... building a flatpak package.

• Thank you.

[gubatron]

Will try to answer in multiple comments.

Recently I've opened an #984 (comment),

Saw the ticket, took a look at Flatpak, didn't really see any benefit compared to APK for Debians, RPM for RedHats and the self contained .tar.gz which should run everywhere.

If you're up to create and maintain a Flatpak through a github action that builds it on every commit, that'd be awesome. I can't commit to such task.

[gubatron]

Can you please try using the rpm command instead?

sudo rpm -i frostwire-6.9.8.amd64.rpm

see if you get similar errors or if it runs fine?

We create the .rpm by using alien on the .deb

[gubatron]

can you do a uname -a on that image?

The error seems to be due to binary compatibility, is it an amd64 image?

[gubatron]

I know that running under a Ubuntu container can be an option for me, but, being realistic, it isn't for all.

I agree, this is why we have an .rpm and .tar.gz

[gubatron]

hmm, este screenshot muestra que la imagen es 64-bit, que extraño

[gubatron]

maybe it's something in the .rpm "manifest" not being very explicit about the architecture when alien creates the .rpm out of the .deb

[gubatron]

And here you can see FrostWire running in a Ubuntu container inside Fedora 35

that's so cool, Linux-ception

I don't want to be heavy but, this problems can be avoided with a flatpak package, because all apps have their own runtime that is something like a microdistro where your app runs inside and it includes all dependencies in it... I hope you can fix this problem with the RPM package, or ideally and better... building a flatpak package.

Help us!!! That's the open source way.
Become the flatpak maintainer!

This reminds me I should probably Open Source the Linux Build script.

[gubatron]

In the meantime I'll try to get a hold of a Fedora distro, I'll be slow, I'm working on a big change for the Android version atm.

[gubatron]

HMMMM!

There's a typo in the name of the libtorrent library, therefore it cannot find it, the right library name is libjlibtorrent.so

That's gotta be the problem.

[gubatron]

Rubber Duck Debug Exercise

Let's grep for libjli.so in a folder where I have all the linux installers...

BAM, the rpm wants a `libjli.so` file

Let's look inside the RPM

Perhaps it has nothing to do with libjlibtorrent.so, perhaps there should be a libjli.so, let's google for libjli...

Hmmm, wonder why the RPM thinks it needs that.

Let's check the dependencies defined by our debian control file (manifest)

Source: frostwire
Section: net
Priority: optional
Maintainer: FrostWire Team <contact@frostwire.com>
Uploaders: Angel Leon <gubatron@gmail.com>
Build-Depends: ant, gradle, zlib1g, javahelper
Standards-Version: 3.9.0

Package: frostwire
Architecture: amd64
Depends: zlib1g, mplayer, net-tools, ${shlibs:Depends}
Homepage: https://www.frostwire.com
Description: Open source file downloader and BitTorrent client
 Its BitTorrent core is based on frostwire-jlibtorrent, a java
 API wrapper around libtorrent.

Only the Build depends needs that javahelper.

To Try: remove javahelper from Build-Depends and see if build goes through, check resulting .rpm to see if libjli.so no longer appears.

We include a custom JRE with the build, and nowhere in it there's a libjli.so, but somehow the RPM thinks it needs that library, which seems to be an old Java library, no longer present in modern JREs.

[gubatron]

getting back to this for our next build. Will try be removing the javahelper build dependency.

[gubatron]

Dear @EuriNaiz
Please give this frostwire-6.9.9.amd64.rpm a go on your Fedora and let me know if it finally runs

[gubatron]

bump

[EuriNaiz]

Hi, I am again, sorry for the long delay, but, actually I am using silverblue and I cannot, instead I tried inside a toolbx container and it doesn't work. Libjli is still apparently the problem.

Actually, the best option is IMO, a flatpak package that could be build automatically in top of the freedesktop runtime.

[EuriNaiz]

bump

I really apologize about the long delay, but, sincerely sometimes I am too busy and I didn't check GitHub... You know, university times, it absorb your time.

[gubatron]

hmm, looks like you have a non x86_64 cpu

[EuriNaiz]

That's weird, because it happens on my laptop and my workstation (both Fedora and x86), I remember when I used debian and FW worked fine, I think the problem is the rpm build.

[EuriNaiz]

hmm, looks like you have a non x86_64 cpu

I just tried with the tar package again, now it is working fine on Fedora Silverblue 38, so, yes, the rpm package is broken... Also, talking with some people, they told me it is possible to configure a CI to build flatpak packages from source instead making a wrapping from the rpm as I said before...

In theory, just with some config and a pull request to flathub you could release an universal package.
Personally, a flatpak package worths more than fixing the rpm package, specially now when fedora and redhat are moving away from the rpms to start shipping the non-system apps as flatpaks.