Palemoon overlay problem

Message

Princess Nell · Post by **Princess Nell** » Thu Dec 17, 2020 11:06 pm

Calculating dependencies / * ERROR: www-client/palemoon-28.16.0::palemoon failed (depend phase):
 *   fdo-mime.eclass could not be found by inherit()
 *

Looks like some updates to the overlay eclasses and palemoon-bin-28.16.0.ebuild are required as fdo-mime.eclass has been removed.
https://gitweb.gentoo.org/repo/gentoo.g ... a993717b59

Post by **Ionen** » Thu Dec 17, 2020 11:31 pm

Seems already a bug + PR opened about this.

Tony0945 · Post by **Tony0945** » Fri Dec 18, 2020 1:47 am

My own local ebuild derived from deulore's https://dpaste.com/96DDK2QRH
palemoon-5-r2.eclass may be a patched version of his. https://dpaste.com/62QPGZZ45

Princess Nell · Post by **Princess Nell** » Mon Dec 21, 2020 9:51 pm

It got fixed.

Princess Nell · Post by **Princess Nell** » Sun Feb 07, 2021 9:59 pm

Hijacking my own thread ...

Has anyone managed to build palemoon 29.x? Compile dies about 2 hours in and it's not quite clear to me what the reason is. The build log is about 2.5MB and it looks like every other file creates a ton of warnings about macros.

I need to use PALEMOON_ENABLE_UNSUPPORTED_COMPILERS with gcc 9.3.0, which is a bit surprising because https://github.com/deu/palemoon-overlay/issues/88, and the exact same setup has compiled probably a dozen versions in the palemoon 28.x series without problem.

saellaven · Post by **saellaven** » Sun Feb 07, 2021 10:31 pm

Princess Nell wrote:Hijacking my own thread ...

Has anyone managed to build palemoon 29.x? Compile dies about 2 hours in and it's not quite clear to me what the reason is. The build log is about 2.5MB and it looks like every other file creates a ton of warnings about macros.

I need to use PALEMOON_ENABLE_UNSUPPORTED_COMPILERS with gcc 9.3.0, which is a bit surprising because https://github.com/deu/palemoon-overlay/issues/88, and the exact same setup has compiled probably a dozen versions in the palemoon 28.x series without problem.

29.x doesn't work with gcc 9.3.0 anymore, I had to reinstall 8.4.0 to get it to compile.

Tony0945 · Post by **Tony0945** » Sun Feb 07, 2021 11:13 pm

saellaven wrote:29.x doesn't work with gcc 9.3.0 anymore, I had to reinstall 8.4.0 to get it to compile.

Interesting and alarming. I quit building palemoon a few versions back. In the early days it loaded substantially quicker than the binary, but for the whole 28.x series I could see no improvement so I went to full binary.
I haven't updated to 29.0 and if it is breaking the default standards, I'm not sure I want to. All I really want is Firefox with the FF 3 interface.

Princess Nell · Post by **Princess Nell** » Sun Feb 07, 2021 11:24 pm

Thanks, saellaven. I half expected to hear this.

Anon-E-moose · Post by **Anon-E-moose** » Mon Feb 08, 2021 12:17 am

I just tried with 9.3.0 and saw where the errors were being generated, but I'm not messing with it any more tonight.

There's a couple of warnings that are being generated as errors, I'll have to look for where to add the no-error override for those.

No doubt the C/C++ standards tightened up between 8 and 9 gcc series, at least as far as warnings/errors are concerned and that's why 8 works but 9 errors out.

Anon-E-moose · Post by **Anon-E-moose** » Mon Feb 08, 2021 2:47 pm

I just got it to compile with this patch

Code: Select all

$ cat /etc/portage/patches/www-client/palemoon-29.0.1/palemoon-wno-error.patch 
--- a/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:54:44.306010803 -0600
+++ b/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:50:31.812881070 -0600
@@ -31,7 +31,7 @@
 if CONFIG['GNU_CXX']:
     # Disable strict-aliasing for GCC, which is enabled by default
     # starting with version 7.1, see Mozilla bug 1363009.
-    CXXFLAGS += ['-Wno-shadow', '-Werror=format', '-fno-strict-aliasing']
+    CXXFLAGS += ['-Wno-shadow', '-Wno-error', '-fno-strict-aliasing']
 
 if CONFIG['JS_HAS_CTYPES'] and CONFIG['MOZ_SYSTEM_FFI']:
     CXXFLAGS += CONFIG['MOZ_FFI_CFLAGS']

Which is the same thing I did to get firefox 52.9 to compile.
I haven't tried running it yet, I'll do it later, but I expect it to work, as ff52.9 works fine with the same problem/solution.

What is happening is that gcc9.3 is complaining about a warning re error, that's not really an error. It's a dynamically built variation of sprintf, with incompleteness when looked at a compile time. Don't know why 9.3 complains vs 8.4 (not running gcc10 so don't know about that), but it may be a regression they haven't fixed.

Anyway the end result is with the patch, it just ignores the warning about Werror=format and leaves it alone, which is probably what the previous versions of gcc did.

saellaven · Post by **saellaven** » Mon Feb 08, 2021 5:34 pm

Anon-E-moose wrote:I just got it to compile with this patch
Code: Select all
$ cat /etc/portage/patches/www-client/palemoon-29.0.1/palemoon-wno-error.patch 
--- a/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:54:44.306010803 -0600
+++ b/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:50:31.812881070 -0600
@@ -31,7 +31,7 @@
 if CONFIG['GNU_CXX']:
     # Disable strict-aliasing for GCC, which is enabled by default
     # starting with version 7.1, see Mozilla bug 1363009.
-    CXXFLAGS += ['-Wno-shadow', '-Werror=format', '-fno-strict-aliasing']
+    CXXFLAGS += ['-Wno-shadow', '-Wno-error', '-fno-strict-aliasing']
 
 if CONFIG['JS_HAS_CTYPES'] and CONFIG['MOZ_SYSTEM_FFI']:
     CXXFLAGS += CONFIG['MOZ_FFI_CFLAGS']
Which is the same thing I did to get firefox 52.9 to compile.
I haven't tried running it yet, I'll do it later, but I expect it to work, as ff52.9 works fine with the same problem/solution.

What is happening is that gcc9.3 is complaining about a warning re error, that's not really an error. It's a dynamically built variation of sprintf, with incompleteness when looked at a compile time. Don't know why 9.3 complains vs 8.4 (not running gcc10 so don't know about that), but it may be a regression they haven't fixed.

Anyway the end result is with the patch, it just ignores the warning about Werror=format and leaves it alone, which is probably what the previous versions of gcc did.

Can confirm this patch works for me... I just hadn't gotten around to diagnosing the error itself.

Anon-E-moose · Post by **Anon-E-moose** » Mon Feb 08, 2021 11:02 pm

The error is this

Code: Select all

8 7:15.26 /var/tmp/portage/www-client/palemoon-29.0.1/work/palemoon-29.0.1/platform/js/src/jit/x86-shared/BaseAssembler-x86-shared.h:3967:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
8 7:15.26  3967 |                 spew("%-11s" MEM_ob ", %s", legacySSEOpName(name),
8 7:15.26       |                 ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8 7:15.26  3968 |                      ADDR_ob(offset, base), XMMRegName(dst));
8 7:15.26       |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to the gcc bugzilla, it's not likely to be fixed in gcc9 and it sorta works gcc10.

So I tried this change and it works well, leaves the Werror=format for any other formatting errors,
but turns off format-overflow checking, which is what it was complaining about.

Code: Select all

$ cat /etc/portage/patches/www-client/palemoon-29.0.1/palemoon-wno-error.patch 
--- a/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:54:44.306010803 -0600
+++ b/platform/js/src/js-cxxflags.mozbuild	2021-02-08 07:50:31.812881070 -0600
@@ -31,7 +31,7 @@
 if CONFIG['GNU_CXX']:
     # Disable strict-aliasing for GCC, which is enabled by default
     # starting with version 7.1, see Mozilla bug 1363009.
-    CXXFLAGS += ['-Wno-shadow', '-Werror=format', '-fno-strict-aliasing']
+    CXXFLAGS += ['-Wno-shadow', '-Werror=format', '-Wno-error=format-overflow', '-fno-strict-aliasing']
 
 if CONFIG['JS_HAS_CTYPES'] and CONFIG['MOZ_SYSTEM_FFI']:
     CXXFLAGS += CONFIG['MOZ_FFI_CFLAGS']

It compiled fine for me, this way. If you want to use gcc9 then use the patch.

sdauth · Post by **sdauth** » Wed Feb 10, 2021 9:36 am

Thanks for the patch Anon-E-moose

guru meditation · Post by **guru meditation** » Wed Feb 17, 2021 3:59 am

The ebuild for 29.0.1 complains on one machine with:

The following REQUIRED_USE flag constraints are unsatisfied:
exactly-one-of ( gtk2 gtk3 )

Setting -gtk2 or gtk3 in package.use doesn't solve it.

saellaven · Post by **saellaven** » Wed Feb 17, 2021 4:11 am

$ cat /etc/portage/package.use/palemoon
www-client/palemoon gtk3 gtk2

I haven't dug through the ebuild, but it seems to be ignoring the gtk3 flag, so the above works for me.

Anon-E-moose · Post by **Anon-E-moose** » Wed Feb 17, 2021 10:28 am

gtk2/3 are not mutually exclusive and they should be.

But since I had to put the ebuild in my local repo, ( to add gcc 9.3 for one thing) I went ahead and changed the ebuild

Code: Select all

 $ diff -u /n/download/palemoon-29.0.1.ebuild palemoon-29.0.1.ebuild 
--- /n/download/palemoon-29.0.1.ebuild	2021-02-17 04:25:42.570833559 -0600
+++ palemoon-29.0.1.ebuild	2021-02-07 17:19:23.790235710 -0600
@@ -1,7 +1,7 @@
 EAPI=6
 
 REQUIRED_BUILDSPACE='16G'
-GCC_SUPPORTED_VERSIONS="4.9 5.4 7.3 8.2 8.3 8.4"
+GCC_SUPPORTED_VERSIONS="4.9 5.4 7.3 8.2 8.3 8.4 9.3"
 
 inherit palemoon-5 git-r3 eutils flag-o-matic pax-utils
 
@@ -23,8 +23,8 @@
 	dbus
 	-necko-wifi
 	gnome
-	gtk2
-	gtk3
+	+gtk2
+	-gtk3
 	pulseaudio
 	+devtools
 "

But you should be able to tell it "-gtk3 gtk2" with use flags without the mod.

Leonardo.b · Post by **Leonardo.b** » Wed Feb 17, 2021 5:35 pm

USE gtk3 is masked.

Anon-E-moose · Post by **Anon-E-moose** » Wed Feb 17, 2021 6:17 pm

gtk2/3 isn't masked (at least on the ebuild I use), but both need to be set. ie either "-gtk2 gtk3" OR "gtk2 -gtk3".

I suppose you could tell it to try both "+", but I don't think it will work that way.

Leonardo.b · Post by **Leonardo.b** » Wed Feb 17, 2021 8:13 pm

Anon-E-moose,
sorry, that's not what I wanted to say.

In the Palemoon overlay there is a profile/package.use.mask that blocks gtk3 for www-client/palemoon.
That could explain why saellaven and guru meditation had troubles enabling that.
I had too.

gtk2 and gtk3 on the same package at the same time, I don't know. I guess it doesn't build at all.

Greetings,
Leonardo

Tony0945 · Post by **Tony0945** » Wed Feb 17, 2021 8:34 pm

Leonardo.b wrote:In the Palemoon overlay there is a profile/package.use.mask that blocks gtk3 for www-client/palemoon.

Very strange because there are binary downloads for gtk2 and for gtk3

Leonardo.b · Post by **Leonardo.b** » Wed Feb 17, 2021 9:11 pm

https://github.com/deu/palemoon-overlay/issues/84

Anon-E-moose · Post by **Anon-E-moose** » Wed Feb 17, 2021 9:12 pm

Leonardo.b wrote:Anon-E-moose,
sorry, that's not what I wanted to say.

In the Palemoon overlay there is a profile/package.use.mask that blocks gtk3 for www-client/palemoon.
That could explain why saellaven and guru meditation had troubles enabling that.
I had too.

gtk2 and gtk3 on the same package at the same time, I don't know. I guess it doesn't build at all.

Greetings,
Leonardo

I don't use the overlay, I just grab the ebuild and put it in my local repo.

But if they have it masked, it's probably because the gtk3 stuff doesn't have all the kinks worked out.

Edit to add: Saw link above, the flag may be left over from the 28 series, and it may be fixed for 29.
The flag can be overridden if someone wants to test it.

Leonardo.b · Post by **Leonardo.b** » Wed Feb 17, 2021 9:21 pm

Anon-E-moose,
yes, and your ebuild is better.

szatox · Post by **szatox** » Wed Feb 17, 2021 9:23 pm

Building palemoon is almost always an adventure.
I keep flipping the flags and never know which set is going to work this time.

gtk2 -gtk3
gtk2 gtk3
-gtk2 gtk3

It just can't seem to make it's mind. Yeah, I know "palemoon requires only one of them to be set and not the other". Still, if I got to build once, and recorded the flags in my config files, I'd expect it to build again without any issues.
Turns out I expect too much.

Tony0945 · Post by **Tony0945** » Wed Feb 17, 2021 11:10 pm

My package use for palemoon

Code: Select all

www-client/palemoon -jemalloc -official-branding  -pulseaudio gtk2  system-bzip2 system-libevent system-sqlite system-libvpx system-zlib threads

EDIT: This was up to and including 28.
I'm just using the bin's for 29