jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , setuptools , libnotify , pytestCheckHook }: buildPythonPackage rec { pname = "pynotifier"; version = "0.5.0"; pyproject = true; src = fetchFromGitHub { owner = "YuriyLisovskiy"; repo = "pynotifier"; rev = version; hash = "sha256-xS3hH3cyqgDD7uoWkIYXpQAh7SN7XJ/qMfB0Vq5bva0="; }; postPatch = '' substituteInPlace pynotifier/backends/platform/linux.py  --replace-fail  'shutil.which("notify-send")'  '"${lib.getExe' libnotify "notify-send"}"' ''; nativeBuildInputs = [ setuptools ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "pynotifier" ]; meta = with lib; { description = "Module for sending notifications"; homepage = "https://github.com/YuriyLisovskiy/pynotifier"; license = licenses.mit; maintainers = with maintainers; [ pbsds ]; }; } </ins>

Discussion:
Project description Python3 module for sending notifications. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...
Check out , it helps with automating the packaging process of many packages.
please test
Change:
, lib , fetchurl , substituteAll <ins> , autoreconfHook </ins> , pkgconfig , intltool , babl

Discussion:
Describe the bug GIMP uses Python and GTK+ for e.g. plugins. But GIMP in the NixOS-GIMP-package cannot find the Python-gtk-module: GIMP itself starts, but e.g. some plugins cannot be used, e.g. . When selecting this plugin, nothing happens, and the following error is shown in the console (again): To Reproduce Steps to reproduce the behavior: GIMP. GIMP. at the error-messages. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can confirm this still doesn't work. Of note is that installing will allow when used from the REPL, but GIMP will still not recognize it. Tagging since they are tagged as the maintainer.

I see the following warnings when running gimp: Not sure if they are critical or not. I do have problems with one Python plugin, not sure if this could be related. Run gimp from the terminal. I'm running it from i3+none desktop environment, if that matters. Please run and paste the results.
I can see the warning too. This is what the file looks like on Arch: nothing special compared to ours: The file exists and is executable Not really sure what is wrong. Also the Python scripts seem to work, at least does.
For me, resynthesizer runs but it doesn't produce correct results:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me. This is the current console output:
I have found this issue can be fixed by installing the python package by yourself (which is weird: it looks like GIMP may be trying to use the command from your ). I have it in my systemPackages and I got past that stage. However, is still blocking the usage of some plugins.
Spent some time in and it looks like the extension mapping from file only searches in path, not in the mapping described on previous lines and registered in : : The extension is so some other mechanism than extension matching must be involved – perhaps shebangs are applied. We will still want to hardcode the path to ensure purity.
Change:
<ins> { stdenv, ghdl-llvm, ghdl-mcode, backend }: let ghdl = if backend == "llvm" then ghdl-llvm else ghdl-mcode; in stdenv.mkDerivation { name = "ghdl-test-simple"; meta.timeout = 300; nativeBuildInputs = [ ghdl ]; buildCommand = '' cp ${./simple.vhd} simple.vhd cp ${./simple-tb.vhd} simple-tb.vhd mkdir -p ghdlwork ghdl -a --workdir=ghdlwork --ieee=synopsys simple.vhd simple-tb.vhd ghdl -e --workdir=ghdlwork --ieee=synopsys -o sim-simple tb '' + (if backend == "llvm" then '' ./sim-simple --assert-level=warning > output.txt '' else '' ghdl -r --workdir=ghdlwork --ieee=synopsys tb > output.txt '') + '' diff output.txt ${./expected-output.txt} && touch $out ''; } </ins>

Discussion:
Describe the bug To Reproduce -env -i ghdl-llvm # or nix run ... -a Expected behavior ghdl compiles and runs the code Additional context uses LLVM as a backend to compile VHDL to a simulator executable for RTL simulation. It finally links its outputs using (via a call to gcc). The problem is, that in this linking step it also wants to link , which the linker can not find. However, in a everything works as intended. Even a and appending to NIX_LDPATH suffices. I tried various (combinations) of and friends and also , but never got this to work. I suspect that there is something in the setup hook of the nix-shell, but inspecting and comparing s didn't get me any further. Maybe someone could look into this or introduce me to the dark magic of and packaging compilers. (Looking at other compiler's .nix files also was a dead end for me.)
I marked this as stale due to inactivity. &rarr;
Change:
checkInputs = [ pytest xmltodict nbconvert ipywidgets ]; propagatedBuildInputs = [ async_generator traitlets nbformat nest-asyncio jupyter-client ]; <ins> postFixup =  '' # Remove until fixed by upstream # https://github.com/jupyter/nbclient/pull/173#issuecomment-968760082 rm $out/bin/.jupyter-run-wrapped rm $out/bin/jupyter-run ''; </ins> meta = with lib; { homepage = "https://github.com/jupyter/nbclient"; description = "A client library for executing notebooks";

