jiebi/CodeConvo huggingface dataset:
Code change:
i686bundled = versionAtLeast version "391" && !disable32Bit; libPathFor = pkgs: pkgs.lib.makeLibraryPath [ pkgs.libdrm pkgs.xorg.libXext pkgs.xorg.libX11 <del> pkgs.xorg.libXv pkgs.xorg.libXrandr pkgs.xorg.libxcb pkgs.zlib pkgs.stdenv.cc.cc ]; </del> <ins> pkgs.xorg.libXv pkgs.xorg.libXrandr pkgs.xorg.libxcb pkgs.zlib pkgs.stdenv.cc.cc pkgs.wayland ]; </ins> self = stdenv.mkDerivation { name = "nvidia-x11-${version}${nameSuffix}";

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:
i686bundled = versionAtLeast version "391" && !disable32Bit; libPathFor = pkgs: pkgs.lib.makeLibraryPath [ pkgs.libdrm pkgs.xorg.libXext pkgs.xorg.libX11 <del> pkgs.xorg.libXv pkgs.xorg.libXrandr pkgs.xorg.libxcb pkgs.zlib pkgs.stdenv.cc.cc ]; </del> <ins> pkgs.xorg.libXv pkgs.xorg.libXrandr pkgs.xorg.libxcb pkgs.zlib pkgs.stdenv.cc.cc pkgs.wayland ]; </ins> self = stdenv.mkDerivation { name = "nvidia-x11-${version}${nameSuffix}";

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:
} assert(_lock == null); + <del> +    final Directory dir = globals.fs.directory(globals.fs.path.join(homeDirPath, '.cache', 'flutter')); </del> <ins> +    final Directory dir = globals.fs.directory(globals.fs.path.join(globals.fsUtils.homeDirPath, '.cache', 'flutter')); </ins> +    if (!dir.existsSync()) { +      dir.createSync(recursive: true); <del> +      os.chmod(dir, '755'); </del> <ins> +      globals.os.chmod(dir, '755'); </ins> +    } final File lockFile = -        globals.fs.file(globals.fs.path.join(flutterRoot, 'bin', 'cache', 'lockfile')); <del> +        globals.fs.file(globals.fs.path.join(homeDirPath, '.cache', 'flutter', 'lockfile')); </del> <ins> +        globals.fs.file(globals.fs.path.join(globals.fsUtils.homeDirPath, '.cache', 'flutter', 'lockfile')); </ins> try { _lock = lockFile.openSync(mode: FileMode.write); } on FileSystemException catch (e) {

Related discussion:
text: When trying to install , the build fails with: To reproduce, use the following and run it with : I think this happens because of the symlink of the , which seems to be resolved while running the build and in that case the symlink target does not exist. /cc btw: could you please also add support for the latest beta / dev / stable releases?
Hey it's fixed in the latest commit. Can you try it ?
Works fine, thank you very much for the fast fix!
Code change:
-not -name '*.so.*'  -not -name '*.so'  -not -name '*.jar'  <ins> -not -name 'jspawnhelper'  </ins> -not -path '*/resources/*' |  while IFS= read -r f ; do patchelf --set-interpreter "${stdenv.cc.bintools.dynamicLinker}" $f

Related discussion:
text: When I try to open a file dialog in Bitwig Studio 4.1.0 I am getting that error: I can manually start from command line and I'm seeing the file dialog and it returns the selected file. Unsure if this is of any use but is the decompiled class that calls . Steps to reproduce the behavior: bitwig (or open any other file dialog in bitwig) GTK file dialog opens Maintainer information: EDIT: more information
I am not a maintainer of bitwig sudio. Just because I changed some lines does not make me knowledgeable about this issue.
Sorry for that. I just did what the bug report template told me:
I played a little bit around with that problem. It seems to be connected to a change of to . further references: As a quick workaround you can launch the application with: is using an embedded version of java 16.
/cc
The cause may be here: We must not wrap :
Two ways to fix: Fix the embedded JDK. Replace the embedded JDK with package.
Thanks for having a look into this. I guess we should fix the embedded JDK as it's the way how it is shipped and it should be a compatible version. I tried to add to which does not improve the situation.
I tried to do the same thing and I noticed that the exact error message changed to: but I can still run . Not sure what that means. EDIT: I've found in another package that they do run patchelf on jspawnhelper. I've also this to the postFixup: and that made it work. Not sure if this is the most elegant way to do it but I can open a PR and we can discuss that there. Thanks :)
Code change:
scipy ]; <del> nativeCheckInputs = [ nose nose-exclude ]; </del> <ins> nativeCheckInputs = [ pytestCheckHook ]; </ins> pythonImportsCheck = [ "pyscf" ]; preCheck = '' # Set config used by tests to ensure reproducibility

