jiebi/CodeConvo huggingface dataset:
Change:
<ins> diff --git a/include/llvm/ADT/IntrusiveRefCntPtr.h b/include/llvm/ADT/IntrusiveRefCntPtr.h index f9df378..9d860ec 100644 --- a/include/llvm/ADT/IntrusiveRefCntPtr.h +++ b/include/llvm/ADT/IntrusiveRefCntPtr.h @@ -134,9 +134,9 @@ public: //===----------------------------------------------------------------------===// template <typename T> class IntrusiveRefCntPtr { +  public: T* Obj; -  public: typedef T element_type; explicit IntrusiveRefCntPtr() : Obj(nullptr) {} </ins>

Discussion:
Trying to build clang35 with nixpkgs HEAD () fails. The build log:
Is this still a problem?
Never mind, it has been marked as broken. You guys appear to be the clang experts. Do you have time to look into this?
That's a pretty strange compilation failure. Seems like it would be easy to patch if it came down to that. I'm not sure why that would be happening though.
Would it be fine to merge that patch? It's really ugly but if you aren't developing visibility isn't too important.
There is also the option that the old version of clang has been marked broken for a couple of months so it might be worth dropping it? I'm not sure if there is large value to fixing the old release.
I'm generally in favor of ditching the old in favor of the new if we can get away with it. You have my approval, for what it's worth. It seems fair to drop support for it, but if someone wants it enough to submit a working build for it, then that's fine we could accept that.
I'll see if wants to fix it otherwise I will create a PR to drop it this week.
Clang 3.5 is required for running the Terra compiler, so removing Clang 3.5 does have wider ranging repercussions. I'd be happy for my horrible patch to be merged (I can submit a PR if you want). I've not had any problems personally using this version of Clang. I'm not invested enough to implement a proper fix though :)
Would you be prepared to accept that patch? Or what would your preferred course of action be?
I'd be happy to accept it but I'm not an official collaborator of nixpkgs. On Tue, Aug 2, 2016, 2:05 PM Kevin Cox wrote:
Well if you open a PR there will be at least 2 :+1:s so I would go for it. On Tue, Aug 2, 2016, 18:43 Andrew Kelley wrote:
Interesting. I wonder why they're stuck on such an old version. I wonder if there were JIT regressions.
I've opened the PR
Change:
++ optional (nvidia_x11.persistenced != null && config.virtualisation.docker.enableNvidia) "L+ /run/nvidia-docker/extras/bin/nvidia-persistenced - - - - ${nvidia_x11.persistenced}/origBin/nvidia-persistenced"; <ins> systemd.services."nvidia-persistenced" = mkIf nvidiaPersistencedEnabled { description = "NVIDIA Persistence Daemon"; wantedBy = [ "multi-user.target" ]; serviceConfig = { Type = "forking"; Restart = "always"; PIDFile = "/var/run/nvidia-persistenced/nvidia-persistenced.pid"; ExecStart = "${nvidia_x11.persistenced}/bin/nvidia-persistenced --verbose"; ExecStopPost = "${pkgs.coreutils}/bin/rm -rf /var/run/nvidia-persistenced"; }; }; </ins> boot.extraModulePackages = [ nvidia_x11.bin ]; # nvidia-uvm is required by CUDA applications.

Discussion:
As described here it would be useful to add an option in to add a systemd entry which forces GPU's to always be online even in headless systems. Here is what the extracted systemd service would look like (taken from )
Change:
owner = "VCVRack"; repo = "Rack"; rev = "v${version}"; <del> sha256 = "0azrqyx5as4jmk9dxb7cj7x9dha81i0mm9pkvdv944qyccqwg55i"; </del> <ins> hash = "sha256-Gn/sFltLXX2mLv4dDqmr/UPd+JBXVkIZGwMI6Rm0Ih4="; </ins> }; patches = [

Discussion:
Package name: vcv-rack Latest released version: 2.4.1 Current version on the unstable channel: 2.4.0 Current version on the stable/release channel: 2.3.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
may be trying something with so I'll wait a bit
Honestly I have no idea what vcv-rack is, I just looked for a package I can update to test out a new feature for `nix-update. If you can, take this from from, feel free to update it.
Not sure if I'll have time in the next few weeks, so this is free to pick
Change:
meta.broken = isPhp74; }; <ins> rdkafka = buildPecl { version = "4.0.3"; pname = "rdkafka"; sha256 = "1g00p911raxcc7n2w9pzadxaggw5c564md6hjvqfs9ip550y5x16"; buildInputs = with pkgs; [ rdkafka pcre' ]; postPhpize = '' substituteInPlace configure  --replace 'SEARCH_PATH="/usr/local /usr"' 'SEARCH_PATH=${pkgs.rdkafka}' ''; meta = { description = "Kafka client based on librdkafka"; homepage = "https://github.com/arnaud-lb/php-rdkafka"; maintainers = lib.teams.php.members; }; }; </ins> redis = buildPecl { version = "5.1.1"; pname = "redis";

Discussion:
Project description Providing the librdkafka module for php I tried to use the existing build suport () and install the rdkafka module in the same manner. I am still new to nix and couldn't figure out how to make it work in a way so the header files (which are checked/required? during phpize) are not on the path. I'm not sure if it really needs to be an official package. But would be nice to have some kind of guidance on how to create this kind of packages. I ended up with the following error and gave up :/: And I used the following package definition:
cc
cc :)
It was a broken configure script, so I a to patch the script in the argument. I don't have any experience with Apache Kafka, but it's big and common enough to include I think. So I made a PR for it. :)
Wow, that was fast :) Thanks!
Can confirm that with the fix rdkafka for PHP is built and installed properly. :) Maybe a side-note: apcubc extension seems to be installed as but linked as , which leads to warnings. I had to point to by adding an entry to the custom ini configuration. (Should I create a new issue for this?)
Thanks for reporting the broken extension. I'm working on a fix for it and a few other issues that popped up on the way. :)
Change:
<ins> From 68defee52f4eba82eefaeea17f21c7498448dd6b Mon Sep 17 00:00:00 2001 From: Samuel Dionne-Riel <samuel@dionne-riel.com> Date: Mon, 3 Jun 2024 16:16:25 -0400 Subject: [PATCH] efi/efi.h: Add efisetjmp.h See https://github.com/ncroxon/gnu-efi/commit/486ba3c3bdd147b7d98159b9e650be60bce0f027 --- efi/efi.h | 1 + 1 file changed, 1 insertion(+) diff --git a/efi/efi.h b/efi/efi.h index c266532f3..e4497574b 100644 --- a/efi/efi.h +++ b/efi/efi.h @@ -23,6 +23,7 @@ #include <efi.h> #include <efilib.h> #include <efistdarg.h> +#include <efisetjmp.h> /* Delay for 100 ms */ #define EFI_NOMAP_PRINT_DELAY	100 </ins>

Discussion:
Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
"Microsoft.NETCore.App.Runtime.linux-musl-x64"  "Microsoft.NETCore.App.Runtime.linux-x64"  "Microsoft.NETCore.App.Runtime.osx-x64"  <del> "Microsoft.NETCore.App.Runtime.win-arm"  </del> "Microsoft.NETCore.App.Runtime.win-arm64"  "Microsoft.NETCore.App.Runtime.win-x64"  "Microsoft.NETCore.App.Runtime.win-x86" 

Discussion:
Package name: , Latest released version: 8.0.100-preview.6..14 Current version on the unstable channel: 8.0.100-preview.5..2 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.
I have a PR for the other dotnet versions (), unfortunately the 8.0 version has problems with missing system nuget versions. Due to that I was planning on skipping this version (it's unstable and should not be dependended upon anyway). Are there any features in this new version that you consider important? I can try hacking up the update script in that case.
Change:
<ins> { lib , runCommand , package }: runCommand "${package.pname}-tests" { HOME = "/tmp/home"; } '' mkdir -p "''${HOME}/.aws" cat > "''${HOME}/.aws/config" <<'EOF' [profile my-profile] azure_tenant_id=3f03e308-ada1-45f7-9cc3-ab777eaba2d3 azure_app_id_uri=4fbf61f5-7302-42e5-9585-b18ad0e4649d azure_default_username=user@example.org azure_default_role_arn= azure_default_duration_hours=1 azure_default_remember_me=false EOF ! ${lib.getExe package} --profile=my-profile 2> stderr [[ "$(cat stderr)" == 'Unable to recognize page state! A screenshot has been dumped to aws-azure-login-unrecognized-state.png. If this problem persists, try running with --mode=gui or --mode=debug' ]] touch $out '' </ins>

Discussion:
consistently fails on 23.11. Steps to reproduce the behavior: to NixOS 23.11 This should work like . Debug output: Installing via or via does not fix this. , but no mention of Chromium itself. It looks like the error message is from . . system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs: (I'll be tweaking this in case I come up with a working solution.) to a new directory, for example a containing the following: the built package like this: Unfortunately, the override doesn't work as expected: ERROR: Failed to set up Chromium r982053! Set "PUPPETEERSKIP_DOWNLOAD" env variable to skip download. I'm not sure how to proceed. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Unfortunately I'm not using this anymore and should remove myself as maintainer. Any volunteers? Looks like we have a fix now too. Can anyone verify?
I'm still using it for the foreseeable, so I've .
Change:
###### implementation <del> config = mkIf cfg.enable { </del> <ins> config = mkIf cfg.enable (let all_peers = flatten (mapAttrsToList (interfaceName: interfaceCfg: map (peer: { inherit interfaceName interfaceCfg peer;}) interfaceCfg.peers ) cfg.interfaces); in { </ins> assertions = (attrValues ( mapAttrs (name: value: {

Discussion:
In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.
Change:
stdenv.mkDerivation rec { name = "gnome-video-effects-${version}"; <del> version = "0.4.1"; </del> <ins> version = "0.4.3"; </ins> src = fetchurl { url = "mirror://gnome/sources/gnome-video-effects/0.4/${name}.tar.xz"; <del> sha256 = "0jl4iny2dqpcgi3sgxzpgnbw0752i8ay3rscp2cgdjlp79ql5gil"; </del> <ins> sha256 = "06c2f1kihyhawap1s3zg5w7q7fypsybkp7xry4hxkdz4mpsy0zjs"; </ins> }; <del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ intltool ]; </del> <ins> nativeBuildInputs = [ pkgconfig intltool ]; </ins> meta = with stdenv.lib; { homepage = https://wiki.gnome.org/Projects/GnomeVideoEffects;

Discussion:
Once you take a video with cheese (as webm), a few strange things happen: No thumbnails for images or videos will load. Cheese will refuse to close without a 'kill/killall .cheese-wrapped' Errors: video in cheese. cheese via 'Quit' button OR by closing the window Check (cheese will still be running) and taking up quite a bit of CPU. Normal behavior is returned once webm file is moved or deleted. Cheese doesn't understand webm yet tries to record as webm. Then every attempt at loading the webm in the preview pane causes an error. Maybe a dependency issue and we should depend on some webm support library? Or an upstream issue with Cheese itself? System: 16.09.1445. (Flounder); 16.03.885. (Emu) Nix version: nix-env (Nix) 1.11.4; nix-env (Nix) 1.11.2 Nixpkgs version: 16.09.1445.; 16.03.885. Cheese version: 3.20.2; 3.18.1
Updated. Still an issue in 16.09.
I can reproduce the problems with thumbnails and webm-related issues on 17.03 and master. It doesn't seem to crash on exit in my testing. Playing with gets problems with missing to disappear, adding gstreamer bits (like is done in totem or sushi) doesn't seem to be sufficient (I'm no expert here). Related: (?).
I opened an upstream issue:
Running cheese with environment variable revealed missing path to bubblewrap. After patching , user still needs to have thumbnailers ( and ) installed, for now I have them as dependencies like I did in . The infinite loop is still an upstream bug but with thumbnailers, it at least should not appear.
Change:
let name = "hplip-${version}"; <del> version = "3.19.1"; </del> <ins> version = "3.19.6"; </ins> src = fetchurl { url = "mirror://sourceforge/hplip/${name}.tar.gz"; <del> sha256 = "1kl1q4753xx1w76dhp92wgrhn5k1yx1ib35pyi0vi3mw0njbhrzm"; </del> <ins> sha256 = "0vfnc6pg7wzs68qn5mlk3cyl969d8n55bydgydq2wzfikvpfvnpw"; </ins> }; plugin = fetchurl { url = "https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/${name}-plugin.run"; <del> sha256 = "1fwjypy1ycyi7rr1vk1yxhbdhx51n7fxhvjb36mzw8qz71dif2i3"; </del> <ins> sha256 = "1b5gys04kh41gg7r7rzlpdbc2f4jirl2ik22cd935mm85k7abfwq"; </ins> }; hplipState = substituteAll {

Discussion:
Printing with a HP Color LaserJet printer fails due to a crash in the filter when using the driver "hpcups 3.19.1" With the "CUPS+Gutenprint v5.2.14" driver printing works. Try to print anything, a test page would do Please run and paste the results. oops.. let's try again:
I'm having the same problem, and made some observations: hplip 3.18.5 (used in release-18.09) works, even if compiled with pkgs from release-19.03 Here's a bug report with a proposed patch: is probably here: I didn't come around to test any of those patches thoug as I have only very limited access to my HP printer.
Change:
# Filebot writes to $APP_DATA, which fails due to read-only filesystem. Using current user .local directory instead. substituteInPlace $out/opt/filebot.sh  --replace 'APP_DATA="$FILEBOT_HOME/data/$(id -u)"' 'APP_DATA=''${XDG_DATA_HOME:-$HOME/.local/share}/filebot/data'  <del> --replace '$FILEBOT_HOME/data/.license' '$APP_DATA/.license' </del> <ins> --replace '$FILEBOT_HOME/data/.license' '$APP_DATA/.license'  --replace '-jar "$FILEBOT_HOME/jar/filebot.jar"' '-Dcom.googlecode.lanterna.terminal.UnixTerminal.sttyCommand=${coreutils}/bin/stty -jar "$FILEBOT_HOME/jar/filebot.jar"' </ins> wrapProgram $out/opt/filebot.sh  --prefix PATH : ${lib.makeBinPath [ openjdk17 ]} # Expose the binary in bin to make runnable.

Discussion:
in filebot tries to execute . This fails on NixOS: From strace: Steps to reproduce the behavior: previous output works. If applicable, add screenshots to help explain your problem. The filebot package is currently using , but I'm not sure if it's feasible to fix this with a patch. Should be used instead?
Change:
goPackagePath = "github.com/coreos/flannel"; <del> hardeningDisable = [ "fortify" ]; </del> src = fetchFromGitHub { inherit rev; owner = "coreos";

Discussion:
Using go + I am unable to build a simple Go program that makes use of C bindings. The program is a testcase from the Go compiler repository ( ) . The build fails with an error message like this: Another example is geth, the go ethereum client, in version 1.6.1: Switching to clang instead seems to be a workaround for the problem: This last command builds successfully. System: (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: Sandboxing enabled: false
I think this has to do with how Go handles GOROOT. It expects to be able to write to $GOROOT even though it's a read-only path. Could you try the buildCommand in go-ethereum:
Aw, I was wondering how to get rid of that warning. The warning is gone, but it doesn't seem to have helped: I originally ran into this issue when I tried to upgrade that linked Nix expression. Version 1.4.7 of go-ethereum compiles just fine, but 1.6.1 doesn't, because now one of the dependencies makes use of some kind of C bindings. While playing around with it I also switched over to using in the Nix expression, but that also didn't help. Switching to clang helped in the end. That version can be found here: But that's just a workaround and I would assume that other Go packages will at some point also run into this problem when they just use or .
I ran into this problem adding seccomp support to the docker package. It's caused by the -O2 optimization flag which is being by the fortify hardening flag. A possible fix would be to add hardeningDisable = [ "fortify" ]; to the buildGoPackage.
I can't no longer reproduce this on my system so I guess the issue is fixed? I created a PR to get rid of the workarounds:
I can confirm that I also cannot reproduce this anymore on my system. I am closing this - thanks!
Change:
libgit2 quazip libngspice <ins> clipper </ins> ]; postPatch = ''

Discussion:
Package name: fritzing Latest released version: 1.0.1 (not tagged, it appears to be ) <!-- Search your package here: --- Current version on the unstable channel: unstable-2022-07-01 Current version on the stable/release channel: unstable-2022-07-01 <!-- 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]:
Thanks! Updated to in
Change:
<ins> { lib, asdf-coordinates-schemas, asdf-standard, asdf-transform-schemas, asdf, astropy, buildPythonPackage, fetchFromGitHub, numpy, packaging, pytest-astropy, pytestCheckHook, pythonOlder, scipy, setuptools-scm, setuptools, tomli, wheel, }: buildPythonPackage rec { pname = "asdf-astropy"; version = "0.6.1"; pyproject = true; disabled = pythonOlder "3.10"; src = fetchFromGitHub { owner = "astropy"; repo = "asdf-astropy"; rev = "refs/tags/${version}"; hash = "sha256-dOd9QdBOu7QotRiHkXJoIqaHG6U9odTlRmy22/nvvuw="; }; nativeBuildInputs = [ setuptools setuptools-scm ]; propagatedBuildInputs = [ asdf asdf-coordinates-schemas asdf-standard asdf-transform-schemas astropy numpy packaging ]; nativeCheckInputs = [ pytest-astropy pytestCheckHook scipy ]; pythonImportsCheck = [ "asdf_astropy" ]; preCheck = '' export HOME=$(mktemp -d) ''; meta = with lib; { description = "Extension library for ASDF to provide support for Astropy"; homepage = "https://github.com/astropy/asdf-astropy"; changelog = "https://github.com/astropy/asdf-astropy/blob/${version}/CHANGES.rst"; license = licenses.bsd3; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Project description Photutils is an Astropy package for detection and photometry of astronomical sources. Metadata homepage URL: source URL: license: 3-clause BSD platforms: unix, linux, darwin, Linux, Darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I could to built here withou errors from source, just the 1.11.0 version, it is not the latest one. My nix block:
Change:
configPackages = mkDefault [ cfg.finalPackage ]; }; <del> environment.sessionVariables = mkIf cfg.envVars.enable { XDG_CURRENT_DESKTOP = "Hyprland"; XDG_SESSION_DESKTOP = "Hyprland"; XDG_SESSION_TYPE = "wayland"; GDK_BACKEND = "wayland,x11"; QT_QPA_PLATFORM = "wayland;xcb"; _JAVA_AWT_WM_NONREPARENTING = "1"; # Fix for Java applications on tiling window managers }; </del> systemd = mkIf cfg.systemd.setPath.enable { user.extraConfig = '' DefaultEnvironment="PATH=$PATH:/run/current-system/sw/bin:/etc/profiles/per-user/%u/bin:/run/wrappers/bin"

Discussion:
A clear and concise description of what the bug is. In , XDGSESSIONTYPE is now set to wayland by default for Hyprland users. However, SDDM will crash when this env var is set. Steps to reproduce the behavior: SDDM with Set under . SDDM greet will never show, and the screen will be black. These two lines can be seen in journalctl, and they are not present for boots from older generations. SDDM does not crash. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Did you enable wayland support for SDDM? ()
Thanks, enabling that option fixed the issue! Would be nice if there is an config assertion for this.
Haven't checked the implications but maybe sddm should just enable by default?
enabling wayland for SDDM, makes it impossible for me to start X11 only sessions (eg Pantheon) Is this expected, or is there a way to use SDDM with wayland and X11 sessions?
Same issue here, workaround mentioned in worked for me. I found the following stacktrace in the logs, not sure if/ how this might be helpful.
The proper workaround for now would be to set . Those are envvars that should be set only when the hyprland session starts, not categorically set.
Thanks, this worked for me. I can now start X11 sessions again :)
Same problem here using Hyprland with Budgie as a second desktop. Thanks for solution :+1: works!
Change:
++ map (p: "-p ${escapeShellArg p}") container.ports ++ optional (container.user != null) "-u ${escapeShellArg container.user}" ++ map (v: "-v ${escapeShellArg v}") container.volumes <ins> ++ (mapAttrsToList (k: v: "-l ${escapeShellArg k}=${escapeShellArg v}") container.labels) </ins> ++ optional (container.workdir != null) "-w ${escapeShellArg container.workdir}" ++ map escapeShellArg container.extraOptions ++ [container.image]

Discussion:
The configuration options do not support the assignment of labels. Labels are common for dynamic configuration, e.g. for . Look at the . Channel 21.11
Change:
serverAliases = [ "${server}-wildcard-alias.example.test" ]; useACMEHost = "example.test"; }; <del> }; </del> <ins> } // (lib.optionalAttrs (server == "nginx") { # The nginx module supports using a different key than the hostname different-key = vhostBaseData // { serverName = "${server}-different-key.example.test"; serverAliases = [ "${server}-different-key-alias.example.test" ]; enableACME = true; }; }); </ins> }; # Used to determine if service reload was triggered

Discussion:
If you have: During evaluation I get this error , pointing to the line Steps to reproduce the behavior: As described above I think this is because here The pairs are made using the , while here: It is trying to use the vhostName. So I think it should be Also, maybe this could be a problem as well, however I am not sure: I would submit a MR, but embarrassingly, I couldn't figure out how to test a patched nixpkgs lib in a flake without having my whole system rebuilt. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Broken by . Fixed by .