Re: Mozilla Software on Sparc64/Linux
Hello Adrian, did the working rust based firefox make it into a released package? The only packaged version of firefox i could get to run was firefox50. And i have tested all higher available version of firefox and firefox-esr on snapshot.debian.org Regards, Connor On Mon, Nov 15, 2021 at 1:06 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 11/14/21 17:58, Riccardo Mottola wrote: > >> i would be very interested in getting Firefox and Thunderbird (and > possibly > >> Seamonkey, but this isn't available at all with debian it seam) > running, if > >> possible at all for the newer versions. > > > > yes, SeaMonkey is for me a missed package for both Debian/Devuan and > FreeBSD. > > I just love it. I like the classic interface and can't stand the > chrome-like > > of Firefox. > > There is currently no one willing to step up being the maintainer of > Seamonkey > in Debian which is why it's currently not included. > > > SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It > should > > be a decent candidate to get it running on SPARC, since a specific Mac > PPC G5 > > version was maintained for a long time. Current SM is FF 60 based and so > has rust > > Rust is available on SPARC and fully supported. > > >> Rust seems not to be an issue any more for sparc64/linux, but the > general upstream > >> neglect of sparc64 seems to be the major problem. > > > > Rust is evil... however as you write it does not to be the biggest > problem here. > > Calling Rust "evil" is not a technical argument but an emotional one. > > > The major issue is endianness - current FireFox runs on PPC64 but is > totally unusable. > > Everything in the UI has mangled colors, endianness is broken at about > every level. > > E.g. FF relies now a lot on skia and officially it will never support > BE. And so a > > lot of other issues, including Mesa. > > As I mentioned before, Oracle officially support Firefox on Solaris on > SPARC and thus > on a big-endian system. Debian ships Firefox on s390x as a supported > package. > > Claiming that Firefox is a mess on big-endian is definitely not accurate > although > Firefox upstream does not officially support big-endian targets, but they > don't > prevent it either. > > > Add to endianness issues that SPARCs are sensitive to memory alignment > and issues and you get the crashes. > > The more Rust code Firefox has, the less likely this is going to happen as > Rust is much > stricter with alignment than C/C++. > > > I am working since a long time on ArcticFox and intend to keep it as > much as possible > > cross-platform, close to Firefox, but incorporating as many fixes done > for TenFourFox > > as I can. Currently, it is quite usable on PPC, although there are > endianness issues > > with image composition operations. I can browser Wikipedia and even > watch a youtube > > video with audio. That is already impossible with standard Firefox. > > Well, it's based on an ancient Firefox code base which is why it still has > many of the > old bugs that have been fixed in the mean time. > > >> I would like to hear opinions on how to proceed or if you think this is > a lost cause? > > > > > > It is not a lost cause, but it is a hard cause, not well supported by > upstream. I intend > > to generalize a lot of TenFourFox patches in ArcticFox, but it requires > work. > > > > NetBSD should have a working FF (I think FF 52) on SPARC. > > > > I was finally able to compile ArcticFox on NetBSD/SPARC64 and > Linux/SPARC64. It will start, > > show a window but crash very soon. That's already an improvement > compared to crashing immediately > > as it did one year ago! > > We have already had a fully working Rust-based Firefox on SPARC. I don't > think it's a good > idea to use these ancient versions, especially since there is no official > security support. > > > For this cause, I need help - I am working alone and I have no real > Gecko knowledge. I need > > to port patches from Gecko to improve certain parts, so I need somebody > how knows Firefox > > code more than me to help me understand why certain give issues. Not > specific SPARC, but I > > work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my > netra T1 takes 20 hours > > to compile ArcticFox) So if you know somebody who can help me with > some specific issues > > please ping me. I have some blocking issues I need to solve so that > ArcticFox doesn't die > > out and can evolve, specifically some JavaScript and JIT issues, > currently verified on Intel. > > It's probably a better idea to start working on separating the Javascript > transpilation process > in the Firefox build system from the build process for the native code as > this will remove > the NodeJS build dependency for Firefox. > > Firefox itself does not require NodeJS. It's just that the Mozilla > developers decided to pull > in NodeJS as a hard dependency for the build so that the Javascript files > are always freshly >
Re: Mozilla Software on Sparc64/Linux
Hello! On 11/14/21 17:58, Riccardo Mottola wrote: >> i would be very interested in getting Firefox and Thunderbird (and possibly >> Seamonkey, but this isn't available at all with debian it seam) running, if >> possible at all for the newer versions. > > yes, SeaMonkey is for me a missed package for both Debian/Devuan and FreeBSD. > I just love it. I like the classic interface and can't stand the chrome-like > of Firefox. There is currently no one willing to step up being the maintainer of Seamonkey in Debian which is why it's currently not included. > SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It should > be a decent candidate to get it running on SPARC, since a specific Mac PPC G5 > version was maintained for a long time. Current SM is FF 60 based and so has > rust Rust is available on SPARC and fully supported. >> Rust seems not to be an issue any more for sparc64/linux, but the general >> upstream >> neglect of sparc64 seems to be the major problem. > > Rust is evil... however as you write it does not to be the biggest problem > here. Calling Rust "evil" is not a technical argument but an emotional one. > The major issue is endianness - current FireFox runs on PPC64 but is totally > unusable. > Everything in the UI has mangled colors, endianness is broken at about every > level. > E.g. FF relies now a lot on skia and officially it will never support BE. And > so a > lot of other issues, including Mesa. As I mentioned before, Oracle officially support Firefox on Solaris on SPARC and thus on a big-endian system. Debian ships Firefox on s390x as a supported package. Claiming that Firefox is a mess on big-endian is definitely not accurate although Firefox upstream does not officially support big-endian targets, but they don't prevent it either. > Add to endianness issues that SPARCs are sensitive to memory alignment and > issues and you get the crashes. The more Rust code Firefox has, the less likely this is going to happen as Rust is much stricter with alignment than C/C++. > I am working since a long time on ArcticFox and intend to keep it as much as > possible > cross-platform, close to Firefox, but incorporating as many fixes done for > TenFourFox > as I can. Currently, it is quite usable on PPC, although there are endianness > issues > with image composition operations. I can browser Wikipedia and even watch a > youtube > video with audio. That is already impossible with standard Firefox. Well, it's based on an ancient Firefox code base which is why it still has many of the old bugs that have been fixed in the mean time. >> I would like to hear opinions on how to proceed or if you think this is a >> lost cause? > > > It is not a lost cause, but it is a hard cause, not well supported by > upstream. I intend > to generalize a lot of TenFourFox patches in ArcticFox, but it requires work. > > NetBSD should have a working FF (I think FF 52) on SPARC. > > I was finally able to compile ArcticFox on NetBSD/SPARC64 and Linux/SPARC64. > It will start, > show a window but crash very soon. That's already an improvement compared to > crashing immediately > as it did one year ago! We have already had a fully working Rust-based Firefox on SPARC. I don't think it's a good idea to use these ancient versions, especially since there is no official security support. > For this cause, I need help - I am working alone and I have no real Gecko > knowledge. I need > to port patches from Gecko to improve certain parts, so I need somebody how > knows Firefox > code more than me to help me understand why certain give issues. Not specific > SPARC, but I > work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1 > takes 20 hours > to compile ArcticFox) So if you know somebody who can help me with some > specific issues > please ping me. I have some blocking issues I need to solve so that ArcticFox > doesn't die > out and can evolve, specifically some JavaScript and JIT issues, currently > verified on Intel. It's probably a better idea to start working on separating the Javascript transpilation process in the Firefox build system from the build process for the native code as this will remove the NodeJS build dependency for Firefox. Firefox itself does not require NodeJS. It's just that the Mozilla developers decided to pull in NodeJS as a hard dependency for the build so that the Javascript files are always freshly transpiled from the source. However, the transpilation process does not necessarily have to happen on the same architecture and one can transpile the Javascript files on x86_64 and copy them into the Firefox build tree later. This is what Oracle does on Solaris and we could do the same on Debian by moving the transpiled Javascript packages into a firefox-common package which will be used by the firefox package on the various architectures. This way we could use current versions of Firefox and wouldn't be stuck
Re: Mozilla Software on Sparc64/Linux
Hi Riccardo, thank you for your reply and insights into the matter. I have Firefox52 and Thunderbird52 up and running on NetBSD9.2/Sparc64 compiled from pkgsrc. Now i wanted to do the same on Debian/Sparc64, but the pkgsrc patches seem to be custom created for NetBSD by Martin Husemann, and they will not build on Debian ootb. While NetBSD is a fine system, i can get more software to compile and run on Debian/Sparc64, like Libreoffice, xrdp-server and others. NetBSD is also missing rust and ada on sparc64. On Debian I tried to apply various sparc64 patches i found left and right on the internet, could get pkgsrc's firefox52 and thunderbird52 to build but they will not run and bus error out in libxul.so. So i will try soon to rebuild firefox50 from debian source package as Adrian told and try to apply some patches i found for the "[GFX1]: Unknown image format 1" errors and others that are filling up the console. But as these versions are old and not security fixed, it makes less and less sense to use those for anything on the internet. This led me to the fitting of Raspberry-Pis 3 into my workstations which will display their up-to-date browsers on the screen via ssh x forwarding. But of course this is cheating, i would rather have them do it natively on their own. So I will also try to build your ArcticFox. Somehow i did not come across it yet, thank you for the suggestion. Unfortunately i am an intermediate end user in this regard. I can apply patches, work around certain library problems and get stuff to compile, but i can't help with coding. So if it helps at all, if someone compiles and tests it, let me know. Sparc64 as a platform is almost dead and i know that as a result most projects still doing something for it are mostly one-man shows. But it is still fun to have the boxes running and i am also still planning to get some of those beefier T3-T8 servers once they are cheaply available on ebay and when i have more experience in quieting them down without killing them. Regards, Connor On Sun, Nov 14, 2021 at 6:06 PM Riccardo Mottola wrote: > Hi Connor, > > > you touch a delicate subject. You touch both endianness and SPARC cpu in > > On 11/6/21 5:05 PM, Connor McLaughlan wrote: > > Hello All, > > > > i would be very interested in getting Firefox and Thunderbird (and > > possibly Seamonkey, but this isn't available at all with debian it > > seam) running, if possible at all for the newer versions. > > > yes, SeaMonkey is for me a missed package for both Debian/Devuan and > FreeBSD. I just love it. I like the classic interface and can't stand > the chrome-like of Firefox. > > SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It > should be a decent candidate to get it running on SPARC, since a > specific Mac PPC G5 version was maintained for a long time. Current SM > is FF 60 based and so has rust > > > > > > Rust seems not to be an issue any more for sparc64/linux, but the > > general upstream neglect of sparc64 seems to be the major problem. > > Rust is evil... however as you write it does not to be the biggest > problem here. > > The major issue is endianness - current FireFox runs on PPC64 but is > totally unusable. Everything in the UI has mangled colors, endianness is > broken at about every level. E.g. FF relies now a lot on skia and > officially it will never support BE. And so a lot of other issues, > including Mesa. > > Add to endianness issues that SPARCs are sensitive to memory alignment > and issues and you get the crashes. > > > I follow the Big Endian issues closely, since I am interested in getting > a usable browser on PPC, but it is an uphill road. I have been in > contact for a long time with Cameron Kaiser who maintained TenFourFox > (winding down activity right this year) and which as an excellent > browser on MacOS PPC. Some of his patches were accepted upstream, but > several not. His browser fork however is heavily MacOS 10.4 optimized > (hence the name). > > I am working since a long time on ArcticFox and intend to keep it as > much as possible cross-platform, close to Firefox, but incorporating as > many fixes done for TenFourFox as I can. Currently, it is quite usable > on PPC, although there are endianness issues with image composition > operations. I can browser Wikipedia and even watch a youtube video with > audio. That is already impossible with standard Firefox. > > > > > > I would like to hear opinions on how to proceed or if you think this > > is a lost cause? > > > It is not a lost cause, but it is a hard cause, not well supported by > upstream. I intend to generalize a lot of TenFourFox patches in > ArcticFox, but it requires work. > > NetBSD should have a working FF (I think FF 52) on SPARC. > > I was finally able to compile ArcticFox on NetBSD/SPARC64 and > Linux/SPARC64. It will start, show a window but crash very soon. That's > already an improvement compared to crashing immediately as it did one > year ago! > > > For this cause, I
Re: Mozilla Software on Sparc64/Linux
Hi Connor, you touch a delicate subject. You touch both endianness and SPARC cpu in On 11/6/21 5:05 PM, Connor McLaughlan wrote: Hello All, i would be very interested in getting Firefox and Thunderbird (and possibly Seamonkey, but this isn't available at all with debian it seam) running, if possible at all for the newer versions. yes, SeaMonkey is for me a missed package for both Debian/Devuan and FreeBSD. I just love it. I like the classic interface and can't stand the chrome-like of Firefox. SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It should be a decent candidate to get it running on SPARC, since a specific Mac PPC G5 version was maintained for a long time. Current SM is FF 60 based and so has rust Rust seems not to be an issue any more for sparc64/linux, but the general upstream neglect of sparc64 seems to be the major problem. Rust is evil... however as you write it does not to be the biggest problem here. The major issue is endianness - current FireFox runs on PPC64 but is totally unusable. Everything in the UI has mangled colors, endianness is broken at about every level. E.g. FF relies now a lot on skia and officially it will never support BE. And so a lot of other issues, including Mesa. Add to endianness issues that SPARCs are sensitive to memory alignment and issues and you get the crashes. I follow the Big Endian issues closely, since I am interested in getting a usable browser on PPC, but it is an uphill road. I have been in contact for a long time with Cameron Kaiser who maintained TenFourFox (winding down activity right this year) and which as an excellent browser on MacOS PPC. Some of his patches were accepted upstream, but several not. His browser fork however is heavily MacOS 10.4 optimized (hence the name). I am working since a long time on ArcticFox and intend to keep it as much as possible cross-platform, close to Firefox, but incorporating as many fixes done for TenFourFox as I can. Currently, it is quite usable on PPC, although there are endianness issues with image composition operations. I can browser Wikipedia and even watch a youtube video with audio. That is already impossible with standard Firefox. I would like to hear opinions on how to proceed or if you think this is a lost cause? It is not a lost cause, but it is a hard cause, not well supported by upstream. I intend to generalize a lot of TenFourFox patches in ArcticFox, but it requires work. NetBSD should have a working FF (I think FF 52) on SPARC. I was finally able to compile ArcticFox on NetBSD/SPARC64 and Linux/SPARC64. It will start, show a window but crash very soon. That's already an improvement compared to crashing immediately as it did one year ago! For this cause, I need help - I am working alone and I have no real Gecko knowledge. I need to port patches from Gecko to improve certain parts, so I need somebody how knows Firefox code more than me to help me understand why certain give issues. Not specific SPARC, but I work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1 takes 20 hours to compile ArcticFox) So if you know somebody who can help me with some specific issues please ping me. I have some blocking issues I need to solve so that ArcticFox doesn't die out and can evolve, specifically some JavaScript and JIT issues, currently verified on Intel. I have the hardware, I can test and often GDB stacktraces are quite meaningless if a debug is not used. I need real "code" help, if you know somebody, please point him. Riccardo