Related discussion:
text: Steps to reproduce the behavior: See Broke 3 days ago, (also broken for python-3.10 and x86_64-darwin, probably here )
Same issue when trying to run .
Code change:
<ins> { lib , python3 , fetchFromGitLab , appstream , desktop-file-utils , glib , gobject-introspection , gtk3 , libhandy , librsvg , meson , ninja , pkg-config , poppler_gi , wrapGAppsHook }: python3.pkgs.buildPythonApplication rec { pname = "metadata-cleaner"; version = "1.0.3"; format = "other"; src = fetchFromGitLab { owner = "rmnvgr"; repo = "metadata-cleaner"; rev = "v${version}"; sha256 = "06dzfcnjb1xd8lk0r7bi4i784gfj8r7habbjbk2c4vn2847v71lf"; }; nativeBuildInputs = [ appstream desktop-file-utils glib gtk3 meson ninja pkg-config wrapGAppsHook ]; buildInputs = [ gobject-introspection gtk3 libhandy librsvg poppler_gi ]; propagatedBuildInputs = with python3.pkgs; [ mat2 pygobject3 ]; meta = with lib; { description = "Python GTK application to view and clean metadata in files, using mat2"; homepage = "https://gitlab.com/rmnvgr/metadata-cleaner"; license = with licenses; [ gpl3Plus cc-by-sa-40 ]; maintainers = with maintainers; [ dotlambda ]; }; } </ins>

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
buildPythonPackage rec { pname = "gcsfs"; <del> version = "2022.5.0"; </del> <ins> version = "2022.8.2"; </ins> format = "setuptools"; disabled = pythonOlder "3.7";

Related discussion:
text: Steps to reproduce the behavior: dvc with aws integration I am running nixos on the unstable branch. Please run and paste the result. Probably fsspec needs an update to 2022.8.2
Will be fixed with .
Oh sorry for the noise, did not search the PRs.
Code change:
libpng pkgconfig mock pytz ] ++ stdenv.lib.optional enableGtk2 pygtk <del> ++ stdenv.lib.optionals enableGtk3 [ cairo pycairo gtk3 gobjectIntrospection pygobject3 ]; </del> <ins> ++ stdenv.lib.optionals enableGtk3 [ cairo pycairo gtk3 gobjectIntrospection pygobject3 ] ++ stdenv.lib.optionals enableTk [ tcl tk tkinter libX11 ]; </ins> <del> patches = stdenv.lib.optionals stdenv.isDarwin [ ./darwin-stdenv.patch ]; </del> <ins> patches = [ ./basedirlist.patch ] ++ stdenv.lib.optionals stdenv.isDarwin [ ./darwin-stdenv.patch ]; # Matplotlib tries to find Tcl/Tk by opening a Tk window and asking the # corresponding interpreter object for its library paths. This fails if # `$DISPLAY` is not set. The fallback option assumes that Tcl/Tk are both # installed under the same path which is not true in Nix. # With the following patch we just hard-code these paths into the install # script. postPatch = let inherit (stdenv.lib.strings) substring; tcl_tk_cache = ''"${tk}/lib", "${tcl}/lib", "${substring 0 3 tk.version}"''; in stdenv.lib.optionalString enableTk "sed -i '/self.tcl_tk_cache = None/s|None|${tcl_tk_cache}|' setupext.py"; </ins> checkPhase = '' ${python.interpreter} tests.py

