[SOLVED] ghostty-git and zig issues

grail69 · 2025-04-09 11:24:16

For some time I have been running into the following error when trying to update ghostty-git:

==> Starting prepare()...
Fetching: git+https://codeberg.org/atman/zg#4a002763419a34d61dcbb1f415821b83b9bf8ddc
Fetching: git+https://github.com/TUSF/zigimg#31268548fe3276c0e95f318a6c0d2ab10565b58d
Failed to fetch: git+https://github.com/TUSF/zigimg#31268548fe3276c0e95f318a6c0d2ab10565b58d
==> ERROR: A failure occurred in prepare().
    Aborting...
error: failed to build 'ghostty-git-1.1.2.r262.gefc1b10-1':
error: packages failed to build: ghostty-git-1.1.2.r262.gefc1b10-1

So the error output is rather unintuitive, but I can run the zig fetch on its own:

zig fetch git+https://github.com/TUSF/zigimg#31268548fe3276c0e95f318a6c0d2ab10565b58d
/home/grail/.cache/zig/tmp/56334936ac30b45c/build.zig.zon:2:14: error: expected string literal
    .name = .zigimg,
             ^~~~~~

So after reading this I went to the git page and found that the build.zig.zon does indeed not quote the value:

current -- .name = .zigimg,

desired -- .name = ".zigimg",

It turns out this is not the only download that has this issue as I did try others that are in the fetch shell script file.

Now another little side note on the zigimg git page is how it has been updated for zig 0.14.0, while our current version is 0.13.0

I guess my question is, has anyone else been able to get this package to update?
And if so, could you please share your wisdom?

Last edited by grail69 (2025-04-10 16:12:08)

twelveeighty · 2025-04-09 14:41:48

That PKGBUILD looks pretty bad to me: it's executing a script in prepare(), which is where your error occurs:

PKGBUILD wrote:

prepare() {
	cd "$_pkgbase"
	ZIG_GLOBAL_CACHE_DIR="$srcdir/zig-global-cache/" ./nix/build-support/fetch-zig-cache.sh
}

What the hell is that script doing?

Edit: if this "zig" business is a dependency, it should be either another package, OR this PKGBUILD should be a split package.

Last edited by twelveeighty (2025-04-09 14:44:13)

loqs · 2025-04-09 20:05:12

Have you looked at https://github.com/ghostty-org/ghostty/discussions/6732?

mackin_cheese · 2025-04-09 21:11:17

this PKGBUILD is all messed up.

Last edited by mackin_cheese (2025-04-09 22:01:30)

loqs · 2025-04-09 22:13:34

mackin_cheese wrote:

this PKGBUILD is all messed up.

Provide constructive suggestions to improve the current PKGBUILD on https://aur.archlinux.org/packages/ghostty-git?

mackin_cheese · 2025-04-09 22:20:53

loqs wrote:

mackin_cheese wrote:
this PKGBUILD is all messed up.
Provide constructive suggestions to improve the current PKGBUILD on https://aur.archlinux.org/packages/ghostty-git?

Yep, just flagged it as out of date.

loqs · 2025-04-09 22:24:11

mackin_cheese wrote:

Yep, just flagged it as out of date.

I had more in mind you contributed a fixed PKGBUILD.

mackin_cheese · 2025-04-09 22:25:27

loqs wrote:

mackin_cheese wrote:
Yep, just flagged it as out of date.
I had more in mind you contributed a fixed PKGBUILD.

I been trying my best working on it. I spent two hours already and it's killing me lol

loqs · 2025-04-09 22:33:52

Have you looked at the PKGBUILD for https://archlinux.org/packages/extra/x86_64/ghostty/ as a reference point? If it would help I can look at what issues you have left.

yataro · 2025-04-10 05:33:18

Ghostty master needs Zig 0.14.0, while the one available in the extra is 0.13.0. I think Zig 0.14.0 is available in AUR as "zig-bin".
PKGBUILD looks fine for me, I don't think it's messed up.

twelveeighty wrote:

What the hell is that script doing?

It fetches source-dependencies, yeah it should be handled in "source" (like how extra/zls does) but it's fine by me. Probably there's too many dependencies and no tolling to convert them into "source" notation. BTW extra/ghostty does nearly the same.

Lone_Wolf · 2025-04-10 08:25:30

AUR ghostty-git

ZIG_GLOBAL_CACHE_DIR="$srcdir/zig-global-cache/" ./nix/build-support/fetch-zig-cache.sh

repo ghostty

	export ZIG_GLOBAL_CACHE_DIR="$srcdir/zig-global-cache/"
	zig build --fetch

Those 2 are very different.

I agree with logs, start with the repo ghostty PKGBUILD and adapt it to become a -git package.

yataro · 2025-04-10 08:54:57

Those 2 are very different.

Would disagree, the only difference is that repo ghostty uses just "zig build --fetch", while "nix/build-support/fetch-zig-cache.sh" will fetch dependencies one by one using "zig fetch", to avoid https://github.com/ziglang/zig/issues/20976 bug.
There's no real difference, "fetch-zig-cache.sh" is a mere workaround to fix network-isolated builds. Of course there's no need for this workaround with Arch Linux

seth · 2025-04-10 11:48:34

Afaiu this is also not the problem - the ghostty version in the current git master relies on a zig version that's incompatible w/ the one in the repos as build dependency, so the fix for the package is to add a versioned zig as make dependency (which is currently only fulfilled by the upstream build in the AUR or probably later the repo version) and the zig developers need to be slapped over the head for this kind of backwards incompatibility.

yataro · 2025-04-10 13:04:19

Yes, I pointed to real problem in my first post, good addition about versioned dependency though

seth wrote:

and the zig developers need to be slapped over the head for this kind of backwards incompatibility.

Can't help but derail discussion from original problem further
I strongly disagree with this, Zig is still in development and the fact that things are going to be broken was announced long time ago. I think they need to be pet over the head for this ! They decided to break things and not be encumbered by API and tool compatibility, all the "ugly stuff and many ways to do the same thing just to keep compatibility with older version" is a thing that C with C++ suffer a lot. Zig don't want to be like C.
As far as I know, Zig explicitly states that it should not be used for production yet. It was a bold decision for Arch Linux to include Zig in the repos, I remember how long it took to finally get 0.13.0 (and llvm 19) in the repos, and now after 0.14.0 was released a month ago, Arch is still on 0.13.0.

seth · 2025-04-10 13:45:12

OT sparring:

Zig is still in development

If it wasn't, that bitrot would get dropped into the AUR

It was a bold decision for Arch Linux to include Zig in the repos

It's build dependency for a couple of repo-packages…

Zig don't want to be like C.

You mean being a reliably heavyweight for decades?
The various C compilers (and notably gcc) *have* at times discarded (non-standard) legacy behavior, just not this way.

Randomly breaking external interfaces from one version to another is a very gnome approach and I cannot constantly chastize A but give B a pass.
Their claim is

Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

I don't see anything like "PoC, experimental project, no way ready for productive use, stay away, for internal use only!"

Everybody gets to do as they like, but if you constantly change your mind from one moment to another, people will stop playing with you and move their investments to China.
Because no tariff ever overcomes complete unpredictability.

---

For a more serious reponse, though:

not be encumbered by API and tool compatibility

Yes, but the usual way is to tag a feature as deprecated and yell at everybody that "this is gonna break next year, so fix your code".
This way you can have your cake and eat it without making a ruckus.

yataro · 2025-04-10 15:05:50

If it wasn't, that bitrot would get dropped into the AUR

I mean still in kinda immature phase of development

Randomly breaking external interfaces from one version to another is a very gnome approach and I cannot constantly chastize A but give B a pass.

Fair enough, but with Zig those breaking changes usually have a reasonably cause.
You may not be familiar with it, but when you develop something non-trivial with Zig, it probably will eventually take you into Zig development, due to various reasons: documentation, bugs, etc. Zig is clearly not ready for ordinary programmer workflow.

You mean being a reliably heavyweight for decades?
The various C compilers (and notably gcc) *have* at times discarded (non-standard) legacy behavior, just not this way.

Lol you got me with "reliably heavyweight for decades", I think this will be achieved, someday. I believe Zig doesn't want to follow this gcc path, one of the goals is "only one obvious way to do things", and legacy APIs and interfaces don't fit well into this, at least at the current stage of development.

I don't see anything like "PoC, experimental project, no way ready for productive use, stay away, for internal use only!"
Everybody gets to do as they like, but if you constantly change your mind from one moment to another, people will stop playing with you and move their investments to China.
Because no tariff ever overcomes complete unpredictability.

I wish Zig would be more clear about his current state, it's indeed not explicit as I said before. As for "should not be used for production" this is what Andrew Kelley (designed and lead developer of Zig) said once or twice, I can say you will get this idea really soon when you start using Zig.
As for breaking changes, yeah this can turn off many folks, but it's very hard to design something perfectly form day one.
I don't think Zig is afraid to scare anyone away, time will pass, 1.0 will be out (or not, who knows? maybe WW3 will come sooner), it will be ready for investments like big production software.

Yes, but the usual way is to tag a feature as deprecated and yell at everybody that "this is gonna break next year, so fix your code".
This way you can have your cake and eat it without making a ruckus.

If there were such a thing, it would require a lot of code maintenance to keep legacy things working, and with Zig case, when such changes are large and frequent, it will escalate really fast. At the moment there is no goal to not break someone's workflow yet, will see when 1.0 is out

All these Zig issue like unstability and breakage is a byproduct of pre 1.0 software.
Was it a wise decision to use pre 1.0 tool for "serious" software like ghostty? Maybe yes, maybe no, but I can certainly say that Zig has something that makes people use it despite stability issues.

grail69 · 2025-04-10 16:10:15

Whilst I do agree with some of the OT rhetoric, it would seem the helper for me was to install zig-bin and now the install works.

I will say that to make a nuanced change about what needs quotes or not and then not give a couple of versions grace is a bit poor

Thanks all for the feedback and help.

Arch Linux

#1 2025-04-09 11:24:16

[SOLVED] ghostty-git and zig issues

#2 2025-04-09 14:41:48

Re: [SOLVED] ghostty-git and zig issues

#3 2025-04-09 20:05:12

Re: [SOLVED] ghostty-git and zig issues

#4 2025-04-09 21:11:17

Re: [SOLVED] ghostty-git and zig issues

#5 2025-04-09 22:13:34

Re: [SOLVED] ghostty-git and zig issues

#6 2025-04-09 22:20:53

Re: [SOLVED] ghostty-git and zig issues

#7 2025-04-09 22:24:11

Re: [SOLVED] ghostty-git and zig issues

#8 2025-04-09 22:25:27

Re: [SOLVED] ghostty-git and zig issues

#9 2025-04-09 22:33:52

Re: [SOLVED] ghostty-git and zig issues

#10 2025-04-10 05:33:18

Re: [SOLVED] ghostty-git and zig issues

#11 2025-04-10 08:25:30

Re: [SOLVED] ghostty-git and zig issues

#12 2025-04-10 08:54:57

Re: [SOLVED] ghostty-git and zig issues

#13 2025-04-10 11:48:34

Re: [SOLVED] ghostty-git and zig issues

#14 2025-04-10 13:04:19

Re: [SOLVED] ghostty-git and zig issues

#15 2025-04-10 13:45:12

Re: [SOLVED] ghostty-git and zig issues

#16 2025-04-10 15:05:50

Re: [SOLVED] ghostty-git and zig issues

#17 2025-04-10 16:10:15

Re: [SOLVED] ghostty-git and zig issues

Board footer