jiebi/CodeConvo huggingface dataset:
Code change:
sha256 = "add96ad3509d4d5c6d8658b005dfd046963cd6bb0a4e1f3e88f726a86c05810f"; }; <ins> passthru.tests = nixosTests.freetube; </ins> appimageContents = appimageTools.extractType2 { name = "${pname}-${version}"; inherit src;

Related discussion:
text: Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.
Code change:
aarch64-darwin = "97adf13306c9b3b304d3e9ddf68f5f7fb9b79c9a1342114e3671182f3cc9e808"; headers = "0gl30q2igr9c8sjlhyj5w57dm5navpkas5hnz9yl7sasbx66v10v"; }; <ins> electron_19 = mkElectron "19.0.7" { armv7l-linux = "d6a6d2d7c0d658695783137d032a50f20843cdfe6582ef985451d741eef4dd32"; aarch64-linux = "58685d21bb92c2667d20063ab12aabc2e5c2518f3eda84e98a0fa2306456ce57"; x86_64-linux = "a4c20a068c54c238ae8c440ab8f46d39eda4168d6aa8cffcaae406800b539983"; x86_64-darwin = "2709dd94e22ecfc8e7de0c7a7009160ed79e95ba91618c7307e24c26a33e978b"; aarch64-darwin = "f9042bce83fe8446e22f6885285dd5fc2dca048d0b89cbf7f326a46102ffc440"; headers = "09dbx4qh0rgp5mdm6srz6fgx12zq6b9jqq1k6l3gzyvwigi3wny1"; }; </ins> }

Related discussion:
text: Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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 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: <!-- The current version can be found easily with the same process as 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: 18.1.0 desired version: 19.0.7 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package
Code change:
mkdir -p $out/bin makeWrapper ${Agda}/bin/agda $out/bin/agda  --add-flags "--with-compiler=${ghc}/bin/ghc"  <del> --add-flags "--library-file=${library-file}"  --add-flags "--local-interfaces" </del> <ins> --add-flags "--library-file=${library-file}" </ins> ln -s ${Agda}/bin/agda-mode $out/bin/agda-mode <del> ''; # Local interfaces has been added for now: See https://github.com/agda/agda/issues/4526 </del> <ins> ''; </ins> withPackages = arg: if builtins.isAttrs arg then withPackages' arg else withPackages' { pkgs = arg; };

Related discussion:
text: Describe the bug The new version of Agda is working fine on other systems, but not NixOS. I've reported a bit more about what is known at To Reproduce Steps to reproduce the behavior: Agda 2.6.1 any file (e.g, ) Expected behavior Agda checks the file quickly and exits. Additional context Issue in the Agda repository: agda/agda Metadata Maintainer information:
I believe that this is fixed by rework of our Agda setup ! (Which is included in the most recent nixos-unstable.) Can you confirm? :-) $ echo module Main where && time agda Checking Main (). real 0m0.132s user 0m0.104s sys 0m0.028s Looks reasonable!
I haven't had chance to test the new stuff, but this issue probably should be closed anyway, as it's being worked on upstream (). I'm doing fine now using the workaround of adding option .
Code change:
libgphoto2 libjpeg libpng librsvg libtiff openexr sqlite libxslt libsoup graphicsmagick json-glib openjpeg lua pugixml colord colord-gtk libwebp libsecret gnome3.adwaita-icon-theme <del> osm-gps-map </del> <ins> osm-gps-map ocl-icd </ins> ]; cmakeFlags = [ "-DBUILD_USERMANUAL=False" ];

