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 > 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 to > old and buggy > versions. I have already a concept for the common package, but I didn't > have the time for > turning the concept into code yet. > > 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 > >