Discussion:
Tried today to update my nixOS system, which was last updated on 27/10/2021. Now when trying to nixos-rebuild switch i get the following error: Using unstable. relevant part of setup: home.packages = with pkgs; [ (python3.withPackages (ps: with ps; [jupyter numpy pandas matplotlib])) ]; flake was updated as below: • Updated input 'nixpkgs': 'github:nixos/nixpkgs/' (2021-10-27) → 'github:nixos/nixpkgs/' (2021-11-13)
Hey, thanks for the report with the thorough explanations. This seems to be an issue with . For some reason they don't set in their call in . For the actual collision I'm afraid we can't do much about it. Users of both and might expect to find in the closure. So I'd suggest to ask home-manager to allow collisions, or move your colliding packages into . Feel free to ping me if you think there is another cause for the issue.
I've just hit this problem in a flake :
(doesn't happen on so I'm using that for now)
Reopening, as is inside Nixpkgs. I'm somewhat surprised that it doesn't .
using a file works though, so there's something different about flakes dev shells maybe ?
Are you sure that you are supplying nixos-unstable to ? I can also reproduce with nix-shell:
oh, I'm actually using a nixos-unstable channel from 2 weeks ago, you're right
That's on purpose, so we can find packaging mistakes. The version bump introduced the regression. Upstream
Proposed fix
This appears to have broken : Edit: sorry, I'll post on the PR not the issue...
Change:
<ins> diff --git a/lib/CatalystX/Script/Server/Starman.pm b/lib/CatalystX/Script/Server/Starman.pm index 670bd74..7b3bd2e 100644 --- a/lib/CatalystX/Script/Server/Starman.pm +++ b/lib/CatalystX/Script/Server/Starman.pm @@ -9,7 +9,7 @@ our $VERSION = '0.02'; extends 'Catalyst::Script::Server'; -has '+fork' => ( default => 1, init_arg => undef ); +has '+fork' => ( default => 1 ); has [qw/ keepalive restart restart_delay restart_regex restart_directory/] => ( init_arg => undef, is => 'ro' ); @@ -70,7 +70,7 @@ CatalystX::Script::Server::Starman - Replace the development server with Starman -d --debug           force debug mode -f --fork            handle each request in a new process -                            (defaults to false) +                            (defaults to true) -? --help            display this help and exits -h --host            host (defaults to all) -p --port            port (defaults to 3000) </ins>

Discussion:
As of nixos/nixpkgs (i.e., today) seems to be failing due to an unsupported command line switch being passed (see ) Actually, starting doesn't fail, but some (all?) of the other command line arguments are ignored. For example, I tried setting , but see how insists on starting on port . Removing the switch makes start as expected, respecting the other given command line switches, but is this what we want to do? cc
this was broken due to Catalyst bump. See duplicated - I don't know how to best fix this as switch might have an impact. If someone has time to fix it, I'd be very happy :)
Change:
# directories. This causes non-determinism in the install since # the installation order of font files with the same name is not # fixed. <del> rm -rv ofl/alefhebrew  ofl/misssaintdelafield  ofl/mrbedford  ofl/siamreap  ofl/terminaldosislight # See comment above, the structure of these is a bit odd # We keep the ofl/<font>/static/ variants rm -rv ofl/comfortaa/*.ttf  ofl/mavenpro/*.ttf  ofl/muli/*.ttf  ofl/oswald/*.ttf </del> <ins> rm -rv ofl/cabincondensed  ofl/signikanegative  ofl/signikanegativesc </ins> if find . -name "*.ttf" | sed 's|.*/||' | sort | uniq -c | sort -n | grep -v '^.*1 '; then echo "error: duplicate font names"

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: google-fonts <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2019-07-14 desired version: 2021-01-?? (see ) <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: (the most recent committer here) Please tag this issue in your PR.
Change:
class JunitXMLLogger(AbstractLogger): class TestCaseState: def __init__(self) -> None: self.stdout = ""

