Package Details: firefox-nightly 81.0a1.20200727-1

Git Clone URL: https://aur.archlinux.org/firefox-nightly.git (read-only, click to copy)
Package Base: firefox-nightly
Description: Standalone Web Browser from Mozilla — Nightly build (en-US)
Upstream URL: https://www.mozilla.org/en-US/firefox/nightly
Keywords: browser gecko web
Licenses: GPL, MPL, LGPL
Submitter: None
Maintainer: Archange
Last Packager: Archange
Votes: 576
Popularity: 3.71
First Submitted: 2008-09-10 14:23
Last Updated: 2020-07-28 09:34

Required by (95)

Sources (8)

Pinned Comments

Archange commented on 2017-06-15 12:42

If you face this:

==> Verifying source file signatures with gpg... yyyymmdd-firefox-xx.0a1.en-US.linux-${CARCH}.tar.bz2 ... FAILED (unknown public key BBBEBDBB24C6F355)

Please read this.

Short answer:

gpg --recv-key 0x61B7B526D98F0353

If you face this:

==> Verifying source file signatures with gpg... yyyymmdd-firefox-xx.0a1.en-US.linux-${CARCH}.tar.bz2 ... FAILED (bad signature from public key BBBEBDBB24C6F355)

Then just retry later (~1h), this is a CDN caching issue.

Det commented on 2011-01-12 13:54

He wouldn't be the only one :). I just mailed him.

cgirard commented on 2011-01-12 09:15

@xenom : do you happen to read the comments sometimes ?

Det commented on 2011-01-11 20:15

b10_pre_

Xabre commented on 2011-01-11 17:28

b10 is out

cgirard commented on 2011-01-05 15:12

I've just tested it and yes, it does not, as expected.

The thing is I have asked xenom to add the "-N" option to wget to be able to be able to detect when the file has been changed on the server side. With your sha512sum hack, we do detect it but we need to manually delete the old source file.

I understand that having these wget, bsdtar and sha512sum is not really elegant, but at the end of the day the same operations are done ? Aren't they ?

@xenom: what do you think about this ? Either way a solution has to be taken because right now the PKGBUILD package the wrong file (download a file and package an older one already there).

Det commented on 2010-12-30 19:16

Ahh, gotcha. Well, I don't think it does. It just says that the checksum failed.

But really, since a new trunk build for Firefox is released _daily_ and not like every 10 minutes (as with Chromium), it's good enough.

I don't think there's even a way to trick makepkg e.g. to manually check whether the tarball passed the sha512sum check and if it wouldn't it would be replaced with a new one. That won't work because the sha512sum check is done _before_ the "build()" and "package()" functions are executed, meaning.. well, that it just wouldn't work.

I(ns)t(ead) _could_ be done that the tarball would *manually* be downloaded and then *manually* checked against the sha512sum in "http://ftp.mozilla.org" but that's just... stupid, if you ask me. The maintainer can choose to do that if he wishes to but I couldn't bring myself to care for that matter even if my life depended on it (just kidding).

cgirard commented on 2010-12-30 18:35

No what I meant is : does makepkg download a new copy of the file if an older version is already downloaded ?

Det commented on 2010-12-30 18:23

Yes it would. But if you look at the upload times you notice that the files are uploaded at the same time. To avoid exactly that.

cgirard commented on 2010-12-30 18:07

Won't the packaging just fail if the checksum is invalid (thus the file have been updated on the server side) ?

Det commented on 2010-12-30 17:46

No wait, forget that. It's better to do the downloading and checksumming through the "source=()" section, e.g. like this: http://aur.pastebin.com/zsp1R1hM

The only 'disadvantage' with this implementation is that the checksum section needs to be a "sha512sums=()" section. However the same files do not need to be redownloaded because they pass the sha512sum check.