Question: patches = [ # https://github.com/neomutt/neomutt/issues/3773#issuecomment-1493295144 ./fix-open-very-large-mailbox.patch <ins> (fetchpatch { name = "disable-incorrect-tests.patch"; url = "https://github.com/neomutt/neomutt/pull/3933.patch"; hash = "sha256-Plei063T8XyXF4/7/nAb6/4OyXz72vBAXHwls9WL1vM="; excludes = [".github/workflows/macos.yml"]; }) </ins> ]; buildInputs = [

Steps to reproduce the behavior: on darwin aarch64 see Since neomutt is broken on darwin-aarch64. See the CI output: Tangent: is it normal that a failing CI build wasn't marked as a failed check, but rather just ignored? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Broken on Darwin x86-64 as well.
seems to work — I can't tell whether they are running the tests, though, or not. Here are the failing tests.
Looking at the latest comment on the already closed issue here: This issue could use some love. Neomutt is broken on MacOS and it looks like it's the derivation, not upstream.
I can't install neomutt on MacOS with home-manager too
The failing tests were disabled upstream in . I tried simply upgrading to HEAD with the following patch, and the succeeded (darwin-aarch64):
( That's a different bug which you should probably raise separately.)
Unfortunately, the latest fix didn't work for my Intel Mac, some tests are failing for me. I tested using because I didn't know how to do overrides from the CLI
Yes, the failure on should be a separate bug (and could probably be fixed by putting into ).


Question: <ins> { stdenv, lib, fetchFromGitHub, qmake, qtbase, wrapQtAppsHook }: stdenv.mkDerivation { pname = "selectdefaultapplication"; version = "unstable-2021-08-12"; src = fetchFromGitHub { owner = "sandsmark"; repo = "selectdefaultapplication"; rev = "c752df6ba8caceeef54bcf6527f1bccc2ca8202a"; sha256 = "C/70xpt6RoQNIlAjSJhOCyheolK4Xp6RiSZmeqMP4fw="; }; nativeBuildInputs = [ qmake wrapQtAppsHook ]; buildInputs = [ qtbase ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp selectdefaultapplication $out/bin install -Dm644 -t "$out/share/applications" selectdefaultapplication.desktop install -Dm644 -t "$out/share/icons/hicolor/48x48/apps" selectdefaultapplication.png runHook postInstall ''; meta = with lib; { description = "A very simple application that lets you define default applications on Linux in a sane way"; homepage = "https://github.com/sandsmark/selectdefaultapplication"; maintainers = with maintainers; [ nsnelson ]; license = licenses.gpl2; platforms = platforms.linux; }; } </ins>

Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!


Question: stdenv.mkDerivation rec { pname = "spirv-headers"; <del> version = "unstable-2021-08-11"; </del> <ins> version = "1.2.198.0"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Headers"; <del> rev = "e71feddb3f17c5586ff7f4cfb5ed1258b800574b"; sha256 = "sha256-9m0EBcgdya+KCNJHC3x+YV2sXoSNToTcgDkpeKzId6U="; </del> <ins> rev = "sdk-${version}"; sha256 = "sha256-cdEiRSCoX0New8ecUh7UTDz/is2v29zhf6Il2N1j3mw="; </ins> }; nativeBuildInputs = [ cmake ];

name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.


Question: # NB: migration must be performed prior to pre-start, else we get the failure message! preStart = '' ipfs repo fsck # workaround for BUG #4212 (https://github.com/ipfs/go-ipfs/issues/4214) <del> ipfs --local config Addresses.API ${cfg.apiAddress} ipfs --local config Addresses.Gateway ${cfg.gatewayAddress} </del> '' + optionalString cfg.autoMount '' ipfs --local config Mounts.FuseAllowOther --json true ipfs --local config Mounts.IPFS ${cfg.ipfsMountDir}

default: cc Until then, just edit manually.
Remember you can do this too: = [ "/ip4/0.0.0.0/tcp/4001" "/ip6/::/tcp/4001" ]; It seems reasonable to have this default, however, since the nixos module has no way of getting the daemon to reset options when the user removes an explicit option from Incidentally, some config needs special handling, since it can't be set without re-initializing the leveldb, etc. I don't like the idea of having to duplicate every default setting into a , but I guess there's no other way until the ipfs devs make the daemon's config less stateful. I would prefer they move this type of runtime config into command-line args whose absence indicates that defaults should be used. Perhaps we should file that upstream.


Question: }); luadbi-mysql = super.luadbi-mysql.override({ <del> extraVariables = '' -- Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR='${pkgs.libmysqlclient}/include/mysql'; MYSQL_LIBDIR='${pkgs.libmysqlclient}/lib/mysql'; ''; </del> <ins> extraVariables = { # Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR="${pkgs.libmysqlclient}/include/mysql"; MYSQL_LIBDIR="${pkgs.libmysqlclient}/lib/mysql"; }; </ins> buildInputs = [ pkgs.mysql.client pkgs.libmysqlclient

Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?


Question: }); luadbi-mysql = super.luadbi-mysql.override({ <del> extraVariables = '' -- Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR='${pkgs.libmysqlclient}/include/mysql'; MYSQL_LIBDIR='${pkgs.libmysqlclient}/lib/mysql'; ''; </del> <ins> extraVariables = { # Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR="${pkgs.libmysqlclient}/include/mysql"; MYSQL_LIBDIR="${pkgs.libmysqlclient}/lib/mysql"; }; </ins> buildInputs = [ pkgs.mysql.client pkgs.libmysqlclient

I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.


Question: }); luadbi-mysql = super.luadbi-mysql.override({ <del> extraVariables = '' -- Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR='${pkgs.libmysqlclient}/include/mysql'; MYSQL_LIBDIR='${pkgs.libmysqlclient}/lib/mysql'; ''; </del> <ins> extraVariables = { # Can't just be /include and /lib, unfortunately needs the trailing 'mysql' MYSQL_INCDIR="${pkgs.libmysqlclient}/include/mysql"; MYSQL_LIBDIR="${pkgs.libmysqlclient}/lib/mysql"; }; </ins> buildInputs = [ pkgs.mysql.client pkgs.libmysqlclient

Describe the bug I have neovim in my systemPackages, I did and today and it stuck at building luajit: To Reproduce Steps to reproduce the behavior: to Expected behavior The system should upgrade properly. Additional context Output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kj): nixpkgs: Maintainer information:
Possible fix is in . There was already an open issue about it () but from an unclear reason people have reached the conclusion it was fixed on latest master.
Oh I meant , not .
Well, I agree with that conclusion. For me, on the build is broken with the error above and on current master it isn't. EDIT: note that the channels lag behind, usually less than a couple days, but sometimes we get a week or two due to some harder regression.
Yea right. For me on NixOS I tried with the nixpkgs-unstable channel and could install successfully. The nixos-unstable still fails though.


Question: cfg = config.services.garage; toml = pkgs.formats.toml { }; configFile = toml.generate "garage.toml" cfg.settings; <ins> anyHasPrefix = prefix: strOrList: if isString strOrList then hasPrefix prefix strOrList else any ({ path, ... }: hasPrefix prefix path) strOrList; </ins> in { meta = { doc = ./garage.md; <del> maintainers = [ ]; </del> <ins> maintainers = [ maintainers.mjm ]; </ins> }; options.services.garage = {

Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.


Question: (fetchNuGet { pname = "Nito.AsyncEx.Tasks"; version = "5.1.2"; sha256 = "11wp47kc69sjdxrbg5pgx0wlffqlp0x5kr54ggnz2v19kmjz362v"; }) (fetchNuGet { pname = "Nito.Collections.Deque"; version = "1.1.1"; sha256 = "152564q3s0n5swfv5p5rx0ghn2sm0g2xsnbd7gv8vb9yfklv7yg8"; }) (fetchNuGet { pname = "Nito.Disposables"; version = "2.2.1"; sha256 = "1hx5k8497j34kxxgh060bvij0vfnraw90dmm3h9bmamcdi8wp80l"; }) <del> (fetchNuGet { pname = "NLog"; version = "5.2.5"; sha256 = "02fybqi9d7czz3jmhmgb8wia2hpjj5hmcnij6zsgs69rkv6hf9j0"; }) (fetchNuGet { pname = "NLog.Extensions.Logging"; version = "5.3.5"; sha256 = "0jzfqa12l5vvxd2j684cnm29w19v386cpm11pw8h6prpf57affaj"; }) (fetchNuGet { pname = "NLog.Web.AspNetCore"; version = "5.3.5"; sha256 = "0li0sw04w0a4zms5jjv1ga45wxiqlcvaw8gi0wbhiifrdzz5yckb"; }) </del> <ins> (fetchNuGet { pname = "NLog"; version = "5.2.7"; sha256 = "1gq5l9qv3vnl0rvxa110bbqsq6m43h8h912xijqab1hsjdpb46q3"; }) (fetchNuGet { pname = "NLog.Extensions.Logging"; version = "5.3.7"; sha256 = "1hv2v4hqqq86vjvxa0cbk4klaii8n8h1wjrlsfzbp9nnxnzg9pzi"; }) (fetchNuGet { pname = "NLog.Web.AspNetCore"; version = "5.3.7"; sha256 = "1jifwnvkfi3jankan7543q985gzrywddvajlqrf573aa2dbp5n1f"; }) </ins> (fetchNuGet { pname = "NuGet.Frameworks"; version = "6.5.0"; sha256 = "0s37d1p4md0k6d4cy6sq36f2dgkd9qfbzapxhkvi8awwh0vrynhj"; }) (fetchNuGet { pname = "protobuf-net"; version = "3.2.26"; sha256 = "1mcg46xnhgqwjacy6j8kvp3rylpi26wjnmhwv8mh5cwjya9nynqb"; }) (fetchNuGet { pname = "protobuf-net.Core"; version = "3.2.26"; sha256 = "1wrr38ygdanf121bkl8b1d4kz1pawm064z69bqf3qbr46h4j575w"; })

Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update


Question: meta.homepage = "https://github.com/vim-scripts/align/"; }; <ins> alpha-nvim = buildVimPluginFrom2Nix { pname = "alpha-nvim"; version = "2022-04-22"; src = fetchFromGitHub { owner = "goolord"; repo = "alpha-nvim"; rev = "4781fcfea5ddc1a92d41b32dc325132ed6fce7a8"; sha256 = "03i75403lskpgaqv7xp5hk4v6kqb0sv15ciil9jyj735ylhry3qq"; }; meta.homepage = "https://github.com/goolord/alpha-nvim/"; }; </ins> aniseed = buildVimPluginFrom2Nix { pname = "aniseed"; version = "2022-05-14";

Project description describe the project a little is a highly configurable dashboard for Neovim. It's an alternative to Metadata homepage URL: source URL: license: MIT platforms: Anything that can run Neovim, I would assume


Question: } ++ (lib.mapAttrsToList (vhost: conf: { virtualHosts.${vhost} = { locations = { <ins> "/".extraConfig = '' # pass information via X-User and X-Email headers to backend, requires running with --set-xauthrequest flag proxy_set_header X-User  $user; proxy_set_header X-Email $email; # if you enabled --cookie-refresh, this is needed for it to work with auth_request add_header Set-Cookie $auth_cookie; ''; </ins> "/oauth2/auth" = let maybeQueryArg = name: value: if value == null then null

OAuth2 Proxy's Nginx plugin used to forward and headers to downstream programs. This stopped working after I updated on unstable channel, which is potentially related to or . Steps to reproduce the behavior: up OAuth2 Proxy + Nginx up of header name . does not recognize the session More simply: up OAuth2 Proxy + Nginx or something similar the headers — and used to be present, but not anymore and are passed to downstream servers under Nginx. I have I went on upgrade of nixpkgs unstable from sometime late January to a few hours ago, which is what led me to the two PRs mentioned above. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
are you able to play around a bit and confirm if the changes mentioned introduced this regression?
yes. I can't really pin-point to what exactly since there were a lot of changes. Instead, I just have a local fork from (prior to the changes mentioned in the PRs above).
I have a pretty good idea what it could be.
Can you give a try? I didn't test it yet, so it could completely break everything and be completely insecure, just as warning.
fantastic work please let us know how it goes
Sorry for the late reply, I haven't been able to have time to test it out. Now that I do, it seems like has been converted to . This won't be an easy find-and-replace for me to try in my setup, so I will have to find some time to do proper cleanup.


Question: basic.fail(f"grep -q @PSK_SPECIAL@ {config_file}") basic.succeed(f"grep -q @PSK_MISSING@ {config_file}") basic.succeed(f"grep -q P@ssowrdWithSome@tSymbol {config_file}") <ins> basic.succeed(f"grep -q 'PassowrdWith&symbol' {config_file}") </ins> with subtest("WPA2 fallbacks have been generated"): assert int(basic.succeed(f"grep -c sae-only {config_file}")) == 1

Using the NixOS option to specify the configuration, I noticed that if an ampersand () is present, the password field of isn't generated correctly. the option along with the option. The environment file should contain . the field "password= the content of . The password is decrypted to . The password shuld be decrypted to . The global variable's name shouldn't show. Here are some nix code that is tested to trigger this issue instead. The environment file: Generated in the aforementioned path, note how the field is erroneous. A hack to get around this is to split your password in two halves, and put the & in plain text. . Of course I would still like to see this get fixed :p Thank you for maintaining this module and reading this issue ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It looks like a missed a metacharacter: I don't know if escaping it as works, or it interacts somehow with other systemd/shell/nix metacharacters. I lost counts of how many level of escaping we are in. I hope to get rid of all of this nonsense with , but next release of wpasupplicant is taking forever.
Done in The fix should be in NixOS 24.05.


Question: <ins> import ./make-test.nix ({ pkgs, ... }: let track = pkgs.fetchurl { # Sourced from http://freemusicarchive.org/music/Blue_Wave_Theory/Surf_Music_Month_Challenge/Skyhawk_Beach_fade_in # License: http://creativecommons.org/licenses/by-sa/4.0/ name = "Blue_Wave_Theory-Skyhawk_Beach.mp3"; url = https://freemusicarchive.org/file/music/ccCommunity/Blue_Wave_Theory/Surf_Music_Month_Challenge/Blue_Wave_Theory_-_04_-_Skyhawk_Beach.mp3; sha256 = "0xw417bxkx4gqqy139bb21yldi37xx8xjfxrwaqa0gyw19dl6mgp"; }; defaultCfg = rec { user = "mpd"; group = "mpd"; dataDir = "/var/lib/mpd"; musicDirectory = "${dataDir}/music"; }; defaultMpdCfg = with defaultCfg; { inherit dataDir musicDirectory user group; enable = true; }; musicService = { user, group, musicDirectory }: { description = "Sets up the music file(s) for MPD to use."; requires = [ "mpd.service" ]; after = [ "mpd.service" ]; wantedBy = [ "default.target" ]; script = '' mkdir -p ${musicDirectory} && chown -R ${user}:${group} ${musicDirectory} cp ${track} ${musicDirectory} chown ${user}:${group} ${musicDirectory}/$(basename ${track}) ''; }; mkServer = { mpd, musicService, }: { boot.kernelModules = [ "snd-dummy" ]; sound.enable = true; services.mpd = mpd; systemd.services.musicService = musicService; }; in { name = "mpd"; meta = with pkgs.stdenv.lib.maintainers; { maintainers = [ emmanuelrosa ]; }; nodes = { client = { config, pkgs, ... }: { }; serverALSA = { config, pkgs, ... }: (mkServer { mpd = defaultMpdCfg // { network.listenAddress = "any"; extraConfig = '' audio_output { type "alsa" name "ALSA" mixer_type "null" } ''; }; musicService = with defaultMpdCfg; musicService { inherit user group musicDirectory; }; }) // { networking.firewall.allowedTCPPorts = [ 6600 ]; }; serverPulseAudio = { config, pkgs, ... }: (mkServer { mpd = defaultMpdCfg // { extraConfig = '' audio_output { type "pulse" name "The Pulse" } ''; }; musicService = with defaultCfg; musicService { inherit user group musicDirectory; }; }) // { hardware.pulseaudio.enable = true; }; }; testScript = '' my $mpc = "${pkgs.mpc_cli}/bin/mpc --wait"; # Connects to the given server and attempts to play a tune. sub play_some_music { my $server = $_[0]; $server->waitForUnit("mpd.service"); $server->succeed("$mpc update"); my @tracks = $server->execute("$mpc ls"); for my $track (split(/n/, $tracks[1])) { $server->succeed("$mpc add $track"); }; my @added_tracks = $server->execute("$mpc listall"); (length $added_tracks[1]) > 0 or die "Failed to add audio tracks to the playlist."; $server->succeed("$mpc play"); my @status = $server->execute("$mpc status"); my @output = split(/n/, $status[1]); $output[1] =~ /.*playing.*/ or die "Audio track is not playing, as expected."; $server->succeed("$mpc stop"); }; play_some_music($serverALSA); play_some_music($serverPulseAudio); $client->succeed("$mpc -h serverALSA status"); # The PulseAudio-based server is configured not to accept external client connections # to perform the following test: $client->fail("$mpc -h serverPulseAudio status"); ''; }) </ins>

As it stands, the NixOS MPD module runs MPD as a systemd system service. As such it expects that the MPD user account (mpd by default) has control over the audio device. This conflicts with PulseAudio when it's used as a systemd user service (the default configuration). The intent of this change is to extend the MPD module so that it can be configured to run as a systemd user service. The changes remain backwards-compatible so users can continue with a system-wide configuration or go with a per-user config. I have a proof-of-concept of the modified module which I'm currently experimenting with. It can be used in as follows: The result is MPD running within a user slice: [ ] Ability to use a different per user; Probably by providing a option which overrides the other options and simply points to a file in the users home directory (ex. ). [ ] See if it's possible to get realtime scheduling to work. [x] Add NixOS tests. Currently there aren't any. The different options make for numerous potential combinations; I'm to lazy to test all of them manually.
did you ever add support for running mpd as a user service? It looks like just tests in preparation for running it as a user service.
Wow, I forgot all about this. Perhaps because I soon after stopped using MDP. The implementation is still on Github:
An alternative could be to let it talk to pulseaudio over the network. In the past I have used a config in mpd like audio_output { type "pulse" name "pulseaudio" server "127.0.0.1" } and then some config in to allow this access.


Question: opensp = callPackage ../tools/text/sgml/opensp { }; <ins> opentofu = callPackage ../applications/networking/cluster/opentofu { }; </ins> opentrack = libsForQt5.callPackage ../applications/misc/opentrack { }; opentracker = callPackage ../applications/networking/p2p/opentracker { };

Project description OpenTofu is a fork of Terraform, which is no longer under a free license (and should be marked as unfree for releases = 1.6.0). This fork is from the free sources before the license change to a source-available BSL license. Metadata homepage URL: source URL: license: mpl platforms: unix
cc some active maintainers of terraform:
Related issue:
I think it would be a good idea to wait for it to be actually named, see OpenTF is a placeholder name, and at this point OpenTF didn't release an alpha.
Will to take this on later today if nobody else grabs it.
Pull request has been opened, if the current Terraform maintainers are okay with it I can add them to the maintainers section of the new package. Otherwise more than happy to take responsibility for it.


Question: <ins> { invalidateFetcherByDrvHash, fetchgit, ... }: { simple = invalidateFetcherByDrvHash fetchgit { name = "nix-source"; url = "https://github.com/NixOS/nix"; rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a"; sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY="; }; } </ins>

Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See


Question: buildInputs = [ python go cmake <del> (if stdenv.isDarwin then llvmPackages.clang else llvmPackages.clang-unwrapped) llvmPackages.llvm </del> ] ++ stdenv.lib.optional stdenv.isDarwin Cocoa; propagatedBuildInputs = stdenv.lib.optional (!stdenv.isDarwin) rustracerd; patches = [ <del> ./patches/youcompleteme/1-top-cmake.patch </del> ./patches/youcompleteme/2-ycm-cmake.patch ]; <ins> # YCM requires path to external libclang 3.9 # For explicit use and as env variable for ../third_party/ycmd/build.py EXTRA_CMAKE_ARGS="-DEXTERNAL_LIBCLANG_PATH=${llvmPackages.clang.cc}/lib/libclang.${if stdenv.isDarwin then "dylib" else "so"}"; </ins> buildPhase = '' patchShebangs . substituteInPlace plugin/youcompleteme.vim

Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by


Question: { mkDerivation, lib, cmake, xorg, plasma-framework, plasma-wayland-protocols, fetchFromGitLab <del> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff, wayland }: </del> <ins> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff , wayland, plasma-workspace }: </ins> mkDerivation rec { pname = "latte-dock"; <del> version = "unstable-2022-09-06"; </del> <ins> version = "unstable-2023-03-31"; </ins> src = fetchFromGitLab { domain = "invent.kde.org"; owner = "plasma"; repo = "latte-dock"; <del> rev = "cd36798a61a37652eb549d7dfcdf06d2028eddc4"; sha256 = "sha256-X2PzI2XJje4DpPh7gTtYnMIwerR1IDY53HImvEtFmF4="; </del> <ins> rev = "4f93251d8c635c6150483ecb321eb276f34d4280"; sha256 = "sha256-oEfKfsVIAmYgQ7+WyBEQfVpI4IndWhYXWBsJE8bNNyI="; </ins> }; <del> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland ]; </del> <ins> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland plasma-workspace ]; </ins> nativeBuildInputs = [ extra-cmake-modules cmake karchive kwindowsystem qtx11extras kcrash knewstuff ];

When I click on any program in latte-dock, nothing happens. If I run in a terminal, I get these warnings:
I figured out the issue is that latte-dock code fails to detect the version of plasma desktop. For that they parse the output of . I made a dirty test with hardcoded value in and which works around the issue. What is the correct solution to have latte-dock detect the version of plasma? Does it not have access to plasmashell path? Also I noticed that the command results in a segfault. Is that an issue?
See for more discussion. Would you mind describing how to trigger the issue for a person (such as me) who doesn't use plasma shell nor latte dock and so is unaware of (a) how the thing is supposed to work (b) how to set it up?
Sure. the latte-dock package latte-dock. There will be a in the nix store path/share/applications that should appear in your application launcher. For more verbosity, run will see the default layout for latte-dock appear at the bottom of the screen ! By default it has in my case Firefox, Dolphin, and a clock widget. I don't know if it will show your default browser and file manager instead. will auto-hide if a windows covers its area. app that you open should also appear there (eg. a terminal emulator) on an icon of an app that is not already open should open a new instance on an icon of an app that is already open should show that windows if there is only one. If there are more than one, it should show an option to chose the window. At point 6 or 7 in NixOS currently nothing happens and we get in the log which is due to in latte-dock (see )
Curious. I can't reproduce this. Could you try cleaning latte-dock qml cache () and trying again? [aroun plasmashell -v plasmashell 5.26.4 Segmentation fault (core dumped) Can't reproduce this either with Plasma 5.27.
When running , the issue is still happening for me. The segfault also happens for me in plasma 5.27 on NixOS unstable (inside a VM). !


Question: { mkDerivation, lib, cmake, xorg, plasma-framework, plasma-wayland-protocols, fetchFromGitLab <del> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff, wayland }: </del> <ins> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff , wayland, plasma-workspace }: </ins> mkDerivation rec { pname = "latte-dock"; <del> version = "unstable-2022-09-06"; </del> <ins> version = "unstable-2023-03-31"; </ins> src = fetchFromGitLab { domain = "invent.kde.org"; owner = "plasma"; repo = "latte-dock"; <del> rev = "cd36798a61a37652eb549d7dfcdf06d2028eddc4"; sha256 = "sha256-X2PzI2XJje4DpPh7gTtYnMIwerR1IDY53HImvEtFmF4="; </del> <ins> rev = "4f93251d8c635c6150483ecb321eb276f34d4280"; sha256 = "sha256-oEfKfsVIAmYgQ7+WyBEQfVpI4IndWhYXWBsJE8bNNyI="; </ins> }; <del> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland ]; </del> <ins> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland plasma-workspace ]; </ins> nativeBuildInputs = [ extra-cmake-modules cmake karchive kwindowsystem qtx11extras kcrash knewstuff ];

Which DE are you using? Maybe this happens only in KDE plasma?
NixOS Unstable () with KDE and Radeon graphics. Ok, this seems like a plasma bug, though very weird. Can you provide a stack trace? Here's the short instruction: Install gdb in your system cp . chmod u+w ./plasmashell open plasmashell in your text editor, scroll to the last line, add gdb into it so that it looks like this: (the hash might be different) run You'll be presented with the gdb repl. Run commands and . If you get a segfault, run . Copy the stack trace and paste it here. Also, having your VM would help.
Thank you for the instructions.
Oh sorry.. i forgot to ask you to run in gdb if you get a segfault. That was actually supposed to give you the stack trace. Updated the instruction above. But from the looks of it, there's something wrong with d-bus in your system and this is a plasma bug, not a latte-dock or nix bug. The best course of action for you would be to create an issue in KDE bug tracker and attack system info, stack trace, and other relevant data.
Here is the bt Ok I will try to create an issue in the KDE bug tracker. Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? EDIT: How do I install debug symbols on NixOS?
Are you saying that latte-dock works perfectly well on NixOS on your side, in the current state? Can you share your nix config? It's pretty generic. I have latte-dock in and KDE installed as per wiki: This has worked with Radeon, Nvidia, and Intel graphics. EDIT: How do I install debug symbols on NixOS? This might be tricky. Here are a couple of relevant links. I haven't tried this myself, mind you. P.S. I use X11 only. Scrolled through this thread and didn't find any mentions of whether you test this with Xorg or Wayland.


Question: { mkDerivation, lib, cmake, xorg, plasma-framework, plasma-wayland-protocols, fetchFromGitLab <del> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff, wayland }: </del> <ins> , extra-cmake-modules, karchive, kwindowsystem, qtx11extras, qtwayland, kcrash, knewstuff , wayland, plasma-workspace }: </ins> mkDerivation rec { pname = "latte-dock"; <del> version = "unstable-2022-09-06"; </del> <ins> version = "unstable-2023-03-31"; </ins> src = fetchFromGitLab { domain = "invent.kde.org"; owner = "plasma"; repo = "latte-dock"; <del> rev = "cd36798a61a37652eb549d7dfcdf06d2028eddc4"; sha256 = "sha256-X2PzI2XJje4DpPh7gTtYnMIwerR1IDY53HImvEtFmF4="; </del> <ins> rev = "4f93251d8c635c6150483ecb321eb276f34d4280"; sha256 = "sha256-oEfKfsVIAmYgQ7+WyBEQfVpI4IndWhYXWBsJE8bNNyI="; </ins> }; <del> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland ]; </del> <ins> buildInputs = [ plasma-framework plasma-wayland-protocols qtwayland xorg.libpthreadstubs xorg.libXdmcp xorg.libSM wayland plasma-workspace ]; </ins> nativeBuildInputs = [ extra-cmake-modules cmake karchive kwindowsystem qtx11extras kcrash knewstuff ];

My config is pretty generic too, especially in the VM, I installed NixOS with KDE Plasma, latte-dock in system packages and not much more. I actually switched channel to unstable to try with plasma 5.27, but apart from that I'm basically on default nix config. I did slightly more configuration on my main NixOS install, 22.11, but get same behavior in both cases. Debug symbols seems painful on NixOS. Unsure if I will do that now. Thank you for the help. I use X11 too.
Ok, so after reading the suggested , I enabled and followed the instructions of the option I have and The part for plasma-workspace seems to work fine, but the one for qt5 givers this:
To reproduce the bug described in this issue, a simple way is this: the official NixOS virtualbox ova from (22.11.2939. at the date of writing this) it in VirtualBox the vm konsole will segfault will run latte-dock and you will see that clicking on items in the dock does nothing
I also tried to update the vm to unstable still segfaults, only that the version shown is 5.27.2 still nothing happens when clicking on items in the dock
Again, this seems like a Plasma bug, possibly due to VirtualBox video drivers or something.


Question: <del> { lib , stdenv , fetchFromGitHub , emptyDirectory , writeText , makeWrapper , gradle , jdk21 , llvmPackages }: let gradleInit = writeText "init.gradle" '' logger.lifecycle 'Replacing Maven repositories with empty directory...' gradle.projectsLoaded { rootProject.allprojects { buildscript { repositories { clear() maven { url '${emptyDirectory}' } } } repositories { clear() maven { url '${emptyDirectory}' } } } } settingsEvaluated { settings -> settings.pluginManagement { repositories { maven { url '${emptyDirectory}' } } } } ''; in stdenv.mkDerivation { pname = "jextract"; version = "unstable-2023-11-27"; src = fetchFromGitHub { owner = "openjdk"; repo = "jextract"; rev = "8730fcf05c229d035b0db52ee6bd82622e9d03e9"; # Update jextract 21 with latest fixes hash = "sha256-Wct/yx5C0EjDtDyXNYDH5LRmrfq7islXbPVIGBR6x5Y="; }; nativeBuildInputs = [ gradle makeWrapper ]; env = { ORG_GRADLE_PROJECT_llvm_home = llvmPackages.libclang.lib; ORG_GRADLE_PROJECT_jdk21_home = jdk21; }; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --console plain --init-script "${gradleInit}" assemble runHook postBuild ''; doCheck = true; checkPhase = '' runHook preCheck gradle --console plain --init-script "${gradleInit}" verify runHook postCheck ''; installPhase = '' runHook preInstall mkdir -p $out/opt/ cp -r ./build/jextract $out/opt/jextract runHook postInstall ''; postFixup = '' makeWrapper "$out/opt/jextract/bin/jextract" "$out/bin/jextract" ''; meta = with lib; { description = "A tool which mechanically generates Java bindings from a native library headers"; mainProgram = "jextract"; homepage = "https://github.com/openjdk/jextract"; license = licenses.gpl2Only; maintainers = with maintainers; [ sharzy ]; }; } </del>

Package name: jextract (jextract-unstable) Current version on the unstable channel: 2023-11-27 Current version on the stable/release channel: n/a As of today the current release build is (see ) It would be nice for the nixpkgs version to be based on JDK 22 -- which contains the final non-preview release of Java Foreign Function & Memory API (aka "Panama") There are significant changes to that users will want before building/launching projects that use Panama. See: I am wiling to contribute but before we can do this we'll need to build with JDK 22 (see Issue )
It would be great if we could update to be based on JDK 22 :+1: , and we should also keep the current JDK 21 package as a new name (perhaps ?) at the same time, as some downstreams still depend on it and JDK 21 is a LTS version.
So should the first step be to rename the existing package? And leave as JDK 21-based (with a warning, maybe) and then do a separate PR to upgrade to JDK 21?
Update: There is a PR for JDK 22:
I can open a PR to update jextract after gets merged. Considering the significant API changes between JDK 21 and 22, and the fact that jextract itself produces very differnt code if you have to use JDK21 (see ) , is there really value in keeping a jextract version compatible with JDK21?
Awesome! I'm going to test on macOS/aarch64 this weekend, so that will help get it merged. wrote: as some downstreams still depend on it and JDK 21 is a LTS version. JDK 21 is LTS, but Panama (Foreign Functions & Memory API) is a "preview feature" which makes it really hard to build anything real with it (i.e. publish JARs for use by other projects. I even had problems with a Gradle multi-module build). I migrated my project to 22 a few weeks ago and am not looking back (which meant I had to stop using Nix as a source for temporarily.) But, I don't see any harm in renaming the existing to and starting a new one. And we certainly don't want to unnecessarily break anyone's dependencies.


Question: <del> { lib , stdenv , fetchFromGitHub , emptyDirectory , writeText , makeWrapper , gradle , jdk21 , llvmPackages }: let gradleInit = writeText "init.gradle" '' logger.lifecycle 'Replacing Maven repositories with empty directory...' gradle.projectsLoaded { rootProject.allprojects { buildscript { repositories { clear() maven { url '${emptyDirectory}' } } } repositories { clear() maven { url '${emptyDirectory}' } } } } settingsEvaluated { settings -> settings.pluginManagement { repositories { maven { url '${emptyDirectory}' } } } } ''; in stdenv.mkDerivation { pname = "jextract"; version = "unstable-2023-11-27"; src = fetchFromGitHub { owner = "openjdk"; repo = "jextract"; rev = "8730fcf05c229d035b0db52ee6bd82622e9d03e9"; # Update jextract 21 with latest fixes hash = "sha256-Wct/yx5C0EjDtDyXNYDH5LRmrfq7islXbPVIGBR6x5Y="; }; nativeBuildInputs = [ gradle makeWrapper ]; env = { ORG_GRADLE_PROJECT_llvm_home = llvmPackages.libclang.lib; ORG_GRADLE_PROJECT_jdk21_home = jdk21; }; buildPhase = '' runHook preBuild export GRADLE_USER_HOME=$(mktemp -d) gradle --console plain --init-script "${gradleInit}" assemble runHook postBuild ''; doCheck = true; checkPhase = '' runHook preCheck gradle --console plain --init-script "${gradleInit}" verify runHook postCheck ''; installPhase = '' runHook preInstall mkdir -p $out/opt/ cp -r ./build/jextract $out/opt/jextract runHook postInstall ''; postFixup = '' makeWrapper "$out/opt/jextract/bin/jextract" "$out/bin/jextract" ''; meta = with lib; { description = "A tool which mechanically generates Java bindings from a native library headers"; mainProgram = "jextract"; homepage = "https://github.com/openjdk/jextract"; license = licenses.gpl2Only; maintainers = with maintainers; [ sharzy ]; }; } </del>

And now that Panama/FF&M is final, I'm hoping it will be possible to use jextract 22 to build headers for JDK 23+. Newer versions of jextract might offer improvements, but headers generated for JDK 22 should work wth JDK 23+ (I don't know what guarantees the JDK makes for that, but this seems a reasonable conclusion given a stable API.)
Nice to hear that, and thanks for your work! IMO, I think it's worth. The point is that JDK 21 is a LTS version, some downstreams prefer to use a LTS version of JDK to develop their projects. For them, if we don't keep JDK 21's , this will be unavailable to them unless they give up on choosing LTS and do some extra effort - porting their project to a newer version of JDK.
I agree. But I also strongly encourage new projects to start with JDK 22 and existing projects to migrate as quickly as possible. Having to make sure "preview mode" is set in the compiler and at runtime can cause various problems with tools and the output of the latest is significantly improved. In general, it's much better to be using a non-LTS JDK with a non-preview feature than and LTS JDK with a preview feature. I migrated my project recently and wish I had migrated to JDK 22 much earlier.
PR has been merged. I gave it a quick test on macOS/aarch64 and it seems to be working. (I used it to build which uses JDK 22 and Panama via Gradle's Java toolchains)


Question: <del> GEM remote: https://rubygems.org/ specs: activesupport (5.2.4.5) concurrent-ruby (~> 1.0, >= 1.0.2) i18n (>= 0.7, < 2) minitest (~> 5.1) tzinfo (~> 1.1) addressable (2.5.2) public_suffix (>= 2.0.2, < 4.0) app_conf (0.4.2) ast (2.4.2) aws-eventstream (1.1.0) aws-partitions (1.426.0) aws-sdk-apigateway (1.59.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-apigatewayv2 (1.31.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-applicationautoscaling (1.49.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-athena (1.35.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-autoscaling (1.53.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-batch (1.43.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-budgets (1.37.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudformation (1.47.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudfront (1.48.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudhsm (1.28.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudhsmv2 (1.32.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudtrail (1.33.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudwatch (1.49.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cloudwatchevents (1.40.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-cloudwatchlogs (1.39.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-codecommit (1.41.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-codedeploy (1.38.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-codepipeline (1.40.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-cognitoidentity (1.29.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-cognitoidentityprovider (1.48.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-configservice (1.56.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-core (3.112.0) aws-eventstream (~> 1, >= 1.0.2) aws-partitions (~> 1, >= 1.239.0) aws-sigv4 (~> 1.1) jmespath (~> 1.0) aws-sdk-costandusagereportservice (1.29.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-databasemigrationservice (1.50.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-dynamodb (1.59.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-ec2 (1.224.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-ecr (1.41.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-ecs (1.74.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-efs (1.37.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-eks (1.47.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-elasticache (1.53.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-elasticbeanstalk (1.41.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-elasticloadbalancing (1.30.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-elasticloadbalancingv2 (1.59.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-elasticsearchservice (1.48.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-firehose (1.36.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-glue (1.82.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-guardduty (1.44.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-iam (1.47.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-kafka (1.34.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-kinesis (1.31.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-kms (1.42.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-lambda (1.59.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-organizations (1.55.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-ram (1.22.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-rds (1.112.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-redshift (1.54.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-route53 (1.46.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-route53domains (1.29.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-route53resolver (1.23.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-s3 (1.88.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sdk-kms (~> 1) aws-sigv4 (~> 1.1) aws-sdk-secretsmanager (1.43.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-securityhub (1.40.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-servicecatalog (1.57.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-ses (1.37.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-shield (1.34.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-sms (1.28.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-sns (1.38.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-sqs (1.36.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-ssm (1.104.0) aws-sdk-core (~> 3, >= 3.112.0) aws-sigv4 (~> 1.1) aws-sdk-states (1.37.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sdk-transfer (1.29.0) aws-sdk-core (~> 3, >= 3.109.0) aws-sigv4 (~> 1.1) aws-sigv4 (1.2.2) aws-eventstream (~> 1, >= 1.0.2) azure_graph_rbac (0.17.2) ms_rest_azure (~> 0.12.0) azure_mgmt_key_vault (0.17.7) ms_rest_azure (~> 0.12.0) azure_mgmt_resources (0.18.1) ms_rest_azure (~> 0.12.0) azure_mgmt_security (0.19.0) ms_rest_azure (~> 0.12.0) azure_mgmt_storage (0.22.0) ms_rest_azure (~> 0.12.0) bcrypt_pbkdf (1.1.0) berkshelf (7.1.0) chef (>= 15.7.32) chef-config cleanroom (~> 1.0) concurrent-ruby (~> 1.0) minitar (>= 0.6) mixlib-archive (>= 0.4, < 2.0) mixlib-config (>= 2.2.5) mixlib-shellout (>= 2.0, < 4.0) octokit (~> 4.0) retryable (>= 2.0, < 4.0) solve (~> 4.0) thor (>= 0.20) builder (3.2.4) chef (15.15.0) addressable bcrypt_pbkdf (~> 1.0) bundler (>= 1.10) chef-config (= 15.15.0) chef-utils (= 15.15.0) chef-zero (>= 14.0.11) diff-lcs (~> 1.2, >= 1.2.4) ed25519 (~> 1.2) erubis (~> 2.7) ffi (~> 1.9, >= 1.9.25) ffi-libarchive (~> 1.0, >= 1.0.3) ffi-yajl (~> 2.2) highline (>= 1.6.9, < 2) iniparse (~> 1.4) license-acceptance (~> 1.0, >= 1.0.5) mixlib-archive (>= 0.4, < 2.0) mixlib-authentication (>= 2.1, < 4) mixlib-cli (>= 2.1.1, < 3.0) mixlib-log (>= 2.0.3, < 4.0) mixlib-shellout (>= 3.0.3, < 4.0) net-sftp (>= 2.1.2, < 4.0) net-ssh (>= 4.2, < 7) net-ssh-multi (~> 1.2, >= 1.2.1) ohai (~> 15.0) plist (~> 3.2) proxifier (~> 1.0) syslog-logger (~> 1.6) train-core (~> 3.2, >= 3.2.28) train-winrm (>= 0.2.5) tty-screen (~> 0.6) uuidtools (~> 2.1.5) chef-cli (3.1.1) addressable (>= 2.3.5, < 2.8) chef (>= 15.0) cookbook-omnifetch (~> 0.5) diff-lcs (>= 1.0, < 1.4) ffi-yajl (>= 1.0, < 3.0) license-acceptance (>= 1.0.11, < 3) minitar (~> 0.6) mixlib-cli (>= 1.7, < 3.0) mixlib-shellout (>= 2.0, < 4.0) pastel (~> 0.7) solve (> 2.0, < 5.0) chef-config (15.15.0) addressable chef-utils (= 15.15.0) fuzzyurl mixlib-config (>= 2.2.12, < 4.0) mixlib-shellout (>= 2.0, < 4.0) tomlrb (~> 1.2) chef-dk (4.13.3) addressable (>= 2.3.5, < 2.6) chef (~> 15.0) cookbook-omnifetch (~> 0.5) diff-lcs (~> 1.0) ffi-yajl (>= 1.0, < 3.0) license-acceptance (~> 1.0, >= 1.0.11) minitar (~> 0.6) mixlib-cli (>= 1.7, < 3.0) mixlib-shellout (>= 2.0, < 4.0) paint (~> 1.0) solve (> 2.0, < 5.0) chef-provisioning (2.7.6) cheffish (>= 4.0, < 15.0) inifile (>= 2.0.2) mixlib-install (>= 1.0) net-scp (~> 1.0) net-ssh (>= 2.9, < 5.0) net-ssh-gateway (> 1.2, < 3.0) winrm (~> 2.0) winrm-elevated (~> 1.0) winrm-fs (~> 1.0) chef-telemetry (1.0.14) chef-config concurrent-ruby (~> 1.0) ffi-yajl (~> 2.2) chef-utils (15.15.0) chef-vault (4.1.0) chef-zero (14.0.17) ffi-yajl (~> 2.2) hashie (>= 2.0, < 4.0) mixlib-log (>= 2.0, < 4.0) rack (~> 2.0, >= 2.0.6) uuidtools (~> 2.1) cheffish (14.0.13) chef-zero (~> 14.0) net-ssh chefspec (9.2.1) chef (>= 14) chef-cli fauxhai-ng (>= 7.5) rspec (~> 3.0) cleanroom (1.0.0) coderay (1.1.3) concurrent-ruby (1.1.8) cookbook-omnifetch (0.11.1) mixlib-archive (>= 0.4, < 2.0) declarative (0.0.20) declarative-option (0.1.0) diff-lcs (1.3) diffy (3.4.0) docker-api (2.0.0) excon (>= 0.47.0) multi_json domain_name (0.5.20190701) unf (>= 0.0.5, < 1.0.0) ed25519 (1.2.4) erubi (1.10.0) erubis (2.7.0) excon (0.79.0) faraday (1.3.0) faraday-net_http (~> 1.0) multipart-post (>= 1.2, < 3) ruby2_keywords faraday-cookie_jar (0.0.7) faraday (>= 0.8.0) http-cookie (~> 1.0.0) faraday-net_http (1.0.1) faraday_middleware (1.0.0) faraday (~> 1.0) fauxhai-ng (8.7.0) net-ssh ffi (1.14.2) ffi-libarchive (1.0.17) ffi (~> 1.0) ffi-yajl (2.3.4) libyajl2 (~> 1.2) foodcritic (16.3.0) erubis ffi-yajl (~> 2.0) nokogiri (>= 1.5, < 2.0) rake rufus-lru (~> 1.0) treetop (~> 1.4) fuzzyurl (0.9.0) git (1.8.1) rchardet (~> 1.8) google-api-client (0.52.0) addressable (~> 2.5, >= 2.5.1) googleauth (~> 0.9) httpclient (>= 2.8.1, < 3.0) mini_mime (~> 1.0) representable (~> 3.0) retriable (>= 2.0, < 4.0) rexml signet (~> 0.12) googleauth (0.14.0) faraday (>= 0.17.3, < 2.0) jwt (>= 1.4, < 3.0) memoist (~> 0.16) multi_json (~> 1.11) os (>= 0.9, < 2.0) signet (~> 0.14) gssapi (1.3.1) ffi (>= 1.0.1) gyoku (1.3.1) builder (>= 2.1.2) hashie (3.6.0) highline (1.7.10) http-cookie (1.0.3) domain_name (~> 0.5) httpclient (2.8.3) i18n (1.8.8) concurrent-ruby (~> 1.0) inifile (3.0.0) iniparse (1.5.0) inspec (4.26.4) faraday_middleware (>= 0.12.2, < 1.1) inspec-core (= 4.26.4) train (~> 3.0) train-aws (~> 0.1) train-habitat (~> 0.1) train-winrm (~> 0.2) inspec-core (4.26.4) addressable (~> 2.4) chef-telemetry (~> 1.0) faraday (>= 0.9.0, < 1.4) faraday_middleware (~> 1.0) hashie (>= 3.4, < 5.0) license-acceptance (>= 0.2.13, < 3.0) method_source (>= 0.8, < 2.0) mixlib-log (~> 3.0) multipart-post (~> 2.0) parallel (~> 1.9) parslet (>= 1.5, < 2.0) pry (~> 0.13) rspec (>= 3.9, < 3.11) rspec-its (~> 1.2) rubyzip (>= 1.2.2, < 3.0) semverse (~> 3.0) sslshake (~> 1.2) thor (>= 0.20, < 2.0) tomlrb (>= 1.2, < 2.1) train-core (~> 3.0) tty-prompt (~> 0.17) tty-table (~> 0.10) ipaddress (0.8.3) jmespath (1.4.0) json (2.5.1) jwt (2.2.2) kitchen-inspec (2.3.0) hashie (>= 3.4, <= 5.0) inspec (>= 2.2.64, < 5.0) test-kitchen (>= 2.7, < 3) kitchen-vagrant (1.8.0) test-kitchen (>= 1.4, < 3) knife-spork (1.7.3) app_conf (>= 0.4.0) chef (>= 11.0.0) diffy (>= 3.0.1) git (>= 1.2.5) libyajl2 (1.2.0) license-acceptance (1.0.19) pastel (~> 0.7) tomlrb (~> 1.2) tty-box (~> 0.3) tty-prompt (~> 0.18) little-plugger (1.1.4) logging (2.3.0) little-plugger (~> 1.1) multi_json (~> 1.14) memoist (0.16.2) method_source (1.0.0) mini_mime (1.0.2) mini_portile2 (2.5.0) minitar (0.9) minitest (5.14.3) mixlib-archive (1.1.4) mixlib-log mixlib-authentication (3.0.7) mixlib-cli (2.1.8) mixlib-config (3.0.9) tomlrb mixlib-install (3.12.5) mixlib-shellout mixlib-versioning thor mixlib-log (3.0.9) mixlib-shellout (3.2.2) chef-utils mixlib-versioning (1.2.12) molinillo (0.7.0) ms_rest (0.7.6) concurrent-ruby (~> 1.0) faraday (>= 0.9, < 2.0.0) timeliness (~> 0.3.10) ms_rest_azure (0.12.0) concurrent-ruby (~> 1.0) faraday (>= 0.9, < 2.0.0) faraday-cookie_jar (~> 0.0.6) ms_rest (~> 0.7.6) multi_json (1.15.0) multipart-post (2.1.1) net-scp (1.2.1) net-ssh (>= 2.6.5) net-sftp (2.1.2) net-ssh (>= 2.6.5) net-ssh (4.2.0) net-ssh-gateway (2.0.0) net-ssh (>= 4.0.0) net-ssh-multi (1.2.1) net-ssh (>= 2.6.5) net-ssh-gateway (>= 1.2.0) nokogiri (1.11.1) mini_portile2 (~> 2.5.0) racc (~> 1.4) nori (2.6.0) octokit (4.20.0) faraday (>= 0.9) sawyer (~> 0.8.0, >= 0.5.3) ohai (15.12.0) chef-config (>= 12.8, < 16) ffi (~> 1.9) ffi-yajl (~> 2.2) ipaddress mixlib-cli (>= 1.7.0) mixlib-config (>= 2.0, < 4.0) mixlib-log (>= 2.0.1, < 4.0) mixlib-shellout (>= 2.0, < 4.0) plist (~> 3.1) systemu (~> 2.6.4) wmi-lite (~> 1.0) os (1.1.1) paint (1.0.1) parallel (1.20.1) parser (3.0.0.0) ast (~> 2.4.1) parslet (1.8.2) pastel (0.8.0) tty-color (~> 0.5) plist (3.6.0) polyglot (0.3.5) proxifier (1.0.3) pry (0.14.0) coderay (~> 1.1) method_source (~> 1.0) public_suffix (3.1.1) racc (1.5.2) rack (2.2.3) rainbow (3.0.0) rake (13.0.3) rchardet (1.8.0) regexp_parser (2.0.3) representable (3.0.4) declarative (< 0.1.0) declarative-option (< 0.2.0) uber (< 0.2.0) retriable (3.1.2) retryable (3.0.5) rexml (3.2.4) rspec (3.10.0) rspec-core (~> 3.10.0) rspec-expectations (~> 3.10.0) rspec-mocks (~> 3.10.0) rspec-core (3.10.1) rspec-support (~> 3.10.0) rspec-expectations (3.10.1) diff-lcs (>= 1.2.0, < 2.0) rspec-support (~> 3.10.0) rspec-its (1.3.0) rspec-core (>= 3.0.0) rspec-expectations (>= 3.0.0) rspec-mocks (3.10.2) diff-lcs (>= 1.2.0, < 2.0) rspec-support (~> 3.10.0) rspec-support (3.10.2) rubocop (1.9.1) parallel (~> 1.10) parser (>= 3.0.0.0) rainbow (>= 2.2.2, < 4.0) regexp_parser (>= 1.8, < 3.0) rexml rubocop-ast (>= 1.2.0, < 2.0) ruby-progressbar (~> 1.7) unicode-display_width (>= 1.4.0, < 3.0) rubocop-ast (1.4.1) parser (>= 2.7.1.5) ruby-progressbar (1.11.0) ruby2_keywords (0.0.4) rubyntlm (0.6.3) rubyzip (2.3.0) rufus-lru (1.1.0) sawyer (0.8.2) addressable (>= 2.3.5) faraday (> 0.8, < 2.0) semverse (3.0.0) signet (0.14.1) addressable (~> 2.3) faraday (>= 0.17.3, < 2.0) jwt (>= 1.5, < 3.0) multi_json (~> 1.10) solve (4.0.4) molinillo (~> 0.6) semverse (>= 1.1, < 4.0) sslshake (1.3.1) strings (0.2.0) strings-ansi (~> 0.2) unicode-display_width (~> 1.5) unicode_utils (~> 1.4) strings-ansi (0.2.0) syslog-logger (1.6.8) systemu (2.6.5) test-kitchen (2.10.0) bcrypt_pbkdf (~> 1.0) ed25519 (~> 1.2) license-acceptance (>= 1.0.11, < 3.0) mixlib-install (~> 3.6) mixlib-shellout (>= 1.2, < 4.0) net-scp (>= 1.1, < 4.0) net-ssh (>= 2.9, < 7.0) net-ssh-gateway (>= 1.2, < 3.0) thor (>= 0.19, < 2.0) winrm (~> 2.0) winrm-elevated (~> 1.0) winrm-fs (~> 1.1) thor (1.1.0) thread_safe (0.3.6) timeliness (0.3.10) tomlrb (1.3.0) train (3.4.9) activesupport (>= 5.2.4.3, < 6.0.0) azure_graph_rbac (~> 0.16) azure_mgmt_key_vault (~> 0.17) azure_mgmt_resources (~> 0.15) azure_mgmt_security (~> 0.18) azure_mgmt_storage (~> 0.18) docker-api (>= 1.26, < 3.0) google-api-client (>= 0.23.9, <= 0.52.0) googleauth (>= 0.6.6, <= 0.14.0) inifile (~> 3.0) train-core (= 3.4.9) train-winrm (~> 0.2) train-aws (0.1.35) aws-sdk-apigateway (~> 1.0) aws-sdk-apigatewayv2 (~> 1.0) aws-sdk-applicationautoscaling (>= 1.46, < 1.50) aws-sdk-athena (~> 1.0) aws-sdk-autoscaling (>= 1.22, < 1.54) aws-sdk-batch (>= 1.36, < 1.44) aws-sdk-budgets (~> 1.0) aws-sdk-cloudformation (~> 1.0) aws-sdk-cloudfront (~> 1.0) aws-sdk-cloudhsm (~> 1.0) aws-sdk-cloudhsmv2 (~> 1.0) aws-sdk-cloudtrail (~> 1.8) aws-sdk-cloudwatch (~> 1.13) aws-sdk-cloudwatchevents (>= 1.36, < 1.41) aws-sdk-cloudwatchlogs (~> 1.13) aws-sdk-codecommit (~> 1.0) aws-sdk-codedeploy (~> 1.0) aws-sdk-codepipeline (~> 1.0) aws-sdk-cognitoidentity (>= 1.26, < 1.30) aws-sdk-cognitoidentityprovider (>= 1.46, < 1.49) aws-sdk-configservice (~> 1.21) aws-sdk-core (~> 3.0) aws-sdk-costandusagereportservice (~> 1.6) aws-sdk-databasemigrationservice (>= 1.42, < 1.51) aws-sdk-dynamodb (~> 1.31) aws-sdk-ec2 (~> 1.70) aws-sdk-ecr (~> 1.18) aws-sdk-ecs (~> 1.30) aws-sdk-efs (~> 1.0) aws-sdk-eks (~> 1.9) aws-sdk-elasticache (~> 1.0) aws-sdk-elasticbeanstalk (~> 1.0) aws-sdk-elasticloadbalancing (~> 1.8) aws-sdk-elasticloadbalancingv2 (~> 1.0) aws-sdk-elasticsearchservice (~> 1.0) aws-sdk-firehose (~> 1.0) aws-sdk-glue (>= 1.71, < 1.83) aws-sdk-guardduty (~> 1.31) aws-sdk-iam (~> 1.13) aws-sdk-kafka (~> 1.0) aws-sdk-kinesis (~> 1.0) aws-sdk-kms (~> 1.13) aws-sdk-lambda (~> 1.0) aws-sdk-organizations (>= 1.17, < 1.56) aws-sdk-ram (>= 1.21, < 1.23) aws-sdk-rds (~> 1.43) aws-sdk-redshift (~> 1.0) aws-sdk-route53 (~> 1.0) aws-sdk-route53domains (~> 1.0) aws-sdk-route53resolver (~> 1.0) aws-sdk-s3 (~> 1.30) aws-sdk-secretsmanager (>= 1.42, < 1.44) aws-sdk-securityhub (~> 1.0) aws-sdk-servicecatalog (>= 1.48, < 1.58) aws-sdk-ses (~> 1.0) aws-sdk-shield (~> 1.30) aws-sdk-sms (~> 1.0) aws-sdk-sns (~> 1.9) aws-sdk-sqs (~> 1.10) aws-sdk-ssm (~> 1.0) aws-sdk-states (>= 1.35, < 1.38) aws-sdk-transfer (>= 1.26, < 1.30) train-core (3.4.9) addressable (~> 2.5) ffi (!= 1.13.0) json (>= 1.8, < 3.0) mixlib-shellout (>= 2.0, < 4.0) net-scp (>= 1.2, < 4.0) net-ssh (>= 2.9, < 7.0) train-habitat (0.2.22) train-winrm (0.2.12) winrm (>= 2.3.6, < 3.0) winrm-elevated (~> 1.2.2) winrm-fs (~> 1.0) treetop (1.6.11) polyglot (~> 0.3) tty-box (0.7.0) pastel (~> 0.8) strings (~> 0.2.0) tty-cursor (~> 0.7) tty-color (0.6.0) tty-cursor (0.7.1) tty-prompt (0.23.0) pastel (~> 0.8) tty-reader (~> 0.8) tty-reader (0.9.0) tty-cursor (~> 0.7) tty-screen (~> 0.8) wisper (~> 2.0) tty-screen (0.8.1) tty-table (0.12.0) pastel (~> 0.8) strings (~> 0.2.0) tty-screen (~> 0.8) tzinfo (1.2.9) thread_safe (~> 0.1) uber (0.1.0) unf (0.1.4) unf_ext unf_ext (0.0.7.7) unicode-display_width (1.7.0) unicode_utils (1.4.0) uuidtools (2.1.5) winrm (2.3.6) builder (>= 2.1.2) erubi (~> 1.8) gssapi (~> 1.2) gyoku (~> 1.0) httpclient (~> 2.2, >= 2.2.0.2) logging (>= 1.6.1, < 3.0) nori (~> 2.0) rubyntlm (~> 0.6.0, >= 0.6.3) winrm-elevated (1.2.3) erubi (~> 1.8) winrm (~> 2.0) winrm-fs (~> 1.0) winrm-fs (1.3.5) erubi (~> 1.8) logging (>= 1.6.1, < 3.0) rubyzip (~> 2.0) winrm (~> 2.0) wisper (2.0.1) wmi-lite (1.0.5) PLATFORMS ruby DEPENDENCIES berkshelf chef-dk (= 4.13.3) chef-provisioning chef-vault chefspec fauxhai-ng foodcritic inspec kitchen-inspec kitchen-vagrant knife-spork ohai pry rubocop test-kitchen BUNDLED WITH 2.1.4 </del>

ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.


Question: <ins> { lib , buildNpmPackage , mkYarnPackage , fetchYarnDeps , fetchFromGitHub , typescript , jq , fetchpatch }: let # Instead of the build script that spectral-language-server provides (ref: https://github.com/luizcorreia/spectral-language-server/blob/master/script/vscode-spectral-build.sh), we build vscode-spectral manually. # This is because the script must go through the network and will not work under the Nix sandbox environment. vscodeSpectral = mkYarnPackage rec { pname = "vscode-spectral"; version = "1.1.2"; src = fetchFromGitHub { owner = "stoplightio"; repo = "vscode-spectral"; rev = "v${version}"; hash = "sha256-TWy+bC6qhTKDY874ORTBbvCIH8ycpmBiU8GLYxBIiAs="; }; packageJSON = ./package.json; offlineCache = fetchYarnDeps { yarnLock = src + "/yarn.lock"; hash = "sha256-am27A9VyFoXuOlgG9mnvNqV3Q7Bi7GJzDqqVFGDVWIA="; }; nativeBuildInputs = [ typescript jq ]; postPatch = '' cp server/tsconfig.json server/tsconfig.json.bak jq '.compilerOptions += {"module": "NodeNext", "moduleResolution": "NodeNext"}' server/tsconfig.json.bak > server/tsconfig.json ''; dontConfigure = true; buildPhase = '' runHook preBuild # FIXME: vscode-spactral depends on @rollup/pluginutils, but it may have a bug that doesn't provide the type definitions for NodeNext module resolution. (ref: https://github.com/rollup/plugins/issues/1192) # tsc detects some type errors in the code. However we ignore this because it's not a problem for the final build if server/dist is generated. tsc -p server || true test -d server/dist runHook postBuild ''; installPhase = '' runHook preInstall mkdir -p $out cp -R server/dist $out runHook postInstall ''; doDist = false; meta = with lib; { homepage = "https://github.com/stoplightio/vscode-spectral"; description = "VS Code extension bringing the awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support"; license = licenses.asl20; }; }; in buildNpmPackage rec { pname = "spectral-language-server"; version = "1.0.8-unstable-2023-06-06"; src = fetchFromGitHub { owner = "luizcorreia"; repo = "spectral-language-server"; rev = "c9a7752b08e6bba937ef4f5435902afd41b6957f"; hash = "sha256-VD2aAzlCnJ6mxPUSbNRfMOlslM8kLPqrAI2ah6sX9cU="; }; npmDepsHash = "sha256-ixAXy/rRkyWL3jdAkrXJh1qhWcKIkr5nH/Bhu2JV6k8="; patches = [ # https://github.com/luizcorreia/spectral-language-server/pull/15 (fetchpatch { name = "fix-package-lock.patch"; url = "https://github.com/luizcorreia/spectral-language-server/commit/909704850dd10e7b328fc7d15f8b07cdef88899d.patch"; hash = "sha256-+mN93xP4HCll4dTcnh2W/m9k3XovvgnB6AOmuJpZUZ0="; }) ]; dontNpmBuild = true; npmFlags = [ "--ignore-scripts" ]; installPhase = '' runHook preInstall mkdir -p $out/bin mkdir -p $out/node_modules mkdir -p $out/dist/spectral-language-server cp -R ${vscodeSpectral}/dist/* $out/dist/spectral-language-server/ cp ./bin/* $out/bin cp -R ./node_modules/* $out/node_modules runHook postInstall ''; meta = with lib; { homepage = "https://github.com/luizcorreia/spectral-language-server"; description = "Awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support"; maintainers = with maintainers; [ momeemt ]; license = licenses.mit; mainProgram = "spectral-language-server"; }; } </ins>

Awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support Spectral is a flexible object linter with out of the box support for OpenAPI v2 and v3, JSON Schema, and AsyncAPI. MIT
Should be trivial to package using .


Question: <ins> { lib , stdenv , fetchFromGitHub , libaio }: stdenv.mkDerivation rec { pname = "stressapptest"; version = "1.0.9"; src = fetchFromGitHub { owner = pname; repo = pname; rev = "v${version}"; sha256 = "1qzj6h6adx042rb9aiz916jna269whibvj5ys4p5nwdp17fqh922"; }; buildInputs = [ libaio ]; meta = with lib; { description = "Userspace memory and IO stress test tool"; homepage = "https://github.com/stressapptest/stressapptest"; license = with licenses; [ asl20 ]; maintainers = with lib.maintainers; [ fab ]; platforms = platforms.unix; }; } </ins>

Stressful Application Test (or stressapptest, its unix name) is a memory interface test. It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time [...] In my experience it's an absolute monster in finding random memory errors that don't show up over weeks of real world usage. Until ECC is commonplace, running this software is necessary. Metadata source URL: license: Apache 2.0 platforms: linux
could you please give a try?
worked no problem, thanks a lot!


Question: ln -sfv "${nodejs}/include" "$HOME/.node-gyp/${nodejs.version}" export npm_config_nodedir=${nodejs} <del> pushd redisinsight </del> # Build the sqlite3 package. <ins> pushd redisinsight </ins> npm_config_node_gyp="${buildPackages.nodejs}/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" npm rebuild --verbose --sqlite=${sqlite.dev} sqlite3 popd <ins> # Build node-sass LIBSASS_EXT=auto npm rebuild --verbose node-sass </ins> substituteInPlace redisinsight/api/config/default.ts  <del> --replace "process['resourcesPath']" ""$out/share/redisinsight""  </del> <ins> --replace-fail "process['resourcesPath']" ""$out/share/redisinsight""  # has irrelevant files rm -r resources/app </ins> runHook postConfigure ''; buildPhase = '' runHook preBuild <del> yarn config --offline set yarn-offline-mirror $offlineCache pushd node_modules/node-sass LIBSASS_EXT=auto yarn run build --offline popd </del> <ins> yarn config --offline set yarn-offline-mirror ${finalAttrs.offlineCache} </ins> yarn --offline build:prod yarn --offline electron-builder  <del> --dir ${if stdenv.isDarwin then "--macos" else "--linux"} ${if stdenv.hostPlatform.isAarch64 then "--arm64" else "--x64"}  </del> <ins> --dir  </ins> -c.electronDist=${electron}/libexec/electron  -c.electronVersion=${electron.version}

Steps to reproduce the behavior: -shell -p redisinsight Multiple of these errors Full log - Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { lib, stdenv, fetchurl, fetchFromGitHub, jdk17_headless, jre17_minimal, gradle_7, bash, coreutils, substituteAll, nixosTests, fetchpatch, writeText, }: let gradle = gradle_7; jdk = jdk17_headless; # Reduce closure size jre = jre17_minimal.override { modules = [ "java.base" "java.logging" "java.naming" "java.sql" "java.desktop" "java.management" ]; jdk = jdk17_headless; }; version = "01497"; freenet_ext = fetchurl { url = "https://github.com/freenet/fred/releases/download/build01495/freenet-ext.jar"; sha256 = "sha256-MvKz1r7t9UE36i+aPr72dmbXafCWawjNF/19tZuk158="; }; seednodes = fetchFromGitHub { name = "freenet-seednodes"; owner = "hyphanet"; repo = "seedrefs"; rev = "9df1bf93ab64aba634bdfc5f4d0e960571ce4ba5"; hash = "sha256-nvwJvKw5IPhItPe4k/jnOGaa8H4DtOi8XxKFOKFMAuY="; postFetch = '' cat $out/* > $out/seednodes.fref ''; }; patches = [ # gradle 7 support # https://github.com/freenet/fred/pull/827 (fetchpatch { url = "https://github.com/freenet/fred/commit/8991303493f2c0d9933f645337f0a7a5a979e70a.patch"; sha256 = "sha256-T1zymxRTADVhhwp2TyB+BC/J4gZsT/CUuMrT4COlpTY="; }) ]; in stdenv.mkDerivation rec { pname = "freenet"; inherit version patches; src = fetchFromGitHub { owner = "freenet"; repo = "fred"; rev = "refs/tags/build${version}"; hash = "sha256-pywNPekofF/QotNVF28McojqK7c1Zzucds5rWV0R7BQ="; }; postPatch = '' rm gradle/verification-{keyring.keys,metadata.xml} ''; nativeBuildInputs = [ gradle jdk ]; wrapper = substituteAll { src = ./freenetWrapper; inherit bash coreutils jre seednodes ; }; mitmCache = gradle.fetchDeps { inherit pname; data = ./deps.json; }; # using reproducible archives breaks the build gradleInitScript = writeText "empty-init-script.gradle" ""; gradleFlags = [ "-Dorg.gradle.java.home=${jdk}" ]; gradleBuildTask = "jar"; installPhase = '' runHook preInstall install -Dm644 build/libs/freenet.jar $out/share/freenet/freenet.jar ln -s ${freenet_ext} $out/share/freenet/freenet-ext.jar mkdir -p $out/bin install -Dm755 ${wrapper} $out/bin/freenet export CLASSPATH="$(find ${mitmCache} -name "*.jar"| sort | grep -v bcprov-jdk15on-1.48.jar|tr $'n' :):$out/share/freenet/freenet-ext.jar:$out/share/freenet/freenet.jar" substituteInPlace $out/bin/freenet  --subst-var-by CLASSPATH "$CLASSPATH" runHook postInstall ''; passthru.tests = { inherit (nixosTests) freenet; }; meta = { description = "Decentralised and censorship-resistant network"; homepage = "https://freenetproject.org/"; sourceProvenance = with lib.sourceTypes; [ binaryBytecode ]; license = lib.licenses.gpl2Plus; maintainers = with lib.maintainers; [ nagy ]; platforms = with lib.platforms; linux; changelog = "https://github.com/freenet/fred/blob/build${version}/NEWS.md"; }; } </ins>

Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: