Solved firefox as of may 5 crashes, also firefox-esr...

I ended up opening a bug report for Thunderbird since I believe one for Firefox will arrive shortly:
That was't necessary, the issue was already fixed in ports before it landed in pkg repositories:
www/firefox{,-esr}, mail/thunderbird: remote LTO from default options

When rust's internal LLVM does not match the LLVM used for building
gecko ports, LTO-built binaries will be unstable, exhibit crashes
and other undesirable behaviour. Rust 1.60 created such a situation.
Disabling LTO will allow these ports to be used, and keeping it off
will safe on build and debug time.
If you build it from ports now, it should be fine, we just need to wait for the latest pkg repository to get updated.

Now I am using Midori
You can use the Firefox .pkg I uploaded!
 
Hi friends, the very latest version of Firefox is broken on my side; is it just me or are you having the same issue?

Code:
firefox-100.0_1,2
Name           : firefox
Version        : 100.0_1,2
Installed on   : Thu May  5 09:42:59 2022 EDT
The errors:
Code:
firefox #refreshed
console.warn: SearchSettings: "get: No settings file exists, new profile?" (new NotFoundError("Could not open the file at /home/freezr/.mozilla/firefox/1u2vk142.default-release/search.json.mozlz4", (void 0)))
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory.
Exiting due to channel error.
fish: Job 1, 'firefox' terminated by signal SIGTRAP (Trace or breakpoint trap)

Also Thunderbird has issues but looks related with some extensions...

had exactly the same errors with firefox-esr 91.9.0.1 built via poudriere on monday (may 2nd) on my desktop at home (12.3-RELEASE, quarterly branch). I rolled back to a ZFS snapshot before the upgrade to restore the previous (working) state with ff 91.8

I'm currently running another built for 'quarterly/2022Q2' with ff now being at version 91.9.2_1. I'll report back when I had the chance to upgrade the host again (either this evening or maybe tomorrow...)
 
There is a thread about this in the freebsd-ports mailing list. The workaround was to disable the LTO option if building from ports. This has been fixed in 100.0_3,2 which is now in ports so should be available in the package repositories soon.
 
I just discovered that disabling LTO *massively* reduces build times - It went down from ~1:20-1:50h (heavily varying over the last few builds) to only 25 minutes in the current poudriere build job for www/firefox-esr

Is there any negative side-effect in leaving LTO disabled? Needing only 1/6th of the build time sounds too good to be true, so where's the catch?
 
LTO indeed increases build time a lot. This is not specific to firefox.
The downsides of building without LTO are mainly larger binary size and overall slower performance (due to "less optimization". There should not be any functional disadvantage of disabling LTO.
 
I just discovered that disabling LTO *massively* reduces build times [...]
Are those incremental (Firefox) builds? More specifically: the much shorter build time without LTO is that an incremental build?
Do you employ meta mode: WITH_META_MODE=YES ?
 
Ahh, LTO stands for link time optimization. Interesting. Not related to Rust, but I've seen similar things with other languages and compilers that reveal subtle potential bugs in code. Inlining, loop unrolling, they all fundamentally change the code. Variables may need to be "decorated" differently (think volatile keyword) and other things. All subtle.
-o0 is nice for debugging because thing fancy is done and you can step through the code easily.
Higher levels of optimization may start bringing in parallel operations, branch prediction so when you are stepping through with a debugger you may jump all over the place.
But "production" levels of optimization you are better off starting with so you avoid the "it works with -o0".

Increase in build time is likely the linker making multiple passes over object code figuring out where it can do something for you.
 
Are those incremental (Firefox) builds? More specifically: the much shorter build time without LTO is that an incremental build?
Do you employ meta mode: WITH_META_MODE=YES ?
it's a relatively default poudriere install apart from enabled ccache, tempfs and PRIORITY_BOOST for some ports. I don't have WITH_META_MODE anywhere configured in poudriere.conf or make.conf. So I don't think its enabled or those are incremental builds, as poudriere clears out any packages that have been updated at the start of the poudriere bulk run.
 
I started using Midori and Claws-mail, until then. These programs are pretty good, though they lack convenience and features. I supposed any graphical Internet browser that has SpiderMonkey as a dependency may work for sites that need Javascript.

I'm wondering if the fixed packages have been made available. When I test installing Firefox and Thunderbird, before the confirm prompt, the amount of dependencies don't show up, including the ones that require uninstalling and reinstalling everything else. It's like dependencies associated with that messed up my graphics display. LLVM association with Mesa, gl or another dependency. libdrm needed to be reinstalled, and it took down my drm-kmod installation for FreeBSD. Another time, it seemed to bring down my drm-kmod install from packages.

Code:
New packages to be INSTALLED:
        aom: 3.3.0_1
        argp-standalone: 1.3_4
        botan2: 2.19.1
        dav1d: 1.0.0
        ffmpeg: 4.4.2_1,1
        firefox: 100.0_1,2
        lame: 3.100_4
        libass: 0.15.2
        libpci: 3.8.0
        libtheora: 1.1.1_7
        libv4l: 1.23.0
        libva: 2.14.0
        libvdpau: 1.5
        libvpx: 1.11.0
        libx264: 0.163.3060
        svt-av1: 1.0.0
        thunderbird: 91.9.0_2
        vmaf: 2.3.1
        x265: 3.4_2
        xvid: 1.3.7,1

Number of packages to be installed: 20

The process will require 640 MiB more space.

Proceed with this action? [y/N]:
In short, the latest packages from Latest are: Firefox 100.0_1,2 and Thunderbird 91.9.0_2. I wasn't paying attention to the version number that failed, but these could be different default option and patched builds. It didn't ask for the latest LLVM and Rust, and the seemingly perpetual uninstalls and installs that come with that. Also, the defaults for port building of Firefox and Thunderbird didn't have the LTO option set mentioned earlier.


Late edit: comparing to the comments before, they seem to be the same version numbers. Perhaps they changed their default options, made patches and made repository packages from them since then.
 
I've been using Claws-mail for a while and it's been pretty solid for me.
claws-mail has been my only mail client for years. much saner and without the insane amount of bloat thunderbird has gathered over the years... also uses plain, simple and battle-tested gpg, not some (horribly implemented) home-brewn solution.
 
These latest packages don't interfere with kmod drm, which caused Xorg problems before.

It uses Meson as a dependency now, instead of the latest LLVM.


The following notice is of no consequence:
ATTENTION: default value of option mesa_glthread overridden by environment.

Late edit: In the previous packages they simplified LLVM and Rust dependencies, so it didn't require the latest of these, and so the install wouldn't interfere with drm and mesa. On these pkgs that work, the dependency Meson replaced LLVM.
 
claws-mail has been my only mail client for years.
also uses plain, simple and battle-tested gpg, not some (horribly implemented) home-brewn solution.
How did you get gpg to work? I always get a "No such file or directory" error when using Claws Mail with gpg.


I haven't had any issues with firefox-esr after upgrading, there may have been a patch I'm not aware of because I just upgraded today.
 
How did you get gpg to work? I always get a "No such file or directory" error when using Claws Mail with gpg.
I didn't configure anything special in claws-mail. it even detects the correct private key to use from the mail address...
simply install and configure gpg /w gpg-agent and it 'just works'™
The only thing you might have to change nowadays is the key server in gpg.conf (e.g. hkps://keys.opepgp.org), as the sks-servers are gone thanks to a braindamaged interpretation of the GDPR...
 
I figured out that even using gpg on its own yields a "No such file or directory" error and can't find anything but Windows users getting the problem.. Thanks for that keyserver though, I set it to use that.
 
Back
Top