Package Details: firefox-aurora 52.0a2.20161209004005-1

Git Clone URL: (read-only)
Package Base: firefox-aurora
Description: Firefox Aurora channel - Nightly build
Upstream URL:
Keywords: firefox mozilla
Licenses: GPL, MPL, LGPL
Submitter: L42y
Maintainer: AlexTalker
Last Packager: AlexTalker
Votes: 312
Popularity: 3.122490
First Submitted: 2011-04-13 19:15
Last Updated: 2016-12-09 16:59

Latest Comments

kahnpro commented on 2016-11-23 01:38

Which day's build did you look at? Today's checksums are right, but at the time of writing I was using the Nov 19th build. I'm not using any custom PKGBUILD, I took it from a fresh clone of the git repo linked above. Steps to reproduce:

git clone
git checkout ff7f628b33632f775c3a2d58626f862c82b3ceb6
cd firefox-aurora
makepkg PKGBUILD

It seems like the Nov 20-22 builds are fine, but you might want to look into why it broke for that day's build.

AlexTalker commented on 2016-11-21 21:00

As always, check sums are right. IDK what is your problem but will appreciate if next time u show me PKGBUILD on which your building goes wrong.

kahnpro commented on 2016-11-20 16:55

Seems like the latest package has bad signatures. Won't install from pacaur after clearing cache... downloading the snapshot tar.gz and running makepkg from inside the folder also fails.

macheath commented on 2016-11-16 06:35

Sound stopped working without pulseaudio. Anyone has workwaround using alsa?

kahnpro commented on 2016-11-13 03:52

@evotopid You're absolutely right, I'm using pacaur and it's caching stuff in $HOME/.cache/pacaur/firefox-aurora. Removed this now it's able to verify and build the package. Thanks!

AlexTalker commented on 2016-11-12 18:16

@evotopid is right, I will think about integrate buildid in tarball name, but as I remember this could cause problems with obs. Will check soon.

evotopid commented on 2016-11-11 21:09

@kahnpro: Are you by any chance trying to update the package using an AUR helper which keeps the files around after building a package? In that case make sure the file is deleted when updating the package. I guess you should be able to configure such behavior in your AUR helper but you can also delete such a directory manually.

The PKGBUILD could also be updated to save the source file to a version dependent name. This fixes the problem for many users – though this is mostly about fixing a flaw in AUR helpers., some AUR helpers will accumulate quite some mass of files over time (I just checked mine and it's 3.9GB of files I don't need).

kahnpro commented on 2016-11-11 19:19

It still doesn't work.

==> Validating source_x86_64 files with sha512sums...
firefox-51.0a2.en-US.linux-x86_64.tar.bz2 ... FAILED
==> ERROR: One or more files did not pass the validity check!

AlexTalker commented on 2016-10-28 10:05

@evotopid I rewrite generator for this package with simple traversal starting from to daily release. No more broken hashsums :)))

AlexTalker commented on 2016-10-27 11:16

