Monday, October 19, 2026

Re: PATCH www/librewolf: update to v 158.0-1

just remove the locked: true bits on pdfalttext and translations then. i don't really care as i leave them off anyway btw, i set locked: true on the others, matching ff (yes, ff port does not set locked on translation/alttextpdf) tbh i just sync ff, but disabled by default is fine. i mean, lw already sets these same off-by-default, but doesn't add locked: anywhere. perhaps i could just not patch policy at all? then without that, the only change is removing perplexity honestly, removing the policy patch entirely would be the most puffy thing to do. that's what i'd recommend. but it's up to you lot. do as you please. my patches are largely advisory, for reference purpose but the ports team is in charge of what they merge. so... choose :) Am 19.10.26 um 14:00 schrieb Stuart Henderson: > On 2026/10/19 13:50, Stuart Henderson wrote: >> On 2026/10/19 13:28, Leah Rowe wrote: >>> i don't think translations/pdfalttext are disabled outright, i think it's >>> just the AI bits. >> translations *are* in the "AI" group. >> >>> my port turns off AI entirely, in librewolf. the firefox >>> port also disabled AI, based on config provided by the justthebrowser >>> project. >> grmbl, so *that's* why I couldn't find it any more, I thought they had >> just messed about with where it was in the UI and I hadn't found it yet. >> >>> i do the same in librewolf. i don't think we should be putting >>> strain on electricity and water needlessly in the browser. > what you have is different than in firefox; the version in fx allows > reenabling from prefs, the version you have doesn't (locked: true) -- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

Re: emulators/wine

On Mon, Oct 19, 2026 at 11:43:54AM +0100, Stuart Henderson wrote: > well that is quite a surprise! > > > # keep this in sync with MODCLANG_VERSION > > # source for updates/new releases: https://thfr.gothub.org/wine-clang-pe-headers > > I'm concerned about this. Really need some information about how to > generate these, ideally an automated method that can run from llvm/clang > source tarballs as part of the emulators/wine build so that wine doesn't > block every lang/clang update, but if not then at least something that > can run from a make target. Something like this was originally done in the port, but it seemed excessive to extract the LLVM sources for the ~8 header needed by clang-pe to build the Wine DLL libraries. https://thfr.gothub.org/repos/?action=summary&path=wine-clang-pe-headers.git They're copied as-is and it shouldn't to hard to keep in sync. https://github.com/llvm/llvm-project/tree/llvmorg-22.1.8/clang/lib/Headers -Bryan.