Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Support and discussions for the x86/x64 Linux version of Pale Moon.

Moderators: trava90, satrow

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby New Tobin Paradigm » Thu, 18 Jan 2018, 10:28

Dnes's memory address space overflows and he will stop giving bad advice. I mean epoch won't fit into a 32bit integer anymore.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

User avatar
Terryphi
Fanatic
Fanatic
Posts: 156
Joined: Wed, 26 Aug 2015, 06:32
Location: Wales, UK

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby Terryphi » Thu, 18 Jan 2018, 13:31

gracious1 wrote:
Walter Dnes wrote:We've got 20 more years till 2038.

What happenes in 2038? :?:

Year 2038 problem - https://en.wikipedia.org/wiki/Year_2038_problem
Linux Mint 18.3 64bit MATE. Latest release builds of Pale Moon and Basilisk.

inops
Moongazer
Moongazer
Posts: 9
Joined: Thu, 23 Feb 2017, 15:38

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby inops » Thu, 18 Jan 2018, 15:18

gracious1 wrote:What happenes in 2038? :?:

https://en.wikipedia.org/wiki/Year_2038_problem
tl;dr: On 32-bit machines, Unix time will tick back to 1901, because of the limitations of a signed 32-bit integer
pretty similar to the Y2K bug
Last edited by inops on Thu, 18 Jan 2018, 15:25, edited 1 time in total.

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby New Tobin Paradigm » Thu, 18 Jan 2018, 16:42

That's what I said.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

inops
Moongazer
Moongazer
Posts: 9
Joined: Thu, 23 Feb 2017, 15:38

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby inops » Thu, 18 Jan 2018, 18:27

stevepusser wrote: I don't know how stable it is when built with that compiler, so if you could test it, I would appreciate it.

I've just tested on my install of 17.10 and I keep getting segmentation faults (usually after a few minutes of use), here's the tail-end of the core dump:

Code: Select all

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `palemoon'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  raise (sig=<optimised out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7fcba606f740 (LWP 7907))]


if you can manage to compile PM with gcc v4, I'll be glad to try it.
Last edited by inops on Thu, 18 Jan 2018, 18:27, edited 1 time in total.

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Thu, 18 Jan 2018, 19:20

Well, the 14.04 version is compiled with the gcc-4.8 that's default in that release, along with all the software that was in that LTS release, so it must have been stable enough for that. Let's see how I disable fstack-protector-strong and use `-fstack-protector --param ssp-buffer-size=4' instead for 4.8. I'm trying to follow this guide, after I get 27.7.1 built for the rest of the releases. https://wiki.debian.org/Hardening

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Fri, 19 Jan 2018, 02:21

