Package Details: firefox-nightly 127.0a1+20240430.1+h650dda918743-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: 1.01
First Submitted: 2008-09-10 14:23 (UTC)
Last Updated: 2024-04-30 09:10 (UTC)

Dependencies (38)

Required by (0)

Sources (4)

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 .. 4 5 6 7 8 9 10 11 12 13 14 .. 56 Next › Last »

hsantanna commented on 2021-05-14 16:14 (UTC) (edited on 2021-05-14 16:42 (UTC) by hsantanna)

Updated today (2021-05-14) to 90.0a1 (2021-05-13) and I'm getting compositor crash on KDE Plasma Wayland (kwin_wayland) every time firefox-nightly is started.

So I figured out that it was related to gfx.webrender.compositor.force-enabled=true about:config setting.

Opening firefox-nightly on XWayland and setting gfx.webrender.compositor.force-enabled=false solved the compositor crashing, so I can start the current nightly version as an Wayland client again.

I'm commenting it here just in case someone get to this problem.

Archange commented on 2021-05-14 11:05 (UTC)

@xuiqzy No, I thought about it of course, but that’s not possible in an acceptable way. The thing is we only know after downloading the file, at which point the renaming already happened.

So it would require downloading the file in a variable, i.e. as part of parsing the PKGBUILD. This was pointed as a very bad practice when I did so years ago for grabbing checksums when Mozilla wasn’t signing the tarball but only the checksums file.

xuiqzy commented on 2021-05-14 10:12 (UTC)

@Archange Great with the detailed pkgver! Could you also include this info in the filename so makepkg etc don't see the version from the same day as the same (cached) version but download the new one if it has a different version? Currently same day updates require that the downloaded old sources from the same day are not present in the build directory.

Archange commented on 2021-05-14 06:50 (UTC)

@ToadKing: I’ve tweaked the pkgver to be more descriptive now. As you suggested I’m now using the full build timestamp and also the mercurial revision (as in heftig package).

ToadKing commented on 2021-03-28 03:41 (UTC)

Is it possible to use the full 14 digit timestamp from the text file on the CDN server as the version number instead of just the year/month/day part? Nightly updates can often come twice in a day and having the exact version number for those might be helpful.

nrayamjhee commented on 2021-02-26 21:51 (UTC)

@SimPilotAdamT Just change the _version = 88.0a1 and pkgver = 88.0a1.20210226 in PKGBUILD and rebuild the package for now. @Archange is probably going to update that and .SRCINFO sometime soon. Just did that so that I can get the update with doge firefox logo :D

SimPilotAdamT commented on 2021-02-25 16:27 (UTC)

Any news on when the AUR version of Nightly is going to be updated? I am currently on 88.0a1, while AUR is still 87.0a1.

drugo commented on 2021-02-18 14:24 (UTC) (edited on 2021-02-18 19:03 (UTC) by drugo)

Hello, it is failing for me with a key error, but because of a bad signature instead of a missing key.

==> Verifying source file signatures with gpg...
    20210218-firefox-87.0a1.en-US.linux-x86_64.tar.bz2 ... FAILED (bad signature from public key F1A6668FBB7D572E)

The key was imported automatically during installation, and deleting and manually importing it leads to the same behaviour. Issue on their side?

EDIT: this happened with yay, cloning and installing manually worked (same check was made but passed for some reason)

masih commented on 2021-02-14 18:37 (UTC)

@Archange oh sorry i didn't know that

Archange commented on 2021-02-14 09:48 (UTC)

@masih Please stop flagging out-of-date, this PKGBUILD auto-update at build time unless the major version number changed (which won’t be the case before another two weeks at least).

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 56 Next › Last »