Package Details: waterfox-classic-kpe 2022.04-0

Git Clone URL: (read-only, click to copy)
Package Base: waterfox-classic-kpe
Description: Customizable privacy conscious web browser with better integration with KDE
Upstream URL:
Keywords: firefox kwaterfox plasma waterfox-classic-kde waterfox-kde
Licenses: MPL
Conflicts: waterfox-classic, waterfox-kde
Provides: waterfox-classic
Replaces: waterfox-kde
Submitter: hawkeye116477
Maintainer: hawkeye116477
Last Packager: hawkeye116477
Votes: 9
Popularity: 0.013575
First Submitted: 2019-10-27 10:38 (UTC)
Last Updated: 2022-04-12 18:10 (UTC)

Dependencies (36)

Required by (1)

Sources (11)

Pinned Comments

hawkeye116477 commented on 2019-09-03 16:53 (UTC) (edited on 2021-03-08 11:18 (UTC) by hawkeye116477)

Binary version of this package is available on my repository on OBS and language packs are available as separete waterfox-classic-i18n-* packages.

Source files at:

Server =$arch

If you got 404, then temporarily try to replace with That should enforce direct download without mirror.

key=$(curl -fsSL$(uname -m)/home_hawkeye116477_waterfox_Arch.key)
fingerprint=$(gpg --quiet --with-colons --import-options show-only --import --fingerprint <<< "${key}" | awk -F: '$1 == "fpr" { print $10 }')

pacman-key --init
pacman-key --add - <<< "${key}"
pacman-key --lsign-key "${fingerprint}"

Latest Comments

toxygen commented on 2022-03-08 02:11 (UTC)

if anyone is having the tab crashing problem, this patch fixed it for me (on the currently available version)... it's just one file change after getting the source:

toxygen commented on 2021-12-04 18:00 (UTC)

on new PKGBUILD, all the

"cd Waterfox"

should be

"cd Waterfox-Classic"

nobyte commented on 2021-11-20 19:15 (UTC) (edited on 2021-11-20 19:17 (UTC) by nobyte)

Does anyone else have problems with building after updates of rust, llvm, libffi and other packages?

rust had been updated (1:1.55.0-1 -> 1:1.56.1-3)

waterfox build of 2021.10 returns errors that appear to have to do with rust:

... 33:16.41 Compiling rust_url_capi v0.0.1 (/var/tmp/pamac-build-user/waterfox-classic-kpe/src/Waterfox/netwerk/base/rust-url-capi)

33:18.67 error[E0557]: feature has been removed

33:18.67 --> /var/tmp/pamac-build-user/waterfox-classic-kpe/src/Waterfox/third_party/rust/packed_simd/src/

33:18.67 |

33:18.67 202 | #![cfg_attr(use_const_generics, feature(const_generics))]

33:18.67 | ^^^^^^^^^^^^^^ feature has been removed

33:18.67 |

33:18.67 = note: removed in favor of #![feature(adt_const_params] and #![feature(generic_const_exprs)]

33:18.67 ...

I'm trying to do a fresh build of 2021.10 because after updates waterfox-classic doesn't start anymore .. doesn't find a library: cannot open shared object file

libffi and associated packages had been updated as well: libffi (3.3-4 -> 3.4.2-4)

I tried to downgrade llvm, llvm-libs and so on, but I don't want to downgrade libffi as the new thunderbird version depends on that.

Any ideas?

nobyte commented on 2021-10-27 09:51 (UTC)

@ranger .. ok thanks. I'll have a look at the pamac gitlab. Sorry for spamming with off topic stuff.

ranger commented on 2021-10-26 20:38 (UTC)


your problem is not with waterfox, is that you are using pamac The standard method (makepkg) wont delete the folder, if you want you can try. Or maybe there is an option in pamac to do that, I'm not using it

nobyte commented on 2021-10-26 19:26 (UTC)

@toxygen .. I might be having a noob problem here.

Keeping the "Waterfox" folder from previous build is what I would want. But the build process (started from pamac gui) appears to always clean up the build dir before starting to update the source dir from the repo (which leads to the whole source being downloaded again).

So in order to keep the previous source I always move the "Waterfox" dir out of the build dir before telling pamac gui to build the package (as I wrote already) and only move it back to the build dir after the cleanup .. which is after I've saved PKGBUILD changes from the gui and before I click on build.

