Package Details: waterfox-kde 56.0.3-1

Git Clone URL: (read-only)
Package Base: waterfox-kde
Description: Free, open and private browser with openSUSE's patches for better integration with KDE
Upstream URL:
Keywords: firefox kwaterfox plasma waterfox
Licenses: MPL
Conflicts: waterfox
Provides: waterfox=56.0.3
Submitter: hawkeye116477
Maintainer: hawkeye116477
Last Packager: hawkeye116477
Votes: 5
Popularity: 1.337119
First Submitted: 2017-07-15 21:09
Last Updated: 2018-01-13 15:12

Dependencies (38)

Required by (0)

Sources (18)

Latest Comments

Abogical commented on 2017-10-18 15:14

disable_e10s.patch missing a closing bracket?

line 10:
+pref("browser.tabs.remote.autostart.2", false;

hawkeye116477 commented on 2017-10-10 18:39

@meatatt Ok, sorry for this, fixed.

meatatt commented on 2017-10-10 13:46

'-$_patchrev' postfix should be added to sed commands in 'Fix openSUSE's patches for Waterfox' in order to build it.

p.s. better stay as contributor for little time with package maintaining.

meatatt commented on 2017-09-28 15:19

@hawkeye116477 It works now, thanks XD

hawkeye116477 commented on 2017-09-27 11:50

@meatatt Also it can be issue with new python ( Try new version. I added new patches, maybe these patches will help.

meatatt commented on 2017-09-27 00:21

@hawkeye116477 Tried freetype2 v2.8.1, v2.8, v2.7.1, but still no luck. I was initially using freetype2 v2.8 with infinality patch. Any idea?

hawkeye116477 commented on 2017-09-26 15:04

@meatatt I have Manjaro Linux Stable and all is fine. As @philmanjaro said it's issue with freetype2 v2.8.1. So the only solution for now is downgrading freetype2 to v.2.8 or just install waterfox-kde-bin.

meatatt commented on 2017-09-26 01:04

There is definitely some kind of memory leak in compiling. It eats up all 16G of ram space and got it self killed. Compiling with lastest version of everything and the default arch kernel.

hawkeye116477 commented on 2017-09-11 19:57

@meatatt Ok, you're right. Changed source to git, added patch for jack and other improvements :)

meatatt commented on 2017-08-23 18:29

@hawkeye116477 You may be mistaken. I choose to clone also because of the slow download speed. The bare repo is huge and it takes much more time to clone, but ONLY AT THE FIRST TIME. Unlike tarballs which need a full download every update, old repos can be updated to a new commit instantly & automatically. So just keep the cloned repo elsewhere and drop a symbol link to it in the build dir before running makepkg. Additionally, repos have builtin checksum support, which is safer than a tarball with 'SKIP'.

All comments