@evotopid Hello, thank you, I never thought about that :(
You script seems very clear to me and I think I'll find some time on holiday to fix mine that way.
By the way, I think a bit that add `git commit` and such things in PKGBUILD update generator is not very clear(since if ppl want to use it, the'll not need it usually). I cut that logic away in few shell scripts which keep abstraction around the whole updating, that's why only makes new PKGBUILD by template. But, that's question of code style and architecture more.
Thanks again for giving me the tip.
Also, u can use hashsums from the same directory as tarball, just one more request.

evotopid commented on 2016-10-27 11:07

@AlexTalker : On the Mozilla FTP server there are archive directories for the individual release versions so the kind of hash conflicts won't happen if you link to them instead of the binary that is updated daily. However updating the package gets a bit more tricky. Many Arch users (me included) don't want to add more repos to their system than they need.

You might want to check out my package "firefox-developer-de". I have a ruby script in the repo that I launch using a cron job that determines the most recent release and updates the PKGBUILD accordingly with the new hash. Caveat: so far it doesn't check signatures of the fetched file and just calculates the hash by downloading the file, I guess before wider deployment this might have to be fixed. (If you need further info you can write me an email.)

AlexTalker commented on 2016-10-27 10:20

What's wrong with u, folks?
I didn't said I wouldn't maintain this one. I just said I try to automatize it.

Sorry, I've got a little trouble, has to erase 'Template' package use by update script. Very sorry.

Yes, I wanna say that its better to use package from OpenSUSE build system than build manually 'cause here's will always be wrong hashes for some people 'cause I update the package around 4am, but new releases comes around 10am of local time. My laptop is usually offline all the day so I probably can't update to release as soon as it comes. I'll try to minimize that but most likely there's nothing to do. I just updated the package, sorry for interrupt.

Gharial commented on 2016-10-24 09:40

Please update the checksum for the 51.02.x86_64 tar in the PKGBUILD.

kahnpro commented on 2016-10-23 20:07

@AlexTalker I'm seconding this, the package right now does not build. If you no longer intend on maintaining this package then please orphan it and let someone else take over.

Anonymous comment on 2016-10-02 22:02

@AlexTalker please orphan this package if you no longer intend to maintain it. @LA-MJ is also correct.

ianks commented on 2016-10-02 19:41

@AlexTalker, so we should not use this AUR package anymore? I think the firefox page should be updated as such if this is the case.

AlexTalker commented on 2016-10-01 16:14

Hello, folks!

It was long time for me till my patch for Open Build System was applied on finally, so now I moved building of the package to there.

So, if u used my previous repo, you can easily use new one

SigLevel = Never
Server =$arch

Web view to project is here:

Now I hope will no more broken hashsums and mess in logs since I rewrite my scripts to automatic update this and few other packages to use OBS instead of building locally and push to my own old repo.

I hope u enjoy this improvement.

Also git of the package now contains 2 files, & PKGBUILD.template which I use to generate PKGBUILD using fresh information from vendor sites. U can as well use it yourself, just run

Have a lucky day!

LA-MJ commented on 2016-10-01 10:11

what's with the horrific mess that is the latest commits to this package?

AlexTalker commented on 2016-09-25 13:04

@growler sad, AFAIK .SRCINFO is updated right after successful building of package with makepkg(i did automatize the process), so I really don't know what could mismatch... and you show error output, please?

growler commented on 2016-09-21 22:40

firefox-aurora package(s) failed to install. Check .SRCINFO for mismatching data with PKGBUILD.

I deleted $TMP/pacaur* before building this, so all files were downloaded fresh, any idea the cause/fix of this checksum issue - it certainly isn't stale files on my system.

evotopid commented on 2016-08-03 19:06

Renaming the file by prepending "firefox_$pkgver.tar.bz2::" to the source file did the trick for me in firefox-developer-de. Pacaur will still accumulate files in its cache though (but builds won't fail).

jP_wanN commented on 2016-07-23 12:58

Oh okay, that's pacaur's fault then I guess. Is there no way around having to delete that file?

piemonkey commented on 2016-07-23 11:43

@jP_wanN You need to delete the firefox-<version>.en-US.linux-x86_64.tar.bz2 file. The version number is the same even though the build changes nightly, so it doesn't download the new one unless you manually delete. Maybe the file name needs a date stamp to be added to mitigate this?

rmbd commented on 2016-07-06 20:03

The StartupWMClass entry in the .desktop files should really be removed since it makes the stable version of Firefox appears with the Aurora icon and name once started in GNOME, which is confusing.

Upon reading the comments regarding this issue, I understand why the choice of this setting was made, but I don't think it solves the core issue, which is that it's not possible to separate running instances of Firefox stable from Aurora's in the GNOME dash.

It's still possible to pin Aurora as a favorite without the StartupWMClass entry, but you have to do it via the application menu, not from the dash.

jP_wanN commented on 2016-07-06 10:39

Since a few versions, the checksum doesn't match anymore. It also doesn't seem to have changed with the last update. Please fix!

jP_wanN commented on 2016-07-04 11:13

enricostn: If you have Intel graphics, maybe this is your problem as well?

enricostn commented on 2016-06-30 12:56

Anybody else noticed slowness in response? I mean the application itself, nothing related to network issues. Especially dealing with text inputs and URL bar.

Noticing this since like one month. Had to switch to Chrome for work :(

AlexTalker commented on 2016-06-16 21:27

Oh, I've got it

AlexTalker commented on 2016-06-16 21:25

about .srcinfo....seems strange, hashsums is different between makepkg -g and makepkg --printsrcinfo

AlexTalker commented on 2016-06-16 21:23

Oh, I misunderstood problem I think. See, I am completely unsure I can make unique name, since pkgver generated after files is downloaded.

AlexTalker commented on 2016-06-16 21:16

@thx1138 strange, I generate .SRCINFO using mksrcinfo (is this deprecated now?)
I might rename source file, but does it really costs?

thx1138 commented on 2016-06-04 03:02

"pacaur" requires that each nightly-build source file have a unique name, or otherwise it will re-use its previously downloaded source file. Fortunately, the old file's sha512sum will not match for the new file, and the build will stop. Please see pacaur issue #491:

This echoes vith's comment below, 2016-04-20. Please see also pacaur issue #461:

Even removing the old source file, the pacaur install fails with:
:: firefox-aurora package(s) failed to install. Check .SRCINFO for mismatching data with PKGBUILD.

pacaur's saved ~/.cache/pacaur/firefox-aurora/.SRCINFO has an empty "sha512sums =" for the source. But "makepkg --printsrcinfo" generates the correct "sha512sums =" using the PKGBUILD. pacaur does not build this incomplete .SRCINFO, and I'm not sure where it is being generated.

Should the .SRCINFO file be explicitly generated with a "makepkg --printsrcinfo"?

EndUserOnly commented on 2016-05-27 11:16

Any chance on getting grsec kernel support? It just crashes. Here is the syslog denial from grsec: grsec: denied RWX mprotect of <anonymous mapping> by /opt/firefox-aurora/firefox[firefox-aurora:1481]

aouellette commented on 2016-05-12 22:24

Could you remove the cache update commands from the PKGBUILD? They are no longer necessary, as hooks provide this functionality.

AlexTalker commented on 2016-05-07 19:16

Also, I appreciate that people enjoy my repo so result of builds for updates now usable not only for me, thank you!
Seems like now is about 5-20 people daily download my packages from there.

I would like to communicate if somebody from comments use it :)

AlexTalker commented on 2016-05-07 19:11

By the way I still unsure about alsa-lib, can somehow help me to prove this dependency?

AlexTalker commented on 2016-05-07 19:09

@vith @jgmdev
Yes, I ever saw comments that the bug was fixed in nightly but hasn't come to aurora yet.
Hope, you appreciate new experience :D

vith commented on 2016-05-07 15:23

@jgmdev yes, upstream bug:

jgmdev commented on 2016-05-07 15:15

Isn't anyone else having issues with the scroll bar button not been visible?

vith commented on 2016-04-20 03:17

makepkg has failed with checksum error until I `git clean -xfd` on multiple days. I think because the source tarball's filename doesn't change every day, so makepkg thinks it can reuse the old one.

nwah1 commented on 2016-03-31 05:30

Is alsa-lib a hard dependency still?

Is libpulse now a hard dependency?

AlexTalker commented on 2016-02-13 12:13

@dfanz0r somewhere in 2015(if I remember right)
ff aurora become developer edition(and start include nice dark theme!)
Since renaming the package might make little problems for currently users, I decide to do nothing since source archives for the package still called 'aurora' :D
@eolianoe I am unsure about merging, never mind about it. Since the package is nice for 'daily update without headache' by my opinion, I will keep it while here's some users :)

eolianoe commented on 2016-02-13 08:42

@dfanz0r: a quick search leads to (from [1]) :
"Firefox Developer Edition replaces the Aurora channel in the Firefox Release Process. Like Aurora, features will land in the Developer Edition every six weeks, after they have stabilized in Nightly builds."

Maybe this package should be merged in firefox-developer [2]


dfanz0r commented on 2016-02-13 02:52

When installed this is becoming firefox developer edition. Anyone else having this issue?

AlexTalker commented on 2016-02-11 13:17

Hi, folks!
For everybody who's lazy to build on his x64 this package(and thunderbird-earlybird and firefox-aurora-ru too) I've create a repo since anyway packages that build on automatical version may be reused :)
Just use the lines for yours pacman.conf:
SigLevel = Optional TrustAll
Server =

Have a lucky build!

lucaswerkmeister commented on 2016-02-07 12:47

package version currently doesn’t match, this is what makepkg produces:

AlexTalker commented on 2016-01-20 11:37

@artafinde You may notice the conversation below about addition StartupWMClass to .desktop files. So this is why the problem is exist.
Since the WMClass for all releases of firefox is the same, I cannot do much.
Probably I shall experiment with .install file to interactive addition the of StartupWMClass or just make the .desktop like `firefox` package does.
Also, no, there's must not be leading slash since wiki tell us so
Have a lucky build!

artafinde commented on 2016-01-17 11:36

I have a weird issue. I have both firefox and firefox-aurora packages installed (different profiles). When I start firefox from Gnome on the Dock (extension) the icon appears as Aurora (blue fox) instead of Firefox icon and the name is "Aurora - Safe Mode". I tried updating the gnome icons etc with no luck. This problem goes away only if I un-install firefox-aurora package.

artafinde commented on 2016-01-17 11:27

Shouldn't the `gtk-update-icon-cache -q -t -f usr/share/icons/hicolor` be targeting `/usr/share/icons/hicolor` in the `.install` file?

belak commented on 2016-01-14 23:34

That appears to work. Thanks for the fix!

AlexTalker commented on 2016-01-13 19:01

@SangSatori fix up checksums, thank you for notice!
Seems like it's 'cause StartupWMClass must match at least one of classes of the app. I'll appreciate if you remove line in firefox-aurora-safe.desktop and test it out!
Thanks for testing, anyway!

SangSatori commented on 2016-01-12 17:27

@AlexTalker Pinning works for me (Aurora gets labeled as "Aurora Safe Mode", but it works now otherwise). You should update checksums on those two .desktop files however; installing package is currently failing because of them.

AlexTalker commented on 2016-01-12 11:14

@belak like StartupWMClass="firefox"?
I've to added the property in Desktop Entries, please, check it out

belak commented on 2016-01-11 21:34

StartupWMClass should probably be set in the .desktop files. Otherwise, it won't let you pin it as a favorite app in gnome.

btreecat commented on 2015-10-28 15:27

@AlexTalker, there may be a redirection, however it fails when using your script:

==> Building and installing package
==> Making package: firefox-aurora 43.0a2.20151027004102-1 (Wed Oct 28 11:13:35 EDT 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found firefox-aurora.desktop
-> Found firefox-aurora-safe.desktop
-> Downloading firefox-43.0a2.en-US.linux-x86_64.tar.bz2...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 54.3M 100 54.3M 0 0 30.2M 0 0:00:01 0:00:01 --:--:-- 30.2M
==> Validating source files with sha512sums...
firefox-aurora.desktop ... Passed
firefox-aurora-safe.desktop ... Passed
firefox-43.0a2.en-US.linux-x86_64.tar.bz2 ... FAILED
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build firefox-aurora.

Have you recently tried to resync this package?

The best way to fix this issue and avoid future issues would be to change the script to not use the redirection and rather use the real baseurl.

I have no issue downloading the checksums via your curl command (also tested wget) or manually through a browser. However when using the redirect and your cur command there are some interesting results.

Running part of your script:
curl -vs "${_baseurl}/${_filename}.checksums" 2>&1 | grep "${_filename}.tar.bz2" | grep sha512

Produced this result:
d624255b3abae78456738d792ca37708333f0013fc6bfe9cd9712e306806443236b8462fbb03386169ebc93e55a8b54dcd774ef0cb7726875bc30eb76081e645 sha512 56975220 firefox-43.0a2.en-US.linux-x86_64.tar.bz2

However, when I manually browse to it and select the file with out using the redirect URL:
ec4bbb11bbb89f1d8a9fd7844b3169c82da99847468957861716e77176167e57f4581c810e92241401649b3c48a2200e7dbd63522562c9c35978542f91be8b1a sha512 56976157 firefox-43.0a2.en-US.linux-x86_64.tar.bz2

The interesting bit, the checksums file that is returned is actually yesterdays checksums file, not today's. So it seems that while there IS a redirect, it is not working as expected.

Please update PKGBUILD with:


Thank you.

AlexTalker commented on 2015-10-28 08:28

@btreecat If you can't download hashsum then something wrong I guess but on my PC everything works correctly every night when it's update automatically(building the package for me and push updates to AUR).

AlexTalker commented on 2015-10-28 08:26

@btreecat it's correct.
A redirection exist ;)

btreecat commented on 2015-10-27 15:25


The baseurl needs to be updated, the checksums file that is downloaded currently is incorrect.


Thank you.

AlexTalker commented on 2015-10-24 22:11

@Saren, the checksums are signalize that you need to rebuild package.
And also check correctness of downloaded files 'on the fly'.

kdiogenes commented on 2015-10-20 20:49

Is there anyway to make it launch by default with the following in GNOME: `GTK_THEME=Adwaita firefox-aurora`. Without this env var, using the tweak to make GNOME theme dark results in input elements like these:

Saren commented on 2015-10-14 17:33

It seems that the source files are changing everyday, it may be not suitable to add checksum to PKGBUILD.

danyf90 commented on 2015-09-24 16:21

@niceman: the check is disabled because it is builded daily so i should have to change it every day

niceman commented on 2015-09-24 16:07

@danyf90 but the files passed the shasum check ! anyway it's working now so thanks .

danyf90 commented on 2015-09-20 21:26

@niceman: I don't get that error. As it says probably the problem is that your download is corrupted

niceman commented on 2015-09-19 21:24

error: could not extract opt/firefox-developer/ (Lzma library error: Corrupted input data)

auscompgeek commented on 2015-09-18 06:30

@frnx: extra/firefox is compiled against GStreamer 1.0, Mozilla builds are still compiled against GStreamer 0.10.

somekool commented on 2015-09-16 16:55

To enable automatic updates

sudo chown -R $USER:$USER /opt/firefox-aurora/

frnx commented on 2015-09-03 21:11

@gant: Got media (incl. Soundcloud) working again after making sure gstreamer0.10-plugins-ugly is installed. Weirdest thing is that FF40 (and everything else) was working just fine without that package.

patrickod commented on 2015-08-29 22:48

@gant: I had no such issues with Soundcloud with the latest version 42.0a2-1.

gant commented on 2015-08-22 20:47

This package definitely had degraded media functionality. Soundcloud works out of the box with stable, this doesn't.

SRChiP commented on 2015-08-15 16:52

42.0a2 is out now.

somekool commented on 2015-08-14 12:03

correction to my previous comments, beta-bin, developer and aurora are all 3 on 41 right now.

according to comments on nightly, both GTK3 and GTK2 must be added as a dependencies.

all of these firefox AUR package should sync with each other...

somekool commented on 2015-08-14 11:59

What is difference with "developer build" ? There is also firefox-beta-bin which is on version 40. Aurora is at 41 right now. And nightly already ship 42.

So, why there is a beta and developer shipping the same version?

any customization added on either side?


AnAkkk commented on 2015-08-11 19:15

The new version now depends on gtk3.

Det commented on 2015-08-11 17:48

Can you add the date to the version number like the others, too?

danyf90 commented on 2015-08-10 09:19

The package is updated since the last version is 41.0a2, if you want to update it just reinstall the package. The tarball on the site is updated daily, I can't update it every day. I update it when the version change. If you want to install daily you just have to reinstall the package every day

Anonymous comment on 2015-08-08 22:15

Is H.264 decoding through GStreamer supported in firefox-developer?

Optional GStreamer dependencies are listed in the firefox and firefox-beta packages, but not in this one or firefox-aurora.

t.ask commented on 2015-08-07 21:26

Please upgrade for 0-day bug.

lucaswerkmeister commented on 2015-08-07 11:36

Does this need to be updated for ?

arp12 commented on 2015-05-13 15:09

Please update to 40.

py_crash commented on 2015-04-18 07:51

You can do it, however in Arch we try to keep it as *upstreamy* as posible, and also keep support to different languages

electricprism commented on 2015-04-16 20:55

When Firefox Aurora is a "Favorite App" in the Gnome Dock and open it creates "Two Instances" of Firefox Aurora and has no right click options for "New Window", etc...

I created a new /usr/share/applications/firefox-aurora.desktop and based on firefox.desktop and stripped out the additional language fields to make it readable.

dummyuploader commented on 2015-02-02 15:29

37.0a2-2 is out now

danyf90 commented on 2015-01-17 07:01

@wwgfd: the PKGBUILD is okay because that files are linked in the src directory during makepkg. It works fine.
For the auto-update: if you install it from aur you are supposed to update it from aur

wwgfd commented on 2015-01-16 19:15

Tried to build this package and got the following error:
- install: cannot stat ‘/home/chell/.packages/AUR/Applications/mozilla/firefox-developer/src/firefox-developer.desktop’: No such file or directory

Changing the two 'install' lines for the .desktop file and the 'vendor.js' file as follows seemed to fix it okay:
- install -m644 $srcdir/../firefox-$_channel.desktop ...
- install -Dm644 $srcdir/../vendor.js

I guessed that the package() function is executed within the 'pkg/{pkgname}' folder so needed to get back to the PKGBUILD file's root. The method I used was to go to the '$srcdir' folder then up one level (i.e. '../') from there! :_)

However I noticed that the 'vendor.js' file is only there to disable the auto-update feature. Since I noted in my previous comment the advice from 'Nemu_khao' on how to get this feature working properly then I figure this file is no longer needed?

wwgfd commented on 2015-01-16 19:07

Tried to build this package and got the following error:
- install: cannot stat ‘firefox-aurora.desktop’: No such file or directory

Changing the two 'install' lines for the .desktop files as follows seemed to fix it okay:
- install -Dm644 "$srcdir/../${pkgname}.desktop" ...

I guessed that the package() function is executed within the 'pkg/{pkgname}' folder so needed to get back to the PKGBUILD file's root. The method I used was to go to the '$srcdir' folder then up one level (i.e. '../') from there! :_)

I also changed the 'mv "${_name}" ...' line to 'cp -r "${_name}" ...' so that I could just re-build using the existing source without having to move or re-download anything.

AlexTalker commented on 2015-01-16 15:41

@wwgfd, it is, I see, but this not mine problem, I think.
I just didn't want to rename package after this 'name rebranding',so, I think, everything fine.

wwgfd commented on 2015-01-16 15:08

Additional 'FYI':

For everyone else still wondering how to make it self-update, just do:
sudo chown USER /opt/firefox-developer

-- Thanks to comments by 'Nemu_khao' and 'ahura' on the firefox-aurora package's page!
[Ref: ]

wwgfd commented on 2015-01-16 15:06

It seems that this package and the 'firefox-developer' package both utilise the latest 'aurora' source from Mozilla!

[Ref: ]

wwgfd commented on 2015-01-16 15:05

It seems that this package and the 'firefox-developer' package both build the latest 'aurora' source from Mozilla!

[Ref: ]

wwgfd commented on 2015-01-16 15:01

Is the [url=]firefox-developer[/url] package just a duplicate of this one? -- It seems they both build the 'latest-mozilla-aurora' source!

wwgfd commented on 2015-01-16 14:55

+1 for flaviut

"Firefox Developer Edition" is the name that Mozilla released their project 'Aurora' browser with, as evident by the '.../latest-mozilla-aurora/...' part in the source uri for this package.

clfarron4 commented on 2015-01-15 16:21

@arslonga: That would require it to become a package in the main repositories.

Det commented on 2015-01-09 16:26

Maybe you could use this as the homepage?:

arslonga commented on 2014-12-28 10:13

Is there a chance that firefox-developer will be added to pacman?

ahura commented on 2014-12-10 19:46

@scjet it doesn't seem to me they are the same. The last update for latest-gum was on Nov 08 and to Aurora on Dec 10th.

@Nemu_khao my bad, your answer works perfectly. For everyone else still wondering how to make it self-update, just do:

sudo chown USER /opt/firefox-aurora

scjet commented on 2014-12-10 17:31

in PKGBUILD, changed the line:

and that fixed the URL - 404 error.
...everything installed fine after that.

ahura commented on 2014-12-10 16:09

@Nemu_khao sorry, here it isn't self updating, what am I doing wrong? thank you for your work!

piratejon commented on 2014-11-27 04:31

Thanks Nemu_khao, that works pretty well.

Nemu_khao commented on 2014-11-23 09:09

@piratejon: I just changed ownership of /opt/firefox-aurora to current user and now aurora/dev edition updates itself on its own.

piratejon commented on 2014-11-19 03:37

What is a good way to keep this up-to-date? Is it possible to use the software update dialog, as root perhaps? Or do I need to re-run makepkg/yaourt each time?

AlexTalker commented on 2014-11-18 13:04

Notice for folks who want just use Aurora:

AlexTalker commented on 2014-11-18 12:54

I've to make base on firefox-hg, it works, you'll try it if want some extend optimization....ccache supported

esrevinu commented on 2014-11-17 05:10

I am using firefox-aurora, not firefox-developer, but I have the same issue that
in Gnome, Dash shows the red firefox icon for firefox-aurora.
Although I don't know why, changing /usr/share/applications/firefox.desktop to other name like firefox-stable.desktop solves the issue.

hikkakaru commented on 2014-11-15 07:55

furthermore you can disable this independent profile behavior. options>general>enable firefox developer and firefox to run at the same time.

hikkakaru commented on 2014-11-15 07:54

sync is intended to collide -- firefox developer is supposed to use separate firefox profiles; the only data share channel is provided by sync. This is on purpose so as to allow a "client" view firefox browser to be running alongside the 'dev' browser on the same machine for live-update coding or whatever.

the themes/addins only collide if you enable them to be synced with your other sync nodes. if you check your ~/.mozilla/firefox directory and have firefox & firefox-developer installed you'll notice two separate folders; '.dev-edition-default' and '.default'. Those represent two separate irefox profiles.

e8hffff commented on 2014-11-14 10:28

@hikkakaru It will start separately but the Sync, themes and add-ins, collide

dare023 commented on 2014-11-12 10:47

@hikkakaru: Not completely, I think. I have issue with icon-only task manager in kde, uses same icon for both firefox and firefox developer. Does anybody have same issue? I tried changing icon but not working.

hikkakaru commented on 2014-11-12 06:26

@e8hffff it operates seperately from the regular Firefox release.

py_crash commented on 2014-11-12 01:09

Firefox Developer Edition is still Aurora Channel, and the only aurora channel. No need for a new Package

flaviut commented on 2014-11-11 20:49

What's the difference between this and ?

Pazuzu156 commented on 2014-11-11 19:04

No install problems. Installs beside standard Firefox. Very quick response to add to AUR. Awesome!

k2s commented on 2014-11-11 13:50

latest sha512sum is dc7d56fd60353af1765231b198e78bdf080f7aeebac943714297f5eb56f2c17379bc063e4a40d57c90ad47f0bf8e5a07f60eafda14959d6f3c384470c984f782

e8hffff commented on 2014-11-11 13:39

Does this install parallel to common Firefox or attempts to overwrite it?

I hope this goes to mainline Archlinux packages.

I currently installed the mozilla based package manually in my home directory under .firefoxdev and it works fine.

k2s commented on 2014-11-11 13:27

I am getting error:
==> Validating source files with sha512sums...
firefox-35.0a2.en-US.linux-x86_64.tar.bz2 ... FAILED
firefox-developer.desktop ... Passed
vendor.js ... Passed

noxpo commented on 2014-11-11 12:02

Thx a lot!
And now an almost equally quick bug report :o) :
When I start WebIDE, create the Hello World app and try to run it on the local runtime, I get
"Operation failed: installing and running app"
Don't see any error messages for that when I run firfox-developer from a terminal window.

gabx commented on 2014-11-11 11:12

So my guess is there will be a new AUR package ?

Dea993 commented on 2014-11-11 10:08

firefox aurora no more exist.
now there is firefox developer edition

trzalica commented on 2014-11-11 09:43

Nice! :)

LiquidityC commented on 2014-11-11 08:50

That was quick. GJ! :D

AlexTalker commented on 2014-11-10 22:43

@gabx, sure, clear cache.Hash summ calculating automatically from source site, for lastest version.

gabx commented on 2014-11-07 12:10

keep getting ==> ERROR: One or more files did not pass the validity check!

AlexTalker commented on 2014-10-30 10:22

I'm back in blaaaaaaaaaaaaack.

Okay, it's joking.I just mean i am return back to Arch and will continue support this thing.

swiftgeek commented on 2014-09-21 14:26

Only changing _milestone is needed, pkgver is updating itself on its own
Still annoying because it's not that effortless to use to automatically update this package on next system update

SpeedGhost commented on 2014-09-19 16:51

Changing _milestone and and pkgver in the PKGBUILD to 34.0a2 will get the updated version. Only a short term fix, hope this package gets updated soon. Looks like blackout even provided an updated tarball already.

blackout commented on 2014-09-16 20:38

really? no mail no update *feeling depressed*

blackout commented on 2014-09-14 21:32

I've sent you the updated tarball, pls upload it

AlexTalker commented on 2014-09-03 20:23

Sorry me, i am killed my mbr on drive and i haven't any Arch around to build fresh package.If you will help me, you can send source package by email.

AlexTalker commented on 2014-07-16 00:11

@gabx, `makepkg -i` call synchronization sources and checking hash summs before start.Also that call pkgver function and if you have new release - start rebuild.

abandonedaccount commented on 2014-07-15 10:13

worked for me
Packages (1): firefox-aurora-32.0a2.20140715004003-1
even though the PKGBUILD itself may be outdated with that pkgver=32.0a2.20140610004002
it still gets the latest aurora
the milestone seems to be the same anyway _milestone=32.0a2
only the dates changed

gabx commented on 2014-06-09 08:39

the below mentioned issue still exists.
gabx@hortensia ➤➤ ~aur/firefox-aurora % makepkg -i
==> Making package: firefox-aurora 31.0a2.20140605004002-1 (Mon Jun 9 10:37:18 CEST 2014)
warning: firefox-aurora-31.0a2.20140511004003-1 is up to date -- reinstalling

I start to build 31.0a2.20140605004002-1 and end with 31.0a2.20140511004003-1

gabx commented on 2014-06-04 09:11

something weird:
gabx@hortensia ➤➤ src/firefox % cat platform.ini|grep BuildID|cut -d "=" -f2
As you can see, version number is wrong on their desktop.ini file. That could explain the below mentioned issue

gabx commented on 2014-06-04 08:50

I had an issue with sha512sums for firefox-31.0a2.en-US.linux-x86_64.tar.bz2.
On the firefox repo, firefox-31.0a2.en-US.linux-x86_64.checksums give this:

fca4b30072c1e6780b326d67845d5b82cb2b2c1915d9f93b6100509b8cb9cd64554dd18c46184042e30713fa2edfe925b55aaec2c51b598dd0a00cc836097eb2 sha512 44070080 firefox-31.0a2.en-US.linux-x86_64.tar.bz2

when indeed it is this:
1f9c4351a347037ea817cb6a053f648c1ca8f925f5298796def0f7e489bd9adae6b1cf8f7e40e106c11f5684a77e674c1cd3970212323ae18c35c2429e46ffb5 firefox-31.0a2.en-US.linux-x86_64.tar.bz2

AlexTalker commented on 2014-05-21 14:47

@py_crash, you mean, i should update sources anyday? LOL

py_crash commented on 2014-04-30 00:43

Aurora gets dayly updates so it's good to know wich version you have installed

AlexTalker commented on 2014-04-29 17:16

What you think about remove crap 20140429004000 in version?

AlexTalker commented on 2014-04-29 17:15

Update to 31

konart commented on 2014-04-13 10:06


Now it works fine, thanks. There were no problems with with before, despite static name.

contrebasse commented on 2014-04-12 18:48

@konart: Did you try to remove the file in your source directory ? Its name may not change between versions.

konart commented on 2014-04-12 11:52

Fails on checksum now

AlexTalker commented on 2014-03-18 18:39

Updated in process, wait :P

t0m3k commented on 2014-03-18 14:29

If u know that there is newer version u can update by simple instaling again firefox-aurora but it should work automatically with updates...

t0m3k commented on 2014-03-18 14:28

Why nobody is updating info about version? The newest now is 29.0a2.20140317004002-1 while yaourt see 29.0a2.20140203004003-1 and is not updating...

Claudiop commented on 2013-12-27 02:28

@py_clash Oh, sorry for bothering you. I thought that Firefox nightly was the one with daily builds, my bad.
I see, let's hope it will be fixed soon :/
Thanks for your time

Claudiop commented on 2013-12-27 02:28

@py_clash Oh, sorry for bothering you. I thought that Firefox nightly was the one with daily builds, my bad.
I see, let's hope it will be fixed soon :/
Thanks for your time

py_crash commented on 2013-12-26 04:44

@Claudiop It will complain unless you rebuild the package every day. Aurora is an alpha build so is rebuild daily. I have a script which does it for me.
THe bug is alredy reported in mozilla: Feel free to cc your self if you whant to enter the discusion. It should crash the browser so it's not critical

Claudiop commented on 2013-12-26 04:03

It is complaining there is a newer build.
It is also reproducing this:

py_crash commented on 2013-11-27 13:01

@fhahan yes, sorry about the typo. Corrected!

fhahn commented on 2013-11-27 08:50

It's only a minor thing, but the upstream url seems broken. (note the dash instead the underscore) should work

narical commented on 2013-11-04 13:58

It works after changing string in pkgbuild:
_milestone=26.0a2 to _milestone=27.0a2

py_crash commented on 2013-10-21 09:09

@gabx are you using yaourt or makepkg for creating the pkg? That error usually happens when you have the wrong daly package downlaoded

gabx commented on 2013-10-19 12:19

Again same issue as described below.
==> ERROR: One or more files did not pass the validity check!
Please fix it.

gabx commented on 2013-10-10 08:16

