Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 723372

Summary: www-client/seamonkey-2.53.2 - ERROR: --disable-skia is not supported anymore
Product: Gentoo Linux Reporter: ernsteiswuerfel <erhard_f>
Component: Current packagesAssignee: Myckel Habets <gentoo-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: jstein, marcus, mattst88, mozilla, sam
Priority: Normal Keywords: PullRequest
Version: unspecified   
Hardware: PPC64   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=703862
https://github.com/gentoo/gentoo/pull/24760
https://bugs.gentoo.org/show_bug.cgi?id=836319
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: build.log
emerge --info
build.log (ppc64, 2.53.11.1)

Description ernsteiswuerfel archtester 2020-05-16 11:38:28 UTC
Created attachment 639626 [details]
build.log

[...]
checking for the Bing API key... no
checking for the Adjust SDK key... no
checking for the Leanplum SDK key... no
checking for the Pocket API key... no
ERROR: --disable-skia is not supported anymore
*** Fix above errors and then restart with\
               "make -f client.mk build"
make: *** [client.mk:362: configure] Error 1
 * ERROR: www-client/seamonkey-2.53.2::gentoo failed (configure phase):
 *   emake failed
Comment 1 ernsteiswuerfel archtester 2020-05-16 11:39:02 UTC
Created attachment 639628 [details]
emerge --info
Comment 2 Myckel Habets 2022-03-22 14:32:56 UTC
It seems like mozilla made the choice that skia is a required component Firefox, and Seamonkey backported this.

So a build without skia isn't possible any more. My plan is remove the endianess-check and the skia-related compile options from the ebuild. In principle this solves this bug, but there is a chance building Seamonkey on PPC64 will fail, due to the endianess. In that case, bugs need to be filed upstream.
Comment 3 Marcus Comstedt 2022-03-22 14:59:45 UTC
IME trying to file upstream bugs with skia is a dead end; they don't care that their crap is broken.  Keeping a huge local patchset is the only what to get it to work properly.  I have one here:
https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/skia.patch
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-22 18:06:08 UTC
While that doesn't sound crazy, I still think it'd be worth filing bugs so we can ask some of the people we know about them and try poke things internally if necessary. Not promising that will work, but my point is we'd need tangible bugs/patches submitted to link to, rather than complaining in abstract.

Would you consider submitting those patches somewhere if you haven't already?
Comment 5 Marcus Comstedt 2022-03-22 21:20:56 UTC
@sam Here's an example of a patch I submitted, and all the good it did me:
https://skia-review.googlesource.com/c/skia/+/342921
Not exactly my idea of a fruitful activity.
Comment 6 Myckel Habets 2022-03-22 22:19:11 UTC
With "upstream" I meant Seamonkey upstream (or Mozilla/Firefox), not skia itself.

Mozilla/Firefox devs have committed themselves for supporting skia by accepting patches for all the platforms that they support (including big endian archs).
See https://bugzilla.mozilla.org/show_bug.cgi?id=1323303.

I've already talked with Seamonkey upstream regarding skia and they said they backported https://bugzilla.mozilla.org/show_bug.cgi?id=1144632 this afternoon (will get into the patch queue). However, they don't have any big endian systems to test it.

The best I can do now is fix the ebuild for the next release (as it seems to be broken for PPC64 at this moment any way) and see if it build and works.
Comment 7 Marcus Comstedt 2022-03-23 16:10:00 UTC
> However, they don't have any big endian systems to test it.

Would it help if I donated a Raspberry Pi 3?
Comment 8 ernsteiswuerfel archtester 2022-03-23 17:28:43 UTC
(In reply to Marcus Comstedt from comment #7)
> Would it help if I donated a Raspberry Pi 3?
Hehe. But an interesting point! Are there any distros officially supporting BE on ARM hardware? I only know of https://github.com/zeldin/linux-1/releases
Comment 9 Marcus Comstedt 2022-03-23 17:30:48 UTC
Distros supporting 64-bit ARM in big endian mode?  Yes.  It's called Gentoo.  :-)
Comment 10 Myckel Habets 2022-03-24 09:49:00 UTC
(In reply to Marcus Comstedt from comment #7)
> > However, they don't have any big endian systems to test it.
> 
> Would it help if I donated a Raspberry Pi 3?

Hmmm... I wasn't aware R-Pi's are big endian. Got one somewhere here, might set it up to do some testing myself. :-D
Comment 11 ernsteiswuerfel archtester 2022-03-24 10:19:55 UTC
@Marcus: Well, then Gentoo FTW! ;) Didn't find BigEndian stages on the mirror, so I thought there was no official support. Did not do any further research as I got no Pi.

@Myckel: Not per default, only if you set it up to be BigEndian. Probably this is as easy as on ppc64 where you only need to set an option in the kernel .config. After that you would 'only' need BE toolchain and userland. And it looks like the Pi4 ist out of question at the moment: https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117.html
Comment 12 Marcus Comstedt 2022-03-24 10:59:26 UTC
@Myckel
Like all modern architectures (meaning anything newer than x86), ARM is bi-
endian.  All 64-bit cores from ARM Ltd (e.g. Cortex A-5x and A-7x) can switch
endianness at runtime, which also makes it possible to run KVM guests with a
different endianness than the host system.

If you want to run big endian bare metal (i.e. not in a VM) on Pi3, there are some kernel bugs which need fixing first.  I have a fixed kernel build here:
https://github.com/zeldin/linux-1/releases/tag/pi3be_v0.2
There is also a complete SD-card image with a Gentoo installation at the same
place.

@ernsteiswuerfel
There are no official stages AFAIK (but I have unofficial ones if you
want them), probably blocked by https://bugs.gentoo.org/782076

But there is an official profile:  

  [13]  default/linux/arm64/17.0/big-endian (exp) *

This was added after I made the initial Pi3BE release, but before I made the
second one, so the latest build uses this official profile.

Pi4 is fine, the only problem I have found is the USB3 controller on PCIe
(the XHCI driver _should_ work fine on BE, so I don't know what the problem is,
 possibly some issue with the PCIe root complex driver).

CM4 (with IO board) should work as it doesn't include the USB3 controller but
has USB via DWC instead just like Pi3.
Comment 13 Myckel Habets 2022-03-26 14:42:07 UTC
I've just put in a PR for a version bump of seamonkey, that also "fixes" this bug (it removes the check and the invalid configuration option) and puts in the upstream patch.

It seems that setting up a big endian system on basis of a R-Pi takes more time than I have, so if others have ready access to such system, feel free to test if it works. If you run into issues, please open a new bug for that (here, or upstream).
Comment 14 Alessandro Barbieri 2022-03-26 14:42:46 UTC
Thanks for the patches, I'll add them to media-gfx/skia::guru
Comment 15 Larry the Git Cow gentoo-dev 2022-03-27 00:24:20 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=600d93ba48fad2419b0cc20874b336b31902edb3

commit 600d93ba48fad2419b0cc20874b336b31902edb3
Author:     Myckel Habets <gentoo-bugs@habets-dobben.nl>
AuthorDate: 2022-03-26 14:22:48 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-03-27 00:24:11 +0000

    www-client/seamonkey: bump version to 2.53.11.1
    
    Additionally:
    
    * Remove check for big endian and conditional --disable-skia configuration option.
    * Include an upstream patch that fixes the skia build on big endian systems.
    Bug: https://bugs.gentoo.org/723372
    
    * Remove a sed that suppresses format errors on gcc-9.
    
    Signed-off-by: Myckel Habets <gentoo-bugs@habets-dobben.nl>
    Closes: https://github.com/gentoo/gentoo/pull/24760
    Signed-off-by: Sam James <sam@gentoo.org>

 www-client/seamonkey/Manifest                   |   3 +
 www-client/seamonkey/seamonkey-2.53.11.1.ebuild | 543 ++++++++++++++++++++++++
 2 files changed, 546 insertions(+)
Comment 16 ernsteiswuerfel archtester 2022-03-27 19:33:00 UTC
Created attachment 768012 [details]
build.log (ppc64, 2.53.11.1)

First I needed to comment out "mozconfig_annotate '' --disable-elf-hack" in the ebuild or I get this error:
[...]
 0:06.47 mozbuild.configure.options.InvalidOptionError: --disable-elf-hack is not available in this configuration

After commenting out the '--disable-elf-hack' line the 2.53.11.1 build continues but fails later with :
[...]
31:06.70 In file included from /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:16:
31:06.70 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/seccomp_macros.h:290:2: error: #error Unsupported target platform
31:06.70   290 | #error Unsupported target platform
31:06.70       |  ^~~~~
31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc: In function 'const char* sandbox::bpf_dsl::{anonymous}::DataOffsetName(size_t)':
31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:68:10: error: 'SECCOMP_NR_IDX' was not declared in this scope; did you mean 'SECCOMP_RET_KILL'?
31:07.00    68 |     case SECCOMP_NR_IDX:
31:07.00       |          ^~~~~~~~~~~~~~
31:07.00       |          SECCOMP_RET_KILL
31:07.00 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:70:10: error: 'SECCOMP_ARCH_IDX' was not declared in this scope
31:07.00    70 |     case SECCOMP_ARCH_IDX:
31:07.00       |          ^~~~~~~~~~~~~~~~
31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:72:10: error: 'SECCOMP_IP_LSB_IDX' was not declared in this scope
31:07.01    72 |     case SECCOMP_IP_LSB_IDX:
31:07.01       |          ^~~~~~~~~~~~~~~~~~
31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:74:10: error: 'SECCOMP_IP_MSB_IDX' was not declared in this scope
31:07.01    74 |     case SECCOMP_IP_MSB_IDX:
31:07.01       |          ^~~~~~~~~~~~~~~~~~
31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc: In function 'void sandbox::bpf_dsl::{anonymous}::AppendInstruction(std::string*, size_t, const sock_filter&)':
31:07.01 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:90:42: error: 'SECCOMP_ARG_LSB_IDX' was not declared in this scope
31:07.02    90 |         if (maybe_argno < 6 && insn.k == SECCOMP_ARG_LSB_IDX(maybe_argno)) {
31:07.02       |                                          ^~~~~~~~~~~~~~~~~~~
31:07.02 /var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/security/sandbox/chromium/sandbox/linux/bpf_dsl/dump_bpf.cc:93:30: error: 'SECCOMP_ARG_MSB_IDX' was not declared in this scope
31:07.02    93 |                    insn.k == SECCOMP_ARG_MSB_IDX(maybe_argno)) {
31:07.02       |                              ^~~~~~~~~~~~~~~~~~~
31:07.08 gmake[4]: *** [/var/tmp/portage/www-client/seamonkey-2.53.11.1/work/seamonkey-2.53.11.1/config/rules.mk:1033: dump_bpf.o] Error 1
[...]

So in it's current state 2.53.11.1 is not buildable (yet) on ppc64.
Comment 17 Marcus Comstedt 2022-03-27 21:07:03 UTC
@ernsteiswuerfel Sigh, looks like more chromium cruft has been cargo-culted
into seamonkey...

chromium's sandbox (like most chromium components) is broken on ppc64.
Here's a patch:

https://github.com/zeldin/chromium_be/blob/master/chromium-89.0.4389.114/sandbox.patch
Comment 18 ernsteiswuerfel archtester 2022-03-27 21:36:02 UTC
@Marcus: Thanks! This is quite a large patch. Will take some time to find and try the relevant parts concerning seamonkey. If I succeed at all...
Comment 19 Marcus Comstedt 2022-03-28 06:48:17 UTC
@ernsteiswuerfel
Gentoo already carries most of the patch for www-client/chromium (unless
it was removed again), I just added the 11 lines needed for BE support.
Comment 20 Myckel Habets 2022-03-28 10:42:01 UTC
Closing this bug, as its part has been completed. I made a new bug tracker to handle PPC64 support (and BE in general): Bug 836319

Please continue discussion there.