From: Mike Larkin Subject: Re: [IMPROVEMENT] Integrate the app server daemon into devel/codex. To: David Uhden Collado Cc: kirill@korins.ky, ports@openbsd.org Date: Tue, 13 Oct 2026 18:42:36 -0700 On Tue, Oct 13, 2026 at 07:59:00PM +0000, David Uhden Collado wrote: > Kirill A. Korinsky wrote: > > On Tue, 13 Oct 2026 20:42:00 +0200, > > David Uhden Collado wrote: > > > > > > Please find attached a patch proposing proper integration of the Codex > > > app-server daemon with the OpenBSD package system. > > > > > > The port already includes the daemon functionality, but upstream > > > normally expects a complete standalone installation and may try to > > > install another Codex executable under ~/.codex/packages. This is > > > unsuitable for a package managed by pkg_add. > > > > > > The proposed changes address this without disabling the daemon or > > > rewriting its lifecycle management. > > > > > > > Sorry, you tried to ship way more than only this changes. > > > > You had touched many patches and reformat port's Makefile. > > > > > [2 codex-0.162.1p0.diff ] > > > ? devel/codex/files > > > ? devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs > > > ? devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs > > > ? devel/codex/patches/patch-codex-rs_app-server-daemon_src_managed_install_rs > > > ? devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_build_config_clang_clang_gni > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_build_detect_host_arch_py > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_AddressSpace_hpp > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_EHHeaderParser_hpp > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_UnwindCursor_hpp > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_v8_gni_v8_gni > > > ? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_v8_src_wasm_stacks_cc > > > ? devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs > > > > I thunk you also forgot quite a few patches. > > > > Can you resend your diff to minimal version which adds support of that codex daemon? > > > Hello Kirill, > > You're right. The previous diff included more than the daemon integration, > and I should have made that clearer. Sorry for the confusion. > > I've attached a revised diff against the current CVS tree, including the > previously missing patch files. > > The daemon integration itself is relatively small. It reuses the existing > Codex executable as the app-server daemon, installs it with the required > package manifest under libexec/codex, and makes the daemon resolver use that > executable instead of downloading or copying another one into > ~/.codex/packages. > > The existing upstream process management, Unix sockets, IPC, and > start/stop/restart functionality remain unchanged. Only internal > installation and self-update mechanisms are disabled, since pkg_add owns the > executable. > > I also included some V8 portability improvements. These are independent of > the daemon integration, but I think they are worth considering because Codex > builds its own V8 150.4.0 and uses it for code-mode functionality. > > Several changes are adapted from the OpenBSD www/chromium port patches: > > - Prevent Linux-specific Clang module configuration from being enabled on > BSD. > - Correct OpenBSD arm64 host architecture detection. > - Improve libunwind handling of DW_EH_PE_omit and reuse cached unwind > sections. > - Enable OpenBSD support in the WASM interpreter platform checks. > - Use MAP_STACK for the usable WASM stack region while preserving its guard > pages. > > These changes address OpenBSD-specific portability and runtime behavior > rather than daemon management. Keeping the relevant V8 fixes consistent with > Chromium should also make future updates easier to maintain. > > Thanks, > David. the right way to do this is to get this work upstreamed rather than keep 2500+ lines of patches locally. someone is going to need to make sure that these thousands of lines of diffs keep working when upstream makes changes, and you yourself have pointed out that the churn there is incredible. this is going to add a ton of work moving forward for whoever is the maintainer. you made one specific thing work for this specific version only. it's gonna fall apart fast and we're gonna end up with thousand line diffs that patch other thousand line diffs. but if you take the time to land this upstream then we stand a better chance of making this continue to work.