Re: PPC64 install && Firefox

[Ken Cunningham]

> On Apr 8, 2024, at 1:02 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> On Mon, 2024-04-08 at 19:38 +1200, Mike Hosken wrote:

>> As for Firefox thanks for the info, hopefully it will get fixed as it would 
>> make
>> ppc64 still very useable in this modern era. 
> 
> Well, someone interested in Firefox on big-endian targets would have to take 
> a look
> at it. I currently don't have the time for it.
> 
> Adrian


FireFox is quite broken, for a long time now.

There was a browser thread a few months ago.

The only browser I have found that is worth using on ppc64 debian so far is 
SeaLion.

https://lists.debian.org/debian-powerpc/2023/11/msg00012.html


It works pretty.well, and was updated not long ago. It's not perfect either, 
but so far is much better than anything else.

K

Re: PPC64 install && Firefox

[Thomas Schmitt]

Hi,

Mike Hosken wrote:
> When I burned it to a cd it didn’t boot. When I tried a dvd it did boot.

That's strange. Do you still have that CD with the ISO on it ?
If so, what do you get from a run of

  xorriso -indev /dev/sr0 -toc -report_system_area plain -check_media --

assumed that /dev/sr0 is the drive by which you tried to boot.

It will show what the drive perceives as table of content and it will
try to read all blocks that are covered by the ISO.
(No need to show all of the many pacifier lines like
   xorriso : UPDATE : .. blocks read in ... seconds , ...xC
but any other text output might be of interest.)

The same run with the DVD might show significant differences.


Have a nice day :)

Thomas

Re: PPC64 install && Firefox

[John Paul Adrian Glaubitz]

On Mon, 2024-04-08 at 19:38 +1200, Mike Hosken wrote:
> I used debian-12.0.0-ppc64-NETINST.iso with the date 2023-05-16.
> I downloaded this from cdimage.debian.org. When I burned it to a
> cd it didn’t boot. When I tried a dvd it did boot. I’m assuming
> that it’s the latest image.

There were 15 images released after that one:

> https://cdimage.debian.org/cdimage/ports/snapshots/

Not sure why you thought it's the latest one.

> I ended up doing 6 installations overall, for testing purposes and it worked 
> well. 
> 
> As for Firefox thanks for the info, hopefully it will get fixed as it would 
> make
> ppc64 still very useable in this modern era. 

Well, someone interested in Firefox on big-endian targets would have to take a 
look
at it. I currently don't have the time for it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: PPC64 install && Firefox

[Mike Hosken]

Hi Adrian,

I used debian-12.0.0-ppc64-NETINST.iso with the date 2023-05-16. I downloaded 
this from cdimage.debian.org. When I burned it to a cd it didn’t boot. When I 
tried a dvd it did boot. I’m assuming that it’s the latest image.  I ended up 
doing 6 installations overall, for testing purposes and it worked well. 

As for Firefox thanks for the info, hopefully it will get fixed as it would 
make ppc64 still very useable in this modern era. 


> On 8 Apr 2024, at 19:09, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hello,
> 
>> On Mon, 2024-04-08 at 17:19 +1200, Mike Hosken wrote:
>> I just wanted to give some feedback on the install of ppc64 on a Mac G5.
>> 
>> I had a few issues when installing the latest version.
> 
> Which image did you use? The latest snapshot image is known to not boot on
> PowerMac G5, so I'm doubtful you were actually using the latest 
> 
>> Grub install fails when not installing standard system utilities through
>> tasksel during installation. I’m not sure if packages are required for ppc64
>> grub install from standard system utilities but I thought I’d mention it.
> 
> Without knowing what image was used, I cannot really comment here.
> 
>> During installation, upgrading via ports archive dpkg throws up an error with
>> the start stop daemon not being able to write to the directory. After 
>> installation
>> upon reboot dpkg is broken because of this. The fix was simple and upon 
>> reinstall
>> dpkg works as expected.
> 
> I have run into this issue during a test installation as well, but I have not 
> figured
> out yet what the problem is.
> 
>> I installed xfce and noticed Firefox failed to launch with segmentation 
>> errors also
>> the esr version does the same. Upon further research I discovered others 
>> also have
>> this problem.
> 
> The Firefox issue is a known upstream bug:
> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1845669
> 
>> I tried building both versions from Sid but they both failed to build. Is 
>> there a fix for this issue ?
> 
> Both firefox and firefox-esr built successfully on ppc64 16 days ago:
> 
>> https://buildd.debian.org/status/fetch.php?pkg=firefox=ppc64=124.0.1-1=1711164847=0
>> https://buildd.debian.org/status/fetch.php?pkg=firefox=ppc64=124.0.1-1=1711164847=0
> 
>> I’d like to thank the maintainers for keeping the ports going on 20 year old 
>> hardware.
> 
> You're welcome. I'm glad my work is useful to others.
> 
> Adrian
> 
> --
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: PPC64 install && Firefox

[John Paul Adrian Glaubitz]

Hello,

On Mon, 2024-04-08 at 17:19 +1200, Mike Hosken wrote:
> I just wanted to give some feedback on the install of ppc64 on a Mac G5. 
> 
> I had a few issues when installing the latest version. 

Which image did you use? The latest snapshot image is known to not boot on
PowerMac G5, so I'm doubtful you were actually using the latest version.

> Grub install fails when not installing standard system utilities through
> tasksel during installation. I’m not sure if packages are required for ppc64
> grub install from standard system utilities but I thought I’d mention it.

Without knowing what image was used, I cannot really comment here.

> During installation, upgrading via ports archive dpkg throws up an error with
> the start stop daemon not being able to write to the directory. After 
> installation
> upon reboot dpkg is broken because of this. The fix was simple and upon 
> reinstall
> dpkg works as expected.

I have run into this issue during a test installation as well, but I have not 
figured
out yet what the problem is.

> I installed xfce and noticed Firefox failed to launch with segmentation 
> errors also
> the esr version does the same. Upon further research I discovered others also 
> have
> this problem.

The Firefox issue is a known upstream bug:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1845669

> I tried building both versions from Sid but they both failed to build. Is 
> there a fix for this issue ? 

Both firefox and firefox-esr built successfully on ppc64 16 days ago:

> https://buildd.debian.org/status/fetch.php?pkg=firefox=ppc64=124.0.1-1=1711164847=0
> https://buildd.debian.org/status/fetch.php?pkg=firefox=ppc64=124.0.1-1=1711164847=0

> I’d like to thank the maintainers for keeping the ports going on 20 year old 
> hardware. 

You're welcome. I'm glad my work is useful to others.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

PPC64 install && Firefox

[Mike Hosken]

Hi everyone,

I just wanted to give some feedback on the install of ppc64 on a Mac G5. 

I had a few issues when installing the latest version. 

Grub install fails when not installing standard system utilities through 
tasksel during installation. I’m not sure if packages are required for ppc64 
grub install from standard system utilities but I thought I’d mention it. 

During installation, upgrading via ports archive dpkg throws up an error with 
the start stop daemon not being able to write to the directory. After 
installation upon reboot dpkg is broken because of this. The fix was simple and 
upon reinstall dpkg works as expected. 

I installed xfce and noticed Firefox failed to launch with segmentation errors 
also the esr version does the same. Upon further research I discovered others 
also have this problem. I tried building both versions from Sid but they both 
failed to build. Is there a fix for this issue ? 

I’d like to thank the maintainers for keeping the ports going on 20 year old 
hardware. 

Mike Hosken 
Sent via my iPhone 

Re: Please test Firefox on ppc64

[Johannes Brakensiek]

Am Donnerstag, dem 31.08.2023 um 23:16 +0200 schrieb John Paul Adrian
Glaubitz:
> On Thu, 2023-08-31 at 23:06 +0200, John Paul Adrian Glaubitz wrote:
> > Can anyone running Debian on ppc64 please give it a try?
> 
> It might crash because of this bug:
> 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1845669
> 
> Adrian
> 

Hi Adrian,

I was just able to test it using an upgraded Debian Sid ppc64:

It crashes because of:

Thread 1 "firefox-esr" received signal SIGSEGV, Segmentation fault.
i32_load8_u (addr=2014643200, mem=) at rlbox.wasm.c:146
146 rlbox.wasm.c: Datei oder Verzeichnis nicht gefunden.

Backtrace attached.

Regards
Johannes
Thread 1 "firefox-esr" received signal SIGSEGV, Segmentation fault.
i32_load8_u (addr=2014643200, mem=) at rlbox.wasm.c:146
146	rlbox.wasm.c: Datei oder Verzeichnis nicht gefunden.

(gdb) bt
#0  i32_load8_u (addr=2014643200, mem=) at rlbox.wasm.c:146
#1  w2c_rlbox_streqci (var_p0=var_p0@entry=262000, var_p1=2014643200, instance=) at rlbox.wasm.c:925
#2  0x7fffe96bdbe8 in w2c_rlbox_getEncodingIndex (var_p0=, instance=) at rlbox.wasm.c:66394
#3  w2c_rlbox_getEncodingIndex (var_p0=262000, instance=0x7fffd89a8000) at rlbox.wasm.c:841
#4  w2c_rlbox_MOZ_XmlInitEncodingNS_0 (instance=0x7fffd89a8000, var_p0=438772, var_p1=438768, var_p2=262000) at rlbox.wasm.c:2467
#5  0x7fffe97097dc in w2c_rlbox_initializeEncoding (instance=instance@entry=0x7fffd89a8000, var_p0=var_p0@entry=438624) at rlbox.wasm.c:48421
#6  0x7fffe97cbc38 in w2c_rlbox_prologInitProcessor (instance=0x7fffd89a8000, var_p0=438624, var_p1=445808, var_p2=511344, var_p3=262140)
at rlbox.wasm.c:45429
#7  0x7fffe97dc744 in w2c_rlbox_MOZ_XML_Parse_0 (var_p3=0, var_p2=65536, var_p1=445808, var_p0=438624, instance=0x7fffd89a8000) at rlbox.wasm.c:49444
#8  w2c_rlbox_MOZ_XML_Parse (instance=0x7fffd89a8000, var_p0=438624, var_p1=445808, var_p2=65536, var_p3=0) at rlbox.wasm.c:20953
#9  0x7fffea549d30 in rlbox::rlbox_wasm2c_sandbox::impl_invoke_with_func_ptr(XML_Status (*)(unsigned int, unsigned int, int, int), unsigned int&&, unsigned int&&, unsigned int&&, bool&&) (func_ptr=, this=0x7fffd89a8000)
at ./build-browser/dist/include/mozilla/rlbox/rlbox_wasm2c_sandbox.hpp:763
#10 rlbox::rlbox_sandbox::INTERNAL_invoke_with_func_ptr&, rlbox::tainted, unsigned long, bool>(char const*, void*, rlbox::tainted&, rlbox::tainted&&, unsigned long&&, bool&&)
(func_name=, func_ptr=, this=) at ./build-browser/dist/include/mozilla/rlbox/rlbox_sandbox.hpp:790
#11 nsExpatDriver::ParseChunk(char16_t const*, unsigned int, nsExpatDriver::ChunkOrBufferIsFinal, unsigned int*, unsigned long*)
(this=0x776ee740, aBuffer=, aLength=aLength@entry=32768, aIsFinal=aIsFinal@entry=nsExpatDriver::ChunkOrBufferIsFinal::FinalChunk, aConsumed=0x7fffc21c, aLastLineLength=0x7fffc220) at ./parser/htmlparser/nsExpatDriver.cpp:1248
#12 0x7fffea54a13c in nsExpatDriver::ChunkAndParseBuffer(char16_t const*, unsigned int, bool, unsigned int*, unsigned int*, unsigned long*)
(this=this@entry=0x776ee740, aBuffer=aBuffer@entry=0x7fffdbf60020 u"\n\n

Re: Please test Firefox on ppc64

[Stan Johnson]

Hello Carsten,

On 9/3/23 11:40 AM, Carsten Jacobi wrote:
> ... I'm reluctant
> on "just trying out the new version", I'm not sure whether I'll be able
> to get back to the still working version in case the new one doesn't 
> run and just crashes.
> ...
You could create a backup before you install Firefox, then restore from
that backup if Firefox doesn't work (that's what I ended up doing). I
use Gentoo and Debian SID on my PowerMac G5 as rescue systems for each
other.

-Stan

Re: Please test Firefox on ppc64

[Stan Johnson]

Hello Adrian,

On 8/31/23 3:06 PM, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> Thanks to the efforts of Debian's Firefox maintainer, the Firefox package
> is building again on ppc64 (big-endian) the first time in a long period.
> 
> However, we don't know whether Firefox actually works on 64-bit Big-Endian
> PowerPC.
> 
> Can anyone running Debian on ppc64 please give it a try?
> 
> Thanks,
> Adrian
> 

On a PowerMac G5 with 8 GB memory, I updated to the latest Debian SID,
then I installed firefox ("apt-get install firefox"). It had a
segmentation fault when I ran it from the command line (Firefox did not
automatically run when I clicked on the Web Browser icon in xfce4).

I wasn't able to use vmlinux-6.4.0-4-powerpc64, since that kernel
doesn't support nVidia cards (I used a custom 6.5.1 kernel that worked).

-Stan

Re: Please test Firefox on ppc64

[Carsten Jacobi]

Hello,

I'm running firefox on 64-bit Big-Endian and am till current date stuck 
on these packages:


ii  firefox  85.0.1-1    ppc64    Mozilla Firefox 
web browser
ii  firefox-esr  78.14.0esr-1+b1 ppc64    Mozilla Firefox 
web browser - Extended Support Release (ESR)


Since there was no stable update path after those packages I did 
everything possible to stay
on these versions to have a working browser available on my system. 
That's why I'm reluctant
on "just trying out the new version", I'm not sure whether I'll be able 
to get back to the still

working version in case the new one doesn't run and just crashes.

For some time there was also the "epiphany" web browser available as an 
alternative
web-browser with JavaScript support (though I hate JavaScript, but many 
Web-Pages
nowadays require it). But also here the last version I had crashed 
constantly and I can't
try out a newer version as this would break the dependency chain for the 
still working

version of firefox I still have …

Regards,

Carsten

Am 31.08.23 um 23:06 schrieb John Paul Adrian Glaubitz:

Hi!

Thanks to the efforts of Debian's Firefox maintainer, the Firefox package
is building again on ppc64 (big-endian) the first time in a long period.

However, we don't know whether Firefox actually works on 64-bit Big-Endian
PowerPC.

Can anyone running Debian on ppc64 please give it a try?

Thanks,
Adrian

Re: Please test Firefox on ppc64

[Michael Cree]

On Thu, Aug 31, 2023 at 11:16:01PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-08-31 at 23:06 +0200, John Paul Adrian Glaubitz wrote:
> > Can anyone running Debian on ppc64 please give it a try?
> 
> It might crash because of this bug:
> 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1845669

Just installed and given firefox 117.0-1 a spin on ppc64.  It segfaults
on startup.  Not sure if that is the bug you reference.  I can try to
get a backtrace.  Hmm the debugging symbols file is massive and gdb is
already up to 85% memory and swap used. Still loading and voraciously
swapping virtual memory. Maybe another day...

Regards,
Michael.

Re: Please test Firefox on ppc64

[John Paul Adrian Glaubitz]

On Thu, 2023-08-31 at 23:06 +0200, John Paul Adrian Glaubitz wrote:
> Can anyone running Debian on ppc64 please give it a try?

It might crash because of this bug:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1845669

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Please test Firefox on ppc64

[John Paul Adrian Glaubitz]

Hi!

Thanks to the efforts of Debian's Firefox maintainer, the Firefox package
is building again on ppc64 (big-endian) the first time in a long period.

However, we don't know whether Firefox actually works on 64-bit Big-Endian
PowerPC.

Can anyone running Debian on ppc64 please give it a try?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

On Saturday, March 6, 2021, Riccardo Mottola 
wrote:
> Hi Luke,
>
>
> Luke Kenneth Casson Leighton wrote:
>>
>> just to confirm: that's definitely "setting machine to capabilities that
the machine doesn't have, then requesting that feature and gcc 10 says
'ok'" yes?
>>
>> i do not know the exact machine, let us assume it is -mg3.
>>
>> the options being passed are "gcc -mg3 -maltivec" and this should
definitely cause gcc to raise an error, is that correct?
>
> that is what the current test written by Adrian does, but I don't think
it is the best solution.

right.  ok.  so by "autoconf" test i meant creating an actual program (even
if it is a one line assembly file) and executing it.

of course that relies on native building which in debian is the default,
but, argh i just realised that "native build host" in this case will be an
IBM POWER9 system which is effectively a cross compile scenario (similar to
using aarch64 to build armhf). unless the Program Compatibility Register is
set and that... wouldn't work either

argh! :)

> So I think the safest bet still would be a hard switch to enable/disable
AltiVec builds.

yes i concur, i would however still consider this to be a bug in gcc (apart
from the 750 with/without altivec) if gcc is not excluding combinations for
which there is no known hardware.

