jiebi/CodeConvo huggingface dataset:
Code change:
# code, using default options and effectively ignore security relevant # ZFS properties such as `setuid=off` and `exec=off` (unless manually # duplicated in `fileSystems.*.options`, defeating "zfsutil"'s purpose). <del> copy_bin_and_libs ${pkgs.util-linux}/bin/mount </del> <ins> copy_bin_and_libs ${pkgs.util-linux.mount}/bin/mount </ins> copy_bin_and_libs ${pkgs.zfs}/bin/mount.zfs ''}

Related discussion:
text: Trying to update a system to the latest "release" () results in the following error: I don't know how to easily reproduce this. At least for me, it seems to happen because the needs to adjusted. So: Try to update a system that (at least) uses ZFS I guess ... No build failure. N/A It looks like this was caused by . I'm not sure if the ZFS module is the only place that needs to be adjusted after this PR has landed. (authored the PR mentioned above) (approved the PR mentioned above) (ZFS maintainers) Please run and paste the result.
For now, I'm not sure, I can reproduce on 23.11pre504982.. It seems like the fix is obvious though.
While I understand how to adjust the two lines in , I don't know how to deal with the other occurrences of in that file.
Usually you can replace "PATH lookup handle where this binary actually is.
I have a potentially fix in
Someone should prove that before the fix, this was broken with a NixOS test ideally and with this fix, this is unbroken.
I suspect it's related to and that that's not covered by any of the existing nixos tests.
And that in turn can't trivially be tested end-to-end because nixos-generate-config doesn't actually support non-legacy zfs mounts... I've written a test and a little prose about the issue:
Maybe we should consider adding them. Using new mounts is rather convenient when the disk needs to be mounted in a live iso.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Ran into the same exact issue over here. Also running on ZFS root. (The discourse link above is mine.) EDIT: Fixed by updating to master. I think I'll be converting to flakes soon, thanks to this
Fix reverted because it broke basically the entire nixos test suite:
I get this with NixOS 23.05.
are you sure it's exactly that? The util-linux split isn't even on 23.05 so that would be very weird.
Yes
That sounds like you're somehow using unstable util-linux for the stable initramfs generation, and it's not surprising that that would break.
Code change:
# code, using default options and effectively ignore security relevant # ZFS properties such as `setuid=off` and `exec=off` (unless manually # duplicated in `fileSystems.*.options`, defeating "zfsutil"'s purpose). <del> copy_bin_and_libs ${pkgs.util-linux}/bin/mount </del> <ins> copy_bin_and_libs ${pkgs.util-linux.mount}/bin/mount </ins> copy_bin_and_libs ${pkgs.zfs}/bin/mount.zfs ''}

Related discussion:
text: You can try confirming this by temporarily setting both nixpkgs to point to the same (doesn't even matter if it's unstable or stable).
I have unstable for Alacrity which is an application, I don't see how that would affect initramfs generation.
And I don't see how you'd get a split util-linux from 23.05, since wasn't backported there.
Indeed: And in fact: Which is a different util-linux version number than we see in your error message. Finally, your nix flake metadata says your using , and: So something fishy is going on here. You've got an overlay or override or something that's pulling in a different util-linux from unstable. Either that or there's some other build that's occurring as an unexpected transitive dependency that's building a nixos system using an unstable nixpkgs that doesn't contain the fix. Either way, I feel fairly confident in saying this is some obscure and subtle user error.
Code change:
}: stdenv.mkDerivation rec { <del> version = "3.3.4"; </del> <ins> version = "3.3.5"; </ins> pname = "glfw"; src = fetchFromGitHub { owner = "glfw"; repo = "GLFW"; rev = version; <del> sha256 = "sha256-BP4wxjgm0x0E68tNz5eudkVUyBnXkQlP7LY3ppZunhw="; </del> <ins> sha256 = "sha256-1KkzYclOLGqiV1/8BsJ3e+pXMQ6a+sjLwZ7mjSuxxbA="; </ins> }; <del> patches = lib.optional waylandSupport ./wayland.patch; </del> <ins> # Fix freezing on Wayland (https://github.com/glfw/glfw/pull/1711) # and linkage issues on X11 (https://github.com/NixOS/nixpkgs/issues/142583) patches = if waylandSupport then ./wayland.patch else ./x11.patch; </ins> propagatedBuildInputs = [ libGL ];

Related discussion:
text: should hide the cursor but does not on X11. I have not tested this on Wayland or Cocoa. Steps to reproduce the behavior: GLFW 3.3.x (to match unstable, which is currently 3.3.4) GLFW's dependencies ( on X11), build the library's examples. The default CMake build should do the job: using or equivalent. Verify that left clicking the window hides the cursor since is set. NixOS's , build the example manually with . Execute it and now clicking moves the cursor to the center of the window but does not hide it. NixOS build should behave the same as the hand-built one. GLFWCURSOR_HIDDEN is also affected. and
Could you send a strace of you running the example?
Yes I could. It seems that it's not due to how GLFW is built by nix but how dynamic libraries are looked up at runtime. Since the handmade executable only works with I made the wrong assumption: the one linked against nixpkgs' GLFW also work correctly. For the ease of reproducibility this is the program for producing the straces: I'm not sure if this is the cause but something is definitely wrong:
Code change:
# updated by the update script # this is always the commit that should be used with asf-ui from the latest asf version rev = version; <del> hash = "sha256-NISUhxClFAzLQp4o9AzMzasPV9+aBAyDd1tuNT7HJw4="; </del> <ins> hash = "sha256-QrHBmLqvnVfHhBC+AF3YZUOx3ZEKA/FjtjXZW7ust8w="; </ins> }; <del> npmDepsHash = "sha256-kI7kgSw0xs8Hsa/5lhLteDo8TgwyxIxKE1QK92D1Qio="; </del> <ins> npmDepsHash = "sha256-MmNckugDMNlBs6dNg/JRE+Qf5P8LbwIesul+7Osd16Y="; </ins> installPhase = '' runHook preInstall

Related discussion:
text: Package name: ArchiSteamFarm Latest released version: 5.5.2.3 <!-- Search your package here: --- Current version on the unstable channel: 5.5.0.11 Current version on the stable/release channel: 5.4.12.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It helps if I also open the PR when doing the update
Code change:
]; patches = [ <ins> # see https://github.com/mate-desktop/mate-control-center/pull/528 ./0001-Search-system-themes-in-system-data-dirs.patch </ins> # look up keyboard shortcuts in system data dirs ./mate-control-center.keybindings-dir.patch ];

Related discussion:
text: Describe the bug Themes are not listed anymore in the Appearance Preferences for the Mate desktop environment. Some screenshots of a VM running Mate to demonstrate the issue: ! ! Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Is the value of clobbered in the session? In an unwrapped program like , what is its value?
In in a VM with almost only Mate installed:
With the following patch find the themes.
It seems that the function to locate the system themes. This function is returning something like , which is not suitable for NixOS, I suppose. If this is really true, than is not being used. How it used to work before, I do not know.
 uses the environment variable , if it is defined. Does it used to be defined in some NixOS module, and has that changed?
We patch gtk2 like so that function works there without having to set which isn't good. By all means mate shouldn't use this totally deprecated function at all, especially in gtk3.
I may patch it to use and submit upstream.
Code change:
++ lib.optionals withGui [ wrapQtAppsHook ]; buildInputs = [ boost libevent miniupnpc zeromq zlib ] <del> ++ lib.optionals withWallet [ db48 sqlite ] </del> <ins> ++ lib.optionals withWallet [ sqlite ] </ins> ++ lib.optionals withGui [ qrencode qtbase qttools ]; postInstall = ''

Related discussion:
text: fails while compiling The same thing happens with Steps to reproduce the behavior: or: is successfully installed. Here is the output:
Fix in
Thanks On the same system that I encountered the error on, I checkout out the branch with your fix and then ran: The installation worked and is runnable. I'll be doing more testing later today/tomorrow.
Code change:
<ins> { lib, buildGoModule, fetchFromGitHub, stdenv, darwin, copyDesktopItems, makeDesktopItem, xorg, libGL, gtk3, pkg-config, wrapGAppsHook3, }: buildGoModule rec { pname = "picocrypt"; version = "1.34"; src = fetchFromGitHub { owner = "Picocrypt"; repo = "Picocrypt"; rev = version; hash = "sha256-TO72s8v0cpyKjvi0b74vux3+VzTfW540Drtr2bD5xVw="; }; sourceRoot = "${src.name}/src"; vendorHash = "sha256-W982HiosXvDadMJJ0wP6AsalQ/uxklSbbmFp26XQEhM="; ldflags = [ "-s" "-w" ]; buildInputs = [ xorg.libX11 xorg.libXcursor xorg.libXrandr xorg.libXi xorg.libXinerama xorg.libXxf86vm libGL.dev gtk3 ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Kernel ]; nativeBuildInputs = [ copyDesktopItems pkg-config wrapGAppsHook3 ]; CGO_ENABLED = 1; postInstall = '' mv $out/bin/Picocrypt $out/bin/picocrypt-gui install -Dm644 $src/images/key.svg $out/share/icons/hicolor/scalable/apps/picocrypt.svg ''; desktopItems = [ (makeDesktopItem { name = "Picocrypt"; exec = "picocrypt-gui"; icon = "picocrypt"; comment = meta.description; desktopName = "Picocrypt"; categories = [ "Utility" ]; }) ]; meta = { description = "Very small, very simple, yet very secure encryption tool, written in Go"; homepage = "https://github.com/Picocrypt/Picocrypt"; changelog = "https://github.com/Picocrypt/Picocrypt/blob/main/Changelog.md"; license = lib.licenses.gpl3Only; maintainers = with lib.maintainers; [ ryand56 ]; mainProgram = "picocrypt-gui"; }; } </ins>

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:
|| cfg.duoSecurity.enable)) ( '' <del> auth required pam_unix.so ${optionalString cfg.allowNullPassword "nullok"} ${optionalString cfg.nodelay "nodelay"} likeauth </del> <ins> auth optional pam_unix.so ${optionalString cfg.allowNullPassword "nullok"} ${optionalString cfg.nodelay "nodelay"} likeauth </ins> '' + optionalString config.security.pam.enableEcryptfs '' auth optional ${pkgs.ecryptfs}/lib/security/pam_ecryptfs.so unwrap

Related discussion:
text: Describe the bug When using krb5 together with samba & winbind for login in an AD, login works everywhere except . So or for example work just fine. However, when is used (either through the binary in the shell or through a tty or display manager), I get: Up on further inspection, I noticed a difference in the respective pam service files. Most of these files have with one notable difference: has If I change the in by , I can login to AD accounts without problem even using or . To Reproduce Steps to reproduce the behavior: (It's not realistically possible to reproduce the full setup) an AD with krb5, samba (+winbind) and a custom pam winbind service ` Expected behavior Login works for AD users with , and all the same. Additional Notes I'm by no means an expert in the domain of domains. What I however wonder is, how others solved this issue when integrating NixOS machines in an AD. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Update: This seems to be related to the section following in the pam module. Namely, if any of , , , , , or is true, is , breaking any remote auth (like LDAP/AD/...). Why is this the case? Do these things (like kwallet or gnome-keyring) only work when called after ?
I marked this as stale due to inactivity. &rarr;
This is not stale.
At least for sssd, it looks like gnome keyring would be propagated correctly (). So probably the comment pamunix is marked as 'sufficient' on NixOS which means nothing will run after it succeeds. Certain modules need to run after pamunix prompts the user for password so we run it once with 'required' at an earlier point and it will run again with 'sufficient' further down. We use tryfirst_pass the second time to avoid prompting password twice from is likely not true anymore for sssd
Fixed by .
Code change:
, pythonAtLeast , fetchFromGitHub , substituteAll <ins> , fetchpatch </ins> , gdb , django , flask

Related discussion:
text: Steps to reproduce the behavior: (warning: veeery long) Seems caused by Also previously reported (if I'm reading the many thousands of lines of output right) to be another instance of Breaks: .
This appears to have been fixed somewhere between and
I have no idea how you tested, but after a (pulling branch), I fail to build this same package. Now with the newer hash: I vote for this issue to be marked as "prematurely-closed", and thus re-opened.
debugpy was blocking my nixos rebuilds through . Updating to resolved it for me. That's about all the testing I did at the time, and figured it was good. Sorry about that.
Yep! Looks like this is related to flaky process test timeouts (which are more likely to fail on less powerful / overworked devices). should fix this!
You can checkout to see when the fix will be applied to the channel you're using.
Code change:
--argstr libPath "$libPath"  --argstr pkgsLibPath "$pkgsLibPath"  --argstr nixosPath "$nixosPath"  <del> --arg modules "[ $modules ]"  </del> <ins> --arg modules "import $modulesPath"  </ins> --argstr stateVersion "${options.system.stateVersion.default}"  --argstr release "${config.system.nixos.release}"  $nixosPath/lib/eval-cacheable-options.nix > $out 

Related discussion:
text: When building nixos top level, will be too long to consume. I don't have a minimal config to generate the drv but here is an example: No Error Related code: Not entirely sure which version is causing the failure --- used to be able to built on but seems to be failing afterwards. Will update once find the exact hash. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The module list grows over time, so it would make sense to hit the limit at some point. I suppose you could write the expression to a file and pass to fix the problem. I don't get why this derivation is called "lazy" though.
Code change:
<ins> { stdenv , fetchurl , appimageTools , makeWrapper , electron_8 }: stdenv.mkDerivation rec { pname = "jitsi-meet-electron"; version = "2.0.0"; src = fetchurl { url = "https://github.com/jitsi/jitsi-meet-electron/releases/download/v${version}/jitsi-meet-x86_64.AppImage"; sha256 = "11ci9dqhy8hkb4fwykjvcvai20ahqhjil825n1y1xf663ch8by93"; name="${pname}-${version}.AppImage"; }; appimageContents = appimageTools.extractType2 { name = "${pname}-${version}"; inherit src; }; dontUnpack = true; dontConfigure = true; dontBuild = true; nativeBuildInputs = [ makeWrapper ]; installPhase = '' runHook preInstall mkdir -p $out/bin $out/share/${pname} $out/share/applications cp -a ${appimageContents}/{locales,resources} $out/share/${pname} cp -a ${appimageContents}/jitsi-meet.desktop $out/share/applications/${pname}.desktop cp -a ${appimageContents}/usr/share/icons $out/share substituteInPlace $out/share/applications/${pname}.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' runHook postInstall ''; postFixup = '' makeWrapper ${electron_8}/bin/electron $out/bin/${pname}  --add-flags $out/share/${pname}/resources/app.asar  --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ stdenv.cc.cc ]}" ''; meta = with stdenv.lib; { description = "Jitsi Meet desktop application powered by Electron"; homepage = "https://github.com/jitsi/jitsi-meet-electron"; license = licenses.asl20; maintainers = with maintainers; [ prusnak ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Related discussion:
text: Related to Project description Jitsi Meet desktop application powered by Electron Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix, linux, darwin,
+1 as the App seems to have some benefits over using just a browser. Whoever starts working on this, please remember to deactivate the auto-update functionality.
Also I would suggest to make sure we are using a recent version of Electron and nodejs, as don in this fork:
There was a 2.0.0 release two days ago: I think this fixes the outdated dependencies issue mentioned in the previous comment.
Yes a pull request from the fork I mentioned before was accepted.
I fixed the outstanding issues and PR is ready for review
Code change:
{ lib, stdenv , fetchurl , makeDesktopItem <ins> , writeText </ins> # Common run-time dependencies , zlib

Related discussion:
text: When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?
Code change:
{ lib, stdenv , fetchurl , makeDesktopItem <ins> , writeText </ins> # Common run-time dependencies , zlib

Related discussion:
text: The person on uses wayland (with sway). I currently still use x11 (with i3) and haven't tested it with wayland.
That did it! I missed that you should specify the file in the path. I'm using AwesomeWM.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The person on had the same problem and the same solution :-)
Why did you close this issue You can't seriously think that this temporary workaround is an acceptable permanent solution to this problem? While we still don't have a permanent solution, it should be as easy as possible for users to find information about this workaround. By closing this issue we signal to people that this problem has been solved. And people currently experiencing this problem on a fully up-to-date system will probably not think about looking into closed issues, because the issue is still there.
I am also experiencing this issue. The fix worked for me.
Confirmed. The issue is still present. Default installed value of is 127.0.0.1. Changing it to resolves the problem.
This issue only started happening on my machine after deleting today.
Still an issue. I'm using TBB with firejail and I have to apply the workaround at every restart. TBB creates the folder but not a profile inside (this wouldn't be a problem for me if connection works out of the box). about:config - = tor-browser-bundle-bin 12.0.5 firejail-0.9.72 nixos-unstable
By default, the service runs on port 9050 and the control port on 9051. This is configured in the torrc file: Your firewall may be blocking some of these ports bound by default to localhost which normally point to 127.0.0.1
The PR for Tor Browser 13 removes the current workaround again, because it seems the issue was fixed upstream: I would be grateful if some of you could give this a try and report if it's still working (or working again).
Code change:
<del> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config , alsa-lib, libtool, icu </del> <ins> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config, makeWrapper , alsa-lib, alsa-plugins, libtool, icu, pcre2 </ins> , pulseaudioSupport ? config.pulseaudio or false, libpulseaudio }: stdenv.mkDerivation rec { pname = "mimic"; <del> version = "1.2.0.2"; </del> <ins> version = "1.3.0.1"; </ins> src = fetchFromGitHub { rev = version; <del> repo = "mimic"; </del> <ins> repo = "mimic1"; </ins> owner = "MycroftAI"; <del> sha256 = "1wkpbwk88lsahzkc7pzbznmyy0lc02vsp0vkj8f1ags1gh0lc52j"; </del> <ins> sha256 = "1agwgby9ql8r3x5rd1rgx3xp9y4cdg4pi3kqlz3vanv9na8nf3id"; </ins> }; nativeBuildInputs = [ autoreconfHook pkg-config <ins> makeWrapper </ins> ]; buildInputs = [ alsa-lib <ins> alsa-plugins </ins> libtool icu <ins> pcre2 </ins> ] ++ lib.optional pulseaudioSupport libpulseaudio; <ins> postInstall = '' wrapProgram $out/bin/mimic  --run "export ALSA_PLUGIN_DIR=${alsa-plugins}/lib/alsa-lib" ''; </ins> meta = { description = "Mycroft's TTS engine, based on CMU's Flite (Festival Lite)"; homepage = "https://mimic.mycroft.ai/";

Related discussion:
text: I want to use the TTS Mimic on a Debian 11. After installation, I Tried reading a text. Cli usage give me an "alsa lib error". Steps to reproduce the behavior: -env -iA -t "hello world" A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Maintainer information:
works perfectly on NixOS 21.05. Can you elaborate more about your sound setup? While geared toward NixOS, this thread might give useful information to debug further: Also try running ALSA tools or CLI audio applications natively from Debian and via to observe any differences in behaviour.
The above works for me too on NixOS, at least. I'm not familiar with how ALSA and PulseAudio in nixpkgs integrate with non-NixOS systems; perhaps a thread on Discourse might be of more help.
I was able to reproduce your issue on Ubuntu 20.04. It seems this is . A few workarounds are mentioned in the linked issue.
It seems mimic just needs a proper wrapper: should give you some output.
Ok, I found a solution with inspiration. alsa-lib-1.2.4 doesn't containt but if i installed alsaPlugin (nix-build -A alsaPlugins '<nixpkgs'), this works for me : However, not really user friendly.