Ubuntu 14.04 (or Flatpak) builds?

[RJVB]

trafficstars

Is your feature request related to a problem? Please describe. Somehow I've been lucky (apparently) that Waterfox still ran on my Trusty old Ubuntu 14.04-based OS. Sadly, that luck ran out with G3 3.2.6, which requires a newer glibc (2.28 according to the download page, but possibly 2.30 because of the versioning symbols mentioned).

Describe the solution you'd like I would of course like the official builds to support older OS versions too but don't really want to ask that (but FWIW, Firefox Dev. Edition still runs for me). I tried to build a newer glibc myself, installed in its own subprefix, but get a SIGSEGV at launch when I try to start most applications against that library. I do notice that Flatpak installs do use their own libc so maybe it would be possible to provide an official build via flathub? Or maybe the same is possible with an AppImage? Or maybe someone actually managed to set up a Ubuntu 14.04 PPA?

Describe alternatives you've considered Building Waterfox myself is an alternative I'd like to try but I'm pretty certain I can't on my hardware ... I'm considering going back to plain Firefox if I don't find another solution and start getting too much behind. Updating my OS isn't an option for now, if not only because I'm not ready to give up the good old KDE Plasma4 desktop.

[hawkeye116477]

See https://github.com/hawkeye116477/waterfox-deb-rpm-arch-AppImage#downloading-and-installing-appimage-packages. It works with CentOS 7, maybe it will work also with Trusty.

Official container packages are very unlikely rather. In case of Flatpak, as I see it requires bundling a lot of things and that could be problematic from licensing side. I don't know how Mozilla did that, but maybe they have permission from someone to do that.

PS: My AppImage G3 package is statically linked with libstdc++, but it requires glibc 2.17+ and I'm not bundling depends. It's also more optimized than official one, cuz it's built with LTO+PGO.

[RJVB]

Thanks!

[pm-pm]

Hey Guys :-(

AFTER AUTOMATIC waterfox update 3.2.5 -> 3.2.6 GLIC 2.30 is reqired.

Suddenly nothing worked and it took me hours to figure it out. No clue, no information. (I open the tools via a gui.) My profiles, my work, my last websites cannot be found due to this mess. Really not nice. I use Debian Buster 10

Of course it is possible to change the GLIBC, but this should be announced BEFORE AN UPDATE.

Edit: Please advice hot to go back correctly and to find all the pages, bookmarks and recently open webpages. Thx.

[hawkeye116477]

Please advice hot to go back correctly and to find all the pages, bookmarks and recently open webpages

That data is saved on seperate folder in so called profile. So just install older version again or one of packages created by me and that shouldn't be problem.

Maybe #2266 could help a little with that situation when MrAlex will trigger manually building that Docker image or will merge before 1 Oct.

[pm-pm]

Thanks for your answer. Installing an older version is tricky!

What is the first thing an old version does? It automatically updates to a new version! ;-) So you have to disable auto-update and reinstall a second time the old version. In the hope that it will not be automatically updated again.

BTW: Docker is not a solution on a thin Debian System.

[RJVB]

So you have to disable auto-update and reinstall a second time the old version. In the hope that it will not be automatically updated again.

With Firefox clones you have to create a file called policies.json inside a directory called distribution in the same directory where the browser executable lives. For instance with the Firefox Developer Edition but also the official Waterfox build, I have

> cat /opt/waterfox/distribution/policies.json
{
    "policies": {
        "DisableAppUpdate": true
    }
}

I'm not certain where that file would need to go if you use a build that installs into /usr (like @hawkeye116477's builds do, I think) ... but maybe his builds are configured to look for his own updates (or else they c/should have the policies.json file present or auto-updating disabled otherwise!).

[hawkeye116477]

but maybe his builds are configured to look for his own updates

Packages from seperate repositories for each distro have updater disabled at build time.