sigh why on earth this was not placed behind dynamic runtime libraries a
long time ago, i do not fully understand.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Riccardo Mottola]

Hi Luke,


Luke Kenneth Casson Leighton wrote:


just to confirm: that's definitely "setting machine to capabilities 
that the machine doesn't have, then requesting that feature and gcc 10 
says 'ok'" yes?


i do not know the exact machine, let us assume it is -mg3.

the options being passed are "gcc -mg3 -maltivec" and this should 
definitely cause gcc to raise an error, is that correct?


that is what the current test written by Adrian does, but I don't think 
it is the best solution.


Whould we really get an error? In the case of the g3 I don't think so, 
strictly speaking.


I did test
-mcpu=750 -mtune=750 -maltivec

And I do not get an error. However, CPUs with a 750 core and altivec do 
exist, even if they were not officially mounted in Mac, they were used 
elsewhere and perhaps upgrade boards exist (PPC 750 VX).

I might test with cores that impossibly can have AltiVec, like G2 cores

So I think the safest bet still would be a hard switch to enable/disable 
AltiVec builds.


Riccardo

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

On Tuesday, March 2, 2021, Luke Kenneth Casson Leighton 
wrote:
>
>
> On Tuesday, March 2, 2021, Riccardo Mottola 
wrote:
>
>> actually the original point is even for PPC32, note just PPC64. The
>> configure check added by Adrian in Firefox checks if the compiler
>> accepts -maltivec and just enables it in the build.
>> However, this assumption is not correct and causes issues as explained
>> in my previous mail.
>
> ouch.  seems like an autoconf test is needed, at least.  and an upstream
bugreport to gcc.
>
> just to confirm: that's definitely "setting machine to capabilities that
the machine doesn't have, then requesting that feature and gcc 10 says
'ok'" yes?
>
> i do not know the exact machine, let us assume it is -mg3.
>
> the options being passed are "gcc -mg3 -maltivec" and this should
definitely cause gcc to raise an error, is that correct?

or, is it:

* just -mnoaltivec
* no specific setting of machine type
* VMX instructions still get introduced

whilst i do not know if gcc rejects inline VSX assembly if -mnoaltivec is
given, i have a sneaking suspicion that this could be something not to do
with gcc itself but with e.g. recent libc6 proliferation of inline assembly
variants of functions such as strncpy.

are you able to send a gdb stacktrace here to the list and also a disasm
dump at the PC showing which instruction is being attempted?

this will tell us what function is going awry and we can then ping the
right people.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

On Tuesday, March 2, 2021, Riccardo Mottola 
wrote:

> actually the original point is even for PPC32, note just PPC64. The
> configure check added by Adrian in Firefox checks if the compiler
> accepts -maltivec and just enables it in the build.
> However, this assumption is not correct and causes issues as explained
> in my previous mail.

ouch.  seems like an autoconf test is needed, at least.  and an upstream
bugreport to gcc.

just to confirm: that's definitely "setting machine to capabilities that
the machine doesn't have, then requesting that feature and gcc 10 says
'ok'" yes?

i do not know the exact machine, let us assume it is -mg3.

the options being passed are "gcc -mg3 -maltivec" and this should
definitely cause gcc to raise an error, is that correct?

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

SIMD not present in Libre/Open hardware OpenPOWER implementations [was Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)]

[Luke Kenneth Casson Leighton]

changing subject, for reference / background:

* Paul Mackerras is working on an experimental branch to add VSX
 https://github.com/paulusmack/microwatt/blob/vecvsx/decode1.vhdl
 he was experimenting to see what was needed to get Fedora booting.  the
internal design is a Finite State Machine.  multiple clocks per instruction
(due to internal 64 bit pathways)

* neither A2I nor A2O have VSX and an estimate for adding it to these
high-performance gate-level designs would be around 2 years
https://github.com/openpower-cores/a2o
https://github.com/openpower-cores/a2i

* LibreSOC we are just not going to add VSX. the development cost is far
too high, the performance nowhere near that of Vectors, software complexity
far too high and L1 cache usage is compromised.
http://git.libre-soc.org

all of these designs - all four - have internal 64 bit pathways.  OpenPOWER
instruction decoding is complex even without SIMD (4,000 gates) and adding
VSX multiplies that by three or four.  that's enough gates to do a decent
embedded RISC core in any other RISC ISA.

IBM had years in which to incrementally extend SIMD operations.  Jeffrey in
another post kindly outlines the progression.

now, at POWER10 with 18 billion transistors, the barrier to entry is so
high that if someone doesn't put their foot down and say "no" to SIMD there
isn't going to *be* any new OpenPOWER hardware other than that from IBM
[not, at least, capable of running standard ppc64le distros that is]

we seriously considered doing an entirely new ppc64le-eabi-1.5/1.9 Debian
Distro port at one point, going *backwards* to the time when SIMD was not
mandatory but doing LE rather than BE, but the risk of it being viewed in
the same way as "rasbian" is too great.


On Tuesday, March 2, 2021, Riccardo Mottola 
wrote:

>
> Emulation at kernel level is painfully slow,

seriously, i kid you not, it is infinitely better than trying to implement
VSX in hardware.  we would spend so long implementing it that it would
delay LibreSOC *beyond* the point where money from NLnet was available,
jeapordising the entire project in the process.

given a choice between "painfully slow right now but fixable in software
later" and "completely destroying any chance of completing and delivering
even any hardware at all" it's hardly a choice :)

the Cray-style Vectorisation being added will smoke SIMD in the long run,
once the ABIs and compilers are sorted.


> yes enabling runtime libraries could be done, requires extensive work in
> upstream code.

this is a better situation than an entire new distro port.  we may have to
have one anyway: all timescale estimates which start from defining a new
triplet and going from there are around 3-5 years.

if a new EABI has to be defined and spec'd as well it's even longer.

> An easier version is the path that TenFourFox and other follow: just
> provide two binaries, which is what I intend to do with ArcticFox.
> However if Debian wants to come up with the pain of two (or more?) FF
> packages

deep breath, this may be a sane medium term solution.  long term the
separation of SIMD is needed behind dynamic loadable libraries (and HWCAPS
in glibc6) rather than assuming it is 100% guaranteed available.

LibreSOC in particular needs to appear to go *backwards* in terms of
performance before it can go forwards, once the Cray-style Vectorisation
hits gcc properly.

then other hardware can also do variants of the same libraries (including
POWER9/10).


On Tuesday, March 2, 2021, Jeffrey Walton  wrote:

> Based on my experience with Botan and Crypto++... VSX is available
> with POWER7 and -mvsx compiler option. VSX is part of POWER8 core and
> does not need a compiler option.

as demonstrated by A2O/I in particular there is unfortunately a problem
with referring to IBM proprietary processor names as the canonical
definition of available features: A2I/O are Power v2.06/7 compliant but
*still do not have VSX*.

this is because the feature is optional except by the time you get to the
AIX Compliancy Subset.  see v3.0C or v3.1 first few pages, copy easily
available at http://ftp.libre-soc.org

note that it really does say "SIMD is optional" for Linux/UNIX subset,
Floating Point Embedded subset and Fixed Point subset.

many people misinterpret / misread that document including myself for
several months.

this conflation is caused by the fact that only IBM processors, which
happen to go by proprietary names POWER7-10, are commonly available.  NXP
Quorl, not so well known, which is v2.08B compliant, used in the PowerPC
Notebook, is going EOL.


> VSX is a lot like Intel tic/toc features. VSX allows a 64-bit vector
> loads and stores, but it does not provide operations on 64-bit
> vectors. You have to use POWER8 to get the 64-bit add (addudm),
> subtract (subudm), etc.

this illustrates very nicely the progression over time (many years) as the
team inside IBM ramped up the capabilities.

we can see very unfortunately that they too were seduced by what SIMD 

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Riccardo Mottola]

Hi Luke,


Luke Kenneth Casson Leighton wrote:
>
> 1.5 and 1.9 never had SIMD / VMX / VSX so there shouldn't be a problem
> (for G5).
>
> which, coming back to the original question, i'm not seeing a reason
> why disabling altivec should not compile.
>
> unless, of course, there have been assumptions "#ifdef PPC64 equals
> POWER9 therefore VSX" which are unfortunately creeping in ever since
> EABI 2.0 came about?

actually the original point is even for PPC32, note just PPC64. The
configure check added by Adrian in Firefox checks if the compiler
accepts -maltivec and just enables it in the build.
However, this assumption is not correct and causes issues as explained
in my previous mail.

Riccardo

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Riccardo Mottola]

Hi Gabriel,


Gabriel Paubert wrote:
> This is going to be hopelessly slow. The point of SIMD is to process
> quickly vast amounts of data, the overhead of every single emulated
> instructions is counted in hundreds of cycles.
>
> IMHO, the only solution is to:
> a) only use SIMD in library code
> b) compile 2 or 3 versions of libraries: no SIMD, VMX and/or VSX
> c) put each library in a different directory
> d) at run time, select the path to load the libraries from CPU
>capabilities

Emulation at kernel level is painfully slow, like FPU emulation - while
here you want maximum speed for that code. Already not having vector
instructions is a penalty, but an optimized build can still be usable.

yes enabling runtime libraries could be done, requires extensive work in
upstream code.

An easier version is the path that TenFourFox and other follow: just
provide two binaries, which is what I intend to do with ArcticFox.
However if Debian wants to come up with the pain of two (or more?) FF
packages

Riccardo

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Riccardo Mottola]

Hi,

Riccardo Mottola wrote:
>
> This causes a big issue if you want to compile a non-Altivec build on
> a capable processor like the G4: it will automatically enabled even if
> you don't want.
> E.g. if I want to build on a G4 a binary working on the G3, I can't. I
> specify -mcpu=750 -mtune=750, but the compiler will accept -maltivec
> and create an incompatible binary. 

I actually just tested and "debian shipped firefox" fires an illegal
instruction on a G3, so it is having a similar issue than my own
ArcticFox builds.

I also did a test and tried to compile on my G3 (and yes, it is an old
iBook which has a classic non-altivec 750 PPC, GX if I am right) and
-maltivec gets just accepted by gcc 10 now.

So, essentially Adrian's patch is wrong in concept: you cannot use the
compiler even on a native CPU to test for altivec

This means double-issue: using a higher-spec'd CPU cannot be used to
compile for a lower-spec, but also a native build will fail.

I would try to follow to possibilities:
- just a "hard switch" like --enable-altivec --disable-altivec for PCP
- try to parse the optimization flas one might extra use, so if the
compiler is invoked with "gcc -maltivec" (common practive) a
HAVE_ALTIVEC build is automatically enabled

What do you think?

Riccardo

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Jeffrey Walton]

On Mon, Mar 1, 2021 at 3:39 AM Gabriel Paubert  wrote:
>
> On Sun, Feb 28, 2021 at 11:52:12PM +, Luke Kenneth Casson Leighton wrote:
> > On Monday, March 1, 2021, Riccardo Mottola 
> > wrote:
> > ...
> > Tulio Magno Quites Machado Filho is currently working on glibc6 patches
> > which reverse these erroneous assumptions, replacing them with "#ifdef VSX"
> > thus allowing people to compile code that does not rely on SIMD.
>
> Beware that VSX is not Altivec. Altivec was called VMX by IBM and
> VSX is a superset of Altivec (IIRC).

Based on my experience with Botan and Crypto++... VSX is available
with POWER7 and -mvsx compiler option. VSX is part of POWER8 core and
does not need a compiler option.

VSX is a lot like Intel tic/toc features. VSX allows a 64-bit vector
loads and stores, but it does not provide operations on 64-bit
vectors. You have to use POWER8 to get the 64-bit add (addudm),
subtract (subudm), etc.

So a POWER7+VSX 64-bit add might look like:

typedef __vector unsigned intuint32x4_p;
typedef __vector unsigned long long uint64x2_p;

# Load 64-bit vector from uint64_t[2]
uint64x2_p a = vec_ld(...);
uint64x2_p b = vec_ld(...);

# But still perform the 32-bit add
uint64x2_p c = (uint64x2_p )VecAdd64((uint32x4_p)a, (uint32x4_p)b);

And:

uint32x4_p
VecAdd64(const uint32x4_p vec1, const uint32x4_p vec2)
{
// The carry mask selects carry's for elements 1 and 3 and sets
// remaining elements to 0. The result is then shifted so the
// carried values are added to elements 0 and 2.
#if defined(MYLIB_BIG_ENDIAN)
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {0, 1, 0, 1};
#else
const uint32x4_p zero = {0, 0, 0, 0};
const uint32x4_p mask = {1, 0, 1, 0};
#endif

uint32x4_p cy = vec_addc(vec1, vec2);
uint32x4_p res = vec_add(vec1, vec2);
cy = vec_and(mask, cy);
cy = vec_sld (cy, zero, 4);
return vec_add(res, cy);
}

 A POWER8 add looks as expected:

uint64x2_p
VecAdd64(const uint64x2_p vec1, const uint64x2_p vec2)
{
return vec_add(a, b);
}

Even with the crippled 64-bit add using 32-bit elements, some
algorithms, like Bernstein's ChaCha, runs about 2.5x faster than over
the scalar unit.

Jeff

enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

On Monday, March 1, 2021, Gabriel Paubert  wrote:
> On Mon, Mar 01, 2021 at 12:22:22PM +, Luke Kenneth Casson Leighton
wrote:
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Mon, Mar 1, 2021 at 8:39 AM Gabriel Paubert  wrote:
>>
>> > Beware that VSX is not Altivec. Altivec was called VMX by IBM and
>> > VSX is a superset of Altivec (IIRC).
>> >
>> > G4 and G5 do not have VSX.
>>
>> apologies i tend to lump these together.
>>
>> > This is going to be hopelessly slow.
>>
>> great!  i have absolutely no problem with that, at all.  the idea is
>> to give people access to something where due to the ongoing cascading
>> mistaken assumptions "nobody has any hardware except IBM POWER9 and
>> EABI 2.0 says VSX therefore #ifdef POWER9 --> enable VSX".
>>
>> it's a stopgap measure that at least allows... _something_.  breathing
>> space whilst the OpenPOWER Foundation puts together a plan.
>>
>> > The point of SIMD is to process quickly vast amounts of data,
>>
>> that was its seductive intent.  the reality is very different,
>> poisoning L1 I-Cache through massive bloating of program size, and in
>> some cases actually causing such heavy internal bus contention between
>> instruction and data reads that all processing grinds to a halt.
>>
>> https://www.sigarch.org/simd-instructions-considered-harmful/
>
> This publications claims (and probably rightly) that vector instructions
> are preferable to SIMD, but does not say at all that falling back to
> purely scalar is better.

i appreciate this is a side-track: LibreSOC is introducing a concept of
Cray-style "hardware for-loops" around the scalar ISA.  with gcc
autovectorisation the seemingly-scalar c code becomes as fast as the
hardware has available parallel ALUs.  hence the performance penalty is not
as great.

POWER9 on the other hand, if you've seen the proposed glibc6 patch to add
VSX to e.g. strncpy, it's alarming.  whilst the above article is
hypothetical, the real-world patch is a staggering 250 hand-coded assembly
instructions (the equivalent RVV is 13), dramatically reducing L1 cache
effectiveness and likely interfering with the use of memory bounds checkers
that align memory at the end of pages.

> Also, PPC SIMD has seen fewer variations than x86, which started with
> MMX (64bit), then SSE (128 bit registers, single precision only), SSE2
> (finally able to get rid of the awful x87 stacked registers) and so many
> extensions that I agree that it is impossible to track.

indeed.  all that is gone with Cray-style Vectors.


> Hmmm, G5 is BE only. No way to run LE, G4 and older are 32 bit BE (they
> could run LE also, but it's not easy).
>

understood.  ok so EABI 2.0 is out of the running, and EABI 1.9 is the
64-bit upgrade of 1.5, which is what debian-ppc64 (be) is based on.

1.5 and 1.9 never had SIMD / VMX / VSX so there shouldn't be a problem (for
G5).

which, coming back to the original question, i'm not seeing a reason why
disabling altivec should not compile.

unless, of course, there have been assumptions "#ifdef PPC64 equals POWER9
therefore VSX" which are unfortunately creeping in ever since EABI 2.0 came
about?

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Gabriel Paubert]

On Mon, Mar 01, 2021 at 12:22:22PM +, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Mon, Mar 1, 2021 at 8:39 AM Gabriel Paubert  wrote:
> 
> > Beware that VSX is not Altivec. Altivec was called VMX by IBM and
> > VSX is a superset of Altivec (IIRC).
> >
> > G4 and G5 do not have VSX.
> 
> apologies i tend to lump these together.
> 
> > This is going to be hopelessly slow.
> 
> great!  i have absolutely no problem with that, at all.  the idea is
> to give people access to something where due to the ongoing cascading
> mistaken assumptions "nobody has any hardware except IBM POWER9 and
> EABI 2.0 says VSX therefore #ifdef POWER9 --> enable VSX".
> 
> it's a stopgap measure that at least allows... _something_.  breathing
> space whilst the OpenPOWER Foundation puts together a plan.
> 
> > The point of SIMD is to process quickly vast amounts of data,
> 
> that was its seductive intent.  the reality is very different,
> poisoning L1 I-Cache through massive bloating of program size, and in
> some cases actually causing such heavy internal bus contention between
> instruction and data reads that all processing grinds to a halt.
> 
> https://www.sigarch.org/simd-instructions-considered-harmful/