I'm not sure if this is intended behaviour on behalf of pamac. I already asked on the Manjaro forums.

Maybe I should just build from terminal.

I just thought there ought to be an easier way, this can't be the way it's supposed to work.

Thanks anyway.

toxygen commented on 2021-10-26 16:38 (UTC)

@nobyte dont you just need to keep the "Waterfox" folder that's initially created? my process is usually download the new version aur files to a build folder, then cp over the "Waterfox" folder from the previous build in ./waterfox-classic-kpe/Waterfox, make any additional PKGBUILD changes, and makepkg from there.
the git takes a lot less than doing it from scratch for me with this process. i'm sure there's better ways tho lol

nobyte commented on 2021-10-22 10:40 (UTC)

In the beginning of the build process the source (from previous build) is always cleaned/deleted on my system (Manjaro).

This makes the monthly build take much longer, as the git index-pack step alone takes almost an hour. Also the full 5 GB of source files are always downloaded again, which is a waste of traffic. Additionally it causes lots of disk IO which is annoying on a system with HDD instead of SSD.

Is there a way to prevent the source from the previous build being deleted?

As a workaround I moved the source dir from the build dir after a completed build to somewhere else and "injected" it back to the build dir right after I saved the PKGBUILD (after customizing it for build). But this is always a hassle.

toxygen commented on 2021-04-27 14:49 (UTC)

thanks hawkeye, that fix worked

hawkeye116477 commented on 2021-04-27 11:57 (UTC)

@toxygen Oops, sorry, apparently MrAlex now didn't added classic to tag.

toxygen commented on 2021-04-27 03:23 (UTC)

here's the error, which happened again on a clean build:

fatal: invalid reference: 2021.04.2-classic ==> ERROR: Failure while creating working copy of Waterfox git repo

toxygen commented on 2021-04-27 02:36 (UTC)

I tried building 2021.04.2 and it built.. waterfox (not -classic) originally had an error about not finding tag 2021.04.2-classic, re-running makepkg re-downloaded from git, and it turned into regular waterfox

trying again now, we'll see how it goes

toxygen commented on 2020-12-02 02:16 (UTC) (edited on 2020-12-02 02:17 (UTC) by toxygen)

@hawkeye116477 I was going based on this commit

but i see what you mean, gotta wait a few more days i guess!

hawkeye116477 commented on 2020-11-30 10:11 (UTC) (edited on 2020-11-30 10:12 (UTC) by hawkeye116477)

@toxygen 2020.11 isn't released, it's not tagged yet on GitHub and no binary on official website.

toxygen commented on 2020-08-19 00:48 (UTC) (edited on 2020-08-19 00:52 (UTC) by toxygen)

package cannot be compiled without removing "ac_add_options --with-system-png" line. Same problem exists also in new firefox By removing this line from PKGBUILD, application gets compiled successfully after about two hours and supports properly the APNG (animated PNG) images.

how odd, I was using arch's libpng which apparently until a couple months ago (june 25th) was patching with apng support and waterfox was still building for me as of a week or two ago

and it was removed due to some (seemingly) random issue

the patch still exists

and going by the 1.6.37-2 version of libpng PKGBUILD should still work (it does for me on 1.6.37-3) by adding a few lines (you can probably diff the two PKGBUILDs, basically a source line, a sha256 line, and the gunzip/patch line). I guess I had added the patch line when 1.6.37-3 came out and forgot about it ;^)

that's neither here nor there, since arch has decided (albeit without much discussion) to just do without the apng patch and let each package that requires apng support to use a bundled version, as firefox/chrome and now waterfox are going to do.

ah well. it's not a big deal other than the extra compilation time, I suppose. but the info is there, if anyone wants to go the old way.

gerstavros commented on 2020-08-16 12:53 (UTC)

package cannot be compiled without removing "ac_add_options --with-system-png" line. Same problem exists also in new firefox By removing this line from PKGBUILD, application gets compiled successfully after about two hours and supports properly the APNG (animated PNG) images.

hawkeye116477 commented on 2020-04-13 15:23 (UTC)


toxygen commented on 2020-04-12 19:54 (UTC) (edited on 2020-04-12 19:54 (UTC) by toxygen)

line 68 on PKGBUILD