Related discussion:
text: While going through the documentation I came about a that explicitly requires matplotlib with the TkAgg backend. I tried to generate a nix-shell with matplotlib and tcl/tk and tkinter. However, the script does not execute and instead I get the following error message: In a simplified form: Start nix-shell:Start Python:Try to import matplotlib, configure the backend, and import parts of Tk:Observe the following error message:System: NixPkgs on openSuse 13.2 (Harlequin) (x86_64) Nix version: nix-env (Nix) 1.10 Nixpkgs version: "16.09pre83147." Matplotlib Maintainer:
Judging from the matplotlib expression we don't build against tcl/tk.
I made an attempt to build matplotlib against tcl/tk with the following patch: Unfortunately, compilation fails with the following error message: The linker cannot find the tcl/tk libraries. The linker flags are quite off: They include and the like. This must be due to matplotlib's own build script, as no such flags are set in my bash environment and is executed with the flag anyway.
Code change:
<del> "740f233da00c4fb5bcc225b2e29768824bcecc58" </del>

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
it complains "Cannot create session: Already running in a session". */ runuser-l = { rootOK = true; unixAuth = false; }; <ins> } // optionalAttrs (config.security.pam.enableFscrypt) { # Allow fscrypt to verify login passphrase fscrypt = {}; </ins> }; security.apparmor.includes."abstractions/pam" = let

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
# Nvidia support (lib.mkIf cfg.nvidiaSupport { <del> systemd.services.coolercontrold.path = with config.boot.kernelPackages; [ nvidia_x11 # nvidia-smi nvidia_x11.settings # nvidia-settings </del> <ins> systemd.services.coolercontrold.path = let nvidiaPkg = config.hardware.nvidia.package; in [ nvidiaPkg # nvidia-smi nvidiaPkg.settings # nvidia-settings </ins> ]; }) ]);