This publications claims (and probably rightly) that vector instructions
are preferable to SIMD, but does not say at all that falling back to
purely scalar is better.

Also, PPC SIMD has seen fewer variations than x86, which started with
MMX (64bit), then SSE (128 bit registers, single precision only), SSE2
(finally able to get rid of the awful x87 stacked registers) and so many
extensions that I agree that it is impossible to track. 

At least for PPC until now, it has been 128 bit registers, always.
> 
> 
> > the overhead of every single emulated
> > instructions is counted in hundreds of cycles.
> 
> > IMHO, the only solution is to:
> > a) only use SIMD in library code
> > b) compile 2 or 3 versions of libraries: no SIMD, VMX and/or VSX
> 
> this requires going backwards to EABI 1.5.  EABI 2.0 as currently
> defined *makes SIMD mandatory*.
> 
> given that debian PPC64 is BE EABI 1.5 but PPC64LE is LE EABI 2.0 i
> don't see how that's workable.

Hmmm, G5 is BE only. No way to run LE, G4 and older are 32 bit BE (they
could run LE also, but it's not easy).


> 
> unless you create a new triplet PPC64-LE-using-EABI-1.5
> 

I don't think so, stay with BE.

> also: multilib and it is being ripped out from distros.
> 
> > c) put each library in a different directory
> > d) at run time, select the path to load the libraries from CPU
> >capabilities
> 
> this is multiarch i believe.  it requires, as i recall, a
> syscall-level understanding of the two ABIs.  with ppc64 being BE and
> ppc64le being LE this would require word-order swapping at the syscall
> level.

You have to be BE anyway (kernel and userspace) to support the oldest 64
bit processors. The switch to LE occured during Power7, but I believe
that real official distro support only happened with Power8.  

Locating libraries at program startup is done by ld.so, not by the kernel.


Gabriel
 

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Mar 1, 2021 at 8:39 AM Gabriel Paubert  wrote:

> Beware that VSX is not Altivec. Altivec was called VMX by IBM and
> VSX is a superset of Altivec (IIRC).
>
> G4 and G5 do not have VSX.

apologies i tend to lump these together.

> This is going to be hopelessly slow.

great!  i have absolutely no problem with that, at all.  the idea is
to give people access to something where due to the ongoing cascading
mistaken assumptions "nobody has any hardware except IBM POWER9 and
EABI 2.0 says VSX therefore #ifdef POWER9 --> enable VSX".

it's a stopgap measure that at least allows... _something_.  breathing
space whilst the OpenPOWER Foundation puts together a plan.

> The point of SIMD is to process quickly vast amounts of data,

that was its seductive intent.  the reality is very different,
poisoning L1 I-Cache through massive bloating of program size, and in
some cases actually causing such heavy internal bus contention between
instruction and data reads that all processing grinds to a halt.

https://www.sigarch.org/simd-instructions-considered-harmful/


> the overhead of every single emulated
> instructions is counted in hundreds of cycles.

> IMHO, the only solution is to:
> a) only use SIMD in library code
> b) compile 2 or 3 versions of libraries: no SIMD, VMX and/or VSX

this requires going backwards to EABI 1.5.  EABI 2.0 as currently
defined *makes SIMD mandatory*.

given that debian PPC64 is BE EABI 1.5 but PPC64LE is LE EABI 2.0 i
don't see how that's workable.

unless you create a new triplet PPC64-LE-using-EABI-1.5

also: multilib and it is being ripped out from distros.

> c) put each library in a different directory
> d) at run time, select the path to load the libraries from CPU
>capabilities

this is multiarch i believe.  it requires, as i recall, a
syscall-level understanding of the two ABIs.  with ppc64 being BE and
ppc64le being LE this would require word-order swapping at the syscall
level.

l.

Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Gabriel Paubert]

On Sun, Feb 28, 2021 at 11:52:12PM +, Luke Kenneth Casson Leighton wrote:
> On Monday, March 1, 2021, Riccardo Mottola 
> wrote:
> 
> > A quick solution would to have this configure as a convenience, but have
> a way to pass an --enable-altivec and -disable-altivec (or with/without?)
> parameter to configure.
> 
> EABI v2.0 rather unfortunately, despite it being optional in the OpenPOWER
> Compliancy Suite, made SIMD mandatory.
> 
> EABI v1.5 does not require SIMD.
> 
> the problem is that the assumption "#ifdef POWER9" is bleeding through to
> many code repositories.
> 
> Tulio Magno Quites Machado Filho is currently working on glibc6 patches
> which reverse these erroneous assumptions, replacing them with "#ifdef VSX"
> thus allowing people to compile code that does not rely on SIMD.

Beware that VSX is not Altivec. Altivec was called VMX by IBM and
VSX is a superset of Altivec (IIRC).

G4 and G5 do not have VSX. 

> 
> unfortunately it is somewhat a lost cause because of the mistake made in
> EABI v2.  modifying EABI v2 to make SIMD optional is no longer possible
> because it would break backwards compatibility, the only option being to
> create a new triplet, then an entire new distro port, and that is a 3 to 5
> year process.
> 
> an alternative solution is to have a kernel-level emulator of SIMD
> instructions.
> https://bugs.libre-soc.org/show_bug.cgi?id=602

This is going to be hopelessly slow. The point of SIMD is to process
quickly vast amounts of data, the overhead of every single emulated
instructions is counted in hundreds of cycles.

IMHO, the only solution is to:
a) only use SIMD in library code
b) compile 2 or 3 versions of libraries: no SIMD, VMX and/or VSX
c) put each library in a different directory
d) at run time, select the path to load the libraries from CPU
   capabilities

There is a precedent for this in the x86 world, where there were i386
and i686 directories to support the PPro. It is still the case on the
machines where I have to install 32 bit libraries:

$ locate libx264.so
/usr/lib/i386-linux-gnu/i686/sse2/libx264.so.155
/usr/lib/i386-linux-gnu/libx264.so.155
/usr/lib/x86_64-linux-gnu/libx264.so.155

There are two 32 bit versions of the libx264, one for old processors and
one for processors with sse2.

Regards,
Gabriel


> 
> fascinatingly there is precedent for this in the form of sstep.c which
> triggers from illegal instruction trap and emulates some parts of the
> OpenPOWER ISA.
> 
> l.
> 
> 
> -- 
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
 

enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Luke Kenneth Casson Leighton]

On Monday, March 1, 2021, Riccardo Mottola 
wrote:

> A quick solution would to have this configure as a convenience, but have
a way to pass an --enable-altivec and -disable-altivec (or with/without?)
parameter to configure.

EABI v2.0 rather unfortunately, despite it being optional in the OpenPOWER
Compliancy Suite, made SIMD mandatory.

EABI v1.5 does not require SIMD.

the problem is that the assumption "#ifdef POWER9" is bleeding through to
many code repositories.

Tulio Magno Quites Machado Filho is currently working on glibc6 patches
which reverse these erroneous assumptions, replacing them with "#ifdef VSX"
thus allowing people to compile code that does not rely on SIMD.

unfortunately it is somewhat a lost cause because of the mistake made in
EABI v2.  modifying EABI v2 to make SIMD optional is no longer possible
because it would break backwards compatibility, the only option being to
create a new triplet, then an entire new distro port, and that is a 3 to 5
year process.

an alternative solution is to have a kernel-level emulator of SIMD
instructions.
https://bugs.libre-soc.org/show_bug.cgi?id=602

fascinatingly there is precedent for this in the form of sstep.c which
triggers from illegal instruction trap and emulates some parts of the
OpenPOWER ISA.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)

[Riccardo Mottola]

Hello,

I was checkin gout a specific patch Adrian made for Firefox, which 
should help building on non-Altivec capable CPUs.

https://github.com/mozilla/gecko-dev/commit/c6b39f0f902898988ca7793af56307640ff81362

I have imported it in ArcticFox with this commit and tested it.
https://github.com/rmottola/Arctic-Fox/commit/1e3eb367dcfd6c9f61c738443b7967aa5fd7dae9

This configure tests relies on the fact that the compiler will throw 
an error if -maltivec is used and not supported.


This causes a big issue if you want to compile a non-Altivec build on 
a capable processor like the G4: it will automatically enabled even if 
you don't want.
E.g. if I want to build on a G4 a binary working on the G3, I can't. I 
specify -mcpu=750 -mtune=750, but the compiler will accept -maltivec 
and create an incompatible binary.


A quick solution would to have this configure as a convenience, but 
have a way to pass an --enable-altivec and -disable-altivec (or 
with/without?) parameter to configure.


I am not even sure if it is still true that the compiler will reject 
the option, I will test on my G3.


Another proposal would be to parse the CFLAGS and check if -maltivec 
was specified and thus enable HAVE_ALTIVEC



Other proposals? Let's discuss.


Riccardo

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 3/7/19 8:21 AM, Dennis Clarke wrote:
> Ha.  Let's not drag the SPARC world into this. In my opinion, based on
> some twenty years of observational data, the only problem with SPARC
> based systems is that they are horribly slow and run horribly hot while
> costing horrible amounts of money. Other than that it is a fantastic
> architecture.   :-)

Slow? The SPARC T5 we have in Debian Ports is eight or nine years old
and is still one of the fastest machines we have in the whole of Debian.

But that was not my point: My point is to ask users to fix bugs upstream
so everyone profits from the fixes and don't keep your fixes local.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: News about Firefox for PowerPC

[Dennis Clarke]

On 3/6/19 12:34 PM, John Paul Adrian Glaubitz wrote:
> On 3/6/19 5:52 AM, Dennis Clarke wrote:
>> So would it be of value for me to fire up Debian buster or sid on a
>> PowerMac G5 here and do some testing?  Not sure where you are getting
>> your Firefox from.  Also is that the nightly builds?
> 
> We're building stock Debian packages from unstable. Debian has a "firefox"
> and a "firefox-esr" package, both maintained by Mike Hommey who is also
> an engineer working at Mozilla.
> 
>> I currently am
>> running 67.0a1 where about:buildconfig claims :
>>
>> https://hg.mozilla.org/mozilla-central/rev/78601cacfe69dc8659c3fe7cd3eb94366aa3d680
>>
>> Is this similar to Firefox for PowerPC ?
> 
> There is no "Firefox for PowerPC". Again, I'm not building packages manually
> for powerpc/ppc64. All packages you are getting for powerpc and ppc64 are
> automatically built from what's in the Debian archive for Debian unstable.
> 
> Any bug fixes should therefore either go to the corresponding Debian package,
> or even better, forwarded upstream. Keeping fixes in local repositories 
> specifically
> for powerpc or ppc64 is a very bad idea because those fixes will have to be 
> carried
> around indefinitely. You will always want to upstream everything to make sure
> everyone gets those fixes.
> 
> And if something crashes on SPARC, for example, there is a chance the bug also
> affects x86, just in a more subtle way.

Ha.  Let's not drag the SPARC world into this. In my opinion, based on
some twenty years of observational data, the only problem with SPARC
based systems is that they are horribly slow and run horribly hot while
costing horrible amounts of money. Other than that it is a fantastic
architecture.   :-)


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 3/6/19 5:52 AM, Dennis Clarke wrote:
> So would it be of value for me to fire up Debian buster or sid on a
> PowerMac G5 here and do some testing?  Not sure where you are getting
> your Firefox from.  Also is that the nightly builds?

We're building stock Debian packages from unstable. Debian has a "firefox"
and a "firefox-esr" package, both maintained by Mike Hommey who is also
an engineer working at Mozilla.

> I currently am
> running 67.0a1 where about:buildconfig claims :
> 
> https://hg.mozilla.org/mozilla-central/rev/78601cacfe69dc8659c3fe7cd3eb94366aa3d680
> 
> Is this similar to Firefox for PowerPC ?

There is no "Firefox for PowerPC". Again, I'm not building packages manually
for powerpc/ppc64. All packages you are getting for powerpc and ppc64 are
automatically built from what's in the Debian archive for Debian unstable.

Any bug fixes should therefore either go to the corresponding Debian package,
or even better, forwarded upstream. Keeping fixes in local repositories 
specifically
for powerpc or ppc64 is a very bad idea because those fixes will have to be 
carried
around indefinitely. You will always want to upstream everything to make sure
everyone gets those fixes.

And if something crashes on SPARC, for example, there is a chance the bug also
affects x86, just in a more subtle way.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: News about Firefox for PowerPC

[Dennis Clarke]

On 3/5/19 3:18 AM, John Paul Adrian Glaubitz wrote:
> On 3/5/19 8:58 AM, aggaz wrote:
>> Hello, browsing the mailing list archive I read that on December 2018
>> people with a Macintosh G5 was kindly asked to try Fedora and OpenSUSE
>> to see if their GRUB works [1].
>>
>> I was not member of the list at the time, but now I am. I have a
>> PowerMac G5 late 2005 and if this kind of help/test is still needed I
>> will give it a try.
> 
> Yes, please. And please open a new thread for that. More testing and
> reports are always welcome.

So would it be of value for me to fire up Debian buster or sid on a
PowerMac G5 here and do some testing?  Not sure where you are getting
your Firefox from.  Also is that the nightly builds?  I currently am
running 67.0a1 where about:buildconfig claims :

https://hg.mozilla.org/mozilla-central/rev/78601cacfe69dc8659c3fe7cd3eb94366aa3d680

Is this similar to Firefox for PowerPC ?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 3/5/19 8:58 AM, aggaz wrote:
> Hello, browsing the mailing list archive I read that on December 2018
> people with a Macintosh G5 was kindly asked to try Fedora and OpenSUSE
> to see if their GRUB works [1].
> 
> I was not member of the list at the time, but now I am. I have a
> PowerMac G5 late 2005 and if this kind of help/test is still needed I
> will give it a try.

Yes, please. And please open a new thread for that. More testing and
reports are always welcome.

Just test things and report how it goes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: News about Firefox for PowerPC

[aggaz]

Hello, browsing the mailing list archive I read that on December 2018
people with a Macintosh G5 was kindly asked to try Fedora and OpenSUSE
to see if their GRUB works [1].

I was not member of the list at the time, but now I am. I have a
PowerMac G5 late 2005 and if this kind of help/test is still needed I
will give it a try.

[1] https://lists.debian.org/debian-powerpc/2018/12/msg00010.html

Regards
F.

Re: Enable GRUB installation for powerpc/ppc64 Macs (was: Re: News about Firefox for PowerPC)

[Mathieu Malaterre]

Hi Frank,

On Fri, Dec 21, 2018 at 10:38 PM Frank Scheiner  wrote:
>
> Hi Adrian,
>
> On 12/11/18 00:00, John Paul Adrian Glaubitz wrote:
> > @Frank: Could you repost your patches for grub-installer rebased for the 
> > current
> >  version? Maybe also include the ofpath script from the yaboot 
> > package
> >  (download from 
> > http://snapshot.debian.org/archive/debian/20160607T104140Z/pool/main/y/yaboot/yaboot_1.3.17-4.dsc).
>
> Noticed this by chance.

Just for reference, please consider using patches from:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916830

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916864

That way we'll replace yaboot/ofpath with grub-ofpathname.

Thanks much for your work !

> Although I'm subscribed to this list, I actually don't read every mail
> on it (completely) or all mails in time. Maybe better put me in TO or CC
> next time or address me directly at the beginning. Not sure if I missed
> something else, though.
>
> Thanks for your insistence :-), actually I haven't forgotten about
> enabling GRUB installation for powerpc/ppc64 Macs, but missed the time
> for it until now, as it actually requires a bigger effort. I hope I can
> bring this forward in the next weeks but I can't give a promise.
>
> In addition I plan to deviate from the patches I created in late 2017,
> maybe even start from scratch. One of the main things I want to keep out
> of d-i/grub-installer this time is the HFS stuff related to FS creation
> and such. Unfortunately this is not done by d-i/partman-newworld but was
> always done by d-i/yaboot-installer or d-i/grub-installer with my
> patches from late 2017. To fix that I plan to create a d-i/partman-hfs
> (based on d-i/partman-ext3 but adapted for hfs) which should take care
> of the FS related tasks and maybe later replace d-i/partman-newworld.
> This should shrink the amount of changes needed for d-i/grub-installer
> considerably. I also like to "save space" by focusing on successful
> operation for the simplest case possible only - i.e. empty disk or prior
> OS installation on disk is thrown away - at first, instead of trying to
> support special cases.
>
> The plan then is as follows:
>
> 1. Increase size of HFS partitions in d-i/partman-auto to 10 to 20 MB to
> prepare for future GRUB installations. More details on [1].
>
> [1]: https://salsa.debian.org/installer-team/partman-auto/merge_requests/2
>
> 2. Create d-i/partman-hfs to handle all FS related stuff for HFS
>
> 3. Patch d-i/grub-installer to support a GRUB installation for
> powerpc/ppc64 Macs for the simplest case.
>
> This time I also plan to do the development on powerpc and use ppc64 for
> verification.
>
> Cheers,
> Frank
>