First TY for your package.
There is an issue with the $sha512sum variable. It is not egal to the correct one.
$ sha512sum firefox-26.0a2.en-US.linux-x86_64.tar.bz2
$ b4d40401084748dd0801c261a8303c99a59a4396689954e97a2cda0495f8c4f8343d063eac25d31f690dbc48e2833704d198ccc7db5531b8800a7091f4b2859a

Thank you

py_crash commented on 2013-09-22 16:16

@LeetShiva No problems and thanks for the flag. I was traveling and forgot to set up an script to update it for me

LeetShiva commented on 2013-09-19 03:05

Need to flag it out of date. It past two days since release schedule date for official firefox and aurora 26 actually existed a few days more than that.

This is no bad intention, I just trying to remind maintainer sbout updating package. I use firefox-aurora every day :)

HalosGhost commented on 2013-08-31 07:14

Alright, the reason that the version manipulation makes sense is because this package functions similarly to a VCS package, you need to stop re-uploading the package unless something in the PKGBUILD itself changes.

All the best,

HalosGhost commented on 2013-07-14 17:16

Right, but nothing in the PKGBUILD is actually changing except the version number which is being handled by pkgver. I mean, do what feels right, but there's really no gain from it.

All the best,

HalosGhost commented on 2013-07-14 17:10

Right, but nothing in the PKGBUILD is actually changing except the version number which is being handled by pkgver.

All the best,

py_crash commented on 2013-07-14 13:25

@HalosGhost I have to re do the package for myself every day, so i found no problem in sending the update

HalosGhost commented on 2013-07-13 15:37

The PKGBUILD could be updated to download each new archive under a different name pretty easily, but I would recommend you just delete them by-hand. Otherwise, you'll end up with a ton of wasted space very quickly.

Also, py_crash, there's no need for you to keep submitting updates to the PKBUILD; people should rebuild nightly anyway because it's a nightly. You should just update the package when something has actually changed (it is best to think of this package like a -git package).

All the best,

HalosGhost commented on 2013-07-13 15:36

The PKGBUILD could be updated to download each new archive under a different name pretty easily, but I would recommend you just delete them by-hand. Otherwise, you'll end up with a ton of wasted space very quickly.

Also, py_crash, there's no need for you to keep submitting updates to the PKBUILD; people should rebuild nightly anyway because it's a nightly. You should just update the package when something has actually changed (it is best to think of this package like a -git package).

All the best,

contrebasse commented on 2013-07-13 10:58

I found the problem : I use yaourt to install my packages, and since the name of the firefox archive doesn't change, it isn't redownloaded and the last cache version is taken instead.
Is there a way to force the download in the PKGBUILD or do I have to delete the old file by hand ?

py_crash commented on 2013-07-13 09:30

@contrebasse I didn't got that error but check if the problem persist with the version 24.0a2.20130712004003-1

contrebasse commented on 2013-07-12 16:15

I get a sha512sum error for firefox-24.0a2.en-US.linux-x86_64.tar.bz2, I can't update. The package version is firefox-aurora 24.0a2.20130711004005-1.

py_crash commented on 2013-07-04 15:29

@HaloGhost I see it now..

py_crash commented on 2013-07-04 14:38

@HalosGhost It makes sense using a pkgver function, however the link you send me doesn't work. You can send it again or just send a pull request

HalosGhost commented on 2013-07-04 14:01

Having the build number makes more sense to me anyway, and this way it will stop all this pkgrel nonsense :)

Here is an ix of the PKGBUILD I use and would propose:
The new version scheme isn't very pretty, but it's much more truthful. This update includes a new variable, a pkgver function and minor modification to the _file variable.

All the best,

HalosGhost commented on 2013-07-04 13:41

But you don't mean a change in the shasums of the source files you provide. You're changing the pkgrel when the upstream source changes. For a normal package, that is standard practice. But this package was designed to build the latest version of a nightly-released software channel. pkgrel is not meant to reflect upstream source changes, it is meant to reflect package changes (of which there haven't been any between -6 and -9). If you feel like you need to have the package personally indicate a version change, it might be worth using a pkgver function (though it is typically meant for VCS packages) to automatically update the version with a build number at the end.

However, the point is, Aurora provides its own update notifications (despite the fact that it doesn't handle its own updates, so this way of doing things is not preferable). I'd be happy to look into adding a valid pkgver function for you if you'd like.

All the best,

py_crash commented on 2013-07-04 04:57

@HalosGhost I update the pkgrel every time there's an update in the sha512sums therefore there is an update in the binaries (and the code). Some of the updates are just one-line changes, so you won't see a difference in pkg size, and since most of updates are the bug-fixes and Aurora is pretty stable you may not notice them. However some are security-fixes so I update the pkgrel so everyone gets an automatic update, as it was suggested by @therico and @awh

HalosGhost commented on 2013-07-04 03:23

Why the pkgrel updates? As far as I can tell, nothing changed between -6 and -8.

All the best,

py_crash commented on 2013-06-30 04:51

Merged.. I'll update the package the next time a new update (so a new pkgrel) comes

HalosGhost commented on 2013-06-30 00:44

Big pull-request submitted :)

py_crash commented on 2013-06-29 17:03

@HalosGhost Yep.. You're probably right but i don't know how to write the script with curl, if you send it to me (Or better you make a pull request: I'll change the next time I update the pkgrel

HalosGhost commented on 2013-06-28 15:13

It would be preferable to use curl instead of wget as curl is used by pacman, it is a safe assumption that all arch installs have it, so it would effectively remove an extra dependency (even though it's just a makedepends).

py_crash commented on 2013-06-27 17:17

@therico.. updated and removed the hardcoded checksums.. I still need to clean the pkgbuild so it cann be build in a clean chroot

therico commented on 2013-06-27 10:41

The new pkgbuild fails for me:

==> Validating source files with sha512sums...
firefox-aurora.desktop ... Passed
firefox-aurora-safe.desktop ... Passed
firefox-24.0a2.en-US.linux-x86_64.tar.bz2 ... FAILED
==> ERROR: One or more files did not pass the validity check!

Why are the checksums hardcoded? I definitely remember someone adding code to download the checksums from the server so they did not need to be manually updated.

py_crash commented on 2013-06-26 01:43

@HalosGhost I'll do that thanks

HalosGhost commented on 2013-06-26 01:33

Might I recommend that you clean up the PKGBUILD a bit? Here's the one I use (heavily modified version of yours):

In particular, it removes some of your unneeded top variables and cleans up the checksum arrays considerably.

All the best,

py_crash commented on 2013-06-26 00:37

@det Updated :)

Det commented on 2013-06-25 17:34

Umm.. now?

py_crash commented on 2013-06-25 17:10

The i686 version is out.. but i'll update the PKGBUILD when the x86_64 version is ready

py_crash commented on 2013-06-16 19:06

@awh @therico I incremented the revision number, I'm making some script to check if there's any update...

awh commented on 2013-06-15 15:03

I'd be in favour of incrementing the revision number.

therico commented on 2013-06-15 01:40

I marked this package out of date because it's roughly a month old, but the major version is still 23.0a2, so perhaps it does not matter :) Unfortunately I can't 'unmark' it out of date now :(

If anyone wants the latest version, they can simply re-install the package.
Of course we could increase the revision number in the PKGBUILD so people get automatic updates.

py_crash commented on 2013-02-21 17:16

I'll update it tomorrow.. Today i have an exam :p

0mark commented on 2013-02-21 11:25

Fixed that. Sure, you are right, i just am to lazy to take care about that. So, since you asked, i happily disown the package. Have fun, and thanks :)

py_crash commented on 2013-02-21 11:15

@0mark I liked the "trick" you added to the PKGBUILD so the package is always made with the latest sources. However i think manualy updating PKGBUILD in each release is good for two reason: first of all it provides support to yaourt so user don't need to check is there's an update or not, and second it's helpful for Maintainers to check if nothing has changed from a release to the other. For example your package doesn't work anymore because mozicon128.png was moved from icons to browser/icons. I can takeover if you want. I'm maintaining thunderbird-earlybird so it's not much work for me...

Decorian commented on 2013-01-22 12:56

@0mark: I have decided that I do want to help out more with the Arch community, but instead of taking over a package that you are already maintaining, I'm sure there are already some orphaned packages that I could help with. Thanks for your work on this one.

Decorian commented on 2013-01-14 12:38

@0mark: I was saying that I would be willing if you have had enough of maintaining it, if you would rather continue maintaining it yourself you are welcome to. If you do disown it, let me know and I'll maintain it. Thanks for the permanent fix though, I didn't realize that was possible!

0mark commented on 2013-01-14 12:19

Sorry, i was at maintenance for some time.

@problem: I have fixed you, the current latest major is now determined on build time. I hope thats fixing you permanently ;)

@Decorian: No problem, if you like i disown it.

Decorian commented on 2013-01-14 11:32

I agree with awh, the PKGBUILD should be updated every major version.
It is not too difficult to change yourself, but if you use an AUR helper like I do, it always downloads live the latest PKGBUILD from here. This means for a nightly like firefox aurora that I have to manually change that pkgver variable every day.

If 0mark doesn't want to maintain this package anymore, I would be happy to volunteer as the maintainer.

Anonymous comment on 2012-12-31 05:41

Yes, it is :) You can look at the PKGBUILD--everything is referenced by ${pkgver}, so changing that variable changes what you download, what you build, what you check the checksum for, everything. Sure, it'd be nice if the PKGBUILD here had the pkgver variable changed, so that people downloading it didn't have to do so, but the same effect is achieved either way.

awh commented on 2012-12-25 22:58

@acvoight, is it? I know it fetches a nightly build of Aurora, but every major version release, the PKGBUILD should be updated too, shouldn't it?

Anonymous comment on 2012-12-23 01:21

The PKGBUILD is specifically created so that all you have to do is change the version number. If there is a new version, simply change the "pkgver" variable (to 19.0a2, in this case).

awh commented on 2012-12-09 19:35

It'd be awesome if this were updated to the latest version; it's been out a while now.

Decorian commented on 2012-11-27 12:44

Temporary update to v. 19.0 on pastebin it worked for me, but use at your own risk!

Decorian commented on 2012-10-10 12:46

Sorry, my mistake, it seems that at approximately the same time as I wrote my previous comment, they did in fact update Aurora to version 18. In general my comment about this package not going out of date and having to manually force a rebuild is correct though, it's only when they change the version that this needs updating.

0mark commented on 2012-10-10 11:25

Thats weird, cause it cheats the validity check:

> _md5=$(wget -qO- ${_baseurl}/${_filename}.checksums | awk -F' ' '$2 == "md5" && $4 == "'"${_filename}.tar.bz2"'" { print $1 } ')
> md5sums=('663176661ce817e40b4217c5e107df42'
> '1fbf95734ceb475ac2ac6ab085fc1961'
> ${_md5})

I tested it just now, seemed to work. Maybe it was just a transmission error.

jdarnold commented on 2012-10-09 17:52

Well, I just tried to install it and it failed the validity check.

Decorian commented on 2012-10-09 17:07

I un-flagged its out of date status. It's a nightly, see PaterSiul's comment. It can't go out of date whilst the version number is still 17.0a2, which I believe it is.

jdarnold commented on 2012-07-13 04:12

Odd, because I hadn't seen it before. But yeah, I'll just keep ignoring it.

PaterSiul commented on 2012-07-12 20:36

It's a nightly build. That means there's a new 'version' every day. So you'll have to get and install it anew every day if you want to always have the latest version. Or you could just turn off the update notices in 'preferences'. Or ignore them. It's your choice.
The PKGBUILD is designed to give you the newest build every time you run 'makepkg'. So there are really only two reasons to change the pkgbuild. 1: The mozilla developers decide to change the version number. 2: Some change in something breaks something connected to either building or running aurora.

PaterSiul commented on 2012-07-12 20:34

It's a nightly build. Whicht means, there's a new 'version' every day. So you'll have to get and install it anew every day if you want to always have the latest version. Or you just turn off the messages in 'preferences'. It's your choice.
The PKGBUILD is designed to give you the newest build every time you run 'makepkg'. So there are really only two reasons to change the pkgbuild. 1: The mozilla developers decide to change the version number. 2: Some change in something breaks something connected to either building or running aurora.

jdarnold commented on 2012-07-12 20:12

Well, I just got asked again and it is in fact, asking if I want to update to 15.0a2. What gives?

jdarnold commented on 2012-07-12 17:53

Well, I keep getting asked if I want to upgrade, and I have the latest from AUR.

PaterSiul commented on 2012-07-12 15:54