Related discussion:
text: CoolerControl does not detect Nvidia GPU when enabled via options Steps to reproduce the behavior: GPU with proprietary drivers (version 555, but might not matter) spits out error about missing and CoolerControl to detect Nvidia GPU ! Logging output: If I manually stop the systemd process and start it detects the requested binaries correctly, which makes me think that the coolercontrold binary just doesn't search the correct paths. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The tools should be on PATH if you check the generated service file. And restarting the daemon would support that I think, since it shouldn't pick up any new paths from the env AFAIU. So might not like whatever state your system is in whenever first launches? I sadly don't have any nvidia system to test this with… I think if you try something like this you could delay the service startup to check if the above guess is correct? (Or override the package with an overlay and patch it into the service that way if this doesn't work the way I think it does)
Restarting the service does not work, as that throws out the same identical error. After adding that to my config, rebuilding and restarting the service, I get this output: which looks like sleep succeeded, but not sure how that would help so I did this instead: Which I either did wrong, but it seems to print the GPU fine? But that made me realize one difference. I am on beta drivers, but as per your code block, you pull in the stable ones... Could that be the distinguishing factor? In which case, maybe it might be better if it pulled in the field rather than hardcode to stable drivers?
Oh sorry, I thought that read "restart coolercontrold". Maybe. Likely.
Code change:
<ins> import ./make-test-python.nix ({ ... }: { name = "fscrypt"; nodes.machine = { pkgs, ... }: { imports = [ ./common/user-account.nix ]; security.pam.enableFscrypt = true; }; testScript = '' def login_as_alice(): machine.wait_until_tty_matches("1", "login: ") machine.send_chars("alicen") machine.wait_until_tty_matches("1", "Password: ") machine.send_chars("foobarn") machine.wait_until_tty_matches("1", "alice@machine") def logout(): machine.send_chars("logoutn") machine.wait_until_tty_matches("1", "login: ") machine.wait_for_unit("default.target") with subtest("Enable fscrypt on filesystem"): machine.succeed("tune2fs -O encrypt /dev/vda") machine.succeed("fscrypt setup --quiet --force --time=1ms") with subtest("Set up alice with an fscrypt-enabled home directory"): machine.succeed("(echo foobar; echo foobar) | passwd alice") machine.succeed("chown -R alice.users ~alice") machine.succeed("echo foobar | fscrypt encrypt --skip-unlock --source=pam_passphrase --user=alice /home/alice") with subtest("Create file as alice"): login_as_alice() machine.succeed("echo hello > /home/alice/world") logout() # Wait for logout to be processed machine.sleep(1) with subtest("File should not be readable without being logged in as alice"): machine.fail("cat /home/alice/world") with subtest("File should be readable again as alice"): login_as_alice() machine.succeed("cat /home/alice/world") logout() ''; }) </ins>

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
''; }; <del> port = mkOption { type = types.int; default = 0; description = '' Port for the server. Option will be removed, use <option>listen</option> instead. ''; }; </del> listen = mkOption { type = types.listOf (types.submodule ( {

Related discussion:
text: I set up a brand new NixOS system with nothing but . After switching to the new configuration, I ran and was surprised to find in there in a and state. I poked around and it turns out that our module refers to in its section: It sort of makes sense, because presumably you want your webserver to spin up after your database, but it feels kinda icky to give completely unrelated (in principle) services dependencies on one another, especially when some of them might not even be on your system. I suppose we could make that entry conditional on , but I'm not sure what the pros and cons of that are.
Yes, I'd think it would better be conditional. Units should get reloaded on system switch IIRC, before starting new services, so I see no danger in that.
I think, this link should be broken unconditionally. In my scenario apache-httpd is used solely for SVN web interface, and while I have running Postgresql instance, they are orthogonal (postgresql is acompanied by tomcat container/nginx pair)
Perhaps, yeah. It also appears to depend on , which I think is a nixops-ism.
Code change:
# build , cmake , ctags <del> , python2Packages </del> <ins> , python3Packages </ins> , swig # math , eigen

Related discussion:
text: Using Shogun as a for another CMake-based project fails because the dependent project cannot properly find the shogun library (via its installed cmake files). Steps to reproduce the behavior: to build a derivation based on shogun files are wrong Everything builds correctly I am trying to build the following derivation However I get an error at the build generation step: This indicates that shogun CMake files are not in the right place and/or are pointing towards the wrong paths.
I fixed the issue with shogun. When installing the configuration files, CMake calculates the prefix to the installed library based on the output directory, instead of the default , and I missed it when I split the derivation into multiple outputs. I wonder why it's not a more widespread issue, only a few derivations patch it. But that derivation still doesn't build: This is in macOS, though. Maybe it works on Linux.
Thanks, is the fix committed yet? The other error is unrelated and I can fix it.
I'm working on the PR.
Code change:
makeWrapperArgs = [ "--prefix PATH : ${lib.makeBinPath [ tarsnap ]}" ]; <ins> checkPhase = '' runHook preCheck nosetests tests runHook postCheck ''; </ins> pythonImportsCheck = [ "tarsnapper" ]; meta = with lib; {

Related discussion:
text: Steps to reproduce the behavior: tarsnapper on nixos-24.05 @ system: host os: multi-user?: sandbox: version: channels(root): channels(asymmetric): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
type = types.listOf (types.submodule bindingCfg); default = []; example = lib.literalExpression '' <del> [ { keys = ["PLAYPAUSE"];  cmd = "''${pkgs.mpc_cli}/bin/mpc -q toggle"; } ] </del> <ins> [ { keys = ["PLAYPAUSE"];  cmd = "''${pkgs.mpc-cli}/bin/mpc -q toggle"; } ] </ins> ''; description = '' Key bindings for <command>triggerhappy</command>.

Related discussion:
text: The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.
Code change:
patchelf --add-needed ${libpulseaudio}/lib/libpulse.so $out/lib/Signal/resources/app.asar.unpacked/node_modules/ringrtc/build/linux/libringrtc.node ''; <ins> postFixup = '' # This hack is temporarily required to avoid data-loss for users: cp ${./db-reencryption-wrapper.py} $out/bin/signal-desktop substituteInPlace $out/bin/signal-desktop  --replace '@PYTHON@' '${python3}/bin/python3'  --replace '@ZENITY@' '${gnome.zenity}/bin/zenity'  --replace '@SQLCIPHER@' '${sqlcipher}/bin/sqlcipher'  --replace '@SIGNAL-DESKTOP@' "$out/bin/signal-desktop-unwrapped" ''; </ins> # Tests if the application launches and waits for "Link your phone to Signal Desktop": passthru.tests.application-launch = nixosTests.signal-desktop;

Related discussion:
text: Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended