jiebi/CodeConvo huggingface dataset:
Change:
let # minorVersion is even for stable, odd for unstable <del> version = "9.2.6"; </del> <ins> version = "9.2.7"; </ins> # This package provides several with* options, which replaces the old extraLibraries option. # This error should help users that still use this option find their way to these flags.

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
<del> { lib, stdenv, buildGoModule, fetchFromGitHub, buildPackages, installShellFiles </del> <ins> { lib, stdenv, buildGoModule, fetchFromGitHub, buildPackages, installShellFiles, fetchpatch </ins> , makeWrapper , enableCmount ? true, fuse, macfuse-stubs }:

Discussion:
Steps to reproduce the behavior: 1.63.0 on rclone 1.63.0 is available in nixos-unstable Using flakes, tracking nixos-unstable Please run and paste the result.
It happens because go-m1cpu<0.1.6, doesn't handle when building with macOS SDK = 12.0 It was already fixed in upstream I think we can add a patch with it.
I opened an issue under (which was the wrong place), but I have the same issue. This is what my ticket said. I think the issue maybe with more than just the package. Describe the bug There appears to be an issue with packages that use the later versions of . I don't think the issue is with directly. See So far the error can be seen in both and . See the example error below.(Ran from inside folder on master branch. So far I get the same issue on both and packages. This seems like a relatively new issue as both and have recently updated the package I believe this issue is related to nixpkgs and NOT the go-m1cpu as i'm able to checkout both and source repositories and run successfully. Steps To Reproduce Try building latest version of nomad or rclone on an m2 mac using the latest nix derivation located at pkgs/applications/networking/sync/rclone/ and pkgs/applications/networking/cluster/nomad/ Example command nix-build -E 'with import <nixpkgs{ }; callPackage { }' Expected behavior Packages build correctly nix-env --version output nix-env (Nix) 2.15.1 Additional context OSX 13.4.1, M2
Change:
<ins> { lib , fetchFromGitHub , gobject-introspection , gtk-layer-shell , gtk3 , python3Packages , wrapGAppsHook }: python3Packages.buildPythonApplication rec { pname = "nwg-hello"; version = "0.1.6"; src = fetchFromGitHub { owner = "nwg-piotr"; repo = "nwg-hello"; rev = "v${version}"; hash = "sha256-+D89QTFUV7/dhfcOWnQshG8USh35Vdm/QPHbsxiV0j0="; }; nativeBuildInputs = [ gobject-introspection wrapGAppsHook ]; buildInputs = [ gtk3 gtk-layer-shell ]; propagatedBuildInputs = [ python3Packages.pygobject3 ]; postPatch = '' # hard coded paths substituteInPlace nwg_hello/main.py  --replace '/etc/nwg-hello' "$out/etc/nwg-hello"  --replace "/usr/share/xsessions" "/run/current-system/sw/share/xsessions"  --replace "/usr/share/wayland-sessions" "/run/current-system/sw/share/wayland-sessions" substituteInPlace nwg-hello-default.json  --replace "/usr/share/xsessions" "/run/current-system/sw/share/xsessions"  --replace "/usr/share/wayland-sessions" "/run/current-system/sw/share/wayland-sessions" substituteInPlace nwg_hello/ui.py --replace '/usr/share/nwg-hello' "$out/share/nwg-hello" ''; postInstall = '' install -D -m 644 -t "$out/etc/nwg-hello/" nwg-hello-default.json nwg-hello-default.css hyprland.conf sway-config README install -D -m 644 -t "$out/share/nwg-hello/" nwg.jpg install -D -m 644 -t "$out/share/nwg-hello/" img/* ''; # Upstream has no tests doCheck = false; pythonImportsCheck = [ "nwg_hello" ]; meta = { homepage = "https://github.com/nwg-piotr/nwg-hello"; description = "GTK3-based greeter for the greetd daemon, written in python"; license = lib.licenses.mit; platforms = lib.platforms.linux; maintainers = [ ]; mainProgram = "nwg-hello"; }; } </ins>

Discussion:
GTK3-based greeter for greetd written in python <!-- Describe the project a little: --Metadata homepage URL: source URL: license: MIT platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { lib, python3, fetchFromGitHub, nixosTests }: </del> <ins> { lib, python3, fetchFromGitHub, nixosTests, wrapGAppsNoGuiHook, gobject-introspection, glib }: </ins> python3.pkgs.buildPythonApplication rec { pname = "targetcli";

Discussion:
it's impossible to use due to an import error: Steps to reproduce the behavior: to run eg ratbagctl "shows something". (i.e. current mouse hardware/mapping etc.) (no gui, cli only) I (may) need because it has infos/options that are not yet fully implemented in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.

As title says, openrazer-daemon no longer work after update. Steps to reproduce the behavior: system -daemon fail to start. Openrazer-daemon start on boot. If applicable, add screenshots to help explain your problem. Manually calling openrazer-daemon -Fv print me this: <!-- 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]:
overlay fix for anyone who have this issue.
This overlay fix worked for me, thank you!
Change:
<del> { lib, stdenv, fetchurl, appimageTools, makeWrapper, electron_21, libsecret }: </del> <ins> { lib, stdenv, fetchurl, appimageTools, makeWrapper, electron_24, libsecret }: </ins> stdenv.mkDerivation rec { pname = "todoist-electron"; <del> version = "1.0.9"; </del> <ins> version = "8.3.3"; </ins> src = fetchurl { <del> url = "https://electron-dl.todoist.com/linux/Todoist-${version}.AppImage"; sha256 = "sha256-DfNFDiGYTFGetVRlAjpV/cdWcGzRDEGZjR0Dc9aAtXc="; </del> <ins> url = "https://electron-dl.todoist.com/linux/Todoist-linux-x86_64-${version}.AppImage"; hash = "sha256-X928hCrYVOBTEZq1hmZWgWlabtOzQrLUuptF/SJcAto="; </ins> }; appimageContents = appimageTools.extractType2 {

Discussion:
Package name: todoist-electron Latest released version: 1.1.2 Current version on the unstable channel: 1.0.9 Current version on the stable/release channel: 1.0.9 currently depends on which is EOL. I don't know how to determine from the appimage which version of Electron upstream is using. 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.
, upstream is way behind, I checked the appimage with appimage-run: unfortunately, overriding electron21 with electron22 seems to break login. I opened a support ticket () asking if they have plans to update to a newer Electron version any time soon.
Change:
<del> diff --git a/cmd/main.go b/cmd/main.go index ede7cd8..c553140 100644 --- a/cmd/main.go +++ b/cmd/main.go @@ -401,8 +401,11 @@ func splitWith(arg string) (module, version, replace string, err error) { return } +var customVersion string + // xcaddyVersion returns a detailed version string, if available. func xcaddyVersion() string { +	return customVersion mod := goModule() ver := mod.Version if mod.Sum != "" { </del>

Discussion:
Caddy fails to build for riscv64 Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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]:
(please fill out more parts of the bug report template next time) Assuming this is , likely an instance of . Pinging maintainers:
Hi, thanks for the ping :) The fix for this is fairly trivial. Either skip the shell completions/man pages[^1], or use something like But I am upset that you ( didn't even care enough to do the bare minimum and fill out the issue template. [^1]: Technically only the kills the build, not the , because bash pipefail defaults.
i'm sorry for the issue template, it was more of a quick note to myself. i'll do it right next time
Change:
- `nixos/lib/make-disk-image.nix` can now mutate EFI variables, run user-provided EFI firmware or variable templates. This is now extensively documented in the NixOS manual. <ins> - `services.grafana` listens only on localhost by default again. This was changed to upstreams default of `0.0.0.0` by accident in the freeform setting conversion. </ins> - A new `virtualisation.rosetta` module was added to allow running `x86_64` binaries through [Rosetta](https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment) inside virtualised NixOS guests on Apple silicon. This feature works by default with the [UTM](https://docs.getutm.app/) virtualisation [package](https://search.nixos.org/packages?channel=unstable&show=utm&from=0&size=1&sort=relevance&type=packages&query=utm). - The new option `users.motdFile` allows configuring a Message Of The Day that can be updated dynamically.

Discussion:
changed on which address Grafana listens by default. Previously (under 22.05) it was localhost only and it was necessary to explicitly adjust this if so desired. Now (with 22.11) Grafana is listening on all IPs. Previously: New default is to listen on all IPs: Without enabled (and properly configured) firewall this could result in situations where people are exposing their Grafana installation unintentionally.
but the default settings should suffice to catch this, right? This also matches the upstream grafana default
Yes, I would think so. Therefore not really dramatic in most cases.
Change:
"-DAPICORE=ON" "-DETHDBUS=OFF" "-DCMAKE_BUILD_TYPE=Release" <del> ] ++ lib.optionals (!cudaSupport) [ </del> <ins> ] ++ (if cudaSupport then [ "-DCUDA_PROPAGATE_HOST_FLAGS=off" ] else [ </ins> "-DETHASHCUDA=OFF" # on by default <del> ]; </del> <ins> ]); </ins> nativeBuildInputs = [ cmake

Discussion:
Describe the bug I'm not sure what's exactly going on here, but it looks like the build is attempting to use gcc10 includes from somewhere, while the default nvcc from cudatoolkit only supports gcc9 at best. Maybe someone better versed with how cmake works on NixOS could take a look? To Reproduce Steps to reproduce the behavior: to build from nixpkgs (). Expected behavior The package builds successfully with CUDA support. Additional context Persists after version bump Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Maintainer information:
Change:
githubId = 1943632; name = "fro_ozen"; }; <ins> frogamic = { email = "frogamic@protonmail.com"; github = "frogamic"; githubId = 10263813; name = "Dominic Shelton"; }; </ins> Frostman = { email = "me@slukjanov.name"; github = "Frostman";

Discussion:
Project description This is an [x-]cursor theme designed to look decent. Includes light and dark cursors Metadata homepage URL: license: GPL3 + CC BY-SA 4.0) platforms: unix? linux?
Change:
- The `bind` module now allows the per-zone `allow-query` setting to be configured (previously it was hard-coded to `any`; it still defaults to `any` to retain compatibility). <ins> - `make-disk-image` handles `contents` arguments that are directories better, fixing a bug where it used to put them in a subdirectory of the intended `target`. </ins> ## Detailed migration information {#sec-release-23.05-migration} ### Pipewire configuration overrides {#sec-release-23.05-migration-pipewire}

Discussion:
takes an argument that copies source paths into the resulting VM image. It seems to work fine when the sources are files or , but when copying directories, they end up nested inside the target directory named with a nix-store-like path. This is not what I expected, it is hard to use, and I do not think it is the intended behavior. these files: (and additional , see attached ). the VM image with . the VM image, e.g. with . in with credentials literal . that contains a subdirectory with a Nix-store-like path, e.g. instead of . I expected that the source would end up at the target, as happens with contents objects that are files. ! I will have a PR with a test and fix up soon. When changing the behavior of a function that is already widely used, even fixing a bug can cause problems for people. I checked, but I did not find any existing usages of with directories in . And given how broken the directory support seems, I suspect that it is not actually used in the wild, so I think it is okay to fix this behavior. Please run and paste the result.
Change:
{ lib, stdenv, fetchFromGitHub <ins> , fetchpatch </ins> , addOpenGLRunpath , wrapGAppsHook , cmake

Discussion:
Steps to reproduce the behavior: the following : the flake: cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oddly enough, (the original PR ) actually fails as well. Result of run on x86_64-linux <details<summary1 package failed to build:</summary<ul<licemu</li</ul</details
Change:
++ lib.optionals (atLeast "9.6" && !stdenv.isDarwin) [ systemd ] ++ lib.optionals (!stdenv.isDarwin) [ libossp_uuid ]; <del> enableParallelBuilding = true; </del> <ins> enableParallelBuilding = !stdenv.isDarwin; </ins> makeFlags = [ "world" ];

Discussion:
While trying to I was unable to build . The important lines from the build log () seem to be: The build succeeds with This build may fail: (While it points to a commit in my fork of nixpkgs, this fork does not change the package. It updates something that depends on which I still haven't got building on Darwin.) :
; seems to be related.
Do we know if that failure in the IRC logs you linked was on Darwin? We could disable parallel building on Darwin, but if this affects Linux too we'd be better doing both.
Doesn't hurt to propose it for Darwin now, I guess. Can always add Linux later.
I think it built correctly on my GNU/Linux machine, but since this is possibly a non-deterministic failure that's not strong evidence for anything in particular.
It would be nice to have this reported upstream as well.
Done. It should show up on soon, but hasn't yet.
There now:
you should probably reply to this:
Is there any strong evidence this failure is linked to parallel building? From what I read in the error log, this is happening within the "ar rcs" command. I don't see why make -j would directly influence this.
my guess is that it's trying to open a file that hasn't been created yet, because of a incorrect dependency graph – if that were the case, would make sense that disabling parallel building would fix it.
Agreed with your reading that it appears to happen within the , but all I can say is that it was repeatedly failing to build, then passed with .
but that's the thing -- ar should be the command creating the archive. I don't see how this could be a make parallelism problem if the same command (at the Makefile level) which creates the .a also fails to read it for one of its steps. This seems like papering over an issue that's not properly understood.
I see what you mean. It could indeed be something different, and if we see it again after disabling parallel builds I'm more than happy to be reverted, but I think it's worth a shot, given what says.
I found which seems to discuss a similar problem with races in ranlib invocations on macOS. I note that the build log calls multiple times. Is it possible that they are stepping over each other?
I think that's indeed what's happening.

Starting in 9.1.0 (postgres/postgres this is in the postgres codebase: If both of these end up happening in parallel then they would race over libpgtypes.a. Can you pass this back to upstream? I can't easily reply to the existing thread...
Will do ; I need to reply to the thread there anyway.
Reported findings upstream:
Change:
<del> {lib, python3Packages, fetchpatch, gettext, qt5, fetchFromGitHub}: </del> <ins> {lib, python3Packages, gettext, qt5, fetchFromGitHub}: </ins> python3Packages.buildPythonApplication rec { pname = "dupeguru"; <del> version = "4.0.4"; </del> <ins> version = "4.1.1"; </ins> format = "other";

Discussion:
Describe the bug Running gives the following error message: To Reproduce Steps to reproduce the behavior: . . Notify maintainers Metadata
I marked this as stale due to inactivity. &rarr;
This is still an issue.
I can confirm the bug.
Change:
<del> { lib, fetchFromGitHub, crystal_0_36, openssl }: </del> <ins> { lib, fetchFromGitHub, crystal_1_0, openssl }: </ins> let <del> crystal = crystal_0_36; </del> <ins> crystal = crystal_1_0; </ins> in crystal.buildCrystalPackage rec { <del> version = "0.11.0"; </del> <ins> version = "0.14.0"; </ins> pname = "mint"; src = fetchFromGitHub { owner = "mint-lang"; repo = "mint"; rev = version; <del> sha256 = "sha256-QqO4Kc8hf6WNCENPvLwYIF9gtXG/VRR7DhyZvxB4VsA="; </del> <ins> sha256 = "1mf9d0jpdb21hkzaqvwyx2171dv3hr50zhl07p85wpf0d3n5wml8"; </ins> }; postPatch = ''

Discussion:
current version: 0.11.0 desired version: 0.12.0 Would you be able to share the workflow/commands/tools that you go through to upgrade mint? I know it might be a lot to ask but it would be much appreciated. I'd be happy to help with also keeping this package up to date.
Fork nixpkgs and clone it Checkout a new branch Take the latest ver and replace the version in Replace the sha256 with 52 zeroes ( easy to do in vim 52i0<esc) in nixpkgs then copy the sha256 it gives you and replace the zeroes with it cd to the mint dir, run , move the .nix file you get in to the same dir as the mint again, if it works then create a commit and a pr If you need to edit the commit https://git-
Sorry to leave you hanging steps should do the trick.
No worries! I was able to get up to running the nix-shell that suggested but I get the following error: I then tried installing crystal2nix 0.1.1 from and I get the following error: Any suggestions of what I should try next?
did you run crystal2nix in the mint repo?
also, you need to bump the crystal version to
you test it and make a pr
I tried both your suggestions but now I get the following error: This is what my generated looks like: This is what my looks like: This is what my looks like: Anything else I might be doing wrong?
sorry for not responding. you changed format to when its supposed to be just shards
thanks! I'll keep that in mind for the next time around. Thanks for updating mint :)
Change:
done install -d        $out/share/fcitx/imicon <del> install    -m 644 fcitx-mozc-icons/mozc.png                 $out/share/fcitx/imicon/mozc.png </del> <ins> install    -m 644 fcitx-mozc-icons/mozc.png      $out/share/fcitx/imicon/mozc.png </ins> install -d        $out/share/fcitx/mozc/icon <del> install    -m 644 fcitx-mozc-icons/mozc.png                 $out/share/fcitx/mozc/icon/mozc.png install    -m 644 fcitx-mozc-icons/mozc-alpha_full.png      $out/share/fcitx/mozc/icon/mozc-alpha_full.png install    -m 644 fcitx-mozc-icons/mozc-alpha_half.png      $out/share/fcitx/mozc/icon/mozc-alpha_half.png install    -m 644 fcitx-mozc-icons/mozc-direct.png          $out/share/fcitx/mozc/icon/mozc-direct.png install    -m 644 fcitx-mozc-icons/mozc-hiragana.png        $out/share/fcitx/mozc/icon/mozc-hiragana.png install    -m 644 fcitx-mozc-icons/mozc-katakana_full.png   $out/share/fcitx/mozc/icon/mozc-katakana_full.png install    -m 644 fcitx-mozc-icons/mozc-katakana_half.png   $out/share/fcitx/mozc/icon/mozc-katakana_half.png install    -m 644 fcitx-mozc-icons/mozc-dictionary.png      $out/share/fcitx/mozc/icon/mozc-dictionary.png install    -m 644 fcitx-mozc-icons/mozc-properties.png      $out/share/fcitx/mozc/icon/mozc-properties.png install    -m 644 fcitx-mozc-icons/mozc-tool.png            $out/share/fcitx/mozc/icon/mozc-tool.png </del> <ins> install    -m 644 fcitx-mozc-icons/*.png                 $out/share/fcitx/mozc/icon/ </ins> ''; meta = with clangStdenv.lib; {

Discussion:
after a , fcitx cannot switch to mozc only in chromium. journalctl gives me System: (NixOS: , Ubuntu/Fedora: , ...) 09pre106117. (Hummingbird) Nix version: (run ) nix-env (Nix) 1.11.8 Nixpkgs version: (run ) "17.09pre106117." fcitx version: 4.2.9.1 Chromium 57.0.2987.133
Thanks for reporting! Will look into this.