OpenBSD Journal

The many ways of running firefox on OpenBSD

Contributed by weerd on from the mighty lizards and spiders dept.

Landry Breuil, OpenBSD's firefox (and other Mozilla ports) maintainer, writes:

Maybe i haven't talked about it enough on the lists, but since i've been maintaining the various mozillas in the portstree (cvs log says i started around firefox 3.6.something... 7 years ago. *sigh*) a lot of things changed, so i wanted take the 6.1 release as an occasion to sum up the various ways one could run which version of which firefox on which version of OpenBSD.

First, and this has been the case for a few years already, these days I only target amd64 and i386. It's been "fun" for a while but now it's impossible to keep up with macppc and sparc64, although Martin Husemann from NetBSD still manages to run recent firefox on sparc64, i gave up on this - even *running* firefox on an i386 netbook with 1Gb of memory is unbearable. Sad state of affairs.. and on top of this, the recent dependency on rust also limits the amount of platforms firefox could run on, since rust only works on amd64 and i386 for now (thanks to the insane amount of work by semarie@ !).

So, for mozilla i do my maintenance work in two distinct ways...

On one hand, i'm running a buildbot on -current, with amd64 and i386 -current slaves (there's also a freebsd amd64 -current slave, courtesy of This buildbot starts builds every night of mozilla-central (ie, firefox trunk), comm-central (ie thunderbird trunk) and mozilla-aurora (the 'stabilization' branch between trunk and beta, although this one is going away soon) - and this on all slaves. Those branches build unpatched on OpenBSD, and with the default upstream options, which is a nice achievement - and sometimes, that of course breaks, the buildbot waterfall view is burning, kittens die, etc.

If the build succeeds, it produces a 'mozilla package', available at - those aren't OpenBSD packages at all, but rather archives with the same layout as mozilla-provided binaries for Tier1 platforms.

firefox-55.0a1.en-US.openbsd6.1-i386.tar.bz2 is a build from the trunk on i386, firefox-54.0a2.en-US.openbsd6.1-x86_64.tar.bz2 is a build from the aurora branch on amd64, etc. To run one, grab it, extract it, run ./firefox, and if you have the correct libraries on your system (ie, the same that i have on the -current slaves at the time of the build), congrats, you're running a Nightly version of firefox (check it by visiting about:buildconfig and about:support...) with all the default options, like most mozilla developers do. It's advised of course to run this instance with a separate profile to avoid messing up your daily firefox profile...

And on the other hand, i build (almost) each beta and release candidate of firefox (available upstream like every final release as a ~200Mb source tarball) and thunderbird, most of the times only on amd64 -current, so that i can run it on all my machines. Those beta/rc are built from a branch of a git repo tracking the www/mozilla-firefox port, where i maintain the various branches from which i push releases to the end users on the official OpenBSD cvs. This git repo is of course public and clonable.

From this 'beta' branch of the port, I build OpenBSD packages, that i sign with a signify key and distribute, even over https!. That means that if you're also running amd64 -current and added my signify key to your machine, you can run the latest *beta* version of firefox by just updating its package via:

doas env PKG_PATH= pkg_add -u firefox

Of course, i also do the same builds for the ESR branch of firefox, which is a sort-of non-bleeding-edge-maintained-longer version, targeted at enterprise users, and getting a major update every 7 releases of firefox (10, 17, 24, 31, 38, 45, 52,....). This work is done in the www/firefox-esr port, and gets updated every 6 weeks, following regular mainline firefox updates.

But to benefit from all those updates every 6 weeks, it means you need to be running -current, and it seems some of our users like to run -stable or -release for various reasons on their desktops. So for 6.1, i decided to try merging the firefox updates commited in -current to -stable, this needs some work to ensure correct versions of dependencies are used, so we'll see if this is sustainable on the long term. For now, i've just updated www/mozilla-firefox to 53.0 and www/firefox-esr to 52.1.0 in the 6.1 -stable branch, and as good things never come alone, i've also built -stable packages for them on i386 and amd64, signed with the same signify key - just point PKG_PATH to$(arch -s), and you should be able to run the latest & greatest firefox on your -stable desktop.

With that, anyone should be able to decide which firefox version to run on which version of OpenBSD... don't hesitate to send feedback on those packages and ports, of course! Starting with firefox 54, and the resolution of bug #1348576, multi-process (e10s) might get enabled to some users by default, provided you don't have incompatible addons (check about:support for multiprocess status). You can of course enable it now by toggling browser.tabs.remote.autostart preference to true, and start dogfooding it..

PS: No i can't do anything about the crashes or the OOMs ! Send your reports directly upstream !
PPS: No, i won't build packages for -stable for other ports, i'll let others talk of what's cooking for that topic ....
PPPS: i don't know yet what to do about thunderbird in -stable, as 6.1 had the previous 45 branch, that would be disrupting.

(Comments are closed)

  1. By Will Backman ( on

    Wow! That is much more effort than I anticipated. As a user of Firefox, I just want to say thank you!

  2. By Anonymous Coward ( on

    Recent builds for -stable. That's awesome. Thanks for your great work.

  3. By michael reed ( on

    thanks a lot for all your work landry!

  4. By Noryungi (noryungi) on

    Some missing characters in the second paragraph: "rst" should probably be "First".

    Yes, I am nitpicking... ;-)

  5. By Anonymous Coward ( on

    Seems aurora (dev edition) and beta branches are merging. Interadasting.

Latest Articles


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]