In case of AppImage packages, updater is enabled, but it's pointed to my own xml file, which points to AppImage file and automatic update isn't even possible (updater doesn't know how to handle AppImages).

BTW: Docker is not a solution on a thin Debian System.

After approving my changes, package could be build by Waterfox Team on GitHub Actions on CentOS 7 docker image, which has glibc 2.17, so it should fix that problems with incompatibility with distros that old like CentOS 7.

[ilu33]

This should have the bug label. It would be nice if this recurring built system issue could be avoided.

[ilu33]

Any news on this @MrAlex94 ? Changing the build system to a newer glibc has absolutely no technical advantage, it just annoys loyal users.

[MrAlex94]

Not yet - need to fix the issues people are facing first. Unfortunately the glibc change wasn't on purpose - we just needed to build on a newer distro and that unfortunately pulls in a higher version of glibc than we'd like.

[RJVB]

Not yet - need to fix the issues people are facing first.

So ... either those of us using an older glibc aren't people, or the issue we face isn't one? O:-)

[reesericci]

Flatpak is the way forward for Linux app development. There are entire distros that only use Flatpak - Fedora Silverblue, SteamOS 3, Fedora Kinonite, etc. Waterfox needs to seriously think about packaging itself as a Flatpak for both ease of use and relevance.

[hawkeye116477]

Flatpak is not that good. It weighs a lot, cuz a lot of dependencies needs to be included in it and not sure if wouldn't be license conflicts. On some distros (maybe mostly those older) Flatpak also needs to be installed to install Flatpak package. AppImage is easier, bundling depends not needed, can share depends from distro and nothing needs to be installed, just run and be happy.

[RJVB]

That, and applications are sandboxed by default; installing resources to be used by other applications (including dbus, systemd & family) tricky to say the least.

[reesericci]

It weighs a lot,

It only weighs a lot if you install one app. The more apps you install, they share runtimes, and thus the per-app size is lower.

AppImage is easier, bundling depends not needed, can share depends from distro and nothing needs to be installed, just run and be happy.

It doesn't integrate with your system as easily, you still need a separate app, AppImageLauncher. Updates are much more of a chore, and people just aren't using it.

can share depends from distro and nothing needs to be installed,

That's just not true. AppImages bundle all their dependencies into that file. In fact, over time Flatpak will use less storage because Flatpaks can share runtimes, unlike AppImages.

applications are sandboxed by default;

That's a good thing! It keeps your system safe from malicious apps and viruses, while providing an easier user experience as everything just works as intended. No faffing around trying to get all the apps on your system to play nice, portals do that for you.

[RJVB]

It only weighs a lot if you install one app. The more apps you install, they share runtimes, and thus the per-app size is lower.

That isn't necessarily true, as runtimes are versioned. I've also already seen a rather simple Qt-based application pull in the entire KDE runtime...

applications are sandboxed by default;

That's a good thing! It keeps your system safe from malicious apps and viruses

Viruses are irrelevant here, and for the rest this is a good thing only if you're installing the odd application that's not part of your distro. A flatpak-based distro would NOT want its programs to be sandboxed from each other, IMHO. You could provide the entire distro as a runtime, but that's just putting a traditional distro inside a sandbox (from what?) ... minus the possibility to install only the bits and pieces you need and remove those you don't want.

And I don't even want to imagine the runtime overhead if components of a traditional Unix pipeline command (sed, grep, awk, tee &c) all have to be started via flatpak. Actually I can ... and if this were a movie I'd call it "Microsoft's Revenge" (because MSWin 10+ will probably feel very snappy in comparison) ;)

[hawkeye116477]

AppImages bundle all their dependencies into that file.

So apparently I must be wizard, cuz made Waterfox AppImage without bundling depends (libnotify and other things just uses from distro) and it works good. However Waterfox made with Flatpak requires adding few additional depends => https://github.com/flathub/org.mozilla.firefox.BaseApp/blob/branch/21.08/org.mozilla.firefox.BaseApp.json.

Flatpaks can share runtime

Problem is that some apps needs more depends than just this runtime.

It doesn't integrate with your system as easily, you still need a separate app, AppImageLauncher. Updates are much more of a chore, and people just aren't using it.

With that I can partially agree, cuz people likes my AppImage packages :smile:. In case of updates, you can bundle special updater with it, but you need to write additional code (not tried by me).

Generally all these container packages have some drawbacks, just good only on paper. I think that standard distro packages are better, running, works faster. Making small installation script is also good thing.