patch -Np1 -i ../classic-kde-xul-2020.03.patch

should be

patch -Np1 -i ../classic-kde-xul-2020.04.patch

toxygen commented on 2020-02-22 18:32 (UTC)

@hawkeye116477 hey that worked great, and thanks for removing that --with-system-libvpx, no errors were thrown without it.

hawkeye116477 commented on 2020-02-22 16:02 (UTC)

@toxygen In case of Clang issue, seems that disabling elf hack helps.

toxygen commented on 2020-02-19 00:21 (UTC)

looks like the patch worked, so I was able to build. Without getting into a discussion about google/safe-browsing, i'll just say I prefer it off and appreciate your work on this package.

Sadly, even though the patch worked, the clang issue is still present for me, but it's an easy downgrade (until i forget to not clean up the clang/llvm files from pacman cache) so looks like it's building fine.

on a related note, are you having issues with libvpx 1.8.x? i have to manually set --without-system-libvpx for waterfox to build, otherwise i get a vpx error as per and

i'm on libvpx 1.8.2 and it still gives the error, so I'm guessing the issue is in waterfox/firefox, not libvpx, but I'm wondering how you got it to build.

hawkeye116477 commented on 2020-02-18 13:14 (UTC) (edited on 2020-02-18 20:33 (UTC) by hawkeye116477)

@toxygen I'm not sure if disabling Safe Browsing is good option. It may reduce security. See also

In case of that error, check if fix from helps.

You can always also branch and change it to like you want.

toxygen commented on 2020-02-17 15:34 (UTC)

so it looks like building with latest llvm/clang is ok now, but now i'm getting some weird graphics lib error that I cant hunt down anywhere:

src/Waterfox/obj-x86_64-pc-linux-gnu/dist/include/mozilla/dom/ImageBitmap.h:203:15: error: unknown type name 'gfxAlphaType' 5:17.30 gfxAlphaType aAlphaType = gfxAlphaType::Premult);

so @hawkeye116477, could you be so kind to build your binary version of waterfox-kpe-classic with additional flags:

--disable-safe-browsing --disable-synth-speechd

(only the first one is important to me, but the latter would be nice as well). Reason for this is to avoid browser from calling google on every request, as it does even when you disable in the options->security page ("Block dangerous and deceptive content). Meanwhile I'll keep hunting down that error, looks like a missing library or maybe and incompatible version.

hawkeye116477 commented on 2019-11-24 22:06 (UTC) (edited on 2019-11-24 22:07 (UTC) by hawkeye116477)

@toxygen Oops, sorry, looks like I hurried up a little, anyway on line 231 was correct, name on source field was bad.

toxygen commented on 2019-11-14 02:47 (UTC) (edited on 2019-11-14 02:55 (UTC) by toxygen)

two items:

PKGBUILD line 231 should be : install -Dm644 $srcdir/waterfox-classic-kpe.1 \ "$pkgdir/usr/share/man/man1/waterfox-classic-kpe.1"

(fails because cannot stat waterfox-classic.1)

second, please warn that you renamed /usr/bin/waterfox to waterfox-classic. not a biggie but it was weird :-)

also, still cant build on rust 1.1.39 and clang/llvm 9.0.0 versions that work for me are clang 8.0.1-1 llvm 8.0.1-3 llvm-libs 8.0.1-3 compiler-rt 8.0.1-1 rust 1:1.38.0-1.1

newer versions through errors while compiling

hawkeye116477 commented on 2019-10-29 08:46 (UTC)

@toxygen KPE means KDE Plasma Edition :-)

toxygen commented on 2019-10-28 23:16 (UTC)

shouldnt that be waterfox-classic-kde ?

hawkeye116477 commented on 2019-10-27 09:28 (UTC)

This is Classic. I'll rename it and also push waterfox-current-kpe.

ranger commented on 2019-10-27 09:11 (UTC) (edited on 2019-10-27 09:14 (UTC) by ranger)

@toxygen There is no waterfox beta upstream any more.

Names and versioning changed since this month. There are now two different "stable" versions(Waterfox classic and waterfox current), based on different Firefox versions (legacy and modern). And versioning changed for both to YY.MM.X

So if this is the legacy version it should be named waterfox-classic, as is not possible to distinguish classic from current based on version number.

toxygen commented on 2019-10-26 23:42 (UTC)

