Repositories for supported Debian, Raspbian, and Ubuntu releases

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
New Tobin Paradigm

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

Unread post by New Tobin Paradigm » 2018-01-18, 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.

Terryphi

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

Unread post by Terryphi » 2018-01-18, 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

inops

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

Unread post by inops » 2018-01-18, 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 2018-01-18, 15:25, edited 1 time in total.

New Tobin Paradigm

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

Unread post by New Tobin Paradigm » 2018-01-18, 16:42

That's what I said.

inops

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

Unread post by inops » 2018-01-18, 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 2018-01-18, 18:27, edited 1 time in total.

User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-18, 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
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-19, 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 stevenpusser on 2018-01-19, 02:22, edited 1 time in total.

smoki

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

Unread post by smoki » 2018-01-19, 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

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

Unread post by smoki » 2018-01-19, 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
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-23, 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: 1736
Joined: 2013-05-20, 18:19
Location: Somewhere in Sector 001

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

Unread post by trava90 » 2018-01-23, 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
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-23, 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?

New Tobin Paradigm

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

Unread post by New Tobin Paradigm » 2018-01-23, 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 2018-01-23, 20:19, edited 1 time in total.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

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

Unread post by Walter Dnes » 2018-01-23, 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

mandrivaONE07

Re: Debian 6

Unread post by mandrivaONE07 » 2018-01-24, 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
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-24, 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".

New Tobin Paradigm

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

Unread post by New Tobin Paradigm » 2018-01-24, 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 2018-01-24, 02:27, edited 1 time in total.

User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-24, 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 stevenpusser on 2018-01-24, 22:28, edited 1 time in total.

New Tobin Paradigm

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

Unread post by New Tobin Paradigm » 2018-01-24, 22:51

We need detection for glib version then we could ifdef and support both.

User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

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

Unread post by stevenpusser » 2018-01-24, 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 stevenpusser on 2018-01-24, 23:52, edited 1 time in total.

Post Reply