jiebi/CodeConvo huggingface dataset:
Change:
"See the 16.09 release notes for more information.") (mkRemovedOptionModule [ "services" "phpfpm" "phpIni" ] "") (mkRemovedOptionModule [ "services" "dovecot2" "package" ] "") <ins> (mkRemovedOptionModule [ "services" "xserver" "displayManager" "sddm" "themes" ] "Set the option `services.xserver.displayManager.sddm.package' instead.") </ins> ]; }

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:
runHook preInstall make -f misc/Makefile  <del> PYTHON=${python3.pythonOnBuildForHost.interpreter}  </del> <ins> PYTHON=${(python3.pythonOnBuildForHost.withPackages (ps: with ps; [ setuptools ])).interpreter}  </ins> PREFIX=.  DESTDIR="$out"  DATAROOTDIR=/share 

Discussion:
Steps to reproduce the behavior: qutebrowser Distutils since python 3.10 has been deprecated, possibly the issue here? Thank you! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
has a similar enough problem The solution there was to add
There is a PR fixing it by pinning to Python 3.11, the latest version with which were removed in 3.12. documentations moving to . Archlinux package .
The issue isn't as simple as adding setup tools. Actually the build itself is working fine with newer versions of python. The issue was coming from the which uses the upstream Makefile to install, primarily to preserve the logic of installing all the extra scripts, man page, etc. I worked out a fix to simply patch the makefile to call pip install instead of and it works. Apparently the latter makes internal calls to distutils cause there are none in qutebrowsers source. In any case, I'll open a PR shortly, just wanna do some additional cleanup while I'm at it.
Change:
{ coreutils, db, fetchurl, openssl, pcre2, perl, pkg-config, lib, stdenv <ins> , libxcrypt </ins> , procps, killall , enableLDAP ? false, openldap , enableMySQL ? false, libmysqlclient, zlib

Discussion:
Exim 4.97.1 has been released to fix CVE-2023-. This will also need a backport to the stable channel. Package name: exim Latest released version: 4.97.1 Current version on the unstable channel: 4.96.2 (vulnerable Current version on the stable/release channel: 4.96.2 (vulnerable) 4.96: 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:
"gateway": { "update-channel": "Gateway RELEASE", "url-template": "https://download.jetbrains.com/idea/gateway/JetBrainsGateway-{version}.tar.gz", <del> "version": "2023.1.1", "sha256": "217196806daebd14e604d13247862e44e6a0b0b9f115f1b9ceadbcfb064b3c3c", "url": "https://download.jetbrains.com/idea/gateway/JetBrainsGateway-2023.1.1.tar.gz", "build_number": "231.8770.69" </del> <ins> "version": "2023.1.2", "sha256": "fab46521e7a4558a166e3b11d86ca2312a9807e69419925ed5743ab4f421ab96", "url": "https://download.jetbrains.com/idea/gateway/JetBrainsGateway-2023.1.2.tar.gz", "build_number": "231.9011.34" </ins> }, "goland": { "update-channel": "GoLand RELEASE",

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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! --- There is , which mentions that the "script still has issues with Gateway". A manual download of the updated Gateway does work. Updating this myself is a bit over the top of my head. There is an script involved, etc. If you prefer, please fill me in on how the pipeline works! 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.
Change:
, stdenv , fetchFromGitHub , gnugrep <del> , nix , enableFlakes ? null # deprecated </del> <ins> , nixStable , nix_2_4 , enableFlakes ? false </ins> }: <ins> let nix = if enableFlakes then nix_2_4 else nixStable; in </ins> stdenv.mkDerivation rec { pname = "nix-direnv"; version = "1.5.0";

Discussion:
nix-direnv was updated in to assume that is 2.4, but that is no longer true after was merged. This causes files with to fail to active the . Steps to reproduce the behavior: sure your system is running NixOS 21.11 or is nix-darwin following the nixos-21.11 channel; (or any project with a flake); and . The specified in the flake is activated. Overriding in an overlay with allows the flake to activate the as expected. Please run and paste the result. Maintainer information:
This is only for nixpkgs. There was also a home-manager module option that needs to be re-introduced:
Hi, had the same problem too, just updated and everything is fine, seems like it's fixed now.
Yes. This was fixed in the linked pull requests.
I'm using flakes for my configuration and I still exhibit the problem with these fixed inputs: Is this expected? Or am I doing something wrong?
Looks like it was a configuration problem (). Enabling solved the issue.
Change:
outputs = [ "out" "installer" ]; setOutputFlags = false; <ins> # Work around https://github.com/NixOS/nixpkgs/issues/166205. env = lib.optionalAttrs stdenv.cc.isClang { NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}"; }; </ins> # change argv0 to "opam" as a workaround for # https://github.com/ocaml/opam/issues/2142 postInstall = ''

Discussion:
Steps to reproduce the behavior: opam It seems to be a linking problem, might be related with the fact that I'm on darwin. Thank you !!

Steps to reproduce the behavior: opam Could be related to Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
nativeBuildInputs = [ pkg-config removeReferencesTo <ins> autoreconfHook </ins> ] ++ lib.optional withQt5 qt5.wrapQtAppsHook; pythonPath = with python3Packages; [

Discussion:
The recent fixes to disable in hplip didn't seem to properly work on , making the whole package fail with a cryptic error. Additionally, due to a dependency failure in PyQt5, the package further refuses to build unless it's disabled. Steps to reproduce the behavior: an aarch64-linux user it fail due to PyQt5 failure that PyQt5 support can be disabled it fail again with -related errors hplip works n/a Current unstable as of writing this is . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc as maintainer
cc as PyQt5 maintainer due to dependency failure - should a separate issue be filed for this?
Can reproduce. I ended up moving the print server to a x86-64 machine which was conveniently only a ~meter away from the RPi.
Also got bit by this on a RaspberryPi 4 server upgrade to 22.05. Did a bit of investigation, and came up with an overlay workaround (and hplip upgrade to 3.22.4) using a patch by the Debian crew: The meat of the issue comes down to the HP folks feeling the need to include their non-free x86/-64 'ImageProcessor' in the default build (even when the applicable flag is specified). So the community consensus is hoping that HP will fix/revert this, but until then everyone's just patching it out. Could this patch be to the patch list (and likely update hplip to 3.22.4) ?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
"-DWITH_GFLAGS=0" "-DUSE_RTTI=1" "-DROCKSDB_INSTALL_ON_WINDOWS=YES" # harmless elsewhere <del> (lib.optional (stdenv.hostPlatform.isx86 && stdenv.hostPlatform.isLinux) "-DFORCE_SSE42=1") </del> <ins> (lib.optional sse42Support "-DFORCE_SSE42=1") </ins> (lib.optional enableLite "-DROCKSDB_LITE=1") "-DFAIL_ON_WARNINGS=${if stdenv.hostPlatform.isMinGW then "NO" else "YES"}" ] ++ lib.optional (!enableShared) "-DROCKSDB_BUILD_SHARED=0";

Discussion:
The derivation enables for all x86 Linux platforms (). This causes to fail on CPUs that don't support . Example CPU that fails to run : AMD G-T56N 64-bit dual core on AMD Fusion Controller Hub A55E Chipset Hardware: Steps to reproduce the behavior: the system in configuration the package . I am using nix-bitcoin for this the changes in nix-bitcoin on AMD G-T56N 64-bit dual core chip Electrs should start up and run. Instead it throws a core-dump. Systemd journal: Here's my . Please run and paste the result.
Fix in
Change:
matchesDoc = v: builtins.match (if webdoc <del> then ".*[0-9]_LINUX.sh" else ".*[0-9]_BNDL_LINUX.sh") v.src.name != null; </del> <ins> then ".*[0-9]_LIN(UX)?.sh" else ".*_B[Nn][Dd][Ll].sh") v.src.name != null; </ins> in

Discussion:
(Note: this may be a somewhat more complex upgrade, as Wolfram has moved to using the Wolfram Installer for everything. Not sure if that'll affect the actual package, though.) Package name: mathematica Latest released version: 14.1.0 <!-- Search your package here: --- Current version on the unstable channel: 14.0.0 Current version on the stable/release channel: 14.1.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.
Also, I'm not currently able to find a link with the old installer for 14.0.0. Wolfram may have taken it down, making it seemingly impossible to install this package right now. If anyone knows an archive of it, please let me know.
Found a direct link: If you're signed into your wolfram account, this will work. This works for using mathematica until the package update.
I will take a look at this later in October. I apologize for the delay.
Change:
buildInputs = [ zlib libzen libmediainfo curlWithGnuTls libmms glib ]; <ins> postPatch = '' # replace lanterna.jar to be able to specify `com.googlecode.lanterna.terminal.UnixTerminal.sttyCommand` cp ${lanterna} jar/lanterna.jar ''; </ins> dontBuild = true; installPhase = '' mkdir -p $out/opt $out/bin

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:
<del> { rustPlatform, fetchFromGitHub, lib, nasm, cargo-c }: </del> <ins> { stdenv, rustPlatform, fetchurl, fetchFromGitHub, lib, nasm, cargo-c }: </ins> rustPlatform.buildRustPackage rec { pname = "rav1e"; <del> version = "0.3.4"; </del> <ins> version = "0.4.0-alpha"; </ins> <del> src = fetchFromGitHub { owner = "xiph"; repo = "rav1e"; rev = "v${version}"; sha256 = "0zwjg0sv504i1ahzfy2jgng6qwmyvcrvdrp4n3s90r4kvwjkv8xs"; }; </del> <ins> src = stdenv.mkDerivation rec { name = "${pname}-${version}-source"; src = fetchFromGitHub { owner = "xiph"; repo = "rav1e"; rev = "v${version}"; sha256 = "1fw1gxi8330kfhl9hfzpn0lcmyn5604lc74d6g6iadzz2hmv4mb9"; }; cargoLock = fetchurl { url = "https://github.com/xiph/rav1e/releases/download/v0.4.0-alpha/Cargo.lock"; sha256 = "002s2wlzpifn5p2ahdrjdkjl48c1wr6fslg0if4gf9qpl8qj05fl"; }; </ins> <del> cargoSha256 = "1mfzshcbxky27nskxhcyrj99wd3v5f597ymgv7nb67lzp5lsyb24"; </del> <ins> installPhase = '' mkdir -p $out cp -r ./* $out/ cp ${cargoLock} $out/Cargo.lock ''; }; cargoSha256 = "1i5ldqb77rrhfxxf9krp7f6yj3h6rsqak6hf23fd2znhgmi7psb1"; </ins> nativeBuildInputs = [ nasm cargo-c ]; postBuild = ''

Discussion:
cc:
It appears that there is a bad interaction between cargo-c and cargo's LTO.
Change:
buildInputs = [ ArchiveZip ArchiveCpio <ins> SubOverride </ins> ]; <del> nativeCheckInputs = [ SubOverride ]; </del> postPatch = '' substituteInPlace lib/File/StripNondeterminism.pm  --replace "exec('file'" "exec('${lib.getExe file}'"

Discussion:
Running the script on a zip archive on darwin (nixos-23.05 and nixos-unstable) fails with: Looking at the script on linux and darwin, the Sub-Override module is just missing from the darwin script: Steps to reproduce the behavior: It should be able to process the zip file. cc:
Change:
<ins> { lib, buildGoModule, fetchFromGitHub, }: let version = "0.30.0"; in buildGoModule { pname = "csvtk"; inherit version; src = fetchFromGitHub { owner = "shenwei356"; repo = "csvtk"; rev = "refs/tags/v${version}"; hash = "sha256-xq56dErO0vjG9bZ5aISIFWX4IOHaQksE9W1is2HiFuQ="; }; vendorHash = "sha256-wJedDF7QIg8oWc/QX+rZDyq/nkAW+PMb8EYb0RGJxQM="; meta = { description = "Cross-platform, efficient and practical CSV/TSV toolkit in Golang"; changelog = "https://github.com/shenwei356/csvtk/releases/tag/v${version}"; homepage = "https://github.com/shenwei356/csvtk"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ luftmensch-luftmensch ]; mainProgram = "csvtk"; }; } </ins>

Discussion:
Project description Metadata homepage URL: source URL: license: mit platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
runHook postInstall ''; <ins> # we use makeShellWrapper instead of the makeBinaryWrapper provided by wrapGAppsHook for proper shell variable expansion </ins> postFixup = '' <del> makeWrapper ${electron}/bin/electron $out/bin/koodo-reader  </del> <ins> makeShellWrapper ${electron}/bin/electron $out/bin/koodo-reader  </ins> --add-flags $out/share/lib/koodo-reader/resources/app.asar  "''${gappsWrapperArgs[@]}"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}" 

Discussion:
Koodo reader is an electron application, and although the build process to add the proper ozone flags when the app is launched in a Wayland environment, it seems for some reason, it's not working as expected: But launching the app with the required flags, it works: The process arguments seem weird: Notice that the the by the package are truncated after the first space . I tried splitting up the flag into two sentences to avoid spaces: But now it looks l like the process does not pick up the environment variables: The variables exist, I define them as . Changing the above override to explicitly set the ozone flags (without the shell expansion conditional) works. Other packages like do the same shell expansion, and they also work in my environment without overriding anything. Steps to reproduce the behavior: in a wayland environment (I'm using hyprland) if the application is using xwayland by running shows the application again but with the ozone flags the app does not use xwayland: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm not a wayland user, so I usually just copy this line from other electron apps' definitions and hope it works. I think the issue here is that when is present will use the binary implementation, which doesn't expand shell variables, thus not making this work. It looks like I forgot about this behaviour when packaging this.
Change:
gsettings-desktop-schemas libosinfo gtksourceview4 ] ++ lib.optional spiceSupport spice-gtk; <del> propagatedBuildInputs = with python3.pkgs; [ </del> <ins> dependencies = with python3.pkgs; [ </ins> pygobject3 libvirt libxml2 requests cdrtools ];

Discussion:
Build on () and when running I find in the runtime closure pytest shouldn't be a runtime dependency <!-- 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]:
Change:
buildPythonPackage rec { pname = "einops"; <del> version = "0.3.2"; </del> <ins> version = "0.4.1"; </ins> src = fetchFromGitHub { owner = "arogozhnikov"; repo = pname; rev = "v${version}"; <del> sha256 = "0ix094cfh6w4bvx6ymp5dpm35y9nkaibcn1y50g6kwdp4f0473y8"; </del> <ins> hash = "sha256-n4R4lcRimuOncisCTs2zJWPlqZ+W2yPkvkWAnx4R91s="; </ins> }; checkInputs = [

Discussion:
Build of failed on x86_64-linux as of . Maintainer cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
Change:
, multiprocess , pefile , pyelftools <ins> , pythonOlder </ins> , python-registry , pyyaml , unicorn

Discussion:
seems to be missing a dependency which was introduced in 1.4.1 (the current version in nixpkgs, 1.4.2 has already been released, so probably should be updated). The build fails: I am puzzled how this slipped past the checks. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. I am building on Fedora. system: multi-user?: sandbox: version: channels(): nixpkgs:
Change:
die(){ echo $@; exit 1; } # custom unpack: <ins> mkdir fglrx cd fglrx </ins> unzip $src <del> run_file=$(echo fglrx-*/amd-driver-installer-*) </del> <ins> cd .. run_file=$(echo fglrx/amd-driver-installer-*) </ins> sh $run_file --extract . eval "$patchPhase"

Discussion:
I was given a tip by vcunat to upgrade the kernel to see if my GPU requires a newer kernel version (AMD has done a lot of adding to the linux kernel lately). But I received the same error when I tried upgrading to linuxPackages314 and linuxPackageslatest: /tmp/nix-build-ati-drivers-13.12- In function 'KCLACPIGetHandles': /tmp/nix-build-ati-drivers-13.12- error: 'struct acpidevnode' has no member named 'handle' pInfo-videohandle = pInfo-pcidev-; Can someone reproduce this? Suggested fix?
These are common problems. AMD's proprietary drivers have problems compiling with newer kernels. On gentoo they have patches , and they have multiple versions working, probably even with 3.14. The build process is a terrible mess though, so it won't be straightforward to port. Anyway, I'd think that the AMD work in kernel mostly only affects the free drivers.
True enough, and they might migrate completely to open source - but that time is not now :/ With the open source ATI drivers I'm seeing screen tears and all kinds of strange screen corruptions when, for instance, suspending to disk. I'm not sure this would be remedied by them releasing patches any time soon.
Try
This issue remains for 3.19 and 4.0. I'm still running 3.18 because of this. I hope there is some progress going on?
Driver needs an update to 15.5, which might fix your compilation issues? (I'll swap across to an ati card and test the update sometime in the coming week if nobody beats me to it) It's unlikely that your issues with 3.19 and 4.0 are the same compilation issues that this thread had initially, which were fixed in one of the ati driver updates.
Do you had any success?
I have a fix for this which fixes compilation issues and also upgrades to 15.07. Pull request incoming shortly as soon I get it properly merged into the tree rather than implemented as an override.
Thanks for getting to this dfoxfranke. I normally use my ati card for vga passthrough to a windows vm so this fell to the bottom of the priority list for me.
Change:
cabal2nix --revision "$ghcide_new_version" "https://github.com/haskell/ghcide" > "$ghcide_derivation_file" <ins> # =========================== # HLS maintainer's Brittany fork # =========================== # brittany derivation created with cabal2nix. brittany_derivation_file="${script_dir}/hls-brittany.nix" # This is the current revision of the brittany fork in Nixpkgs. brittany_old_version="$(sed -En 's/.*bversion = "(.*?)".*/1/p' "$brittany_derivation_file")" brittany_new_version=$(curl --silent "https://api.github.com/repos/bubba/brittany/commits/ghc-8.10.1" | jq '.sha' --raw-output) echo "Updating haskell-language-server's brittany from old version $brittany_old_version to new version $brittany_new_version." echo "Running cabal2nix and outputting to ${brittany_derivation_file}..." cabal2nix --revision "$brittany_new_version" "https://github.com/bubba/brittany" > "$brittany_derivation_file" </ins> # =========================== # HLS

Discussion:
Describe the bug , a nested dependency, requires < 4.1.14. To Reproduce
Can probably be closed now?
Yes, I thought that would happen automatically.
I just bumped on (something very similar to?) this:
Change:
disabledTests = [ # Fail with: 'no server running on /tmp/tmux-1000/libtmux_test8sorutj1'. "test_new_session_width_height" <ins> ] ++ lib.optionals stdenv.isDarwin [ # tests/test_pane.py:113: AssertionError "test_capture_pane_start" </ins> ]; disabledTestPaths = lib.optionals stdenv.isDarwin [ <del> "test_test.py" </del> <ins> "tests/test_test.py" "tests/legacy_api/test_test.py" </ins> ]; pythonImportsCheck = [ "libtmux" ];

Discussion:
Steps to reproduce the behavior: The derivation failed to build on macOS at test stage Encounter this problem when build , as is the dependency. <!-- 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.