Package Details: palemoon 28.5.2-1

Git Clone URL: (read-only)
Package Base: palemoon
Description: Open source web browser based on Firefox focusing on efficiency.
Upstream URL:
Keywords: browser goanna web
Licenses: GPL, MPL, LGPL
Submitter: artiom
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 120
Popularity: 1.632593
First Submitted: 2014-06-05 10:54
Last Updated: 2019-06-05 10:15

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

WorMzy commented on 2017-11-24 22:59

A notify daemon is not needed to build the package. If your build is really terminating because it can't create a notification file a bug report upstream and/or build in a clean chroot.

sph commented on 2017-11-18 09:56

unable to build without a service providing org.frreedesktop.Notifications (eg. xfce4-notifyd), please add it as a dep

19:03.76 Notification center failed: The name org.freedesktop.Notifications was not provided by any .service files

EDIT: and it has to be started, even. meh.

sekret commented on 2017-11-15 05:01

Ok, all is good now. @WorMzy it's as you described.

Problem solved :-)

sekret commented on 2017-11-13 05:48

Interesting! I again tried to build palemoon with my old build of gcc5 from the AUR. Now it stopped at another point.

41:38.95 make[5]: *** [/build/palemoon/src/Pale-Moon/config/ Unified_cpp_dom_canvas0.o] Error 1
41:38.95 make[4]: *** [/build/palemoon/src/Pale-Moon/config/ dom/canvas/target] Error 2
41:38.95 make[4]: *** Waiting for unfinished jobs....
41:38.95 Unified_cpp_dom_media3.o
41:40.16 In file included from /build/palemoon/src/pmbuild/dom/media/Unified_cpp_dom_media1.cpp:20:0:
41:40.16 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: At global scope:
41:40.16 Warning: -Wunused-variable in /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used
41:40.16 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp:893:20: warning: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used [-Wunused-variable]
41:40.16 static const char* TYPE_STR[3] = {"NONE", "XING", "VBRI"};
41:40.16 ^
41:58.92 libdom_media.a.desc
41:58.99 make[3]: *** [/build/palemoon/src/Pale-Moon/config/ compile] Error 2
41:58.99 make[2]: *** [/build/palemoon/src/Pale-Moon/config/ default] Error 2
41:58.99 make[1]: *** [/build/palemoon/src/Pale-Moon/ realbuild] Error 2
41:58.99 make: *** [ build] Error 2
41:59.02 114 compiler warnings present.
41:59.33 Notification center failed: Install the python dbus module to get a notification when the build finishes.
==> ERROR: A failure occurred in build().

How can this be so random?!?!

Ok I'll definitely rebuild gcc5 now while the machine is alone.

Oh and:
$ grep _GLIBCXX_USE_C99_MATH /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h
/* #undef _GLIBCXX_USE_C99_MATH */
#define _GLIBCXX_USE_C99_MATH_TR1 1

WorMzy commented on 2017-11-12 23:07

Thanks, runical.

@sekret, that probably was the culprit (or at least part of the problem). Ignore the _TR1 varient, it is the '#undef _GLIBCXX_USE_C99_MATH' that causes the __builtin problem, and is possibly the cause of your build failure too. If the gcc5 rebuild had completed, you would (hopefully) have found that c++config.h now had '#define _GLIBCXX_USE_C99_MATH 1' instead, and the palemoon package builds again.

runical commented on 2017-11-12 21:25

I built GCC5 last Thursday (November 9th). The exact time being 12:35:53 CET.

My processor: Intel(R) Core(TM) i5-4200M

The build flags in my chroot are as standard as they come:

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"

_GLIBCXX_USE_C99_MATH is also defined.

I don't know if the info was still needed, but here you go.

sekret commented on 2017-11-12 20:53

I had to abort the build, my system got unstable... Old machine ;-)

But here's an info from the "old" gcc5, which causes palemoon to not build

$ grep _GLIBCXX_USE_C99_MATH /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h
/* #undef _GLIBCXX_USE_C99_MATH */
#define _GLIBCXX_USE_C99_MATH_TR1 1

So this wasn't the culprit on my machine.

sekret commented on 2017-11-12 12:44

My old build of gcc5 was finished 31.10.2017 18:00. The rebuild runs right now, takes quite a while, because I have an old CPU

$ grep "model name" /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz
model name : Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz

WorMzy commented on 2017-11-12 12:38

Recompiling gcc5 worked for me. \o/

I am now thoroughly confused.

There was a rebuild of glibc on the 29th of October, which may have pulled in this commit [1], which sounds like it would have fixed the problem me and wolf were encountering.

It seems that there are three different builds of gcc5, all slightly different depending on the environment they were built in. Wolf and me had one variant, which led to the __builtin build failures, sekret had one which led to the Unified_cpp_dom_canvas0.o build failure, and runical and fabertawe had one which led to a successful build.

I strongly suspect glibc was responsible for the group one failures, I'm not sure about group two, and I'm going to assume group three builds were done after groups one and two. Comparing dates on our respective gcc5 packages may confirm this, but so long as the problem is resolved, I'm not going to expend too much effort investigating it.


fabertawe commented on 2017-11-12 11:29

I don't build in a clean chroot! CPU is an Intel i7 4790k, 'makepkg.conf' reads...
CFLAGS="-march=native -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"

'c++config.h' (untouched by me) shows...
#define _GLIBCXX_USE_C99_MATH 1