http://bugzilla.suse.com/show_bug.cgi?id=1012627 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-mozilla@forge.prov |wolfgang@rosenauer.org |o.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c2 --- Comment #2 from Michel Normand --- If I do compare jobhistory with related changes file then it seems the build failure is present since version 48.0 update. === $osc jobhistory mozilla:Factory/MozillaFirefox/openSUSE_Factory_PowerPC/ppc64 -l1000 >/tmp/x time package reason code MozillaFirefox.changes ... 2016-07-20 10:12:31 MozillaFirefox source change succeeded <= Tue Jul 19 Update the appdata.xml 2016-07-21 12:12:43 MozillaFirefox meta change unchanged 2016-07-24 22:39:06 MozillaFirefox source change failed <= Sat Jul 23 Fix Firefox crash on startup on i586 (boo#986541) 2016-07-27 18:29:18 MozillaFirefox meta change succeeded 2016-07-29 01:08:51 MozillaFirefox meta change unchanged 2016-07-29 10:30:06 MozillaFirefox source change succeeded <= Fri Jul 29 update in in appdata.xml 2016-07-31 12:52:20 MozillaFirefox meta change succeeded 2016-08-02 23:15:39 MozillaFirefox source change failed <= Mon Aug 1 update to Firefox 48.0 (boo#991809) 2016-08-03 05:41:54 MozillaFirefox source change failed ... 2016-12-13 22:17:24 MozillaFirefox source change failed <= Thu Dec 1 update to Firefox 50.0.2 2016-12-14 11:24:58 MozillaFirefox meta change failed === -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c4 Michel Normand changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wolfgang@rosenauer.org Flags| |needinfo?(wolfgang@rosenaue | |r.org) --- Comment #4 from Michel Normand --- Hello Wolgang do you have a suggestion for investigation of ABORT error as per log extract of [1] ? The ABORT is the result of JS_InitWithFailureDiagnostic failure in XPCOMInit.cpp as per code extract (2) (1) https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/MozillaFire... === [ 3620s] Executing /home/abuild/rpmbuild/BUILD/obj/dist/bin/xpcshell -g /home/abuild/rpmbuild/BUILD/obj/dist/bin/ -a /home/abuild/rpmbuild/BUILD/obj/dist/bin/ -f /home/abuild/rpmbuild/BUILD/mozilla/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache("resource://gre/"); [ 3620s] [24699] ###!!! ABORT: u_init() failed: file /home/abuild/rpmbuild/BUILD/mozilla/xpcom/build/XPCOMInit.cpp, line 672 [ 3620s] [24699] ###!!! ABORT: u_init() failed: file /home/abuild/rpmbuild/BUILD/mozilla/xpcom/build/XPCOMInit.cpp, line 672 [ 3620s] Traceback (most recent call last): [ 3620s] File "/home/abuild/rpmbuild/BUILD/mozilla/toolkit/mozapps/installer/packager.py", line 415, in <module> [ 3620s] main() [ 3620s] File "/home/abuild/rpmbuild/BUILD/mozilla/toolkit/mozapps/installer/packager.py", line 409, in main [ 3620s] args.source, gre_path, base) [ 3620s] File "/home/abuild/rpmbuild/BUILD/mozilla/toolkit/mozapps/installer/packager.py", line 166, in precompile_cache [ 3620s] errors.fatal('Error while running startup cache precompilation') [ 3620s] File "/home/abuild/rpmbuild/BUILD/mozilla/python/mozbuild/mozpack/errors.py", line 103, in fatal [ 3620s] self._handle(self.FATAL, msg) [ 3620s] File "/home/abuild/rpmbuild/BUILD/mozilla/python/mozbuild/mozpack/errors.py", line 98, in _handle [ 3620s] raise ErrorMessage(msg) [ 3620s] mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation === (2) === extract mozilla/xpcom/build/XPCOMInit.cpp // Initialize the JS engine. const char* jsInitFailureReason = JS_InitWithFailureDiagnostic(); if (jsInitFailureReason) { NS_RUNTIMEABORT(jsInitFailureReason); } === -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c6 --- Comment #6 from Michel Normand --- (In reply to Michal Suchanek from comment #5)

As a workaround can you build without EXPOSE_INTL_API whatever it is?

Michal, may be you could try with a build I have in my branch (1) with last available Firefox version. At least the build is OK for ppc64/ppc64le but I did not tried to use it. (I did not searched the EXPOSE_INTL_API your are referring above) (1) https://build.opensuse.org/package/show/home:michel_mno:branches:mozilla:Fac... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c8 --- Comment #8 from Michal Suchanek --- The original issue persists even with the updated firefox. The problem is that the numeric format value is different on BE and LE, and the values 0 and 1 are invalid on BE and something is obviously passing them into GfxFormatToCairoFormat: enum class SurfaceFormat : int8_t { // The following values are named to reflect layout of colors in memory, from // lowest byte to highest byte. The 32-bit value layout depends on machine // endianness. // in-memory 32-bit LE value 32-bit BE value B8G8R8A8, // [BB, GG, RR, AA] 0xAARRGGBB 0xBBGGRRAA B8G8R8X8, // [BB, GG, RR, 00] 0x00RRGGBB 0xBBGGRR00 R8G8B8A8, // [RR, GG, BB, AA] 0xAABBGGRR 0xRRGGBBAA R8G8B8X8, // [RR, GG, BB, 00] 0x00BBGGRR 0xRRGGBB00 A8R8G8B8, // [AA, RR, GG, BB] 0xBBGGRRAA 0xAARRGGBB X8R8G8B8, // [00, RR, GG, BB] 0xBBGGRR00 0x00RRGGBB #if MOZ_LITTLE_ENDIAN A8R8G8B8_UINT32 = B8G8R8A8, // 0xAARRGGBB X8R8G8B8_UINT32 = B8G8R8X8 // 0x00RRGGBB #elif MOZ_BIG_ENDIAN A8R8G8B8_UINT32 = A8R8G8B8, // 0xAARRGGBB X8R8G8B8_UINT32 = X8R8G8B8 // 0x00RRGGBB My guess is that SurfaceFormatToImageFormat and ImageFormatToSurfaceFormat should mirror the endian format branching above but do not. Still being able to build current firefox on ppc64 be is nice. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c10 Sebastian Parschauer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian.parschauer@suse.c | |om --- Comment #10 from Sebastian Parschauer --- I have a patch to silence the messages in L3 bug 1105124. HTML5 video uses the little endian color scheme which can look really ugly on big endian. On a ppc64 or s390x box you also don't really want to play videos as there is no HW acceleration for this. So your videos are plain too slow. Converting all that from le colors to be colors makes it even slower. AFAIK those systems are rather used for big data processing instead of fancy graphics and remote Firefox web surfing. ;) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c14 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #14 from Michal Suchanek --- The boxes do have actual video cards so can render video. VMs can also render video and stream it over the virtual video card provided the video is rendered correctly. Since more and more documentation is provided as video only it is important to be able to render video anywhere in reasonable quality. You probably cannot render a 4k video in software even on a POWER machine but that does not mean rendering videos does not work or is useless. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c16 --- Comment #16 from Sebastian Parschauer --- I can play a Youtube video in 360p if I use a ppc64 machine in NUE as SSH+SOCKS5 proxy but the dirty work to play the video is done on x86_64 then. As I can access it directly with my ISP, I get better performance (1080p) without the proxy of cause. Would be interesting to stream big-endian original video material from one big-endian machine to another. Then there should be no need for endianness conversion at least. Would be also interesting which FPS rate the SW renderer with glxgears provides with a monitor directly attached to the ppc64 box. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1012627 http://bugzilla.suse.com/show_bug.cgi?id=1012627#c18 --- Comment #18 from Michal Suchanek --- (In reply to Sebastian Parschauer from comment #16)

Would be interesting to stream big-endian original video material from one big-endian machine to another. Then there should be no need for endianness conversion at least.

There is no big-endian video material. The material coming from youtube is always the same. It becomes bigendian when the wrong endian load is used to load it from memory. I am not sure what Firefox does with the data but ideally it should tag it correctly so that whatever rendering library is used knows what to do with the data. Unfortunately, last time I looked at the code there was a boilerplate for endian handling but somebody took a shortcut and always assumed everything is littleendian and any endian conversion was missing. -- You are receiving this mail because: You are on the CC list for the bug.