Enable GRUB installation for powerpc/ppc64 Macs (was: Re: News about Firefox for PowerPC)

[Frank Scheiner]

Hi Adrian,

On 12/11/18 00:00, John Paul Adrian Glaubitz wrote:

@Frank: Could you repost your patches for grub-installer rebased for the current
 version? Maybe also include the ofpath script from the yaboot package
 (download from 
http://snapshot.debian.org/archive/debian/20160607T104140Z/pool/main/y/yaboot/yaboot_1.3.17-4.dsc).


Noticed this by chance.

Although I'm subscribed to this list, I actually don't read every mail 
on it (completely) or all mails in time. Maybe better put me in TO or CC 
next time or address me directly at the beginning. Not sure if I missed 
something else, though.


Thanks for your insistence :-), actually I haven't forgotten about 
enabling GRUB installation for powerpc/ppc64 Macs, but missed the time 
for it until now, as it actually requires a bigger effort. I hope I can 
bring this forward in the next weeks but I can't give a promise.


In addition I plan to deviate from the patches I created in late 2017, 
maybe even start from scratch. One of the main things I want to keep out 
of d-i/grub-installer this time is the HFS stuff related to FS creation 
and such. Unfortunately this is not done by d-i/partman-newworld but was 
always done by d-i/yaboot-installer or d-i/grub-installer with my 
patches from late 2017. To fix that I plan to create a d-i/partman-hfs 
(based on d-i/partman-ext3 but adapted for hfs) which should take care 
of the FS related tasks and maybe later replace d-i/partman-newworld. 
This should shrink the amount of changes needed for d-i/grub-installer 
considerably. I also like to "save space" by focusing on successful 
operation for the simplest case possible only - i.e. empty disk or prior 
OS installation on disk is thrown away - at first, instead of trying to 
support special cases.


The plan then is as follows:

1. Increase size of HFS partitions in d-i/partman-auto to 10 to 20 MB to 
prepare for future GRUB installations. More details on [1].


[1]: https://salsa.debian.org/installer-team/partman-auto/merge_requests/2

2. Create d-i/partman-hfs to handle all FS related stuff for HFS

3. Patch d-i/grub-installer to support a GRUB installation for 
powerpc/ppc64 Macs for the simplest case.


This time I also plan to do the development on powerpc and use ppc64 for 
verification.


Cheers,
Frank

Re: News about Firefox for PowerPC

[Riccardo Mottola]

Hi Christian

(removing others who will read the reply on the ML)

Christian Zigotzky wrote:
>
> Thanks for your reply. We get the error message 'Illegal instruction'
> on the X5000. That means it doesn't start. Could you please compile it
> without AltiVec (-maltivec -mabi=altivec)? 

I do not provide a binary, that must have been built by somebody else.
I was just compiling and testing for the sake of PPC! (I was further
motivated by the PowerProgressCommunity and their plans for PPC machines
https://www.powerprogress.org)

I cannot do a test build now because my iBook G4 is "out of order",
until we find a way to reinstall it. I hoped Adrian could spin out a new
ISO, otherwise I need some help or magic to boot the "bad" install the
current one creates. Right now I am just working on the Intel-side and
porting back several bugfixes from FF.

Riccardo

Re: News about Firefox for PowerPC

[Christian Zigotzky]

On 11 December 2018 at 7:04PM, Riccardo Mottola wrote:

Hi Christian!

Christian Zigotzky wrote:
Many thanks for ArcticFox! I successfully tested it on my AmigaOne 
X1000 today. (64-bit 1.8 GHz dual-core PWRficient PA6T-1682M PowerPC 
with AltiVec)


Screenshot of ArcticFox on Fienix (32-bit Debian based distribution 
with a 64-bit kernel): 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633402818128594658 



Screenshot of ArcticFox on ubuntu MATE 16.04.5 LTS 32-bit PowerPC 
with a 64-bit kernel: 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633406944852828306


Those look cool and promising!




Unfortunately it doesn't work on our AmigaOne X5000. (Freescale P5020 
CPU 2GHz, 64-bit e5500 dual-core PowerPC SoC without AltiVec)


Does it not work? build? what happens?



Did you compile it with G4/AltiVec compiler flags? 


Yes, I did:

export CC="gcc -flax-vector-conversions -O3 -mcpu=7450 -mtune=7450 
-maltivec -mabi=altivec -falign-loops=16 -falign-functions=16 
-falign-labels=16 -falign-jumps=16"
export CXX="g++ -flax-vector-conversions -fpermissive -O3 -mcpu=7450 
-mtune=7450 -maltivec -mabi=altivec -falign-loops=16 
-falign-functions=16 -falign-labels=16 -falign-jumps=16"

export LDFLAGS="-latomic"


I did not try without, I know that on Intel SSE2 is required

Riccardo


Hi Riccardo,

Thanks for your reply. We get the error message 'Illegal instruction' on 
the X5000. That means it doesn't start. Could you please compile it 
without AltiVec (-maltivec -mabi=altivec)?


Thanks,
Christian

Re: News about Firefox for PowerPC

[Riccardo Mottola]

Hi Christian!

Christian Zigotzky wrote:
Many thanks for ArcticFox! I successfully tested it on my AmigaOne 
X1000 today. (64-bit 1.8 GHz dual-core PWRficient PA6T-1682M PowerPC 
with AltiVec)


Screenshot of ArcticFox on Fienix (32-bit Debian based distribution 
with a 64-bit kernel): 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633402818128594658 



Screenshot of ArcticFox on ubuntu MATE 16.04.5 LTS 32-bit PowerPC with 
a 64-bit kernel: 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633406944852828306


Those look cool and promising!




Unfortunately it doesn't work on our AmigaOne X5000. (Freescale P5020 
CPU 2GHz, 64-bit e5500 dual-core PowerPC SoC without AltiVec)


Does it not work? build? what happens?



Did you compile it with G4/AltiVec compiler flags? 


Yes, I did:

export CC="gcc -flax-vector-conversions -O3 -mcpu=7450 -mtune=7450 
-maltivec -mabi=altivec -falign-loops=16 -falign-functions=16 
-falign-labels=16 -falign-jumps=16"
export CXX="g++ -flax-vector-conversions -fpermissive -O3 -mcpu=7450 
-mtune=7450 -maltivec -mabi=altivec -falign-loops=16 
-falign-functions=16 -falign-labels=16 -falign-jumps=16"

export LDFLAGS="-latomic"


I did not try without, I know that on Intel SSE2 is required

Riccardo

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 12/11/18 12:00 AM, John Paul Adrian Glaubitz wrote:
> On 12/10/18 6:23 PM, Riccardo Mottola wrote:
>> PS: Adrian, I hope you get out a new ISO soon, so I try reinstalling the 
>> iBook and test again :) I got the machine exactly for working on ArcticFox
> 
> The problem is that we currently don't have Yaboot in the archives which is
> required by the debian-installer package. Someone requested for Yaboot among
> other packages to be removed from the Debian FTP archive. So I will have
> to tackle this first. I'm not sure whether Yaboot still builds fine but I 
> guess
> it does. At least pmac-utils didn't build when I tried it due to issues with
> sgml2man converting the SGML files to manpages (syntax errors).

Ok, Yaboot doesn't build. It has a hard build-dependency on efslibs1.41-dev
which we don't have anymore. It doesn't build against ef2fslibs-dev.

I think Frank should re-submit his patch set to add PPC Mac support to the
grub-installer package with the patch

"[PATCH 4/5] Create and configure the missing CHRP boot script."

modified to include the "ofpath" script taken from the yaboot package directly
into the grub-installer package.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 12/10/18 6:23 PM, Riccardo Mottola wrote:
> PS: Adrian, I hope you get out a new ISO soon, so I try reinstalling the 
> iBook and test again :) I got the machine exactly for working on ArcticFox

The problem is that we currently don't have Yaboot in the archives which is
required by the debian-installer package. Someone requested for Yaboot among
other packages to be removed from the Debian FTP archive. So I will have
to tackle this first. I'm not sure whether Yaboot still builds fine but I guess
it does. At least pmac-utils didn't build when I tried it due to issues with
sgml2man converting the SGML files to manpages (syntax errors).

I wish I had the time to work on GRUB integration for powerpc and ppc64 but it's
quite some involved task due to the HFS image requirements for PPC Macs. I have
recently learned, however, that Fedora for ppc64 has support for installing
on 64-bit PowerPC Macs using syslinux for the installation media as well as
GRUB as a bootloader for the installed system. However, I haven't verified
that yet.

Thus, can someone with a 64-bit PowerPC Mac, i.e. a Macintosh G5, give it
a try and install Fedora's ppc64 port on their G5 Mac? Images can be found
here:

> https://download-ib01.fedoraproject.org/pub/fedora-secondary/releases/27/Everything/ppc64/iso/

Also, maybe give openSUSE ppc64 a spin:

> http://download.opensuse.org/ports/ppc/factory/iso/

I haven't tried either of them on a G5 Mac and would be interested to see
whether an installation is possible which would indicate these distributions
have HFS support added to syslinux and GRUB.

The first step for Debian then would be to make sure Debian's syslinux package
has support for the "macboot.img" image which is required to boot Linux with
syslinux on a PPC Mac.

The next step would be finding out what Fedora is doing to replace ofpath which
is required for grub-installer. On the other hand, I just realized that ofpath
is just a bash script and we might as well add it to the grub-installer package.

@Frank: Could you repost your patches for grub-installer rebased for the current
version? Maybe also include the ofpath script from the yaboot package
(download from 
http://snapshot.debian.org/archive/debian/20160607T104140Z/pool/main/y/yaboot/yaboot_1.3.17-4.dsc).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: News about Firefox for PowerPC

[Christian Zigotzky]

On 10 December 2018 at 6:23PM, Riccardo Mottola wrote:

Hi,

swamprock wrote:
Meanwhile, there is a fork of Pale Moon 27.x called Arctic Fox that 
can be used on 32-bit PowerPC-https://github.com/wicknix/Arctic-Fox/


More 
info:https://forums.macrumors.com/threads/arctic-fox-web-browser-for-10-6-32-64-bit.2133051/


I need to chime in, being one of the main contributors behind 
ArcticFox, although it is not directly my idea.



I had it working on Linux/PPC too and compiling with gcc 6.5 on Debian 
(you can check my fork on github in case, but it gets pulled in 
regularly). It could even play videos off you-tube although ad a 
ridiculous frame rate


If someone can help me with getting gcc7 and gcc8 working, welcome!!

Don't hold your breath on JS though: no JIT for PPC and stability is 
(still) dubious. Some other PPC enthusiasts got it compiling then also 
on PPC 64, although there were some endianness issues which did not 
happen in 32bit, there were also some stbaility issues.
I did some progress by packporting numerous fixes, but I lack 
currently the PPC machine to test it on and am working on Intel.
Right now on Intel I can use major sites: github, facebook, youtube... 
even web mail. It keeps me motivated!


Riccardo


PS: Adrian, I hope you get out a new ISO soon, so I try reinstalling 
the iBook and test again :) I got the machine exactly for working on 
ArcticFox




Hi Riccardo,

Many thanks for ArcticFox! I successfully tested it on my AmigaOne X1000 
today. (64-bit 1.8 GHz dual-core PWRficient PA6T-1682M PowerPC with AltiVec)


Screenshot of ArcticFox on Fienix (32-bit Debian based distribution with 
a 64-bit kernel): 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633402818128594658


Screenshot of ArcticFox on ubuntu MATE 16.04.5 LTS 32-bit PowerPC with a 
64-bit kernel: 
https://plus.google.com/u/0/photos/photo/115515624056477014971/6633406944852828306


Unfortunately it doesn't work on our AmigaOne X5000. (Freescale P5020 
CPU 2GHz, 64-bit e5500 dual-core PowerPC SoC without AltiVec)


Did you compile it with G4/AltiVec compiler flags?

Thanks,
Christian

Re: News about Firefox for PowerPC

[Riccardo Mottola]

Hi,

swamprock wrote:

Meanwhile, there is a fork of Pale Moon 27.x called Arctic Fox that can be used 
on 32-bit PowerPC-https://github.com/wicknix/Arctic-Fox/

More 
info:https://forums.macrumors.com/threads/arctic-fox-web-browser-for-10-6-32-64-bit.2133051/


I need to chime in, being one of the main contributors behind ArcticFox, 
although it is not directly my idea.



I had it working on Linux/PPC too and compiling with gcc 6.5 on Debian 
(you can check my fork on github in case, but it gets pulled in 
regularly). It could even play videos off you-tube although ad a 
ridiculous frame rate


If someone can help me with getting gcc7 and gcc8 working, welcome!!

Don't hold your breath on JS though: no JIT for PPC and stability is 
(still) dubious. Some other PPC enthusiasts got it compiling then also 
on PPC 64, although there were some endianness issues which did not 
happen in 32bit, there were also some stbaility issues.
I did some progress by packporting numerous fixes, but I lack currently 
the PPC machine to test it on and am working on Intel.
Right now on Intel I can use major sites: github, facebook, youtube... 
even web mail. It keeps me motivated!


Riccardo


PS: Adrian, I hope you get out a new ISO soon, so I try reinstalling the 
iBook and test again :) I got the machine exactly for working on ArcticFox

Re: News about Firefox for PowerPC

[swamprock]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, December 10, 2018 10:41 AM, John Paul Adrian Glaubitz 
 wrote:

> On 12/10/18 4:37 PM, Christian Zigotzky wrote:
>
> > I am not sure if you know this website: 
> > https://wiki.raptorcs.com/wiki/Porting/Firefox
>
> Nice. Looks like there hasn't been any work done on 32-Bit PowerPC yet
> though. In order to get Firefox working on 32-Bit PowerPC, someone needs
> to implement the WASM stuff on this target.
>
> Adrian
>

Meanwhile, there is a fork of Pale Moon 27.x called Arctic Fox that can be used 
on 32-bit PowerPC- https://github.com/wicknix/Arctic-Fox/

More info: 
https://forums.macrumors.com/threads/arctic-fox-web-browser-for-10-6-32-64-bit.2133051/

Brian


> --
>
> .''`. John Paul Adrian Glaubitz : :' : Debian Developer - 
> glaub...@debian.org`. `' Freie Universitaet Berlin - 
> glaub...@physik.fu-berlin.de`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 
> F5B5 F913

Re: News about Firefox for PowerPC

[John Paul Adrian Glaubitz]

On 12/10/18 4:37 PM, Christian Zigotzky wrote:
> I am not sure if you know this website: 
> https://wiki.raptorcs.com/wiki/Porting/Firefox

Nice. Looks like there hasn't been any work done on 32-Bit PowerPC yet
though. In order to get Firefox working on 32-Bit PowerPC, someone needs
to implement the WASM stuff on this target.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

News about Firefox for PowerPC

[Christian Zigotzky]

Hi All,

I am not sure if you know this website: 
https://wiki.raptorcs.com/wiki/Porting/Firefox


Many thanks to all for Debian PowerPC! :-) I use it with pleasure on my 
AmigaOnes.


Cheers,
Christian

Re: Firefox segfaults when I start it

[Dennis Clarke]

On 08/27/2018 11:09 PM, John Paul Adrian Glaubitz wrote:

On 8/28/18 5:08 AM, John Paul Adrian Glaubitz wrote:

Guess not.


Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html


Oh, FWIW, you need to install the version from experimental.

# apt install firefox -t=experimental

Adrian



Get to it later ... kernel building with that patch from Linus and this
time I will use "make INSTALL_MOD_STRIP=1 modules_install" to trim the
bulk.

dc

Re: Firefox segfaults when I start it

[John Paul Adrian Glaubitz]

On 8/28/18 5:08 AM, John Paul Adrian Glaubitz wrote:
>> Guess not.
> 
> Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html

Oh, FWIW, you need to install the version from experimental.

# apt install firefox -t=experimental

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox segfaults when I start it

[John Paul Adrian Glaubitz]

On 8/28/18 4:35 AM, Dennis Clarke wrote:
> root@nix:~# apt-get install firefox
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  firefox : Depends: libevent-2.0-5 (>= 2.0.10-stable) but it is not 
> installable
>    Depends: libhunspell-1.4-0 but it is not installable
>    Depends: libvpx4 (>= 1.6.0) but it is not installable
> E: Unable to correct problems, you have held broken packages.
> root@nix:~#
> 
> Guess not.

Explanation here: https://lists.debian.org/debian-sparc/2017/12/msg00060.html

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox segfaults when I start it

[Dennis Clarke]

On 08/27/2018 09:54 PM, John Paul Adrian Glaubitz wrote:

On 8/25/18 10:54 AM, John Paul Adrian Glaubitz wrote:

2) Firefox segfaults when I start it, either from command line or from the 
system menu.  Is this a known bug?   Are there any other graphical (i.e., 
non-text-mode) browsers I can use instead?  I can use elinks for most things, 
but it’s a lot harder to configure cups printers when you don’t have a 
graphical browser!


This is a known bug which has reported upstream. I don’t have the bug number at 
hand at the moment. I have been trying to debug it but I was unsuccessful so 
far.


See:


https://bugzilla.mozilla.org/show_bug.cgi?id=1405062
https://bugzilla.mozilla.org/show_bug.cgi?id=1466567


Adrian



bugid : 1405062

An interesting thing: the only architecture where we see this has
pagesize of 64k (may be just a coincidence though).


I have pagesize 4096 bytes here so I could see what happens.

nix$ uname -a
Linux nix 4.18.5-genunix #1 SMP Sat Aug 25 16:18:55 GMT 2018 ppc64 GNU/Linux
nix$ getconf PAGESIZE
4096

nix$ su -
Password:
root@nix:~# apt-get install firefox
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 firefox : Depends: libevent-2.0-5 (>= 2.0.10-stable) but it is not 
installable

   Depends: libhunspell-1.4-0 but it is not installable
   Depends: libvpx4 (>= 1.6.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
root@nix:~#

Guess not.

Subject line "G5 fans run out of control" didn't seem reasonable for
 a browser problem.

Anyways .. I'll poke at that patch from Linus .. for fun.

Dennis

Bug#889896: firefox: 59.0~b4-1

[John Paul Adrian Glaubitz]

Source: firefox
Version: 59.0~b4-1
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: powerpc sparc64

Hi!

On both powerpc and sparc64, firefox FTBFS because the compiler doesn't
understand the flag -fno-lifetime-dse. This can be fixed with the following
patch which removes that compiler flag for these architectures:

--- firefox-59.0~b4/debian/rules.orig   2018-01-29 10:00:01.0 +0100
+++ firefox-59.0~b4/debian/rules2018-02-08 13:56:55.173190353 +0100
@@ -112,7 +112,11 @@
 
 ifneq (,$(findstring gcc,$(CC)))
 ifeq (,$(filter 4.% 5.%,$(shell $(CC) -dumpversion)))
+ifneq (,$(filter powerpc sparc64,$(DEB_HOST_ARCH)))
+CFLAGS += -fno-schedule-insns2 -fno-delete-null-pointer-checks
+else
 CFLAGS += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
+endif
 ifneq (,$(filter armel armhf,$(DEB_HOST_ARCH)))
 CFLAGS += -fno-schedule-insns
 endif

The issue occurs right at the beginning when the build process is
trying to build ICU. For some reason, the configure script of ICU
prefers clang over gcc which results in this error as clang doesn't
understand -fno-lifetime-dse.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- firefox-59.0~b4/debian/rules.orig   2018-01-29 10:00:01.0 +0100
+++ firefox-59.0~b4/debian/rules2018-02-08 13:56:55.173190353 +0100
@@ -112,7 +112,11 @@
 
 ifneq (,$(findstring gcc,$(CC)))
 ifeq (,$(filter 4.% 5.%,$(shell $(CC) -dumpversion)))
+ifneq (,$(filter powerpc sparc64,$(DEB_HOST_ARCH)))
+CFLAGS += -fno-schedule-insns2 -fno-delete-null-pointer-checks
+else
 CFLAGS += -fno-schedule-insns2 -fno-lifetime-dse 
-fno-delete-null-pointer-checks
+endif
 ifneq (,$(filter armel armhf,$(DEB_HOST_ARCH)))
 CFLAGS += -fno-schedule-insns
 endif

Re: Bug#888898: firefox: Please add patch for big-endian support

[John Paul Adrian Glaubitz]

On 01/31/2018 12:21 AM, John Paul Adrian Glaubitz wrote:

src:firefox currently FTBFS on big-endian powerpc/ppc64 because skia
needs to be patched to support big-endian systems [1]:

n file included from 
/<>/gfx/skia/skia/src/core/SkRasterPipeline.h:11:0,
  from /<>/gfx/skia/skia/src/core/SkOpts.h:12,
  from /<>/gfx/2d/ConvolutionFilter.cpp:11:
/<>/gfx/skia/skia/include/core/SkImageInfo.h:86:6: error: #error 
"SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
  #error "SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
   ^

With the patch, firefox_59 builds fine:

Build Architecture: ppc64
Build Type: any
Build-Space: 15897132
Build-Time: 1854
Distribution: sid
Host Architecture: ppc64
Install-Time: 374
Job: /var/lib/buildd/firefox/firefox_59.0~b4-1.dsc
Machine Architecture: ppc64
Package: firefox
Package-Time: 2314
Source-Version: 59.0~b4-1
Space: 15897132
Status: successful
Version: 59.0~b4-1

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#888898: firefox: Please add patch for big-endian support

[John Paul Adrian Glaubitz]

Source: firefox
Version: 59.0~b4-1
Severity: normal
Tags: patch
User: debian-powerpc@lists.debian.org
Usertags: powerpc ppc64

Hello!

src:firefox currently FTBFS on big-endian powerpc/ppc64 because skia
needs to be patched to support big-endian systems [1]:

n file included from 
/<>/gfx/skia/skia/src/core/SkRasterPipeline.h:11:0,
 from /<>/gfx/skia/skia/src/core/SkOpts.h:12,
 from /<>/gfx/2d/ConvolutionFilter.cpp:11:
/<>/gfx/skia/skia/include/core/SkImageInfo.h:86:6: error: #error 
"SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
 #error "SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
  ^

This is achieved by applying the attached patch which I have taken from
the Firefox package in Fedora [2].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=firefox=ppc64=59.0%7Eb4-1=1517354143=0
> [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1020385

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -up firefox-56.0/gfx/skia/skia/include/core/SkColorPriv.h.big-endian 
firefox-56.0/gfx/skia/skia/include/core/SkColorPriv.h
--- firefox-56.0/gfx/skia/skia/include/core/SkColorPriv.h.big-endian
2017-07-31 18:20:55.0 +0200
+++ firefox-56.0/gfx/skia/skia/include/core/SkColorPriv.h   2017-09-29 
17:25:04.651876330 +0200
@@ -31,7 +31,7 @@
  *
  *  Here we enforce this constraint.
  */
-
+/*
 #ifdef SK_CPU_BENDIAN
 #define SK_RGBA_R32_SHIFT   24
 #define SK_RGBA_G32_SHIFT   16
@@ -43,6 +43,7 @@
 #define SK_BGRA_R32_SHIFT   8
 #define SK_BGRA_A32_SHIFT   0
 #else
+*/
 #define SK_RGBA_R32_SHIFT   0
 #define SK_RGBA_G32_SHIFT   8
 #define SK_RGBA_B32_SHIFT   16
@@ -52,7 +53,7 @@
 #define SK_BGRA_G32_SHIFT   8
 #define SK_BGRA_R32_SHIFT   16
 #define SK_BGRA_A32_SHIFT   24
-#endif
+/*#endif*/
 
 #if defined(SK_PMCOLOR_IS_RGBA) && defined(SK_PMCOLOR_IS_BGRA)
     #error "can't define PMCOLOR to be RGBA and BGRA"
diff -up firefox-56.0/gfx/skia/skia/include/core/SkImageInfo.h.big-endian 
firefox-56.0/gfx/skia/skia/include/core/SkImageInfo.h
--- firefox-56.0/gfx/skia/skia/include/core/SkImageInfo.h.big-endian
2017-07-31 18:20:55.0 +0200
+++ firefox-56.0/gfx/skia/skia/include/core/SkImageInfo.h   2017-09-29 
17:25:04.651876330 +0200
@@ -83,7 +83,8 @@ enum SkColorType {
 #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A)
 kN32_SkColorType = kRGBA__SkColorType,
 #else
-#error "SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
+//#error "SK_*32_SHFIT values must correspond to BGRA or RGBA byte order"
+kN32_SkColorType = kBGRA__SkColorType
 #endif
 };
 
diff -up firefox-56.0/gfx/skia/skia/include/gpu/GrColor.h.big-endian 
firefox-56.0/gfx/skia/skia/include/gpu/GrColor.h
--- firefox-56.0/gfx/skia/skia/include/gpu/GrColor.h.big-endian 2017-07-31 
18:20:55.0 +0200
+++ firefox-56.0/gfx/skia/skia/include/gpu/GrColor.h2017-09-29 
17:25:04.652876327 +0200
@@ -74,8 +74,13 @@ static inline GrColor GrColorPackA4(unsi
  *  Since premultiplied means that alpha >= color, we construct a color with
  *  each component==255 and alpha == 0 to be "illegal"
  */
-#define GrColor_ILLEGAL (~(0xFF << GrColor_SHIFT_A))
+//Just for big endian platforms, little has: (~(0xFF << GrColor_SHIFT_A))
+#ifdef SK_CPU_BENDIAN
+#define GrColor_ILLEGAL 0xFF00
+#else
+#define GrColor_ILLEGAL (~(0xFF << GrColor_SHIFT_A)) 
 
+#endif
 #define GrColor_WHITE 0xFFFF
 #define GrColor_TRANSPARENT_BLACK 0x0
 
diff -up firefox-56.0/gfx/skia/skia/include/gpu/GrTypes.h.big-endian 
firefox-56.0/gfx/skia/skia/include/gpu/GrTypes.h
--- firefox-56.0/gfx/skia/skia/include/gpu/GrTypes.h.big-endian 2017-07-31 
18:20:55.0 +0200
+++ firefox-56.0/gfx/skia/skia/include/gpu/GrTypes.h2017-09-29 
17:25:04.652876327 +0200
@@ -326,15 +326,13 @@ enum GrPixelConfig {
 static const int kGrPixelConfigCnt = kLast_GrPixelConfig + 1;
 
 // Aliases for pixel configs that match skia's byte order.
-#ifndef SK_CPU_LENDIAN
-#error "Skia gpu currently assumes little endian"
-#endif
 #if SK_PMCOLOR_BYTE_ORDER(B,G,R,A)
 static const GrPixelConfig kSkia_GrPixelConfig = 
kBGRA__GrPixelConfig;
 #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A)
 static const GrPixelConfig kSkia_GrPixelConfig = 
kRGBA__GrPixelConfig;
 #else
-#error "SK_*32_SHIFT values must correspond to GL_BGRA or GL_RGBA format."
+static const GrPixelConfig kSkia_GrPixelConfig = 
kBGRA__GrPixelConfig;
+static const GrPixelConfig kSkiaGamma_GrPixelConfig = 
kSBGRA__GrPixelConfig;
 #endif
 
 // Returns true if the pixel config is a GPU-specific compressed format

Bug#888638: firefox: FTBFS on powerpc and ppc64: Error updating ICU data file

[Aaron M. Ucko]

Source: firefox
Version: 58.0-1
Severity: normal
Tags: upstream
User: debian-powerpc@lists.debian.org
Usertags: powerpc ppc64

Builds of firefox for powerpc and ppc64 (the only big-endian
architectures rustc supports at present, and admittedly not release
architectures) have been failing lately.  As of 58.0-1, the
(immediate) errors take the form

  cd build-browser && MOZCONFIG=mozconfig.icu ../mach python 
../intl/icu_sources_data.py "/«PKGBUILDDIR»"
  New python executable in 
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python2.7
  Also creating executable in 
/«PKGBUILDDIR»/build-browser/_virtualenv/bin/python
  Installing setuptools, pip, wheel...done.
  WARNING: Python.h not found. Install Python development headers.
  Error processing command. Ignoring because optional. 
(optional:setup.py:third_party/python/psutil:build_ext:--inplace)
  Error processing command. Ignoring because optional. 
(optional:packages.txt:comm/build/virtualenv_packages.txt)
  Error running "make" in directory /tmp/icu-obj-aDwfA5
  See output in /tmp/icu-make84ZXyL
  Error updating ICU data file
  Updating ICU sources lists...
  Running ICU configure...
  Running ICU make...
  debian/rules:205: recipe for target 'stamps/configure-browser' failed
  make[1]: *** [stamps/configure-browser] Error 1

When I tried to reproduce these errors on porter boxes for both
architectures to see what they actually were, I ran into *different*
errors:

  cd build-browser && MOZCONFIG=mozconfig.icu ../mach python 
../intl/icu_sources_data.py "/home/ucko/firefox"
  Traceback (most recent call last):
File "../mach", line 86, in 
  main(sys.argv[1:])
File "../mach", line 78, in main
  mach = get_mach()
File "../mach", line 68, in get_mach
  mach = check_and_get_mach(dir_path)
File "../mach", line 42, in check_and_get_mach
  return load_mach(dir_path, mach_path)
File "../mach", line 30, in load_mach
  return mach_bootstrap.bootstrap(dir_path)
File "/home/ucko/firefox/build/mach_bootstrap.py", line 335, in bootstrap
  driver.load_commands_from_file(os.path.join(mozilla_dir, path))
File "/home/ucko/firefox/python/mach/mach/main.py", line 267, in 
load_commands_from_file
  imp.load_source(module_name, path)
File "/home/ucko/firefox/build/valgrind/mach_commands.py", line 16, in 

  from mozbuild.base import (
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
  module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mozbuild/mozbuild/base.py", line 16, in 

  from mach.mixin.process import ProcessExecutionMixin
File "/home/ucko/firefox/build/mach_bootstrap.py", line 364, in __call__
  module = self._original_import(name, globals, locals, fromlist, level)
File "/home/ucko/firefox/python/mach/mach/mixin/process.py", line 29, in 

  raise Exception('Could not detect environment shell!')
  Exception: Could not detect environment shell!
  debian/rules:205: recipe for target 'stamps/configure-browser' failed

Due to this discrepancy, and the lack of available details for the
autobuilders' failures, I have *not* reported anything upstream here.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#888635: firefox: FTBFS on ppc64el: jit unexpected alignment requirements

[Aaron M. Ucko]

Source: firefox
Version: 58.0-1
Severity: serious
Tags: patch upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powerpc@lists.debian.org
Usertags: ppc64el
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1425413

Builds of firefox for ppc64el have been failing lately.  As of 58.0-1,
the (immediate) problem is

  /<>/js/src/jit/Linker.cpp:27:5: error: static assertion failed: 
Unexpected alignment requirements
   static_assert(CodeAlignment >= ExecutableAllocatorAlignment,

This appears to be the same problem as in
https://bugzilla.mozilla.org/show_bug.cgi?id=1425413, reportedly fixed
upstream with a one-line patch:

https://hg.mozilla.org/integration/mozilla-inbound/rev/34839f53008f

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Re: why firefox crash on debian ppc64

[luigi burdo]

Hi Adrian,

that issue

https://bugzilla.mozilla.org/show_bug.cgi?id=1269654

was never fixed, i reported many months ago (or year) and just made firefox 
slower but is not making the crash.

Im using right now for writing here  firefox 47 (with that issue present) from 
ubuntu but no problems just more cpu % in use.

Im pretty sure the crash come because something related the message that i send 
you before, because is the only differences i sow compared before, the 
reference of chromium and this pipe errors not present before.


if gdb is needed i can try to do it but i dont know if can be possible gdb it

i will check


Luigi

No, it isn't. The log messages you provide don't reveal anything,
you need to use GDB to debug the actual crash.

The bug is already discussed in [1] and the issue is related to
the endianness of the target system.

Adrian

Bug#879497: firefox: FTBFS: Don't know how to translate powerpc64-unknown-linux-gnu for rustc

[John Paul Adrian Glaubitz]

Source: firefox
Version: 56.0-2
Severity: normal
User: debian-powerpc@lists.debian.org
Usertags: ppc64

Hi!

I bootstrapped rustc and cargo for ppc64 this weekend, so that
the build dependencies for src:firefox are fulfilled on ppc64
again.

Unfortunately, we are now running into the same problem as on
ppc64el [1] that the firefox build system doesn't know anything
about powerpc64-unknown-linux-gnu:

checking for rustc... /usr/bin/rustc
checking for cargo... /usr/bin/cargo
checking rustc version... 1.20.0
checking cargo version... 0.20.0
ERROR: Don't know how to translate powerpc64-unknown-linux-gnu for rustc
debian/rules:213: recipe for target 'stamps/configure-browser' failed
make[1]: *** [stamps/configure-browser] Error 1
make[1]: Leaving directory '/<>'
debian/rules:361: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Could you add support for ppc64 in a similar way as you added it for ppc64el? 
[2]

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864822
> [2] 
> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/commit/?id=e0c9718b0c4a72f7ddaad8213d751f8ab9e6a19b

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: why firefox crash on debian ppc64

[John Paul Adrian Glaubitz]

On 10/22/2017 10:45 AM, luigi burdo wrote:
> probably this small report can made understand one of the reason why firefox 
> crash on debian PPC64.
> (...)
> look  like the issue come on debian because a pipe error.

No, it isn't. The log messages you provide don't reveal anything,
you need to use GDB to debug the actual crash.

The bug is already discussed in [1] and the issue is related to
the endianness of the target system.

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1269654

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

why firefox crash on debian ppc64

[luigi burdo]

I Adrian,

probably this small report can made understand one of the reason why firefox 
crash on debian PPC64.


Plus i made an experiment yesterday

On this last sid  i installed one of my archived firefox esr 45.x ( from old 
debian sid archive) that is  working on others ppc64 distros (fedora 25 ppc64) 
but here crash exactly like the new versions .

look  like the issue come on debian because a pipe error.


_log


###!!! [Child][MessageChannel] Error: 
(msgtype=0xE20003,name=PTexture::Msg_Destroy) Channel error: cannot send/recv
###!!! [Child][MessageChannel] Error: 
(msgtype=0x3E0003,name=PCompositable::Msg_Destroy) Channel error: cannot 
send/recv
[Child 3646] ###!!! ABORT: Aborting on channel error.: file 
/build/firefox-esr-iI1OHq/firefox-esr-52.3.0esr/ipc/glue/MessageChannel.cpp, 
line 2152
[Parent 3937] WARNING: pipe error (57): Connection reset by peer: file 
/build/firefox-esr-iI1OHq/firefox-esr-52.3.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 322
[Parent 3937] WARNING: pipe error (64): Connection reset by peer: file 
/build/firefox-esr-iI1OHq/firefox-esr-52.3.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 322
___


hope it can help


Ciao

Luigi

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Gabriel Paubert]

On Fri, Sep 29, 2017 at 02:15:42PM +0200, Gabriel Paubert wrote:
> On Fri, Sep 29, 2017 at 01:36:19PM +0200, Mathieu Malaterre wrote:
> > On Fri, Sep 29, 2017 at 12:40 PM, Gabriel Paubert <paub...@iram.es> wrote:
> > > On Fri, Sep 29, 2017 at 12:10:20PM +0200, Christian Zigotzky wrote:
> > >> On 29 September 2017 at 11:42AM, Gabriel Paubert wrote:
> > >> > Hi Christian,
> > >> >
> > >> > The right mouse button, i.e., the one that pops up a menu.
> > >> >
> > >> I understand. Yes, you're right. There is a problem. I can open the menu 
> > >> but
> > >> selecting a menu point doesn't work. Thanks for the hint.
> > >
> > > Ok, in my case it is way more drastic: SIGSEGV causing 
> > > InstantProcessDeath(TM).
> > >
> > > There is a trace in the kernel log, with a blurb about "invalid signal
> > > frame" and not much more.
> > >
> > > This is with v4.13/v4.14 kernels.
> > 
> > Could you please report the bug with the content of syslog.
> 
> I'm away from the machine until next Friday, and running firefox on
> remote display on a slow link is painful, to put it mildly.

Hmm, well, I just got a very similar Firefox crash on my PB G4 a few minutes 
ago:

Sep 30 11:25:23 localhost vmunix: Compositor[5787]: bad frame in 
handle_rt_signal32: a2c00b50 nip b5b8037c lr b5b80350
Sep 30 11:25:23 localhost vmunix: Chrome_ChildThr[7685]: bad frame in 
handle_rt_signal32: b016de60 nip b54b737c lr b54b7350

I might not have used Firefox for a while on that machine, and it was
updated (Debian stable) earlier this morning.

Gabriel

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Gabriel Paubert]

On Fri, Sep 29, 2017 at 01:36:19PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 29, 2017 at 12:40 PM, Gabriel Paubert <paub...@iram.es> wrote:
> > On Fri, Sep 29, 2017 at 12:10:20PM +0200, Christian Zigotzky wrote:
> >> On 29 September 2017 at 11:42AM, Gabriel Paubert wrote:
> >> > Hi Christian,
> >> >
> >> > The right mouse button, i.e., the one that pops up a menu.
> >> >
> >> I understand. Yes, you're right. There is a problem. I can open the menu 
> >> but
> >> selecting a menu point doesn't work. Thanks for the hint.
> >
> > Ok, in my case it is way more drastic: SIGSEGV causing 
> > InstantProcessDeath(TM).
> >
> > There is a trace in the kernel log, with a blurb about "invalid signal
> > frame" and not much more.
> >
> > This is with v4.13/v4.14 kernels.
> 
> Could you please report the bug with the content of syslog.

I'm away from the machine until next Friday, and running firefox on
remote display on a slow link is painful, to put it mildly.

Gabriel

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Mathieu Malaterre]

On Fri, Sep 29, 2017 at 12:40 PM, Gabriel Paubert  wrote:
> On Fri, Sep 29, 2017 at 12:10:20PM +0200, Christian Zigotzky wrote:
>> On 29 September 2017 at 11:42AM, Gabriel Paubert wrote:
>> > Hi Christian,
>> >
>> > The right mouse button, i.e., the one that pops up a menu.
>> >
>> I understand. Yes, you're right. There is a problem. I can open the menu but
>> selecting a menu point doesn't work. Thanks for the hint.
>
> Ok, in my case it is way more drastic: SIGSEGV causing 
> InstantProcessDeath(TM).
>
> There is a trace in the kernel log, with a blurb about "invalid signal
> frame" and not much more.
>
> This is with v4.13/v4.14 kernels.

Could you please report the bug with the content of syslog.

Thanks

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Gabriel Paubert]

On Fri, Sep 29, 2017 at 12:10:20PM +0200, Christian Zigotzky wrote:
> On 29 September 2017 at 11:42AM, Gabriel Paubert wrote:
> > Hi Christian,
> > 
> > The right mouse button, i.e., the one that pops up a menu.
> > 
> I understand. Yes, you're right. There is a problem. I can open the menu but
> selecting a menu point doesn't work. Thanks for the hint.

Ok, in my case it is way more drastic: SIGSEGV causing InstantProcessDeath(TM).

There is a trace in the kernel log, with a blurb about "invalid signal 
frame" and not much more.

This is with v4.13/v4.14 kernels.

Gabriel

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Christian Zigotzky]

On 29 September 2017 at 11:42AM, Gabriel Paubert wrote:

Hi Christian,

The right mouse button, i.e., the one that pops up a menu.

I understand. Yes, you're right. There is a problem. I can open the menu 
but selecting a menu point doesn't work. Thanks for the hint.


-- Christian

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Gabriel Paubert]

