bug#75237: Packaging ghostty terminal

bug#75237: Packaging ghostty terminal

[boogs via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

Hi,
I'm looking to package the ghostty terminal (https://ghostty.org/docs/install/build) but I ran into an issue with the zig build system pertaining to the dependencies?

I've attached the package definition including the error output below. I would appreciate some pointers here please.


[-- Attachment #2: packages.scm --]
[-- Type: text/plain, Size: 1669 bytes --]

(define-module (boogs packages)
  #:use-module (guix build-system zig)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (gnu packages glib)
  #:use-module (gnu packages zig-xyz)
  #:use-module (gnu packages gnome)
  #:use-module (gnu packages gtk)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages zig)
  #:use-module (srfi srfi-1))

(define-public ghostty
  (let* ((version "1.0.0")
         (commit (string-append "v" version)))
    (package
      (name "ghostty")
      (version version)
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/ghostty-org/ghostty.git")
               (commit commit)))
         (file-name (git-file-name name version))
         (sha256
          (base32
           "0cs1n7qddy2487hbw72v0h23ybdmp25cag00q46pk0czi5kkawh0"))))
      (build-system zig-build-system)
      (arguments
       (list #:zig zig-0.13
             #:install-source? #f))
      (native-inputs
       (list gtk
             libadwaita
             pkg-config
             zig))
      (home-page "https://www.ghossty.org/")
      (synopsis "Fast, feature-rich, and cross-platform terminal
  emulator that uses platform-native UI and GPU acceleration.")
      (description
       "Ghostty is a terminal emulator that differentiates itself by
  being fast, feature-rich, and native. While there are many excellent
  terminal emulators available, they all force you to choose between
  speed, features, or native UIs. Ghostty provides all three.")
      (license expat))))

ghostty

[-- Attachment #3: bug-ghostty-1.0.0.drv.gz --]
[-- Type: application/octet-stream, Size: 13948 bytes --]

[-- Attachment #4: Type: text/plain, Size: 12 bytes --]



-- 
boogs

bug#75237: Packaging ghostty terminal

[Murilo via Bug reports for GNU Guix]

Hi, sadly its not an easy task as you might be expecting it to be.

It vendors a lot of dependencies in the repository and recursive dependency
replacing with zig fetch isn't quite there yet so we have to do some more work,
create a cache and vendor it with --system. I don't know if this is the best
approach since I never touched anything zig, but it seems to be the easiest from
my research.

Fortunately I've already went through the trouble and packaged it on my channel
a couple days ago so you can use it right away :)

Feel free to take a look at my package definition [0] or use my channel [1]. I
plan to upstream it here once holidays are over and I have some free time, whats
left to do is looking at the vendored sources one by one to ensure everything is
free and there are no nasty pre-built stuff inside the sources, and see if any
of it can be made into a proper guix package so we can use it as normal inputs.
Feel free to help with those too if you want to, the more help the merrier :)

[0] https://codeberg.org/look/saayix/src/branch/entropy/saayix/packages/terminals.scm
[1] https://codeberg.org/look/saayix

bug#75237: Packaging ghostty terminal

[boogs via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/html, Size: 1941 bytes --]

bug#75237: Packaging ghostty terminal

[Frank J. Cameron]

Murilo wrote on 1 Jan 14:44 +0100
> Fortunately I've already went through the trouble and packaged it on my channel
> a couple days ago so you can use it right away :)

Thanks for the package; I can confirm it built successfully for me as well.

So, I took your code and munged it with the version I had been working on. My
new version doesn't actually work :-) but, I posted it on the off chance that
someone would find it interesting.

https://gitlab.com/-/snippets/4792310

I was trying to handle the zig system pkgdir by defining a package for each
module that could simply be added as build-inputs:

    (native-inputs (list [...]
      zig-pkgdir-breakpad-6dc2a1ea         zig-pkgdir-cimgui-1f40c122
      zig-pkgdir-fontconfig-a4fcb3b7       zig-pkgdir-freetype-2adf969d
      zig-pkgdir-glfw-98a7272d             zig-pkgdir-glslang-9dd23ba1
      zig-pkgdir-harfbuzz-d1063122         zig-pkgdir-highway-8cbe165b
      zig-pkgdir-imgui-8bfc6402            zig-pkgdir-iterm2_themes-f0498620
      zig-pkgdir-libpng-723b1c66           zig-pkgdir-libxev-02078bbf
      zig-pkgdir-libxml2-65a64f7d          zig-pkgdir-mach_glfw-37696a62
      zig-pkgdir-oniguruma-cd9706bb        zig-pkgdir-sentry-37a9c77e
      zig-pkgdir-spirv_cross-2748c8da      zig-pkgdir-utfcpp-a931e641
      zig-pkgdir-vaxis-c6e4c087            zig-pkgdir-vaxis-c8c91d2f
      zig-pkgdir-vulkan_headers-894fa2cf   zig-pkgdir-wayland_headers-da2c11ca
      zig-pkgdir-wuffs-de700462            zig-pkgdir-x11_headers-57b36465
      zig-pkgdir-xcode_frameworks-d67d19cb zig-pkgdir-z2d-06b5416a
      zig-pkgdir-zf-b5dd35e8               zig-pkgdir-zg-984c6e40
      zig-pkgdir-zigimg-1be35cf5           zig-pkgdir-zig_js-f4f6fefc
      zig-pkgdir-ziglyph-6a02cf25          zig-pkgdir-zig_objc-4415c634
      zig-pkgdir-zlib-66742efb))

It does look like it populates the pkgdir successfully (with symlinks into the
store) and starts building but fails:

error: sub-compilation of libcxx failed
    /gnu/store/...-zig-pkgdir-xcode_frameworks-.../include/i386/_types.h:48:33: note: typedef redefinition with different types ('long long' vs 'long')
    [...]
    /gnu/store/...-glibc-2.39/include/bits/types.h:44:25: note: previous definition is here
    [...]
Build Summary: 78/81 steps succeeded; 1 failed (disable with --summary none)

bug#75237: Packaging ghostty terminal

[Murilo via Bug reports for GNU Guix]

Hi Frank,

> error: sub-compilation of libcxx failed
>     /gnu/store/...-zig-pkgdir-xcode_frameworks-.../include/i386/_types.h:48:33: note: typedef redefinition with different types ('long long' vs 'long')
>     [...]
>     /gnu/store/...-glibc-2.39/include/bits/types.h:44:25: note: previous definition is here
>     [...]
> Build Summary: 78/81 steps succeeded; 1 failed (disable with --summary none)

I took a glance at the package definition in the link you sent, it seems to me
that this error is caused because ghostty vendors [1] various zig custom builds
[2] from the C sources within its own source repository.
What I suspect is happening (again, I didn't try building your
package definition to check, I could be wrong!) with this error is the
'unpack-dependencies phase from zig-build-system runs 'zig fetch' in all the
dependencies and thus replaces all the zig sources in the main 'build.zig.zon',
including the local vendored ones [2], thus you won't get the custom vendored
builds from the local source repository [1].

This is why I replaced [3] the 'unpack-dependencies in the %standard-phases.
This doesn't mean we absolutely cannot use 'unpack-dependencies, infact I am
trying to package it with the 'unpack-dependencies phase, but its proving to be
a bit hard to accomodate it.
The easier option would be to reimplement it and only run 'zig fetch' on the
packages that we want it to replace, but it would be best if we could use the
'unpack-dependency phase from zig-build-system for upstreaming purposes.

[1] https://github.com/ghostty-org/ghostty/tree/6ef757a8f85db7a124d370378850339a899c9e65/pkg
[2] https://github.com/ghostty-org/ghostty/blob/6ef757a8f85db7a124d370378850339a899c9e65/build.zig.zon#L46-L59
[3] https://codeberg.org/look/saayix/src/commit/b319144fbcd37ce786134cca1092946afad8393b/saayix/packages/terminals.scm#L64

bug#75237: Packaging ghostty terminal

[Murilo via Bug reports for GNU Guix]

I essentially gave up on packaging ghostty for upstreaming, already spent too
much time on this so I'm moving on.
Will continue to update the current working version on my channel, for personal
use.
Here's my WIP guix branch for ghostty if someone wants to give it a shot, in the
hopes that it might be useful for someone:

https://codeberg.org/look/guix/src/branch/wip-ghostty
https://codeberg.org/look/guix/commits/branch/wip-ghostty

Some zig dependencies there already meet the upstreaming requirements.

The ghostty package does not build, getting some strange errors because of
libvaxis, and missing some zig-mach dependencies.

Might experience some version mismatches because I'm initially using the C
packages we already have packaged on guix.

It needs wuffs which is going to be pain :-(.

The 'fix-path phase substitute* does not work, can be removed, was something I
was experimenting with.

The 'hard-disable-macos-dependencies is also an experiment, might not work.

bug#75237: Packaging ghostty terminal

[Frank J. Cameron]

On Fri, Jan 10, 2025, at 1:49 PM, Murilo wrote:
> I took a glance at the package definition in the link you sent, it seems to me
> that this error is caused because ghostty vendors [1] various zig custom builds
> [2] from the C sources within its own source repository.
> What I suspect is happening (again, I didn't try building your
> package definition to check, I could be wrong!) with this error is the
> 'unpack-dependencies phase from zig-build-system runs 'zig fetch' in all the
> dependencies and thus replaces all the zig sources in the main 'build.zig.zon',
> including the local vendored ones [2], thus you won't get the custom vendored
> builds from the local source repository [1].
>
> This is why I replaced [3] the 'unpack-dependencies in the %standard-phases.

I don't that's the issue in this case. Just now as an experiment, I replaced
unpack-dependencies instead of running after unpack and hit the same error. It
appears to me that since I was defining the module packages with
copy-build-system rather than zig-build-system that was bypassing the zig fetch
magic in unpack-dependencies (there are no zig fetch appearing in the log). As
another experiment, I used zig-build-system instead of copy-build-system for the
module packages and it did do the zig fetch magic in that case (zig fetch was
visible in the log) (and then failed in a different way).

> This doesn't mean we absolutely cannot use 'unpack-dependencies, infact I am
> trying to package it with the 'unpack-dependencies phase, but its proving to be
> a bit hard to accomodate it.

Yesterday, I started from scratch with each zig module dependency defined as a
package using zig-build-system (modeled after libxkcb in zig-xyz) and letting
the default unpack-dependencies do the zig fetch magic. It got past the point of
trying to download dependencies and then died while building:

starting phase `build'
running: ("zig" "build" "--prefix" "" "--prefix-lib-dir" "lib" "--prefix-exe-dir" "bin" "--prefix-include-dir" "include" "--verbose" "-Dtarget=x86_64-linux-gnu" "-j2" "--release=fast")
thread 1257 panic: unable to find module 'freetype'
/gnu/store/ncxvllgf84qnnylw7b1snwvg2sapfc1g-zig-0.13.0/lib/zig/std/Build.zig:1857:18: 0x1152797 in module (build)
            panic("unable to find module '{s}'", .{name});
                 ^
/tmp/guix-build-ghostty-1.0.1.drv-0/source/build.zig:1114:67: 0x1152ce7 in addDeps (build)
        step.root_module.addImport("freetype", freetype_dep.module("freetype"));

Thanks!

-frank