I now attach a new tarball, based on: 
https://codeberg.org/vimuser/librewolf-openbsd-port/commits/branch/submit8

It 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:
> - 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?
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.
>
> - 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 (19K)
• OpenPGP_0x5C654067D383B1FF.asc (3K)