Related discussion:
text: Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?
Code change:
githubId = 70191398; name = "Ryan Cao"; }; <ins> ryand56 = { email = "git@ryand.ca"; github = "ryand56"; githubId = 22267679; name = "Ryan Omasta"; }; </ins> ryane = { email = "ryanesc@gmail.com"; github = "ryane";

Related discussion:
text: Project description A very small, very simple, yet very secure encryption tool. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, windows
Code change:
lib.optional (coreutils != null) "PR_PROGRAM=${coreutils}/bin/pr" ++ lib.optional (stdenv.buildPlatform != stdenv.hostPlatform) "gl_cv_func_getopt_gnu=yes"; <del> doCheck = true; </del> <ins> # Test failure on QEMU only (#300550) doCheck = !stdenv.buildPlatform.isRiscV64; </ins> meta = with lib; { homepage = "https://www.gnu.org/software/diffutils/diffutils.html";

Related discussion:
text: Steps to reproduce the behavior: diffutils-3.10-riscv64-linux i had suspended the system halfway through the build, and suspected that might have caused an issue, so i ran the build again and got the same result <!-- 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]:
I can't reproduce this failure on RISC-V hardware. With , the following command runs just fine: Could this be an issue with the emulator you're using or a result of ?
The following command also builds for me. Relevant excerpt of the logs: Could you try running this in your build environment to see whether it's an issue with your emulator or build machine? If it builds, could you improve the reproducing instructions you've given?
I ran that command on a seperate x86 machine and recieved the same build failure
I have successfully reproduced the issue by emulating RISC-V on an x86 machine. So this could be caused by a QEMU bug. I suggest you update the title to make it clear that it only happens with binfmt emulation.
Ok i edited the title
i'm curious why the gnugrep pr was merged, but not this one ? given that confirmed this build failure, but not the other one ?
The other one just got the attention of a committer a bit earlier
Code change:
]; buildInputs = [ <del> llvmPackages_39.llvm llvmPackages_39.clang-unwrapped </del> <ins> llvmPackages_4.llvm llvmPackages_4.clang-unwrapped </ins> hiredis gtest ]; <ins> patches = [ ./cmake-fix.patch ]; </ins> enableParallelBuilding = true; preConfigure = ''

Related discussion:
text: was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )
Code change:
preBuild = stdenv.lib.optionalString stdenv.isDarwin "unset AR"; <ins> GRPC_BUILD_WITH_BORING_SSL_ASM = ""; </ins> GRPC_PYTHON_BUILD_SYSTEM_OPENSSL = 1; GRPC_PYTHON_BUILD_SYSTEM_ZLIB = 1; GRPC_PYTHON_BUILD_SYSTEM_CARES = 1;

Related discussion:
text: Describe the bug is broken in latest master To Reproduce Steps to reproduce the behavior: -build -A lieer cc
I reverted locally, and got it to build again - so it's definitely some incompatibility with the openssl we pass in.
that commit is from 4 years ago, I wonder why it's making an appearance now
This error seems to be present since (more specifically ), so is probably mostly unrelated to it.
Code change:
"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

Related discussion:
text: 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
Code change:
# Needs GCC rocprofiler = callPackage ./rocprofiler { <ins> inherit rocmUpdateScript clr rocm-core rocm-thunk rocm-device-libs roctracer rocdbgapi rocm-smi hsa-amd-aqlprofile-bin; </ins> inherit (llvm) clang; <del> inherit rocmUpdateScript clr rocm-thunk roctracer rocm-smi hsa-amd-aqlprofile-bin; </del> }; # Needs GCC

Related discussion:
text: When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see
Code change:
buildPythonPackage rec { pname = "libvirt"; <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = "libvirt"; repo = "libvirt-python"; rev = "v${version}"; <del> sha256 = "sha256-/OS+qBo0h9jshKDuxKX++cRPAjegImQROb7Uh+imOUA="; </del> <ins> sha256 = "sha256-eJ0RPxJ4Gm+VGs6NeTWP2FbvDnJy4mURPlFbgvkSgo0="; </ins> }; nativeBuildInputs = [ pkg-config ];

Related discussion:
text: When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.
Code change:
buildPythonPackage rec { pname = "libvirt"; <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = "libvirt"; repo = "libvirt-python"; rev = "v${version}"; <del> sha256 = "sha256-/OS+qBo0h9jshKDuxKX++cRPAjegImQROb7Uh+imOUA="; </del> <ins> sha256 = "sha256-eJ0RPxJ4Gm+VGs6NeTWP2FbvDnJy4mURPlFbgvkSgo0="; </ins> }; nativeBuildInputs = [ pkg-config ];