stevepusser wrote:Well, the 14.04 version is compiled with the gcc-4.8 that's default in that release, along with all the software that was in that LTS release, so it must have been stable enough for that. Let's see how I disable fstack-protector-strong and use `-fstack-protector --param ssp-buffer-size=4' instead for 4.8. I'm trying to follow this guide, after I get 27.7.1 built for the rest of the releases. https://wiki.debian.org/Hardening


Edit: The standard and -nonsse2 versions have been updated to 27.7.1 in the repo. Still poking away at 17.10 builds with sticks.
Last edited by stevepusser on Fri, 19 Jan 2018, 02:22, edited 1 time in total.

smoki
Hobby Astronomer
Hobby Astronomer
Posts: 20
Joined: Fri, 19 Jan 2018, 05:34

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby smoki » Fri, 19 Jan 2018, 14:29

stevepusser wrote:Not to mention that so far none of the Debian or Ubuntu 32-bit kernels, in fact no Linux 32-bit kernels, offer any mitigation for the Meltdown attack.


Well at least someone upstream working on it, here are some early patches for 32-bit PTI support on lkml:

https://lkml.org/lkml/2018/1/16/668

smoki
Hobby Astronomer
Hobby Astronomer
Posts: 20
Joined: Fri, 19 Jan 2018, 05:34

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby smoki » Fri, 19 Jan 2018, 14:50

smoki wrote:
stevepusser wrote:Not to mention that so far none of the Debian or Ubuntu 32-bit kernels, in fact no Linux 32-bit kernels, offer any mitigation for the Meltdown attack.


Well at least someone upstream working on it, here are some early patches for 32-bit PTI support on lkml:

https://lkml.org/lkml/2018/1/16/668


Or better to say Intel CPUs, since only Intel is affected by Meltdown, but not AMD CPUs - so it is not a problem for everybody :lol:

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Tue, 23 Jan 2018, 01:20

I haven't quit working on 17.10, and am now trying gcc-4.9 in it again. First I must rebuild those packages in the 17.10 repo.

I guess clang compilers are out of the question for now, unless anyone has succeeded with those?

User avatar
trava90
Contributing developer
Contributing developer
Posts: 1438
Joined: Mon, 20 May 2013, 18:19
Location: Earth
Contact:

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby trava90 » Tue, 23 Jan 2018, 13:10

stevepusser wrote:I guess clang compilers are out of the question for now, unless anyone has succeeded with those?

At last check clang could successfully compile Pale Moon, but the resulting build was extremely unstable.

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Tue, 23 Jan 2018, 19:19

The OBS succeeded after about 12 hours in compiling gcc-4.9 for Ubuntu 17.10, but gave up after 23 hours for 32-bit.

The 64-bit Pale Moon build then fails with

Code: Select all

[ 1019s] /usr/src/packages/BUILD/dom/canvas/CanvasRenderingContext2D.cpp:2420:8: error: '__builtin_isfinite' is not a member of 'std'
[ 1019s]    if (!std::isfinite((float)aX) | !std::isfinite((float)aY) |
[ 1019s]         ^
[ 1019s] /usr/src/packages/BUILD/dom/canvas/CanvasRenderingContext2D.cpp:2420:8: note: suggested alternative:
[ 1019s] <built-in>: note:   '__builtin_isfinite'


because of this code in the noted file:

Code: Select all

  // bug 1018527
  // The values of canvas API input are in double precision, but Moz2D APIs are
  // using float precision. Bypass canvas API calls when the input is out of
  // float precision to avoid precision problem
  if (!std::isfinite((float)aX) | !std::isfinite((float)aY) |
      !std::isfinite((float)aWidth) | !std::isfinite((float)aHeight)) {
    return false;
  }


So there's a suggested alternative, but I'm no coder, so don't really know what they are suggesting. Should I bring this up as an issue on Github?

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby New Tobin Paradigm » Tue, 23 Jan 2018, 20:17

This is caused by Glib 2.26..

Also, why is OBS taking tens of hours to compile.. Shit, it would be easier to have a bunch of VMs your self and just..
Last edited by New Tobin Paradigm on Tue, 23 Jan 2018, 20:19, edited 1 time in total.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

Walter Dnes
Lunatic
Lunatic
Posts: 479
Joined: Thu, 30 Jul 2015, 20:29
Location: Vaughan, ON, Canada

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby Walter Dnes » Tue, 23 Jan 2018, 23:14

stevepusser wrote:The OBS succeeded after about 12 hours in compiling gcc-4.9 for Ubuntu 17.10, but gave up after 23 hours for 32-bit.

The 64-bit Pale Moon build then fails with

Ignore the error messages. It looks like gcc is running out of ram, and that generates all sorts of weird error messages that have nothing to do with your problem. Can you set your VM/chroot with more ram and swap?

My current desktop is a 2008 Dell with 3 gigs of ram and an Intel Core2 Duo running 32-bit Gentoo. It refuses to die. gcc-6.4.0 takes approx 3 hours to build, and gcc-5.4.0 took under 80 minutes. 4.9.4 should be approx an hour. Pale Moon builds in under 90 minutes. Recently, I've been using a Silvermont (64-bit Atom), 8 gigs of ram, running 64-bit Gentoo (with the same CentOS 6.5 chroot) for doing the builds. That takes almost 2 hours to build, because the Silvermont is 1.6 ghz max, versus the Core2Duo 2.4 ghz. If gcc is taking that long to build on the OBS server, you need more ram/swap.
There's a right way
There's a wrong way
And then there's my way

User avatar
mandrivaONE07
New to the forum
New to the forum
Posts: 1
Joined: Tue, 23 Jan 2018, 15:04
Contact:

Re: Debian 6

Postby mandrivaONE07 » Wed, 24 Jan 2018, 02:00

Since it gave the transition from GTK2 to GTK3, Firefox and consequently Seamonkey, without being able to update... the latter only up to the version

User agent: Mozilla/5.0 (X11; Linux i686; RV: 49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46

Pale Moon is wonderful, as long as you can give compatibility to most addons would be great...

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Wed, 24 Jan 2018, 02:09

Walter Dnes wrote:
stevepusser wrote:The OBS succeeded after about 12 hours in compiling gcc-4.9 for Ubuntu 17.10, but gave up after 23 hours for 32-bit.

The 64-bit Pale Moon build then fails with

Ignore the error messages. It looks like gcc is running out of ram, and that generates all sorts of weird error messages that have nothing to do with your problem. Can you set your VM/chroot with more ram and swap?

My current desktop is a 2008 Dell with 3 gigs of ram and an Intel Core2 Duo running 32-bit Gentoo. It refuses to die. gcc-6.4.0 takes approx 3 hours to build, and gcc-5.4.0 took under 80 minutes. 4.9.4 should be approx an hour. Pale Moon builds in under 90 minutes. Recently, I've been using a Silvermont (64-bit Atom), 8 gigs of ram, running 64-bit Gentoo (with the same CentOS 6.5 chroot) for doing the builds. That takes almost 2 hours to build, because the Silvermont is 1.6 ghz max, versus the Core2Duo 2.4 ghz. If gcc is taking that long to build on the OBS server, you need more ram/swap.


Gcc's going to take that long if all the self tests are enabled, as Debian and Ubuntu builds do by default. I turned them off in the rules.def file and the build completed in just a small fraction of the time. I tried versions of 4.9 built by Ubuntu's gcc-5-base and gcc-6-base, but they still fail with that same canvas error.

More frustrating is that I built gcc-4.9 for Debian 9 against its gcc-6, and that builds PM without errors. But that same version of gcc-4.9 fails to build in 17.10; I'm using a different version from a PPA for 17.10.

I can't find any way to change the VM parameters in the cloud that the OBS provides. I can't build some packages such as Mesa in it because those run out of virtual memory really quick.

If there's some way to fix that bit of code that generates the error, it's easy to create a patch incorporating it for the Debian build system, however. Just change the code and run "dpkg-source --commit".

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby New Tobin Paradigm » Wed, 24 Jan 2018, 02:26

I REALLY hope you don't mean the browser tests...

ALSO I told you it was Glib 2.26 that causes the error with infinity..
Last edited by New Tobin Paradigm on Wed, 24 Jan 2018, 02:27, edited 1 time in total.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Wed, 24 Jan 2018, 22:24

New Tobin Paradigm wrote:I REALLY hope you don't mean the browser tests...

ALSO I told you it was Glib 2.26 that causes the error with infinity..


No, I mean I disabled the self-tests of the compiler after it built, since the same source already succeeded in the self-tests in the first 64-bit build, plus in the PPA where I pulled the sources. The self-test procedure takes about ten times longer than actually just compiling gcc.

Oh, you mean the canvas errors are due to glibc 2.26 (libc6 in Debian and Ubuntu), not libglib2.0. That's why it succeeded in Stretch with libc6 2.24. OK, but changing that is not really an option for Ubuntu 17.10 or any current upstream Debian. Is there any approved patch to fix the build on glibc 2.26? I just googled the error message, and it appears it's pretty common in other programs with that glibc...let's see what they do to fix it.
Last edited by stevepusser on Wed, 24 Jan 2018, 22:28, edited 1 time in total.

User avatar
New Tobin Paradigm
Banned user
Banned user
Posts: 4417
Joined: Tue, 09 Oct 2012, 19:37

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby New Tobin Paradigm » Wed, 24 Jan 2018, 22:51

We need detection for glib version then we could ifdef and support both.
I hate Pod Six. Tch, I don't even know why we have a Pod Six. Total suck Pod.
[ ニュー・トビン・パラダイム ]

User avatar
stevepusser
Lunatic
Lunatic
Posts: 334
Joined: Sat, 01 Aug 2015, 18:33
Location: California

Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories

Postby stevepusser » Wed, 24 Jan 2018, 23:23

Could it be as simple as passing -std=c99 or -std-c++11 to the CXXFLAGS in mozconfig or exporting that in build environment?

It's also allowable in Debian policy to have a patch only for a specific distro release and assume that a certain package version is what you have. The original source from upstream, such as the Pale Moon tarball, is never changed; it's only extracted and patched during the build process. Some upstream Debian packages have patches that break the builds on Debian Stable, for example; the bane of backporters to stable like me...gnuradio in upstream Debian, for example. So I could upload separate source files for Ubuntu 17.10, and only those would have the patch.
Last edited by stevepusser on Wed, 24 Jan 2018, 23:52, edited 1 time in total.


Return to “Pale Moon for Linux”

Who is online

Users browsing this forum: No registered users and 9 guests