still compiling, but i noticed this in the meantime:

https://codeberg.org/vimuser/librewolf-openbsd-port/commit/59917feb7aac09def38582b530f62f09d64ca965

this shouldn't actually affect anything functionally, due to the way 
diff format works, but this patches out a leftover from when i manually 
converted a git diff to create a patch for this port

just a minor thing really


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/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

• OpenPGP_0x5C654067D383B1FF.asc (3K)