Related discussion:
text: I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
Code change:
hash = "sha256-cyyxu/oj4QEFp3CVx2WeXa9T4OAUyynuBJHGkBZSxJI="; }; <ins> patches = [ # CMake formatting, required for the next two commits to cleanly apply (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/5555f467f68ce7cdf1060991c24263073b95e9da.patch"; hash = "sha256-yNkg7GCXDPJdsE7M6J98YylnRxQWpcM5N3olix7Oc1A="; }) # removes wayland-scanner from deps, as it includes a pkg-config that # defines that it has a non-existent include directory which trips up CMake (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/0dd9af698b9386bcf25d3ea9f5017eca721831c1.patch"; hash = "sha256-Y6eWASHoMXVN2rYJ1rs0jy2qP81/qbHsZU+6b7XNBBg="; }) # handle finding wayland-scanner more nicely (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/2425e8f541525fa7409d9f26a8ffaf92a3767251.patch"; hash = "sha256-6dCg/U/SIjtvo07Z3tn0Hn8Xwx72nwVz6Q2cFnObonU="; }) ]; depsBuildBuild = [ pkg-config ]; </ins> nativeBuildInputs = [ cmake pkg-config

Related discussion:
text: Steps to reproduce the behavior: xdg-desktop-portal-hyprland-1.3.3 This issue only recently occurred upon updating to the latest revision. My entire nix config is . <!-- 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]:
I suspect this is fixed by For some reason has a pkg-config that defines that it has a non-existent include directory, which cmake then later chokes on since it declares it has a dependency on as a package, not a tool.
Indeed. I'm cooking up a PR for this.
Code change:
./qtbase.patch ./qtbase-darwin.patch ./qtbase-revert-no-macos10.10.patch <ins> ] ++ optionals stdenv.isDarwin [ ./qtbase-darwin-nseventtype.patch </ins> ]; qtdeclarative = [ ./qtdeclarative.patch ]; qtscript = [ ./qtscript.patch ];

Related discussion:
text: It looks like Qt has broken support for SDK 10.10 in their latest release. Here is the log: Any ideas on how we can fix this?
fixes this.
We should probably keep this open tho, we can't keep using
Code change:
install -Dm644 ../packaging/linux/${pname}.desktop $out/share/applications/${pname}.desktop ''; <del> passthru.updateScript = ./updater.sh; </del> <ins> passthru = { tests.sunshine = nixosTests.sunshine; updateScript = ./updater.sh; }; </ins> meta = with lib; { description = "Sunshine is a Game stream host for Moonlight";

Related discussion:
text: Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
Code change:
<ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

Related discussion:
text: Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.
Code change:
<ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

Related discussion:
text: Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:
Code change:
, attr , bash , btrfs-progs <ins> , cdrkit </ins> , criu , dnsmasq <ins> , e2fsprogs , getent </ins> , gnutar , gptfdisk , gzip , iproute2 , iptables <ins> , kmod , lvm2 , minio , nftables </ins> , OVMF , qemu_kvm , qemu-utils , rsync , spice-gtk , squashfsTools <ins> , thin-provisioning-tools </ins> , util-linux , virtiofsd , xz

Related discussion:
text: When tries to create a volume of type=block, it cannot be created due to the occurrence of . This is because is not registered in . Steps to reproduce the behavior: Create block type volume. If you check nixpkgs for lxd 5.20, you can see other package dependencies that are not present in incus. For example with lvm, this is expected to severely impact the lvm backend. (Currently, it cannot be confirmed because there is no lvm drive.) Can we change it in the same way as lxd? <!-- 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]:
Opened a PR to fix. Sorry about that. Not sure why I dropped these...
Code change:
python3.pkgs.buildPythonApplication rec { pname = "gitless"; <del> version = "0.8.8"; </del> <ins> version = "0.9.17"; </ins> format = "setuptools"; src = fetchFromGitHub { <del> owner = "gitless-vcs"; </del> <ins> owner = "goldstar611"; </ins> repo = pname; <del> rev = "v${version}"; hash = "sha256-xo5EWtP2aN8YzP8ro3bnxZwUGUp0PHD0g8hk+Y+gExE="; </del> <ins> rev = version; hash = "sha256-XDB1i2b1reMCM6i1uK3IzTnsoLXO7jldYtNlYUo1AoQ="; </ins> }; nativeBuildInputs = [ python3.pkgs.pythonRelaxDepsHook ]; propagatedBuildInputs = with python3.pkgs; [ <del> sh </del> pygit2 <del> clint </del> <ins> argcomplete </ins> ]; pythonRelaxDeps = [ "pygit2" ];

Related discussion:
text: The original author of gitless has not committed any code to it since 2021, and the version currently in nixpkgs errors out when trying to do anything useful with it. has forked and continued to develop it though: Package name: gitless Latest released version: 0.9.17 Current version on the unstable channel: 0.8.8 Current version on the stable/release channel: 0.8.8 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.
Thanks for the tag! I'm glad that gitless can live on past the initial MIT research that was conducted. Although it's been a while since I've updated gitless, it has been very useful for my day to day work and I'm committed to fixing bugs in a timely manner.
Sure! I rediscovered gitless (and your fork) on the back of a recent Slack discussion with folks from about the best way to make version control as accessible as possible for newcomers in the research community.