Package Details: palemoon 1:33.5.0-1

Git Clone URL: https://aur.archlinux.org/palemoon.git (read-only, click to copy)
Package Base: palemoon
Description: Open source web browser based on Firefox focusing on efficiency.
Upstream URL: https://www.palemoon.org/
Keywords: browser goanna web
Licenses: MPL-2.0
Submitter: artiom
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 141
Popularity: 0.064316
First Submitted: 2014-06-05 10:54 (UTC)
Last Updated: 2024-12-05 10:09 (UTC)

Pinned Comments

WorMzy commented on 2021-03-02 16:19 (UTC) (edited on 2022-08-03 21:12 (UTC) by WorMzy)

The following key is used to sign release commits:

40481E7B8FCF9CEC

Import it into your keyring however you want.

https://wiki.archlinux.org/index.php/GnuPG#Import_a_public_key

Latest Comments

« First ‹ Previous 1 .. 26 27 28 29 30 31 32 33 34 35 36 .. 38 Next › Last »

WorMzy commented on 2016-05-12 22:32 (UTC) (edited on 2016-05-12 22:32 (UTC) by WorMzy)

I've opened a thread on the Pale Moon forums with various logs. Feel free to take a look and participate in the thread, or make suggestions here or by email if you don't have a forum account. :) EDIT: Link: http://forum.palemoon.org/viewtopic.php?f=37&t=12045

wolf commented on 2016-05-12 04:24 (UTC) (edited on 2016-05-12 04:24 (UTC) by wolf)

To the best of my knowledge, `-flto=7` shouldn't have any success on any asserts.. Link time optimization shouldn't really affect if the program compiles or not. I can try it without the `-flto` just to make sure when I get from work, but I would be really surprised if it won't compile without it. Could you post the error you get during compilation here or to my email? Maybe I can help.

WorMzy commented on 2016-05-11 23:43 (UTC)

Thanks for the offer. I think you're on to something with the -flto flag you're using -- another PM user had similar success with LTO with gcc6: https://forum.palemoon.org/viewtopic.php?t=11715 Unfortunately, I don't know what LTO is, and just adding -flto=7 to my *FLAGS didn't seem to make any difference on my system. I'm going to have to read up on LTO and see if I can't figure out why it seems to help in some cases. I'd quite like to drop the gcc5 dep asap.

wolf commented on 2016-05-11 20:52 (UTC) (edited on 2016-05-11 21:26 (UTC) by wolf)

Standard gcc from core/gcc: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160501 (GCC) PKGBUILD - only change was upaded md5sum of mozconfig.in mozconfig.in - only change was removing the `-5` suffix for CC and CXX makepkg.conf CFLAGS="-flto=7 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4" CXXFLAGS="-flto=7 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4" LDFLAGS="-flto=7 -Wl,-O1,--sort-common,--as-needed,-z,relro" MAKEFLAGS="-j7" [..] #-- Destination: specify a fixed directory where all packages will be placed PKGDEST=~/archrepo/packages #-- Source cache: specify a fixed directory where source files will be cached #SRCDEST=~/archrepo/sources #-- Source packages: specify a fixed directory where all src packages will be placed SRCPKGDEST=~/archrepo/srcpackages #-- Log files: specify a fixed directory where all log files will be placed #LOGDEST=/home/makepkglogs #-- Packager: name/email of the person or organization building packages PACKAGER="Wolf <wolf@wolfsden.cz>" #-- Specify a key to use for package signing GPGKEY="52C5A16E" Nothing else was changed afaik.

WorMzy commented on 2016-05-11 20:24 (UTC)

Interesting, I've not had any success with gcc6, on three different PCs. It aborts after 10 minutes or so complaining that MOZ_ASSERT needs to be declared. The gcc5 makedep is supposed to be a stopgap until I can figure out what's causing the build to fail with gcc6. Have you customized your makepkg.conf, PKGBUILD, or mozconfig.in at all? (besides changing the CC and CXX declarations)

wolf commented on 2016-05-11 20:08 (UTC)

Why it needs gcc-5? I tried to compile it with current core/gcc (6.1.something) and it worked just fine.

WorMzy commented on 2016-04-09 10:38 (UTC)

Whoops. Thanks for pointing that out, djmattyg007. Fixed.

djmattyg007 commented on 2016-04-09 01:42 (UTC)

I flagged this package as out of date, but in actual fact it's just that the .SRCINFO file wasn't updated. This was very confusing.

WorMzy commented on 2016-04-06 14:54 (UTC)

Looks like valgrind is tripping the build up. As I understand it, valgrind is supposed to be disabled by default [1] unless explicitly enabled in mozconfig, but this doesn't appear to be the case. Build in a clean chroot [2] if you can, or try a build with 'ac_add_options --disable-valgrind' in mozconfig.in, if you try the latter, and it works, please file a bug upstream. As an aside, I'd recommend not building palemoon in /tmp unless you have a really big /tmp (e.g. 15GB+) [1] https://github.com/MoonchildProductions/Pale-Moon/blob/master/configure.in#L1590 [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

Matalonder commented on 2016-04-06 12:23 (UTC)

Building palemoon 26.2.0-1 fails on two machines for me as of the time of this comment. http://pastebin.com/U9zg1jfH