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


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

Reply via email to