Hi Christian,

On Fri, Sep 29, 2017 at 11:23:30AM +0200, Christian Zigotzky wrote:
> Hi Gabriel,
> 
> Could you please exactly describe where the button is? I don't know which
> button do you mean.

The right mouse button, i.e., the one that pops up a menu.

> 
> Just for info. The A-EON PowerPC machines use their own customized Linux
> kernels and they don't need Grub, Yaboot or something like that for booting.
> The firmwares boot the Linux kernels directly. Only FYI.
> 
> I have posted a call to subscribe to the Firefox bug in the A-EON Linux PPC
> support forum. [1]
> 
> Cheers,
> Christian
> 
> [1] 
> http://forum.hyperion-entertainment.biz/viewtopic.php?f=35=2453=42499#p42499
> 
> 
> On 29 September 2017 at 11:03AM, Gabriel Paubert wrote:
> > Do you also have the problem of FireFix exiting with corrupt signal
> > frame or a similar message when clicking on the right button under
> > FireFox?
> > 
> > It might be signal handling kernel bug on recent kernels, I don't know.
> > But it's very easily reproducible (read: alsmot systematic) on my ppc64
> > machine with 32 bit userspace.
> > 
> > Gabriel

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Christian Zigotzky]

Hi Gabriel,

Could you please exactly describe where the button is? I don't know 
which button do you mean.


Just for info. The A-EON PowerPC machines use their own customized Linux 
kernels and they don't need Grub, Yaboot or something like that for 
booting. The firmwares boot the Linux kernels directly. Only FYI.


I have posted a call to subscribe to the Firefox bug in the A-EON Linux 
PPC support forum. [1]


Cheers,
Christian

[1] 
http://forum.hyperion-entertainment.biz/viewtopic.php?f=35=2453=42499#p42499



On 29 September 2017 at 11:03AM, Gabriel Paubert wrote:

Do you also have the problem of FireFix exiting with corrupt signal
frame or a similar message when clicking on the right button under
FireFox?

It might be signal handling kernel bug on recent kernels, I don't know.
But it's very easily reproducible (read: alsmot systematic) on my ppc64
machine with 32 bit userspace.

Gabriel

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[John Paul Adrian Glaubitz]

On 09/29/2017 10:59 AM, Christian Zigotzky wrote:

It's the same bug report. :-) Your first link is also correct.


FWIW, please avoid posting messages like "I have the same problem, too",
it just causes unnecessary noise. You should only post to bug reports
when you have additional information available.

Subscribing to the bug report is enough to show the maintainers that
you are affected by this problem as well.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Gabriel Paubert]

On Fri, Sep 29, 2017 at 10:06:08AM +0200, Christian Zigotzky wrote:
> Hi All,
> 
> I have Debian Sid PowerPC (PPC32) on my A-EON AmigaOne X1000 Nemo (P.A. Semi
> PA6T). I have the same problems with Firefox ESR.
> 
> Adrian, could you try to get in touch with the Firefox maintainer? I think
> you can better discuss with him about the problems.

Do you also have the problem of FireFix exiting with corrupt signal
frame or a similar message when clicking on the right button under
FireFox?

It might be signal handling kernel bug on recent kernels, I don't know.
But it's very easily reproducible (read: alsmot systematic) on my ppc64
machine with 32 bit userspace.

Gabriel

