Package Details: firefox-nightly 128.0a1+20240526.1+h277ccd163bbc-1

Git Clone URL: https://aur.archlinux.org/firefox-nightly.git (read-only, click to copy)
Package Base: firefox-nightly
Description: Development version of the popular Firefox web browser
Upstream URL: https://www.mozilla.org/firefox/channel/#nightly
Keywords: browser gecko web
Licenses: MPL-2.0
Submitter: None
Maintainer: heftig
Last Packager: heftig
Votes: 609
Popularity: 0.54
First Submitted: 2008-09-10 14:23 (UTC)
Last Updated: 2024-05-26 13:51 (UTC)

Pinned Comments

heftig commented on 2022-07-27 22:26 (UTC)

Instead of building this yourself, please use the repository from https://bbs.archlinux.org/viewtopic.php?id=117157.

Not only do you skip the very time-consuming builds, but the published package also has debug symbols at Mozilla's crash reports service, which helps tremendously with finding or filing bugs for any crashes you get.

I consider this the canonical firefox-nightly package for Arch Linux.

[heftig]
SigLevel = Optional
Server = https://pkgbuild.com/~heftig/repo/$arch

Alternatively, download Firefox Nightly straight from Mozilla, extract it to a writable place (e.g. ~/.local/firefox-nightly) and let it update itself using the integrated updater.

Latest Comments

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 56 Next › Last »

Archange commented on 2017-11-14 15:15 (UTC)

Hum they changed that between y-day and today… I’ve updated the package to correctly install icons based on the new locations.

ananaso commented on 2017-11-14 14:28 (UTC)

/icons/mozicon128.png doesn't seem to exist, which causes the PKGBUILD to fail. Removing line 65 (install -Dm644 "${SRC_LOC}"/icons/mozicon128.png "${DEST_LOC}"/128x128/apps/${pkgname}.png) solves the issue.

Archange commented on 2017-11-13 21:49 (UTC)

Outside of recompiling (personally I have in head the idea of switching to building nightlies for several reasons, starting by aligning with repo package), not sure anything can be done about this.

jcstryker commented on 2017-11-13 20:49 (UTC)

can something be done about the locked toolkit.telemetry.enabled;true in the latest nightly releases Discussed here: https://medium.com/georg-fritzsche/data-preference-changes-in-firefox-58-2d5df9c428b5

Archange commented on 2017-10-07 10:23 (UTC)

If you get bad signatures, retry a bit after (like 1 h). The download is handled by CDN, so the .sig file and the tarball might actually differ because of not being cached at the same time. The TTL was set to 1 h instead of 24 h to mitigate this, but you might still fall into a window where a new build has been published and one of the two files is still cached from previous build.

bemeurer commented on 2017-10-07 06:18 (UTC)

I second saghm's issue. I get `FAILED (bad signature from public key BBBEBDBB24C6F355)` as well, independent of having the correct keys imported.

saghm commented on 2017-09-25 18:32 (UTC)

I'm getting a "bad signature from public key" error when trying updating to 58.0a1. (I tried reimporting the key with gpg just in case, but it reported it as unchanged).

z3ntu commented on 2017-09-22 06:12 (UTC)

58.0a1 files are available!