jiebi/CodeConvo huggingface dataset:
Code change:
source = "${nvidia_x11.bin}/share/nvidia/nvidia-application-profiles-rc"; }; <ins> # 'nvidia_x11' installs it's files to /run/opengl-driver/... environment.etc."egl/egl_external_platform.d".source = "/run/opengl-driver/share/egl/egl_external_platform.d/"; </ins> hardware.opengl.package = mkIf (!offloadCfg.enable) nvidia_x11.out; hardware.opengl.package32 = mkIf (!offloadCfg.enable) nvidia_x11.lib32; hardware.opengl.extraPackages = optional offloadCfg.enable nvidia_x11.out;

Related discussion:
text: I came here because I'm experiencing the same as and Can't launch Steam or Kitty under Wayland: nvidia: 470.42.01 xwayland: 21.1.2 Config is virtually identical to
I found this issue because I had the same problem as After reading , I tried to create a different file (listed in the end). And that solved my problem. With this file, I can open steam. However, alacritty still has an error. Maybe that relates to another . The cause of this problem is that even though both and packages provide , cannot be found without a json file. The says: So, maybe we should add a json file /usr/share/egl/eglexternalplatform.d /xxx.jsonnvidia-x11egl-waylandlibnvidia-egl-wayland.solibnvidia-egl-, gnome setting says my video card is "Unknown". In the end, I will post my related config:
I filed this issue to see if we can patch to look in the right place: If we can't get it to look in then we should probably just add the etc symlink in the nixos module so that this works correctly for end users out of the box. I'll send an initial PR shortly and will update it in that egl-wayland issue gets a useful answer (or if there's another way to patch a closed source SO that I'm not thinking of).
BTW, I can confirm the different results. When I override nvidia's with our "upstream" one, I get more info in , but I'm not sure if there are other functional differences. Not sure what I would've expected, but it nags me that there's a difference.
PR:
Interesting, there IS a way to override the egl_externaplatform search path(s):
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
would this still be an issue after ?
I think it needs and
I am taking over as I've been using that setup as a daily driver and have a rough working understanding of the pieces fitting together. And to confirm, the general problem here, that is addressed in , is EGLStreams working in Wayland environment with the NVIDIA driver (aka, it doesn't now because we don't "wire up" NVIDIA's egl driver per egl-wayland's expectations).
Code change:
source = "${nvidia_x11.bin}/share/nvidia/nvidia-application-profiles-rc"; }; <ins> # 'nvidia_x11' installs it's files to /run/opengl-driver/... environment.etc."egl/egl_external_platform.d".source = "/run/opengl-driver/share/egl/egl_external_platform.d/"; </ins> hardware.opengl.package = mkIf (!offloadCfg.enable) nvidia_x11.out; hardware.opengl.package32 = mkIf (!offloadCfg.enable) nvidia_x11.lib32; hardware.opengl.extraPackages = optional offloadCfg.enable nvidia_x11.out;

Related discussion:
text: That is pretty tangential to NVIDIA having a driver that supports GBM allocation and "wiring it up" (an extra piece included in ), and it being discoverable (whatever I send to replace ). Hope that helps.
Also, to reiterate, is good to merge independently on it's own and will resolve this issue. Separately, a replacement for will be necessary for the ideal Sway scenario without users having to set an extra env var.
I thought the point of the new Nvidia driver was to finally move away from EGLStreams? Is EGLStreams used by the new stable driver at all?
I don't know? It doesn't really matter, we should still fix it? Like, the fundamental issue is that we're simply not installing the Nvidia driver correctly for NixOS when it comes to these important configuration JSON files. Plus, it's not like everything is going to immediately switch to GBM, drop EGL, know about the env var, on and on. That, and the wiring for GBM is in that PR and I'm not splitting them apart at the current merge rate.
Code change:
imports = [ (mkRenamedOptionModule [ "networking" "networkmanager" "packages" ] <del> [ "networking" "networkmanager" "plugins" ]) (mkRenamedOptionModule [ "networking" "networkmanager" "useDnsmasq" ] [ "networking" "networkmanager" "dns" ]) </del> <ins> [ "networking" "networkmanager" "plugins" ] ) (mkRenamedOptionModule [ "networking" "networkmanager" "useDnsmasq" ] [ "networking" "networkmanager" "dns" ] ) (mkRemovedOptionModule [ "networking" "networkmanager" "extraConfig" ] '' This option was removed in favour of `networking.networkmanager.settings`, which accepts structured nix-code equivalent to the ini and allows for overriding settings. Example patch: ```patch networking.networkmanager = { -    extraConfig = ''' -      [main] -      no-auto-default=* -    ''' +    extraConfig.main.no-auto-default = "*"; }; ``` '' ) </ins> (mkRemovedOptionModule [ "networking" "networkmanager" "enableFccUnlock" ] '' This option was removed, because using bundled FCC unlock scripts is risky, might conflict with vendor-provided unlock scripts, and should

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
++ lib.optional perlBindings perl ++ lib.optional saslSupport sasl; <del> patches = [ ./apr-1.patch ]; </del> <ins> patches = [ ./apr-1.patch ] ++ extraPatches; </ins> # We are hitting the following issue even with APR 1.6.x # -> https://issues.apache.org/jira/browse/SVN-4813

Related discussion:
text: , CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
Code change:
import json import os <ins> import sys </ins> from pathlib import Path XDG_CONFIG_HOME = os.environ.get("XDG_CONFIG_HOME") or os.path.join(

Related discussion:
text: Discord's package has a script which disables breaking updates, by looking and modifying the file. This script breaks if said exists but is empty (fails to load the JSON object) For some reason all values in this file cleared to me and I encountered this issue. (tested on NixOS 22.11 but the script hasn't changed in master) Steps to reproduce the behavior: discord discord should not launch at all (silently, unless launched from a terminal) should handle the exception which arises from this issue. N/A Some logs of when this happens: <!-- 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.
Hmm, interesting that Discord doesn't launch at all. This is a pretty simple fix though, Or something like that (Now that I think about it, if the doesn't exist yet, the script could create it)
Tangentally related: I installed discord on a new machine, and the disable breaking updates script didn't appear to have any effect until I created an empty containing just . There were other files in , but not . Creating that would be nice. Also, the only real indication that it was missing is that when I ran from a terminal, the first line of the output was . This is quite easy to miss because it's at the top of the output, so maybe it would be good to show these errors in a dialog or something similar.
I'm surprised this is even in tree - I don't think we should be changing program behavior - especially when you're calling it . I doubt the majority of the users even knew this was happening outside of those involved in PRs for nixpkgs. This is a matter of convenience like stated in the script that has a trade off causing a degradation in the security of the application - causing users to not update - relying on maintainers to do it. Please create a separate package for this at the same time when fixing this - call it whatever - just not . Or enclose it in an arg that is disabled by default.
I hit this same issue and adding an with contents got it running for me as well.
Thanks for opening an issue and describing the fix. This broke for me too and it took me a while to figure out why ...
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
license = licenses.lgpl21Plus; platforms = lib.platforms.linux; maintainers = [ ]; <ins> knownVulnerabilities = [ "CVE-2020-35476" # https://github.com/OpenTSDB/opentsdb/issues/2051 ]; </ins> }; }

Related discussion:
text: , CVSSv3=9.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
Code change:
# tesseract & leptonica. ++ lib.optionals enableTesseract [ tesseract leptonica ] ++ lib.optional enableTbb tbb <del> ++ lib.optional enableCuda cudatoolkit </del> ++ lib.optionals stdenv.isDarwin [ bzip2 AVFoundation Cocoa VideoDecodeAcceleration ] ++ lib.optionals enableDocs [ doxygen graphviz-nox ]; <del> propagatedBuildInputs = lib.optional enablePython pythonPackages.numpy; </del> <ins> propagatedBuildInputs = lib.optional enablePython pythonPackages.numpy ++ lib.optional enableCuda cudatoolkit; </ins> nativeBuildInputs = [ cmake pkg-config unzip ];

Related discussion:
text: qimgv fails to build when . Steps to reproduce the behavior: No build errors. N/A. N/A. Maintainer information:
I am working on a patch to OpenCV to fix this issue correctly. In the meantime, you can replace with and it will build and operate properly. On my system I also had to add to to stop it crashing when I tried to open a file dialog but maybe that is just because I run Nix on Ubuntu instead of NixOS.
Code change:
"ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "08c118j440xpfbjjxmwzm6dfnv4y35q540mmzkchhpbwx89lczxd"; </del> <ins> sha256 = "0zd6skf9qcwlk1k1ljgwijwlyz5si3pgi0h97gd6kkivm7a4y43p"; </ins> }; # TODO: #  revive ./dricore-gallium.patch when it gets ported (from Ubuntu), as it saved #  ~35 MB in $drivers; watch https://launchpad.net/ubuntu/+source/mesa/+changelog patches = [ <del> # fixes pkgsMusl.mesa build </del> <ins> # To fix flickering on Intel GPUs (iris), see https://github.com/NixOS/nixpkgs/issues/153377: </ins> (fetchpatch { <del> url = "https://raw.githubusercontent.com/void-linux/void-packages/b9f58f303ae23754c95d5d1fe87a98b5a2d8f271/srcpkgs/mesa/patches/musl.patch"; sha256 = "sha256-Jyl7ILLhn8hBJG7afnEjE8H56Wz/1bxkvlqfrXK5U7I="; </del> <ins> url = "https://gitlab.freedesktop.org/mesa/mesa/-/commit/07dc3d4238e57901ccf98e0b506d9aad2c86b9d9.diff"; sha256 = "sha256-3fa1qHJes3x1/iXsxfjgy9HnEGlOyFtJatSkU1a3XDI="; </ins> }) <ins> # fixes pkgsMusl.mesa build ./musl.patch </ins> (fetchpatch { url = "https://raw.githubusercontent.com/void-linux/void-packages/b9f58f303ae23754c95d5d1fe87a98b5a2d8f271/srcpkgs/mesa/patches/musl-endian.patch"; sha256 = "sha256-eRc91qCaFlVzrxFrNUPpAHd1gsqKsLCCN0IW8pBQcqk=";

Related discussion:
text: Thanks a lot for putting together a fix! I'm happy to test. Could you confirm I understood the instructions correctly? 1) integrate the code from the above PR into my nixpkgs tree. 2) put the following into my nixos config: 3) replace with the path to my nixpkgs tree. 4) run Did I get that right?
It's the easiest if you use a separate/dedicated Nixpkgs tree for Mesa ( in the example). That way you don't have to rebuild a lot of other packages (which would most likely still take way too long). You can also cherry-pick the commit to (I'd recommend doing that) which saves additional rebuilds (I only tested it that way so no idea how many many builds are currently cached for staging-next). The rest looks fine. And thanks in advance :)
It works like a charm. Thanks
Seems like this wasn't closed automatically once landed in master. Should be fixed now. And upstream merged the required patches in the meantime (s. note in ). And thanks for testing the fix and :)
Code change:
Xaw3d ghostscriptX perl <del> ] ++ stdenv.lib.optionals stdenv.isDarwin [ </del> pkgconfig <ins> ] ++ stdenv.lib.optionals stdenv.isDarwin [ </ins> libiconv ];

Related discussion:
text: gv crashes with a segmentation fault immediately upon starting, before a window is visible. This happens even with an empty dummy document (created using latex and pdf2ps). For ease of reproducibility, you can find it . $ nix-shell -p gv [nix-shell:~]$ gv Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Thanks for merging! Glad that this is fixed. :-)
Code change:
<del> { stdenv, fetchurl, makeWrapper, jre, callPackage }: let dotty-bare = callPackage ./dotty-bare.nix { inherit stdenv fetchurl makeWrapper jre; }; in stdenv.mkDerivation { pname = "dotty"; inherit (dotty-bare) version; dontUnpack = true; installPhase = '' mkdir -p $out/bin ln -s ${dotty-bare}/bin/scalac $out/bin/scalac ln -s ${dotty-bare}/bin/scaladoc $out/bin/scaladoc ln -s ${dotty-bare}/bin/scala $out/bin/scala ln -s ${dotty-bare}/bin/common $out/bin/common ''; inherit (dotty-bare) meta; } </del>

Related discussion:
text: Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be
Code change:
("generators.mkValueStringDefault: " + "${t} not supported: ${toPretty {} v}"); in   if isInt      v then toString v <ins> # convert derivations to store paths else if lib.isDerivation v then toString v </ins> # we default to not quoting strings else if isString   v then v # isString returns "1", which is not a good default

Related discussion:
text: hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:
Code change:
!langJit && !stdenv.hostPlatform.isDarwin && enableShared <del> ; </del> <ins> ; </ins> <del> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </del> <ins> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </ins> in (pkg: pkg.overrideAttrs (previousAttrs: lib.optionalAttrs ((!langC) || langJit || enableLibGccOutput) {

Related discussion:
text: On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.
Code change:
!langJit && !stdenv.hostPlatform.isDarwin && enableShared <del> ; </del> <ins> ; </ins> <del> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </del> <ins> # For some reason libgcc_s.so has major-version "2" on m68k but # "1" everywhere else.  Might be worth changing this to "*". libgcc_s-version-major = if targetPlatform.isM68k then "2" else "1"; </ins> in (pkg: pkg.overrideAttrs (previousAttrs: lib.optionalAttrs ((!langC) || langJit || enableLibGccOutput) {

Related discussion:
text: Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.
Code change:
# Arguments that this derivation gets when it is created with `callPackage` { stdenv , lib <del> , symlinkJoin </del> , makeWrapper <ins> , symlinkJoin </ins> , yt-dlp }:

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: mpv <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.33.1 desired version: 0.34.0 <!-- 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.
Code change:
sed '2i echo Skipping rm deep-2 test && exit 77' -i ./tests/rm/deep-2.sh sed '2i echo Skipping du long-from-unreadable test && exit 77' -i ./tests/du/long-from-unreadable.sh <ins> # The test tends to fail on cephfs sed '2i echo Skipping df total-verify test && exit 77' -i ./tests/df/total-verify.sh </ins> # Some target platforms, especially when building inside a container have # issues with the inotify test. sed '2i echo Skipping tail inotify dir recreate test && exit 77' -i ./tests/tail/inotify-dir-recreate.sh

Related discussion:
text: Steps to reproduce the behavior: error occurs is installed as a standalone binary. There is custom configuration: The test that fails is : I would, but it depends on coreutils. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like a "known issue" without a solution with cephfs and that test: If you can use default path for store instead of: you won't have to build it yourself as it should be fetched from instead.
Unfortunately, I very much cannot use . Given that it's a known bug with that test, would a PR disabling that test likely be accepted into nixpkgs?
Maintainers for in nixpkgs would probably be able answer it better. But you can always overlay/add patch to your own config. Considering you are already building everything from scratch there won't be that much difference there.
Not sure why this wasn't auto closed.
Code change:
{ lib , buildPythonPackage <ins> , fetchpatch </ins> , fetchPypi , isPy3k , pytestCheckHook

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -