Package Details: firefox-nightly 137.0a1+20250213.1+h67ec343f7371-1

Git Clone URL: https://aur.archlinux.org/firefox-nightly.git (read-only, click to copy)
Package Base: firefox-nightly
Description: Fast, Private & Safe Web Browser (Nightly version)
Upstream URL: https://www.mozilla.org/firefox/channel/desktop/#nightly
Keywords: browser gecko web
Licenses: MPL-2.0
Submitter: None
Maintainer: heftig
Last Packager: heftig
Votes: 615
Popularity: 1.49
First Submitted: 2008-09-10 14:23 (UTC)
Last Updated: 2025-02-13 07:59 (UTC)

Sources (5)

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 .. 45 46 47 48 49 50 51 52 53 54 55 56 Next › Last »

eca commented on 2011-02-07 20:09 (UTC)

Easier, but somewhat risky workaround-run firefox-nightly as root then help>about>update.

xenom commented on 2011-02-07 20:07 (UTC)

I won't use the mar files because : 1) We need to find the external number, and I need to be sure the external number is correct, else it can break the PKGBUILD. 2) Use of mar files make a complex PKGBUILD, that won't match all the user preferences, and can cause problem with AUR helper. 3) Update can crash a running instance of firefox. Even if someone can make a nice patch, with a sure (and verified) way to find the external number, and no problem with AUR helper, I'm not sure I would merge it, just because of 3.

cgirard commented on 2011-02-07 19:29 (UTC)

Well, even if we do understand this numbering, one point is worrying me: "It is recommended that all instances of the application that are running on the system including those being used by other users are closed before going any further. Important: though this should never cause the update to fail there might be cases where it will and it can definitely break a running instance of the application." You cannot ask the user to close all firefox instances before running the update. And crashing its running instance is bad as well...

Det commented on 2011-02-07 19:22 (UTC)

So we'd need to find out not only the date of the latest trunk release but that external number part too, which separates different releases for the same date (the scheme goes: [year]-[month]-[date]-[the-external-number]-mozilla-central eg. 2011-02-07-03-mozilla-central). Great. Bug #1745010581, Action #1792740281 - Status change: New → Feature Request Bug #1745010581, Action #1792740286 - Status change: Feature Request → Patches Welcome

cgirard commented on 2011-02-07 16:21 (UTC)

You're right. They are available there: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-02-07-03-mozilla-central/firefox-4.0b12pre.en-US.linux-x86_64.partial.20110206030345-20110207030345.mar but it seems difficult to use them as we need to know the exact version we are updating from and to.

Det commented on 2011-02-07 15:46 (UTC)

Those are the complete ones - not the partial ones.

cgirard commented on 2011-02-07 10:01 (UTC)

I guess there : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ but it's as big as the bz2.

« First ‹ Previous 1 .. 45 46 47 48 49 50 51 52 53 54 55 56 Next › Last »