jiebi/CodeConvo huggingface dataset:
Change:
In the documentation of (stable and unstable), the option states the following: In the referenced documentation of (stable and unstable), two meanings of are described. The second one reads as follows: However, when e.g. is configured as , an error is returned. Used NixOS configuration: Log of : I'm not sure weather this is a documentation problem or a bug. We should either make it clear in the documentation, that with only can be used, or allow the usage of . <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the documentation on is valid only for that command. The value of is passed to . As that manual page says, corresponds to , where is a fixed special value. It may be a bit confusing because you have to wire those different things up in your head while reading. Adding a few links would certainly help. But otherwise documentation and option behavior is correct.

Discussion:
example = "--max-freed $((64 * 1024**3))"; type = lib.types.singleLineStr; description = lib.mdDoc '' <del> Options given to {file}`nix-collect-garbage` when the garbage collector is run automatically. </del> <ins> Options given to [`nix-collect-garbage`](https://nixos.org/manual/nix/stable/command-ref/nix-collect-garbage) when the garbage collector is run automatically. </ins> ''; };
Change:
Steps to reproduce the behavior: This might be broken since but I did not bisect. maintainer: author of : Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can confirm that broke the test. One solution would be to override the urwid version khal uses. I also suggest opening an upstream issue.

Discussion:
, python3 }: <del> python3.pkgs.buildPythonApplication rec { </del> <ins> let py = python3.override { packageOverrides = self: super: { # Doesn't work with latest urwid urwid = super.urwid.overridePythonAttrs (oldAttrs: rec { version = "2.1.2"; src = fetchFromGitHub { owner = "urwid"; repo = "urwid"; rev = "refs/tags/${version}"; hash = "sha256-oPb2h/+gaqkZTXIiESjExMfBNnOzDvoMkXvkZ/+KVwo="; }; doCheck = false; }); }; }; in with py.pkgs; buildPythonApplication rec { </ins> pname = "khal"; version = "0.11.2"; <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "pimutils"; <del> repo = pname; rev = "v${version}"; </del> <ins> repo = "khal"; rev = "refs/tags/v${version}"; </ins> hash = "sha256-yI33pB/t+UISvSbLUzmsZqBxLF6r8R3j9iPNeosKcYw="; };

glibcLocales installShellFiles ] ++ (with python3.pkgs; [ <ins> setuptools </ins> setuptools-scm sphinx sphinxcontrib-newsfeed ]); <del> propagatedBuildInputs = with python3.pkgs;[ </del> <ins> propagatedBuildInputs = with py.pkgs;[ </ins> atomicwrites click click-log

meta = with lib; { description = "CLI calendar application"; homepage = "http://lostpackets.de/khal/"; <ins> changelog = "https://github.com/pimutils/khal/releases/tag/v${version}"; </ins> license = licenses.mit; maintainers = with maintainers; [ gebner ]; };
Change:
Steps to reproduce the behavior: I'm trying to build an host from I've historically disabled the option whenever cross-compiling However, it seems like a relatively simple program, merely limited by the good ole bare Makefile. And my aarch64 sbc would benefit from a wifi adapter that needs this module/package. I was going to dive in and try to just make it a meson project, but then I realized we already carry a patch for the Makefile, so I figured I'd open this before I forget, in case I don't have time to dig in: 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. --This is on the latest usb-modeswitch rev from 2019, from : Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
sha256 = "18wbbxc5cfsmikba0msdvd5qlaga27b32nhrzicyd9mdddp265f2"; }; <del> patches = [ ./configurable-usb-modeswitch.patch ]; </del> <ins> patches = [ ./configurable-usb-modeswitch.patch ./pkg-config.patch ]; </ins> # Remove attempts to write to /etc and /var/lib. postPatch = ''

<ins> diff --git a/Makefile b/Makefile index 9aa7356..c5f2a87 100644 --- a/Makefile +++ b/Makefile @@ -2,7 +2,8 @@ PROG        = usb_modeswitch VERS        = 2.6.0 CC          ?= gcc CFLAGS      += -Wall -Wno-deprecated-declarations -LIBS        = `pkg-config --libs --cflags libusb-1.0` +PKG_CONFIG  ?= pkg-config +LIBS        = `$(PKG_CONFIG) --libs --cflags libusb-1.0` RM          = /bin/rm -f OBJS        = usb_modeswitch.c PREFIX      = $(DESTDIR)/usr </ins>
Change:
The Syncthing project recently released a fix for a security vulnerability, the symlink attack described here: The issue was fixed in Syncthing 0.14.35. However, this release contained a serious bug, so 0.14.36 should be used instead.
cc
14.36 was already in master but now 17.03 has been updated too. Thanks for spotting this

Discussion:
<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.15.2"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.15/${name}.tar.xz"; sha256 = "0g71zq6dpqrw2f40wfzdf18fdw41ymr17laqniy2kr622hkxdi8w"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

<ins> {stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { version = "0.16.1"; name = "vala-${version}"; src = fetchurl { url = "mirror://gnome/sources/vala/0.16/${name}.tar.xz"; sha256 = "1n708n9ixyy9qrzyv1wf4ybvcclx43ib9ki028wwpvkz6kv8zqlb"; }; buildNativeInputs = [ yacc flex pkgconfig xz ]; buildInputs = [ glib ]; meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; }; } </ins>

{stdenv, fetchurl, yacc, flex, pkgconfig, glib, xz}: stdenv.mkDerivation rec { <del> name = "vala-0.14.2"; </del> <ins> version = "0.17.2"; name = "vala-${version}"; </ins> src = fetchurl { <del> url = mirror://gnome/sources/vala/0.14/vala-0.14.2.tar.xz; sha256 = "1l5kllw9vpwv24lzv9fp64l3sad46wpxgvsgryrwlrjg91w6jzl0"; </del> <ins> url = "mirror://gnome/sources/vala/0.17/${name}.tar.xz"; sha256 = "09i2s0dwmrk147ind2dx7nq845g12fp6fsjqrphhrr0dbi0zzgh3"; </ins> }; buildNativeInputs = [ yacc flex pkgconfig xz ];

meta = { description = "Compiler for the GObject type system"; homepage = "http://live.gnome.org/Vala"; <ins> license = "free-copyleft"; platforms = stdenv.lib.platforms.all; maintainers = [ stdenv.lib.maintainers.antono ]; </ins> }; }

urweb = callPackage ../development/compilers/urweb { }; <del> vala = callPackage ../development/compilers/vala { }; </del> <ins> vala = vala17; vala15 = callPackage ../development/compilers/vala/15.2.nix { }; vala16 = callPackage ../development/compilers/vala/16.1.nix { }; vala17 = callPackage ../development/compilers/vala/default.nix { }; </ins> visualcpp = callPackage ../development/compilers/visual-c++ { };
Change:
Project description <!-- 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]:

Discussion:
<ins> { lib , rustPlatform , fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "obsidian-export"; version = "23.12.0"; src = fetchFromGitHub { owner = "zoni"; repo = "obsidian-export"; rev = "v${version}"; hash = "sha256-r5G2XVV2F/Bt29gxuTZKX+KxH6RFa1hJNH3gSTi7yCU="; }; cargoHash = "sha256-lkqoMFasHpfhmVd3dlYd/TKIBIDzqMbsxfigpeJq0w8="; meta = { changelog = "https://github.com/zoni/obsidian-export/blob/${src.rev}/CHANGELOG.md"; description = "Rust library and CLI to export an Obsidian vault to regular Markdown"; homepage = "https://github.com/zoni/obsidian-export"; license = lib.licenses.bsd2Patent; mainProgram = "obsidian-export"; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>
Change:
Incus fails to find when launching a VM. (There is no problem launching a container.) It exits with the error message: Lines 1815-1824 of in the looks for it at or in the path. I think it means that there is a fixup that isn't being done. Steps to reproduce the behavior: (The specific image doesn't seem to matter.) while the VM is created... It exits with the error message above. that is installed at just not being found. Launching a VM should work as expected without the error message. <!-- 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]:
While that path does appear to be hardcoded in Incus, I'm not able to recreate the error on my zfs storage pool. Can you provide more information about your storage setup, including the output of
Never mind I see the problem. Will take some time to get this reviewed, backported, and available to 23.11

Discussion:
"network-online.target" ]; <del> path = lib.mkIf config.boot.zfs.enabled [ config.boot.zfs.package ]; </del> <ins> path = lib.mkIf config.boot.zfs.enabled [ config.boot.zfs.package "${config.boot.zfs.package}/lib/udev" ]; </ins> environment = { # Override Path to the LXC template configuration directory
Change:
Package name: rgbds Latest released version: 0.7.0 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.6.1 <!-- 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]:

Discussion:
stdenv.mkDerivation rec { pname = "rgbds"; <del> version = "0.6.1"; </del> <ins> version = "0.7.0"; </ins> src = fetchFromGitHub { owner = "gbdev"; repo = "rgbds"; rev = "v${version}"; <del> sha256 = "sha256-3mx4yymrOQnP5aJCzPWl5G96WBxt1ixU6tdzhhOsF04="; </del> <ins> hash = "sha256-aktKJlwXpHpjSFxoz5wZJPGWZIcn4ax5iBP0GQEux78="; </ins> }; nativeBuildInputs = [ bison flex pkg-config ]; buildInputs = [ libpng ]; <ins> postPatch = '' patchShebangs --host src/bison.sh ''; </ins> env.NIX_CFLAGS_COMPILE = lib.optionalString stdenv.isDarwin "-fno-lto"; installFlags = [ "PREFIX=${placeholder "out"}" ];
Change:
Steps to reproduce the behavior: ytcc directly from () that the build fails This could in fact be a upstream problem, as they haven't updated their build system since at least Oct 22, 2022. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
python3Packages.buildPythonApplication rec { pname = "ytcc"; version = "2.6.1"; <del> format = "pyproject"; </del> <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "woefe"; repo = "ytcc"; rev = "v${version}"; <del> sha256 = "sha256-pC2uoog+nev/Xa6UbXX4vX00VQQLHtZzbVkxrxO/Pg8="; </del> <ins> hash = "sha256-pC2uoog+nev/Xa6UbXX4vX00VQQLHtZzbVkxrxO/Pg8="; </ins> }; <del> nativeBuildInputs = [ gettext installShellFiles ]; </del> <ins> nativeBuildInputs = [ gettext installShellFiles ] ++ (with python3Packages; [ setuptools ]); </ins> propagatedBuildInputs = with python3Packages; [ yt-dlp

wcwidth ]; <del> nativeCheckInputs = with python3Packages; [ nose pytestCheckHook ]; </del> <ins> nativeCheckInputs = with python3Packages; [ pytestCheckHook ]; </ins> # Disable tests that touch network or shell out to commands disabledTests = [
Change:
Please see the build logs of librewolf here: You can find for the first build. The second build should have set, but it's not there. I also think the current way of doing PGO can be improved. I am working on splitting the derivation into two, one for profile generation and one for profile use, which should also make investigating this problem easier. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
So for some reason extending does not affect the resulting configure flags. Not yet sure why.
Bisected to commit Author: Artturin <: Wed Jun 1 00:34:59 2022 +0300 stdenv: support opt-in _structuredAttrs Co-authored-by: Robin Gloster <: print message if structuredAttrs is enabled stdenv: add append reduces the chance of a user doing it wrong fix nix develop issue output hooks don't work yet in nix develop though making $outputs be the same on non-structuredAttrs and structuredAttrs is too much trouble. lets instead make a function that gets the output names reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin' nix: std::string Common::makeRcScript(nix::ref<nix::Store, const BuildEnvironment&, const Path&): Assertion `outputs != ()' failed. use a function to get all output names instead of using $outputs copy env functionality from .../cluster/nomad- | 2 +- pkgs/build-support/bintools- | 4 +- pkgs/build-support/release/nix- | 2 +- pkgs/build-support/setup-hooks/auto- | 2 +- pkgs/build-support/setup-hooks/move- | 12 +- pkgs/build-support/setup-hooks/multiple- | 34 ++-- .../setup-hooks/patch-ppd-files/patch-ppd- | 2 +- pkgs/build-support/setup- | 21 +- pkgs/build-support/setup-hooks/win-dll- | 2 +- pkgs/build-support/testers/expect- | 2 +- pkgs/data/icons/catppuccin- | 2 +- | 2 +- | 2 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 4 +- | 2 +- .../darwin/signing-utils/auto-sign- | 2 +- pkgs/stdenv/generic/default- | 4 + pkgs/stdenv/generic/make- | 31 ++- | 222 ++++++++++++++++----- | 2 +- 29 files changed, 272 insertions(+), 120 deletions(-)

Discussion:
unset 'configureFlagsArray[i]' fi done <del> configureFlagsArray+=( "--enable-profile-use=cross" "--with-pgo-profile-path="$TMPDIR/merged.profdata"" "--with-pgo-jarlog="$TMPDIR/jarlog"" ) </del> <ins> appendToVar configureFlags --enable-profile-use=cross appendToVar configureFlags --with-pgo-profile-path=$TMPDIR/merged.profdata appendToVar configureFlags --with-pgo-jarlog=$TMPDIR/jarlog </ins> ${lib.optionalString stdenv.hostPlatform.isMusl '' LDFLAGS="$OLD_LDFLAGS" unset OLD_LDFLAGS
Change:
Steps to reproduce the behavior: kodi-inputstream-ffmpegdirect on the unstable channel log here if short otherwise a link to a gist ` 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]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
upstream fix:

Discussion:
buildKodiBinaryAddon rec { pname = "inputstream-ffmpegdirect"; namespace = "inputstream.ffmpegdirect"; <del> version = "20.5.0"; </del> <ins> version = "unstable-20.5.0"; </ins> src = fetchFromGitHub { owner = "xbmc"; repo = "inputstream.ffmpegdirect"; <del> rev = "${version}-${rel}"; sha256 = "sha256-2Xa5q+o/AYDwG+JYeXTUfMTJk/kln16J8KRcXILNE6c="; </del> <ins> rev = rel; sha256 = "sha256-+u28Wzp2TonL5jaa5WJUr9igR6KiaxizZAX9jqqBUns="; </ins> }; extraBuildInputs = [ bzip2 zlib kodi.ffmpeg ];
Change:
This is regarding hydra build failure. Thanks to a matrix user for pointing out the hydra link! Thank you! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Discussion:
# Test flaky because of our RPATH patching # https://github.com/NixOS/nixpkgs/pull/230965#issuecomment-1545336489 "compiler/codegen" <ins> # Test flaky "read" </ins> ] ++ lib.optionals (lib.versionAtLeast version "1.10") [ # Test flaky # https://github.com/JuliaLang/julia/issues/52739 "REPL" <ins> # Test flaky "ccall" </ins> ] ++ lib.optionals stdenv.isDarwin [ # Test flaky on ofborg "FileWatching"

-rm -f $(DESTDIR)$(datarootdir)/julia/base/version_git.sh -rm -f $(DESTDIR)$(datarootdir)/julia/test/Makefile -- <del> 2.42.0 </del> <ins> 2.43.0 </ins>

<del> From c7e2f6ed00c170b68d5d156faac38aa76d4490fd Mon Sep 17 00:00:00 2001 </del> <ins> From 9da2f2596db9f4f1a61825d82d9b8c3f3b2e99aa Mon Sep 17 00:00:00 2001 </ins> From: Nick Cao <nickcao@nichi.co> Date: Wed, 10 Jan 2024 20:58:20 -0500 Subject: [PATCH 2/2] skip failing and flaky tests

1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile b/test/Makefile <del> index 88dbe5b2b4..f0bdedfdf5 100644 </del> <ins> index 88dbe5b2b4..a2a7a55e20 100644 </ins> --- a/test/Makefile +++ b/test/Makefile @@ -28,7 +28,7 @@ default:

$(TESTS): @cd $(SRCDIR) &&  -	$(call PRINT_JULIA, $(call spawn,$(JULIA_EXECUTABLE)) --check-bounds=yes --startup-file=no --depwarn=error ./runtests.jl $@) <del> +	$(call PRINT_JULIA, $(call spawn,$(JULIA_EXECUTABLE)) --check-bounds=yes --startup-file=no --depwarn=error ./runtests.jl --skip NetworkOptions REPL channels $@) </del> <ins> +	$(call PRINT_JULIA, $(call spawn,$(JULIA_EXECUTABLE)) --check-bounds=yes --startup-file=no --depwarn=error ./runtests.jl --skip NetworkOptions REPL channels FileWatching ccall $@) </ins> $(addprefix revise-, $(TESTS)): revise-% : @cd $(SRCDIR) &&  -- <del> 2.42.0 </del> <ins> 2.43.0 </ins>
Change:
Because systemd-boot- gets stored straight up as (as a file in ), Python imports will crawl through the whole directory to try and find local .py files that can be imported. This can take very long and a lot of RAM. We hit into this on which has 40M entries in its right now, causing to take 5-10minutes and 10GB of RAM to execute. Steps to reproduce the behavior: up your with a LOT of entries to a new configuration with systemd-boot as the configured bootloader. Switching to a new configuration doesn't take 5+ minutes and 10GB of RAM, but is instead near-instantaneous. n/a Stack trace taken 1min into the execution of the script showing it's stuck trying to import stuff: This is on NixOS 23.05 but I don't see any change that would impact this in 23.11 or master. Would love a backport all the way to 23.05 if possible since we still haven't updated :) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Just to track the backport.
Maybe needs to be spinned off into a separate issue, but I think there are more Python scripts affected by this, such as or . Quick search:
No strong opinion, I don't personally care about getting those fixed right now so it might be easier if you filed it as a new issue if you're interested in working on it.
Will close this because this specific issue is solved, but feel free to open other issues for the other python scripts that suffer from this problem.

Discussion:
checkedSystemdBootBuilder = pkgs.runCommand "systemd-boot" { nativeBuildInputs = [ pkgs.mypy ]; } '' <del> install -m755 ${systemdBootBuilder} $out </del> <ins> mkdir -p $out/bin install -m755 ${systemdBootBuilder} $out/bin/systemd-boot-builder </ins> mypy  --no-implicit-optional  --disallow-untyped-calls  --disallow-untyped-defs  <del> $out </del> <ins> $out/bin/systemd-boot-builder </ins> ''; finalSystemdBootBuilder = pkgs.writeScript "install-systemd-boot.sh" '' #!${pkgs.runtimeShell} <del> ${checkedSystemdBootBuilder} "$@" </del> <ins> ${checkedSystemdBootBuilder}/bin/systemd-boot-builder "$@" </ins> ${cfg.extraInstallCommands} ''; in {
Change:
Package name: most Latest released version: 5.2.0 <!-- Search your package here: --- Current version on the unstable channel: 5.1.0 Current version on the stable/release channel: 5.1.0 <!-- 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]:

Discussion:
stdenv.mkDerivation rec { pname = "most"; <del> version = "5.1.0"; </del> <ins> version = "5.2.0"; </ins> src = fetchurl { url = "https://www.jedsoft.org/releases/${pname}/${pname}-${version}.tar.gz"; <del> sha256 = "008537ns659pw2aag15imwjrxj73j26aqq90h285is6kz8gmv06v"; </del> <ins> hash = "sha256-lFWuuPgm+oOFyFDcIr8PIs+QabPDQj+6S/LG9iJtmQM="; </ins> }; <del> patches = [ # Upstream patch to fix parallel build failure ./parallel-make.patch ]; </del> outputs = [ "out" "doc" ]; makeFlags = [

<del> Upstream commit c9cfad50a ("src/Makefile.in: Avoid a race condition when performing a parallel build") --- a/src/Makefile.in +++ b/src/Makefile.in @@ -54,6 +54,12 @@ COMPILE_CMD = $(CC) -c $(ALL_CFLAGS) -DMOST_SYSTEM_INITFILE='"$(SYS_INITFILE)"' all: $(EXEC) $(EXEC): $(OBJDIR) $(CONFIG_H) slangversion $(OBJDIR)/$(EXEC) @echo $(EXEC) created in $(OBJDIR) + +# C source files include autogenrated "config.h". Make sure +# it's available before the compilation. Pessimistically assume +# any source file can depend on "config.h". +$(OBJS) $(OBJDIR)/chkslang.o: $(CONFIG_H) + $(OBJDIR)/$(EXEC): $(OBJS) cd $(OBJDIR); $(CC) $(OFILES) -o $(EXEC) $(LDFLAGS) $(EXECLIBS) # </del>