jiebi/CodeConvo huggingface dataset:
Change:
{ lib , buildPythonPackage , fetchFromGitHub <ins> , fetchpatch </ins> , mypy , pytestCheckHook , python-lsp-server

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
It seems that it is caused by this recent change in :
EDIT: the commit mentioned above is not the problem but the fix. Indeed, updates the test to work with the new version of mypy (0.991). The author has not made a new release yet. Hence, we have two choices: 1) Disable (temporarily) the tests waiting for the new release of . 2) Change the and fetch the master branch of the .
Does that commit apply cleanly to the latest version if used as a patch? You can it into on the derivation if so
Change:
, libmtp, unzip, taglib, libkate, libtiger, libv4l, samba, libssh2, liboggz , libass, libva, libdvbpsi, libdc1394, libraw1394, libopus , libvdpau, libsamplerate, live555, fluidsynth, wayland, wayland-protocols <ins> , ncurses </ins> , onlyLibVLC ? false , withQt5 ? true, qtbase, qtsvg, qtx11extras, wrapQtAppsHook , jackSupport ? false

Discussion:
Looks like the package doesn't provide ?
Wasn't this fixed by ?
Er, yes, I thought "resolving " would automatically close it. Guess not.
Change:
buildPythonPackage rec { pname = "sarge"; <del> version = "0.1.7"; </del> <ins> version = "0.1.7.post1"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "vsajip"; repo = pname; rev = version; <del> sha256 = "sha256-E1alSDXj0oeyB6dN5PAtN62FPpMsCKb4R9DpfWdFtn0="; </del> <ins> sha256 = "sha256-bT1DbcQi+SbeRBsL7ILuQbSnAj3BBB4+FNl+Zek5xU4="; </ins> }; checkInputs = [ pytestCheckHook ]; <ins> disabledTests = [ # Aarch64-linux times out for these tests, so they need to be disabled. "test_timeout" "test_feeder" ]; </ins> pythonImportsCheck = [ "sarge" ];

Discussion:
Since the PR which I am unable to build Octoprint on my raspberrypi 4. Steps to reproduce the behavior: Use either or Octoprint builds successfully. This is the output of : This is the output of Octoprint maintainers: PR author: Original issue author: Please run and paste the result.
Can confirm this, I wasn't originally sure whether it is caused by my config, as I am cross compiling with binfmt+qemu.
Some further information: doesn't build on aarch64-linux either: notice the same path.. When looking at sarge I noticed a version bump from 0.1.7 to 0.1.7.post1 not long ago. Updating sarge locally enables me build sarge, as well as octoprint. I'll post a PR later on today with an updated sarge.
Short follow up: The reason the test fail, are a strict timeout setting (first for an echo command, second for a timeout test). Increasing the timeout make the test pass on raspberry pi and with binfmt/qemu.
Change:
cfg = dmcfg.sddm; xEnv = config.systemd.services."display-manager".environment; <del> sddm = pkgs.sddm.override { inherit (cfg) themes; }; </del> <ins> sddm = cfg.package; </ins> xserverWrapper = pkgs.writeScript "xserver-wrapper" '' #!/bin/sh

Discussion:
On NixOS 17.03, the in the system configuration with Plasma 5 enabled, has and in its runtime closure, which causes unnecessary bloat. This is because has: then causes the directories of and to be to the wrapper script. (Automatically adding everything with a directory to the wrapper seems pretty drastic BTW.) System: NixOS Nix version: 1.12pre5073_1cf4801
KDE upstream is slightly careless about implicit runtime dependencies. I spent hours trying to figure out which runtime dependencies needed to be in . By the way, you have to guess at this because SDDM doesn't log error messages. Could we drop ? Probably. Can I answer that question for any of the other dependencies? Not a chance. So I nuked it from orbit. Guessing the correct setting would be a good project for a first-time contributor with a lot of free time. At the moment, I'm trying to get rid of entirely. This problem may go away as a happy accident, but that won't help this release. I'm open to other suggestions.
Change:
desktopName = longName; comment = "Code Editing. Redefined."; genericName = "Text Editor"; <del> exec = "${executableName} %U"; </del> <ins> exec = "${executableName} %F"; </ins> icon = "code"; startupNotify = "true"; categories = "Utility;TextEditor;Development;IDE;";

Discussion:
Describe the bug I'm using PCManFM as Filemanager and if I try to open a File with VSCode it only opens an empty file. (This issue is known: ). To fix this the issue recommends to change to in the desktop file. To Reproduce Steps to reproduce the behavior: to open a file in PCManFM with VSCode Expected behavior File is opened in VSCode Screenshots ! In VSCode I manullly opened the file on the left and tried to open it with PCManFM. As you can see, %U tells PCManFM to return a URL, but VSCode doesn't know what to do with it. So will be converted to . Additional context I'm not quite sure whether I'm the only one with this issue, I haven't seen any other issue explaining this same problem. But a friend of mine who I introduced to NixOS also had this Problem, so I'm probably not alone. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(vincentcui): nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos Maintainer information:
I already tried to change in to (Notice the part in the desktop entry) After I made this change and build it with (with NIXPKGS=<location of the changed nixpkgs directory) VSCode would open files from PCManFM without issue. I also haven't seen any other bugs created by this. I'm quite new to Nix and this is also my first issue, it would be really nice if you could tell me if I could have done something different or better.
Change:
<del> { lib, fetchFromGitHub, python3Packages </del> <ins> { stdenv, lib, fetchFromGitHub, python3Packages </ins> , hackrf, rtl-sdr, airspy, limesuite, libiio , libbladeRF , qt5

Discussion:
Steps to reproduce the behavior: (from this template), triggering nix-darwin to be rebuilt qtwayland (I assume as part of darwin). Here is the output of : 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]:
qtwayland should not be built on Darwin, whatever package is doing that needs to be fixed.
(Shouldn't you be running into an error about your platform not being marked supported by ?) Your issue is: dependency on without limiting it to Linux. Opened to make it a Linux-only dependency.
We should probably mark qtwayland broken on Darwin explicitly, yeah.
And it has been marked as broken there in on all supported channels.
Ahh - you're right - it is probably the urh package then. I really love how attentive and helpful people are with fixing things in nixpkgs =). It was just confusing because I saw this line in the output: Hence I just assumed it was nix-darwin. But is that a bit of a red herring? (I'm a nix newbie, so always keen to learn) Also - is there any way to manually apply patches/PRs like Or should I just wait for it to get merged, and then pushed out to the Nixpkgs unstable channel? (I was using to give me an idea of when a commit might be available - I get the impression that there is some gap between when it's actually merged, versus available in nixpkgs).
Change:
{ stdenv, buildEnv, pidgin, makeWrapper, plugins }: <del> let drv = buildEnv { </del> <ins> let extraArgs = map (x: x.wrapArgs or "") plugins; drv = buildEnv { </ins> name = "pidgin-with-plugins-" + (builtins.parseDrvName pidgin.name).version; paths = [ pidgin ] ++ plugins;

Discussion:
This, and "meta" should probably be filled to enable Hydra builds.
, maybe you can look at this?
The project is on now, and our version looks outdated for years.
I've dropped one version of a plugin and updated and cleaned up another.

Describe the bug After switching my NixOS configuration to use the rebuild failed at rebuilding . Trying to rebuild again (continuing at again) caused the same issue. Tried after setting in my local nixpkgs clone, and that has worked without errors. I've uploaded the log of to . ~The has triggered a rebuild of other packages so I don't have a failing log available (yet).~ EDIT: gist updated with nixos-rebuild log. Looks like there is a difference / error in the detection. has been able to reproduce this (non-deterministically), so I'm curious what his easy reproducer is. To Reproduce Steps to reproduce the behavior: reproducer TBD Expected behavior Package should build. Additional context Add any other context about the problem here. Metadata Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I’m not sure of why exactly this causes the subsequent errors, but is a direct consequence of . My reproducer is simply (where the flake is with ). The reason why it wasn’t deterministic for me is that the second machine in which I tried to build it had the first one as a substituter, so the derivation hadn’t been built locally but had been fetched − and as such wasn’t affected by NixOS/nix .
Didn't realize there was a targeted fix in the nix repo yet, but I've attempted to rebuild my system again with and without any substituters. Took about 36h, but rebuilding the world worked this time.
Change:
nativeBuildInputs = [ pkgconfig ]; buildInputs = [ glib libintl ]; <ins> setupHook = ./setup-hook.sh; </ins> meta = { homepage = http://www.freedesktop.org/wiki/Software/desktop-file-utils; description = "Command line utilities for working with .desktop files";

Discussion:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .
Change:
virtualbox = libsForQt5.callPackage ../applications/virtualization/virtualbox { stdenv = stdenv_32bit; inherit (gnome2) libIDL; <del> jdk = openjdk17; </del> <ins> # VirtualBox uses wsimport, which was removed after JDK 8. jdk = jdk8; </ins> }; virtualboxKvm = lowPrio (virtualbox.override {

Discussion:
Steps to reproduce the behavior: following configuration: # nixos-rebuild switch <!-- 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]:
~ tells me the first bad commit was . I'm not sure if this is correct, because this commit is a qemu version bump (). This build failure can also be seen in the pull request: EDIT: I've tried building it again on another machine and it worked. I think a file somehow got corrupted on the other machine, because the build contains strange errors like and Additionally, was set to false.
Notify maintainers:
your are more then welcome to fix it and create a PR
The issue seems to be that we use a JDK that doesn't have anymore. See also: Can you check whether this PR ( ) fixes things for you? Ideally, if you could run on that PR, I'd be super grateful!
Sorry for the delay. The PR worked, I can with the configuration above. Thanks for the work.
Hi, I'm afraid I'm still experiencing this issue even though the changes landed in . Would anyone mind taking a look at my (shortened for brevity) to see what I did wrong? Thanks!
Change:
services.openssh.startWhenNeeded = mkDefault true; # Shut up warnings about not having a boot loader. <del> system.build.installBootLoader = "${pkgs.coreutils}/bin/true"; </del> <ins> system.build.installBootLoader = lib.mkDefault "${pkgs.coreutils}/bin/true"; </ins> # Not supported in systemd-nspawn containers. security.audit.enable = false;

Discussion:
After updating from to , my config no longer builds: Those two modules appear to by enabled by the of the I am importing but weirdly, neither of those seem to have changed: Run
Bisecting points to cc
Maybe this should be ?
This is great! Those were always in conflict, but one of them won, by luck of the order. You really don't want to have anything important depend on that, so I'm glad this was caught, although I wish the experience of catching it would be nicer. That line does feel like a default.
Hold on, it seems to be the other way around. That line should be a instead, to disable boot loader stuff for containers.
It's kind of the wrong way around, -ing stuff you don't need and then disabling it, but it's the best we can do without RFC22 / Minimal module list. I've opened and to work towards those goals with minimal impact on regular NixOS.
I would assume VPSAdminOS wants the boot loader even for containers if they are explicitly enabling the init scripts. cc
I don't fully understand all these changes, but yes, I would say that (and ) is needed when NixOS is in a container. I mean a container run e.g. by LXC, which is what we do on vpsAdminOS. We don't know what is inside the container and depend on it having . I think on would work.
I thought of the wrong kind of container. lgtm.
Opened
Change:
}; listen = { host = netCfg.listen.host; <del> port = netCfg.listen.port; </del> <ins> port = resolveFinalPort netCfg; </ins> }; tun = { disabled = netCfg.tun.disable;

Discussion:
When a "lighthouse" and a regular "roaming" node are on the same network and the default value for () is used, nodes occasionally enter a consistent failure state while trying to connect. I suspect this occurs when Nebula tries to NAT-punch with the local router and always tries to connect to the lighthouse instead of the roaming node. Steps to reproduce the behavior: up a lighthouse node and roaming node -forward port 4242 for the lighthouse node to set a value for in the Nebula config intermittent failures The value of should be required, with a link to Nebula docs: I'm not entirely sure, but logs from the issue indicate the lighthouse-node handshakes are both sending packets to "192.168.1.1:4242", which is port-forwarded to the lighthouse (I'm in a dual-NAT setup unfortunately; this is the IP of the outer NAT). Explicitly setting the port to (to automatically select an ephemeral port) on the roaming nodes immediately fixes the issue. (wrote the initial module with the port default) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on those docs, I think we can solve this without requiring the user to specify the port. Since we know whether a node is a lighthouse via , we could implement a behavior where defaults to for lighthouses and for non-lighthouses: I'm not sure how to get the for this, though. Maybe if the options were , then we could just refer to ? We'd probably also want to include . Thoughts?
My thought is that a change should meet the following requirements: Per set and to something like:Set the actual value appropriately in the module with an expression like the above if the input is null. If (isLighthouse or isRelay) and the final port evaluates to 0, we should warn, since this config will probably result in connectivity issues. There should be a test for this. I am split on whether to backport this. While this is a bug, people may have relied on the default port to NAT port forward from routers to a Nebula node that is not a lighthouse or a relay.

As such the new default may impede connectivity on restrictive NATs, so this is also a breaking change.
Also, good job diagnosing this. I think I've run into this before but didn't know what was causing it.
Per (captured in + ) Given this, it is probably a good idea to both fix and backport this.
Change:
AS_IF([test "x$ac_cv_ping_6_opt" = "xyes"],[ '') <ins> # put firehol config files in /etc/firehol (not $out/etc/firehol) # to avoid error on startup, see #35114 (pkgs.writeText "firehol-sysconfdir.patch" '' --- a/sbin/install.config.in.in +++ b/sbin/install.config.in.in @@ -4 +4 @@ -SYSCONFDIR="@sysconfdir_POST@" +SYSCONFDIR="/etc" '') # we must quote "$UNAME_CMD", or the dash in /nix/store/...-coreutils-.../bin/uname # will be interpreted as IFS -> error. this might be considered an upstream bug # but only appears when there are dashes in the command path (pkgs.writeText "firehol-uname-command.patch" '' --- a/sbin/firehol +++ b/sbin/firehol @@ -10295,7 +10295,7 @@ kmaj=$1 kmin=$2 -	set -- $($UNAME_CMD -r) +	set -- $("$UNAME_CMD" -r) eval $kmaj=$1 $kmin=$2 } kernel_maj_min KERNELMAJ KERNELMIN '') </ins> ]; nativeBuildInputs = [ autoconf automake ];

Discussion:
The firehol derivation has a parameter . So by default, the firehol package only includes (traffic shaping tool) but not (firewall). This is not really what a user expects from a package called "firehol". I propose changing the default to (or eliminate the parameter altogether) to make the program available without override. No significant impact on build time or storage, just few extra files. /cc maintainer:
While writing this package I was only interested in and this parameter to keep the package smaller. Setting it to by default seems to be a bad decision. Changing it to seems fine for me. Please excuse my late response.
Thank you for your reply. So let's change the default to . I will add this change to my open pull request .

The firewall program in package firehol is unusable, always exits with an error message (see steps to reproduce). Cause: On startup, tries to create the config file and fails since the nix store is read-only. How to fix: Make look for config files in rather than . This makes sense anyway since a fixed bundled firewall config would not be useful. I already implemented the fix. PR follows after testing. firehol with to enable the firehol program (the firehol package doesn't install the firehol program by default - doesn't make sense to me, but that's a separate issue) any firehol command results in this error message: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
After fixing this, fails with a different error message. I discovered another bug caused by an unquoted command path in the bash script. Fixed that as well. Working on a PR.
fixed in
Change:
patchage = callPackage ../applications/audio/patchage { }; <del> patchance = python3Packages.callPackage ../applications/audio/patchance { inherit (qt5) qttools; }; </del> <ins> patchance = python3Packages.callPackage ../applications/audio/patchance { }; </ins> patatt = callPackage ../development/tools/patatt { };

Discussion:
The new package for fails to start due to an error involving Qt. I have reproduced this behavior on two different computers. Steps to reproduce the behavior: raysession to system configuration raysession Raysession does not open, and produces an error in the terminal. Add any other context about the problem here. Output of .
I'm also experiencing this problem with the package.
Looks like it needs `. You might also have to add that and maybe other qt stuff to the wrapper.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made a PR here, you might want to try it a bit more extensively than I did, and also submit a similar fix for the second package mentioned in
Change:
rm -R  $out/share/teamviewer/logfiles  $out/share/teamviewer/config  <ins> $out/share/teamviewer/tv_bin/RTlib  </ins> $out/share/teamviewer/tv_bin/xdg-utils  $out/share/teamviewer/tv_bin/script/{teamviewer_setup,teamviewerd.sysv,teamviewerd.service,teamviewerd.*.conf,libdepend,tv-delayed-start.sh}

Discussion:
Describe the bug When busybox is installed - teamviewer cannot starts correctly To Reproduce Steps to reproduce the behavior: " = true;" to busybox to "environment.systemPackages = with pkgs;" to launch the teamviewer Expected behavior Teamviewer gui starts Screenshots If applicable, add screenshots to help explain your problem. ! Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
This should be fixed by . Please confirm by closing if it indeed does.
Change:
cp $out/lib/* $out/share/adapter cp -r adapter/scripts $out/share/adapter cp -t $out/share/formatters formatters/*.py <del> ln -s ${lldb.lib} $out/share/lldb </del> <ins> ln -s ${lib.getLib lldb} $out/share/lldb </ins> makeWrapper $out/share/adapter/codelldb $out/bin/codelldb  --set-default LLDB_DEBUGSERVER_PATH "${lldb.out}/bin/lldb-server" '';

Discussion:
On Darwin, lldb is unable to locate the support binaries directory. Trying to run lldb with a target executable results in it failing with . a target the target Successfully runs the target executable. The problem is Darwin specific because of the way lldb locates the directory. It expects the and to be present in the same directory as indicated in the comment . As part of the derivation is a separate output, it cannot locate the directory and fails to run the executable.
Can confirm, macos 10.15.
Yes and I have to manually set also.
Problem perists:
are you getting it to work with that? No luck here:
Use instead of . The former one does not contain the output, so you can use an environment variable.
What would be the preferable solution from an LLVM maintainers perspective? The lib output could be dropped, or LLVM would need to be patched to look for the support binaries in the correct path.
I would suggest a LLVM patch that could be general enough that we could send back to upstream, worst case, we can reassemble an out and lib just for this usecase in the meantime for Darwin.
are you sure it should be fixed on LLVM side? Because lldb from homebrew works fine on macos.
The fix is probably similar to what I did for LTO support (using to hardcode the path to the correct location in the store).
Here is the homebrew formula:
I’m working on a patch. The fix is to combine and on Darwin. It’s not possible to patch LLDB to know the location of because that creates a cycle between the two outputs.
I created It doesn’t exhibit the problem, but it also doesn’t seem to work. It may be that this is as good as it can get without the requisite entitlements.
lldb from your PR seems to work for me, even when I unset (my workaround for the prior issues). What wasn't working for you?
When I follow the steps you provided in , I get the following result: It only works if I don’t set .
Reopening because the change is technically breaking, and we’re in a breaking change freeze before the release.
Note that if you do need this, you can cherry-pick my commit from .

Yes, I see that error with my own MRE (haha) if I set to the nix version; it works with (which I assume is the default anyway).
When will this feature typically merged from master to unstable branch?
Nvm, just noticed that it was reverted :/
I had to revert because there is a freeze on breaking changes until 24.05 is released. Once 24.05 is released, I’ll reopen the fix PR.
I've used the commit you mentioned in previous comments. Thank you!
Just want to check some updates. Is this issue solved in 24.05?
It would be a breaking change, so it’d have to target unstable/24.11.
I resubmitted the lldb fix as