Closed Bug 1678342 (linux-arm64) Opened 5 years ago Closed 8 months ago

Please provide an official linux ARM64 build

Categories

(Release Engineering :: General, enhancement, P4)

Product:
Release Engineering
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kittens, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Firefox for Android

Steps to reproduce:

  1. Go to https://www.mozilla.org/en-US/firefox/all/
  2. Select drop-down box for installers
  3. Look for Linux ARM64

Actual results:

No ARM64 build

Expected results:

ARM64 Linux build should be offered.

The distro builds tend to be altered in one way or another, so it's bad that there is no plain vanilla experience available for those users who want it. This is also problematic especially for users like me who like to run nightly and dev editions and report issues, because this way I don't know what bugs I need to report to the distro and which to Mozilla.

This is also especially problematic with Linux phones like the PinePhone, or Librem 5, all of which are ARM64, since this is a completely different form factor the Firefox Linux builds do somewhat poorly right now. That naturally means there are lot of UI bugs to file specifically, which is problematic if it's all done against distro builds that may also have changed the UI already.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → General
Product: Firefox → Firefox Build System
Product: Firefox Build System → Release Engineering
QA Contact: mtabara
Version: 78 Branch → unspecified

a) There is an official Firefox snap now which contains zero extra patches, and b) it looks like there's an ARM snap in https://snapcraft.io/firefox , for esr, beta, candidate, and stable.

Severity: -- → S4
Status: UNCONFIRMED → RESOLVED
Type: defect → enhancement
Closed: 4 years ago
Priority: -- → P4
Resolution: --- → FIXED
Summary: Please provide an official ARM64 build → Please provide an official linux ARM64 build

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #2)

a) There is an official Firefox snap now which contains zero extra patches, and b) it looks like there's an ARM snap in https://snapcraft.io/firefox , for esr, beta, candidate, and stable.

Hi :aki, could you please reconsider closing this issue? This bug report specifically ask for a binary build that doesn't need a third-party package manager (here Snap). This third-party may not be installed (or even supported by the distribution) on the user computer. It also opens the door of favorizing one package manager over the other (e.g What about supporting Flatpak).

Thanks :)

Flags: needinfo?(aki)

We can reopen this bug, but we likely won't prioritize it highly, so it may sit for a few years or more. Is that sufficient?

Flags: needinfo?(aki)

As an additional note: this ticket wasn't originally made with the idea of one limited container release anyway. Why can't there be a binary tarball release with a reasonably low GLIBC requirement instead? This would provide a much better foundation for all sorts of other distribution methods (it's e.g. trivial to make a flatpak release from that, I think, likely also a snap), and it's available for x86_64 as one of the defaults too. So why not for ARM64?

I believe that's because Canonical is doing the work for Snaps. If Flatpak maintainers want to do something similar, that sounds great to me.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---

To reiterate, the ticket asked for a binary tarball. See also original description and where it links to. Flatpak/containers really wasn't on the table. It sure did not ask for a THIRD-PARTY repackaging either, which you just suggested and which really seems to miss the point of the ticket:

The point of this ticket asking for an OFFICIAL release is 1.) it's unaltered, 2.) I can actually report bugs without all the indirections. Right now, ARM64 reporting of bugs is a pain because I always need to go to the distro first, and because there is no official release I never know if it's a distro repackaging bug, or if I can actually file it here directly (or I need to wait forever until it is forwarded). That workflow sucks. You should fix it.

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #4)

We can reopen this bug, but we likely won't prioritize it highly, so it may sit for a few years or more. Is that sufficient?

Thank you for reopening and taking the time to reply. I do understand that you may have more urgent things to work on. However, could you give us a bit more information on:

  1. What's making this issue hard to solve in the near future?
  2. Is there someone else at Mozilla we should/could ni? and see if this issue can be resolved sooner?
  3. Is there anything someone from the community could do to make it move faster?

Ellie I get your frustration but could you please tone it down a little. Saying things like "it suck" or "You should fix it" won't help. On the contrary, developers will be less open to discuss. I'll share our community participation guideline in case you didn't know about it https://www.mozilla.org/en-US/about/governance/policies/participation/. Thanks!

Flags: needinfo?(aki)

My apologies for my wording. Thanks for moving it forward constructively!

(In reply to Danny Colin [:sdk] from comment #9)

(In reply to Aki Sasaki [:aki] (he/him) (UTC-6) from comment #4)

We can reopen this bug, but we likely won't prioritize it highly, so it may sit for a few years or more. Is that sufficient?

Thank you for reopening and taking the time to reply. I do understand that you may have more urgent things to work on. However, could you give us a bit more information on:

  1. What's making this issue hard to solve in the near future?
  2. Is there someone else at Mozilla we should/could ni? and see if this issue can be resolved sooner?

The issue is that we have limited resources in terms of human time, so we need to prioritize those resources to target the work that will have the largest positive effect.

I know that adding official linux ARM64 release support is non-trivial in terms of human time. I'm under the impression that an official binary tarball of ARM linux builds is not likely to unlock large numbers of users or large markets that we haven't been able to reach otherwise. If that assumption is wrong, data showing that Mozilla would be best off using its limited resources targeting those users and markets would help us reprioritize this bug more highly.

  1. Is there anything someone from the community could do to make it move faster?

On the one side, the data mentioned above would help us prioritize the work needed to get this done.

On the other side, if we reduce how much work is needed to enable, it could be an easier discussion of "should we flip this switch" rather than "should we sink many weeks of human time into this project".

Steps here may include

If a contributor is able to create a patchset that enables linux arm64 release automation, then there's a significantly lower barrier to enabling those releases.

Ellie I get your frustration but could you please tone it down a little. Saying things like "it suck" or "You should fix it" won't help. On the contrary, developers will be less open to discuss. I'll share our community participation guideline in case you didn't know about it https://www.mozilla.org/en-US/about/governance/policies/participation/. Thanks!

Thank you.

(In reply to Ellie from comment #8)

The point of this ticket asking for an OFFICIAL release is 1.) it's unaltered

Aiui, Canonical is under contractual obligation to ship unaltered source. The official snaps are unaltered Mozilla source code.

about:buildconfig shows the configuration used to build the snap.

Flags: needinfo?(aki)

Note: there are already arm64 linux builds in CI, but they're not in a shape to be released (to begin with, they're not tested).

I'd like to chime in here in support for Arm64 builds.
Snap is not enough because it is not supported in Docker images.

My specific use case is Selenium WebDriver. Because there are no official place to download, it just downloads the Linux x64 version because it has no other choice.

Alpine has the only working firefox that works in docker. No other Linux distro in docker is usable for testing with Firefox.

Thank you!

I have some good news: bug 1867368 is on its way. We will provide Arm64 builds on Nightly to gather feedback from the Nightly community. Stay tuned 😃

Depends on: linux-arm64-nightly

Awesome!

Here's a link to Selenium bug report: https://github.com/SeleniumHQ/selenium/issues/13793

Alias: linux-arm64

It was great to see the announcement https://blog.nightly.mozilla.org/2024/04/19/firefox-nightly-now-available-for-linux-on-arm64/in April 2024, where it says:

Our goal is to integrate ARM64 builds into Firefox’s extensive automated test suite, which will enable us to offer this architecture across the beta, release, and ESR channels.

Is there any time-line on when Firefox Linux ARM64 (aka aarch64) would be available on the release channel?

QA Contact: mtabara

https://www.mozilla.org/en-US/firefox/136.0/releasenotes/ says:

On Linux, Firefox is now available on ARM64 (AArch64), with installation options via APT and tarballs. Flatpak support is coming soon.

so it appears that this request is resolved.

I still do not see Linux Arm64 here: https://www.mozilla.org/en-US/firefox/all/desktop-release/

...

  1. Platform: Choose from the list below Get help

Windows 64-bit
Windows 64-bit MSI
Windows ARM64/AArch64
Windows 32-bit
Windows 32-bit MSI
Microsoft Store
macOS
Linux 64-bit
Linux 32-bit

I have not been able to try it out yet, however I can see a download available here:

https://download-installer.cdn.mozilla.net/pub/firefox/releases/136.0/linux-aarch64/en-US/

I will keep this bug open until the builds are available in https://www.mozilla.org/

My patch landed and I see the builds in https://www.mozilla.org/en-US/firefox/all/

Status: REOPENED → RESOLVED
Closed: 4 years ago → 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.