@ranger - there is a waterfox-kde-beta which i believe is "current" so this would be classic dont know why the version changed to 2019-10 rather than the 5x.xx we had before

ranger commented on 2019-10-25 18:41 (UTC)

Is this Waterfox Classic or Current? Could help if you include in the name or description

toxygen commented on 2019-10-21 23:26 (UTC) (edited on 2019-10-21 23:28 (UTC) by toxygen)


rm src/path, or rm the whole src before makepkg

are you using the -e option?

Star-X commented on 2019-10-21 19:15 (UTC)

Can't build currently, as the pkgbuild tries to do mkdir path and fails because path already exists.

Any fix?

toxygen commented on 2019-10-16 23:33 (UTC) (edited on 2019-10-16 23:41 (UTC) by toxygen)

well it goes through the [compile] portion fine, it gets to the [misc] portion, it buils some tests apparently, and gets to

waterfox-kde/src/Waterfox/build/unix/elfhack/test-ctors.c and fails:

9:40.49 Stack dump: 9:40.49 1. <eof> parser at end of file 9:40.49 2. Code generation 9:40.49 3. Running pass 'Function Pass Manager' on module 'waterfox-kde/src/Waterfox/build/unix/elfhack/test-ctors.c'. 9:40.49 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@test' 9:40.52 Stack dump: 9:40.52 1. <eof> parser at end of file 9:40.53 2. Code generation 9:40.53 3. Running pass 'Function Pass Manager' on module '/home/trumpop/waterfox-kde/src/Waterfox/build/unix/elfhack/test-array.c'. 9:40.53 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@test' 9:40.55 #0 0x00007f47d08b2b7b llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/ 9:40.55 #1 0x00007f47d08b0a44 llvm::sys::RunSignalHandlers() (/usr/bin/../lib/ 9:40.55 #2 0x00007f47d08b0bd6 (/usr/bin/../lib/

with a bunch of other messages followed by

9:40.55 #20 0x00007f47cf4d21d8 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/usr/bin/../lib/ 9:40.55 clang-9: error: unable to execute command: Segmentation fault 9:40.55 clang-9: error: clang frontend command failed due to signal (use -v to see invocation) 9:40.55 clang version 9.0.0 (tags/RELEASE_900/final) 9:40.55 Target: x86_64-pc-linux-gnu 9:40.55 Thread model: posix 9:40.55 InstalledDir: /usr/bin 9:40.55 clang-9: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.

9:40.58 clang-9: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script. 9:40.60 clang-9: note: diagnostic msg: 9:40.60 **** 9:40.60 9:40.60 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 9:40.60 Preprocessed source(s) and associated run script(s) are located at: 9:40.60 clang-9: note: diagnostic msg: /tmp/test-ctors-c12089.c 9:40.60 clang-9: note: diagnostic msg: /tmp/ 9:40.60 clang-9: note: diagnostic msg: 9:40.60 9:40.60 *** 9:40.60 make[5]: [waterfox-kde/src/Waterfox/config/ test-ctors.o] Error 254 9:40.60 make[5]: Waiting for unfinished jobs.... 9:40.63 clang-9: note: diagnostic msg: 9:40.63 ***** 9:40.63 9:40.63 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 9:40.63 Preprocessed source(s) and associated run script(s) are located at: 9:40.63 clang-9: note: diagnostic msg: /tmp/test-array-bfb319.c 9:40.63 clang-9: note: diagnostic msg: /tmp/ 9:40.63 clang-9: note: diagnostic msg:

that's all. I wondered if some march or mtune settings are causing this? I have a ryzen 3700x (zen2) so maybe the cpu is conflicting there? i believe clang/llvm 9 have native support for ryzen (march=zenver2) so i switched those, and it fails at the exact same point. both test-ctors.c and the following file waterfox-kde/src/Waterfox/build/unix/elfhack/test-array.c fail with the same errors, both in the same folder waterfox-kde/src/Waterfox/obj-x86_64-pc-linux-gnu/build/unix/elfhack

and like i said, downgrading clang/llvm to previous versions, it builds just fine

hawkeye116477 commented on 2019-10-16 19:12 (UTC)

@toxygen Hmm, on OBS was fine. What error message displayed?

toxygen commented on 2019-10-16 02:06 (UTC)

man, i dont know what's up with either my system or with the new rust/llvm/clang, i couldnt build the new version with the latest versions of those, had to downgrade to clang/llvm 8.0.1 and the previous version of rust, and it built successfully

with the latest versions, the build itself went fine, but the "misc" portion failed for me with some llvm error followed by a compiler error.

so far working ok with using the previous versions to build it though

hawkeye116477 commented on 2019-10-05 08:59 (UTC)

@toxygen Cssparser needs updating, but seems that's not that easy, cuz it's required by servo, which also needs some fixes to use new version of cssparser. That's rather not worth to make that fixes, cuz Servo/Stylo can't work good for now, so you can just disable stylo and that will fix that error also :-)

toxygen commented on 2019-10-04 03:03 (UTC) (edited on 2019-10-04 03:16 (UTC) by toxygen)

cant build because of changes in rust 1.38 and a cssparser error: (file: src/Waterfox/third_party/rust/cssparser/src/ 3:20.30 error[E0506]: cannot assign to self.input.cached_token because it is borrowed 3:20.43 error: Could not compile cssparser.

per "Rust was updated to 1.38 in OpenBSD, and as a side effect thunderbird 68 & firefox-esr 68 now fail to build, choking on cssparser - see for the original report/bugfix."

this seems to affect arch/artix waterfox-kde as well, at least the error and location are the same i attempted some patching but got nowhere (as per comment "backporting on top of third-party/rust/cssparser/src/ was enough to fix the build with rust 1.38" on that bugzilla) but i got nowhere

also looks like downgrading rust to 1.37-2 allows build to complete, with a warning instead of a build error at the same file/location (src/Waterfox/third_party/rust/cssparser/src/

hawkeye116477 commented on 2019-09-03 16:53 (UTC) (edited on 2021-03-08 11:18 (UTC) by hawkeye116477)

Binary version of this package is available on my repository on OBS and language packs are available as separete waterfox-classic-i18n-* packages.

Source files at:

Server =$arch

If you got 404, then temporarily try to replace with That should enforce direct download without mirror.

key=$(curl -fsSL$(uname -m)/home_hawkeye116477_waterfox_Arch.key)
fingerprint=$(gpg --quiet --with-colons --import-options show-only --import --fingerprint <<< "${key}" | awk -F: '$1 == "fpr" { print $10 }')

pacman-key --init
pacman-key --add - <<< "${key}"
pacman-key --lsign-key "${fingerprint}"

hawkeye116477 commented on 2019-06-24 09:47 (UTC) (edited on 2019-06-24 09:48 (UTC) by hawkeye116477)

Rust-simd should work again now, thanks to my patch based on <> and <> :-)

SolarAquarion commented on 2019-06-11 10:19 (UTC) (edited on 2019-06-11 10:24 (UTC) by SolarAquarion)

you need to add "git" to makedepends, also 'libevent'

Star-X commented on 2019-06-09 00:06 (UTC) (edited on 2019-06-09 00:17 (UTC) by Star-X)

It worked on my tablet, but my desktop PC is failing to verify waterfox.1.

By chance did you change it recently, or is it a screwup on my end somehow?

EDIT: Nvm, fixed it by skipping waterfox.1's SHA256 verification in the pkgbuild manually using Pacaur's --edit flag. I mean, it's a manual, in plaintext, I can't imagine that ever being a risk.

hawkeye116477 commented on 2019-06-08 07:20 (UTC)

@Star-X Sorry, fixed

Star-X commented on 2019-06-07 21:29 (UTC) (edited on 2019-06-07 21:29 (UTC) by Star-X)

Getting the following error when I try to update Waterfox:

=> ERROR: Integrity checks (sha256) differ in size from the source array.

Any chance you could fix this?

hawkeye116477 commented on 2019-04-19 14:14 (UTC) (edited on 2019-04-19 14:15 (UTC) by hawkeye116477)

I disabled rust-simd and stylo for now, cuz this cause problems with rust>1.32.

hawkeye116477 commented on 2018-12-24 13:30 (UTC) (edited on 2018-12-24 13:32 (UTC) by hawkeye116477)

@jaxad0127 I checked and sums are fine, so something is probably not right on your side, just try again :)

jaxad0127 commented on 2018-12-21 17:49 (UTC)

waterfox.desktop and waterfox.1 fail validity check using 56.2.6-1.