As far as I can see (, 15.0a2 is still the latest version. Please get back to me, if and when you have better information. Tanks.

PaterSiul commented on 2012-06-07 22:11

Should be fixed.

Anonymous comment on 2012-06-06 13:56

new PKGBUILD - Fixed broken md5sums

Anonymous comment on 2012-06-06 13:54

The md5sum is wrong for firefox-14.0a2.en-US.linux-i686.tar.bz2

I use 0f5e83780d3e8c568c0aca768e2a2bfa and it's worked (for me).


jdarnold commented on 2012-06-05 18:42

Actually, it looks to me like the PKGBUILD has a inherent problem - it uses the same md5sum for both the 32 & 64 bit downloads, which almost certainly isn't the case.

jdarnold commented on 2012-06-05 15:30

The md5sum is wrong for firefox-14.0a2.en-US.linux-x86_64.tar.bz2. It needs to be 'ea70a500bcc4678f8c65e87820e53a40'

PaterSiul commented on 2012-06-05 08:27

For those who want always the latest build: Please use
I will update this package whenever I get to it - but not anywhere near daily.

PaterSiul commented on 2012-06-01 12:12

So. $src now points to one of the daily builds, so this should continually work. This way users of tools like yaourt will see new versions.

Anonymous comment on 2012-06-01 07:34

therico's script works well.

Shouldn't it be possible to set the pkgver variable like this too? For example, wget the _baseurl, grep the .txt file for "linux-$(CARCH), get the version number from this filename and the build date from this file content...
Since it's a nightly build, I think the version number should contain the date.

therico commented on 2012-05-31 08:17

Something like this should work...

_md5=$(wget -qO- ${_baseurl}/${_filename}.checksums | awk -F' ' '$2 == "md5" && $4 == "'"${_filename}.tar.bz2"'" { print $1 } ')

Anonymous comment on 2012-05-25 22:53

The package is rebuilt nightly so the md5 will be different every day...

Anonymous comment on 2012-05-25 15:51

md5sums error: change it to

PaterSiul commented on 2012-05-23 09:24

Fixed broken md5sums and missing .desktop file

Anonymous comment on 2012-05-23 03:10

Latest update broken. Source file md5sum wrong in PKGBUILD.
Change md5sums=('c3d8b9f2da81a3459fc7817649147f1d'

Anonymous comment on 2012-05-17 00:07

This package is not out of date anymore. I installed it today and I'm on Firefox 14.0a2 (2012-05-16).

Please remove the out-of-date flag.

philefou commented on 2012-05-15 17:51


firefox=$(wget -qO - | grep -m 1 linux-x86_64.tar.bz2| awk -F'"' '{print $8}' OFS='"')

wget ${url}${firefox}

This can retrieve the link to the package... I didn't look enought at the PKGBUILD structure to be able to fix it all.. Hope it can help.

rjrjr commented on 2012-05-05 15:20

Is this still being updated? Isn't aurora up to version 14? Even the beta builds are ahead of us.

ruario commented on 2012-02-24 14:53

> Why the hell does this makedepend on lynx?

Indeed "lynx -dump" could be replaced with "wget -qO-".

Anonymous comment on 2012-02-06 15:40

The wget command heftig posted works and has the advantage of not installing extra makedepends.

wodim commented on 2012-02-04 11:43

Why the hell does this makedepend on lynx?

erufu commented on 2011-11-25 17:01

Thx for your help :)

fmoralesc commented on 2011-11-23 21:14

Another option is to give global write permissions to the /opt/firefox-aurora folder.

Anonymous comment on 2011-11-23 16:22

Sure there is. You can just download the tar.bz2 file from the Firefox-Homepage, extract it and use it per chmod +x firefox and ./firefox - then these Aurora files will be updated per Firefox-Aurora automatically.

That'll work, but then Aurora isn't fully integrated in your system of course. So there'll happen nothing when you type in 'firefox-aurora'.

erufu commented on 2011-11-23 12:59

And there is no solution to auto-update with yaourt ? Or directly with the auto-update of firefox ? Thx

Anonymous comment on 2011-11-23 12:17

You don't need to remove it, just build the package again and reinstall it. It'll get the latest version from the mozilla-homepage.

erufu commented on 2011-11-23 11:08

Hi, it is usual that to update the package to the lastest version of firefox we need to remove and reinstall the package ?

fmoralesc commented on 2011-11-09 22:29

Hi, I went back to this and found a better solution: retrieving the dir listings and parsing that to get the latest version url. This new PKGBUILD is at

fmoralesc commented on 2011-10-18 19:54

The 8.0a2 version being downloaded was just an artifact of the state of the mozilla dir. I have modified the PKGBUILD so it uses wget instead of lynx. This version only uncompresses the latest version it finds, just in case:

dserban commented on 2011-10-02 16:53

I just tried the wget command you suggested.
The output is:

The command downloads 2 files, one 18M in size for version 8.0a2, and one 19M in size for version 9.0a2.

The one thing I'm doing in the PKGBUILD to address this issue is to use "| tail -1" at the end of the lynx command to only retrieve the latest version.
I'm wondering if the globbed wget command can be made to behave similarly.

heftig commented on 2011-10-02 16:02

No need to use lynx. wget can glob:
wget '*linux-x86_64.tar.bz2'

gaelic commented on 2011-08-28 15:47

Thanks a lot.

dserban commented on 2011-08-27 13:02


gaelic commented on 2011-08-27 12:29

can you ship an updated desktop file, because of missing mimetypes gnome3 doesn't recognize it ...


dserban commented on 2011-08-24 15:46

I assume "performing an AUR update" means using yaourt or packer or another AUR helper.
My advice is: Don't use those! They are buggy and unpredictable.
The only supported method of using PKGBUILDs on AUR is to download the tarball, inspect the files and run "makepkg -s".
Aurora is not nightly, yes, but they recently switched to an aggresive enough build schedule to warrant setting this PKGBUILD "on autopilot" with lynx.
You are welcome to share your PKGBUILDs with the community, that's what AUR is here for. You don't need to ask for permission from anyone.

Anonymous comment on 2011-08-24 15:16

IMO always downloading `latest` is a mistake, because Aurora doesn't update that often (it's not nightly), so you'll download / reinstall the same thing each time you perform an AUR update. If you stick to specific versions you won't need Lynx either to figure out which version is the latest.

Should I create my own package that checks for specific versions?

Anonymous comment on 2011-08-24 08:33

Sorry if I made a mistake by flagging it out-of-date. I'm using packer to manage the packages from AUR when passing "packer -Syu" firefox-aurora wasn't updated, although reinstalling the program gave me the latest version. Don't know if this is a packer issue or something to do with the pkgbuild.

dserban commented on 2011-08-23 21:15

Un-flagging out-of-date, here's my makepkg output:
Before you flag out-of-date again for no reason, please explain why, or otherwise post your makepkg output.

dserban commented on 2011-08-20 09:37

lynx does a *much* better job at web-scraping / HTML parsing /dynamically determining the URL of the latest version than wget.
But I'd be happy to take a look at an alternative version of the PKGBUILD if you find a better (wget-centric) solution for:
_url=$(lynx -dump "${_url_prefix}" | grep -o http.*linux-${CARCH}.tar.bz2 | tail -1)

Anonymous comment on 2011-08-20 04:48


really? use wget instead - it's in the base group so everyone should have it already.

linuxJay commented on 2011-07-14 21:57

please orphan this package

linuxJay commented on 2011-07-13 18:12

still not working

L42y commented on 2011-07-08 01:11

@pluckypigeon, this may not be package's problem, it works in my machine. you should search it before flag it out-of-date, the error is something related to xulrunner.

linuxJay commented on 2011-07-07 15:11

doesn't start now, with error in terminal:

Couldn't load XPCOM.

L42y commented on 2011-07-07 02:03

update to 7.0a2

L42y commented on 2011-05-26 08:17

update to 6.0a2, thanks megadriver

L42y commented on 2011-04-30 15:23

aeosynth, thanks for your advise

Anonymous comment on 2011-04-30 14:16

--2011-04-30 07:10:14--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: [following]
--2011-04-30 07:10:14--

tl;dr change point to final url by changing _fxurl to

praetorian commented on 2011-04-15 16:22

I got a warning in aurora that this was out of date (from auora).. I have a feeling they only update the file (not the file name), as rebuilding this package removed the error.