> 
> Thanks,
> Christian
> 
> On 28.09.2017 23:59, John Paul Adrian Glaubitz wrote:
> > Hi Sinan!
> > 
> > On 09/28/2017 09:22 PM, Sinan Gürkan wrote:
> > > I am running Debian 9 ppc64 with Mate Desktop on A-Eon Cyrus X5000 
> > > (Freescale P5020)
> > > 
> > > Both Firefox-ESR and Qupzilla exits or crashes while browsing.
> > You most likely ran into this upstream bug [1] which affects big-endian
> > systems. As far as I can see, there is no new solution yet so it might
> > be a good idea for you to subscribe to this bug report.
> > 
> > Unfortunately, Firefox upstream doesn't care much about big-endian systems
> > so they are knowingly accepting patches that causes these regressions. And
> > even if we had a patch to address this issue, we still have the problem
> > that Debian's Firefox maintainer is not very responsive when it comes
> > to patches to address issues on Debian Ports architectures. My patches
> > to fix firefox-esr on m68k, sh4 and sparc64, for example, have still not
> > been merged :(.
> > 
> > Debian's Thunderbird maintainer is more welcoming in this regard and he's
> > always happy to merge patches that fix issues on Debian Ports architectures
> > and since Thunderbird is based on Firefox, you might be seeing this
> > crash there as well.
> > 
> > Adrian
> > 
> > > [1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654
> 

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Christian Zigotzky]

Hi All,

I have just subscribed to the bug report. [1]

@All
Please subscribe to this bug report.

Thanks,
Christian

[1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654


On 29 September 2017 at 10:06AM, Christian Zigotzky wrote:

Hi All,

I have Debian Sid PowerPC (PPC32) on my A-EON AmigaOne X1000 Nemo 
(P.A. Semi PA6T). I have the same problems with Firefox ESR.


Adrian, could you try to get in touch with the Firefox maintainer? I 
think you can better discuss with him about the problems.


Thanks,
Christian

On 28.09.2017 23:59, John Paul Adrian Glaubitz wrote:

Hi Sinan!

On 09/28/2017 09:22 PM, Sinan Gürkan wrote:
I am running Debian 9 ppc64 with Mate Desktop on A-Eon Cyrus X5000 
(Freescale P5020)


Both Firefox-ESR and Qupzilla exits or crashes while browsing.

You most likely ran into this upstream bug [1] which affects big-endian
systems. As far as I can see, there is no new solution yet so it might
be a good idea for you to subscribe to this bug report.

Unfortunately, Firefox upstream doesn't care much about big-endian 
systems
so they are knowingly accepting patches that causes these 
regressions. And

even if we had a patch to address this issue, we still have the problem
that Debian's Firefox maintainer is not very responsive when it comes
to patches to address issues on Debian Ports architectures. My patches
to fix firefox-esr on m68k, sh4 and sparc64, for example, have still not
been merged :(.

Debian's Thunderbird maintainer is more welcoming in this regard and 
he's
always happy to merge patches that fix issues on Debian Ports 
architectures

and since Thunderbird is based on Firefox, you might be seeing this
crash there as well.

Adrian


[1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Christian Zigotzky]

Adrian,

It's the same bug report. :-) Your first link is also correct.

Cheers,
Christian


On 29 September 2017 at 00:04AM, John Paul Adrian Glaubitz wrote:

On 09/28/2017 11:59 PM, John Paul Adrian Glaubitz wrote:

[1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654

That link is bogus, sorry. Should be:


https://bugzilla.mozilla.org/show_bug.cgi?id=1269654

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Christian Zigotzky]

Hi All,

I have Debian Sid PowerPC (PPC32) on my A-EON AmigaOne X1000 Nemo (P.A. 
Semi PA6T). I have the same problems with Firefox ESR.


Adrian, could you try to get in touch with the Firefox maintainer? I 
think you can better discuss with him about the problems.


Thanks,
Christian

On 28.09.2017 23:59, John Paul Adrian Glaubitz wrote:

Hi Sinan!

On 09/28/2017 09:22 PM, Sinan Gürkan wrote:

I am running Debian 9 ppc64 with Mate Desktop on A-Eon Cyrus X5000 (Freescale 
P5020)

Both Firefox-ESR and Qupzilla exits or crashes while browsing.

You most likely ran into this upstream bug [1] which affects big-endian
systems. As far as I can see, there is no new solution yet so it might
be a good idea for you to subscribe to this bug report.

Unfortunately, Firefox upstream doesn't care much about big-endian systems
so they are knowingly accepting patches that causes these regressions. And
even if we had a patch to address this issue, we still have the problem
that Debian's Firefox maintainer is not very responsive when it comes
to patches to address issues on Debian Ports architectures. My patches
to fix firefox-esr on m68k, sh4 and sparc64, for example, have still not
been merged :(.

Debian's Thunderbird maintainer is more welcoming in this regard and he's
always happy to merge patches that fix issues on Debian Ports architectures
and since Thunderbird is based on Firefox, you might be seeing this
crash there as well.

Adrian


[1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[John Paul Adrian Glaubitz]

On 09/28/2017 11:59 PM, John Paul Adrian Glaubitz wrote:
>> [1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654

That link is bogus, sorry. Should be:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1269654

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[John Paul Adrian Glaubitz]

Hi Sinan!

On 09/28/2017 09:22 PM, Sinan Gürkan wrote:
> I am running Debian 9 ppc64 with Mate Desktop on A-Eon Cyrus X5000 (Freescale 
> P5020)
> 
> Both Firefox-ESR and Qupzilla exits or crashes while browsing.

You most likely ran into this upstream bug [1] which affects big-endian
systems. As far as I can see, there is no new solution yet so it might
be a good idea for you to subscribe to this bug report.

Unfortunately, Firefox upstream doesn't care much about big-endian systems
so they are knowingly accepting patches that causes these regressions. And
even if we had a patch to address this issue, we still have the problem
that Debian's Firefox maintainer is not very responsive when it comes
to patches to address issues on Debian Ports architectures. My patches
to fix firefox-esr on m68k, sh4 and sparc64, for example, have still not
been merged :(.

Debian's Thunderbird maintainer is more welcoming in this regard and he's
always happy to merge patches that fix issues on Debian Ports architectures
and since Thunderbird is based on Firefox, you might be seeing this
crash there as well.

Adrian

> [1] https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269654

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Firefox-esr and qupzilla crash/exit under Debian 9 ppc64

[Sinan Gürkan]

Dear all

I am running Debian 9 ppc64 with Mate Desktop on A-Eon Cyrus X5000
(Freescale P5020)

Both Firefox-ESR and Qupzilla exits or crashes while browsing.

Here are the outputs in the terminal.

Firefox-ESR:

Crash Annotation GraphicsCriticalError: |[0][GFX1]: Unknown image format 1
(t=4.70433) |[5086][GFX1]: Unknown image format 1 (t=90.5178)
|[5087][GFX1]: Unknown image format 1 (t=90.5287) |[5088][GFX1]: Unknown
image format 1 (t=94.4401) |[5089][GFX1]: Unknown image format 1
(t=94.4405) |[5090][GFX1]: Unknown image format 1 (t=94.4417)
|[5091][GFX1]: Unknown image format 1 (t=94.4568) |[5077][GFX1]: Unknown
image format 1 (t=85.4479) |[5078][GFX1]: Unknown image format 1 (t=85.449)
|[5079][GFX1]: Unknown image format 1 (t=85.4647) |[5080][GFX1]: Unknown
image format 1 (t=90.0794) |[5081][GFX1]: Unknown image format 1
(t=90.0797) |[5082][GFX1]: Unknown image format 1 (t=90.0809)
|[5083][GFX1]: Unknown image format 1 (t=90.0964) |[5084][GFX1]: Unknown
image format 1 (t=90.5144) |[5085][GFX1]: Unknown image format 1
(t=90.5167) [GFX1]: Unknown image format 1
Illegal instruction

Qupzilla:

root@X5000:/home/amigaone# qupzilla
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000
instead of 0
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000
instead of 0
Qt: Session management error: None of the authentication protocols
specified are supported
AdBlockSubscription:: loadSubscription invalid format of adblock file
"/root/.config/qupzilla/profiles/default/adblock/customlist.txt"
QupZilla: 0 extensions loaded
QIODevice::read (QFile, "/root/.config/qupzilla/
profiles/default/cookies.dat"): device not open
Illegal instruction



-- 
Sinan Gürkan
AmigaOS4 Beta-Tester
**AmigaOne X5000 + 8GB RAM + Asus Radeon R7 265 **
**AmigaOne A1222 + 2GB RAM + Asus Radeon R7 265**
**Sam460ex + 2GB RAM + Sapphire Radeon 7750**

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Lennart Sorensen]

On Mon, Feb 13, 2017 at 04:44:22PM -0500,  wrote:
> Well there does exist cheaper options, like the $4k T4240QDS-PB, which
> is 12 core (24 threads) 1.8Ghz 64 bit powerpc.
> 
> The P5040RDB is $3k for a quad core 64 bit powerpc.
> 
> That's still not hobby level pricing though.  Better than the price of
> the talos, but also not ppc64el compatible (as far as I know).

Seems you can get an IBM S812LC with an 8 core Power8 for under $5k with
32GB ram.  That would make for a nice build machine.  You wouldn't want
to be anywhere near it due to the fan noise though.

-- 
Len Sorensen

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[luigi burdo]

P5040 is much less then 3k in prize or there is P5020 too *cyrus plus

or the old good G5 Quad.. it rulez today im writing right now from fedora 25 
PPC64 firefox 51 and i dont miss a new gen machine. Work in full PPC64 made 
this machine really enjoyable.


Luigi



Da: Lennart Sorensen <lsore...@csclub.uwaterloo.ca>
Inviato: lunedì 13 febbraio 2017 22.44
A: Konstantinos Margaritis
Cc: debian-powerpc@lists.debian.org
Oggetto: Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): 
Segmentation fault

On Mon, Feb 13, 2017 at 10:44:57PM +0200, Konstantinos Margaritis wrote:
> As with all new languages it will take time, but eventually it will get
> there, with a big IF. The biggest(only?) problem with PowerPC in
> general right now is hardware availability not lack of interested
> developers. Developers will try anything new if it's decently priced
> (as ARM/MIPS have already proven). Show me a decent 64-bit PowerPC
> board at ~100-200EUR, Talos was a great idea, but about $17k more
> expensive than it should have been.

Well there does exist cheaper options, like the $4k T4240QDS-PB, which
is 12 core (24 threads) 1.8Ghz 64 bit powerpc.

The P5040RDB is $3k for a quad core 64 bit powerpc.

That's still not hobby level pricing though.  Better than the price of
the talos, but also not ppc64el compatible (as far as I know).

--
Len Sorensen

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Lennart Sorensen]

On Mon, Feb 13, 2017 at 10:44:57PM +0200, Konstantinos Margaritis wrote:
> As with all new languages it will take time, but eventually it will get
> there, with a big IF. The biggest(only?) problem with PowerPC in
> general right now is hardware availability not lack of interested
> developers. Developers will try anything new if it's decently priced
> (as ARM/MIPS have already proven). Show me a decent 64-bit PowerPC
> board at ~100-200EUR, Talos was a great idea, but about $17k more
> expensive than it should have been.

Well there does exist cheaper options, like the $4k T4240QDS-PB, which
is 12 core (24 threads) 1.8Ghz 64 bit powerpc.

The P5040RDB is $3k for a quad core 64 bit powerpc.

That's still not hobby level pricing though.  Better than the price of
the talos, but also not ppc64el compatible (as far as I know).

-- 
Len Sorensen

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/13/2017 09:44 PM, Konstantinos Margaritis wrote:
> I'm not a compiler developer, but I've done my share of compiler 
> bootstrapping/bug reporting/bug fixing.

Same here. I'm just more involved with gcc on targets like SH, sparc64
and m68k.

> In fact I'm one of the maintainers of LDC (LLVM D compiler), and I've 
> bootstrapped the package for armhf/ppc64/ppc64le and working on arm64/powerpc 
> and
> other arches to follow (s390x/mips*) when I have the time. I've also done 
> quite a few bug reports to gcc upstream (mostly NEON ICEs for armhf). So I 
> have a
> pretty good idea of what's involved, though I've only scratched Rust on the 
> surface and never actually developed on/for it.

Ok. It first sound like you thought it would be a trivial thing to do.
- From my experience, getting compilers work properly can be quite involved
on non-mainstream architectures. People are normally used to compilers
to be nearly bug free from their experience on x86 targets but that's
often not the case on other architectures. On SH, for example, there
were over 20 bugs to be fixed until the SH backend for gcc-5 was properly
working.

> I know for a fact that there are people pushing for IBM to actively support 
> Rust on ppc64*. Whether that works or not, I have no idea, but at least people
> are not idle.

I have heard the same, yes. But the question is whether this is endorsed
by IBM themselves or just some people working at IBM. Unlike Golang, Rust
doesn't have a big usecase which makes it attractive for porters. For Golang,
it's container technology and all the projects around it. Nearly every company
wants to jump the container hypetrain and that's why Golang is coming to
more and more platforms. Plus, Go has a second implementation called
gccgo which reaches even more targets.

> As with all new languages it will take time, but eventually it will get 
> there, with a big IF. The biggest(only?) problem with PowerPC in general 
> right now
> is hardware availability not lack of interested developers. Developers will 
> try anything new if it's decently priced (as ARM/MIPS have already proven).
> Show me a decent 64-bit PowerPC board at ~100-200EUR, Talos was a great idea, 
> but about $17k more expensive than it should have been.

The problem with Rust is that there isn't even a stable and fully
supported ARM port despite ARM being one of the largest targets
Linux runs on. x86 is their only tier 1 architecture, the rest
is tier 2 or lower.

If Mozilla wants Rust to be a serious competitor to C++, they will
have to stack up their resources but I doubt they have the finanical
power to do that. They're not Google and their contract with Yahoo
will probably not be extended either now that Yahoo has been bought
by Verizon.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAliiHisACgkQdCY7N/W1
+RP+zA//Sfdeeq7hF9Pc3OQiqo1ItYhp0R72Qhj/62roGpCiLjqh6FktfwNNmhTN
GcMwE7rvkzpLDS6fAlmjx8RANqH6qmFug4rmg6XFYM2NGTe/wjWoxrHOFiGpaPpd
u2Sd2FG0pDBHbw/LRV93FF95TPEA23EpbejQqkva68KdrWQ7qgA2YUdZ+W0Opyf9
y43unP6nCDWrZZAdIOeOml/H0G8yf7RdJ4l2NBZZAAu5huMlUInrGE/ZmdoDlLQI
wy74b2XBVFlGc+Z6REY38XrG77ZhHuv66zw3TPD6PElXMGnETDfYtq0QdrVv5dX6
iHk60cM4cbK0pYxEP/ylaxkeugYHy3fw7o0OyvE/eQOUwoxF2xrlKd5wrL4MznQF
TuTq5hwGB8cJ276oBJFbp1kvk3JUkz+z5dVQGbomjtitT1UDTi8LsnJs+5UQTeOc
Gn0u+6vk1+HPp4Tv//0rSC4X8wOYzuwwH9ri2aWg+5vBpn7BCykRCfiZDZ9/EE9C
lMNl3JBb7MwLmM6Bvn4SOxg9VgSOhRma6GpcIPlYQx9VWYtFP6LZgRovGB/RY115
A/rYOa00LVEObQRLBntWKlLbd1wgPb6E8KNo+1QVuhKeW91fmz8QOgIsfCZQ3Iwd
CWiXBoy/AZV3T9D8X2QUPjYTNkD9VpuwWyqnHrfcME81oBLxTB4=
=4HVI
-END PGP SIGNATURE-

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Konstantinos Margaritis]

Στις 13-02-2017, ημέρα Δευ, και ώρα 21:00 +0100, ο/η John Paul Adrian
Glaubitz έγραψε:
> I don't know whether you have already dealt with the internals of
> compilers in the past, but I can tell you that it isn't a matter of
> just "fixing" it. For it to work, someone actually has to maintain
> the codebase for this target. Because as the code is being developed,
> it will break again and again unless someone actually tests the code
> on these architectures.

I'm not a compiler developer, but I've done my share of compiler
bootstrapping/bug reporting/bug fixing. In fact I'm one of the
maintainers of LDC (LLVM D compiler), and I've bootstrapped the package
for armhf/ppc64/ppc64le and working on arm64/powerpc and other arches
to follow (s390x/mips*) when I have the time. I've also done quite a
few bug reports to gcc upstream (mostly NEON ICEs for armhf). So I have
a pretty good idea of what's involved, though I've only scratched Rust
on the surface and never actually developed on/for it.

> The problem is that - unlike Golang - no one outside Mozilla cares
> seriously
> enough about Rust that they would maintain it on other architectures.
> For
> Google's Golang, the architecture ports are maintained by the
> hardware
> vendors themselves. For example, IBM maintains Golang on POWER
> (ppc64el
> and ppc64 and zSeries, Google (being a big ARM supporter because of
> Android)
> themselves maintain Golang on ARM, Oracle on sparc64 and so on.

I know for a fact that there are people pushing for IBM to actively
support Rust on ppc64*. Whether that works or not, I have no idea, but
at least people are not idle.

> For Rust, there is currently no such support. Mozilla develops and
> tests
> on x86 only. Everything else is not guaranteed to work at all and may
> blow up in your face.

As with all new languages it will take time, but eventually it will get
there, with a big IF. The biggest(only?) problem with PowerPC in
general right now is hardware availability not lack of interested
developers. Developers will try anything new if it's decently priced
(as ARM/MIPS have already proven). Show me a decent 64-bit PowerPC
board at ~100-200EUR, Talos was a great idea, but about $17k more
expensive than it should have been.

Regards

Konstantinos

signature.asc
Description: This is a digitally signed message part

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

On 02/13/2017 08:26 PM, Konstantinos Margaritis wrote:
>> Yes. Everyone who is basing their work on Firefox will have to move
>> to a different
>> codebase from version 53 on or fork Firefox and continue without
>> Rust.
> 
> Or, fix Rust for powerpc?

I don't know whether you have already dealt with the internals of
compilers in the past, but I can tell you that it isn't a matter of
just "fixing" it. For it to work, someone actually has to maintain
the codebase for this target. Because as the code is being developed,
it will break again and again unless someone actually tests the code
on these architectures.

The problem is that - unlike Golang - no one outside Mozilla cares seriously
enough about Rust that they would maintain it on other architectures. For
Google's Golang, the architecture ports are maintained by the hardware
vendors themselves. For example, IBM maintains Golang on POWER (ppc64el
and ppc64 and zSeries, Google (being a big ARM supporter because of Android)
themselves maintain Golang on ARM, Oracle on sparc64 and so on.

For Rust, there is currently no such support. Mozilla develops and tests
on x86 only. Everything else is not guaranteed to work at all and may
blow up in your face.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Konstantinos Margaritis]

Στις 13-02-2017, ημέρα Δευ, και ώρα 20:20 +0100, ο/η John Paul Adrian
Glaubitz έγραψε:
> Yes. Everyone who is basing their work on Firefox will have to move
> to a different
> codebase from version 53 on or fork Firefox and continue without
> Rust.

Or, fix Rust for powerpc?

My 2c.

Konstantinos

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

On 02/13/2017 01:25 PM, Herminio Hernandez, Jr. wrote:
> This does not surprise me. It is a really sad case. Even the developer of the
> TenFourFox port of FF knows that he will have to cease being code compatible.

Yes. Everyone who is basing their work on Firefox will have to move to a 
different
codebase from version 53 on or fork Firefox and continue without Rust.

> Right now I am using Midori, but once that moves to webkit2gtk life will be 
> painful.

I think Webkit is still portable to all architectures and not limited to x86.

> Here is backtrace I did.

This is actually a useful backtrace. And it's most likely this bug [1].

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1269654

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez, Jr.]

This does not surprise me. It is a really sad case. Even the developer of
the TenFourFox port of FF knows that he will have to cease being code
compatible. Right now I am using Midori, but once that moves to webkit2gtk
life will be painful.

Here is backtrace I did.

On Mon, Feb 13, 2017 at 4:26 AM, luigi burdo <intermedi...@hotmail.com>
wrote:

> It means all are killing us in all fronts.
>
> [image: ☹]
>
>
> Luigi
>
>
> --
> *Da:* John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
> *Inviato:* lunedì 13 febbraio 2017 11.49
> *A:* debian-powerpc@lists.debian.org
> *Oggetto:* Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC
> (PPC32): Segmentation fault
>
> Hi!
>
> On 02/06/2017 10:39 PM, Christian Zigotzky wrote:
> > I installed Firefox 51.0.1-1 with 'apt-get install -t experimental
> firefox'
> > on Debian Sid/experimental PowerPC (PPC32) today.
>
> Just as a warning in advance: Mozilla upstream has decided to make the Rust
> programming language mandatory for Firefox 54 onwards [1].
>
> Unfortunately, Mozilla currently has little interest to support Rust
> non-x86
> platforms in a stable manner which is why the Rust compiler rustc is
> currently
> really usable on i386, amd64 and with some luck on arm64 [2].
>
> Thus, it can be expected that Firefox 54 and newer will no longer run on
> any PowerPC platforms, especially 32-bit variants.
>
> It's a sad state but Mozilla upstream has decided to make this cut which
> will also eventually see the removal of XUL support and hence the support
> for most of the popular Addons that exist in Firefox like Vimperator.
>
> Adrian
>
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816
> 1284816 – Require Rust to build - bugzilla.mozilla.org
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1284816>
> bugzilla.mozilla.org
> At some point we're going to require Rust to build Firefox. This is a
> blocker to writing any critical components in Rust. Once we've fixed the
> blockers of bug 1283898 ...
>
>
> > [2] http://lists.alioth.debian.org/pipermail/pkg-rust-
> maintainers/Week-of-Mon-20161226/000758.html
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>
rican-linux@debian-ppc:~$ gdb firefox.real
]GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from firefox.real...Reading symbols from /usr/lib/debug/.build-id/a6/81b7e65ae15687f43f84f7c55dfc4626f13bda.debug...done.
done.
(gdb) run http://mozilla.org
Starting program: /usr/bin/firefox.real http://mozilla.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
[New Thread 0xb79ff450 (LWP 2332)]
[New Thread 0xb5c3a450 (LWP 2333)]
[Thread 0xb5c3a450 (LWP 2333) exited]
[New Thread 0xb5c3a450 (LWP 2335)]
[New Thread 0xb49ca450 (LWP 2336)]
[New Thread 0xb3fff450 (LWP 2337)]
[New Thread 0xb37ff450 (LWP 2338)]
[New Thread 0xb2fff450 (LWP 2339)]
[New Thread 0xb27ff450 (LWP 2340)]
[New Thread 0xb1fff450 (LWP 2341)]
[New Thread 0xb17ff450 (LWP 2342)]
[New Thread 0xb0bff450 (LWP 2343)]
[New Thread 0xb03ff450 (LWP 2344)]
[New Thread 0xafb09450 (LWP 2345)]
[New Thread 0xaf309450 (LWP 2346)]
[New Thread 0xb7f8a450 (LWP 2348)]
[New Thread 0xae5ff450 (LWP 2349)]
[New Thread 0xad6ff450 (LWP 2350)]
[New Thread 0xac7ff450 (LWP 2351)]
[Thread 0xac7ff450 (LWP 2351) exited]
[New Thread 0xac7ff450 (LWP 2352)]
[New Thread 0xabd0b450 (LWP 2353)]
[New Thread 0xab50b450 (LWP 2354)]
[Thread 0xac7ff450 (LWP 2352) exited]
[New Thread 0xac7ff450 (LWP 2356)]
[New Thread 0xaae85450 (LWP 2357)]
[New Thread 0xa9fff450 (LWP 2358)]
[New Thread 0xa97ff450 (LWP 2359)]
[New Thread 0xa8fff450 (LWP 2360)]
[New Thread 0xa87ff450 (LWP 2361)]
[New Thread 0xa7bff450 (LWP 2362)]
[New Thread 0xa73ff450 (LWP 2363)]
[New Thread 0xa6bff450 (LWP 2364)]
[New Thread 0xa63ff450 (LWP 2365)]
[Thread

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[luigi burdo]

It means all are killing us in all fronts.

[☹]


Luigi



Da: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Inviato: lunedì 13 febbraio 2017 11.49
A: debian-powerpc@lists.debian.org
Oggetto: Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): 
Segmentation fault

Hi!

On 02/06/2017 10:39 PM, Christian Zigotzky wrote:
> I installed Firefox 51.0.1-1 with 'apt-get install -t experimental firefox'
> on Debian Sid/experimental PowerPC (PPC32) today.

Just as a warning in advance: Mozilla upstream has decided to make the Rust
programming language mandatory for Firefox 54 onwards [1].

Unfortunately, Mozilla currently has little interest to support Rust non-x86
platforms in a stable manner which is why the Rust compiler rustc is currently
really usable on i386, amd64 and with some luck on arm64 [2].

Thus, it can be expected that Firefox 54 and newer will no longer run on
any PowerPC platforms, especially 32-bit variants.

It's a sad state but Mozilla upstream has decided to make this cut which
will also eventually see the removal of XUL support and hence the support
for most of the popular Addons that exist in Firefox like Vimperator.

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816
1284816 – Require Rust to build - 
bugzilla.mozilla.org<https://bugzilla.mozilla.org/show_bug.cgi?id=1284816>
bugzilla.mozilla.org
At some point we're going to require Rust to build Firefox. This is a blocker 
to writing any critical components in Rust. Once we've fixed the blockers of 
bug 1283898 ...



> [2] 
> http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20161226/000758.html

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

Hi!

On 02/06/2017 10:39 PM, Christian Zigotzky wrote:
> I installed Firefox 51.0.1-1 with 'apt-get install -t experimental firefox'
> on Debian Sid/experimental PowerPC (PPC32) today.

Just as a warning in advance: Mozilla upstream has decided to make the Rust
programming language mandatory for Firefox 54 onwards [1].

Unfortunately, Mozilla currently has little interest to support Rust non-x86
platforms in a stable manner which is why the Rust compiler rustc is currently
really usable on i386, amd64 and with some luck on arm64 [2].

Thus, it can be expected that Firefox 54 and newer will no longer run on
any PowerPC platforms, especially 32-bit variants.

It's a sad state but Mozilla upstream has decided to make this cut which
will also eventually see the removal of XUL support and hence the support
for most of the popular Addons that exist in Firefox like Vimperator.

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1284816
> [2] 
> http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/Week-of-Mon-20161226/000758.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez Jr.]

Running debug now with the symbols. 

Sent from my iPhone

> On Feb 12, 2017, at 8:50 AM, Christian Zigotzky <chzigot...@xenosoft.de> 
> wrote:
> 
> Hi Herminio,
> 
> If you want to backtrace Firefox, then you need the debug version of Firefox. 
> Please add the following repositories to your /etc/apt/sources.list:
> 
> deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
> deb http://debug.mirrors.debian.org/debian-debug/ experimental-debug main
> 
> You have to install the Firefox package with dbgsym attached:
> 
> apt-get install -t experimental firefox-dbgsym
> 
> Many thanks for your help.
> 
> Cheers,
> Christian
> 
>> On 12 February 2017 at 10:18 AM, John Paul Adrian Glaubitz wrote:
>>> On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:
>>> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. 
>>> I am posting it here.
>> This backtrace is not usable, it doesn't contains any symbols:
>> 
>> Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
>> 0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
>> (gdb) bt
>> #0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
>> #1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
>> #2  0x20017584 in ?? ()
>> (...)
>> 
>> The "??" indicates you don't have debug symbols installed.
>> 
>> Adrian
>> 
> 

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez Jr.]

Will do. Anything to help. 

Sent from my iPhone

> On Feb 12, 2017, at 8:50 AM, Christian Zigotzky <chzigot...@xenosoft.de> 
> wrote:
> 
> Hi Herminio,
> 
> If you want to backtrace Firefox, then you need the debug version of Firefox. 
> Please add the following repositories to your /etc/apt/sources.list:
> 
> deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
> deb http://debug.mirrors.debian.org/debian-debug/ experimental-debug main
> 
> You have to install the Firefox package with dbgsym attached:
> 
> apt-get install -t experimental firefox-dbgsym
> 
> Many thanks for your help.
> 
> Cheers,
> Christian
> 
>> On 12 February 2017 at 10:18 AM, John Paul Adrian Glaubitz wrote:
>>> On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:
>>> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. 
>>> I am posting it here.
>> This backtrace is not usable, it doesn't contains any symbols:
>> 
>> Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
>> 0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
>> (gdb) bt
>> #0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
>> #1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
>> #2  0x20017584 in ?? ()
>> (...)
>> 
>> The "??" indicates you don't have debug symbols installed.
>> 
>> Adrian
>> 
> 

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Christian Zigotzky]

