Package Details: firefox-esr-i18n-gu-in 115.11.0-3

Git Clone URL: https://aur.archlinux.org/firefox-esr.git (read-only, click to copy)
Package Base: firefox-esr
Description: Standalone web browser from mozilla.org, Extended Support Release
Upstream URL: https://www.mozilla.org/en-US/firefox/enterprise/
Keywords: browser gecko web
Licenses: GPL, MPL, LGPL
Submitter: figue
Maintainer: dudemanguy
Last Packager: dudemanguy
Votes: 47
Popularity: 1.17
First Submitted: 2015-05-28 23:15 (UTC)
Last Updated: 2024-06-02 17:23 (UTC)

Dependencies (56)

Required by (0)

Sources (103)

Latest Comments

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 .. 21 Next › Last »

dctxmei commented on 2020-05-16 04:34 (UTC)

@TheGoliath Added you as a co-maintainer.

figue commented on 2020-05-06 22:45 (UTC)

@GI_Jack thanks. Seems good. Done.

GI_Jack commented on 2020-05-06 13:51 (UTC)

Please change

provides=(firefox)

to

provides=(firefox=${pkgver})

This way it works with packages that version check FX

figue commented on 2019-12-14 11:56 (UTC) (edited on 2019-12-14 12:06 (UTC) by figue)

New prebuilt binaries in my own openSUSE Build Service account:

[home_ffigue_Arch]
Server = http://download.opensuse.org/repositories/home:/ffigue/Arch/$arch

To verify signature, you can do like this:

$ wget -O- http://download.opensuse.org/repositories/home:/ffigue/Arch/x86_64/home_ffigue_Arch.key | sudo gpg --homedir /etc/pacman.d/gnupg --import -
$ sudo pacman-key --lsign-key F5AAC5A5424ED5CA

figue commented on 2019-12-06 21:45 (UTC)

@sp1d3rmxn thanks. Compilation with disable-elf-hack seems ok. Please test.

sp1d3rmxn commented on 2019-12-06 14:27 (UTC)

@figue

Ok the PKGBUILD change I added per the bug report has proven to also be successful with this.

Again like Icecat but, slightly different (no modifications to march/mtune either just like the Icecat build):

In the "prepare()" section under the heading "#Features" add this line:

ac_add_options --disable-elf-hack

It looks like this for me:

Features

ac_add_options --enable-alsa

ac_add_options --enable-jack

ac_add_options --enable-startup-notification

ac_add_options --enable-crashreporter

ac_add_options --disable-gconf

ac_add_options --disable-updater

ac_add_options --disable-elf-hack <---- ADD THIS LINE END

Again no further changes necessary and able to use CPU tuning as expected (no generics at all).

Hope this helps anyone going through the same headache.

figue commented on 2019-12-05 18:54 (UTC)

@sp1d3rmxn thank you, I reply you in IceCat AUR package. I have to compile FF ESR the same way. Seems that something is wrong when you tune CFLAGS...

sp1d3rmxn commented on 2019-12-05 16:36 (UTC)

This bullshit has been going on for awhile. It seems as though specifying your CPU arch is now an issue. Guess the new amateur hour devs are to <fill in the blank> to realize "x86-64" for generic purposes is weak sauce if you don't know that your CPU has specific instruction sets that can get you more bang for the buck. Anyways here's the report: https://bugs.llvm.org/show_bug.cgi?id=43659

sp1d3rmxn commented on 2019-11-22 13:43 (UTC)

@figue - Yes and no answer to your question, yes for the last 4 years we have run linux-hardened, been through many of these upgrades and no because these are stock and installed as such. The only compilation is due to packages being in AUR. We use distcc occasionally if there are a ton to upgrade but, that compiler was eliminated in these test runs.

The issues when new versions of libraries get released seems to be a decades old problem for linux devs to keep their shit straight. The comment section here is proof of the constant issues that shouldn't exist with something called "extended support ...". I did find several others who have had to downgrade to clang/llvm/rust to previous versions or others have changed the compilation back to GCC instead of the shitty clang like here: https://www.linuxquestions.org/questions/slackware-14/llvm-9-0-0-clang-segfault-firefox-build-4175661799/ or this about waterfox (another mozilla based product experiencing similar bullshit to this): https://aur.archlinux.org/packages/waterfox-classic-git/#comment-716172

I have even more links but, I think you get the idea. Doesn't seem to matter to much about the customization as much as it seems in tracking down patches due to devs not being thorough because others are experiencing identical issues and they aren't even using Arch.

I suspect others may not have gone through this because having 500 machines to manage as I do tends to show issues like this quickly.