LibreWolf

[SwampRabbit]

Its build-depends should be similar to that of Firefox 84 upstream, which involves newer versions of cargo and rustc, AFAIK.

Since they offer binary builds, we could duplicate what we do with Firefox and just bundle those into debs.

Yep rustc and cargo are the ones tripping this up right now. There are a few pre-reps for those too. I can dump what I have for the debian folder for you and/or Mike.... ya’ll might be better suited for for this one based on experience with Firefox.. I’ll hit you up in a PM.

[Sterling]

Wow, if there could be a privacy patched Firefox installable straight from the MX Linux repository, that would be really great.

Where you, or those more experienced with compiling Firefox, able to make some progress with Librewolf?

[Sterling]

Some drawbacks of a third- or fourth-(appstore)party flatpack are the delayed security-updates of bundled dependencies, and problems with using the install directory for customizing system wide defaults.

[SwampRabbit]

I personally am not interested in fussing around anymore with trying to build this mess of a package. The developer needs to debianize it.

I haven’t looked to see if Debian upstream got anywhere with their WIP package or not, but will look when I have time.

[andyprough]

I'm running the Debian Sid version of LibreWolf on antiX Sid right now. Works well, but no better than using the appimage version. At this point I don't see any value in not sticking with the appimage on any Buster-based system. The appimage is lightweight and runs great.

If anyone wants to put the appimage in MXPI, I was able to link the appimage with 'ln -s' to /usr/bin to put it in the path, and make a .desktop file for it in /usr/share/applications to get the appimage into the menu. Pretty simple.

[Sterling]

I personally am not interested in fussing around anymore with trying to build this mess of a package. The developer needs to debianize it.

Thanks for your assessment. It's a clear hint, and a mess is a warning sign if it's not addressed.

Did you have the chance to provide some details upstream? https://gitlab.com/librewolf-community/ ... x/-/issues

[andyprough]

I personally am not interested in fussing around anymore with trying to build this mess of a package. The developer needs to debianize it.

Thanks for your assessment. It's a clear hint, and a mess is a warning sign if it's not addressed.

Did you have the chance to provide some details upstream? https://gitlab.com/librewolf-community/ ... x/-/issues

I don't want to answer for @SwampRabbit, but I'll just say I'm pretty sure the LibreWolf devs are well aware that it's not packaging on any Debian but Sid right now. The person who makes the Sid package has been trying and failing to make a package for the current version of Ubuntu for awhile. Raising it as an issue on gitlab isn't going to make the problem resolve any faster. Most likely the problem is related to the advanced versions of rust and cargo that are required to build LibreWolf, and they each require their own advanced version dependencies which are not going to be satisfied on Buster.

[dolphin_oracle]

their pkgbuild files for their arch builds download mozilla source and then apply patches. I'm not even sure that qualifies as a fork. basically if mozilla support disappeared I think this one would too.

[SwampRabbit]

their pkgbuild files for their arch builds download mozilla source and then apply patches. I'm not even sure that qualifies as a fork. basically if mozilla support disappeared I think this one would too.

Correct, the dpkg script does the same thing. They even say to run the script then use something like OBS to build packages.

I don’t know if they want to actually “fork” fork it or not, or even need to for what they are trying to accomplish. But right now everything I see points to what you noticed and that is they are just pulling down the Firefox source package and “bolting on” things or removing some other things.

[dolphin_oracle]

their pkgbuild files for their arch builds download mozilla source and then apply patches. I'm not even sure that qualifies as a fork. basically if mozilla support disappeared I think this one would too.

Correct, the dpkg script does the same thing. They even say to run the script then use something like OBS to build packages.

I don’t know if they want to actually “fork” fork it or not, or even need to for what they are trying to accomplish. But right now everything I see points to what you noticed and that is they are just pulling down the Firefox source package and “bolting on” things or removing some other things.

ok fair point, they actually say its a customized firefox build in their code.

I see some -dev packages added as depends as well (libjack-dev?).