[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: emulators/wine
From: Thomas Frohwein <tfrohwein () fastmail ! com>
Date: 2026-10-18 22:08:43
Message-ID: 20261018150843.271e0c06 () babcom6 ! home ! arpa
[Download RAW message or body] Hello, In what might the most surprising port proposal of the year, I'm proud
to present a new port for wine. This has been a collective effort,
after some of the prodding at the %gs/gsbase question (see thread [1]).
The gates swung open with Andrii's software solution to the %gs issue -
explanation to me: "can't set gsbase, so we are emulating %gs prefix on
commands". Overall, the heavy lifting was done by Andrii and Fabien - kudos. Turns out there is a ground-swell with interest in wine [2], different
than even 5-10 years ago because a lot of Windows software has since
moved to being 64bit. We have since tested several dozens of 64-bit Windows software, mostly
successfully. See screenshots at [3][4][5], livestream recordings at
[6] for example. Even the Remaster of The Witcher 3 which released just
last month runs, and runs well (requires adding in vkd3d-proton; see
README; livestream at [7] which looks less fluent than it is due to
the on-system recording with ffmpeg). Biggest limitation is that WoW64 doesn't work, so 32bit Windows
software is still a no-op. You can check .exe/.dll easily with file(1)
- if it says something like "MS-DOS executable PE for MS Windows (GUI)
Intel 80386 32-bit", then it's 32-bit. The builtin-tests are disabled for now. Enabling them is pretty
involved as they need access to the X server and multiple tests still
hang, however that was not observed in the real life testing with a
good number of games. This is still being worked on. For those who wish to test it, I suggest Notepad++ as a small, fairly
straightforward piece of 64-bit Windows software [8]. Note that this
is (as always) run-at-your-own-risk software (see [9]). Consider
setting up a separate, non-privileged user for this until we can
explore if some fencing in, potentially with unveil(2) can be done. Appreciate testing of the port draft and contributions by: brynet@,
bentley@, pertho (on irc.libera.chat #openbsd-gaming), vl_ms ok? [1] https://marc.info/?l=openbsd-tech&m=179067466617674&w=2
[2] https://marc.info/?l=openbsd-tech&m=179070170845285&w=2
[3]
https://old.reddit.com/r/openbsd_gaming/comments/1x4e7fi/some_samples_from_wip_wine_port/ [4]
https://old.reddit.com/r/openbsd_gaming/comments/1x5yxpu/more_wineonopenbsd_screenshots/ [5]
https://old.reddit.com/r/openbsd_gaming/comments/1x7z2ry/even_more_wineonopenbsd_proof/ [6] https://video.gamerstavern.online/w/8tjjFRDtGJQZwxfE4ojVoC
[7] https://video.gamerstavern.online/w/oZcTRKL5JMiU4M4FqGKcNH
[8]
https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.8.1/npp.8.9.8.1.portable.x64.zip [9]
https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#is-wine-malware-compatible [Attachment #3 (application/x-compressed-tar)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 2

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Bryan Steele <brynet () openbsd ! org>
Date: 2026-10-18 22:58:09
Message-ID: atVPAebWdB6a-UBl () gmail ! com
[Download RAW message or body] On Sun, Oct 18, 2026 at 03:08:43PM -0700, Thomas Frohwein wrote:
> Hello,
> > In what might the most surprising port proposal of the year, I'm proud
> to present a new port for wine. This has been a collective effort,
> after some of the prodding at the %gs/gsbase question (see thread [1]).
> The gates swung open with Andrii's software solution to the %gs issue -
> explanation to me: "can't set gsbase, so we are emulating %gs prefix on
> commands". Overall, the heavy lifting was done by Andrii and Fabien - kudos.
> > Turns out there is a ground-swell with interest in wine [2], different
> than even 5-10 years ago because a lot of Windows software has since
> moved to being 64bit.
> > We have since tested several dozens of 64-bit Windows software, mostly
> successfully. See screenshots at [3][4][5], livestream recordings at
> [6] for example. Even the Remaster of The Witcher 3 which released just
> last month runs, and runs well (requires adding in vkd3d-proton; see
> README; livestream at [7] which looks less fluent than it is due to
> the on-system recording with ffmpeg).
> > Biggest limitation is that WoW64 doesn't work, so 32bit Windows
> software is still a no-op. You can check .exe/.dll easily with file(1)
> - if it says something like "MS-DOS executable PE for MS Windows (GUI)
> Intel 80386 32-bit", then it's 32-bit.
> > The builtin-tests are disabled for now. Enabling them is pretty
> involved as they need access to the X server and multiple tests still
> hang, however that was not observed in the real life testing with a
> good number of games. This is still being worked on.
> > For those who wish to test it, I suggest Notepad++ as a small, fairly
> straightforward piece of 64-bit Windows software [8]. Note that this
> is (as always) run-at-your-own-risk software (see [9]). Consider
> setting up a separate, non-privileged user for this until we can
> explore if some fencing in, potentially with unveil(2) can be done.
> > Appreciate testing of the port draft and contributions by: brynet@,
> bentley@, pertho (on irc.libera.chat #openbsd-gaming), vl_ms
> > ok?
> > [1] https://marc.info/?l=openbsd-tech&m=179067466617674&w=2
> [2] https://marc.info/?l=openbsd-tech&m=179070170845285&w=2
> [3]
> https://old.reddit.com/r/openbsd_gaming/comments/1x4e7fi/some_samples_from_wip_wine_port/
> [4]
> https://old.reddit.com/r/openbsd_gaming/comments/1x5yxpu/more_wineonopenbsd_screenshots/
> [5]
> https://old.reddit.com/r/openbsd_gaming/comments/1x7z2ry/even_more_wineonopenbsd_proof/
> [6] https://video.gamerstavern.online/w/8tjjFRDtGJQZwxfE4ojVoC
> [7] https://video.gamerstavern.online/w/oZcTRKL5JMiU4M4FqGKcNH
> [8]
> https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.8.1/npp.8.9.8.1.portable.x64.zip
> [9]
> https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#is-wine-malware-compatible I've been testing iterations of this port for the past week, and have
played at least one game I own on GOG, "Iratus". Work fine, but have
to set the language to English in the game menus. An incredible amount of effort by Andrii, fabien@ and others. While
there are some rough edges, there's nothing that can't be cleaned up
in-tree. port builds on amd64 (tested on Intel 11th Gen w/ IBT), runs, it will destroy your
productivity successfully (thanks a lot thfr@!) ok brynet@ -Bryan. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 3

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: gkrellm: not supposed to be setgid
From: "Theo de Raadt" <deraadt () openbsd ! org>
Date: 2026-10-18 23:36:52
Message-ID: 27275.1792366612 () cvs ! openbsd ! org
[Download RAW message or body] There is a change percolating through the whole tree. Not all the tree is fixed yet. > I just updated my packages and since last week something has changed for
> gkrellm which now terminates on start with:
> > /usr/local/bin/gkrellm: not supposed to be setgid, aborting
> > I must admit that I didn't know it's setgid but it really is:
> > $ ls -lh /usr/local/bin/gkrellm
> -rwxr-sr-x 1 root kmem 1.2M Oct 17 16:03 /usr/local/bin/gkrellm
> > Whether _all_ of gkrellm needs `kmem` levels of privilege or not, I don't
> know. But, presumably, either gkrellm will need fixing for (what I presume
> are) new security arrangements, or perhaps it can't be fixed?
> > > Laurie
> [prev in list] [next in list] [prev in thread] [next in thread] 

Page 4

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: Port request: xhidecursor
From: "Eugene Triguba" <hello () eugenetriguba ! com>
Date: 2026-10-18 23:37:20
Message-ID: 36dc09e0-c1fa-4f2b-bc6d-220856ff614b () app ! fastmail ! com
[Download RAW message or body] Hi Aleksandrs! I'll take a look into this. I use OpenBSD regularly, but I haven't created a port \
before. However, I've been meaning to get around to learning :) I appreciate the \
links for where it has been packaged elsewhere. Thanks,
Eugene On Fri, Oct 16, 2026, at 03:06, Aleksandrs Stier wrote:
> Hello,
> > I am the maintainer of xhidecursor (https://github.com/astier/xhidecursor), a \
> minimal X11 utility that hides the cursor on key presses and shows it again on \
> mouse movement. It prioritizes a simple implementation and efficient event \
> processing, ignoring redundant input events. > It is already available for Arch Linux through the AUR \
> (https://aur.archlinux.org/packages/xhidecursor), Void Linux \
> (https://github.com/void-linux/void-packages/blob/master/srcpkgs/xhidecursor/template), \
> and Slackware through SlackBuilds.org \
> (https://slackbuilds.org/repository/15.0/misc/xhidecursor/). > Over the last two releases, I've worked on OpenBSD portability by improving the \
> Makefile, and added OpenBSD pledge() support. > Would anyone be interested in creating and maintaining an OpenBSD port? I don't use \
> OpenBSD and cannot take on testing or port maintenance myself. > Best regards,
> Aleksandrs Stier
> [Attachment #3 (text/html)] <!DOCTYPE html><html><head><title></title></head><body><div>Hi&nbsp;<span \
class="color" style="color:rgb(240, 246, \
252);">Aleksandrs!</span></div><div><br></div><div><span class="color" \
style="color:rgb(240, 246, 252);">I'll take a look into this. I use OpenBSD \
regularly, but I haven't created a port before. However, I've been meaning to get \
around to learning :) I appreciate the links for where it has been packaged \
elsewhere.</span><br></div><div><br></div><div>Thanks,</div><div>Eugene</div><div><br></div><div>On \
Fri, Oct 16, 2026, at 03:06, Aleksandrs Stier wrote:</div><blockquote type="cite" \
id="qt" style=""><div>Hello,</div><div><br></div><div>I am the maintainer of \
xhidecursor (<a href="https://github.com/astier/xhidecursor" \
class="">https://github.com/astier/xhidecursor</a>), a minimal X11 utility that hides \
the cursor on key presses and shows it again on mouse movement. It prioritizes a \
simple implementation and efficient event processing, ignoring redundant input \
events.</div><div><br></div><div>It is already available for Arch Linux through the \
AUR (<a href="https://aur.archlinux.org/packages/xhidecursor">https://aur.archlinux.org/packages/xhidecursor</a>), \
Void Linux (<a href="https://github.com/void-linux/void-packages/blob/master/srcpkgs/x \
hidecursor/template">https://github.com/void-linux/void-packages/blob/master/srcpkgs/xhidecursor/template</a>), \
and Slackware through&nbsp;<a href="http://SlackBuilds.org">SlackBuilds.org</a> (<a \
href="https://slackbuilds.org/repository/15.0/misc/xhidecursor/" \
class="">https://slackbuilds.org/repository/15.0/misc/xhidecursor/</a>).</div><div><br></div><div>Over \
the last two releases, I've worked on OpenBSD portability by improving the Makefile, \
and added OpenBSD pledge() support.</div><div><br></div><div>Would anyone be \
interested in creating and maintaining an OpenBSD port? I don't use OpenBSD and \
cannot take on testing or port maintenance myself.</div><div><br></div><div>Best \
regards,</div><div>Aleksandrs Stier</div><div><br></div></blockquote></body></html> [prev in list] [next in list] [prev in thread] [next in thread] 

Page 5

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: [IMPROVEMENT] OpenBSD compatibility and safety fixes for devel/codex
From: David Uhden Collado <daviduhden () gmail ! com>
Date: 2026-10-19 2:36:00
Message-ID: 0b9dffce-9576-403a-83d2-6ac94aa1c859 () gmail ! com
[Download RAW message or body] Hello, Please find attached a patch improving Codex compatibility with
OpenBSD while keeping the changes to upstream code minimal. The main changes are: - Sandbox: Reject unsupported sandbox modes instead of silently running commands without the requested restrictions. pledge/unveil cannot safely sandbox arbitrary subprocesses across execve. Unrestricted execution remains available when explicitly selected. - Daemon: Keep the existing daemon functionality, but disable internal updates and downloads. Updates must go through pkg_add. Process identification is also made more reliable on OpenBSD. - Shell: Support OpenBSD's native ksh and sh without requiring Bash. - PTY: Improve file descriptor handling after fork to avoid unnecessary allocations and descriptor leaks. - Clipboard: Enable the existing X11 clipboard implementation on OpenBSD without introducing another backend. - Packaging: Declare missing runtime dependencies, fix PLIST ownership and document the supported features and limitations. The purpose is to disable features that cannot provide their
expected guarantees safely, while enabling compatible features
through small changes rather than extensive platform-specific code. I have been using Codex with these patches on OpenBSD 8.0-current
for intensive tasks over the past day without encountering any
problems. The clipboard integration still needs to be tested. I would appreciate review, particularly of the sandbox restrictions
and process execution changes. Thank you. Best regards,
David.
["codex-0.163.0p0.patch" (text/x-patch)] Index: devel/codex/Makefile
===================================================================
RCS file: /cvs/ports/devel/codex/Makefile,v
diff -u -p -u -p -r1.61 Makefile
--- devel/codex/Makefile	16 Oct 2026 09:32:32 -0000	1.61
+++ devel/codex/Makefile	18 Oct 2026 16:10:34 -0000
@@ -12,6 +12,7 @@ DPB_PROPERTIES =	parallel USE_WXNEEDED = Yes +REVISION = 0 V = 0.163.0 GH_ACCOUNT = openai GH_PROJECT = codex
@@ -52,7 +53,9 @@ BUILD_DEPENDS = devel/cmake/core \ LIB_DEPENDS = textproc/oniguruma \ x11/dbus -RUN_DEPENDS = lang/python/3 \
+RUN_DEPENDS = devel/git \
+ devel/xdg-utils \
+ lang/python/3 \ textproc/ripgrep MODULES = devel/cargo
Index: devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs
diff -N devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs	18 Oct \
2026 16:10:35 -0000 @@ -0,0 +1,21 @@
+OpenBSD uses the generic ps-based process identity. Keep its lstart string
+independent of the invoking client's locale and timezone so start/stop from
+different terminals can verify the same daemon. Other platforms are unchanged.
+
+Index: codex-rs/app-server-daemon/src/backend/pid.rs
+--- codex-rs/app-server-daemon/src/backend/pid.rs.orig
++++ codex-rs/app-server-daemon/src/backend/pid.rs
+@@ -746,8 +746,11 @@ async fn read_process_start_time(pid: u3
+ + #[cfg(unix)]
+ async fn read_process_details(pid: u32) -> Result<(String, String)> {
+- let output = Command::new("ps")
+- .args(["-p", &pid.to_string(), "-o", "stat=", "-o", "lstart="])
++ let mut command = Command::new("ps");
++ command.args(["-p", &pid.to_string(), "-o", "stat=", "-o", "lstart="]);
++ #[cfg(target_os = "openbsd")]
++ command.env("LC_ALL", "C").env("TZ", "UTC");
++ let output = command
+ .output()
+ .await
+ .context("failed to invoke ps for pid-managed app server")?;
Index: devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs_pkg_update
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs_pkg_update
diff -N devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs_pkg_update
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs_pkg_update	18 Oct \
2026 16:10:35 -0000 @@ -0,0 +1,39 @@
+Reject internal daemon update entry points and keep the updater disabled.
+
+Index: codex-rs/app-server-daemon/src/lib.rs
+--- codex-rs/app-server-daemon/src/lib.rs.orig
++++ codex-rs/app-server-daemon/src/lib.rs
+@@ -282,6 +282,10 @@ pub async fn run_pid_update_loop(
+ restore_release: Option<String>,
+ ) -> Result<()> {
+ ensure_supported_platform()?;
++ anyhow::ensure!(
++ !cfg!(target_os = "openbsd"),
++ "the daemon is managed by the system package manager; use pkg_add -u"
++ );
+ #[cfg(windows)]
+ backend::windows::ensure_not_elevated()?;
+ update_loop::run(http_client_factory, restore_release).await
+@@ -291,6 +295,10 @@ pub async fn update(
+ http_client_factory: codex_http_client::HttpClientFactory,
+ ) -> Result<UpdateOutput> {
+ ensure_supported_platform()?;
++ anyhow::ensure!(
++ !cfg!(target_os = "openbsd"),
++ "the daemon is managed by the system package manager; use pkg_add -u"
++ );
+ #[cfg(windows)]
+ backend::windows::ensure_not_elevated()?;
+ update_loop::request_manual_update(&Daemon::from_environment()?, \
http_client_factory).await +@@ -892,6 +900,11 @@ impl Daemon {
+ + async fn ensure_managed_updater(&self, settings: &DaemonSettings) -> \
Result<bool> { + let updater = \
backend::pid_update_loop_backend(self.backend_paths(settings)); ++ if \
cfg!(target_os = "openbsd") { ++ // Best effort: an invalid stale record \
must not prevent daemon start. ++ let _ = updater.stop().await;
++ return Ok(false);
++ }
+ if !settings.auto_update_enabled {
+ updater.stop().await?;
+ return Ok(false);
Index: devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs_pkg_update ===================================================================
RCS file: devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs_pkg_update diff -N devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs_pkg_update --- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs_pkg_update	18 \
Oct 2026 16:10:35 -0000 @@ -0,0 +1,16 @@
+Reject --from-cli package replacement under the system package manager.
+
+Index: codex-rs/app-server-daemon/src/prepare_install.rs
+--- codex-rs/app-server-daemon/src/prepare_install.rs.orig
++++ codex-rs/app-server-daemon/src/prepare_install.rs
+@@ -52,6 +52,10 @@ pub async fn update_from_cli(
+ confirm: impl FnOnce(&InstallRequest) -> Result<bool>,
+ ) -> Result<Option<crate::UpdateOutput>> {
+ crate::ensure_supported_platform()?;
++ anyhow::ensure!(
++ !cfg!(target_os = "openbsd"),
++ "the daemon is managed by the system package manager; use pkg_add -u"
++ );
+ #[cfg(windows)]
+ crate::backend::windows::ensure_not_elevated()?;
+ let daemon = Daemon::from_environment()?;
Index: devel/codex/patches/patch-codex-rs_cli_src_main_rs_pkg_update
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_cli_src_main_rs_pkg_update
diff -N devel/codex/patches/patch-codex-rs_cli_src_main_rs_pkg_update
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_cli_src_main_rs_pkg_update	18 Oct 2026 \
16:10:35 -0000 @@ -0,0 +1,15 @@
+Reject the package-manager update path with an explicit pkg_add message.
+
+Index: codex-rs/cli/src/main.rs
+--- codex-rs/cli/src/main.rs.orig
++++ codex-rs/cli/src/main.rs
+@@ -874,6 +874,9 @@ fn resolve_windows_update_command_from_p
+ }
+ + fn run_update_command() -> anyhow::Result<()> {
++ if cfg!(target_os = "openbsd") {
++ anyhow::bail!("Codex is managed by OpenBSD packages; update with pkg_add \
-u, then restart the daemon"); ++ }
+ #[cfg(debug_assertions)]
+ {
+ anyhow::bail!(
Index: devel/codex/patches/patch-codex-rs_config_src_constraint_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_config_src_constraint_rs
diff -N devel/codex/patches/patch-codex-rs_config_src_constraint_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_config_src_constraint_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,14 @@
+Index: codex-rs/config/src/constraint.rs
+--- codex-rs/config/src/constraint.rs.orig
++++ codex-rs/config/src/constraint.rs
+@@ -6,6 +6,10 @@ use thiserror::Error;
+ + #[derive(Debug, Error, PartialEq, Eq)]
+ pub enum ConstraintError {
++ #[cfg(target_os = "openbsd")]
++ #[error("OpenBSD cannot enforce managed sandbox permissions; explicitly select \
danger-full-access or externally supplied isolation")] ++ \
OpenBsdManagedSandboxUnavailable, ++
+ #[error(
+ "invalid value for `{field_name}`: `{candidate}` is not in the allowed set \
{allowed} (set by {requirement_source})" + )]
Index: devel/codex/patches/patch-codex-rs_core_src_config_mod_rs_sandbox
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_core_src_config_mod_rs_sandbox
diff -N devel/codex/patches/patch-codex-rs_core_src_config_mod_rs_sandbox
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_core_src_config_mod_rs_sandbox	18 Oct 2026 \
16:10:35 -0000 @@ -0,0 +1,19 @@
+Reject managed trusted-snapshot replacement on OpenBSD.
+
+Index: codex-rs/core/src/config/mod.rs
+--- codex-rs/core/src/config/mod.rs.orig
++++ codex-rs/core/src/config/mod.rs
+@@ -407,6 +407,13 @@ impl Permissions {
+ &mut self,
+ snapshot: PermissionProfileSnapshot,
+ ) -> ConstraintResult<()> {
++ #[cfg(target_os = "openbsd")]
++ if matches!(
++ snapshot.permission_profile(),
++ PermissionProfile::Managed { .. }
++ ) {
++ return \
Err(codex_config::ConstraintError::OpenBsdManagedSandboxUnavailable); ++ }
+ let permission_profile = \
Constrained::allow_only(snapshot.permission_profile().clone()); + \
self.permission_profile_state = + \ PermissionProfileState::from_constrained_snapshot(permission_profile, \ snapshot)?;
Index: devel/codex/patches/patch-codex-rs_core_src_config_resolved_permission_profile_rs ===================================================================
RCS file: devel/codex/patches/patch-codex-rs_core_src_config_resolved_permission_profile_rs diff -N devel/codex/patches/patch-codex-rs_core_src_config_resolved_permission_profile_rs --- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_core_src_config_resolved_permission_profile_rs	18 \
Oct 2026 16:10:35 -0000 @@ -0,0 +1,45 @@
+Index: codex-rs/core/src/config/resolved_permission_profile.rs
+--- codex-rs/core/src/config/resolved_permission_profile.rs.orig
++++ codex-rs/core/src/config/resolved_permission_profile.rs
+@@ -11,6 +11,14 @@ pub(crate) struct PermissionProfileState
+ permission_profile: Constrained<PermissionProfileSnapshot>,
+ }
+ ++#[cfg(target_os = "openbsd")]
++fn reject_openbsd_managed(permission_profile: &PermissionProfile) -> \
ConstraintResult<()> { ++ if matches!(permission_profile, \
PermissionProfile::Managed { .. }) { ++ return \
Err(codex_config::ConstraintError::OpenBsdManagedSandboxUnavailable); ++ }
++ Ok(())
++}
++
+ impl PermissionProfileState {
+ pub(crate) fn from_constrained_legacy(
+ constrained_permission_profile: Constrained<PermissionProfile>,
+@@ -72,6 +80,8 @@ impl PermissionProfileState {
+ &self,
+ permission_profile: &PermissionProfile,
+ ) -> ConstraintResult<()> {
++ #[cfg(target_os = "openbsd")]
++ reject_openbsd_managed(permission_profile)?;
+ let candidate = \
PermissionProfileSnapshot::legacy(permission_profile.clone()); + \
self.permission_profile.can_set(&candidate) + }
+@@ -80,6 +90,8 @@ impl PermissionProfileState {
+ &mut self,
+ permission_profile: PermissionProfile,
+ ) -> ConstraintResult<()> {
++ #[cfg(target_os = "openbsd")]
++ reject_openbsd_managed(&permission_profile)?;
+ self.permission_profile
+ .set(PermissionProfileSnapshot::legacy(permission_profile))
+ }
+@@ -88,6 +100,8 @@ impl PermissionProfileState {
+ &mut self,
+ snapshot: PermissionProfileSnapshot,
+ ) -> ConstraintResult<()> {
++ #[cfg(target_os = "openbsd")]
++ reject_openbsd_managed(snapshot.permission_profile())?;
+ self.permission_profile.set(snapshot)
+ }
+ }
Index: devel/codex/patches/patch-codex-rs_core_src_session_mod_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_core_src_session_mod_rs
diff -N devel/codex/patches/patch-codex-rs_core_src_session_mod_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_core_src_session_mod_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,22 @@
+Reject managed sessions at the central session-spawn boundary. Configuration-only
+commands (login, doctor, MCP administration) and app-server startup remain usable.
+
+Index: codex-rs/core/src/session/mod.rs
+--- codex-rs/core/src/session/mod.rs.orig
++++ codex-rs/core/src/session/mod.rs
+@@ -593,6 +593,15 @@ impl Session {
+ + async fn spawn_internal(args: SessionSpawnArgs) -> CodexResult<(Arc<Self>, \
SessionIo)> { + args.config.validate_windows_mxc_requirement()?;
++ #[cfg(target_os = "openbsd")]
++ if matches!(
++ args.config.permissions.permission_profile(),
++ PermissionProfile::Managed { .. }
++ ) {
++ return Err(CodexErr::UnsupportedOperation(
++ "OpenBSD cannot enforce a managed sandbox session; select explicit \
danger-full-access or external isolation".to_string(), ++ ));
++ }
+ let SessionSpawnArgs {
+ startup,
+ config,
Index: devel/codex/patches/patch-codex-rs_exec-server_src_process_sandbox_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_exec-server_src_process_sandbox_rs
diff -N devel/codex/patches/patch-codex-rs_exec-server_src_process_sandbox_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_exec-server_src_process_sandbox_rs	18 Oct 2026 \
16:10:35 -0000 @@ -0,0 +1,18 @@
+Index: codex-rs/exec-server/src/process_sandbox.rs
+--- codex-rs/exec-server/src/process_sandbox.rs.orig
++++ codex-rs/exec-server/src/process_sandbox.rs
+@@ -95,6 +95,14 @@ pub(crate) async fn prepare_exec_request
+ network_policy_audit_observer: Option<NetworkPolicyAuditObserver>,
+ telemetry: &ProcessTelemetry,
+ ) -> Result<PreparedExecRequest, JSONRPCErrorError> {
++ // A proxy environment cannot enforce egress policy without a command
++ // sandbox. Check before the sandbox=None native-launch shortcut too.
++ #[cfg(target_os = "openbsd")]
++ if params.enforce_managed_network {
++ return Err(invalid_params(
++ "OpenBSD cannot enforce managed command networking: no supported \
command sandbox is available".to_string(), ++ ));
++ }
+ if let Some(sandbox) = params.sandbox.as_ref()
+ && sandbox.windows_sandbox_selection == WindowsSandboxSelection::Mxc
+ {
Index: devel/codex/patches/patch-codex-rs_sandboxing_src_lib_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_sandboxing_src_lib_rs
diff -N devel/codex/patches/patch-codex-rs_sandboxing_src_lib_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_sandboxing_src_lib_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,14 @@
+Index: codex-rs/sandboxing/src/lib.rs
+--- codex-rs/sandboxing/src/lib.rs.orig
++++ codex-rs/sandboxing/src/lib.rs
+@@ -75,6 +75,10 @@ pub fn system_bwrap_warning(
+ impl From<SandboxTransformError> for CodexErr {
+ fn from(err: SandboxTransformError) -> Self {
+ match err {
++ #[cfg(target_os = "openbsd")]
++ SandboxTransformError::OpenBsdSandboxUnavailable => \
CodexErr::UnsupportedOperation( ++ "OpenBSD has no supported command \
sandbox; select explicit danger-full-access or provide external \
isolation".to_string(), ++ ),
+ error @ SandboxTransformError::InvalidCommandCwd { .. }
+ | error @ SandboxTransformError::InvalidSandboxPolicyCwd { .. } => {
+ CodexErr::InvalidRequest(error.to_string())
Index: devel/codex/patches/patch-codex-rs_sandboxing_src_manager_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_sandboxing_src_manager_rs
diff -N devel/codex/patches/patch-codex-rs_sandboxing_src_manager_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_sandboxing_src_manager_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,63 @@
+Index: codex-rs/sandboxing/src/manager.rs
+--- codex-rs/sandboxing/src/manager.rs.orig
++++ codex-rs/sandboxing/src/manager.rs
+@@ -189,6 +189,8 @@ impl PendingSandboxedExecRequest {
+ + #[derive(Debug)]
+ pub enum SandboxTransformError {
++ #[cfg(target_os = "openbsd")]
++ OpenBsdSandboxUnavailable,
+ InvalidCommandCwd {
+ cwd: PathUri,
+ source: io::Error,
+@@ -213,6 +215,11 @@ pub enum SandboxTransformError {
+ impl std::fmt::Display for SandboxTransformError {
+ fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
+ match self {
++ #[cfg(target_os = "openbsd")]
++ Self::OpenBsdSandboxUnavailable => write!(
++ f,
++ "OpenBSD has no supported command sandbox; select explicit \
danger-full-access or provide external isolation" ++ ),
+ Self::InvalidCommandCwd { cwd, source } => {
+ write!(
+ f,
+@@ -256,6 +263,8 @@ impl std::error::Error for SandboxTransf
+ Self::MissingLinuxSandboxExecutable => None,
+ Self::WindowsMxcPreparation(_) => None,
+ Self::EnvironmentNetworkProxy(_) => None,
++ #[cfg(target_os = "openbsd")]
++ Self::OpenBsdSandboxUnavailable => None,
+ #[cfg(target_os = "macos")]
+ Self::SeatbeltPreparation(_) => None,
+ #[cfg(target_os = "linux")]
+@@ -375,6 +384,29 @@ impl SandboxManager {
+ network.and_then(NetworkProxy::managed_mitm_ca_trust_bundle_path);
+ let base_effective_permission_profile =
+ effective_permission_profile(permissions, \
additional_permissions.as_ref()); ++ // OpenBSD has no upstream sandbox \
backend. Never interpret a missing ++ // backend as permission to run a \
restricted request without isolation. ++ #[cfg(target_os = "openbsd")]
++ {
++ let (file_system_policy, network_policy) =
++ base_effective_permission_profile.to_runtime_permissions();
++ if matches!(
++ &base_effective_permission_profile,
++ PermissionProfile::Managed { .. }
++ ) || sandbox != SandboxType::None
++ || (matches!(
++ file_system_policy.kind,
++ codex_protocol::permissions::FileSystemSandboxKind::Restricted
++ ) && !file_system_policy.has_full_disk_read_access())
++ || should_require_platform_sandbox(
++ &file_system_policy,
++ network_policy,
++ enforce_managed_network,
++ )
++ {
++ return Err(SandboxTransformError::OpenBsdSandboxUnavailable);
++ }
++ }
+ let pending_sandboxed_request = PendingSandboxedExecRequest::new(
+ &command.cwd,
+ sandbox_policy_cwd,
Index: devel/codex/patches/patch-codex-rs_shell-command_src_shell_detect_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_shell-command_src_shell_detect_rs
diff -N devel/codex/patches/patch-codex-rs_shell-command_src_shell_detect_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_shell-command_src_shell_detect_rs	18 Oct 2026 \
16:10:35 -0000 @@ -0,0 +1,42 @@
+Minimal OpenBSD ksh preference: recognize ksh and prefer ksh/sh fallback over \
bash/zsh. +Index: codex-rs/shell-command/src/shell_detect.rs
+--- codex-rs/shell-command/src/shell_detect.rs.orig
++++ codex-rs/shell-command/src/shell_detect.rs
+@@ -41,6 +41,7 @@ pub fn detect_shell_type(shell_path: imp
+ match shell_path.as_os_str().to_str() {
+ Some("zsh") => Some(ShellType::Zsh),
+ Some("sh") => Some(ShellType::Sh),
++ Some("ksh") => Some(ShellType::Sh),
+ Some("cmd") => Some(ShellType::Cmd),
+ Some("bash") => Some(ShellType::Bash),
+ Some("pwsh") => Some(ShellType::PowerShell),
+@@ -250,9 +251,15 @@ fn get_bash_shell() -> Option<DetectedSh
+ })
+ }
+ ++#[cfg(target_os = "openbsd")]
++const SH_FALLBACK_PATHS: &[&str] = &["/bin/ksh", "/bin/sh"];
++#[cfg(not(target_os = "openbsd"))]
+ const SH_FALLBACK_PATHS: &[&str] = &["/bin/sh"];
+ + fn get_sh_shell() -> Option<DetectedShell> {
++ #[cfg(target_os = "openbsd")]
++ let shell_path = get_shell_path(ShellType::Sh, "ksh", SH_FALLBACK_PATHS);
++ #[cfg(not(target_os = "openbsd"))]
+ let shell_path = get_shell_path(ShellType::Sh, "sh", SH_FALLBACK_PATHS);
+ + shell_path.map(|shell_path| DetectedShell {
+@@ -372,6 +379,13 @@ pub fn default_user_shell_from_path(user
+ user_default_shell
+ .or_else(|| get_shell(ShellType::Zsh))
+ .or_else(|| get_shell(ShellType::Bash))
++ } else if cfg!(target_os = "openbsd") {
++ // Prefer the platform ksh/sh over bash/zsh when the user shell is
++ // not a recognized explicit choice. An explicit bash/zsh stays.
++ user_default_shell
++ .or_else(|| get_shell(ShellType::Sh))
++ .or_else(|| get_shell(ShellType::Bash))
++ .or_else(|| get_shell(ShellType::Zsh))
+ } else {
+ user_default_shell
+ .or_else(|| get_shell(ShellType::Bash))
Index: devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs
diff -N devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs	18 Oct 2026 \
16:10:35 -0000 @@ -0,0 +1,28 @@
+Keep the daemon enabled while directing package updates to pkg_add.
+Do not offer self-installation actions for a distributor-owned executable.
+
+Index: codex-rs/tui/src/app/daemon_menu.rs
+--- codex-rs/tui/src/app/daemon_menu.rs.orig
++++ codex-rs/tui/src/app/daemon_menu.rs
+@@ -54,6 +54,10 @@ impl App {
+ Some(
+ "Manage this server on its host. Local daemon updates are \
unavailable for remote connections.", + )
++ } else if cfg!(target_os = "openbsd") {
++ Some(
++ "The daemon is installed by the system package manager. Use pkg_add \
-u, then codex app-server daemon restart.", ++ )
+ } else if self.daemon_cli_executable.is_none() {
+ Some("Run the Codex CLI to manage the daemon from this menu.")
+ } else {
+@@ -160,7 +164,9 @@ impl App {
+ let Some(executable) = &self.daemon_cli_executable else {
+ return;
+ };
+- if matches!(self.app_server_target, AppServerTarget::Remote { .. }) {
++ if matches!(self.app_server_target, AppServerTarget::Remote { .. })
++ || cfg!(target_os = "openbsd")
++ {
+ return;
+ }
+ let mut explanation = match source {
Index: devel/codex/patches/patch-codex-rs_tui_src_clipboard_copy_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_tui_src_clipboard_copy_rs
diff -N devel/codex/patches/patch-codex-rs_tui_src_clipboard_copy_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_tui_src_clipboard_copy_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,64 @@
+Keep the existing X11 clipboard lease alive on OpenBSD too. arboard uses
+its Unix/X11 backend here; no new clipboard implementation is introduced.
+
+Index: codex-rs/tui/src/clipboard_copy.rs
+--- codex-rs/tui/src/clipboard_copy.rs.orig
++++ codex-rs/tui/src/clipboard_copy.rs
+@@ -8,7 +8,7 @@
+ //! suppress native copying. Both the host and attached client's clipboards may
+ //! change. Outside tmux, Herdr, and SSH, use OSC 52 only if native copying fails.
+ //!
+-//! On Linux, X11 and some Wayland compositors require the process that wrote the
++//! On Linux and OpenBSD, X11 and some Wayland compositors require the process that \
wrote the + //! clipboard to keep its handle open. `ClipboardLease` wraps the \
`arboard::Clipboard` + //! so the copy worker can retain it for the lifetime of the \
TUI. On other platforms the lease + //! is always `None`.
+@@ -138,19 +138,19 @@ fn copy_to_clipboard(
+ + /// Keeps a platform clipboard owner alive when the backend requires one.
+ ///
+-/// On Linux/X11 and some Wayland compositors, clipboard contents are served by the
++/// On X11 (including OpenBSD) and some Wayland compositors, clipboard contents are \
served by the + /// owning process. Dropping the `arboard::Clipboard` before the user \
pastes causes + /// the content to vanish. Store this lease on a session-lived owner \
so closing a +-/// transient overlay does not release the clipboard contents. On \
non-Linux native paths and OSC 52 ++/// transient overlay does not release the \
clipboard contents. On other native paths and OSC 52 + /// paths the lease is `None` \
— those backends do not require process-lifetime + /// ownership.
+ pub(crate) struct ClipboardLease {
+- #[cfg(target_os = "linux")]
++ #[cfg(any(target_os = "linux", target_os = "openbsd"))]
+ _clipboard: Option<arboard::Clipboard>,
+ }
+ + impl ClipboardLease {
+- #[cfg(target_os = "linux")]
++ #[cfg(any(target_os = "linux", target_os = "openbsd"))]
+ fn native_linux(clipboard: arboard::Clipboard) -> Self {
+ Self {
+ _clipboard: Some(clipboard),
+@@ -160,7 +160,7 @@ impl ClipboardLease {
+ #[cfg(test)]
+ pub(crate) fn test() -> Self {
+ Self {
+- #[cfg(target_os = "linux")]
++ #[cfg(any(target_os = "linux", target_os = "openbsd"))]
+ _clipboard: None,
+ }
+ }
+@@ -279,12 +279,12 @@ fn arboard_copy(
+ None => clipboard.set_text(text),
+ }
+ .map_err(|e| format!("failed to set clipboard text: {e}"))?;
+- // Linux clipboard owners must stay alive until the user pastes.
+- #[cfg(target_os = "linux")]
++ // Linux and OpenBSD clipboard owners must stay alive until the user pastes.
++ #[cfg(any(target_os = "linux", target_os = "openbsd"))]
+ {
+ Ok(Some(ClipboardLease::native_linux(clipboard)))
+ }
+- #[cfg(not(target_os = "linux"))]
++ #[cfg(not(any(target_os = "linux", target_os = "openbsd")))]
+ {
+ Ok(None)
+ }
Index: devel/codex/patches/patch-codex-rs_tui_src_update_action_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_tui_src_update_action_rs
diff -N devel/codex/patches/patch-codex-rs_tui_src_update_action_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_tui_src_update_action_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,13 @@
+Index: codex-rs/tui/src/update_action.rs
+--- codex-rs/tui/src/update_action.rs.orig
++++ codex-rs/tui/src/update_action.rs
+@@ -81,6 +81,9 @@ impl UpdateAction {
+ + #[cfg(not(debug_assertions))]
+ pub fn get_update_action() -> Option<UpdateAction> {
++ if cfg!(target_os = "openbsd") {
++ return None; // Updates are managed by pkg_add, never an upstream \
installer. ++ }
+ UpdateAction::from_install_context(InstallContext::current())
+ }
+ Index: devel/codex/patches/patch-codex-rs_utils_pty_src_pty_rs
===================================================================
RCS file: devel/codex/patches/patch-codex-rs_utils_pty_src_pty_rs
diff -N devel/codex/patches/patch-codex-rs_utils_pty_src_pty_rs
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ devel/codex/patches/patch-codex-rs_utils_pty_src_pty_rs	18 Oct 2026 16:10:35 \
-0000 @@ -0,0 +1,62 @@
+Index: codex-rs/utils/pty/src/pty.rs
+--- codex-rs/utils/pty/src/pty.rs.orig
++++ codex-rs/utils/pty/src/pty.rs
+@@ -606,9 +606,57 @@ pub fn close_inherited_fds_except(preser
+ }
+ }
+ ++// OpenBSD has no allocating descriptor enumeration in this post-fork path.
++// Count valid descriptors rather than using resource limits: inherited high
++// descriptors may remain open after the process lowers its limits.
++#[cfg(target_os = "openbsd")]
++pub(crate) fn close_inherited_fds_except(preserved_fds: &[RawFd]) {
++ unsafe extern "C" {
++ // OpenBSD syscall; not exposed by all supported libc crate versions.
++ fn getdtablecount() -> libc::c_int;
++ }
++
++ // After fork this child has its own descriptor table and one thread. Block
++ // signal handlers while counting/scanning so they cannot change that table.
++ // Cleanup remains best-effort, matching the other platform implementations.
++ unsafe {
++ let mut all_signals: libc::sigset_t = std::mem::zeroed();
++ let mut old_mask: libc::sigset_t = std::mem::zeroed();
++ if libc::sigfillset(&mut all_signals) == -1
++ || libc::sigprocmask(libc::SIG_BLOCK, &all_signals, &mut old_mask) == \
-1 ++ {
++ return;
++ }
++ let mut remaining = getdtablecount();
++ for fd in 0..=RawFd::MAX {
++ if remaining <= 0 {
++ break;
++ }
++ let flags = libc::fcntl(fd, libc::F_GETFD);
++ if flags == -1 {
++ continue;
++ }
++ // Count every valid descriptor, including preserved and CLOEXEC
++ // descriptors, even though those must remain open until exec.
++ remaining -= 1;
++ if fd > libc::STDERR_FILENO
++ && !preserved_fds.contains(&fd)
++ && flags & libc::FD_CLOEXEC == 0
++ {
++ // Keep std::process's CLOEXEC exec-error pipe intact.
++ libc::close(fd);
++ }
++ }
++ libc::sigprocmask(libc::SIG_SETMASK, &old_mask, std::ptr::null_mut());
++ }
++}
++
+ // Other Unix platforms use best-effort /dev/fd cleanup.
+ // Directory enumeration allocates, so this path is not guaranteed fork-safe.
+-#[cfg(all(unix, not(any(target_os = "linux", target_os = "macos"))))]
++#[cfg(all(
++ unix,
++ not(any(target_os = "linux", target_os = "macos", target_os = "openbsd"))
++))]
+ pub(crate) fn close_inherited_fds_except(preserved_fds: &[RawFd]) {
+ if let Ok(dir) = std::fs::read_dir("/dev/fd") {
+ let mut fds = Vec::new();
Index: devel/codex/pkg/PLIST
===================================================================
RCS file: /cvs/ports/devel/codex/pkg/PLIST,v
diff -u -p -u -p -r1.8 PLIST
--- devel/codex/pkg/PLIST	9 Aug 2026 11:29:25 -0000	1.8
+++ devel/codex/pkg/PLIST	18 Oct 2026 16:10:35 -0000
@@ -19,7 +19,5 @@ share/doc/codex/sandbox.md share/doc/codex/skills.md share/doc/codex/slash_commands.md share/doc/pkg-readmes/${PKGSTEM}
-share/fish/
-share/fish/vendor_completions.d/ share/fish/vendor_completions.d/codex.fish share/zsh/site-functions/_codex [prev in list] [next in list] [prev in thread] [next in thread] 

Page 6

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: PATCH www/librewolf: update to v 158.0-1
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 7:36:02
Message-ID: e7f405d5-bcf1-448a-b980-ec68e35f8dea () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] Hi, I know ports tree is closed until after the 8.0 release. Just sending this patch anyway. I see that my 157 update patch did get merged anyway and the firefox 158 patch was merged on 13 october. i didn't check librewolf updates as much this month, precisely because openbsd is in release mode, otherwise i would have been more punctual with the update. no worries if this can't go in tree for 8.0 release as i can always backport it into -stable at a later date. -- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK ["0001-www-librewolf-update-to-158.0-1.patch" (text/x-patch)] From 1e5e3d7c8c56928ee4fcb8f988723d172424cb52 Mon Sep 17 00:00:00 2001
From: Leah Rowe <[email protected]>
Date: Sun, 18 Oct 2026 21:01:03 +0100
Subject: [PATCH 1/1] www/librewolf: update to 158.0-1 GenerativeAI control no longer relevant upstream,
as AIControls replaced it, which we also set already. I've tightened up the policy considerably; translations
and pdf alt text already blocked before in AIControls, and
now locked. I do not want my work contributing politively to
the scourge that is generative artificial intelligence. Besides this, I've rebased patching and synced with the
OpenBSD FireFox 158 port. Everything works. Signed-off-by: Leah Rowe <[email protected]>
--- www/librewolf/Makefile | 7 +- www/librewolf/distinfo | 8 +-- .../patches/patch-config_makefiles_rust_mk | 14 ++-- .../patches/patch-js_src_gc_Memory_cpp | 2 +- .../patches/patch-js_src_wasm_WasmStacks_cpp | 2 +- www/librewolf/patches/patch-lw_policies_json | 65 ++++++++----------- www/librewolf/patches/patch-mozconfig | 8 +-- .../patch-third_party_llama_cpp_moz_build | 2 +- 8 files changed, 48 insertions(+), 60 deletions(-) diff --git a/www/librewolf/Makefile b/www/librewolf/Makefile
index e59e4944b88..fe44267c609 100644
--- a/www/librewolf/Makefile
+++ b/www/librewolf/Makefile
@@ -13,9 +13,8 @@ ONLY_FOR_ARCHS =	amd64 aarch64 riscv64 # If upstream adds revision number -x, it will become plx in OpenBSD, e.g. # librewolf-149.0.2-2 (upstream) becomes librewolf-149.0.2pl2 (patch level 2)
-MOZILLA_DIST_VERSION =	157.0-1
+MOZILLA_DIST_VERSION =	158.0-1 MOZILLA_VERSION =	${MOZILLA_DIST_VERSION:C/-([0-9]+)$/pl\1/}
-REVISION = 0 MOZILLA_PROJECT =	librewolf MOZILLA_CODENAME =	browser
@@ -23,13 +22,13 @@ MAINTAINER = Leah Rowe <[email protected]> # LibreWolf doesn't provide PGO data, but we use the data # provided by FireFox releases, re-using the OpenBSD distfile
-MOZILLA_PROFDATA_TASKID =	BnF3vh8WT4OW53JJ0ow3mQ
+MOZILLA_PROFDATA_TASKID =	Yy7PLAWLTQ6Ru0Iqs0_iRQ FFVERSION = ${MOZILLA_DIST_VERSION:C/-([0-9]+)$//} FFDIST = firefox-${FFVERSION}.source DISTFILES.profdata = ${FFDIST}-profdata.tar.xz{profdata.tar.xz} HOMEPAGE =	https://librewolf.net/
-SO_VERSION =	6.0
+SO_VERSION =	7.0 # Bump minor ver if shlibs deleted in components dir to avoid pkg_add -r issues MOZILLA_LIBS =	mozavcodec mozavutil mozgtk mozinference mozwayland xul \ clearkey gkcodecs lgpllibs mozsqlite3
diff --git a/www/librewolf/distinfo b/www/librewolf/distinfo
index 0fcbdf9217b..f3995170a8b 100644
--- a/www/librewolf/distinfo
+++ b/www/librewolf/distinfo
@@ -1,4 +1,4 @@
-SHA256 (mozilla/firefox-157.0.source-profdata.tar.xz) = \ lwkzOiqkOrreLbO+tEnGwySn0Mb2+W4bNQBL39D/7/c=
-SHA256 (mozilla/librewolf-157.0-1.source.tar.gz) = \ vqPMfFfz+4ko1YOgYDsPQBMLAvZi4DJ0Y0WlHg9V/7M=
-SIZE (mozilla/firefox-157.0.source-profdata.tar.xz) = 18900828
-SIZE (mozilla/librewolf-157.0-1.source.tar.gz) = 1178691023
+SHA256 (mozilla/firefox-158.0.source-profdata.tar.xz) = \
Jd8si/gEYPCqHefjsMFmOyjt438g5pGAGiYqMhl0vuQ= +SHA256 \
(mozilla/librewolf-158.0-1.source.tar.gz) = \
6iQk+0wCkWwMUxIQ8d2LRg6FB08tjKBSnUlVPTbdE8A= +SIZE \
(mozilla/firefox-158.0.source-profdata.tar.xz) = 19008760 +SIZE \ (mozilla/librewolf-158.0-1.source.tar.gz) = 1181473241
diff --git a/www/librewolf/patches/patch-config_makefiles_rust_mk \
b/www/librewolf/patches/patch-config_makefiles_rust_mk index 177aa8e43ee..ec6c03fbb5f \ 100644
--- a/www/librewolf/patches/patch-config_makefiles_rust_mk
+++ b/www/librewolf/patches/patch-config_makefiles_rust_mk
@@ -5,13 +5,13 @@ https://bugzilla.mozilla.org/show_bug.cgi?id=1640982 Index: config/makefiles/rust.mk --- config/makefiles/rust.mk.orig +++ config/makefiles/rust.mk
-@@ -91,7 +91,8 @@ ifeq (,$(RUST_SANCOV_FLAGS))
- # Never enable when coverage is enabled to work around \ https://github.com/rust-lang/rust/issues/90045.
- ifndef MOZ_CODE_COVERAGE
- ifeq (,$(findstring gkrust_gtest,$(RUST_LIBRARY_FILE)))
--cargo_rustc_flags += -Clto$(if $(filter full,$(MOZ_LTO_RUST_CROSS)),=fat)
+@@ -56,7 +56,8 @@ cargo_build_flags += $(MOZ_CARGO_BUILD_STD_ARGS)
+ cargo_rustc_flags = $(CARGO_RUSTCFLAGS)
+ # Enable link-time optimization for release builds.
+ ifdef RUST_LIBRARY_LTO
+-cargo_rustc_flags += -Clto +cargo_rustc_flags += -Clto=thin +export CARGO_PROFILE_RELEASE_LTO=thin endif
- # We need -Cembed-bitcode=yes for all crates when using -Clto.
- RUSTFLAGS += -Cembed-bitcode=yes
+ + ifdef CARGO_INCREMENTAL
diff --git a/www/librewolf/patches/patch-js_src_gc_Memory_cpp \
b/www/librewolf/patches/patch-js_src_gc_Memory_cpp index ed8ff73cccc..811d3308ad1 \ 100644
--- a/www/librewolf/patches/patch-js_src_gc_Memory_cpp
+++ b/www/librewolf/patches/patch-js_src_gc_Memory_cpp
@@ -3,7 +3,7 @@ https://hg.mozilla.org/mozilla-central/rev/b3a14f8efa23 Index: js/src/gc/Memory.cpp --- js/src/gc/Memory.cpp.orig +++ js/src/gc/Memory.cpp
-@@ -532,6 +532,30 @@ void MapStack(size_t stackSize) {
+@@ -534,6 +534,30 @@ void MapStack(size_t stackSize) { #endif } diff --git a/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp \
b/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp index \ 81bbe151b4f..badaabac523 100644
--- a/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp
+++ b/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp
@@ -3,7 +3,7 @@ https://hg.mozilla.org/mozilla-central/rev/b3a14f8efa23 Index: js/src/wasm/WasmStacks.cpp --- js/src/wasm/WasmStacks.cpp.orig +++ js/src/wasm/WasmStacks.cpp
-@@ -874,7 +874,7 @@ ContStackArena::~ContStackArena() {
+@@ -877,7 +877,7 @@ ContStackArena::~ContStackArena() { /* static */ UniqueContStackArena ContStackArena::create(ContStackAllocator* owner) { size_t arenaSize = owner->arenaSize();
diff --git a/www/librewolf/patches/patch-lw_policies_json \
b/www/librewolf/patches/patch-lw_policies_json index ba045f030c7..51f402bd2d8 100644
--- a/www/librewolf/patches/patch-lw_policies_json
+++ b/www/librewolf/patches/patch-lw_policies_json
@@ -3,63 +3,52 @@ perhaps send these to librewolf upstream as well Index: lw/policies.json --- lw/policies.json.orig +++ lw/policies.json
-@@ -1,26 +1,47 @@
- {
+@@ -2,26 +2,37 @@ "__COMMENT__ More Information": \ "https://github.com/mozilla/policy-templates/blob/master/README.md", "policies": {
-- "AIControls": {
-+
-+ "GenerativeAI": {
-+ "Enabled": false,
-+ "Chatbot": false,
-+ "LinkPreviews": false,
-+ "TabGroups": false,
-+ "Locked": true
-+ },
-+ "AIControls": {
+ "AIControls": { + "Default": {
-+ "Value": "blocked",
-+ "Locked": true
++ "Value": "blocked",
++ "Locked": true + }, "Translations": { - "Value": "available"
-+ "Value": "blocked",
-+ "Locked": false
++ "Value": "blocked",
++ "Locked": true }, "PDFAltText": { - "Value": "blocked"
-+ "Value": "blocked",
-+ "Locked": false
++ "Value": "blocked",
++ "Locked": true }, "SmartTabGroups": { - "Value": "blocked"
-+ "Value": "blocked",
-+ "Locked": true
++ "Value": "blocked",
++ "Locked": true }, "LinkPreviewKeyPoints": { - "Value": "blocked"
-+ "Value": "blocked",
-+ "Locked": true
++ "Value": "blocked",
++ "Locked": true }, "SidebarChatbot": { - "Value": "blocked"
-+ "Value": "blocked",
-+ "Locked": true
++ "Value": "blocked",
++ "Locked": true }, "SmartWindow": { - "Value": "blocked"
-+ "Value": "blocked",
-+ "Locked": true
++ "Value": "blocked",
++ "Locked":, true
+ },
+ "SpeechRecognition": {
+- "Value": "blocked"
++ "Value": "blocked",
++ "Locked": true }
-- },
-+
-+ },
-+
-+
+ }, "AppUpdateURL": "https://localhost",
- "DisableAppUpdate": true,
- "DisableDefaultBrowserAgent": true,
-@@ -73,6 +94,7 @@
+@@ -87,6 +98,7 @@ "EnablePrompting": true }, "NoDefaultBookmarks": true,
@@ -67,15 +56,15 @@ Index: lw/policies.json "OverridePostUpdatePage": "", "SkipTermsOfUse": true, "SupportMenu": {
-@@ -84,6 +106,11 @@
+@@ -98,6 +110,11 @@ "SkipOnboarding": true, "MoreFromMozilla": false, "FirefoxLabs": false + }, + "SearchEngines": {
-+ "Remove": [
-+ "Perplexity"
-+ ]
++ "Remove": [
++ "Perplexity"
++ ] } } }
diff --git a/www/librewolf/patches/patch-mozconfig \
b/www/librewolf/patches/patch-mozconfig index 327fa7440ef..6a5c64120f3 100644
--- a/www/librewolf/patches/patch-mozconfig
+++ b/www/librewolf/patches/patch-mozconfig
@@ -28,9 +28,9 @@ Index: mozconfig +# ac_add_options --disable-tests ac_add_options --disable-updater ac_add_options --disable-cargo-incremental
- ac_add_options --enable-hardening
-@@ -13,8 +20,9 @@ ac_add_options --enable-release
- ac_add_options --enable-rust-simd
+ ac_add_options --enable-update-channel=release
+@@ -15,8 +22,9 @@ ac_add_options --enable-rust-simd
+ ac_add_options --enable-proxy-bypass-protection # allow replacing malloc manually, will not affect regular systems # not compatible with ac_add_options --disable-jemalloc, which only works when \ preloading custom malloc -ac_add_options --enable-replace-malloc
@@ -41,7 +41,7 @@ Index: mozconfig ac_add_options --with-app-name=librewolf ac_add_options --with-branding=browser/branding/librewolf
-@@ -33,7 +41,19 @@ mk_add_options MOZ_TELEMETRY_REPORTING=0
+@@ -36,7 +44,19 @@ mk_add_options MOZ_TELEMETRY_REPORTING=0 export CFLAGS="-ftrivial-auto-var-init=zero -fwrapv -Wno-backend-plugin $CFLAGS" export CXXFLAGS="-ftrivial-auto-var-init=zero -fwrapv -Wno-backend-plugin \ $CXXFLAGS"
diff --git a/www/librewolf/patches/patch-third_party_llama_cpp_moz_build \
b/www/librewolf/patches/patch-third_party_llama_cpp_moz_build index \ 931d744474f..cb56ac879cd 100644
--- a/www/librewolf/patches/patch-third_party_llama_cpp_moz_build
+++ b/www/librewolf/patches/patch-third_party_llama_cpp_moz_build
@@ -17,7 +17,7 @@ Example error at compile time: Index: third_party/llama.cpp/moz.build --- third_party/llama.cpp/moz.build.orig +++ third_party/llama.cpp/moz.build
-@@ -135,6 +135,18 @@ if CONFIG["OS_TARGET"] == "Linux":
+@@ -174,6 +174,18 @@ if CONFIG["OS_TARGET"] == "Linux": OS_LIBS += [ "dl", ]
-- 2.55.0 ["OpenPGP_0x5C654067D383B1FF.asc" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 7

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: idea: remove lto on mozilla ports build
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 7:40:32
Message-ID: 379003b3-fc06-4801-8b9e-e6306b84b35b () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] hi just thought i'd run this by the list: I was looking at my librewolf port and also the firefox port. would it not make sense to patch out LTO on these? they already use a lot of memory during the build process and take a long time, especially if you're building this on a ten year old haswell as i do for librewolf. i haven't tested it yet to see what the size difference would be, or how much difference it makes on time, but what would people here think about me patching out LTO entirely on the builds for these? my rationale would be to make testing a bit easier, by reducing the build time. -- 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" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 8

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: gkrellm: not supposed to be setgid
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 8:48:46
Message-ID: atXZbsmO7VXFK6Np () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/18 23:18, Laurence Tratt wrote:
> Hello ports,
> > I just updated my packages and since last week something has changed for
> gkrellm which now terminates on start with:
> > /usr/local/bin/gkrellm: not supposed to be setgid, aborting
> > I must admit that I didn't know it's setgid but it really is:
> > $ ls -lh /usr/local/bin/gkrellm
> -rwxr-sr-x 1 root kmem 1.2M Oct 17 16:03 /usr/local/bin/gkrellm
> > Whether _all_ of gkrellm needs `kmem` levels of privilege or not, I don't
> know. But, presumably, either gkrellm will need fixing for (what I presume
> are) new security arrangements, or perhaps it can't be fixed?
> > > Laurie
> Given the changes in patches/patch-src_sysdeps_openbsd_c, as far as the
main gkrellm port goes, it seems to only be used for the TCP connection
info seen in sysdeps/bsd-net-open.c which is probably not a good enough
reason to keep it sgid kmem. I haven't looked into plugins though. I think we should remove the sgid bit and see if anyone complains. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 9

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: gkrellm: not supposed to be setgid
From: Claudio Jeker <cjeker () diehard ! n-r-g ! com>
Date: 2026-10-19 9:07:07
Message-ID: atXdu_OMyUR9W_74 () diehard ! n-r-g ! com
[Download RAW message or body] On Mon, Oct 19, 2026 at 09:48:46AM +0100, Stuart Henderson wrote:
> On 2026/10/18 23:18, Laurence Tratt wrote:
> > Hello ports,
> > > > I just updated my packages and since last week something has changed for
> > gkrellm which now terminates on start with:
> > > > /usr/local/bin/gkrellm: not supposed to be setgid, aborting
> > > > I must admit that I didn't know it's setgid but it really is:
> > > > $ ls -lh /usr/local/bin/gkrellm
> > -rwxr-sr-x 1 root kmem 1.2M Oct 17 16:03 /usr/local/bin/gkrellm
> > > > Whether _all_ of gkrellm needs `kmem` levels of privilege or not, I don't
> > know. But, presumably, either gkrellm will need fixing for (what I presume
> > are) new security arrangements, or perhaps it can't be fixed?
> > > > > > Laurie
> > > > Given the changes in patches/patch-src_sysdeps_openbsd_c, as far as the
> main gkrellm port goes, it seems to only be used for the TCP connection
> info seen in sysdeps/bsd-net-open.c which is probably not a good enough
> reason to keep it sgid kmem. There is no reason to use kmem for getting TCP connection info. It seems
that code is very old. > I haven't looked into plugins though. Almost everything in OpenBSD can be fetched through other ways (sysctl)
nowadays. Nothing in base uses that anymore. > I think we should remove the sgid bit and see if anyone complains. Most certainly. -- :wq Claudio [prev in list] [next in list] [prev in thread] [next in thread] 

Page 10

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 10:32:31
Message-ID: atXxv7GJlo-cY-zE () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/19 08:36, Leah Rowe wrote:
> I know ports tree is closed until after the 8.0 release. Just
> sending this patch anyway. I see that my 157 update patch did get
> merged anyway and the firefox 158 patch was merged on 13 october. https://marc.info/?l=openbsd-ports&m=179140008318699&w=2 Lock is so we get things stabilized to build the release; we generally
unlock once fast arch are done with package builds and builds on slower
archs have started. So we are now working on 8.0-current in the head
branch, and 8.0-stable in cvs OPENBSD_8_0. > i didn't check librewolf updates as much this month, precisely
> because openbsd is in release mode, otherwise i would have been more
> punctual with the update. no worries if this can't go in tree for
> 8.0 release as i can always backport it into -stable at a later
> date. landry, do you want to handle these? > From 1e5e3d7c8c56928ee4fcb8f988723d172424cb52 Mon Sep 17 00:00:00 2001
> From: Leah Rowe <[email protected]>
> Date: Sun, 18 Oct 2026 21:01:03 +0100
> Subject: [PATCH 1/1] www/librewolf: update to 158.0-1
> > GenerativeAI control no longer relevant upstream,
> as AIControls replaced it, which we also set already.
> > I've tightened up the policy considerably; translations
> and pdf alt text already blocked before in AIControls, and
> now locked. I do not want my work contributing politively to
> the scourge that is generative artificial intelligence. I'm not using librewolf, but fwiw, if I did, I'd find it annoying to
lose the local-only translations stuff (I'd much prefer that stuff
to run locally than send it to google or whoever). > Besides this, I've rebased patching and synced with the
> OpenBSD FireFox 158 port. Everything works.
> > Signed-off-by: Leah Rowe <[email protected]>
> ---
> www/librewolf/Makefile | 7 +-
> www/librewolf/distinfo | 8 +--
> .../patches/patch-config_makefiles_rust_mk | 14 ++--
> .../patches/patch-js_src_gc_Memory_cpp | 2 +-
> .../patches/patch-js_src_wasm_WasmStacks_cpp | 2 +-
> www/librewolf/patches/patch-lw_policies_json | 65 ++++++++-----------
> www/librewolf/patches/patch-mozconfig | 8 +--
> .../patch-third_party_llama_cpp_moz_build | 2 +-
> 8 files changed, 48 insertions(+), 60 deletions(-)
> > diff --git a/www/librewolf/Makefile b/www/librewolf/Makefile
> index e59e4944b88..fe44267c609 100644
> --- a/www/librewolf/Makefile
> +++ b/www/librewolf/Makefile
> @@ -13,9 +13,8 @@ ONLY_FOR_ARCHS =	amd64 aarch64 riscv64
> > # If upstream adds revision number -x, it will become plx in OpenBSD, e.g.
> # librewolf-149.0.2-2 (upstream) becomes librewolf-149.0.2pl2 (patch level 2)
> -MOZILLA_DIST_VERSION =	157.0-1
> +MOZILLA_DIST_VERSION =	158.0-1
> MOZILLA_VERSION =	${MOZILLA_DIST_VERSION:C/-([0-9]+)$/pl\1/}
> -REVISION = 0
> > MOZILLA_PROJECT =	librewolf
> MOZILLA_CODENAME =	browser
> @@ -23,13 +22,13 @@ MAINTAINER = Leah Rowe <[email protected]>
> > # LibreWolf doesn't provide PGO data, but we use the data
> # provided by FireFox releases, re-using the OpenBSD distfile
> -MOZILLA_PROFDATA_TASKID =	BnF3vh8WT4OW53JJ0ow3mQ
> +MOZILLA_PROFDATA_TASKID =	Yy7PLAWLTQ6Ru0Iqs0_iRQ
> FFVERSION = ${MOZILLA_DIST_VERSION:C/-([0-9]+)$//}
> FFDIST = firefox-${FFVERSION}.source
> DISTFILES.profdata = ${FFDIST}-profdata.tar.xz{profdata.tar.xz}
> > HOMEPAGE =	https://librewolf.net/
> -SO_VERSION =	6.0
> +SO_VERSION =	7.0
> # Bump minor ver if shlibs deleted in components dir to avoid pkg_add -r issues
> MOZILLA_LIBS =	mozavcodec mozavutil mozgtk mozinference mozwayland xul \
> clearkey gkcodecs lgpllibs mozsqlite3
> diff --git a/www/librewolf/distinfo b/www/librewolf/distinfo
> index 0fcbdf9217b..f3995170a8b 100644
> --- a/www/librewolf/distinfo
> +++ b/www/librewolf/distinfo
> @@ -1,4 +1,4 @@
> -SHA256 (mozilla/firefox-157.0.source-profdata.tar.xz) = \
> lwkzOiqkOrreLbO+tEnGwySn0Mb2+W4bNQBL39D/7/c=
> -SHA256 (mozilla/librewolf-157.0-1.source.tar.gz) = \
> vqPMfFfz+4ko1YOgYDsPQBMLAvZi4DJ0Y0WlHg9V/7M=
> -SIZE (mozilla/firefox-157.0.source-profdata.tar.xz) = 18900828
> -SIZE (mozilla/librewolf-157.0-1.source.tar.gz) = 1178691023
> +SHA256 (mozilla/firefox-158.0.source-profdata.tar.xz) = \
> Jd8si/gEYPCqHefjsMFmOyjt438g5pGAGiYqMhl0vuQ= +SHA256 \
> (mozilla/librewolf-158.0-1.source.tar.gz) = \
> 6iQk+0wCkWwMUxIQ8d2LRg6FB08tjKBSnUlVPTbdE8A= +SIZE \
> (mozilla/firefox-158.0.source-profdata.tar.xz) = 19008760 +SIZE \
> (mozilla/librewolf-158.0-1.source.tar.gz) = 1181473241
> diff --git a/www/librewolf/patches/patch-config_makefiles_rust_mk \
> b/www/librewolf/patches/patch-config_makefiles_rust_mk index \
> 177aa8e43ee..ec6c03fbb5f 100644
> --- a/www/librewolf/patches/patch-config_makefiles_rust_mk
> +++ b/www/librewolf/patches/patch-config_makefiles_rust_mk
> @@ -5,13 +5,13 @@ https://bugzilla.mozilla.org/show_bug.cgi?id=1640982
> Index: config/makefiles/rust.mk
> --- config/makefiles/rust.mk.orig
> +++ config/makefiles/rust.mk
> -@@ -91,7 +91,8 @@ ifeq (,$(RUST_SANCOV_FLAGS))
> - # Never enable when coverage is enabled to work around \
> https://github.com/rust-lang/rust/issues/90045.
> - ifndef MOZ_CODE_COVERAGE
> - ifeq (,$(findstring gkrust_gtest,$(RUST_LIBRARY_FILE)))
> --cargo_rustc_flags += -Clto$(if $(filter full,$(MOZ_LTO_RUST_CROSS)),=fat)
> +@@ -56,7 +56,8 @@ cargo_build_flags += $(MOZ_CARGO_BUILD_STD_ARGS)
> + cargo_rustc_flags = $(CARGO_RUSTCFLAGS)
> + # Enable link-time optimization for release builds.
> + ifdef RUST_LIBRARY_LTO
> +-cargo_rustc_flags += -Clto
> +cargo_rustc_flags += -Clto=thin
> +export CARGO_PROFILE_RELEASE_LTO=thin
> endif
> - # We need -Cembed-bitcode=yes for all crates when using -Clto.
> - RUSTFLAGS += -Cembed-bitcode=yes
> + > + ifdef CARGO_INCREMENTAL
> diff --git a/www/librewolf/patches/patch-js_src_gc_Memory_cpp \
> b/www/librewolf/patches/patch-js_src_gc_Memory_cpp index ed8ff73cccc..811d3308ad1 \
> 100644
> --- a/www/librewolf/patches/patch-js_src_gc_Memory_cpp
> +++ b/www/librewolf/patches/patch-js_src_gc_Memory_cpp
> @@ -3,7 +3,7 @@ https://hg.mozilla.org/mozilla-central/rev/b3a14f8efa23
> Index: js/src/gc/Memory.cpp
> --- js/src/gc/Memory.cpp.orig
> +++ js/src/gc/Memory.cpp
> -@@ -532,6 +532,30 @@ void MapStack(size_t stackSize) {
> +@@ -534,6 +534,30 @@ void MapStack(size_t stackSize) {
> #endif
> }
> > diff --git a/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp \
> b/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp index \
> 81bbe151b4f..badaabac523 100644
> --- a/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp
> +++ b/www/librewolf/patches/patch-js_src_wasm_WasmStacks_cpp
> @@ -3,7 +3,7 @@ https://hg.mozilla.org/mozilla-central/rev/b3a14f8efa23
> Index: js/src/wasm/WasmStacks.cpp
> --- js/src/wasm/WasmStacks.cpp.orig
> +++ js/src/wasm/WasmStacks.cpp
> -@@ -874,7 +874,7 @@ ContStackArena::~ContStackArena() {
> +@@ -877,7 +877,7 @@ ContStackArena::~ContStackArena() {
> /* static */
> UniqueContStackArena ContStackArena::create(ContStackAllocator* owner) {
> size_t arenaSize = owner->arenaSize();
> diff --git a/www/librewolf/patches/patch-lw_policies_json \
> b/www/librewolf/patches/patch-lw_policies_json index ba045f030c7..51f402bd2d8 \
> 100644
> --- a/www/librewolf/patches/patch-lw_policies_json
> +++ b/www/librewolf/patches/patch-lw_policies_json
> @@ -3,63 +3,52 @@ perhaps send these to librewolf upstream as well
> Index: lw/policies.json
> --- lw/policies.json.orig
> +++ lw/policies.json
> -@@ -1,26 +1,47 @@
> - {
> +@@ -2,26 +2,37 @@
> "__COMMENT__ More Information": \
> "https://github.com/mozilla/policy-templates/blob/master/README.md", "policies": {
> -- "AIControls": {
> -+
> -+ "GenerativeAI": {
> -+ "Enabled": false,
> -+ "Chatbot": false,
> -+ "LinkPreviews": false,
> -+ "TabGroups": false,
> -+ "Locked": true
> -+ },
> -+ "AIControls": {
> + "AIControls": {
> + "Default": {
> -+ "Value": "blocked",
> -+ "Locked": true
> ++ "Value": "blocked",
> ++ "Locked": true
> + },
> "Translations": {
> - "Value": "available"
> -+ "Value": "blocked",
> -+ "Locked": false
> ++ "Value": "blocked",
> ++ "Locked": true
> },
> "PDFAltText": {
> - "Value": "blocked"
> -+ "Value": "blocked",
> -+ "Locked": false
> ++ "Value": "blocked",
> ++ "Locked": true
> },
> "SmartTabGroups": {
> - "Value": "blocked"
> -+ "Value": "blocked",
> -+ "Locked": true
> ++ "Value": "blocked",
> ++ "Locked": true
> },
> "LinkPreviewKeyPoints": {
> - "Value": "blocked"
> -+ "Value": "blocked",
> -+ "Locked": true
> ++ "Value": "blocked",
> ++ "Locked": true
> },
> "SidebarChatbot": {
> - "Value": "blocked"
> -+ "Value": "blocked",
> -+ "Locked": true
> ++ "Value": "blocked",
> ++ "Locked": true
> },
> "SmartWindow": {
> - "Value": "blocked"
> -+ "Value": "blocked",
> -+ "Locked": true
> ++ "Value": "blocked",
> ++ "Locked":, true
> + },
> + "SpeechRecognition": {
> +- "Value": "blocked"
> ++ "Value": "blocked",
> ++ "Locked": true
> }
> -- },
> -+
> -+ },
> -+
> -+
> + },
> "AppUpdateURL": "https://localhost",
> - "DisableAppUpdate": true,
> - "DisableDefaultBrowserAgent": true,
> -@@ -73,6 +94,7 @@
> +@@ -87,6 +98,7 @@
> "EnablePrompting": true
> },
> "NoDefaultBookmarks": true,
> @@ -67,15 +56,15 @@ Index: lw/policies.json
> "OverridePostUpdatePage": "",
> "SkipTermsOfUse": true,
> "SupportMenu": {
> -@@ -84,6 +106,11 @@
> +@@ -98,6 +110,11 @@
> "SkipOnboarding": true,
> "MoreFromMozilla": false,
> "FirefoxLabs": false
> + },
> + "SearchEngines": {
> -+ "Remove": [
> -+ "Perplexity"
> -+ ]
> ++ "Remove": [
> ++ "Perplexity"
> ++ ]
> }
> }
> }
> diff --git a/www/librewolf/patches/patch-mozconfig \
> b/www/librewolf/patches/patch-mozconfig index 327fa7440ef..6a5c64120f3 100644
> --- a/www/librewolf/patches/patch-mozconfig
> +++ b/www/librewolf/patches/patch-mozconfig
> @@ -28,9 +28,9 @@ Index: mozconfig
> +# ac_add_options --disable-tests
> ac_add_options --disable-updater
> ac_add_options --disable-cargo-incremental
> - ac_add_options --enable-hardening
> -@@ -13,8 +20,9 @@ ac_add_options --enable-release
> - ac_add_options --enable-rust-simd
> + ac_add_options --enable-update-channel=release
> +@@ -15,8 +22,9 @@ ac_add_options --enable-rust-simd
> + ac_add_options --enable-proxy-bypass-protection
> # allow replacing malloc manually, will not affect regular systems
> # not compatible with ac_add_options --disable-jemalloc, which only works when \
> preloading custom malloc
> -ac_add_options --enable-replace-malloc
> @@ -41,7 +41,7 @@ Index: mozconfig
> > ac_add_options --with-app-name=librewolf
> ac_add_options --with-branding=browser/branding/librewolf
> -@@ -33,7 +41,19 @@ mk_add_options MOZ_TELEMETRY_REPORTING=0
> +@@ -36,7 +44,19 @@ mk_add_options MOZ_TELEMETRY_REPORTING=0
> > export CFLAGS="-ftrivial-auto-var-init=zero -fwrapv -Wno-backend-plugin $CFLAGS"
> export CXXFLAGS="-ftrivial-auto-var-init=zero -fwrapv -Wno-backend-plugin \
> $CXXFLAGS"
> diff --git a/www/librewolf/patches/patch-third_party_llama_cpp_moz_build \
> b/www/librewolf/patches/patch-third_party_llama_cpp_moz_build index \
> 931d744474f..cb56ac879cd 100644
> --- a/www/librewolf/patches/patch-third_party_llama_cpp_moz_build
> +++ b/www/librewolf/patches/patch-third_party_llama_cpp_moz_build
> @@ -17,7 +17,7 @@ Example error at compile time:
> Index: third_party/llama.cpp/moz.build
> --- third_party/llama.cpp/moz.build.orig
> +++ third_party/llama.cpp/moz.build
> -@@ -135,6 +135,18 @@ if CONFIG["OS_TARGET"] == "Linux":
> +@@ -174,6 +174,18 @@ if CONFIG["OS_TARGET"] == "Linux":
> OS_LIBS += [
> "dl",
> ]
> -- > 2.55.0
> [prev in list] [next in list] [prev in thread] [next in thread] 

Page 11

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Martijn van Duren <openbsd+ports () list ! imperialat ! at>
Date: 2026-10-19 10:38:54
Message-ID: 76e642c9-9e5f-4468-a625-677283c10c43 () list ! imperialat ! at
[Download RAW message or body] So far I've managed to start up and load saves from:
- Timberborn
- Cult of the Lamb
- Frostpunk
- ManorLords
- Peglin (Sound seems to lag behind gameplay for ~1s)
- Whiskerwood Failed to start (without investigating why):
- Cyberpunk2077
- Vampire the Masquerade Bloodlines 2 Note that for some of these games I also had to do some tweaking under Linux, and I'm using the same install under a shared ext2fs home directory, so not sure anymore what tweaks are needed for which game, so your mileage may vary, but at least these _can_ be spun up. I'm happy. OK martijn@ fwiw On 10/19/26 12:08 AM, Thomas Frohwein wrote:
> Hello,
> > In what might the most surprising port proposal of the year, I'm proud
> to present a new port for wine. This has been a collective effort,
> after some of the prodding at the %gs/gsbase question (see thread [1]).
> The gates swung open with Andrii's software solution to the %gs issue -
> explanation to me: "can't set gsbase, so we are emulating %gs prefix on
> commands". Overall, the heavy lifting was done by Andrii and Fabien - kudos.
> > Turns out there is a ground-swell with interest in wine [2], different
> than even 5-10 years ago because a lot of Windows software has since
> moved to being 64bit.
> > We have since tested several dozens of 64-bit Windows software, mostly
> successfully. See screenshots at [3][4][5], livestream recordings at
> [6] for example. Even the Remaster of The Witcher 3 which released just
> last month runs, and runs well (requires adding in vkd3d-proton; see
> README; livestream at [7] which looks less fluent than it is due to
> the on-system recording with ffmpeg).
> > Biggest limitation is that WoW64 doesn't work, so 32bit Windows
> software is still a no-op. You can check .exe/.dll easily with file(1)
> - if it says something like "MS-DOS executable PE for MS Windows (GUI)
> Intel 80386 32-bit", then it's 32-bit.
> > The builtin-tests are disabled for now. Enabling them is pretty
> involved as they need access to the X server and multiple tests still
> hang, however that was not observed in the real life testing with a
> good number of games. This is still being worked on.
> > For those who wish to test it, I suggest Notepad++ as a small, fairly
> straightforward piece of 64-bit Windows software [8]. Note that this
> is (as always) run-at-your-own-risk software (see [9]). Consider
> setting up a separate, non-privileged user for this until we can
> explore if some fencing in, potentially with unveil(2) can be done.
> > Appreciate testing of the port draft and contributions by: brynet@,
> bentley@, pertho (on irc.libera.chat #openbsd-gaming), vl_ms
> > ok?
> > [1] https://marc.info/?l=openbsd-tech&m=179067466617674&w=2
> [2] https://marc.info/?l=openbsd-tech&m=179070170845285&w=2
> [3]
> https://old.reddit.com/r/openbsd_gaming/comments/1x4e7fi/some_samples_from_wip_wine_port/
> [4]
> https://old.reddit.com/r/openbsd_gaming/comments/1x5yxpu/more_wineonopenbsd_screenshots/
> [5]
> https://old.reddit.com/r/openbsd_gaming/comments/1x7z2ry/even_more_wineonopenbsd_proof/
> [6] https://video.gamerstavern.online/w/8tjjFRDtGJQZwxfE4ojVoC
> [7] https://video.gamerstavern.online/w/oZcTRKL5JMiU4M4FqGKcNH
> [8]
> https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.8.1/npp.8.9.8.1.portable.x64.zip
> [9]
> https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#is-wine-malware-compatible [prev in list] [next in list] [prev in thread] [next in thread] 

Page 12

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 10:43:54
Message-ID: atX0arxqE8LJJG72 () symphytum ! spacehopper ! org
[Download RAW message or body] 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. Is there some hope to get some of the big set of patches merged
upstream? Some #ifdef __OpenBSD__ patches look like they could use a check for
the specific thing (at least xattrs, not sure if there are others) and
conditioning on that instead of OpenBSD/not. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 13

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 10:58:36
Message-ID: atX33Is-8Q9rdc9K () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/19 11:43, 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. (If it's not automatic at build-time, then BUILD_DEPENDS needs to be on
the exact version..) > Is there some hope to get some of the big set of patches merged
> upstream?
> > Some #ifdef __OpenBSD__ patches look like they could use a check for
> the specific thing (at least xattrs, not sure if there are others) and
> conditioning on that instead of OpenBSD/not.
> [prev in list] [next in list] [prev in thread] [next in thread] 

Page 14

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: [IMPROVEMENT] OpenBSD compatibility and safety fixes for devel/codex
From: Kirill A. Korinsky <kirill () korins ! ky>
Date: 2026-10-19 11:05:08
Message-ID: 87ik2yosrf.wl-kirill () korins ! ky
[Download RAW message or body] On Mon, 19 Oct 2026 04:36:00 +0200,
David Uhden Collado <[email protected]> wrote:
> > I would appreciate review, particularly of the sandbox restrictions
> and process execution changes.
> When start sending one logical patch at the time. Not dozen of them. -- wbr, Kirill [prev in list] [next in list] [prev in thread] [next in thread] 

Page 15

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 12:28:44
Message-ID: 0b9975c6-6f8d-4d83-9cf9-dc5a6f46a91d () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] Am 19.10.26 um 11:32 schrieb Stuart Henderson: > https://marc.info/?l=openbsd-ports&m=179140008318699&w=2 > > Lock is so we get things stabilized to build the release; we generally > unlock once fast arch are done with package builds and builds on slower > archs have started. So we are now working on 8.0-current in the head > branch, and 8.0-stable in cvs OPENBSD_8_0. understood. as i said, it's no problem if this doesn't go in -release, i can backport to -stable later on. firefox also gets backported to -stable for updates, alongside -current. i'll just sync with ff updates like i do in -current. i do need to set up a -stable openbsd machine when 8.0 comes out. i normally only use -current in the past > I'm not using librewolf, but fwiw, if I did, I'd find it annoying to > lose the local-only translations stuff (I'd much prefer that stuff > to run locally than send it to google or whoever). > > i don't think translations/pdfalttext are disabled outright, i think it's just the AI bits. my port turns off AI entirely, in librewolf. the firefox port also disabled AI, based on config provided by the justthebrowser project. i do the same in librewolf. i don't think we should be putting strain on electricity and water needlessly in the browser. i think it's better than we don't become part of the problem. all the mainstream projects are hyping up AI, but this is openbsd. we run our own race. of course, the ports system is open to anyone to modify. users can just re-build librewolf if they wish to have this turned on by default. i should also say: actually building from source is not required, if the user wants to change this. they can use the binary package, and then modify their own local installation of the policy. this is just the policy that goes in /usr/local, which the user can modify. the actual binary still has these features available, unmodified except by virtue of the policy, which the browser interprets on startup. modifying the policy can also be done to e.g. enable wivedine/eme. ["OpenPGP_0x5C654067D383B1FF.asc" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 16

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 12:50:05
Message-ID: atYR_WG20wkPqOdY () symphytum ! spacehopper ! org
[Download RAW message or body] 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. great, so send translations to google to have them to use even more
electricity and water needlessly instead, so they can do the translation
plus feed into whatever they feed it into for profiling etc? > actually building from source is not required, if the user wants to change
> this. they can use the binary package, and then modify their own local
> installation of the policy. this is just the policy that goes in /usr/local,
> which the user can modify. the actual binary still has these features
> available, unmodified except by virtue of the policy, which the browser
> interprets on startup. that is a complete pain for package updates. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 17

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Neth Iafin <NethIafin-obsd () proton ! me>
Date: 2026-10-19 12:51:09
Message-ID: l2eFinPlTmuUP_xmiNBd7WTsLu-qSfkjMGB4WrY5xxJ4Dxct65zgtF-eMBht9dqZ2sl_QkFsTthWDC8Ewuqcp8WWCcOsBR7NG41J6kokuaY= () proton ! me
[Download RAW message or body] > Is there some hope to get some of the big set of patches merged
> upstream?
>
> Some #ifdef __OpenBSD__ patches look like they could use a check for
> the specific thing (at least xattrs, not sure if there are others) and
> conditioning on that instead of OpenBSD/not. I doubt much will be merged upstream. Many updates we have can technically =
run on other OSes (%gs stubs won't be built on Linux because %gs is correct=
ly set, SIGUSR1 will work but less optimally, etc). However I picked an app=
roach where everything that is done for OpenBSD is just marked as OpenBSD o=
nly. I did that purely to simplify my life while I was working on it and cl=
early mark the changes. When I was talking to Wine maintainers a month ago, they were hesitant to a=
ccept even patching Wine so it compiles for OpenBSD, mostly because it's an=
other OS they will have to support and keep operational, while the %gs stub= fix is something they definitely cannot take upstream. They are very hesit=
ant to take anything that is changing the "emulated" application code. The xattr change was a recent addition from Fabien, I suspect mostly to sup=
port the Mono installer that creates a lot of symlinks for different framew=
ork versions. I guess it can be taken upstream with `#if !defined(HAVE_SYS_=
XATTR_H) && !defined(HAVE_SYS_EXTATTR_H)`, among other places (server/fd.c)= that need this change. In short - merging upstream is not a current goal, at least for me. There a=
re still some stability issues, especially with very demanding 3d games. I'=
ll see where we stand in a few months. > 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. I'll leave the details to Fabien/Thomas, but nothing is actually generated.= The llvm package strips out clang's freestanding headers (float.h inttypes=
.h iso646.h limits.h stdarg.h stdbool.h stddef.h stdint.h) and we need them= for Windows builds. They are copied unchanged from clang/lib/Headers at th=
e llvmorg tag that matches MODCLANG_VERSION, so it can be automated. It doe=
s mean that we have to download ~150 MB distfile for those 8 header files t=
hough. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 18

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 12:58:22
Message-ID: atYUbrlaAsfYMX4E () symphytum ! spacehopper ! org
[Download RAW message or body] 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) [prev in list] [next in list] [prev in thread] [next in thread] 

Page 19

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Bryan Steele <brynet () gmail ! com>
Date: 2026-10-19 13:00:36
Message-ID: atYUdHhKTftMxiuP () gmail ! com
[Download RAW message or body] 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. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 20

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 13:03:48
Message-ID: atYVNHTOdAVG2Vv2 () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/19 12:51, Neth Iafin wrote:
> > Is there some hope to get some of the big set of patches merged
> > upstream?
> > > > Some #ifdef __OpenBSD__ patches look like they could use a check for
> > the specific thing (at least xattrs, not sure if there are others) and
> > conditioning on that instead of OpenBSD/not.
> > I doubt much will be merged upstream. Many updates we have can technically run on \
> other OSes (%gs stubs won't be built on Linux because %gs is correctly set, SIGUSR1 \
> will work but less optimally, etc). However I picked an approach where everything \
> that is done for OpenBSD is just marked as OpenBSD only. I did that purely to \
> simplify my life while I was working on it and clearly mark the changes. > When I was talking to Wine maintainers a month ago, they were hesitant to accept \
> even patching Wine so it compiles for OpenBSD, mostly because it's another OS they \
> will have to support and keep operational, while the %gs stub fix is something they \
> definitely cannot take upstream. They are very hesitant to take anything that is \
> changing the "emulated" application code. > The xattr change was a recent addition from Fabien, I suspect mostly to support the \
> Mono installer that creates a lot of symlinks for different framework versions. I \
> guess it can be taken upstream with `#if !defined(HAVE_SYS_XATTR_H) && \
> !defined(HAVE_SYS_EXTATTR_H)`, among other places (server/fd.c) that need this \
> change. even if it's just that, it would help. > In short - merging upstream is not a current goal, at least for me. There are still \
> some stability issues, especially with very demanding 3d games. I'll see where we \
> stand in a few months. > > 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.
> > I'll leave the details to Fabien/Thomas, but nothing is actually generated. The \
> llvm package strips out clang's freestanding headers (float.h inttypes.h iso646.h \
> limits.h stdarg.h stdbool.h stddef.h stdint.h) and we need them for Windows builds. \
> They are copied unchanged from clang/lib/Headers at the llvmorg tag that matches \
> MODCLANG_VERSION, so it can be automated. It does mean that we have to download \
> ~150 MB distfile for those 8 header files though. The alternative is to have the port break every time clang is updated
(and annoy bulk builders). As far as bulk builds are done (which will be, by far, the most frequent
builds of this in normal circumstances) clang is already downloaded so
that clang can be built in the first place so no extra download there. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 21

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 13:21:14
Message-ID: 2fb25c48-6694-4552-8fc1-7c3d16364601 () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] Am 19.10.26 um 13:50 schrieb Stuart Henderson: > great, so send translations to google to have them to use even more > electricity and water needlessly instead, so they can do the translation > plus feed into whatever they feed it into for profiling etc? just turn it back on. again, i don't think translations are disabled, just AI-based translations. you're not going to be running AI locally in lw/ff, unless i'm mistaken? i think they just use external chatbots and if so it's the same argument. but you can turn it back on. i think it's /usr/local/lib/librewolf or something. just buzz around and you'll find it. modify the policy file in there on your install, and then restart the browser. then you have whatever you want. > >> actually building from source is not required, if the user wants to change >> this. they can use the binary package, and then modify their own local >> installation of the policy. this is just the policy that goes in /usr/local, >> which the user can modify. the actual binary still has these features >> available, unmodified except by virtue of the policy, which the browser >> interprets on startup. > that is a complete pain for package updates. it's the same behaviour that the firefox port uses. i maintain sync with the ff port. also, use of language services isn't required. you can use a human interpreter if necessary, or learn the language yourself. i started learning german last year. but yeah, just modify it. or idk. i mean, i'm in change of stewarding this port, but if the other peeps in puffyos want it, they can turn stuff back on. we're all team players right? -- 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" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 22

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 13:24:21
Message-ID: 047c4aa4-20c4-47d6-a762-751f018a87ef () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] 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 ["OpenPGP_0x5C654067D383B1FF.asc" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 23

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Neth Iafin <NethIafin-obsd () proton ! me>
Date: 2026-10-19 13:42:21
Message-ID: rKVWIcnRh3Bc8r3gWsksdv8_zOgwjYE0BfvltuCFmUNkWhe4g1UZhj0cnFubT8CXR0_V_YJV5TffUL7yazRWhd_vT1uSHKqLC23qhau1N6o= () proton ! me
[Download RAW message or body] Hello, Currently we have the following issues we are looking into:
1. Fixing sound, hopefully by dropping pulseaudio and working directly with= sndiod.
2. Some crashes on exit that we are still observing.
3. Hopefully simplifying the port's makefile (I am a complete newbie here, =
so I will defer to Fabien's/Thomas's opinion)
4. Certain high-end games failing (GPU detect issues?)
5. Adding unveil and maybe even pledge.
6. Checking if the %gs stub rewriter can be abused by a crafted %gs-prefixe=
d instruction that can trick it into generating malicious code.
7. Other FIXMEs on code that does not expect OpenBSD, yet does not cause cr=
ashes on what we were testing. Additionally we are looking into:
1. Filling the list of games that can be run on this port.
2. Finding potential issues on a game-by-game basis and how to fix them. Fo=
r example some of them are fixed by forcing Vulkan (via DXVK or wined3d's V=
ulkan renderer - decided per game too).
3. Contacting some online game developers to check if this port does not tr=
igger their automated ban system. This is only for games that already work =
on Wine on Linux. It's obvious that if a game has anti-cheat, there is not =
much we can do. However games like Path of Exile and Eve Online use interna=
l detection logic (for the macro abuse detection) and the games are server-=
authoritative, so the client never receives hidden information. Having the =
port publicly available will hopefully simplify talking to them. Aspirationally we might look into 32 bit by trying to investigate what FEX =
does along with making our own wow64cpu.dll implementation, but I'd rather =
spend time on items above. Also the code was not reviewed by the Wine team, and older code was not rev=
iewed by anyone either, so if you have questions regarding code quality, or= some suggestions - they are very welcome. I want to thank Fabien, Bryan and Thomas for making this project possible. =
Working with a port Makefile is something completely new for me and I don't= have enough different systems to catch every single problem that a project= of Wine's size can cause. Also it is pretty amazing to see that Wine itsel=
f works quite well as soon as we fixed some blockers. Separate thanks to Fa=
bien again for fixing major issues and helping with the recent code reviews=
. Keep posting what works and what doesn't, we will try to chew through the i=
ssues whenever we have time. Do remember that Wine isn't a sandbox (at least at the moment), so please b=
e cautious with what you run, as Windows apps will have full access to ever=
ything the running user has access to. Also avoid online games that might b=
an you for using an unsupported OS (see item 3 in the second list). We will= add those to the list of supported games if/when developers confirm it is =
safe. [prev in list] [next in list] [prev in thread] [next in thread] 

Page 24

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: emulators/wine
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 13:44:11
Message-ID: atYeqzDlFlEPGCbX () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/19 12:51, Neth Iafin wrote:
> > Is there some hope to get some of the big set of patches merged
> > upstream?
> > > > Some #ifdef __OpenBSD__ patches look like they could use a check for
> > the specific thing (at least xattrs, not sure if there are others) and
> > conditioning on that instead of OpenBSD/not.
> > I doubt much will be merged upstream. Many updates we have can technically run on \
> other OSes (%gs stubs won't be built on Linux because %gs is correctly set, SIGUSR1 \
> will work but less optimally, etc). However I picked an approach where everything \
> that is done for OpenBSD is just marked as OpenBSD only. I did that purely to \
> simplify my life while I was working on it and clearly mark the changes. > When I was talking to Wine maintainers a month ago, they were hesitant to accept \
> even patching Wine so it compiles for OpenBSD, mostly because it's another OS they \
> will have to support and keep operational, while the %gs stub fix is something they \
> definitely cannot take upstream. They are very hesitant to take anything that is \
> changing the "emulated" application code. > The xattr change was a recent addition from Fabien, I suspect mostly to support the \
> Mono installer that creates a lot of symlinks for different framework versions. I \
> guess it can be taken upstream with `#if !defined(HAVE_SYS_XATTR_H) && \
> !defined(HAVE_SYS_EXTATTR_H)`, among other places (server/fd.c) that need this \
> change. > In short - merging upstream is not a current goal, at least for me. There are still \
> some stability issues, especially with very demanding 3d games. I'll see where we \
> stand in a few months. > > 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.
> > I'll leave the details to Fabien/Thomas, but nothing is actually generated. The \
> llvm package strips out clang's freestanding headers (float.h inttypes.h iso646.h \
> limits.h stdarg.h stdbool.h stddef.h stdint.h) and we need them for Windows builds. \
> They are copied unchanged from clang/lib/Headers at the llvmorg tag that matches \
> MODCLANG_VERSION, so it can be automated. It does mean that we have to download \
> ~150 MB distfile for those 8 header files though. remember that devel/llvm is not set in stone. here are two patches, for wine, and for devel/llvm, that make this
significantly less annoying to deal with. my build is still running but
I think it should work. another way to do it: rather than completely removing the stripped-out
headers, devel/llvm could install them under a different dir and
include in packages. --- Makefile.orig	Mon Oct 19 14:18:12 2026
+++ Makefile	Mon Oct 19 14:43:16 2026
@@ -27,19 +27,14 @@ WANTLIB += lib/inotify/inotify lib/libpcap/pcap # loaded with dlopen() WANTLIB += SDL2 cups dbus-1 gnutls netapi vulkan xkbregistry -# keep this in sync with MODCLANG_VERSION
-# source for updates/new releases: https://thfr.gothub.org/wine-clang-pe-headers
-CLANG_PE_HEADERS = 22.1.8
-DISTFILES.clang-pe-headers =	wine-clang-pe-headers-${CLANG_PE_HEADERS}.tar.gz
-SITES.clang-pe-headers =	https://thfr.info/distfiles/
- SITES = https://dl.winehq.org/wine/source/11.x/ EXTRACT_SUFX = .tar.xz MODULES = lang/clang BUILD_DEPENDS = devel/bison \
- devel/nasm
+ devel/nasm \
+ ${_MODCLANG_BUILD_DEPENDS},headerextract:patch RUN_DEPENDS = multimedia/gstreamer1/libav \ multimedia/gstreamer1/plugins-bad \ multimedia/gstreamer1/plugins-good \
@@ -156,9 +151,9 @@ SUBST_VARS+= CLANG_PE_RESOURCE MODCLANG_VERSION pre-configure: ${INSTALL_DATA_DIR} ${CLANG_PE_RESOURCE}/include
-	cp -R ${CLANG_RESOURCE}/include/. ${CLANG_PE_RESOURCE}/include/
-	cp ${WRKDIR}/wine-clang-pe-headers-${CLANG_PE_HEADERS}/*.h \
+	cp ${WRKDIR}/devel/llvm/*/*/clang/lib/Headers/*.h \ ${CLANG_PE_RESOURCE}/include/
+	cp -R ${CLANG_RESOURCE}/include/. ${CLANG_PE_RESOURCE}/include/ ln -sfh ${CLANG_RESOURCE}/lib ${CLANG_PE_RESOURCE}/lib ${SUBST_PROGRAM} ${FILESDIR}/clang-pe ${WRKDIR}/bin/clang-pe Index: Makefile.inc
===================================================================
RCS file: /cvs/ports/devel/llvm/Makefile.inc,v
diff -u -p -r1.35 Makefile.inc
--- Makefile.inc	20 Sep 2026 14:25:09 -0000	1.35
+++ Makefile.inc	19 Oct 2026 13:35:06 -0000
@@ -97,9 +97,19 @@ COMPILER =	base-clang ports-gcc MODULES +=	devel/cmake +# internal use for emulators/wine; reduce extraction size
+FLAVORS=	headerextract
+FLAVOR?=
+
+.if ${FLAVOR} == headerextract
+PATCH_LIST=
+EXTRACT_CASES += llvm*.tar.xz) \
+ xz -T${MAKE_JOBS} -d <${FULLDISTDIR}/$$archive | ${TAR} -xf - -- \
*/clang/lib/Headers;; +.else BUILD_DEPENDS +=	devel/swig \ textproc/py-sphinx \ textproc/py-recommonmark
+.endif CONFIGURE_STYLE +=	cmake CONFIGURE_ARGS +=	\
@@ -151,7 +161,8 @@ CXXFLAGS-powerpc =	-fno-ret-protector CXXFLAGS-mips64 +=	-mxgot CXXFLAGS-mips64el +=	-mxgot -CXXFLAGS += ${CXXFLAGS-${MACHINE_ARCH}}
+CXXFLAGS += ${CXXFLAGS-${MACHINE_ARCH}} \
+ -D_LIBCPP_USE_LOWER_DEQUE_BLOCK_SIZE ALL_TARGET = all docs-llvm-man docs-clang-man [prev in list] [next in list] [prev in thread] [next in thread] 

Page 25

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Leah Rowe <info () minifree ! org>
Date: 2026-10-19 13:55:54
Message-ID: 0d6da8ad-ebb4-4bbd-80db-dfa5ad0f961c () minifree ! org
[Download RAW message or body] [Attachment #2 (multipart/mixed)] [Attachment #4 (multipart/mixed)] [Attachment #6 (text/plain)] yeah i've decided ... please, when you merge my next update, this patch for example, yes, when you merge this patch, delete my policy patch entirely. so, don't include within the update my patch to the policy patch. no remove the policy patch that'll make my job easier lw already turns all those AI options off by default, but doesn't lock them. this is enough for me. locking them only makes it slightly harder for the user to simplify modify the policy in /usr/local instead, and restart the browser. might as well just leave the policy as-is so delete my policy patch entirely Am 19.10.26 um 14:24 schrieb Leah Rowe: > > 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 ["OpenPGP_0x5C654067D383B1FF.asc" (application/pgp-keys)]
["OpenPGP_signature.asc" (application/pgp-signature)] [prev in list] [next in list] [prev in thread] [next in thread] 

Page 26

[prev in list] [next in list] [prev in thread] [next in thread] 

List: openbsd-ports
Subject: Re: PATCH www/librewolf: update to v 158.0-1
From: Stuart Henderson <stu () spacehopper ! org>
Date: 2026-10-19 13:58:52
Message-ID: atYiHMDnE_8dRjU5 () symphytum ! spacehopper ! org
[Download RAW message or body] On 2026/10/19 14:21, Leah Rowe wrote:
> just turn it back on. again, i don't think translations are disabled, just
> AI-based translations. you're not going to be running AI locally in lw/ff,
> unless i'm mistaken? i think they just use external chatbots and if so it's
> the same argument. firefox lump all those features together, there's no separate settings
block for GenAI vs what-used-to-be-called-machine-learning / natural
language processing. on-device translations are certainly regarded
as AI by firefox. (IIUC some of the ones in Firefox that are hard-disabled in config
won't work at all, for example I didn't check but I think the
speech-to-text stuff may use whisperfile which depends on cosmopolitan
libc, which wants its own syscall access, some others may need llamafile) > also, use of language services isn't required. you can use a human
> interpreter if necessary, or learn the language yourself. i started learning
> german last year. yeah, I can read a bit of german, french, spanish, but if I'm trying to
quickly make sense of an article etc to see if I want to spend more
time with it, a quick machine translation is a big help. and I am no
good at non-latin scripts (and if you're trying to make some kind of
sense of current affairs you surely want some of those news sources).
yes it's going to be coloured by the training corpus but no human
interpreter is going to be exactly neutral either. > but yeah, just modify it.
> > or idk. i mean, i'm in change of stewarding this port, but if the other
> peeps in puffyos want it, they can turn stuff back on. we're all team
> players right?
> > -- > Company director, Minifree Ltd
> Registered in England, No. 9361826 | VAT No. GB202190462
> Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK
> [prev in list] [next in list] [prev in thread] [next in thread]