Discussion:
-build -A ! Logs: I'm out of context on this. This seems too fundamental to be broken. It is breaking all NixOS tests? Nginx test also fails the same. I could not build using: ! CC Update: Bisect answer was
!
Oh, that was quick, I'm still building ruff on my machine...
A solution has been found is preparing the PR.
Change:
<ins> { lib, fetchFromGitHub, python3Packages, }: python3Packages.buildPythonApplication rec { pname = "MatrixZulipBridge"; version = "0.4.1"; pyproject = true; disabled = python3Packages.pythonOlder "3.10"; src = fetchFromGitHub { owner = "GearKite"; repo = "MatrixZulipBridge"; rev = "v${version}"; hash = "sha256-5bDqZb8xx5SjThZUSmOcctwo6B15cjkIwA26QNfED2A="; }; build-system = with python3Packages; [ poetry-core ]; dependencies = with python3Packages; [ zulip beautifulsoup4 bidict coloredlogs emoji markdownify mautrix python-dotenv ruamel-yaml zulip-emoji-mapping ]; pythonRelaxDeps = [ "bidict" "markdownify" "ruamel-yaml" "zulip-emoji-mapping" ]; pythonImportsCheck = [ "matrixzulipbridge" ]; meta = { description = "Matrix puppeting appservice bridge for Zulip"; homepage = "https://github.com/GearKite/MatrixZulipBridge"; changelog = "https://github.com/GearKite/MatrixZulipBridge/releases/tag/v${version}"; license = lib.licenses.agpl3Only; maintainers = with lib.maintainers; [ robertrichter ]; mainProgram = "matrix-zulip-bridge"; }; } </ins>

Discussion:
Project description A Zulip puppeting bridge for Zulip. similar to mautrix-signal etc. Metadata homepage URL: source URL: license: agpl 3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See
Change:
${cfg.extraConfig} ''; <ins> enableIwd = cfg.wifi.backend == "iwd"; </ins> in { imports = [

Discussion:
connman built with iwd: But module contains assertion that returns error when wpasupplicant is disabled (enabling iwd disables wpasupplicant):
In , the only supported way to use is to use it as a standalone wireless daemon. Even if you assertion was disabled, it wouldn't make a difference, since the configurations don't allow for to connect to . The default is setup for which differs from the one that is required [1]. Though it does look like it's relatively easy to enable integration with the addition of two services, for now it might be better to just override the module manually on your local configuration. [1]
If someone ends up putting together the needed bits, please share (probably as a PR)! Ive kludged network-manager into using iwd (kludge is needed for similar assertion and to not run iwd standalone, IIRC) but I'm keen to give connman a try :).
FYI guys, ConnMan doesn't really keep up to date with iwd and integration between the two might lead to frustration. See and The best bet for now is to use network manager with iwd ()
NetworkManager is ugly and buggy
I've been also using iwd without network manager or connman just fine.
I'm thinking of writing a GUI for iwd - to use iwd + dhcpcd
Heads up for anyone interested iwd 1.0 was released with breaking changes, refs:
Change:
{ config, options, name, ... }: { options = { config = mkOption { description = '' A specification of the desired configuration of this container, as a NixOS module. ''; <del> type = let confPkgs = if config.pkgs == null then pkgs else config.pkgs; in lib.mkOptionType { </del> <ins> type = lib.mkOptionType { </ins> name = "Toplevel NixOS config"; <del> merge = loc: defs: (import (confPkgs.path + "/nixos/lib/eval-config.nix") { </del> <ins> merge = loc: defs: (import "${toString config.nixpkgs}/nixos/lib/eval-config.nix" { </ins> inherit system; <del> pkgs = confPkgs; baseModules = import (confPkgs.path + "/nixos/modules/module-list.nix"); inherit (confPkgs) lib; </del> modules = let extraConfig = {

Discussion:
Describe the bug Since the introduction of the option in on master and for release-20.03, overlays defined in containers with are no longer working. To Reproduce Execute this test: Expected behavior Overlays should work inside the containers. Notify maintainers (author of the change) Metadata Please run and paste the result. Maintainer information:
[x] Done. [ ] The option seems useful and should be kept on master for the next release, but it needs to be fixed to work with overlays.
It appears 20.09 is affected by this. While trying to upgrade to 20.09 my containers that use personal overlays fail to build. Looking at the git history for tag 20.09, I see in the history, but not the revert commit , and commit logs for does not include a fix for this bug.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> Dump temacs in an empty environment to prevent -dev paths from ending up in the dumped image. diff --git a/src/Makefile.in b/src/Makefile.in index fd05a45df5..13f529c253 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -570,7 +570,7 @@ emacs$(EXEEXT): temacs$(EXEEXT)  lisp.mk $(etc)/DOC $(lisp)  $(lispsource)/international/charprop.el ${charsets} ifeq ($(DUMPING),unexec) -	LC_ALL=C $(RUN_TEMACS) -batch $(BUILD_DETAILS) -l loadup --temacs=dump +	env -i LC_ALL=C $(RUN_TEMACS) -batch $(BUILD_DETAILS) -l loadup --temacs=dump ifneq ($(PAXCTL_dumped),) $(PAXCTL_dumped) emacs$(EXEEXT) endif </del>

Discussion:
Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
inherit (passthru.deps."boringssl.zip") name; src = passthru.deps."boringssl.zip"; <del> vendorHash = "sha256-ISmRdumckvSu7hBXrjvs5ZApShDiGLdD3T5B0fJ1x2Q="; </del> <ins> vendorHash = "sha256-SNUsBiKOGWmkRdTVABVrlbLAVMfu0Q9IgDe+kFC5vXs="; </ins> nativeBuildInputs = [ unzip ];

Discussion:
Package name: curl-impersonate Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.5.4 Current version on the stable/release channel: 0.5.4 <!-- 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 Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
./services/web-apps/prosody-filer.nix ./services/web-apps/matomo.nix ./services/web-apps/openwebrx.nix <ins> ./services/web-apps/outline.nix </ins> ./services/web-apps/restya-board.nix ./services/web-apps/sogo.nix ./services/web-apps/rss-bridge.nix

Discussion:
Project description Outline is a modern web application for creating documentation, kind of a Wiki. Metadata homepage URL: source URL: license: Custom platforms: linux
I marked this as stale due to inactivity. &rarr;
Closing in favor of

Project description Team wiki, documentation, meeting notes, playbooks, onboarding, work logs, brainstorming, & more… Metadata homepage URL: source URL: license: Business Source License 1.1 platforms: unix
I marked this as stale due to inactivity. &rarr;
Change:
{ lib, stdenv, buildPackages, buildHaskellPackages, ghc <del> , jailbreak-cabal, hscolour, cpphs, runCommand </del> <ins> , jailbreak-cabal, hscolour, cpphs, runCommandCC </ins> , ghcWithHoogle, ghcWithPackages , nodejs }:

Discussion:
Suppose you have a project with some native dependency like and try to inside of a like this: Before , this worked fine, but since , building fails: Minimal reproducible example is in I only tested this on . Running for the example above shows that is missing from and . Indeed, adding to the resolves the problem:
cc
Interesting. Especially since we decided against using runCommandNoCC but somehow arrived at similar behavior. Sorry we broke this. I wonder what the best fix is. Should shellFor just always add the GCC dep? Or should gcc maybe become a runtime dependency of cabal-install since apparently that's actually what's going on here?
.
That’s an explanation, thank you! Now the question: What is the correct way to get gcc into scope? I guess the most pragmatic way is to just add it as a dependency of runCommand, but it feels like that is a bit wrong.
should work…
Still not convinced, that’s a clean solution. But yeah, I’ll do that.
Why wouldn't that be a clean solution? The C compiler is part of , so we need to make sure the environment also uses the default that actually has one.
I just wasn’t sure whether every shell should contain stdenv. But I guess that’s kinda stupid.
Change:
buildDotnetModule rec { pname = "bicep"; <del> version = "0.27.1"; </del> <ins> version = "0.28.1"; </ins> src = fetchFromGitHub { owner = "Azure"; repo = "bicep"; rev = "v${version}"; <del> hash = "sha256-7yEsxKUG2jhki1u5CObdjN4JMnEcAYR+SoGPaNJ+9Fs="; </del> <ins> hash = "sha256-9yWfzYrs7LxVmb+AZUI+G0TQQteJP7gpISJGdY0qKAg="; </ins> }; <ins> postPatch = '' substituteInPlace src/Directory.Build.props --replace-fail "<TreatWarningsAsErrors>true</TreatWarningsAsErrors>" "" ''; </ins> projectFile = "src/Bicep.Cli/Bicep.Cli.csproj"; nugetDeps = ./deps.nix;

Discussion:
update script errors when executed as: Logs: -shell --argstr package bicep logs at: Update script should not error. It should update package. An update for bicep 0.28.1 is available. CC
Error looks like a red herring, I see it during successful updates. Seems like a problem with a dependency version in that release. I was able to run it on a newer commit after they bump dependencies. When you run the fetch-deps I see this on that release:
Change:
}; }; <del> meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://apps.gnome.org/Clocks/"; <del> description = "Clock application designed for GNOME 3"; </del> <ins> description = "A simple and elegant clock application for GNOME"; longDescription = '' A simple and elegant clock application. It includes world clocks, alarms, a stopwatch, and timers. - Show the time in different cities around the world - Set alarms to wake you up - Measure elapsed time with an accurate stopwatch - Set timers to properly cook your food ''; </ins> mainProgram = "gnome-clocks"; <del> maintainers = teams.gnome.members; license = licenses.gpl2Plus; platforms = platforms.unix; </del> <ins> maintainers = lib.teams.gnome.members; license = lib.licenses.gpl2Plus; platforms = lib.platforms.unix; </ins> }; <del> } </del> <ins> }) </ins>

Discussion:
Gnome clocks fails to play alarm. Emits following error: (): GStreamer-Play-ERROR **: 05:20:00.109: GstPlay: 'playbin' element not found, please check your setup Trace/breakpoint trap (core dumped) Steps to reproduce the behavior: an alarm for 1 min later and wait. the crash I use Hyprland not gnome. If it is expected for clocks to not work in other desktop environments, I am sorry for the noise. <!-- 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]:
Thanks for reporting. Sounds like we forgot to add GStreamer to buildInputs in the previous bump ( in GNOME 45). It works on GNOME Shell because it leaks GStreamer into environment, masking this issue. The sound theme can be removed.
Please test
Change:
stdenv.mkDerivation rec { pname = "btop"; <del> version = "1.2.13"; </del> <ins> version = "1.3.0"; </ins> src = fetchFromGitHub { owner = "aristocratos"; repo = pname; rev = "v${version}"; <del> hash = "sha256-F/muCjhcnM+VqAn6FlD4lv23OLITrmtnHkFc5zv97yk="; </del> <ins> hash = "sha256-QQM2/LO/EHovhj+S+4x3ro/aOVrtuxteVVvYAd6feTk="; </ins> }; <ins> nativeBuildInputs = [ cmake ]; </ins> buildInputs = lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.CoreFoundation darwin.apple_sdk_11_0.frameworks.IOKit ]; <del> env.ADDFLAGS = lib.optionalString stdenv.isDarwin "-F${darwin.apple_sdk_11_0.frameworks.IOKit}/Library/Frameworks/"; </del> installFlags = [ "PREFIX=$(out)" ]; postInstall = ''

Discussion:
Steps to reproduce the behavior: on x86_64-darwin Thanks for looking! Broken commit: Working commit: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This is failing on aarch64-darwin too.
Haha great! Now I can stop trying to bisect this on a 2015 laptop <img width="282" alt="" src=""
Check out the posted PR. It fixed Darwin for me
Change:
<ins> --- gringo/libgringo/gringo/bug.hh~	2014-03-10 12:19:26.000000000 -0400 +++ gringo/libgringo/gringo/bug.hh	2016-11-12 07:51:55.288563663 -0500 @@ -32,7 +32,7 @@ #define _GLIBCXX_MAKE_MOVE_ITERATOR(_Iter) std::make_move_iterator(_Iter) #define _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(_Iter) std::make_move_iterator(_Iter) -#ifdef MISSING_STD_TO_STRING +#if 0 #include <sstream> </ins>

Discussion:
The OCaml package manager () depends on an external solver. When the package was updated, it changed the compiler configuration, and a dependent package () of the solver () no longer compiled. The fix () uses a different monolithic package of the solver and its various tools (called "clingo") that for unknown reasons breaks : Install and attempt to run . System: Nix version: Nixpkgs version: