here is a new tarball, containing a small fix to the lw policy patch; the patch contained a relic from when i manually converted the patch from git to openbsd ports format, which is cvs-style patching. the patch applies regardless, but when i did this port, i initially worked on a git repository of librewolf. as mentioned in my previous reply, this patch takes openbsd's firefox policy changes and adapts it on top of librewolf's own policy file.
this tarball includes all changes from submit8 (the previous email), such as: use xshm 1.2, ports-clang 22, librewolf 151.0.3-1, change SO_VERSION to 0.0 as per openbsd policy on new ports.
this is up to date versus the latest firefox, but using the corresponding librewolf version.
i confirm that this does in fact build perfectly on ports-clang 22, and it runs perfectly.
librewolf upstream does not provide PGO data, so openbsd's use of PGO on mozilla-firefox has not been adapted for librewolf.
hopefully this new version is ready to merge, but any and all further review is welcome. please also do look at my previous email, where i did address some points made by a reviewer.
Am 03.06.26 um 00:45 schrieb Leah Rowe:
I now attach a new tarball, based on: https://codeberg.org/vimuser/librewolf-openbsd-port/commits/branch/submit8It has the following updates:* Update to ports-clang 22: https://codeberg.org/vimuser/librewolf-openbsd-port/commit/ece9192ee68dce7292c29b86ed703041e8ef8abc* Use XShm 1.2 for better screen capture support with pledge: https://codeberg.org/vimuser/librewolf-openbsd-port/commit/44f0603ca2a39e1a497d4381cc2137c6340c3dca* Update to LibreWolf 151.0.3-1: https://codeberg.org/vimuser/librewolf-openbsd-port/commit/85cb40d462484ba900bf3f3932b83ba878c15d04* Change SO_VERSION to 0.0 - yes, you said that by policy, a new port like this must start from zero.Now, to answer your questions: Am 30.05.26 um 14:32 schrieb Caspar Schutijser:I wasn't aware what it was, so at first I simply copied what Firefox did. With the explanation given by @landry, I have now done as you ask.- Question to other developers: I think it would make sense to have SO_VERSION start at 0.0 instead of 163.0. Do you agree?- When diffing LibreWolf's Makefile with Firefox' Makefile, I see some differences that are mostly whitespace or the addition of quotes ("). I can see why you'd do that, but in the interest of keeping the diff with Firefox as small as possible, if I were you I'd just follow what the Firefox port does. If you would want to fix those, my approach would be to first change those in the Firefox port and then you could copy them to LibreWolf again. But in the end, it's up to you :)I think what I've done is perfectly fine for this port, and even desirable, which is why I did it. I wanted the Makefile to be easier for people to understand, and I did what was feasible (under the limitations of Make) to fix potential globbing issues that I found in the original Firefox port.I don't see how this should be relevant regarding Firefox, as Librewolf is its own port; the fact that I used the Firefox port as a base is merely a coincidence, one of convenience but I could have just as easily did the port from scratch (and an earlier version of the port was largely written from scratch, with the Firefox port only as a reference). Of course, I could also make these improvements to Firefox. You'll note that I also remove a lot of path repetition by putting path strings in variables, thereby reducing the column width per line (every line in my Makefile is 79 characters or fewer in length, not counting line breaks).Don't worry. The current Librewolf port, as I've implemented it, is perfectly in sync with Firefox. The only functional changes are those ones specific to LibreWolf. I track changes to OpenBSD's firefox and I'm quite fastidious about it. I adapt each change, per commit.Were I to ever make a change on my port that is also suitable for Firefox, ideally it should be submitted in the Firefox port as well. My changes to string variables and double-quoting should definitely be adapted for the Firefox port as well, since they do (in my opinion) make it easier to understand the Makefile, and it reduces the chance of splitting strings; in practice, the way ports is used by OpenBSD as a project make it a non-issue. Some of the globbing issues cannot be fixed in either port, due to inherent limitations of how Make handles variables.- And of course the port would need some catching up to the changes in the last few days, like landry@'s LLVM 22 fixes.I have updated to LLVM 22, as in the above changelog.- patch-lw_policies_json: the last few lines look like the patch file originates from git. Perhaps you can do "make update-patches" to make sure it doesn't introduce a useless diff later.Actually, this is an adaptation of one set of changes that OpenBSD makes to Mozilla Firefox; I adapted it for Librewolf, which also provides its own policy file, so instead of merging OpenBSD's firefox policy file as-in, I adapt OpenBSD's version as a patch for LibreWolf's policy. I don't think this will be a problem, but I could perhaps upstream this patchset (send it to LibreWolf).As is, I don't think I should do anything about this, for the port merge. It is something that can be addressed at a later date, as part of regular maintenance.I must note that as I write this, I am currently building the port with these changes as shown above. I'm confident that it will build, and work perfectly. I will nonetheless report back with a follow-up email, after the build is complete and after I've tested everything. As it currently stands, these updates mean that my port is currently in perfect sync with www/mozilla-firefox.
-- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK
librewolf.tar.xz
Description: application/xz
OpenPGP_0x5C654067D383B1FF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