hawkeye116477 commented on 2018-11-02 18:38 (UTC)

@jaxad0127 Sorry, forgot to update, but fixed now.

jaxad0127 commented on 2018-11-02 17:20 (UTC)

The waterfox.1 file doesn't pass validity check for me using the 56.2.5-1 pkgbuild.

toxygen commented on 2018-07-27 11:20 (UTC)

@hawkeye that doesnt get passed to clang (-j is not a valid option for clang) and yes, i have that already

hawkeye116477 commented on 2018-07-27 09:59 (UTC)

@toxygen You can change mk_add_options MOZ_MAKE_FLAGS from -j6 to -j1.

toxygen commented on 2018-07-26 03:36 (UTC) (edited on 2018-07-26 03:37 (UTC) by toxygen)

I have an older cpu (xeon 5470), and with clang the build process sometimes fails (due to high cpu usage/temp). this happens in firefox too. before clang became standard for firefox i could add a "-j1" option to the PKGBUILD either for c/c++ options or a mozconfig option to prevent multi-process compilation and that helped prevent this issue (even though the build process took 3-4x as long).

is there a similar option on clang?

hawkeye116477 commented on 2018-04-04 19:56 (UTC) (edited on 2018-04-04 19:57 (UTC) by hawkeye116477)

@meatatt Ok, fixed typo. And what about build error, just try Rust 1.17 or maybe this will help =>, but I not tested it yet.

meatatt commented on 2018-04-04 13:47 (UTC) (edited on 2018-04-04 13:49 (UTC) by meatatt)

  1. Typo at line 189: "..unity-menubar-$pkgver.patch", missed a slash.
  2. Build error: error: failed to run custom build command for style v0.0.1 (file://waterfox-kde/src/Waterfox/servo/components/style) process didn't exit successfully: waterfox-kde/src/Waterfox/obj-x86_64-pc-linux-gnu/toolkit/library/release/build/style-73d427baf1708f04/build-script-build (exit code: 101)

hawkeye116477 commented on 2018-03-28 16:50 (UTC)

@alium I initially used tarball, but I get convinced by @meatatt that git is better, because on first time is slower to download, but next time is faster, cuz you have previous state of repo and you only need to download what is new. With tarballs you need to redownload full source every time when is update.

alium commented on 2018-03-28 10:33 (UTC)

can you please use source file instead git?$pkgver.tar.gz

Abogical commented on 2017-10-18 15:14 (UTC) (edited on 2017-10-18 15:15 (UTC) by Abogical)

disable_e10s.patch missing a closing bracket? line 10: +pref("browser.tabs.remote.autostart.2", false;

hawkeye116477 commented on 2017-10-10 18:39 (UTC) (edited on 2017-10-10 18:43 (UTC) by hawkeye116477)

@meatatt Ok, sorry for this, fixed.

meatatt commented on 2017-10-10 13:46 (UTC)

'-$_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 (UTC) (edited on 2017-09-28 15:19 (UTC) by meatatt)

@hawkeye116477 It works now, thanks XD

hawkeye116477 commented on 2017-09-27 11:50 (UTC) (edited on 2017-09-27 11:51 (UTC) by hawkeye116477)

@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 (UTC)

@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 (UTC)

@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 (UTC)

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 (UTC) (edited on 2017-09-11 20:02 (UTC) by hawkeye116477)

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

meatatt commented on 2017-08-23 18:29 (UTC)

@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'.

hawkeye116477 commented on 2017-08-23 16:43 (UTC) (edited on 2017-08-23 18:15 (UTC) by hawkeye116477)

@meatatt Ok, thanks, fixed, but left as tarball for now, because for me it takes much time to clone. I don't know why it downloads at 250k. shows 20 Mbps, so should be 2m. Same is also with tarball, but it takes less space, so it faster downloads. I only have that slow download speed on git.

meatatt commented on 2017-08-22 15:23 (UTC)

Just switched from waterfox-git. Nice work, but it seems that you removed the 'not needed icons' without the removal of their hashes. And ccache is a make dependency. Also, I prefer vcs sources to tarballs because it's much faster to update a bare repo to new commits than download a full archive everytime. Here is the PKGBUILD: I bumped the pkgrel to 2, and made some personal modifications such as enabling pulse audio, jack & txt2speech. Diff and see :)