Spec URL: https://github.com/AnthonyZhOon/ghostty-rpm/blob/main/SPECS/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.0.0/ghostty-1.0.0-4.fc41.src.rpm Description: Ghostty is a cross-platform, GPU-accelerated terminal emulator that aims to push the boundaries of what is possible with a terminal emulator by exposing modern, opt-in features that enable CLI tool developers to build more feature rich, interactive applications. Fedora Account System Username:a-zhn Copr: https://copr.fedorainfracloud.org/coprs/a-zhn/ghostty/ This is my first time submitting a package review, I've gone through the Fedora Packaging Guidelines and tried to find references but haven't found existing examples of Zig projects being packaged.
Cannot find any valid SRPM URL for this ticket. Common causes are: - You didn't specify `SRPM URL: ...` in the ticket description or any of your comments - The URL schema isn't HTTP or HTTPS - The SRPM package linked in your URL doesn't match the package name specified in the ticket summary --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Welcome to Fedora. Spec link needs to be to the raw text file, not an html rendering. Spec URL: https://raw.githubusercontent.com/AnthonyZhOon/ghostty-rpm/refs/heads/main/SPECS/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.0.0/ghostty-1.0.0-4.fc41.src.rpm Initial comments: a) Try to use packaged fonts rather than bundling fonts. Go through the installation process, remove the installed fonts and place symlinks to the system fonts. b) The zig build system has options to use system libraries where possible. Does this work for the non Zig libraries? c) Are any of the Zig libraries relatively stable and worth packaging?
I have a few more comments: First, the package currently doesn't build. It looks like it's trying to fetch stuff over the network - this is not allowed for official package builds, which run isolated from the internet in a container with a separate network namespace. If you took inspiration from the unofficial COPR (https://copr.fedorainfracloud.org/coprs/pgdev/), the build there only works because COPR allows overriding the network isolation, which official builds can't. > %global debug_package %{nil} This is a red flag for a package with "native" executables. You'll need to make sure that the zig executable is built *with* debug symbols. Not sure how to tell that to the zig compiler, but there should be a flag to do it. For the common description (%project_description macro), I would recommend this syntax: %global project_description %{expand: ... ... ...} This avoids having to escape newlines. > Source0: https://release.files.ghostty.org/%{version}/%{name}-source.tar.gz This is kind of bad too. Does upstream not provide "versioned" tarballs (i.e. something like "ghostty-1.0.0-source.tar.gz")? Having the tarball name be the same for different versions will cause headaches for packaging. > BuildRequires: zig >= 0.13.0, zig < 0.14.0, pandoc, minisign Please split this across lines (and I would also recommend to keep the list alphabetical), i.e. BuildRequires: (zig >= 0.13 with zig < 0.14~) BuildRequires: pandoc BuildRequires: minisign BuildRequires: pkgconfig(fontconfig) BuildRequires: pkgconfig(freetype2) BuildRequires: pkgconfig(glib-2.0) BuildRequires: pkgconfig(gtk4) BuildRequires: pkgconfig(harfbuzz) BuildRequires: pkgconfig(libadwaita-1) BuildRequires: pkgconfig(libpng) BuildRequires: pkgconfig(oniguruma) BuildRequires: pkgconfig(zlib-ng) (...) BuildRequires: fdupes BuildRequires: desktop-file-utils (...) and the same for the bundled Provides too: Provides: bundled(font(CodeNewRoman)) Provides: bundled(font(CozetteVector)) Provides: bundled(font(Inconsolata)) Provides: bundled(font(JuliaMono)) Provides: bundled(font(JetBrainsMonoNerdFont)) Provides: bundled(font(JetBrainsMonoNoNF)) Provides: bundled(font(KawkabMono)) Provides: bundled(font(Lilex)) Provides: bundled(font(MonaspaceNeon)) Provides: bundled(font(NotoColorEmoji)) Provides: bundled(font(NotoEmoji)) Provides: bundled(glslang) = 14.2.0 Provides: bundled(spirv-cross) = 13.1.1 > # There are more build dependencies statically linked > # listed in the build.zig.zon This is not enough - bundling is OK (and probably unavoidable in an immature library ecosystem such as zig's), but you *MUST* specify bundled dependencies in RPM metadata too, so probably something like: Provides: bundled(zig(mitchellh/libxev)) = 0~gitdb6a52b Provides: bundled(zig(mitchellh/mach-glfw)) = 0~git37c2995 (etc.) Looks like these dependencies are all git snapshots :( There's also a lot of zig bindings for C libraries (in ./pkg/). According to the README, they're subprojects that are (for now) developed as part of ghostty, so that should be fine. > %global pubkey RWQlAjJC23149WL2sEpT/l0QKy7hMIFhYdQOFy0Z7z7PbneUgvlsnYcV > %global _build_flags %{?with_simdutf:-fsys=simdutf} --system "/tmp/offline-cache/p" -Dcpu=baseline -Doptimize=ReleaseFast Please define macros at the top of the spec file, and not under the shell scriptlets. I didn't even know that this is possible. :) > Release: 4%{?dist} > %changelog > %autochangelog This is mixing rpmautospec with non-rpmautpspec constructs, and will cause problems. Either use explicit Release and changelog, or let rpmautospec handle both of them. Mix-and-match is not a good idea, and will give weird results.
*** Bug 2334902 has been marked as a duplicate of this bug. ***
I noticed that the Fedora zig package has a zig-rpm-macros subpackage that has macros like %zig_build and %zig_install. Those are already used by ncdu and river, so it would probably be best to use those here too to avoid diverging.
Spec URL: https://raw.githubusercontent.com/AnthonyZhOon/ghostty-rpm/refs/heads/main/SPECS/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.0.1/ghostty-1.0.1-1.fc41.src.rpm There's a PR merged for removing the default strip in release mode behaviour to allow debuginfo in the next upstream release https://github.com/ghostty-org/ghostty/pull/3945 There's some news about a next 1.1 release in a few weeks upstream. Versioned archives are available since 1.0.1 I've removed the network requirement and used zig-rpm-macros Got some comments from someone who works on the zig package at https://pagure.io/ghostty-rpm/pull-request/1 There's some precedent in river for just providing plain bundled(<dep>) = <version> for the zig dependencies as it reflects what the package manager zon names dependencies for zig, and they suggest a "bundled(zon(<dep>)) = <version>" syntax if we want to add metadata.
Copr build: https://copr.fedorainfracloud.org/coprs/build/8508878 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08508878-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Bundling is not great as reuse across packages is minimal. The bundled package does not get as thorough a review and as thorough testing as a standalone package. Bundling is therefore discouraged. Ideally, once dependencies are in a stable state, bundling should be needed only infrequently. Zig is still relatively new, so many packages will not be in a stable state, but hopefully the ecosystem will evolve so that majority of dependencies do not need to be bundled.
Here's what the policy says about bundling: > All packages whose upstreams have no mechanism to build against system libraries MAY opt to carry bundled libraries, but if they do, they MUST include an indication of what they bundle. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling I don't believe we have any zig libraries packaged as system libraries, which makes it impossible to build against system libraries of these at this point. Therefore, bundling is allowed and the bundled libraries are not a blocker for this review (as long as they are indicated with provides as is already being discussed).
> # Need to disable build from stripping debug > %global debug_package %{nil} You should only need this if the built executables actually have no debuginfo. And if that is the case, something is wrong with the compiler flags that are getting passed. > There's some precedent in river for just providing plain bundled(<dep>) = <version> for the zig dependencies as it reflects what the package manager zon names dependencies for zig, > and they suggest a "bundled(zon(<dep>)) = <version>" syntax if we want to add metadata. I think the latter form should be preferred. The one without "namespacing" doesn't really make sense, it usually refers to package names that already exist in Fedora. Other language ecosystems also use syntax like "bundled(crate(foo)) = 1.2.3" or "bundled(golang(github.com/foo/bar)) = 2.3.4" since this matches the virtual Provides that those crates / Go libraries *would* have if they were packaged instead of bundled. I also tried to find documentation for "zon", but I couldn't find anything relevant. Is this a builtin tool of the zig toolchain or some third-party package manager for zig? I found no references to it in https://github.com/ziglang at all. That said, I'm clearly not responding to updates in this ticket in a timely manner, so I'd like to step aside and let someone else continue with the review.
Hey, zig maintainer here > I also tried to find documentation for "zon", but I couldn't find anything relevant. > Is this a builtin tool of the zig toolchain or some third-party package manager for zig? > I found no references to it in https://github.com/ziglang at all. there used to be a basic explanation but it appears it was removed from website at some point. zon stands for Zig Object Notation and is used by Zig for `build.zig.zon`, a project file where metadata is stored. This includes: - project name - version - relevant paths/files (used for hash generation) - dependencies where dependencies is an object within itself that can contain either a url and a hash or a local relative path. the url can point to any arbitrary file, archive or git repository with names used for dependencies being modifable so a given dependency may be given a different name depending on the project. > I think the latter form should be preferred. The one without "namespacing" doesn't really make sense, it usually refers to package names that already exist in Fedora. Other language ecosystems also use syntax like "bundled(crate(foo)) = 1.2.3" or "bundled(golang(github.com/foo/bar)) = 2.3.4" since this matches the virtual Provides that those crates / Go libraries *would* have if they were packaged instead of bundled. the namespace bundled used for other languages tend to be automatically generated from metadata provided by a given project. Usually this includes some kind of named identifier, which zig lacks. As mentioned zig dependencies can point to any arbitrary content with the only globally identifying factor being the hash. This makes it pretty difficult to specify all the bundled provides since they can be zig projects or C projects or even something else. The for the future is to have 2 form of bundled provides generation: - the zon namespace that includes the hash for every remote dependency - the zig namespace where it iterates through every zig dependency used and uses the name specified in build.zig this will only account for zig dependencies directly and includes the identifier used within the upstream build system so non-zig dependencies would need to be provided manually. Until then the stop-gap solution is to simply use plain provides, the river package already does this as well.
Spec URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0/ghostty-1.1.0-1.fc41.src.rpm Upstream v1.1.0 has released: - New dependencies on wayland, wayland-protocols, plasma-wayland-protocols - Packaging section of the upstream release notes mentions added config (-Dstrip mainly) https://ghostty.org/docs/install/release-notes/1-1-0#changes-for-package-maintainers - debuginfo is being generated now
Created attachment 2074548 [details] The .spec file difference from Copr build 8508878 to 8589178
Copr build: https://copr.fedorainfracloud.org/coprs/build/8589178 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08589178-ghostty/fedora-review/review.txt Found issues: - Not a valid SPDX expression 'MIT AND Apache-2.0 AND APSL-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND BSL-1.0 AND ClArtistic AND curl AND (GPL-2.0-or-later WITH Autoconf-exception-generic) AND GPL-3.0-or-later AND LGPL-2.1 AND LicenseRef-Fedora-Public-Domain AND MPL-2.0 AND OFL-1.1 AND Unicode-3.0 AND (WTFPL OR CC0-1.0) AND License: MIT AND (FTL OR GPL-2.0-or-later) AND (GPL-2.0-or-later WITH Autoconf-exception-generic) AND (WTFPL OR CC0-1.0) AND APSL-2.0 AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BSD-4-Clause AND BSL-1.0 AND ClArtistic AND GPL-3.0-or-later AND HPND AND LGPL-2.1 AND LicenseRef-Fedora-Public-Domain AND LicenseRef-Public-Domain AND MIT-Modern-Variant AND MPL-2.0 AND OFL-1.1 AND Unicode-3.0 AND Unicode-DFS-2016 AND Zlib) AND curl'. Read more: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 Please know that there can be false-positives. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Spec URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.1/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.1/ghostty-1.1.0-1.fc41.src.rpm License field fixed
Created attachment 2075160 [details] The .spec file difference from Copr build 8589178 to 8608028
Copr build: https://copr.fedorainfracloud.org/coprs/build/8608028 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08608028-ghostty/fedora-review/review.txt Found issues: - Upstream MD5sum check error, diff is in /var/lib/copr-rpmbuild/results/ghostty/diff.txt Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ Please know that there can be false-positives. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Spec URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0-2/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0-2/ghostty-1.1.0-1.fc41.src.rpm Accidentally still had the latest-commit source URL
Created attachment 2075339 [details] The .spec file difference from Copr build 8608028 to 8612558
Copr build: https://copr.fedorainfracloud.org/coprs/build/8612558 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08612558-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0-3/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.0-3/ghostty-1.1.0-1.fc41.src.rpm Meet the recommendations for shell completions at https://docs.fedoraproject.org/en-US/packaging-guidelines/ShellCompletions/
Created attachment 2075737 [details] The .spec file difference from Copr build 8612558 to 8631844
Copr build: https://copr.fedorainfracloud.org/coprs/build/8631844 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08631844-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2/ghostty-1.1.2-1.fc41.src.rpm 1.1.2 release. Skipped 1.1.1 as it had a bug that required a new release - Require hicolor-icon-themes for ownership of the icon directories - Split subpackage ghostty-nautilus for 'Open in Ghostty' integration - New bundled dependency zig-gobject - Use a single license field on the main package listing Looking at the review file, there's still some unowned directories for vim, nvim, bat highlighting integration and servicemenus for dolphin 'Open in Ghostty' file explorer integration. What is the recommended way to specify that these are extras that are ideally installed but shouldn't bring in every dependency? I think a weak 'suggests' works but won't install by default and reverse dependencies would fit but should wait om passing review. I found the reason why the fedora-review tool can't download from the ghostty mirror. It uses urllib which is a blocked user-agent by Cloudflare (https://deps.files.ghostty.org/ is hosted there) In python >>> import urllib.request >>> request.urlopen("https://cloudflare.com") # http403 >>> request.urlopen("https://deps.files.ghostty.org/") # http403 Changing the user-agent from "User-Agent: Python-urllib/3.13" to an alternative can fix this Dependencies are mirrored by ghostty as the codeberg source repos are frequently unavailable
Created attachment 2076411 [details] The .spec file difference from Copr build 8631844 to 8654080
Copr build: https://copr.fedorainfracloud.org/coprs/build/8654080 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08654080-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty-1.1.2-1.fc41.src.rpm Fixing the unowned directories warnings from fedora-review, ghostty-dolphin and ghostty-syntax-vim are now add-on packages with appropriate filesystem requires. The neovim and bat syntax files don't work out of the box so I decided not to provide them. hicolor-icon-theme doesn't support 1024x1024 sized icons so I've removed that too
Created attachment 2077236 [details] The .spec file difference from Copr build 8654080 to 8675814
Copr build: https://copr.fedorainfracloud.org/coprs/build/8675814 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08675814-ghostty/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty-1.1.2-1.fc41.src.rpm Sorry, accidentally picked a dependency bump commit when rebasing from tip onto the stable release. Think this is in a good state for further review though, I've addressed the warnings from fedora-review
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-2/ghostty-1.1.2-1.fc41.src.rpm Didn't notice a minor update didn't trigger the review service
Created attachment 2077975 [details] The .spec file difference from Copr build 8675814 to 8704551
Copr build: https://copr.fedorainfracloud.org/coprs/build/8704551 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08704551-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
I missed covering this feedback. (In reply to Benson Muite from comment #2) > Initial comments: > a) Try to use packaged fonts rather than bundling fonts. Go through the > installation process, remove the > installed fonts and place symlinks to the system fonts. To clarify, the srpm contains bundled fonts as ghostty compiles its fallback fonts (JetBrains Mono Nerd Font, Symbols) into the binary, additional fonts are also used only for testing and are not installed. > b) The zig build system has options to use system libraries where possible. > Does this work for the non Zig > libraries? Using system libraries requires writing the build script configuration switches to switch between a build.zig.zon source dependency or a system integrated dependency. Pull requests can be made to configure more dependencies for system integration. > c) Are any of the Zig libraries relatively stable and worth packaging? The current zig dependency system (not system integrated) is that it expects an archive or directory with a matching contents hash as specified in the build.zig.zon file. Then "zig fetch <directory/archive>" is performed before building to populate a zig-cache-dir with "zig-cache-dir/p/<contents-hash>". At build-time the existence of the "cache/p/<hash>" is checked against the build.zig.zon specification. As for stable packages, I'm not confident that the current zig dependency system is stable. Currently, each dependency in a build.zig.zon is not tagged with a version as it's only a URL + contents-hash, a version can only be inferred from the url. There's several open issues for the build system set aside for future milestones https://github.com/ziglang/zig/milestones. We can also expect churn for existing zig projects with breaking language changes between compiler releases at least until a 1.0.0 compiler
(In reply to Anthony Oon from comment #34) > I missed covering this feedback. > (In reply to Benson Muite from comment #2) > > Initial comments: > > a) Try to use packaged fonts rather than bundling fonts. Go through the > > installation process, remove the > > installed fonts and place symlinks to the system fonts. > To clarify, the srpm contains bundled fonts as ghostty compiles its fallback > fonts (JetBrains Mono Nerd Font, Symbols) into the binary, additional fonts > are also used only for testing and are not installed. Ok > > b) The zig build system has options to use system libraries where possible. > > Does this work for the non Zig > > libraries? > Using system libraries requires writing the build script configuration > switches to switch between a build.zig.zon source dependency or a system > integrated dependency. Pull requests can be made to configure more > dependencies for system integration. This would be nice. Happy to help package some of the dependencies. > > c) Are any of the Zig libraries relatively stable and worth packaging? > The current zig dependency system (not system integrated) is that it expects > an archive or directory with a matching contents hash as specified in the > build.zig.zon file. Then "zig fetch <directory/archive>" is performed before > building to populate a zig-cache-dir with "zig-cache-dir/p/<contents-hash>". > At build-time the existence of the "cache/p/<hash>" is checked against the > build.zig.zon specification. > > As for stable packages, I'm not confident that the current zig dependency > system is stable. Currently, each dependency in a build.zig.zon is not > tagged with a version as it's only a URL + contents-hash, a version can only > be inferred from the url. There's several open issues for the build system > set aside for future milestones https://github.com/ziglang/zig/milestones. > We can also expect churn for existing zig projects with breaking language > changes between compiler releases at least until a 1.0.0 compiler Ok. Probably the following can be packaged separately or used from Fedora repositories (most are C++/C): utfcpp iTerm2-Color-Schemes SPIRV-Cross imgui sentry-native glslang highway breakpad wuffs wayland wayland-protocols plasma-wayland-protocols libev Would suggest adding patches to relax the version requirements.
iTerm2-Color-Schemes, this is a general repo for terminal emulators to store their theme files (content in terminal-specific formats). Ghostty only copies its own files to its data directory. I guess we could patch or PR to minimise the dependency to just the ghostty files. Header-only or C libs I think are simple to package: utfcpp wuffs glslang, the current Fedora glslang package only provides glslang.a static archives, these are compiled against the gcc C++ stdlib libstdc++ while Zig prefers linking against libc++ (clang) with its builtin exe.linkLibCpp() step. We could ask the glslang package maintainer about whether a shared-lib could be provided. SPIRV-Cross, fedora seems to package a newer version (15.2.0) compared to ghostty on 14.x.x, could look into upgrading versions in ghostty. cimgui, this is the generated C lib version of Dear ImGui (C++) they are designed to be header+source files you can include in your project I think. Notably there's two branches in development docking and non-docking. sentry, breakpad. Ghostty doesn't enable sentry and its breakpad dependency by default. I've stubbed this from the package. highway, ghostty seems to use this as a vendored dependency adding additional compatibility files and headers to convert #defines into zig functions. It doesn't seem easy to dynamic link for now. libev, ghostty uses libxev. An event loop library for io_uring, epoll, kqueue written in Zig. wayland-protocols, plasma-wayland-protocols, these are used for their datadirs the devel package provides a pkgconfig we could use under system integration as 'pkg-config --variable=pkgdatadir wayland-protocols' for the protocol.xml files instead of the bundled files. Think this can be PR'd. The next version will also system integrate with gtk4-layer-shell already. wayland, the commit depended on is quite recent and but it's the same being needed for protocol xml files which is unchanged.
Discussing with the Ghostty maintainers, the opinion on the wayland, wayland-protocols, plasma-wayland-protocols dependencies is that they are just content file packages with backwards-compatible xml specs used to generate C files via wayland-scanner. So it is preferred to be on the latest versions and bundle for distros missing these packages.
It was discussed with the Ghostty maintainers that wuffs, highway, utfcpp, and cimgui are libs intended to be vendored sources that are configured with defines. Packaging would mean providing both header and source files which seems atypical. There is currently a vendored glad file for working with opengl. I was mistaken in that glslang is the one where Fedora is at 15.2.x while Ghostty depends on 14.x.x. SPIRV-Cross has an existing system-integration switch but is not yet packaged and could be worked on.
SPEC URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-3/ghostty.spec SRPM URL: https://github.com/AnthonyZhOon/ghostty-rpm/releases/download/v1.1.2-3/ghostty-1.1.2-3.fc41.src.rpm Removed unnecessary bundled deps, zig_js, zig_obj, breakpad, sentry Subpackages for optional add-ons (dolphin, nautilus Open in Terminal, vim syntax)
Created attachment 2079651 [details] The .spec file difference from Copr build 8704551 to 8748647
Copr build: https://copr.fedorainfracloud.org/coprs/build/8748647 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2334903-ghostty/fedora-rawhide-x86_64/08748647-ghostty/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
(In reply to Anthony Oon from comment #38) > It was discussed with the Ghostty maintainers that wuffs, highway, utfcpp, > and cimgui are libs intended to be vendored sources that are configured with > defines. Packaging would mean providing both header and source files which > seems atypical. There is currently a vendored glad file for working with > opengl. Most packaging uses shared libraries, and header files are provided. Would be great if this can be supported in the Zig ecosystem. Vendoring should be avoided if it can be. > > I was mistaken in that glslang is the one where Fedora is at 15.2.x while > Ghostty depends on 14.x.x. > Does anything break? > SPIRV-Cross has an existing system-integration switch but is not yet > packaged and could be worked on. Would this take long?
(In reply to Anthony Oon from comment #36) > iTerm2-Color-Schemes, this is a general repo for terminal emulators to store > their theme files (content in terminal-specific formats). Ghostty only > copies its own files to its data directory. I guess we could patch or PR to > minimise the dependency to just the ghostty files. > Great. Even better if this can be upstreamed for other distros to take advantage of. > Header-only or C libs I think are simple to package: > utfcpp > wuffs > Good. Header files are provided as source. We like to use Fedora build flags. > glslang, the current Fedora glslang package only provides glslang.a static > archives, these are compiled against the gcc C++ stdlib libstdc++ while Zig > prefers linking against libc++ (clang) with its builtin exe.linkLibCpp() > step. We could ask the glslang package maintainer about whether a shared-lib > could be provided. Fedora prefers gcc unless for technical reasons it cannot be used. > > SPIRV-Cross, fedora seems to package a newer version (15.2.0) compared to > ghostty on 14.x.x, could look into upgrading versions in ghostty. > > cimgui, this is the generated C lib version of Dear ImGui (C++) they are > designed to be header+source files you can include in your project I think. > Notably there's two branches in development docking and non-docking. > > sentry, breakpad. Ghostty doesn't enable sentry and its breakpad dependency > by default. I've stubbed this from the package. > > highway, ghostty seems to use this as a vendored dependency adding > additional compatibility files and headers to convert #defines into zig > functions. It doesn't seem easy to dynamic link for now. > > libev, ghostty uses libxev. An event loop library for io_uring, epoll, > kqueue written in Zig. libxev webpage indicates it has very few dependencies: https://github.com/mitchellh/libxev Would be good to package separately. Happy to do this. > > wayland-protocols, plasma-wayland-protocols, these are used for their > datadirs the devel package provides a pkgconfig we could use under system > integration as 'pkg-config --variable=pkgdatadir wayland-protocols' for the > protocol.xml files instead of the bundled files. Think this can be PR'd. Would be great if this can be done - it is extra work to check which versions of wayland-protocols and plasma-wayland-protocols are compatible, but it would greatly aid redistribution and adoption of the software. > > The next version will also system integrate with gtk4-layer-shell already. > wayland, the commit depended on is quite recent and but it's the same being > needed for protocol xml files which is unchanged.
(In reply to Benson Muite from comment #42) > (In reply to Anthony Oon from comment #38) > > It was discussed with the Ghostty maintainers that wuffs, highway, utfcpp, > > and cimgui are libs intended to be vendored sources that are configured with > > defines. Packaging would mean providing both header and source files which > > seems atypical. There is currently a vendored glad file for working with > > opengl. > > Most packaging uses shared libraries, and header files are provided. Would > be great if this can be supported in the Zig ecosystem. Vendoring should be > avoided if it can be. Zig does support linking to shared and static libaries (.so and .a) and is capable of parsing C headers But to give some more context about those specific libraries listed: - wuffs wuffs is written in their own custom language that can be transpiled to C, officially they only release a single .c file with no form of build infrastructure place the official recommendation is to just copy and paste it into your project - highway it should be possible to use the system highway shared libary instead of building it from source - utfcpp while utfcpp has an a build system (cmake to be specific) with everything configured to build a libary, its not supported and the developer is considering removing it in the future the only official instructions are "download, unzip, copy into your project" - cimgui cimgui (and by extension dear imgui) are expected to either be included as a submodule or directly vendored in the project, there is no instrastructure for compiling a shared libary and the fact that its common to create custom backends make it unsuitable for this. There are also existing packages that make use of imgui and bundle it like imhex or dolphin-emu. - glad2 the vendored glad stuff is only the generated output from https://gen.glad.sh its possible to regenerate it ourselves but I don't think there is any benefit with there being a likelyhood that a misconfiguration could break it. In general I don't think we should force projects to be compilable as a shared libary, especially if they say this is an unsupported path. > libxev webpage indicates it has very few dependencies: > https://github.com/mitchellh/libxev > Would be good to package separately. Happy to do this. libxev is a zig project and while its capable of generating a shared library any zig project wants to integrate directly with the zig code at this point in time the ecosystem and zig's package management is too immature to have dedicated zig packages. > Fedora prefers gcc unless for technical reasons it cannot be used. zig relies on clang for its C integration
Some updates, There's an open PR for enabling dynamic linking of highway https://github.com/ghostty-org/ghostty/pull/6668 I had some time to check on providing shared libs for glslang and SPIRV-Cross on Fedora, the upstreams do provide build configurations for this that seems to work. I've sent an email to the packagers at glslang-maintainers to ask about providing shared libs, and tested compiling shared libs from source to link against. I've looked at writing a specfile to package SPIRV-Cross, might have time in a week or two to start a package review for it.