Hi Herminio,

If you want to backtrace Firefox, then you need the debug version of 
Firefox. Please add the following repositories to your 
/etc/apt/sources.list:


deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
deb http://debug.mirrors.debian.org/debian-debug/ experimental-debug main

You have to install the Firefox package with dbgsym attached:

apt-get install -t experimental firefox-dbgsym

Many thanks for your help.

Cheers,
Christian

On 12 February 2017 at 10:18 AM, John Paul Adrian Glaubitz wrote:

On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:

I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. I 
am posting it here.

This backtrace is not usable, it doesn't contains any symbols:

Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
(gdb) bt
#0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
#1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
#2  0x20017584 in ?? ()
(...)

The "??" indicates you don't have debug symbols installed.

Adrian

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez Jr.]

You are right. I will install them and run again. 

Sent from my iPhone

> On Feb 12, 2017, at 2:18 AM, John Paul Adrian Glaubitz 
> <glaub...@physik.fu-berlin.de> wrote:
> 
>> On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:
>> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. 
>> I am posting it here.
> 
> This backtrace is not usable, it doesn't contains any symbols:
> 
> Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
> 0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
> (gdb) bt
> #0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
> #1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
> #2  0x20017584 in ?? ()
> (...)
> 
> The "??" indicates you don't have debug symbols installed.
> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[luigi burdo]

the strange it is working  without issue if i dont count the strange webm 
0x0x24 resolution in video (no video) on fedora and ubuntu mate 16.10.
and on mate i was using the debian sid build.

luigi
Inviato da iPad

> Il giorno 12 feb 2017, alle ore 10:19, John Paul Adrian Glaubitz 
> <glaub...@physik.fu-berlin.de> ha scritto:
> 
>> On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:
>> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. 
>> I am posting it here.
> 
> This backtrace is not usable, it doesn't contains any symbols:
> 
> Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
> 0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
> (gdb) bt
> #0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
> #1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
> #2  0x20017584 in ?? ()
> (...)
> 
> The "??" indicates you don't have debug symbols installed.
> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

On 02/12/2017 08:37 AM, Herminio Hernandez, Jr. wrote:
> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. I 
> am posting it here.

This backtrace is not usable, it doesn't contains any symbols:

Thread 1 "firefox.real" received signal SIGSEGV, Segmentation fault.
0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
(gdb) bt
#0  0x1ae2ddf8 in ?? () from /usr/lib/firefox/libxul.so
#1  0x1ae2eed4 in ?? () from /usr/lib/firefox/libxul.so
#2  0x20017584 in ?? ()
(...)

The "??" indicates you don't have debug symbols installed.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Christian Zigotzky]

Thank you! :-)

-- Christian

Sent from my iPhone

> On 12 Feb 2017, at 08:37, Herminio Hernandez, Jr. 
> <herminio.hernande...@gmail.com> wrote:
> 
> I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace. I 
> am posting it here.
> 
> Herminio
> 
>> On Tue, Feb 7, 2017 at 12:49 AM, Christian Zigotzky <chzigot...@xenosoft.de> 
>> wrote:
>> Could someone also test Firefox 51.0.1-1? My gdb closes after the command 
>> 'run'.
>> 
>> -- Christian
>> 
>> Sent from my iPhone
>> 
>> > On 7 Feb 2017, at 00:09, Christian Zigotzky <chzigot...@xenosoft.de> wrote:
>> >
>> > Unfortunately, gdb has closed after the command 'run'. It's not possible 
>> > to get a backtrace.
>> >
>> >> On 07 February 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote:
>> >>> On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
>> >>> (gdb) run
>> >>>
>> >>> Starting program: /usr/lib/firefox/./firefox
>> >>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>> >>> Do you need "set solib-search-path" or "set sysroot"?
>> >>> [Thread debugging using libthread_db enabled]
>> >>> Using host libthread_db library 
>> >>> "/lib/powerpc-linux-gnu/libthread_db.so.1".
>> >>> Dwarf Error: wrong version in compilation unit header (is 7, should be 
>> >>> 2, 3, or 4) [in module
>> >>> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
>> >>> Dwarf Error: wrong version in compilation unit header (is 0, should be 
>> >>> 2, 3, or 4) [in module
>> >>> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
>> >>> Dwarf Error: wrong version in compilation unit header (is 0, should be 
>> >>> 2, 3, or 4) [in module
>> >>> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
>> >>> Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 
>> >>> 0x0 + 6) [in module
>> >>> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
>> >>> Segmentation fault
>> >> And what's the backtrace?
>> >>
>> >
>> 
> 
> 

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez, Jr.]

I ran firefox 51 on my iBook G4 running Sid. I was able to get a backtrace.
I am posting it here.

Herminio

On Tue, Feb 7, 2017 at 12:49 AM, Christian Zigotzky <chzigot...@xenosoft.de>
wrote:

> Could someone also test Firefox 51.0.1-1? My gdb closes after the command
> 'run'.
>
> -- Christian
>
> Sent from my iPhone
>
> > On 7 Feb 2017, at 00:09, Christian Zigotzky <chzigot...@xenosoft.de>
> wrote:
> >
> > Unfortunately, gdb has closed after the command 'run'. It's not possible
> to get a backtrace.
> >
> >> On 07 February 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote:
> >>> On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
> >>> (gdb) run
> >>>
> >>> Starting program: /usr/lib/firefox/./firefox
> >>> warning: Could not load shared library symbols for linux-vdso32.so.1.
> >>> Do you need "set solib-search-path" or "set sysroot"?
> >>> [Thread debugging using libthread_db enabled]
> >>> Using host libthread_db library "/lib/powerpc-linux-gnu/
> libthread_db.so.1".
> >>> Dwarf Error: wrong version in compilation unit header (is 7, should be
> 2, 3, or 4) [in module
> >>> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325c
> b9e187bf.debug]
> >>> Dwarf Error: wrong version in compilation unit header (is 0, should be
> 2, 3, or 4) [in module
> >>> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f408
> 4391a20c.debug]
> >>> Dwarf Error: wrong version in compilation unit header (is 0, should be
> 2, 3, or 4) [in module
> >>> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba
> 3a2ec5ce.debug]
> >>> Dwarf Error: bad offset (0x3e83) in compilation unit header
> (offset 0x0 + 6) [in module
> >>> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a9
> 76ed9a68.debug]
> >>> Segmentation fault
> >> And what's the backtrace?
> >>
> >
>
>


firefox.real-gdb.log
Description: Binary data

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Michel Dänzer]

On 07/02/17 08:04 AM, John Paul Adrian Glaubitz wrote:
> On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
>> (gdb) run
>>
>> Starting program: /usr/lib/firefox/./firefox
>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
>> Dwarf Error: wrong version in compilation unit header (is 7, should be 2, 3, 
>> or 4) [in module
>> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 
>> or 4) [in module
>> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 
>> or 4) [in module
>> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
>> Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 0x0 
>> + 6) [in module
>> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
>> Segmentation fault
> 
> And what's the backtrace?

Since there's no gdb prompt after the crash, the output above looks like
gdb itself crashes.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Christian Zigotzky]

Could someone also test Firefox 51.0.1-1? My gdb closes after the command 'run'.

-- Christian

Sent from my iPhone

> On 7 Feb 2017, at 00:09, Christian Zigotzky <chzigot...@xenosoft.de> wrote:
> 
> Unfortunately, gdb has closed after the command 'run'. It's not possible to 
> get a backtrace.
> 
>> On 07 February 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote:
>>> On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
>>> (gdb) run
>>> 
>>> Starting program: /usr/lib/firefox/./firefox
>>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>>> Do you need "set solib-search-path" or "set sysroot"?
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
>>> Dwarf Error: wrong version in compilation unit header (is 7, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
>>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
>>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
>>> Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 0x0 
>>> + 6) [in module
>>> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
>>> Segmentation fault
>> And what's the backtrace?
>> 
> 

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

On 02/07/2017 06:16 AM, Herminio Hernandez Jr.  wrote:
> Isn't there a logging feature that will capture it?

You don't get the backtrace from these logs. You need gdb for that.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Herminio Hernandez Jr.]

Isn't there a logging feature that will capture it?

Sent from my iPhone

> On Feb 6, 2017, at 4:09 PM, Christian Zigotzky <chzigot...@xenosoft.de> wrote:
> 
> Unfortunately, gdb has closed after the command 'run'. It's not possible to 
> get a backtrace.
> 
>> On 07 February 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote:
>>> On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
>>> (gdb) run
>>> 
>>> Starting program: /usr/lib/firefox/./firefox
>>> warning: Could not load shared library symbols for linux-vdso32.so.1.
>>> Do you need "set solib-search-path" or "set sysroot"?
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
>>> Dwarf Error: wrong version in compilation unit header (is 7, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
>>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
>>> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 
>>> 3, or 4) [in module
>>> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
>>> Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 0x0 
>>> + 6) [in module
>>> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
>>> Segmentation fault
>> And what's the backtrace?
>> 
> 

Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Christian Zigotzky]

Unfortunately, gdb has closed after the command 'run'. It's not possible 
to get a backtrace.


On 07 February 2017 at 12:04 AM, John Paul Adrian Glaubitz wrote:

On 02/07/2017 12:02 AM, Christian Zigotzky wrote:

(gdb) run

Starting program: /usr/lib/firefox/./firefox
warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 7, should be 2, 3, or 
4) [in module
/usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 
4) [in module
/usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, or 
4) [in module
/usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 0x0 + 
6) [in module
/usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
Segmentation fault

And what's the backtrace?

Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Christian Zigotzky]

Hi Adrian,

apt-get install -t experimental firefox-dbgsym

Preparing to unpack .../firefox-dbgsym_51.0.1-1_powerpc.deb ...
Unpacking firefox-dbgsym (51.0.1-1) ...
Setting up firefox-dbgsym (51.0.1-1) ...

apt-get install -t experimental firefox-dev-dbgsym

Setting up firefox-dev (51.0.1-1) ...
Setting up firefox-dev-dbgsym (51.0.1-1) ...

It's working.

gdb ./firefox

GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/firefox/firefox...Reading symbols from 
/usr/lib/debug/.build-id/a6/81b7e65ae15687f43f84f7c55dfc4626f13bda.debug...Dwarf 
Error: wrong version in compilation unit header (is 6, should be 2, 3, 
or 4) [in module 
/usr/lib/debug/.build-id/a6/81b7e65ae15687f43f84f7c55dfc4626f13bda.debug]

(no debugging symbols found)...done.
(no debugging symbols found)...done.

(gdb) run

Starting program: /usr/lib/firefox/./firefox
warning: Could not load shared library symbols for linux-vdso32.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is 7, should be 
2, 3, or 4) [in module 
/usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 
2, 3, or 4) [in module 
/usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
Dwarf Error: wrong version in compilation unit header (is 0, should be 
2, 3, or 4) [in module 
/usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 
0x0 + 6) [in module 
/usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]

Segmentation fault

Cheers,
Christian

On 06 February 2017 at 11:42 PM, John Paul Adrian Glaubitz wrote:

On 02/06/2017 11:36 PM, Christian Zigotzky wrote:

Which package should I install?

firefox-dbgsym should be enough. If not, installing the other
package as well shouldn't hurt either.

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[John Paul Adrian Glaubitz]

On 02/07/2017 12:02 AM, Christian Zigotzky wrote:
> (gdb) run
> 
> Starting program: /usr/lib/firefox/./firefox
> warning: Could not load shared library symbols for linux-vdso32.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
> Dwarf Error: wrong version in compilation unit header (is 7, should be 2, 3, 
> or 4) [in module
> /usr/lib/debug/.build-id/18/ea31ffd1c49eaf7be933acec89325cb9e187bf.debug]
> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 
> or 4) [in module
> /usr/lib/debug/.build-id/26/a1e97b21731a564ed396149593f4084391a20c.debug]
> Dwarf Error: wrong version in compilation unit header (is 0, should be 2, 3, 
> or 4) [in module
> /usr/lib/debug/.build-id/7a/f876d1dcfc23d59299dd09539d4dba3a2ec5ce.debug]
> Dwarf Error: bad offset (0x3e83) in compilation unit header (offset 0x0 + 
> 6) [in module
> /usr/lib/debug/.build-id/7c/05723a7ada75d51fd4a85a036351a976ed9a68.debug]
> Segmentation fault

And what's the backtrace?

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913