[Bug 2334903] Review Request: ghostty - Terminal emulator in Zig

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=2334903

Fabio Valentini <decathorpe@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|nobody@xxxxxxxxxxxxxxxxx    |decathorpe@xxxxxxxxx
                 CC|                            |decathorpe@xxxxxxxxx
              Flags|                            |fedora-review?
             Status|NEW                         |ASSIGNED



--- Comment #3 from Fabio Valentini <decathorpe@xxxxxxxxx> ---
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.


-- 
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2334903

Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202334903%23c3

-- 
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux