tabby-terminal: init at 1.0.216

[geodic]

Added Tabby, an electron-based terminal emulator that proclaims itself "A terminal for a more modern age".

Homepage: https://tabby.dev

Fixes #233509

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[pluiedev]

I don't think this is necessary. From a glance, electron-rebuild supports the --dist-url option which should make it avoid downloading Electron headers all the same.

[geodic]

I tried to set the --dist-url to a file url, but it throws an error saying that it only supports HTTP(S)

[pluiedev]

Ah, so it wants a web URL... Never mind then, maybe someone else would have a better idea

[geodic]

@pluiedev, I fixed most of the changes you suggested.

[lucasew]

Please join all the commits but the first. The first is ready.

[geodic]

After 3 hours of patching the dependencies, I finally got it to run with electron 32 🥳 🎊. @pluiedev, mind reviewing it again?

[geodic]

Looks like tabby just released a new version. It doesn't build because the patch files need to be changed. I have started a PR upstream to use electron 32. Until then, lets just stick to 1.0.215.

[geodic]

nixpkgs-reviewd workflow finished

Status and logs: https://github.com/nixosbrasil/nixpkgs-reviewd/actions/runs/12504723531

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 368048

x86_64-linux

⏩ 2 packages marked as broken and skipped:
⏩ 1 package blacklisted:
❌ 11 packages failed to build:

Looks like Python 3.13 is breaking a lot of packages.

[geodic]

I agree with @pluiedev; patching this many dependencies didn't sit right with me either. I already opened a PR on the upstream repo. If it doesn't get resolved within ~2 weeks, then we could use this as a temporary solution.

[lucasew]

I agree with @pluiedev; patching this many dependencies didn't sit right with me either. I already opened a PR on the upstream repo. If it doesn't get resolved within ~2 weeks, then we could use this as a temporary solution.

That's the way.

Maintaining packages that need patch updating at each bump and can't be patched with substituteInPlace and friends are a big pain in the butt to maintain later.

Electron packages in general are also more hacky to package than normal.

[lucasew]

Ideally, tho, all packages should be updateable by only using the update script system but as life is not a strawberry we can't count on this every time.

[geodic]

@lucasew, I got the changes merged into upstream. Should we wait for a new release (possibly could take months) or just build from that commit and version it 1.0.216+1e44d8c?

[lucasew]

As it's an application and no other PR depends on it i'd prefer to wait for a release.

You can write it in a way that now it points to latest version with this patch merged but setup the update script to update on releases instead of commits (nix-update-script or gitUpdater) so it can be properly bot-updated on the next release and see if someone takes a look and merges or play it safe and wait for the release then bump the PR.

It depends on your sisyphus tolerance.

[geodic]

The maintainer of the project said that it will take a relatively long time to push an update as v1.0.216 brought a lot of problems with SSH, and that he needs to fix them before pushing a new release. Therefore, I think I'll go with option #1 🙂

[geodic]

@lucasew, if you have time, could you help me write an update script for this package? It looks to be considerably complicated as we have to manually update all the hashes in pkg-hashes.json, which the stock update script(s) don't seem to understand.

[lucasew]

@lucasew, if you have time, could you help me write an update script for this package? It looks to be considerably complicated as we have to manually update all the hashes in pkg-hashes.json, which the stock update script(s) don't seem to understand.

For npm, at least, there is a bug where it doesn't update the package-lock.json hashes in some packages and some upstreams didn't care enough about the issue to fix, or let us fix it, then I setup a tool to update them at fetch time. Basically a postFetch in src. IDK how it would look for yarn tho.

How do you generate this JSON file? I found a way to run a specific script on a update script, which I use in flet-client-flutter to update the json lockfile.

[geodic]

Currently, I manually create the JSON file. The only difficulty I am having is obtaining the proper hashes for each of the "submodules" (not git) of the app. For context, my script loops through all the "submodules" and creates a Yarn cache for them, sourcing the hash from pkg-hashes.json. Updating the hashes will likely require evaluating each fetchYarnDeps with an empty hash and obtaining the correct one from the nix-build error log.

[geodic]

@lucasew, is it possible to write the update script in a language other than bash, or will it add too much complexity? I don't think that this update script can be accomplished using a limited language like bash.

[lucasew]

@lucasew, is it possible to write the update script in a language other than bash, or will it add too much complexity? I don't think that this update script can be accomplished using a limited language like bash.

Custom update scripts are kinda tricky to make. BTW nix-update is made with python AFAIK.