|Version 91 (modified by 4 weeks ago) ( diff ),|
Firefox has a nasty habit of requiring a new profile every few releases. I say this is nasty because logins, current tabs, plugins (even if still supported) and perhaps bookmarks can be lost. In addition, it tends to name the profiles default, then default.default when it creates another. This can also apply when downgrading the version (e.g. going from 69.0 to 68.2.0esr). 73.0 required a new profile, that profile continues to work in 78.0
If you wish to use multiple profiles (or to be able to rename or delete old profiles), open firefox with 'firefox -P'.
You can also tell firefox to use a profile which it warns is old, either by invoking it from a term in xorg using 'MOZ_ALLOW_DOWNGRADE=1 firefox' or by invoking it as 'firefox --allow-downgrade'. The latter invocation has been troublesome in the past but appears to work since 68.2.0 and can be used from a desktop 'launcher'.
Which version should I use ?
In general, BLFS tries to always use latest releases. For firefox up to and including 69.0 the latest version has normally been used. But in late 2019 mozilla decided to move to a more-frequent release schedule (eventually 4 weeks instead of 6 or 7 weeks).
Newer versions tend to need newer versions of rust, but this can cause problems with other packages which use rust. In particular, thunderbird releases are based on the firefox esr (extended support releases) code and tend to have code which does not build with the latest version of rust.
There are only a few packages in BLFS which use rust and the editors aim to ensure that all the versions in the book can be built with the same version of rust.
As a result, after firefox-69 the book has moved to the esr versions of firefox which for 68esr was technically a downgrade (see details about profiles above), but contain all the relevant security fixes.
You should always use the latest release, either the latest esr or the latest mainline version (or the latest beta for bleeding edge). And you should remember to update your ca-certificates when building a new version of firefox.
Dependencies for 78-ESR series
Although the book is tested with its latest versions of the dependencies it should be possible to use older versions of some packages:
cbindgen >= 0.14.1 should work
icu needs to be >= 67.1
libwebp >= 1.1.0 should work
node.js needs to be at least v10.19.0. The latest node-v10 is v10.23.1. On BLFS-9.0 and 8.4, v10 built using
export CC=clang CXX=clang++ CFLAGS="$CFLAGS -std=c11" CXXFLAGS="$CXXFLAGS -std=c++14"
nss needs to be at least 3.53.1 with its corresponding version of nspr, but there have been various fixes since then, the latest version of nss continues to be recommended.
The minimum rustc version remains at 1.41.0, which was buggy. Use 1.42.0. If your version of llvm is less than 10.0, build rustc using its shipped llvm (see http://wiki.linuxfromscratch.org/blfs/wiki/rust).
Other changes to the build between 68esr and 78esr
The patch for system graphite2 and harfbuzz has been discontinued. Shipped graphite2 was changed by mozilla so that the patch did not build. Later it became clear that with a revised harfbuzz patch the shipped harfbuzz code was still being compiled.
System sqlite can no-longer be used. Many years ago, having the shipped sqlite in the browser but with system sqlite used by other packages was reported to cause problems. So far, things now seem ok.
Importantly, after ff70 ./mach install no longer accepts '--verbose' and errors if it is used.
A profile which was created for 73.0 seems to work ok.
The available configure options have changed dramatically in 78.0, please review the up to date mozconfig in the book.
Changes to the build since 78.0
In firefox-81.0, creating the python virtual environments has been separated out. Trying to run ./mach build reports
Consider running 'mach bootstrap' or 'mach create-mach-environment' to create the mach virtualenvs, or set MACH_USE_SYSTEM_PYTHON to use the system Python installation over a virtualenv.
Trying ./mach bootstrap fails:
NotImplementedError: Bootstrap support for this Linux distro not yet available: lfs
I do not want to try the system python option because that looks as if it will use pip to download required packages and perhaps try to install them on the system.
Using './mach create-mach-environment' before running other mach commands (but after the exports) works.
With 78.7.0 I have changed the './mach build' invocation to first run './mach configure' (just checking deps and creating the build files ("reticulating splines") to be more consistent with conventional packages, followed by './mach build' after noticing this in an AUR thunderbird build.
Dependencies for the latest release
This is an attempt to help people who want to keep using the latest upstream release, and will be updated from time to time. It is also a store of important changes which will need to be addressed when the book moves to the next ESR version.
Dependencies for 88.0
cbindgen needs to be >= 0.16.0
The node.js version now tests for v10.23.1, you should update all old systems to the latest v10 (if LFS-9.0, I have no older systems) or the latest v12 or latest v14.
nspr needs to be >= 4.30.0
nss needs to be >= 3.63
rustc needs to be >= 1.47
Dependencies for 89.0beta
cbindgen >= 0.19.0
nss >= 3.64.0
As of 89.0b3 it reports that the UI has changed, and allowed me to select a theme - I chose 'System' and my previous 88.0 session came back. I see a lot of complaints about the new themes, but I cannot see any difference. One report said you have to toggle browser.proton.enabled in about:config and restart firefox, but after a fresh boot that was already enabled and I still cannot see the difference, nor can I find the alternative themes which were offered when I first booted this!
The prayer of the user - "From people working on UIs, good lord preserve us."
Note that gcc-11.1.0 as released cannot build 89.0betas, gcc-10 was ok, as is clang-12.0. That has now been fixed upstream at gcc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 patch is currently at https://www.linuxfromscratch.org/~ken/test/ pending further testing. Obviously you need to rebuild gcc to use this. Unfortunately, further testing shows that applying only that patch to gcc-11.1.0 makes it unusably slow - on an 8-core machine, most packages take from 1.5x to 2.5x longer, but some take considerably longer.