Page 10 of 45
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-18, 10:28
by New Tobin Paradigm
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
Posted: 2018-01-18, 13:31
by Terryphi
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
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-18, 15:18
by inops
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
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-18, 16:42
by New Tobin Paradigm
That's what I said.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-18, 18:27
by inops
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-18, 19:20
by stevenpusser
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
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-19, 02:21
by stevenpusser
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-19, 14:29
by smoki
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
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-19, 14:50
by smoki
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
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-23, 01:20
by stevenpusser
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?
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-23, 13:10
by trava90
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-23, 19:19
by stevenpusser
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?
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-23, 20:17
by New Tobin Paradigm
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..
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-23, 23:14
by Walter Dnes
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.
Re: Debian 6
Posted: 2018-01-24, 02:00
by mandrivaONE07
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...
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-24, 02:09
by stevenpusser
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".
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-24, 02:26
by New Tobin Paradigm
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..
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-24, 22:24
by stevenpusser
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.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-24, 22:51
by New Tobin Paradigm
We need detection for glib version then we could ifdef and support both.
Re: Ubuntu 14.04, 16.04, 16.10, 17.04, Debian 7, 8, 9 Pale Moon repositories
Posted: 2018-01-24, 23:23
by stevenpusser
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.