Repositories for supported Debian, Raspbian, and Ubuntu releases
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!
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!
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Dnes's memory address space overflows and he will stop giving bad advice. I mean epoch won't fit into a 32bit integer anymore.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Year 2038 problem - https://en.wikipedia.org/wiki/Year_2038_problemgracious1 wrote:What happenes in 2038?Walter Dnes wrote:We've got 20 more years till 2038.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
https://en.wikipedia.org/wiki/Year_2038_problemgracious1 wrote:What happenes in 2038?
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
That's what I said.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
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: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.
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))]
Last edited by inops on 2018-01-18, 18:27, edited 1 time in total.
- stevenpusser
- 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
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
- stevenpusser
- 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
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.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
Last edited by stevenpusser on 2018-01-19, 02:22, edited 1 time in total.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Well at least someone upstream working on it, here are some early patches for 32-bit PTI support on lkml: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.
https://lkml.org/lkml/2018/1/16/668
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Or better to say Intel CPUs, since only Intel is affected by Meltdown, but not AMD CPUs - so it is not a problem for everybodysmoki wrote:Well at least someone upstream working on it, here are some early patches for 32-bit PTI support on lkml: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.
https://lkml.org/lkml/2018/1/16/668
- stevenpusser
- 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
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?
I guess clang compilers are out of the question for now, unless anyone has succeeded with those?
- trava90
- 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
At last check clang could successfully compile Pale Moon, but the resulting build was extremely unstable.stevepusser wrote:I guess clang compilers are out of the question for now, unless anyone has succeeded with those?
- stevenpusser
- 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
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
because of this code in the noted file:
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?
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'
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;
}
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
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..
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.
-
- 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
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?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
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
There's a wrong way
And then there's my way
Re: Debian 6
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 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...
- stevenpusser
- 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
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.Walter Dnes wrote: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?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
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.
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".
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
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..
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.
- stevenpusser
- 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
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.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..
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
We need detection for glib version then we could ifdef and support both.
- stevenpusser
- 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
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.
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.