jiebi/CodeConvo huggingface dataset:
Code change:
# 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}

Related discussion:
text: 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.
Code change:
}); 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

Related discussion:
text: 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?
Code change:
}); 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

Related discussion:
text: 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.
Code change:
}); 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

Related discussion:
text: 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.
Code change:
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 = {

Related discussion:
text: 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.
Code change:
(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"; })

Related discussion:
text: 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
Code change:
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";

Related discussion:
text: 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
Code change:
} ++ (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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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.
Code change:
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 { };

Related discussion:
text: 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.
Code change:
<ins> { invalidateFetcherByDrvHash, fetchgit, ... }: { simple = invalidateFetcherByDrvHash fetchgit { name = "nix-source"; url = "https://github.com/NixOS/nix"; rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a"; sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY="; }; } </ins>

Related discussion:
text: 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
Code change:
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 

Related discussion:
text: 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
Code change:
{ 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 ];

Related discussion:
text: 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.