https://sw.kovidgoyal.net/kitty/build/#notes-for-linux-macos-packagers recommends to split kitty into three packages with kitty-shell-integration being the one that includes some files useful for the shell integration. We already use kitty.terminfo in Nixpkgs instead of kitty-terminfo but we can't use kitty.shell-integration instead of kitty-shell-integration because shell-integration is not a valid shell variable name. I named it kitty.shell_integration instead. This package can then be used by a future kitty nixos module that still needs to be created. Without this commit, kitty would modify the user's ~/.bashrc when using bash.
Currently compile fails on Darwin on command
running "perl" "./Configure" "--prefix=/private/tmp/nix-build-wezterm-20210814-124438-54e29167.drv-0/source/target/aarch64-apple-darwin/release/build/openssl-sys-90b3c73e9c998931/out/openssl-build/install" "no-dso" "no-shared" "no-ssl3" "no-unit-test" "no-comp" "no-zlib" "no-zlib-dynamic" "no-md2" "no-rc5" "no-weak-ssl-ciphers" "no-camellia" "no-idea" "no-seed" "darwin64-arm64-cc" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC"
with
`Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }'
This commit fixes this issue.
Terminator is currently wrapped twice, which makes the python hook use a
wrapped executable name to set argv[0]. As a result, Terminator can't be
matched to its desktop entry and fails to group correctly in e.g. the GNOME app
launcher. Ensuring we only wrap the executable once solves this.
stimuliFile would get rebuild with every change in version, since the
stimulusGenerator derivation would depend on the version string. Since
the script often doesn't change between releases, this causes
unnecessary rebuilds and cache duplication.
Additionally we add a test to passthru which checks if the hash of the
script is still up to date: By making its name depend on the version
string, it'll get rebuild on every version change, even if the hash
stays the same. This way we can detect new hash mismatches.
foot's upstream has abandoned the approach of using a custom terminfo
install location and setting TERMINFO, but still supports it. For us
this has eliminated the need to build the foot terminfo files manually,
somehow which is appreciated.
We preserve our current approach: Install terminfo files to the terminfo
output and set TERMINFO to that store path instead of propagating the
output for user env insatllations.
Change logs:
* https://codeberg.org/dnkl/foot/releases/tag/1.9.1
* https://codeberg.org/dnkl/foot/releases/tag/1.9.2
* aminal: remove
aminal was renamed to darktile, which was newly added by #136326. there's no
backwards-compatible executable link, so throw with that info.
* Update pkgs/top-level/aliases.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
https://codeberg.org/dnkl/foot/releases/tag/1.9.0
Main change requiring intervention from our side is the new alternative
terminfo install location used by foot in order to coexist with ncurses'
install location.
We want to keep using the normal terminfo install location:
* ncurses and foot have separate store paths so there won't be an
actual conflict
* buildEnv etc. can deal with file conflicts when building the
system path
Since foot now sets the TERMINFO environment variable to its terminfo
directory, we can stop installing foot's terminfo globally always (via
propagated-user-env-package) instead `foot.terminfo` now only needs to
be installed on remote systems were you want to have the proper terminfo
for foot.
We'll need to see if this works reliably in the future. NixOS sets
TERMINFO_DIRS, so there may be packages that have been patched to
respect that, but not TERMINFO.
https://github.com/kovidgoyal/kitty/releases/tag/v0.23.1
Add the new dependencies required for building the documentation.
Also run the postInstall hook at the end of the installPhase instead of in the middle.
The URL of the changelog has changed slightly. The old one still works because of a redirect but it's better to use the new one directly.
* Change from fetchzip to fetchFromGitea
* Set `mesonBuildType` instead of supplying the `--build-type=`
argument in `mesonFlags` as the build type option will be
repeated.
* (hyper): 3.0.2 -> 3.1.1 and fix for desktop files
* hyper: fix deb hash
Fixes ownload of old cached deb package and addition of "new" dependencies.
* hyper: move desktopItem into mkDerivation
* hyper: Simpler fix for the desktopItem issue
- Subsituting the erronous path for the executable name
- Cleanup of the function args
* needs PKG_CONFIG_FOR_BUILD
* in the non-native case we need wayland-scanner (build) and
wayland-protocols (host) separately
* ar needs targetPrefix as well
* See also https://codeberg.org/dnkl/foot/pulls/607
* propagated-user-env-packages is undocumented unfortunately, but
ensure that if you add foot(.out) to your `systemPackages` or
install it via `nix-env`, the terminfo output is also installed
automatically.
* Resolves#125390.
To be able to do LTO with clang we need the LTO-capable llvm-ar from
libllvm.out (== llvmPackages.llvm) which contains a superset of the llvm
bintools. This used to be passed through from stdenv.cc.cc as llvm, but
has been renamed to libllvm in 7869d16545.
llvm-ar would be in stdenv.cc.bintools.bintools provided that we are
using a clang stdenv which uses lld as its linker. In the future we could
thus make this inclusion conditional on stdenv.hostPlatform.linker.
Note that the build of foot.tests still fails, pending resolution of #123361.
(It was requested by them.)
I left one case due to fetching from their personal repo:
pkgs/desktops/pantheon/desktop/extra-elementary-contracts/default.nix
I want to support this in the future. Since I sometimes forget to check
clang compilation when doing a version bump, there has been regression
to this in the past. Let's prevent this by checking compilation with the
default clang version in nixpkgs and the latest clang as well.
The way we need to do PGO builds for foot changed. The gcc build was
unaffected by this, but has been updated to the new instructions. For
clang using the outdated introduction meant that the PGO build was
broken when using clang for building foot with PGO enabled.
This has been fixed by updating to the new build instructions for both
gcc and clang when using PGO:
https://codeberg.org/dnkl/foot/pulls/420
foot.override { stdenv = llvmPackages_11.stdenv; } now works as expected.
