From: Leah Rowe Subject: Re: new port: LibreWolf Web browser To: Landry Breuil , ports@openbsd.org Date: Sun, 19 Apr 2026 13:36:03 +0100 Just the person I wanted to talk to :) I also drive-by pinged sthen on an IRC channel last night. Hi Landry, First of all, thank you for taking the time with me. I've been an admirer of the OpenBSD project for some time, and this is my very first port. Now, in answer to your email, Am 19.04.26 um 07:38 schrieb Landry Breuil: > hi, i havent looked closely at the port (and sorry it won't make 7.9, > too late), but just one first comment on this: That was expected, and that's OK, I shall observe your restrictions. I run -current exclusively anyway, so it can go in 8.0 later, if someone wants it in a stable release. No worries at all. >> * I intend to regard LibreWolf -REVISION changes as the same major version >> in an OpenBSD context, because the OpenBSD LibreWolf package strips >> -REVISION, so e.g. 149.0.2-2 becomes just 149.0.2 in OpenBSD. If I change >> from e.g. -1 to -2, then I would update REVISION= in the OpenBSD port >> Makefile, but then later if LibreWolf released LibreWolf 150, I would >> reset/remove REVISION, then reintroducing it for 150.0.X-1, -2 -3 and so on. >> This ensures that the LibreWolf version number on OpenBSD packages will >> always match the Mozilla FireFox version number, and only the REVISION (e.g. >> p1, p2, p3 etc) would potentially diverge. > i wouldnt drop the 'upstream -REVISION', rather convert it to yet > another dot in the version (eg ${MOZILLA_VERSION:S/-/.}) because: > - REVISION is bumped when you change something in the port and nothing > changed upstream It had not occurred to me that I might replace -x with .x in the OpenBSD version, hence my previous logic. However, you are quite right. Then I shall prepare "submit2", with this change. Having e.g. 149.0.2-2 become 149.0.2.2 is also somewhat awkward, but better than simply omitting it as I currently do, and it is likely the only viable solution within OpenBSD's ports system. The only real reason I stripped e.g. -2 before, is that the ports system regarded -x as flavor "x", which was invalid. Replacing -x with .x makes perfect sense to me. I've attached a new tarball, with the change you requested; it is no different than submit1's tarball, except that it contains these changes: Replace dist version -x with .1 -> https://codeberg.org/vimuser/librewolf-openbsd-port/commit/7248483cc5b1e79427985fee2ad3a8d02ba03735 Change license to OpenBSD's preferred one -> https://codeberg.org/vimuser/librewolf-openbsd-port/commit/c6ba17a9d45878227aa45b750372eea3186154e1 I'm re-building this now, but I anticipate no issues. Feel free to review this new version at your leisure. > generally speaking i'm not a fan of firefox forks (they can be somewhat > PR-hostile vs upstream, which i find often unfair, but ofc i'm biaised), > but as long as they have a proper MAINTAINER and don't get in the way of > www/mozilla/mozilla.port.mk changes i (rarely) need to do for the other > mozillas, that's fine to have them in the portstree. diversity is good > for the end-user. Yes, I've designed my port specifically to not interfere at all with www/mozilla or www/mozilla-firefox - I only adapt its patching and versioning as appropriate. If there ever comes a point where my port requires invasive changes to the existing mozilla ports, I would adapt accordingly so as to avoid this precisely. For example, if that were to occur, I might override a specific configuration from my port while not touching the other ports; in the worst-case future scenario, I could do away with www/mozilla as a dependency in my port, making it completely standalone instead (as was originally my intention). Because LibreWolf upstream closely keeps in sync with the latest FireFox releases, this strategy works and causes no friction in OpenBSD. I don't anticipate any friction, now or in the future. LibreWolf upstream is quite competent and they themselves try to eliminate friction on their end, working closely with the FireFox upstream in parallel at all times. And yes, I will be ten thousand percent clear: I set MAINTAINER = Leah Rowe in my port's Makefile, because I intend to maintain this port long term. I shall be its maintainer. I don't expect anyone else to maintain this port for me, moving forward. I've recently decided to switch to OpenBSD as my main operating system, and I have more ports planned, for things I use. I  may also start fiddling with the base system at some point, and send patches where indicated. As for pull requests, see: https://codeberg.org/librewolf/source/pulls LibreWolf largely focuses on changes to FireFox in line with their main goal of privacy- and security-based hardening, and of course keeping in sync with upstream. Their actual main repository (what I just linked to) doesn't contain the FireFox source code at all, but rather, has a bootstrap script that downloads Mozilla FireFox and applies all of their patching, for the given supported release version. They essentially maintain their own analog of the ports system, though their focus is Linux, Windows and Mac support. They provide regular release tarballs, built from said bootstrap script. This then provides the full Mozilla FireFox source code, with their patching and branding, and it is precisely this source code (inside their tarball) that I use in my port for OpenBSD. It is essentially a drop-in replacement for the FireFox source tarball. In other words, LibreWolf focuses on integration with the Mozilla source code; changes beyond the scope of their mission might be rejected, on the basis that they should be sent upstream (to FireFox instead), but that would seem completely acceptable to me. For example, if some new video codec came out and someone wanted it in the browser, LibreWolf would likely prefer submitting that upstream (to FireFox) first, for it to then trickle down into their distribution. From OpenBSD's perspective, we observe none of this; all we care about is the LibreWolf tarball which is, for all intents and purposes, a drop-in replacement of the FireFox tarball. This will be my focus as well, in OpenBSD, providing only the most conservative changes possible and staying entirely in sync with upstream (LibreWolf) where possible. The only changes I've made to LibreWolf are ones that fix the build, as in the FireFox port, or OpenBSD-specific preferences e.g. disabling AI by default, as in the FireFox port. A surgical, light-touch approach, just as OpenBSD would want. > > (oh and thanks for providing many details on what you changed and why, > that greatly helps reviewing a port submission like this one) Several people have already tried the port too, and it seems to work. That makes me happy. > > Landry -- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK